Фестиваль РИТ++ 2016 завершён. Изучайте презентации, смотрите фотографии и ждите видео :)
Профессиональная конференция для серверных веб-разработчиков

Основные кейсы использования in-memory СУБД на примере Тарантула и проектов Mail.Ru GroupЭлементы архитектуры

Доклад принят в программу конференции
Денис Аникин

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

Основные кейсы использования Тарантула:

1. Когда нужна OLTP-система, позволяющая обрабатывать транзакции в режиме почти реального времени (с милисекундными задержками) и/или с огромной пропускной способностью (сотни тысяч запросов в секунду). Примеры — система сессий, система антибрутфорса, система противодействия атакам, система очередей и пуш-уведомлений, роутинг запросов между серверами.

2. Когда нужна реал-тайм OLAP-система. Т.е. когда нужно супероперативно принимать решения (желательно в реал-тайме), собирая и анализируя информацию по многим источникам. Примеры: фича "уберись в ящике" в Почте@Mail.Ru, почтовый общий и персональный антиспам, система показа рекламы, любые системы, касающиеся классификации и кластеризации данных, которые должны работать в онлайне.

3. Когда текущая СУБД стоит слишком дорого по серверам или лицензиям, и есть желание заменить ее на нечто, что будет в десятки, если не сотню раз более экономное (за счет отсутствия лицензии и за счет радикального снижения количества железа). Можно эту СУБД заменить на Тарантул.

4. Когда текущая СУБД обложена большим зоопаркам NoSQL решений и кэшей с целью повысить ее производительность, но при этом хочется еще больше производительности и/или хочется решить проблему несогласованности данных. Можно эту СУБД и все обвязки вокруг нее заменить на Тарантул.

5. Когда хочется повысить надежность и/или скорость работы текущего кэширующего решения. Можно это решение заменить на Тарантул.

6. Когда текущая СУБД и/или кэш не позволяют в полном объеме реализовать необходимую логику внутри и использовать их как application server. Можно эту СУБД и/или кэш заменить на Тарантул или можно новые фичи разрабатывать Тарантул, не теряя старых решений (Тарантул умеет интегрироваться и реплицироваться в обе стороны с любыми решениями за счет полноценного алгоритмического языка внутри с мощным сетевым SDK).

Решение о разработке своей собственной DBMS (системы управления базами данных) общего назначения обычно зреет долго. Прежде чем броситься в эту нелегкую пучину, вы сначала ищете другие способы решения задач существующими инструментами, в том числе создавая поверх них или интегрируя их различные решения.

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

Именно так и появился Тарантул — одна из самых быстрых баз данных в мире, которая широко применяется в Mail.Ru Group и за её пределами.

Поскольку Тарантул с самого начала разрабатывался отдельной командой в открытых исходных кодах и с прицелом на общее использование, в результате мы получили отличный продукт — DBMS общего назначения с уникальным набором фич.

Денис расскажет о типичных проблемах нагруженных проектов, стандартных способах их решения и причинах, почему они в какой-то момент перестают работать, и как в таких случаях помогает Тарантул.

Другие доклады секции Элементы архитектуры