How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEE является крупнейшим медиа- и развлекательным бизнесом Индии, охватывающим вещание телевидения, фильмы, потоковые медиа и музыку. ZEE5 является их ведущим сервисом OTT streaming, доступным в более чем 190 странах с 150 миллионами активных пользователей в месяц. Инженеры, стоящие за системой, знали, что продолжение роста бизнеса будет подчеркивать их инфраструктуру (а также людей, которые проверяют счета за базу данных).Так, команда решила пересмотреть систему, прежде чем она нанесла какие-либо сердечные приступы. TL;DR, они разработали систему, которая была любима внутри и пользователями. И Jivesh Threja (Tech Lead) и Srinivas Shanmugam (Chief Architect) присоединились к нам в День Святого Валентина в прошлом году, чтобы поделиться своим опытом. Они изложили технические требования к замене (нейтралитет облака, готовность к работе с несколькими арендаторами, простота ввода новых случаев использования, высокая пропускная способность и низкая задержка при оптимальных затратах) и как это привело к ScyllaDB. Затем они объяснили, как они достигли своих целей с помощью нового потока обработки трубопровода, нового уровня API и (ре)моделирования данных. Они поделились уроками, которые могли бы принести пользу любому, кто рассматривает или использует ScyllaDB. 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true Вот некоторые моменты из этой беседы... Что такое Heartbeat? «Heartbeat» относится к запросу, который запускается с регулярными интервалами во время воспроизведения видео на платформе ZEE5 OTT. Эти простые запросы отслеживают то, что пользователи смотрят, и насколько далеко они продвинулись в каждом видео. Они необходимы для функциональности «продолжайте смотреть» ZEE5, которая позволяет пользователям перерывать контент на одном устройстве, а затем возобновить его на любом устройстве. Зачем меняться? Оригинальная система сердцебиения ZEE5 была сетью различных баз данных, каждая из которых обрабатывала определенную часть потокового опыта.Хотя это было технически функциональным, этот подход был дорогим и замкнул их в конкретную экосистему поставщиков. Они хотели системы, которая не была заблокирована ни в одном конкретном облачном провайдере, стоила бы меньше, чтобы работать, и могла справиться с их огромным масштабом с последовательно быстрой производительностью – в частности, однозначными миллисекундными ответами. Плюс, они хотели гибкости, чтобы легко добавлять новые функции и возможность предлагать свою систему другим потоковым платформам. Системная архитектура до и после Вот обзор их оригинальной системной архитектуры с несколькими базами данных: DynamoDB хранит основные данные о сердцебиении Amazon RDS для хранения информации о следующем и предыдущем эпизодах Apache Solr для хранения постоянных метаданных One Redis instance для кэширования метаданных Еще один Redis-инстанция для хранения деталей аудитории Команда ZEE5 рассмотрела четыре основных варианта баз данных для этого проекта: Redis, Cassandra, Apache Ignite и ScyllaDB. После оценки и сравнительного анализа они выбрали ScyllaDB. ScyllaDB управляет как слоем кэша, так и постоянной базой данных в рамках одной инфраструктуры, обеспечивая низкую задержку в разных регионах, репликацию и готовность к работе с несколькими облаками. он работает с любым поставщиком облаков, включая Azure, AWS и GCP, и теперь предлагает управляемую поддержку с временем оборота менее часа. ScyllaDB управляет как слоем кэша, так и постоянной базой данных в рамках одной инфраструктуры, обеспечивая низкую задержку в разных регионах, репликацию и готовность к работе с несколькими облаками. он работает с любым поставщиком облаков, включая Azure, AWS и GCP, и теперь предлагает управляемую поддержку с временем оборота менее часа. Новая архитектура упрощает и сглаживает структуру предыдущей архитектуры системы. Теперь все события сердцебиения вводятся в тему сердцебиения, обрабатываются с помощью потоковой обработки и вводятся в облако ScyllaDB с использованием соединителей ScyllaDB. Всякий раз, когда контент публикуется, он вводят в тему метаданных, а затем вводят в облако ScyllaDB через соединители метаданных. Srinivas заключает: «С этой новой архитектурой мы успешно мигрировали рабочие нагрузки из DynamoDB, RDS, Redis и Solr в ScyllaDB. ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. Глубже в дизайн Следующий Jivesh поделился больше о своем низкоуровневом дизайне... Трубопровод для обработки потоков в режиме реального времени В трубопроводе обработки потоков в режиме реального времени сердцебиения отправляются в ScyllaDB с регулярными интервалами. Интервал сердцебиения устанавливается на 60 секунд, что означает, что каждый клиент фронта отправляет сердцебиение каждые 60 секунд, пока пользователь смотрит видео. Эти сердцебиения проходят через систему обработки потока воспроизведения, бизнес-логические потребители преобразуют эти данные в необходимый формат – затем обработанные данные хранятся в ScyllaDB. Скалируемый API layer Первым компонентом масштабируемого API-слоя является сердцебиение, которое отвечает за обработку больших объемов поглощения данных. Другая примечательная услуга API-слоя — это услуга Concurrent Viewership Count. Эта услуга использует ScyllaDB для получения данных одновременного просмотра — либо по пользователю, либо по активу (например, по идентификатору). Случай использования управления метаданными Одним из первых серьезных вызовов, с которыми столкнулся ZEE5, было управление метаданными для своей огромной платформы OTT. Изначально они полагались на комбинацию трех различных баз данных – Solr, Redis и Postgres – для решения своих обширных потребностей в метаданных. Вот взгляд на их модель метаданных: create keyspace.meta_data ( id text, title text, show_id text, …, …, PRIMARY KEY((id),show_id) ) with compaction = {‘class’: ‘LeveledCompactionStrategy’ }; Поскольку эта таблица испытывает относительно мало записей (написывание происходит только при выпуске нового актива), но значительно больше читает, они использовали Стратегию сжатия уровня для оптимизации производительности. Просмотр Count Use Case Число просмотров можно отслеживать по идентификатору пользователя или по идентификатору актива. ZEE5 решил спроектировать таблицу, в которой идентификатор пользователя служил ключом раздела, а идентификатор актива — ключом сортировки — позволяя эффективно запрашивать данные просмотров. Они настроили TTL ScyllaDB, чтобы соответствовать интервалу сердцебиения в 60 секунд, гарантируя, что данные автоматически истекают после назначенного времени. Дживеш объяснил: «Эта таблица постоянно обновляется сердцебиениями от каждого переднего конца и каждого пользователя. По мере прибытия сердцебиений подсчеты зрителей отслеживаются в режиме реального времени и автоматически очищаются при истечении срока действия TTL. Вот их модель данных о количестве зрителей: CREATE TABLE keyspace.USER_SESSION_STREAM ( USER_ID text, DEVICE_ID text, ASSET_ID text, TITLE text, …, PRIMARY KEY((USER_ID), ASSET_ID) ) WITH default_time_to_live = 60 and compaction = { 'class' : 'TimeWindowCompactionStrategy' }; Результаты ScyllaDB и полученные уроки Следующий отчет об испытании нагрузки показывает пропускную способность 41,7 000 запросов в секунду.Этот показатель проводился во время процесса отбора базы данных для оценки производительности при высокой нагрузке. Дживеш отметил: «Даже при такой высокой пропускной способности мы могли достичь задержки записи в микросекунды и средней задержки чтения в микросекунды. Затем он продолжил делиться некоторыми фактами, которые проливают свет на масштабы развертывания ScyllaDB ZEE5: «У нас на ScyllaDB около 9 ТБ. Даже при таком большом объеме данных он способен обрабатывать задержки в пределах микросекунд и однозначной миллисекунды, что довольно огромно. Каждый день мы записываем столько данных в ScyllaDB и получаем столько данных из него Мы обрабатываем более 100 миллиардов ударов сердца в день, что довольно огромно». Беседа завершилась следующими уроками: Моделирование данных является одним из наиболее важных факторов в достижении однозначной миллисекундной задержки. Выберите правильную настройку кворума и стратегию сжатия.Например, нужно ли записывать сердцебиение на каждый узел, прежде чем его можно прочитать, или достаточно местного кворума? Выбирайте разделительные и кластерные ключи мудро – позже их изменить нелегко. Используйте Материализированные представления для более быстрых поисков и избегайте фильтрационных запросов. Используйте подготовленные заявления для повышения эффективности. Например, в модели метаданных 20 синхронных запросов выполнялись параллельно, и ScyllaDB обрабатывал их в пределах миллисекунд. Клиенты ScyllaDB, осведомленные о зоне, помогают снизить сетевые затраты через АЗ (зону доступности).Загрузка данных в пределах одной АЗ минимизирует задержку и значительно снижает сетевые затраты.
