yngvar_antonsson

Киберпанк 2077 уже наступил. Уровень развития технологий — это почти полное воплощение в реальность мечтаний писателей-фантастов. Умные устройства, «интеллектуальная» среда обитания, автоматизация ручного труда и управление техникой сквозь время и пространство. Полное торжество кибернетики, отложенного старта и дистанционного управления.

Эти «воспоминания о будущем» можно найти как у отечественных писателей, так и у зарубежных. Братья Стругацкие, Сергей Снегов, Кир Булычёв, Рей Брэдбери, Артур Кларк, Станислав Лем предсказали нам то, что мы называем Internet of Things, интернет вещей.

Технологии мотивируют бизнесменов, инженеров, изобретателей и мечтателей придумывать новые задачи и продукты. А новые продукты требуют соответствующих технологий. Этакий замкнутый круг!

Я расскажу о том, как компания Ready For Sky применила Tarantool, чтобы воплотить «воспоминания о будущем» у вас дома.

В этой статье я хочу сравнить Redis и Tarantool. У меня нет цели сделать громогласный вывод «Tarantool лучше!» или «Redis круче!». Я хочу понять их сходства и отличия, разобраться, для каких задач какую технологию выбрать. Потому что это очень близкие на первый взгляд вещи, и вопросы про их отличия я вижу часто.

Для этого мы посмотрим на технологии в трёх частях:

• Вначале посмотрим глазами новичка. Что такое БД в памяти? Какие задачи они решают лучше дисковых БД?
• Потом посмотрим архитектурно. Как обстоит вопрос с производительностью, надёжностью, масштабированием?
• В третьей части лезем в технические вещи поглубже. Типы данных, итераторы, индексы, транзакции, ЯП, репликация, коннекторы.

Смело переходите сразу к наиболее интересной вам части. Или даже сразу к итоговой табличке сравнения, которую я прикладываю в заключении.

Поехали!

В этот статье я хочу еще раз пройтись по особенностям работы транзакций в Tarantool, применительно к движку в памяти и дисковому движку. И главное — расскажу про новый менеджер транзакций, который появился в Tarantool версии 2.6, про его особенности, преимущества и устройство.

Когда меня спрашивают, что такое Tarantool, я отвечаю давно въевшееся в мозг: «Tarantool — persistent in-memory noSQL СУБД с хранимыми процедурами на Lua». Но всë не так просто. Вот in-memory — да, в основном в Tarantool используется memtx engine, движок в памяти, однако дисковый движок (vinyl) тоже давным-давно есть, и у него множество нюансов и особенностей. Или noSQL — да, в основном Tarantool используется как noSQL БД, но SQL он тоже умеет, точнее, какую-то его часть, а какую именно — это надо почитать.

Даже с хранимыми процедурами не совсем всё просто: то, что затевалось как способ сделать JOIN в noSQL БД, обросло кооперативно-многозадачной инфраструктурой для работы с сетью, файлами, HTTP, массой модулей и документации; сейчас Tarantool именуют сервером приложений с БД на борту. Да и хранимые процедуры бывают не только на Lua, но и на C.

Но это, в общем, скорее приятные оговорки, дескать, что поделать, Tarantool сложный и поэтому есть много деталей. А когда меня кто-нибудь спрашивал, есть ли в Tarantool’е транзакции и какой у них уровень изоляции, то я отвечал: «есть, serializable, но...» И далее следовали оговорки мелким шрифтом, которые портили радужную картину и время от времени вызывали негодование пользователей.

Больше никаких оговорок, пора рассмотреть новый менеджер транзакций под микроскопом.

Как сделать так, чтобы любой разработчик мог быстро накидать решение своей проблемы и гарантированно доставить его в прод? Деплоить приложение просто. Сделать из него полноценный продукт, чтобы десяток команд использовал его на сотне инстансов — сложнее. А если речь про мастер-систему на несколько терабайт, то уровень тревожности повышается, руки потеют, а база трещит по швам (может быть).

Я хочу поделиться способом деплоить без простоя и без отказа в обслуживании. Пайплайн на Jenkins, ноль посредников, 500 инстансов в production-среде за 60 минут. Всё это в опенсорсе. За подробностями приглашаю под кат.

Tarantool — это платформа для in-memory вычислений, где упор всегда делался на горизонтальную масштабируемость. То есть при нехватке мощности одного инстанса нужно добавить больше инстансов, а не больше ресурсов одному инстансу.

С самого начала из средств горизонтального масштабирования в Tarantool была только встроенная асинхронная репликация, которой для большинства задач хватало. При этом у нас не было синхронной репликации, заменить которую в некоторых задачах нельзя никаким внешним модулем.

Задача реализации синхронной репликации стояла перед командой разработчиков Tarantool долгие годы, к ней было совершено несколько подходов. И вот теперь в релизе 2.6 Tarantool обзавёлся синхронной репликацией и выборами лидера на базе алгоритма Raft.