Как мы выбирали между Elastic и Tarantool, а сделали свою (самую быструю) inmemory БД. С Join и полнотекстовым поиском
Источник: https://habrahabr.ru/post/346884/
Всем привет,
Я директор по разработке компании Рестрим.
Мы разрабатываем и сопровождаем платформу IPTV/OTT телевидения. У платформы около 10 миллионов пользователей. Платформа первого поколения проектировалась в 2010 году, и была ориентирована в первую очередь на IPTV приставки.
С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.
Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.
У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать несколько сотней тысяч RPS на всю систему.
Это означает, что запросы от клиентов и близко не стоит подпускать к SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш.
Посмотрели на существующие решения — погоняли прототипы. Данных, по современным меркам у нас немного, но параметры фильтрации (читай бизнес-логика) — сложные, и главное персонализированные — зависящие от сессии пользователя, т.е. использовать параметры запроса как ключ кэширования в K-V кэше будет очень накладно, тем более пейджинг и богатый набор сортировок никто не отменял. По сути, под каждый запрос от пользователя формируется полностью уникальный набор отфильтрованных записей.