Компания
1 219,24
рейтинг
4 марта 2015 в 11:35

Разработка → Tarantool 1.6 от первого лица

Привет. Это пост о новой версии Тарантула «от автора». Интернет занятно устроен: если поискать про Тарантул, то найдётся статья от 2011 года, о версии 1.3. И ещё какой-то перфоратор, кажется. На форумах-бордах вообще стоит густой туман. Тарантул «ну это как Редис, только»…

Или ещё, недавно сделал для себя открытие, на Тостере кто-то написал «София — это такое append-only хранилище по типу Тарантула». С такими постами я скоро стану фанатом сайта «сделано у нас», автомата Калашникова и Саяно-Шушенской ГЭС. Правда, мне сложно понять, почему мы восхищаемся западными инструментами, при этом представления не имеем о своих. Итак, Tarantool 1.6. В чём фишка?

На сайте мы пишем про себя, что это что-то вроде микса между Node.JS и Redis. Основная идея в том, чтобы быстро работать с большими объёмами данных в памяти, при этом делать что-то более нетривиальное чем key/value или те структуры данных, которые предоставляет Редис. Идея в том, что у вас десятки, сотни гигабайт живых данных, и у вас есть возможность делать с ними что-то действительно сложное. Антикэш, считать какие-то хитрые корреляции, держать состояние онлайн-игры, и в реалтайме высчитывать рейтинги игроков и т.п.

Можно смотреть на всё это и как на хитрый Мемкэш, мы всё это можем, но так можно и за деревьями леса не увидеть. Например, основное отличие Тарантула от Node.JS — это то, что в Тарантуле не event-ориентированная модель, а зелёные потоки. Можно писать классический последовательный код, а не обвешиваться коллбэками и футурами, и это всё не менее эффективно работает. Есть неблокирующий доступ к сокетам, файлам, внешним базам (MySQL, PostgreSQL). Главное отличие от Редиса — это то, что у нас модель данных по типу MongoDB, а не «структуры данных». Есть, например, вторичные индексы, которые обновляются автоматически, консистентно, атомарно. И ещё это всё использует меньше памяти. Но, имхо, даже не это главное. Главное — что у нас есть транзакции. Нормальный begin, commit, rollback в хранимых процедурах. А ещё, в отличие от Редис, у нас есть diskstore. Но о diskstore отдельно. 

Но и помимо «главных» различий, не главных достаточно много. Во-первых, как я уже писал, у нас, как в MongoDB, есть возможность задать или поменять схему или индексы на лету. Наше слово для таблицы или коллекции — пространство. Новые пространства можно создавать и модифицировать на работающей базе, также можно добавлять и удалять индексы. У наших индексов есть возможность итерирования — то есть можно посмотреть все данные, по возрастанию, убыванию. Вообще, итераторы в Тарантуле — основной механизм описания сложной логики и реализации произвольных структур данных, то есть того, что в Редисе уже «сделано» за вас. За свободу, естественно, приходится расплачиваться сложностью. Тарантул — единственная in-memory база с полноценным R-tree индексом, т.е. возможностью искать по точкам и полигонам. 

Во-вторых, у нас есть diskstore. То есть определённые пространства могут хранить данные, которые многократно превышают объём доступной RAM. Дискстор реализован на архитектуре подключаемых движков для хранения, по типу MySQL, только в отличие от MySQL у нас все движки поддерживают транзакции и используют общий бинлог. О том, почему это важно — читайте, например, в этой статье Олега Царёва, здесь, на Хабре. Для дискстора используется библиотека София, которую тоже написали у нас в команде.

В третьих, у нас другая репликация. Тарантул 1.6 использует асинхронный мастер-мастер, и на нём стоит остановиться подробнее. В классической мастер-слейв репликации источником изменений может выступать только один сервер. В асинхронном мастер-мастере, можно обновлять данные и на реплике. То есть, есть масштабируемость и по чтению, и по записи. НО! Есть одно очень большое НО, которое стоит иметь ввиду. Слово «асинхронная» стоит не просто так. В момент выполнения изменений, сервера не «согласовывают» изменения друг с другом, апдейты «приезжают» по сети на реплику после коммита на мастере. Поэтому, можно легко «всё сломать», обновляя одни и те же данные сразу на двух серверах. Но есть множество случаев, когда именно такой мастер-мастер нужен. Например, когда нужна высокая доступность каждой реплики, при этом большая дистанция между ними. Например, Лондон и Майами, т.е. отсутствие возможности синхронно обнолять одно и то же поле на обоих узлах. Стоит отметить, что в 1.7 в дополнение к асинхронной репликации, мы «готовим» синхронную, а также автоматическое масштабирование по данным на много узлов. И в таком «пакете опций» Тарантул станет единственной на рынке ОСС базой данных в RAM с 100% отказоустойчивостью и поддержкой транзакций. Впрочем, это 1.7, до него ещё надо дожить.

Ну вот, вкратце всё. В настоящее время 1.6 живёт в production в нескольких проектах Mail.Ru, в Сбербанке :), а ещё всю зиму мы выпиливали баги, которые нашли в своём деплое в Авито. Надеюсь, они захотят подробнее рассказать, для чего у них используется Тарантул, и почему они не выбрали что-то ещё, несмотря на все баги бета-версии. А будете ли вы использовать Тарантул в своём проекте, решайте сами. Только не по постам на бордах, а по документации. Ну или вот по этому отчёту. Если у вас остались вопросы — постараюсь ответить на них в комментариях.
Автор: @kostja

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

  • +7
    а ещё tarantool — это application server для lua, у которого есть такой бонус, как всё описанное выше.
    для тех кто читает статьи прошлых лет этот момент скорее всего является важным.

    вот если бы прежде об этом было заявлено прямо и громко, то не было бы возможности сравнивать tarantool и redis — они совершенно разные. Для многих задач это отличие является решающим.
    • 0
      redis также поддерживает lua. отличие?
      • +4
        lua в redis — это как хранимые процедуры, но очень кривые
        а в tarantool ты можешь полноценный сервер писать с http, msgpack, фиберами, логами, тестами, отладкой.

        В одном из проектов, если бы я лучше разобрался прежде, можно было бы всё запилить на tarantool. На redis так же запилить всё не получится.
      • +1
        В Redis используется lua, в tarantool — luajit. Это уже очень большая разница.
        Также, в Redis вызов lua блокирует всё, в tarantool, как я понял в свое время автора, — нет.
  • +2
    Вот всё бы хорошо, но сравнить с редисом только по части in-memory NoSQL не честно. У него вон сколько втроенных типов данных, которые заметно упрощают написание алгоритмов. Имея только get/set в Тарантуле сильно ограничивает разработчиков в вариантах применения тарантула. Плюс транзакции как реализованы? Наверное не MVCC?
    Ну и что больше всего расстроило, так это что вторичных индексов нет если используем diskstore. А так можно было бы как полноценную монгу использовать.
    • +9
      Вы просто не умеете (пока) нас готовить. Мы можем все структуры, которые может редис (мм, разве что недавний hyperloglog нетривиальный получается, но это специфичная штука), как — об этом писали ещё в статье в 2011 г. Календарёва, здесь, на сайте. Транзакции реализованы по-разному — один алгоритм в in-memory, другой в diskstore. В diskstore именно MVCC. Ну да, в diskstore вторичных инексов пока нет, но это пока. У нас там сейчас немного другой фокус — эффективная работа на петабайтных объёмах :)
      • 0
        А почему не встроить эти структуры данных в движок, все-таки. Клиентов же много.
        • +6
          Если речь идёт о том, чтобы написать на Lua соответствующие функции, что-то вроде модуля redis-compat, то главный вопрос *зачем*? Чтобы кто-то перестал использовать Редис и начал использовать Тарантул? *Зачем*? Редис — отличный инструмент, используйте его если он Вас устраивает. Но вот если Вам его перестало хватать, можете посмотреть в нашу сторону, тогда Вам этот уровень не нужен. На самом деле всё можно, можно и это написать, но у нас есть задачи поважнее (фишки, которые нужны нашим пользователям), и команда не такая большая чтобы расбрасываться на имитацию.
        • 0
          это скорее надо делать в виде некоего стандартного набора функций на LUA которые можно дергать из клиента…
      • 0
        Кстати, можете объяснить, почему redis делали таким простым и предсказуемым и вроде бы даже внедряли то, что вы считаете своими features (diskstore у redis был, но они отказались от него из-за просадок в производительности). Проблемы совместимости? Почему у них именно так?
        По идее — у них и клиентов в разы больше и может они столкнулись с какими-то проблемами, которые заставили их идти строго по тому пути, по какому они сейчас и идут?
        Ведь различные форки redis без блокировок и.т.п. почему-то не пользуются популярностью, хотя и обещают очень многое.

  • 0
    Авито, надеюсь, и правда сами расскажут о своем выборе и профитах.

    Но еще более интересно о проектах Сбербанка на Тарантуле, можете рассказать?
    • +3
      Я знаю, что это проект по определению карточного фрода, рассказать в деталях, я, конечно, не могу — лучше если это сделают сами ребята из Сбербанка.
      • 0
        А попросите их рассказать на митапе?
    • +3
      Avito оперативно организовали meetup чтобы рассказать об их использовании Tarantool :-):

      www.meetup.com/Tarantool/events/220924229/
  • +10
    Действительно, интернет устроен забавно: какое-то огромное кол-во материалов по разным базам, но исключительно редко попадаются объясняющие как в сущности устроена и работает база. Без этой информации «быстро», «эффективно» и т. д. — вилами по воде.

    Не обижайтесь, но эта статья — тоже туман. «Тарантул «ну это как Редис, только более лучше тут, тут и тут.»» Почему лучше, почему быстрее?

    Я отнюдь не выступаю апологетом Редиса, Мемкеша и других «проверенных решений» — для меня стало определенным сюрпризом, насколько они на самом деле неэффективно устроены в некоторых принципиальных вопросах.

    Хочу в ближайшем будущем разобраться с Тарантулом. (Без иронии) я почти не сомневаюсь, что у вас все круто, и потом я буду бегать и рассказывать всем, какой классный Тарантул и спрашивать, почему про него никто не знает. Но пока я не знаю, почему именно.
    • +2
      Рома, плюсую!

      Костя, больше мяса и хардкора!
    • +1
      Также присоединяюсь! Расскажите про Тарантул с примерами.
  • +3
    В разное время я рассказывал про какие-то детали внутреннего устройства — движка в памяти, движка на диске, репликации, файберов. Вопрос в том, в чём вопрос :) У нас далеко не всё круто, есть разные косяки в разных фичах.
    • 0
      А можно ссылочки на эти рассказы? Или это в порядке внутренних семинаров? Или уже сильно устарело?
  • 0
    Хорошая штука, в мэйле многие студии используют tarantool в своих игровых продуктах.
  • 0
    Что интересно, изначально проект назывался tarantul, в честь большого паука.
    А название tarantool было использовано в качестве шутки в общении с автором.
    И оно внезапно прижилось :-)

  • 0
    Второй абзац, мне кажется, лишний. В мире ПО не принято делить на «наше» и «ихнее», потому что везде интернационал.
    • +1
      Иногда принято. Например, в российском продукте ожидаешь увидеть российскую документацию;) Этим в свое время очень подкупил nginx (а потом уже всем остальным).
      • +4
        А вот в MySQL, например, документации на шведском или финском никогда не было. У нас правда, всего несколько человек в штате, постарайтесь пожалуйста осознать это :)
        • 0
          У nginx вроде был вообще один в то время. Но в целом, я вас понимаю.
          • 0
            И по документации это всегда было видно.
            • 0
              У меня проблем с документацией к nginx никогда небыло. Может, правда, это связано с тем, что я достаточно давно с ним работаю и многие годы в доках только обновления высматривал.
  • +1
    Тарантул оставляет впечатление, как типичное корпоративное решение, обросшее кучей фишек в которых нуждался то один заказчик, то другой. Это не плохо, просто это «немного из другой оперы», иное «позиционирование». Redis позиционируется как «автомат калашникова в мире баз данных», четыре структуры данных: строка, хэш, цепь, skip-list — вот и всё.
    • +4
      Это троллинг, и он не по существу. Редис *начинал* как простая база данных, с несколькими структурами. В настоящий момент это под 200 команд, и для каждой новой структуры данных понадобится добавлять новую. Мы изначально пошли по парадигме не структур данных, а модели данных на основе таплов и пространств, что позволяет нам иметь потенциально больше возможностей не расширяя синтаксис. Наш синтаксис — обычный Lua, т.е. это просто методы, они не засоряют пространство имён, не добавляют новых ключевых слов и т.п.
      Мы добавляем фичи для пользователей, но говорить что мы «обросли фишками» — это чушь, мы ещё не имеем и половины тех фич что должны иметь. Назовите одну «левую» фичу которую нужно удалять, и мы сможем продолжить разговор. Вот Редису как раз пришлось удалять неудавшийся дискстор — потому что сделали они его изначально неправильно. Я реально не против Редиса, классное решение, отлично развивается, но Вы просто не знаете что такое Тарантул, поэтому лучше не пишите всякую ерунду.
      • +4
        Было 4 структуры и они развились в 200 комманд? Чувствуется что вы писали в 3:05)

        Я ничего плохого о Тарантуле не говорю, и не троллю уж точно. Наоборот, я поддерживаю ваше начинание со всем уважением. Скорее пытаюсь со своей колокольни увидеть какие-то вещи, и вам помочь их увидеть. Ваше дело меня игнорировать или выслушать, — свобода. Вы даже не обязаны читать мой коммент, тратить время на постороннего человека. И я, вообще, говорю не о технической стороне, уверен, вы достаточно компетентны, чтобы всё сделать в лучшем виде. То есть проблемма не в том, что «я просто не знаю, что такое Тарантул», а о том, что в социальном, маркетинговом смысле, вы сами не знаете что это такое. Отсюда ваши затруднения с «туманом» в головах. Можно чисто гуманитарно осмыслить ваше уникальное положение на «рынке», если можно так назвать сообщество пользователей открытого кода. И обменяться нашим видением. Особенность нас русских программистов, нежелание или неумение вести диалог со своими пользователями. У пользователей аналогичная проблема, что сказать, как заявить разрабу о себе и своём существовании и взглядах они не знают. Мы в вакууме общения. Может быть, поэтому, вам автоматически кажется, что я «пишу ерунду». Просто мне уже тоже обидно это слышать, ведь для меня вы «селебрити», — один из авторов Тарантула, и вы мне отвечаете, что по идее мне как юзеру должно быть праздник, по ваша манера ответить не публичная, скорее рефлекторная, это огорчает меня как «фаната». Такая манера общения для технаря — норма, но я об этом же постоянно и говорю, что программист в наше время уже превращается по сути профессии в публичную фигуру.

        Есть такая идеальная ситуация, что, вот разработчик хочет внести изменение в свой проект, и оказывается, что большинство пользователей ожидает именно этого изменения. Этакая синхронизация. Это идеал открытого кода. С Редисом несомненно такая ситуация. Это получается засчёт идеально точного позиционирования, и прозрачности основной идеи. Например, есть функции INTERSECT для сетов и списков, но нет такой же функции для скип-листа (zset-а), и всем понятно, что рано или поздно её надо сделать. Всё предсказуемо. Может предсказуемость, это ключевое слово успешного «маркетинга» для таких проектов. Наоборот, непрозрачность в принятии решений — это фишка. Не мешайте нам работать, мы знаем, что делаем. Я, кстати, не пытаюсь идеализировать Редис.

        Просто можно найти слова, чтобы раскрыть своё внутреннее, интуитивное видение сути проекта. Донести до людей, чтобы они могли полюбить продукт не только за то каким он получился, а в первую очередь за то, каким он мечтался, за внутренние представления разработчиков.

        Я вас не пытаюсь критиковать, не пытаюсь «открыть глаза», просто пытаюсь выйти на дискуссию. Мне тема интересна, вы же сами понимаете, ваш проект уникален для нашего общества. Точнее для того киселя, которое при достаточном общении может ещё стать обществом. То что вы пишете о Тарантуле, это наверняка всё правда и правильно. Но этого мало! Вот в чём тонкость то! Мало написать «правду», надо найти доходчивые, верно резонирующие в душе слушателя, публики слова, которые бы не просто формально соответствовали, но передавали ваше интуитивное ощущение, видение от системы у потенциального пользователя. Я понимаю, что вам, скорее всего «не до этого». И это потому, что ваш основной драйвер не анонимное сообщество, а конкретные заказчики и начальство. Это усложняет картинку, но вопрос выхода на публику остаётся. Просто нам же очевидно, что процесс создания и развития Тарантула, это не чистое идеальное визионерство, а вы, возможно несознательно, пытаетесь представить это в таком виде. Ясно же, что были «указания от начальства», заказчики предъявляли «дополнительные требования», шли какие-то дискуссии, что-то добавлялось и убиралось по ходу эксплуатации, «год выпиливали глюки». Почему бы не позиционироваться с этой стороны? Вот наша база данных, она была создана для гигантских серверов «Однокласников» и «Сбербанка», так-то и так-то. Сразу бы сложилась более конгруэнтная картинка, вызывающая большее доверие и ощущение предсказуемости того, что будет с проектом дальше. Ведь сейчас, что можно подумать о будущем проекта? «Подумывали использовать, но совершенно не ясно куда они будут развиваться, им позвонит начальство и повернёт весь процесс». Это ещё не тупик, если сообщество видит, что о нём думают и видят картинку как она есть, что на самом деле драйвер разработки.

        В общем не ругайтесь, я просто пытаюсь говорить о гуманитарном аспекте. Я от вас ничего не жду и не требую, просто мне интересен сам разговор на эту тему.

        • +2
          Вы всё правильно пишете про позиционирование, как известно, автомобиль — это безлошадная повозка. Но меня задела фактическая сторона вопроса. В Редис не 4 структуры данных, а 6 или 7, цитирую с главной: «Redis is… a data structure server since keys can contain strings, hashes, lists, sets, sorted sets, bitmaps and hyperloglogs». И в Тарантуле нет фич которые надо удалять — мы всё «устаревшее» удалили между 1.5 и 1.6, чем вызвали плач Ярославны от нашего существующего community.
        • +6
          Ещё пару слов про Редис. На мой взгляд, Редис — отличный пример работы сообщества, выбирающего простоту.

          Но с точки зрения архитектуры, например, на мой взгляд, преимущества Редиса являются его же и недостатками. Изобретение своего «языка» данных уже сделало целый ряд задач невозможным — например, нормальную интеграцию с хранимыми процедурами.
          Отсутствие каталога метаданных не позволяет именовать объекты
          СУБД, управлять ими. Отсутствие концепции типа данных создаст проблемы при попытке реализовать поддержку таких типов как точки, полигоны, деньги.
          Отсутствие абастракции модели хранения от модели представления приводит к избыточности хранения, если нужны вторичные индексы.
          Этот список можно продолжать.

          В целом, эти проблемы можно было бы и не «изобретать — это 70е годы 20го века, иерархическая модель данных и т.п. уже показали ущербность таких подходов, но не уверен, что Сальваторе что-то знал про проблематику когда создавал своё решение.
          Но их „понадобилось“ изобрести чтобы достаточно удачно спозиционироваться в растущем сообществе молодых Web-разработчиков. Чтобы „было просто, проще некуда“.

          Параллельно Редис уже в 2004 г. был продукт NDB Clsuter — in-memory database, с открытым исходным кодом, по фичам на порядок превосходящая
          Редис. Community сформировалась тем не менее вокруг Редиса. Можно долго рассуждать про позиционирование, но имхо всё проще — чтобы сообщество сформировалась, его нужно формировать. Пусть даже меня не понимают большинство юзеров, но если я не буду оставлять своих
          попыток объяснить, что я делаю, мы найдём общий язык. Тем не менее, я порой предпочитаю более технически сложное решение, но более „долгоживущее“ с точки зрения архитектуры, чем простоту артикуляции наших фич для community.
        • 0
          Вы так собственно и не написали что конкретно лишнее и прочее. Один «аспект» гуманитарный.
  • +3
    Костя, не обращай внимания. Просто они завидуют (-:
    Пиши чаще, плииииз
  • 0
    движки… используют общий бинлог.… это важно — читайте, например, в этой статье Олега Царёва, здесь, на Хабре.

    можно упомянуть развитие истории «бинлога» базы данных из статьи Олега
    peter.eisentraut.org/blog/2015/03/03/the-history-of-replication-in-postgresql/

  • 0
    Вопрос, о синхронной репликации. Вы не описали, как планируете её реализовать. Не планируете использовать что-нибудь из семейства протоколов Паксос?
    • +1
      Про Paxos для Tarantool говорилось еще в 2012.
      • 0
        Спасибо.

        А когда планируете, что версия 1.7 будет опубликована/готова?? Есть уже предположительные сроки?
        • +1
          Это не ко мне вопрос, я лишь интересуюсь и стараюсь следить за развитием проекта.
        • +1
          V17 ветка на gh, paxos на ветке bsync. В мастер попадёт как только выпилим все косяки.
          • 0
            Большое спасибо за информацию!
            Можно будет тогда c 1.7 версии и нам connector написать.

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

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