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, в Сбербанке:), а ещё всю зиму мы выпиливали баги, которые нашли в своём деплое в Авито. Надеюсь, они захотят подробнее рассказать, для чего у них используется Тарантул, и почему они не выбрали что-то ещё, несмотря на все баги бета-версии. А будете ли вы использовать Тарантул в своём проекте, решайте сами. Только не по постам на бордах, а по документации. Ну или вот по этому отчёту. Если у вас остались вопросы — постараюсь ответить на них в комментариях.
