Mail.Ru Group запустили новое направление бизнеса – системы хранения данных. Заказчикам будут предоставляться услуги на базе opensource-СУБД Tarantool. Это собственная разработка компании. Об этом Roem.ru рассказали в Mail.ru Group.
Разработка Tarantool началась с нуля около 8 лет назад и до сих пор продолжается. «Tarantool используется в большинстве проектов Mail.Ru Group, таких как Почта, Облако Mail.Ru, myTarget и многих других. Например, он обеспечивает хранение пользовательских сессий и профилей, работу таких систем, как портальная аутентификация, антибрутфорс, антифишинг и антиспам, где он доказал свою способность эффективно работать с большими объемами данных и под высокими нагрузками», – комментирует Владимир Габриелян, вице-президент и технический директор Mail.Ru Group.
«Тарантул делает разработку проще и быстрее. Разработчику не надо создавать сложную гетерогенную систему из SQL СУБД + NoSQL СУБД + Кэш. Не надо создавать огромные кластера и платить миллионы за железо. Достаточно одного Tarantool», – комментирует Денис Аникин, технический директор Почты Mail.Ru. Один сервер с Tarantool способен заменить от тридцати и более серверов с классической СУБД, уверяют в компании.
Tarantool полностью выложен в открытый доступ под лицензией BSD. Компания планирует зарабатывать на платной технической поддержке и кастомизации системы. Первыми клиентами компании уже стали сервис знакомств Badoo, классифайд Avito, Qiwi и безопасники Wallarm. Стоимость сервиса и прогнозируемую выручку в компании не раскрывают.
Добавить 17 комментариев
Используем Tarantool уже больше года. Не как основную СУБД, конечно, а для специфических кейсов, наряду с Redis, MongoDB и много чем ещё. Наш директор по разработке говорит, что «Тарантул очень клёвый».
Пользуясь случаем, приглашаю на работу разработчиков, которые хотят всё это пощупать — https://hh.ru/vacancy/14983652
Молодцы сразу по нескольких причинам.
1. Неплохой, хоть и специфичный инструмент
2. BSD
3. Опыт работы с монетизацией через поддержку + кастомизация.
Молодцы.
Больше велосипедов всяких и разных …
>>Наш директор по разработке говорит, что «Тарантул очень клёвый».
Ну прийдет завтра другой директор, скажет что «Oracle очень клевый» ?
Будут переводить на Oracle не иначе.
P.S.: Интересно как они используют специфичный инструмент созданный чисто для Почты на сайте объявлений ? Не иначе почтовым ящиком называется юбер, письмом — объявление ?
:)
Вопрос не в клевости, а в ТТХ, а конкретней — в стоимости разработки новых фич (именно on top of конкретной DBMS), TOC (total cost of ownership), latency, throughput, надежности, удобстве эксплуатации. Все это суммарно повлияло в пользу Tarantool. При этом я готов был (и сейчас готов и всегда готов) выбрать любую другую DBMS для разработки фич в Почте и Облаке. Tarantool у нас внутри победил в жесткой конкуренции с Redis, Couchbase и прочими DBMS в т.ч. с различными вариантами proprietary DBMS, которые мы периодически разрабатываем под конкретные задачи, когда не находим вариантов лучше.
И где же можно прочитать разбор ТТХ? Пока что в вашем сообщении опять только про клевость без конкретики. На сайте как и полгода назад — пусто, кейсов нет.
Над сайтом работаем. Скоро все будет. Пока же про кейсы и разбор ТТХ можно почитать тут:
Юзкейсы:
https://habrahabr.ru/company/mailru/blog/279999/
https://habrahabr.ru/company/mailru/blog/273695/
https://habrahabr.ru/company/mailru/blog/272669/
https://habrahabr.ru/company/mailru/blog/254727/
https://habrahabr.ru/post/254533/
https://habrahabr.ru/company/mailru/blog/252065/
Бенчи:
http://highscalability.com/blog/2015/12/30/how-to-choose-an-in-memory-nosql-solution-performance-measur.html
1. Какие планы насчет развития коммьюнити и пула ресурсов? Этим же Редис и силен.
2. Будет ли generic key-value store роудмэп? Не строго заточенный под ту четкую область применения, в которой Tarantool живет в Мейл.ру?
PS Костя- молодец!
1. Огромные. Развиваем. Пока только в начале пути.
2. Роудмэп есть — кластерное решение, синхронная репликация, облачное решение, поддержка протоколов SQL/MongoDB, репликация из/в других(е) СУБД, дальнейшее уменьшение memory footprint, дальнейшая оптимизация, дальнейшее развитие дискового движка. И это только начало :-)
Костя — просто супер! Присоединяюсь к похвале! :)
Почему нет версии сайта про «Тарантул» на русском языке? Опять только английский. Это чтобы американцы не обиделись и недайбоже не подумали, что разработка-то российская. Не надоело еще жопу вылизывать американцам?
Особенно это комично смотрится на фоне вашего же поста:
«Правда, мне сложно понять, почему мы восхищаемся западными инструментами, при этом представления не имеем о своих. »
https://habrahabr.ru/company/mailru/blog/252065/
Откуда представление, если сайт заточен под ламериканцев и ваш же поиск по запросу «тарантул» выдает… пауков.
А, наверное здесь тоже надо на английском вводить, русские побоку.
Вениамин, проект изначально стартовал как международный open-source проект. И всегда таковым был. Английский язык пока считается международным. При этом вплоть до недавнего времени, мы не пларировали особо продвигать Tarantool. Мы просто его использовали внутри и наслаждались его шустрой и надежной работой. Ну и, разумеется, помогали всем снаружи, кто узнавал про Tarantool и хотел его использовать.
Помогали мы (использую слово «помогали», потому что так я интерпретирую ваш выразительный оборот), так вот, помогали мы всем вне зависимости от их страны проживания и других признаков.
По мере того как мы начали продвигать Tarantool за пределами Mail.Ru мы пришли к пониманию, что надо делать версию сайта на русском языке. Версия сайта на русском языке в процессе разработки. В любом случае, спасибо вам огромное, что обратили внимание на этот недостаток нашего сайта! :)
> Не надоело еще жопу вылизывать американцам?
Вообще об этом должен позаботиться законодатель.
Зачем нам все эти for, while, class? Незачем стесняться своего языка.
А китайцы, индусы и прочий мир пусть изучают русский в школах для полноценного использования наших технологий.
Что я так и не понял — Tarantul хранит данные в ОЗУ и сбрасывает переодически копии данных на диск ? Т е «умного индекса» которых хранил в памяти только те данные которые первых раз запрашивается нет ?
И соотв если памяти на сервере нет то и записи в БД нет ?
Вот просто например если взять http://ssdb.io/ как тоже заявленная альтернатива redis ( на основе leveldb от Google ) — там если я правильно понял задача стоит обратная: использовать как можно меньше памяти — т е данные наоборот рекомендуют хранить на диске
У Tarantool есть два движка — in-memory и on-disk. В обоих случаях КАЖДАЯ транзакция записывается на диск (хотя для in-memory движка при желании, это можно отключить к конфиге).
Отличие этих двух движков в том, что в первом движке чтение происходит гарантированное из памяти (максимальный размер памяти конфигурится заранее, и если операция, изменяющая состояние БД, требует памяти, которой нет, то она отклоняется), а у второго движка — может и из памяти, может и с диска (и в этом случае размер БД ограничен не памятью, а диском).
В любом случае, был бы вам признателен, если бы вы рассказали ваш конкретный кейс — а я бы уже ответил какой из движков Tarantool для его решения стоит применять, и, вообще, стоит ли Tarantool в данном случае применять.
>>бы вам признателен, если бы вы рассказали ваш конкретный кейс —
Есть Redis, в него собираются данные сессии, после обрабатываются и удаляются. Все это отлично работает, но есть специфика: иногда кол-во сессий увеличивается резко в несколько раз. Соотв. сессии начинают скапливаться в Redis и кончается память. Если использовать для этой цели ssdb — то вопрос с памятью снимается, но тут упираемся в скорость диска. В связи с этим вопрос: может ли Tarantool в штатном режиме работать с памятью — в случае добора до лимитов памяти — писать поступающие данные уже на диск, откуда их забирать в память по мере освобождения памяти ?
У вас отличный кейс, спасибо! Он мне нравится! :)
Тут весь вопрос в том, каким образом вы хотите вытеснять данные из памяти на диск. Например, если вы будете делать это по общепринятому принципу LRU, то в момент всплеска все новые сессии попадут в память, старые сессии из нее вытеснятся и пользователи получат в лучшем случае плохую латенси, а в худшем случае полную недоступность системы, если все упрется в потолок IOPS’ов диска из-за большого количества параллельных чтений сессий с диска.
Если делать по тому принципу, по которому вы написали, т.е. все новое писать на диск, то и читаться эти сессии будут с диска, а память, поскольку уже забита старыми сессиями, то, по сути, все новые пришедшие пользователи будут работать с диском. И опять же будет проблема, начиная с некомфортности для пользователей, заканчивая упиранием всей системы в диск.
Вы можете поиграться с помощью Tarantool с различными стратегиями переноса между памятью и диском с помощью Lua (Lua — это язык, на котором можно писать хранимые процедуры внутри Tarantool). Т.е. пишете скрипт, который при превышении количеством сессий определенного значения начинает все новые сессии писать в отдельную таблицу в дисковом движке Tarantool.
Кстати, Tarantool позволяет использовать внутри него любые другие СУБД (потому что он, по сути дела, является высокопроизводительным application сервером). Т.е. я к тому, что если вас дисковый движок Tarantool по каким-то причинам не устроит, то вы можете использовать любой другой движок прямо изнутри Tarantool. Например, вы можете писать в/читать из MySQL прямо из хранимкм внутри Tarantool или даже вызывать внешние системы через HTTP REST API, причем любые тормоза внешних систем никак не сказываются на работе Tarantool — у него все внутри асинхронно, луашные скрипты работают в отдельных файберах. Конечно, ровно тоже самое можно делать и снаружи Tarantool (или снаружи Redis), но это может привести к рассогласованию и дублированию данных. Этим как раз Tarantool и хорош, что у него можно взаимодействовать со всеми внешними источниками изнутри, используя его как умный кэш.
Кроме всего прочего, мы работаем над автоматическим решением проблемы перемещения данных из in-memory двжика в on-disk движок и обратно, пытаемся найти оптимальную в среднем стратегию, а также думаем над различными настройками этих стратегий.
Ну и еще один момент. У Tarantool очень оптимальный memory footprint. Он в этом плане опережает Redis в среднем на десятки процентов, но все зависит от вашего кейса. Кроме того, Tarantool гораздо меньше потребляет дополнительной памяти во время snapshotting’а чем Redis. Все потому, что Redis делает это через fork, и далее при изменениях во время откладывания snapshot Linux начинает копировать все измененные страницы целиком. Tarantool же делает по сути, такой же механизм copy-on-write, но внутри, и копирует только измененные элементы данных. Это я к тому, что, возможно, у Tarantool влезет в память то, что у Redis не влезло