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

Editor's Notes

• #3: Я много рассказывал про Тарантул на разных конференциях. При этом в основном я касался в основном такого аспекта как скорость работы, а именно таких параметров как времени обработки запросов и максимальную пропускную способность. Это самая быстрая СУБД из известных мне. Но скорость – это не единственное достоинство Тарантула и не единственная фича, из-за которой ему отдают предпочтение. В этом выступлении я постарался более полно обрисовать различные кейсы использования Тарантула, когда он может быть вам полезен.
• #4: Я много рассказывал про Тарантул на разных конференциях. При этом в основном я касался в основном такого аспекта как скорость работы, а именно таких параметров как времени обработки запросов и максимальную пропускную способность. Это самая быстрая СУБД из известных мне. Но скорость – это не единственное достоинство Тарантула и не единственная фича, из-за которой ему отдают предпочтение. В этом выступлении я постарался более полно обрисовать различные кейсы использования Тарантула, когда он может быть вам полезен.
• #5: Я много рассказывал про Тарантул на разных конференциях. При этом в основном я касался в основном такого аспекта как скорость работы, а именно таких параметров как времени обработки запросов и максимальную пропускную способность. Это самая быстрая СУБД из известных мне. Но скорость – это не единственное достоинство Тарантула и не единственная фича, из-за которой ему отдают предпочтение. В этом выступлении я постарался более полно обрисовать различные кейсы использования Тарантула, когда он может быть вам полезен.
• #6: Я много рассказывал про Тарантул на разных конференциях. При этом в основном я касался в основном такого аспекта как скорость работы, а именно таких параметров как времени обработки запросов и максимальную пропускную способность. Это самая быстрая СУБД из известных мне. Но скорость – это не единственное достоинство Тарантула и не единственная фича, из-за которой ему отдают предпочтение. В этом выступлении я постарался более полно обрисовать различные кейсы использования Тарантула, когда он может быть вам полезен.
• #7: Я много рассказывал про Тарантул на разных конференциях. При этом в основном я касался в основном такого аспекта как скорость работы, а именно таких параметров как времени обработки запросов и максимальную пропускную способность. Это самая быстрая СУБД из известных мне. Но скорость – это не единственное достоинство Тарантула и не единственная фича, из-за которой ему отдают предпочтение. В этом выступлении я постарался более полно обрисовать различные кейсы использования Тарантула, когда он может быть вам полезен.
• #8: Я сгруппировал юз кейсы в 9 групп. Я где-то слышал прекрасный на мой взгляд способ выступления на конференциях направленный на максимизацию понимания со стороны аудитории – любую мысль надо повторить 3 раза – сначала предварительно говорите то, что сейчас скажите, потом говорите это, потом говорите то, что только что сказали. Следуя это практике, я перечисляю тут все эти группы.
• #9: Когда нужна OLTP-система, позволяющая обрабатывать транзакции в режиме почти реального времени (с милисекундными задержками) и/или с огромной пропускной способностью (сотни тысяч запросов в секунду). Примеры — система сессий, система антибрутфорса, система противодействия атакам, система очередей и пуш-уведомлений, роутинг запросов между серверами.
• #14: Когда нужна реал-тайм OLAP-система. Т.е. когда нужно супероперативно принимать решения (желательно в реал-тайме), собирая и анализируя информацию по многим источникам. Примеры: фича "уберись в ящике" в Почте@Mail.Ru, почтовый общий и персональный антиспам, система показа рекламы, любые системы, касающиеся классификации и кластеризации данных, которые должны работать в онлайне.
• #20: Когда текущая СУБД стоит слишком дорого по серверам или лицензиям, и есть желание заменить ее на нечто, что будет в десятки, если не сотню раз более экономное (за счет отсутствия лицензии и за счет радикального снижения количества железа). Можно эту СУБД заменить на Тарантул.
• #24: Когда текущая СУБД обложена большим зоопаркам NoSQL решений и кэшей с целью повысить ее производительность, но при этом хочется еще больше производительности и/или хочется решить проблему несогласованности данных. Можно эту СУБД и все обвязки вокруг нее заменить на Тарантул.
• #28: Когда хочется повысить надежность и/или скорость работы текущего кэширующего решения. Можно это решение заменить на Тарантул.
• #31: Когда текущая СУБД и/или кэш не позволяют в полном объеме реализовать необходимую логику внутри и использовать их как application server. Можно эту СУБД и/или кэш заменить на Тарантул или можно новые фичи разрабатывать Тарантул, не теряя старых решений (Тарантул умеет интегрироваться и реплицироваться в обе стороны с любыми решениями за счет полноценного алгоритмического языка внутри с мощным сетевым SDK).
• #36: Когда хочется повысить скорость разработки новых фич, особенно в случае микросервисов, чтобы было минимальное количество компонент и серверов, максимально быстро деливирить в продакшн и тратить минимальное время на борьбу с высокой нагрузкой.
• #45: Когда хочется упростить эксплуатацию новых фич.
• #51: IoT platform
• #52: IoT platform
• #53: IoT platform
• #54: Резюмируя сегодняшнее выступление, я хочу сказать, что Тарантул можно рассматривать как платофрму-конструктор, позволяющих собрать высокопроизводительное решение для конкретной задачи. Это не серебрянная пуля в целом, но это мощный инструмент для хайлоуда, для диджитализации, для аналитики, для всего что в рилтайме.
• #55: Если у вас есть любые вопросы, то не стесняйтесь задавать на наш сапорт, в нашу группу в фейсбуке или мне лично на имейл. Ну и конечно вы можете задать любые вопросы здесь и сейчас, я готов ответить на все 