0,0
рейтинг
26 ноября 2011 в 18:18

Разработка → Уникальные возможности Tarantool


Tarantool — это крайне интересная база данных.
Представление о ней можно получить из доклада Константина Осипова Tarantool: как обрабатывать 
1,5 млрд запросов в сутки?

Этой заметкой я хочу обратить внимание на уникальные возможности, которые отличают Tarantool от других подобных решений и делают его полезным инструментом.
Кроме того, я расскажу, чем можно помочь этому открытому проекту и почему это круто :)


Что такое Tarantool


Ключевые слова для прямой загрузки в мозг
nosql, key-value, in-memory, durable, write-ahead log, snapshot, master-slave replication
  • Это очень быстрая in-memory база данных
  • Модель данных «ключ — структурированное значение»
    Каждое значение — это кортеж из произвольного количества полей.
    Например:
    (101, "johnsmith", "25Ezk62$i2Z12QYY", "USA")
    (102, "ivankuznetsov", "35Fal73$y3x23KZZ", "RUS")
  • Первый элемент кортежа — это первичный ключ, по которому осуществляется доступ ко всему кортежу
  • Чтение всегда из памяти
  • Данные в памяти защищены логом транзакций и снапшотами на диске

Tarantool — это зрелый проект

Tarantool разработан в Mail.ru и активно там используется.
В некотором смысле, Tarantool можно сравнить c Nginx, который разрабатывался в Rambler, и только через некоторое время обрел заслуженную славу и признание сообщества, будучи открытым проектом.


Ключевые возможности Tarantool


Прежде всего, хочу подчеркнуть, что Tarantool — это не клон Redis или, уж тем более, Memcached.
С Redis он близок по духу, но не очень-то похож по возможностям. Для одних задач Redis подойдет лучше, для других — лучше Tarantool.
  1. Пространства ключей
    Пространства — это коллекции объектов. Можно думать о пространствах, как об отдельных таблицах. Это удобно, поскольку в одной коллекции, как правило, находятся сущности одного типа. В том же Redis для разделения сущностей предлагается просто добавлять к ключам префикс ("user:1001", "session:9994513"). У каждого пространства в Tarantool может быть свой набор индексов.

  2. Целочисленные ключи
    Наряду со строковыми ключами в Tarantool есть поддержка целочисленных ключей (32 и 64 бита)
    Во-первых, очевидно, что доступ по 32 или 64-битным ключам быстрее, чем по ключам произвольной длины. Во-вторых, это может быть просто удобнее, например, при использовании числовых ID в традиционной (SQL) базе данных.

  3. Вторичные индексы
    Большинство key-value хранилищ ограничиваются доступом по первичному ключу. В Tarantool можно делать выборки по отдельным атрибутам кортежа (для этого поле должно индексироваться).

  4. Вторичные индексы могут быть не уникальны
    Это означает, что запрос по не уникальному полю может возвращать множество значений. Например: «вернуть всех пользователей с кодом страны RUS»

  5. Композитные индексы
    В один вторичный индекс можно включить несколько полей кортежа. Это полный аналог композитных индексов в «традиционных» (SQL) базах данных. Композитные индексы позволяют делать запросы по неполному совпадению (wildcard). Когда известна только первая часть индекса, Tarantool вернет все подходящие значения.

  6. Выборки по диапазонам значений
    В отличие от большинства key-value хранилищ, в Tarantool есть возможность извлекать диапазоны значений (только для целочисленных ключей и только при использовании индекса типа TREE)
    Кстати, это делается хранимой функцией (см. ниже)

  7. Хранимые функции на Lua
    В Tarantool можно писать хранимые функции на Lua. Lua очень простой язык, который поддерживает JIT-компиляцию. Короче говоря, они очень быстрые. Хранимые функции позволяют реализовать схемы данных с достаточно сложной структурой. Например, fifo или какие-нибудь кольцевые буферы.

  8. Фоновые процессы внутри базы данных
    На Lua можно сделать не только обработку отдельных запросов, но и реализовать фоновые обработчики (в режиме кооперативной многозадачности).

  9. Простой SQL-клиент
    Стоит использовать, прежде всего, для экспериментов и интроспекции при разработке. Поддерживаются простые SQL-запросы, типа SELECT * FROM t0 WHERE k0 = 42.


Как начать использовать Tarantool прямо сейчас

  1. У Tarantool есть простой SQL-клиент
    С его помощью можно делать любые запросы и экспериментировать, не написав ни строчки кода
  2. Tarantool поддерживает протокол Memcached
    Используйте Tarantool, как лучший Memcached (со снапшотами и логом транзакций на диске).
  3. Для Tarantool есть клиентские библиотеки на python, ruby, perl, php, java и C
    Подумайте, как использовать возможности Tarantool в вашем проекте


Чем я могу помочь?


Tarantool — это зрелая система, которая давно находится в реальной эксплуатации.

Но как открытый проект он существует относительно недавно. Поэтому информации в интернете мало, сообщество небольшое, документация не идеальна, книжек O'Relly не издает...

И это хорошо! Ведь в проекте, который уже широко известен, трудно сделать что-то существенное — все сделано до нас. А здесь — нет!

Поэтому у вас есть реальный шанс внести значительный вклад в развитие этого перспективного проекта.
Ранние последователи всегда в выигрыше. Этот проект вполне может стать заметным, например, как Nginx.

Присоединяйтесь сейчас и лучи славы коснутся вас :)
  • Пробуйте! Задавайте вопросы в рассылке. Пишите посты в блогах и
  • Используйте в своих проектах (можно начать просто с замены memcached)
  • Сделайте пакеты для вашего дистрибутива
  • Создавайте и дорабатывайте клиентские библиотеки.
  • Присылайте патчи к серверу. Или даже форкайте и делайте что-то свое!


Ссылки
Константин Черкасов @coxx
карма
62,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (153)

  • +15
    Да уж, по логотипу сразу видно, какая компания его разработала, могли бы и не писать)
  • +3
    >Tarantool — это крайне интересная база данных.
    Это не база данных.
    • +6
      Ну Вы бы тогда после отрицания, написали бы тогда истину, на Ваш взгляд
      • +4
        Формально, коллега прав.
        Так же как и Apache — это не веб сервер.
        База данных — это Tarantool/Box. Просто Tarantool, как следует из описания на сайте — это TCP сервер.
        На мой взгляд отдельно о Tarantool/Box будет иметь смысл говорить только если на базе этого TCP-сервера появится еще какой-нибудь Tarantool/*.

        • +1
          Если окончательно снобить, то он не база данных, а СУБД =)
  • +2
    >Присоединяйтесь сейчас и лучи славы коснутся вас :)
    хм, лицензия не самая дружелюбная для присоединения к вам :)
    багтрекер на launchpad, проект на гитхабе… упоминание о вики только для вида…

    >У Tarantool есть простой SQL-клиент
    соответствует стандарту sql 99?
    • 0
      >>У Tarantool есть простой SQL-клиент
      > соответствует стандарту sql 99?
      Лучше не думайте, что в Tarantool есть SQL, как язык запросов.
      SQL-клиент — это просто утилитка, которая сделана для удобства администрирования и разработки. Она локально парсит очень небольшое подмножество SQL и на сервер отправляет уже свои команды. Либо ругается, что invalid syntax. Для использования в живой системе надо использовать клиентскую библиотеку.
      • 0
        тогда не стоит акцентировать внимание на том что там есть sql ;) а ещё лучше что бы там не было sql синтаксиса, просто потому что он излишен в данном продукте :)
        • 0
          Так в самом сервере его и нет :)
          Есть SQL-клиент, который… ну как это сказать, как бы эмулирует SQL, что ли…
          Вам было бы легче, если бы вместо SQL-клиента была бы клиентская утилита с опциями вида:
          tarantool get --index 0 --space 0 --key 42?
          • +2
            tarantool get --index 0 --space 0 --key 42 не сложнее чем select * from table where id = 42. это как сравнивать русский и английский языки.
            • +3
              Ну да. Только английским владеет кажый второй, а русским гораздо меньшее количество.
              • +2
                это китайским или арабским владеет каждый второй, а английским — от силы каждый 18-й.
                • –3
                  Зануда.
        • 0
          sql аналог очень удобен для работы в консоле
    • +5
      > багтрекер на launchpad, проект на гитхабе… упоминание о вики только для вида…

      Ну, фиг его знает — видимо, «так повелось».
      На счет wiki — там ничего нет, видимо, потому что никто ничего не написал :) Собственно, welcome.
      Оригинальная документация есть и живет отдельно от wiki.

      К слову, я-то сам не разработчик и не сотрудник mail.ru.
      Просто, на мой взгляд, это клевый проект, который стоит поддержать.

      • +1
        поддерживаю — проект клeвый
        только начальство боится его исползовать в продакшене
    • НЛО прилетело и опубликовало эту надпись здесь
      • +6
        для меня нет, просто удивляет не желание использовать стандартный багтрекер гитхаба ;)
        • 0
          Он мягко говоря отвратителен для более-менее чего-нибудь серьезного.
    • 0
      чем вам не нравится лицензия?
      • –2
        ну по лицензии получается то, что над проектом работает только 1 человек и mail.ru — а работают над кодом судя по коммитам не меньше 4х человек…
        • НЛО прилетело и опубликовало эту надпись здесь
    • +4
      DYPA,

      launchpad содержит не только bugs, но ещё и например blueprints.launchpad.net/tarantool, а также questions, milestones, series и т.д. У нас можно достаточно легко понять над чем мы работаем и что войдёт в 1.4.4, к примеру — достаточно зайти на launchpad.

      Это интегрировнная среда open source разработки, на ней хостится куча open source projects, такие как, например, Drizzle, MariaDB, и т.д. Это не отменяет факт того, что у drizzle есть drizzle.org а у mariadb есть аж два сайта — askmonty.org, mariadb.org.

      Github — отличный хост для Git репозиториев, с возможностю интеграции с кучей сторонних инструментов, но как issue tracker явно слаб.

      Вики — мы ещё есть на en.wikipedia.org/wiki/Tarantool, но в целом документцию мы пишем в DocBook, а Wiki для текущих заметок и того, что в документацию ещё не попало.

      Ещё у нас есть русскоязычный список рассылки, и англоязчный список рассылки.
      Надеюсь, голова не закружилось: примерно так устроен любой open source проект, просто проекты повзрослее хостят всё на собственном домене.
      • +1
        Проекты повзрослее пользуются GitHub для багтрекинга. Ко всему прочему, wiki там совсем не плох, а ещё можно целиком построить на базе GitHub статический сайт (с комментариями на Disqus, к примеру), и генерацией из исходников, который ко всему прочему можно повесить на собственный домен. Хотите социализироваться — сделайте это, и не заставляйте бедняг регистрироваться на десяти сайтах. Ещё если уж такой взрослый проект, можете ещё канал на irc открыть.
        Но вообще статью нужно было бы начинать с того, что вы чем-то лучше Redis'а, хотя бы по производительности.
        • 0
          > Но вообще статью нужно было бы начинать с того, что вы чем-то лучше Redis'а,
          > хотя бы по производительности.

          Я для себя решил, что нет смысла сравнивать инструменты в стиле «X, лучше чем Y».
          Надо смотреть на возможности, стабильность, возможно, роадмэп. И, если не хочется первопроходцем — на то, кто уже это использует и для чего.
          А «лучше-хуже» — это оценка применимости к конкретной задаче.

          На счет производительности: в докладе кое-что есть. И это надо делать ну уж ооочень большую систему, чтобы имело забивать голову разницей в производительности ± 10 процентов. На мой взгляд фичи важнее (по-моему, потенциально самое полезное — это вторичные индексы).
  • –12
    > Уникальные возможности Tarantool
    > И это хорошо!
    > Ранние последователи всегда в выигрыше.
    image
    • НЛО прилетело и опубликовало эту надпись здесь
      • –5
        Не нравятся многочисленные призывы поддерживать продукт с весьма общими и сомнительными обоснованиями. Естественно, вызывает ассоциацию с такой картинкой (не хватает 2-3 парней вокруг, которые как бы не при деле. Но вот автор статьи говорит, что не при деле). При том, что он успешно развивается под финансированием mail.ru и привлекать бесплатную рабочую силу нет оснований. С продуктом знакомился в более раннем обзоре. Смущает ещё, что название ориентировано на неграмотных русских (в английском произносится «тарАнтула»), поэтому ухудшаются перспективы выхода в международный круг разработчиков.
        • +9
          А если вы увидите статью про Redis, то сразу будете думать, что она заказана VMWare?
          А если про Hadoop, то не иначе Cloudera за этим стоит. ОК.

          > При том, что он успешно развивается под финансированием mail.ru и привлекать бесплатную
          > рабочую силу нет оснований.

          Mail.ru делает систему под себя. А я хочу, к примеру, пакет под Ubuntu. А Mail.ru берет и не делает. Вот гады. А ниже в комментариях человек спрашивает про клиентскую библиотеку для Node.js. А Mail.ru берет и не делает. За что им только деньги платят.

          > Смущает ещё, что название ориентировано на неграмотных русских (в английском произносится «тарАнтула»), поэтому ухудшаются перспективы выхода в международный круг разработчиков.

          Скажите это группе The Beatles.
          • +1
            Redis и Hadoop изначально были opensource и только потом получили поддержку VMWare и Cloudera.
            • +7
              Редис Сальваторе изначально написал для решения задачи, поставленной ему работодателем, потом стал делать full time. Hadoop — open source реализация Google BigTable, созданная в Yahoo, т.е. тоже на коммерческой основе.
              Большинство open source проектов так или иначе спонсируются — сначала одним вендором, потом, если проект успешен, сообществом.

              Интерес Мейл.Ру в *открытой* разработке:
              — во-первых, это важный компонент инфраструктуры, т.е. чем выше его качество — тем лучше для mail.ru. Опять же, если проект будет успешен, значит вложенные именно в *открытую* разработку деньги потрачены не зря — они вернутся в виде communinty feedback, патчей и т.д

              — во-вторых, это технологический маркетинг — вот, например, эта ветка «льёт воду на мельницу» распространения среди engineering community технологий mail.ru, просто понимания того что она делает — что для компании ориентированной на создание софта немаловажно.
              • 0
                Да и OpenSource для мейла это помоему прорыв. Браво! Приятно удивлён.
        • +2
          Tarantool — от слова таран (Battering ram). Логотип сменим.
          • 0
            Я все полгода, что знаю, думал о пауках :)
            • 0
              Я просто уверен, что название получилось так:
              1. На листе бумаги нарисовали кружок: «это, типа, у нас ядро сервера»
              2. К кружочку по сторонам подрисовали палочки «это, типа, TCP-коннекты»
              Получился паучок. Потом игра слов: tul / tool
              :-D

          • 0
            и я тоже :)
          • 0
            а логотип давно надо было придумать :)
          • 0
            А я бы обыграл это логотипом: паук-тарантул держит в лапах таран (ручной небольшой такой) и замахивается разбивать двери. На английском будет не так понятно, но на русском может зайти вполне :)
        • 0
          Даже полгода назад у нас ещё был совсем другой «продукт».
          А в целом, по-моему правильнее в Вашем случае написать свой обзор типа «почему Tarantool — @@%@#$», а не постить картинки.

          Попробуйте найти подобный обзор любой современной nosql системы — днём с огнём не сыщешь. Вон про Моно один аноним решился написать, и то чуть не заклевали:

          nosql.mypopescu.com/post/12466059249/anonymous-post-dont-use-mongodb

          И ещё, от того, что в России вдруг все будут любить или не любить Tarantool мало что зависит, русская programming community замкнута на себе (мы в этом похожи на японцев), так что «втюхивать» ей что-то смысла просто нет.
          • 0
            Кстати, на счет монго — говорил с одним приятелем (гуру от разработки) — говорит, пробовали этот монго и отказались. Ну т.е. не то чтобы совсем отказались, но в нем хранятся только некритичные и/или временные данные, т.к. надежность и целостность у него в заднице. Если реплицировать на кучу машин — то да, но на 1—2 просто опасно.
            Собственно, он вроде и проектировался как раз для больших репликаций, так что тут сложно сказать баг это или фича, но как есть…
            • 0
              хороший был доклад на HiLoad
              «Почему не использовать MongoDb»
  • +2
    Очень интересно, надо сказать.
    Ключевые возможности очень вкусные.
    И во сколько раз поиск по вторичному индексу будет медленнее, чем по первичному?
    • 0
      Я не знаю, как устроены индексы внутри, так что предположить не могу.
      Не думаю, что эти цифры хоть как-то заметны на фоне других задержек (передача пакетов по сети, распаковка-упаковка протокола).

      Но вообще, лучше самому пробовать и моделировать какую-то конкретную задачку.
      • 0
        Можно в следующем посте подробнее про протокол, вот с прочими NoSQL всё гораздо понятнее, про библиотеки за исключением $PHP, о масштабируемости? А то многое остаётся за кадром.
    • 0
      вторичный индек как правило Tree (хотя может быть и Хеш) — первичный всегда Hash
      у них разгая сложность( O(1) & O(Ln(n)) )
      тут надо эксперементировать в зависимости от количества данных
      на практике вторичные индексы нужны для выбора подмножества: см паттерн «Справочник с разделами» слайд 22 www.slideshare.net/akalend/nosql-tarantool
      • 0
        > первичный всегда Hash
        Неа. Он только уникальным должен быть обязательно.
        Я пробовал — можно TREE сделать (выбирать диапазоны по первичному ключу).
        • 0
          изначально было как akalend пишет, мы исправили.
  • +2
    Из node.js использовать судя по всему нельзя пока?
    • +3
      Если вдруг захотите написать клиентскую библиотеку — обращайтесь. Я недавно соорудил клиента на python, так что смогу что-нибудь подсказать.
    • 0
      есть клиент на Си,
      можно использовать в любой языковой системе
      надо только приложить немного усилий.
      • 0
        думаю копать надо здесь: node-v0.6.3/doc/api/api/addons.html
  • –7
    документация на англ…
  • +1
    1.5 млрд в сутки.

    Открываем презентацию: 1.5^{8} в сутки.
    • 0
      Блин, реально, обсчитали! Вот сволочи!
      • –2
        Ой, а стало ещё лучше! 1.5^(10^8). Офигеть! Это около 10^17000000, с каждой секундой всё лучше и лучше!
      • +1
        А можно всё-таки ошибку в презентации поправить, а-то мой мозг не справляется с этим числом: 1.5 в степени сто миллионов запросов в сутки.
  • +5
    И еще: если база крутится в памяти, на сколько лог и снапшоты защищают целостность данных на случай внезапного падения? ну, свет вырубился, например
    • +2
      Посмотрите доклад — где-то с 20-й секунды там есть ответы про сброс на диск.
      Эти вопросы («что будет, если данные не записались на диск и выключился свет») — они ведь и для традиционных БД актуальны. В Tarantool, как и в PostgreSQL параметры, связанные с fsync, можно настраивать.
  • +1
    Прошу прощения, я не нашел в документации упоминания об ограничении размера хранилища, имеется ли данная функция в наличии?
    • 0
      slab_alloc_arena эффективно ограничивает память под данные (но не под индексы). Однако WALы могут быть даже при фиксировнном размере данных очень большими, если update rate высок.
  • +1
    Redis, как утверждают, lock-free — а как у вас с contention? Списки? Pubsub?
    • 0
      Посмотрите доклад. Tarantool тоже lock-free. Модель данных отличается от Redis. Связных списков, как в Redis нет. Pubsub «из коробки» тоже нет. Наверняка что-то можно соорудить на встроенном Lua…
      Но все же, если вам лучше подходит Redis — лучше его и использовать.
      • +1
        А можно вкратце очертить список задач, где лучше тарантул, а где редис?
        • 0
          Список задач… Ну, как тут вкратце расскажешь… Вы про Redis лучше почитайте, и сразу поймете, в чем разница.
        • +1
          я разработал онлайн игру под тарантул
          почти полностью заменил мускуль
        • 0
          задачи: выборка регионов, очереди, нотификации
        • +5
          Во-первых, когда вообще на это нужно смотреть: если у вас высокие нагрузки и есть очень горячие данные, которые кладут традиционную систему (MySQL, PostgreSQL, тот же Mongo).
          При этом на железо деньги выкидывать совсем не хочется (и РСУБД можно масштабировать, прсото там выше издержки на запрос).

          Хранение сессий, профилей, нотификаций и т.д.

          Вы начинаете смотреть в сторону сначала Memcached, потом Redis, Citrusleaf и т.л.

          Так вот ключевая возможность Tarantool — возможность на Lua реализовать свой pattern и бизнес-логику на сервере. Мы, вполне возможно, уступаем Redis по тем структурам, которые в него заложены — очереди, списки и т.д., но у нас есть возможность атомарно реализовать доступ к данным под конкретный проект, то есть что-то, что на структуры «из коробки» неудобно ложится.

          Ну и плюс мы более тщательно подходим к надёжности данных, система изначально использовала Write Ahead Log, и была написана под транзакции.
          • 0
            Спасибо.
            Просто есть планы сделать один проект, который, надеюсь, будет highload :) И сейчас как раз думаю над тем, что на чем реализовывать.

            Из всего вышесказанного сделал предвариттельный вывод, что сессии и очереди событий (т.е. то что по факту запрашивается исключительно по ключу) лучше хранить в redis, а вещи вроде юзер-профайлов (которые чаще всего запрашиваются по ключу, но иногда нужен и поиск по другим полям) — в тарантуле.
            Ну и для некоторых вещей РСУБД.

            А как у тарантула с репликацией?
            • +1
              Мэйл хранит сессии в Tarantool тоже. Все хранимые процедуры, которые использует mail открыты в github.com/mailru/tntlua. Возможно это кому-то ещё пригодится. Если Вы напишете свои хранимки, постучитесь пожалуйста в список рассылки или мне, я добавлю вас в список коммиттеров на github — я лично очень хотел бы чтобы всё что делалось было open source.

              Репликация есть, асинхронная, конфигурируется динамиески. Вот дока:
              tarantool.org/tarantool_user_guide.html#replication
              • 0
                Когда я наконец доберусь до непосредственной разработки — обязательно)
                И спасибо за такой продукт. Откровенно говоря, я когда NoSQL копал, был разочарован, что вот именно такого нету. А тут хоп — и появился ))
                • 0
                  появился год назад
  • 0
    Клиент на Java тоже имеется.
  • 0
    > Ключевые слова для прямой загрузки в мозг
    > durable

    А как насчет прочих компонентов ACID: изоляции и согласованности?
    • 0
      Пишем.
      • 0
        Зачем? Какой ACID в быстрых базах?
        • +3
          Быстрые — не значит говёные.
          • 0
            А как с CAP? Храним сессии в Хабаровском ЦОД'е, который не успел целиком зареплицироваться в Новосибирский, упал под ударом молнии, пользователь получает сообщение «подождите, ждём восстановления ХЦОД» или «ваша сессия не установлена»?
            • 0
              Напишите, пожалуйста, более подробно что вы хотите.
              Что такое сессия, насколько это важные данные.
              Мы, в частности, планируем синхронную и частично-синхронную репликацию:

              То есть, при записи сессии можно будет выставить на клиентском запросе флаг WAIT_RPL_SYNC, и тогда тарантул убедится что этот конкретный write прошёл в реплику, прежде чем отдавать «ОК», и если не прошёл, то откатит его локально.

              Возможно, это не совсем то, что нужно. Возможно, Вам нужен Voldemort, который каждый ключ умеет хранить в нескольких нодах (тарантулах), и если одна из нод упала, восстанавливает её с помощью копий.

              • 0
                Про сессии это скорее к вам вопрос.

                Мне лично по счастью хватает memcached.
        • +2
          В нашей архитектуре есть возможность реализовать ACID по принципу pay per use — то есть, эффекта на производительность запросов состоящих из одной команды поддержка acid не окажет. У нас уже есть write ahead log, и предусмотрена возможность отката последнего запроса. Осталось лишь расширить поддержку на несколько запросов.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      У монго javascript. У нас Lua.
      У монго данные в память могут не влезать. У нас пока такого нет.
      У монго в коробке клластер. У нас кластер надо с помощью вспомогательных инструментов сооружать самим.

      Мы ещё не доросли по функционалу до Монго. Но на signle-server у нас производительность существенно выше (как и у Редиса, кстати).

      Одноклассники используют Tarantool как back-end к Project Voldemort, таким образом получают кластер.
      • 0
        мне тоже кажется, что по функционалу — ближе к монго
        у Редиса — куча не связанных типов данных, здесь тип данных один — кортеж, а вот возможностей много.
      • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Что это за измерения такие «в сутки», нельзя было дать значение в секунду или за минуту? Неужто так важно сделать громкий заголовок?
    • +1
      17000 в секунду (если нагрузка равномерная)
  • 0
    Persistance как решается?
    • 0
      Видимо, никак. Что ж, полезно тем, у кого все данные в память влезают…
      • 0
        Не вполне понятно, какой вы смысл вкладываете в слово «Persistance».

        В Tarantool есть снапшоты и WAL. Данные, разумеется, должны влезать в память, поскольку это in-memory database.
  • 0
    Redis: 120k writes, 270k reads
    Tarantool: 100k writes, 260k reads
    (Взято отсюда — www.slideshare.net/profyclub_ru/12-redis-tarantool)
    Увеличение производительности планируется, или это связанно с более обширным функционалом?
  • 0
  • 0
    доклад понравился,
    спасибо за ссылку
    жаль что не смог по присутствовать лично
  • 0
    Кстати, у Redis тоже Lua движок. Никак не пойму, почему не JS :( Очень не хочеться еще один непонятный язык изучать только ради одной системы
    • 0
      при интеграции JS — получаем более медленный движок хранимок
      • 0
        а можно детальнее? Все, что я нарыл по гуглу (навскид) показывает обратное:

        shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=lua

        или даже хабр

        habrahabr.ru/blogs/algorithm/113250/
        • 0
          именно из-за большого времени подключения Сысоев отказался от использования JS
          как языка расширения nginx
          • 0
            а при чем тут nginx? Там немного другой, как мне кажеться, сценарий использования. Да и Lua они тоже не используют. И судя по очень дискутирующей и в чем-то провокационной статье Игоря, там была совсем в другом проблема (а точнее — просто несогласованость с архитектурой nginx-а). При этом заметьте, JS не ограничиваеться именно v8, а статья Игоря как раз про встраивания не языка а аконкретного движка в нгинкс. Так что пока Вы не ответили на мой вопрос :)
            • 0
              что касается тестов, то каждый тест делается при каких-то определенных условий.
              сам сделал тестов на производительность и не мало
              лично я тестов на сравнение Lua vs JS не делал, но верю словам разработчиков mail.ru
              такой вопрос был на HiLoad — я привел лишь их ответ
              не думаю, что они стали бы использовать что-либо более медленное
  • 0
    Меня всегда страшно возмущало, что in-memory databases считают для себя приемлимой производительность меньше миллиона операций в секунду.

    люди, это же память! Скорость доступа — гигабайты в секунду! Как из этого можно выдавать жалкие сотни тысяч операций?

    Предлагаю любую in-memory key-value БД с производительностью в диапазоне 100к-900к называть «очередная не очень быстрая in-memory DB».
    • 0
      не забывай, какой навешан функционал на любую in-memory databases
      бутылочное горлышко в I/O: общение с клиентом через сокет.
      • 0
        Сейчас мне расскажут, что сокет не может обработать такой объём данных. А вот мне почему-то кажется, что таки может.

        Кроме того, почему только сокет? shared memory отменили?
        • 0
          я начну с друго конца:
          из каких компонент состоит inmemory-БД?
          сколько времени (в долях) тратится на прохождение той или иной части
          где узкое место?
          • +1
            Если бы я занимался разработкой in-memory databases, я бы лучше ответил на этот вопрос. Но я потребитель — и я возмущён медлительностью.
            • 0
              >shared memory отменили?
              а с какого боку здесь упомянут shared memory если обмен данными между БД и клиентом идет через сокет.
              • 0
                А зачем его делать через сокет, если он заведомо узкое место? Нет, понятно, что есть задачи где по другому никак, но не все же.
                • 0
                  не всегда БД и WEB сидят на одном хосте
                  • 0
                    Понятно, что не всегда, я написал об этом. Но когда сидят…
    • +1
      Они даже не сотни выдают. Если верить тому, что в статье — 1.5 млрд в сутки — это 17 тысяч в секунду. Если верить тому, что в документации — 1.5e8 — это 1.7 тысячи в секунду. Для сравнения, tokyo tyrant какой-нибудь выдает порядка 150-200 тысяч.
      • –1
        где вы увидели 1.5e8?
      • –1
        Кажется, Вы путаете температуру кипения с прямым углом. 1.5 млрд — это нагрузка на живой системе. Зачем ее сравнивать с цифрами из тестов.
        • –1
          Или я сам перепутал? :-)
        • 0
          Порядок, за редкими исключениями, в тестах и на живой системе будет тот же самый. Крайней редко строят системы, закладывая 100-кратный, не говоря уже о 1000-кратном запасе по скорости обработки, например — это банально неэффективно и дорого. Можно, конечно, держать кластер на 1000 машин, который будет простаивать 99.99% времени — но зачем?

          Если речь о суточных колебаниях в системах массового обслуживания каких-то живых интернет-пользователей — то там в худшем случае колебания в 4-5 раз, в лучше — раза в полтора-два. Такого, что «ночью никого не было, а с утра все как ломанутся» — в норме практически не бывает. Даже если речь о каких-нибудь СМИ, у которых иногда случается какое-нибудь событие вселенского масштаба и все приходят на них читать об этом событии — ну, в 8-10 раз оно вырастает, но не в сто.

          Поэтому — да, я считаю, что по крайней мере цифрой 1.5e8 в сутки — это совсем не то, чем можно гордиться. Особенно если это не на одной машине делается.
          • 0
            Попробую повторить вопрос, где вы увидели эту смешную цифру?
            • 0
              Очевидно, в заголовке Вашей презентации
              • 0
                там 10^8, не 1.5e8. Но вы правы, это тоже ошибка — я просто посчитал нули в цифре 1500000000 :-)
                Пошёл исправлять…
                Реальные нагрузки у нас 60 тысяч RPS, это только один проект, я дал просто консервативную цифру.
                • 0
                  60 тысяч _каких_ requests per second? И это нагрузка на один сервер или на какой-то кластер? Если на кластер — то из скольки машин, как сделан шардинг и т.д.?
                  • 0
                    Я об этом рассказывал в докладе :)

                    ОК, не растаю повторить:
                    — храним все сессии всех пользователей почты, социальной сети и т.д. — всех кто зашёл на mail.ru сервис.
                    — около 200 млн пользователей всего, одновременно хранится (на момент доклада, сейчас уже подросло наверное) около 100 млн. сессий.
                    — средний размер сессии 350 байт.
                    — т.е. 32 ГБ данных, примерно столько же занимают индексы.
                    — размазаны на 2 машины, на каждой машине — 2 инстанса. 64 гб памяти. Т.е. у каждого инстанса примерно четверть данных, это вместе с индексами получается 16 ГБ.
                    — каждый инстанс держит ~5000 updates/sec 10000 selects/sec. Updates идут в целом на каждый чих, т.к. нужно менять время последнего посещения сайта.

                    Т.е. получается по 30 000 на машину, плюс у нас конечно две машины с репликами стоят для updgrades/downgrades, на случай если железо выйдет из строя и т.д.
                    • 0
                      важное добавление — у нас таймауты стоят на отдачу данных — 1 секунда. Изначально они срабатывали иногда во время откладывания снапшота, но мы докрутили пару параметров в конфиге, и они в целом ушли. Мы сейчас основательно смотрим на скорость WAL writer'а, будем оптимизировать дисковую подсистему ещё.
      • 0
        Кстати — это очень часто не принимают во внимание — узким и, потенциально, проблемным местом является не пропускная способность в запросах в секунду, а время отклика на один запрос. В многокомпонентных системах задержки (из-за промежуточной обработки, сетевого обмена и т.п.) вылезают раньше, чем чем будет достингнута предельньная пропускная способность одного компонента. А ведь, в конечном итоге, именно задержки ухудшают user experience.
        • 0
          Я всё это понимаю. Разумеется, мерять производительность нужно в конкурентной среде.
    • 0
      это не embedded database. не сравнивайте client/server (tarantool, redis) и embedded (leveldb, tokyo cabinet), и всё встанет на свои места.
      • 0
        Вполне можно сравнить с Tokyo Tyrant. И я пока как-то совсем каких-то впечатляющих оценок производительности не вижу. Впрочем, оно и понятно — там больше в диск и память будет упираться, каких-то радикальных прорывов там никто уже года 3-4 не показывает.
        • 0
          Вы попробуйте поискать сравнения Redis vs. Tokyo Tyrant. Редис его рвёт. А наша производительность — на уровне Redis.
          • 0
            Для начала — Tokyo Tyrant базируется на Tokyo Cabinet, у которого есть 4-5 совершенно разных вариантов организации данных со своими плюсами и минусами. О которых из них мы говорим?

            Мы тестировали большинство хранилищ на очень банальной задаче: есть ключ (например, 128-битный хэш), для него нужно хранить строчку байт на 100-200 и делать expiration — выкидывать строчки, к которым не обращаются, скажем, в течение 3 суток. Объем — порядка 5-7 млрд. строчек в сутки, ~70-80% уникальные по ключам, т.е. в среднем около 50-80 тысяч записей в секунду. Чтение при этом пренебрежимо малое — в пике несколько тысяч чтений в минуту, в среднем — порядка сотен. Общий объем хранилища таким образом что-то чуть меньше терабайта в сутки, за 3 суток — соответственно, под 3 терабайта.

            Redis бодро начал, но производительность довольно быстро (через час-два после начала) просела на пару порядков — до совершенно неприемлемых уровней — меньше тысячи записей в секунду на один сервер.

            Tokyo Tyrant (со структурой на базе хэш-таблиц) справлялся существенно лучше, стабильно сохраняя порядка 10-12 тысяч записей в секунду на один сервер, с параллельно идущим expiration. Tokyo Tyrant с fixed-size записями и деревьями для сравнения работал еще раза в 3-4 быстрее, но для нас это был не вариант, т.к. в таком случае нет корректного expiration.

            Redis субъективно хорош не тем, что он какой-то сверхскоростной, а скорее фичами, которые позволяют его использовать во многом как альтернативу более традиционным реляционным базам данных. Судя по тому, что я вижу — Tarantool — тоже ориентируется в основном на такую feature-full нишу.
            • 0
              Любопытно, а сколько записей добавилось в Redis когда он начал проседать? И сколько памяти он при этом занимал?
              • 0
                Ну, соответственно, видимо, «за 1-2 часа» — значит, 1/24..2/24 от суточного объема данных — это порядка 40-80 гигабайт в сумме. Сколько тогда было серверов в шарде — сейчас, боюсь, не вспомню.
            • 0
              Redis скорее всего начал проседать т.к. ушёл в своп, нет?
              Что использовалось в Redis, Redis sets?

              Tokyo * — это дисковый бэкенд. Вы не всё меряли, насколько я вижу. Надо ещё мерять время макс-мин на ответ. У всех существующих сегодня дисковых nosql бэк-эндов оно существенно плавает.

              Мы ориентируемся на скорость в том числе. Наличие хранимых процедур никак на скорость подсистемы индексов не влияют. Было бы очень любопытно посмотреть как мы живём на ваших данных, т.к. похоже это наша ниша.
              • 0
                В своп не уходил, за этим, разумеется, следили. Использовались, видимо, просто strings — нужна-то по сути самая базовая функциональность: SETEX и всё.

                > Tokyo * — это дисковый бэкенд

                Вы, вероятно, что-то хотели этим сказать (ввести какую-то типизацию и противопоставить что-то чему-то) — но, видимо, я не понимаю, что вы хотели сказать.

                > Вы не всё меряли, насколько я вижу

                Я вроде бы пока даже никаких цифр толком не назвал — только очень грубые относительные характеристики «на порядок быстрее / медленнее»…

                > Наличие хранимых процедур никак на скорость подсистемы индексов не влияют.

                Наличие _самих_ индексов — влияет, тогда как

                > Было бы очень любопытно посмотреть как мы живём на ваших данных, т.к. похоже это наша ниша.

                Мы меряли примерно 2-3 года назад. С тех пор в этом месте мы уже давно написали собственное специализированное решение, которое позволяет нам этот несчастный терабайт-в-сутки хранить средствами ровно 2 физических машин с очень скромной нагрузкой. Для реализации такого же на Redis в свое время понадобился бы кластер из сотен машин, на TT — из десятков.
  • 0
    Есть такой форк Redis, который раньше назывался Redisql, а теперь — Alchemy Database.
    code.google.com/p/alchemydatabase/

    Он умеет все тоже самое, что и Редис, примерно тоже самое, что и Тарантул — составные композитные индексы, и плюс еще некоторые фичи, например SELECT JOIN.

    Особенности у него такие:
    — основной язык запросов — SQL (также поддерживаются все команды Redis)
    — составные индексы на BTree
    — поддерживает JOIN таблиц
    — умеет дампить данные в MySQL
    — также встроенный LUA
    — LUA-триггеры
    — очень быстрый встроенный веб-сервер, который урлы сразу маппит на вызовы разрешенных LUA-процедур
    — оптимизации для запросов вида SELECT count(*) from table where index between 1 and 10000000
    — еще всякие интересные штуки

    Единственно что плохо — автор ждет Redis 2.6RC, чтобы выпустить стабильную версию.
    • 0
      Пожалуй, в таких доработках меру надо знать. А то выйдет «пилили-пилили… глядь — а получился MySQL 3.23 образца 2001 года» :)
      • +2
        Дайте MySQL образца 2001 года, который делает 100K запросов/сек с репликацией, и мне больше ничего не надо.
        • 0
          используй HandlerSocket и будет тебе счастье
          • 0
            HandlerSocket хорошо работает с primary key.
            А вы представляете, например, насколько небыстрыми будут апдейты на таблицах с десятками миллионов записей с включенными secondary индексами?
            • 0
              используй такую архитектуру — чтоб это было быстро.
              • 0
                Спасибо за совет, и все таки вместо шашечек вроде разворачивания шардинга на несколько машин и кэширования, я бы предпочел делать тупо «insert into» и «select where все что захочу», как это было в «MySQL образца 2001 года», только со скоростью in-memory database.
                • 0
                  я бы тоже предпочел делать тупо «insert into» и «selct where все что захочу» со скоростью in-memory
                  из текущих средств это позволяет пока Handler socket или иные in-memory БД но уже без привычного INSERT/SELECT
                  Скоро все будем изучать UnQL
    • 0
      надо сравнивать в контексте: круг задач — производительность
      • 0
        Круг задач и производительность примерно те же.
  • 0
    Использую Tarantool в некоторых «гаражных» проектах. Устраивает по всем пунктам.
    • 0
      а что за проекты, можно в приват.
  • 0
    > Во-первых, очевидно, что доступ по 32 или 64-битным ключам быстрее, чем по ключам произвольной длины.
    Насколько я понял из этой фразы, поиск идёт по двоичному дереву? Если так, то с Redis очень странно сравнивать, т.к. в нем используются хеш-таблицы, и чтение/запись ключа всегда O(1).
    • 0
      доступ идет либо по деревянным индексам, либо по хеш: как сам настроишь
      на данный момент использование хеш индексов дает больше преимуществ.
      использование деревянных индексов можно лишь через хранимки
  • 0
    у Tarantool есть один огромный минус: mysql-like репликация. Для создания реплики потребуется остановит сервер, сделать копию данных и запустить сервер. Это не проблема когда у вас 1-2 Гб данных, но с 200Гб это уже не столь приятно, не говоря о больших объемах.

    • +1
      Не надо дезинформировать публику. Останавливать сервер для создания реплики никогда не нужно было.
      Бёрете файл-снапшот, на любую дату, копируете на реплику, запускаете реплику, указываете ей ip мастера, она дотягивает изменения сама.

      Наша репликация похожа на MySQL только в одном: она асинхронная. В PostgreSQL тоже асинхронная репликация.
      • 0
        Эмм, но снапшот то тоже надо сделать. Честно, Tarantool не устанавливал, базируюсь только на документации и схема репликации чертовски схожа с Mysql. Там такая проблема есть.

        Если можете, поясните как Репликация происходит здесь, при учете того, что мне надо зафиксировать конкретную копию базы с конкретным айди операции и уже обновляться от нее. Заранее спасибо.
        • 0
          Если хранятся все WAL файлы, то snapshot можно подсунуть пустой, с помощью tarantool_box --init_storage.

          Отличие от mysql репликации в том, что у нас в replication log и write ahead log — одно и то же, то есть на диск мы пишем один раз, а не два, как mysql. в MySQL состояние репликации характеризуется парой binary log file name, offset in the binary log — у нас одним числовым значением log sequence number. Это на практике имеет очень большо ое значение — гораздо проще создавать реплики и делать восстановление если мастер упал.

          У MySQL есть statement-based репликация, и она долгое время была репликацией по умолчанию. У нас, фактически, row based replication, то есть каждая запись в wal затрагивает только один tuple, и делает это однозначно.

          Единственное общее между нами — асинхронная репликация, но мы работаем над добавлением синхронной.
  • +1
    Выглядит интересно.
    Не совсем понял из документации, поддерживаются/планируются ли какие-то то команды-примитивы для синхронизации (CAS, putIfAbsent и т.п.)?
    Планируется ли UDP интерфейс?

    Он одно поточный или многопоточный? Интересует насколько различалась производительность в в многоядерных системах в вариантах «количество потоков по числу каналов памяти + затраты на обеспечение когерентности кешей» vs «один поток».

    Компания mail.ru уже заменила все memcache на тарантул?

    А по поводу негативной реакции людей. Тут как мне кажется дело в том, что когда компания mail.ru рассказывает о тарантуле — перебарщивают с хвалебными эпитетами. Я понимаю, что проделана большая работа, и люди ей в целом скорей всего гордятся. Но просто людьми, судя по негативной реакции, это воспринимается как хвастовство.

    Например «В некотором смысле, Tarantool можно сравнить c Nginx, который разрабатывался в Rambler, и только через некоторое время обрел заслуженную славу и признание сообщества, будучи открытым проектом.» — нет — пока нельзя сравнить: «славы» и «признания сообщества» тарантул пока не обрёл. Тексты в части «Чем я могу помочь» — тоже, уверен, вызывают отторжение у читателей.

    У вас есть свои сильные стороны. Акцентируйте внимание на них. Всё будет хорошо.

    • +1
      Статью написал я и я не сотрудник mail.ru.

      Фразой про Nginx я как раз и хотел сказать, что пока славы и признания нет, и я хочу помочь этому проекту получить известность, а затем, возможно, признание и славу.

      Мне реально по человечески очень интересно, почему список «Чем я могу помочь» у Вас вызвал отторжение (лучше не надо говорить от имени неких «читателей»).

      Я делаю прямой призыв к сообществу: помогайте, кто чем может и совокупный результат достанется каждому. Повторюсь — я не имею никакого отношение к mail.ru.
      У меня есть простой интерес: если проект получится раскачать, то я лично смогу пользоваться всеми благами open source, поддержкой сообщества и с уверенностью использовать эту систему в своих проектах.
      И, поверьте, я свой вклад в этот open source проект вношу не только написанием статьи.

      • 0
        Видимо на вопросы ответа не будет…
        По поводу вашего интереса к психологии и коммуникациям — если он действительно есть — кажется разумным пройтись по топикам посвященным тарантулу и обсудить в лс эти вопросы с авторами комментариев с большим числом минусов. Из этого топика — попробуйте написать например с spmbt выше по тексту.
        • 0
          Alekzandr,
          я не очень слежу за хаброй, надо всё-таки патчи кодить и ревьювить иногда :)
          Добро пожаловать к нам в группу, groups.google.com/group/tarantool-ru
    • –1
      CAS у нас есть с помощью Lua. Как и auto_increment, и ещё с десяток других команд для которых в других NoSQL выдумали собственную команду.
      UDP, возможно, будет использоваться для реализации gossip protocol, в остальном я очень понимаю его преимуществ.

      Сервер использует один POSIX process/thread операционной системы, но использует свои лёгкие потоки для реализации внутренней многозадачности. На многоядерной системы мы просто ставим несколько экземпляров сервера, каждый из которых работает со своими данными.

      В компании mail.ru нет полиции которая бы ходила и проверяла кто чем пользуется. У нас используется и Redis, и HBase, и MySQL. Просто, моё ощущение, люди предпочитают пользоваться тем, для чего есть хорошая поддержка, и оперативно решаются проблемы, даже если это не mainstream и не супер-навороченное решение — поэтому часто выбирают Tarantool. Возможно, это специфика Mail.Ru, не мне решать.

      Наеюсь ответил на все вопросы,
      — kostja
  • 0
    Спасибо за статью, обсуждение тоже было интересным. Особенно для новичка в nosql
  • +1
    >Nginx, который разрабатывался в Rambler,
    Неправда ваша. nginx не разрабатывался в Rambler. От того, что автор писал его работая в данной компании (замечу, админом, а не программером) вовсе не значит, что это разработка данной компании.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.