How Coralogix cut processing times from 30 seconds to 86 milliseconds with a PostgreSQL to ScyllaDB migration. Скорость имеет значение для Coralogix использует потоковую аналитическую трубу в режиме реального времени, предоставляя возможности мониторинга, визуализации и оповещения без необходимости индексирования. Coralogix Одним из ключевых дифференциаторов Coralogix является распределенная система запросов для быстрых запросов на картографированные данные из архивов клиента в удаленном хранилище. Первоначально он был разработан в качестве системы запросов без статуса сверху основного объектного хранилища, но чтение метаданных Parquet во время выполнения запроса ввело неприемлемый удар задержки. Паркет Таким образом, команда попробовала новую реализацию — на этот раз с ScyllaDB вместо PostgreSQL. Спойлер: Это сработало. Они добились впечатляющих результатов — сократили время обработки запросов с 30 секунд до 86 миллисекунд. И их инженеры Дэн Харрис (главный инженер программного обеспечения) и Себастьян Веркройс (старший инженер программного обеспечения) вышли на сцену на саммите ScyllaDB, чтобы объяснить, как они это сделали. Присоединяйтесь к нам на ScyllaDB Summit 24, чтобы услышать больше отчетов из первых рук о том, как команды решают свои самые сложные задачи с базами данных. ScyllaDB Summit 2024 уже в продаже! Update: Метасторы Мотивация и требования Прежде чем входить в детали реализации метастазов, давайте сделаем шаг назад и рассмотрим сначала аргументы построения метастазов. «Мы изначально разрабатывали эту платформу как систему запросов без статуса сверху базового объектного хранилища, но мы быстро поняли, что затраты на чтение метаданных Parquet во время выполнения запроса составляют большой процент времени запроса», — объяснил Дан Харрис. Они придумали решение, которое: Хранить метаданные Parquet в разлагаемом формате для высокой масштабируемости и пропускной способности Используйте фильтры bloom для эффективной идентификации файлов для сканирования для каждого запроса Использование транзакционных журналов коммиссии для транзакционного добавления, обновления и замены существующих данных в базовом хранилище объектов Ключевые требования включали низкую задержку, масштабируемость как с точки зрения способности чтения/писания, так и масштабируемость базового хранилища. генерирует 2000 файлов Parquet в час (50 000 в день), в общей сложности 15 ТБ в день, в результате чего 20 ГБ метаданных Parquet только . Единый клиент За один день Единый клиент За один день Первоначальная реализация PostgreSQL «Мы начали первоначальную реализацию на Postgres, понимая в то время, что нераспределенного двигателя не хватило бы на долгое время», — признался Дан. Эта первоначальная реализация хранила ключевую информацию, такую как «блоки», представляющие одну группу строк и один файл Parquet. Block url: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet Row group: 0, 1, 2 … Min timestamp Max timestamp Number of rows Total size … Чтобы оптимизировать чтение, они использовали фильтры цветов для эффективного обрезки данных. Дэн подробно сказал: «В конечном счете, мы хотим поддерживать что-то вроде полного текстового поиска. В основном, когда мы вводим эти файлы в нашу систему, мы можем построить фильтр цветов для всех отдельных токенов, которые мы находим в файле. Затем, основываясь на конкретном запросе, мы можем использовать эти фильтры цветов для обрезки данных, которые нам нужно сканировать.» Кроме того, они хранили колонные метаданные для каждого файла Parquet, например: Block URL Row Group Column Name Column metadata (blob) Дан объяснил: «Файлы, которые мы пишут, довольно широкие, иногда до 20 000 колонн. так что, читая только те метаданные, которые нам нужны, мы действительно можем уменьшить количество IO, необходимого для любого данного запроса». Внедрение ScyllaDB Далее давайте рассмотрим реализацию ScyllaDB, описанную коллегой по команде Дэн, Себастьяном Веркруйсе. Блокирование моделирования данных Моделирование блоков пришлось пересмотреть для новой имплементации. Вот пример URL блока: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet Смелая часть - это коробка верхнего уровня клиента; внутри коробки предметы разделены по часам. Но у некоторых клиентов гораздо больше файлов Parquet, чем у других клиентов, и они хотели сохранить баланс. ((Block url, row group))? Это уникально идентифицирует данный блок, но было бы трудно перечислить все блоки для данного дня, потому что временная метка не находится в ключе ((Table url, time))? Это работает, потому что если у вас есть 24 часа для запроса, вы можете запросить довольно легко ((Table url, time), block url, row group)? Это то, что они выбрали.Добавляя блок url и строку группы в качестве кластерных ключей, они могут легко получить конкретный блок в течение часа, что также упрощает процесс обновления или удаления блоков и строк групп. Bloom Filter Chunking и моделирование данных Следующая задача: как проверить, что определенные биты настроены, учитывая, что ScyllaDB не предлагает для этого функций вне коробки. Команда решила прочитать фильтры цветения и обрабатывать их в приложении. Однако помните, что они имеют дело с до 50 000 блоков в день на клиента, каждый блок содержит 262 КБ для части фильтра цветения. Это в общей сложности 12 ГБ – слишком много, чтобы перетащить обратно в приложение для одного запроса. Но им не нужно было читать весь фильтр цветения каждый раз; им нужны были только части этого, в зависимости от токенов, участвующих во время выполнения запроса. Для моделирования данных одним из вариантов было использование В качестве основного ключа. Это генерировало бы 8192 фрагмента 32 байта на цветочный фильтр, что привело бы к равномерному распределению примерно с 262 КБ на раздел. С каждым цветочным фильтром в одном разделе было бы легко вводить и удалять данные с помощью одного партийного запроса. Но есть улов, который влияет на эффективность чтения: вам нужно знать идентификатор блока, прежде чем вы сможете прочитать цветочный фильтр. Кроме того, подход включал бы доступ к существенному количеству разделов; 50K блоки означают 50K разделов. И, как отметил Себастьян, «Даже с чем-то таким быстрым, как ScyllaDB, все еще трудно достичь подсекундного процесса для 50K разделов». ((block_url, row_group), индекс шунка Другой вариант (то, о котором они в конечном итоге решили): Обратите внимание, что это тот же разделительный ключ, что и блок, с добавленным индексом к разделительному ключу, который представляет собой первый токен, требуемый поисковой системой.С этим подходом сканирование 5 токенов, охватывающих 24-часовое окно, приводит к 120 разделам – впечатляющее улучшение по сравнению с предыдущим вариантом моделирования данных. ((table url, hour, chunk index), блок url, группа строк) Кроме того, этот подход больше не требует идентификатора блока перед чтением фильтра цветения – позволяя более быстрые чтения. Конечно, всегда есть компромиссы. Здесь, из-за блокированного подхода фильтра цветения, им приходится разделить один фильтр цветения на 8192 уникальных разделов. Это в конечном итоге влияет на скорость поглощения по сравнению с предыдущим подходом разделения, который позволил поглощать все куски фильтра цветения сразу. Однако, способность быстро читать данный блок в течение часа для них важнее, чем быстрые письма – поэтому они решили, что этот компромисс стоит того. Моделирование данных ухудшает Неудивительно, что переход от SQL к NoSQL включал в себя достаточное количество переработки моделирования данных, включая некоторые попытки и ошибки. Например, Себастьян поделился: «Однажды я узнал, что мы сломали минус и максимум временные отметки – и я подумал, как я собираюсь это исправить. я думал, что, возможно, я мог бы переименовать столбцы, а затем каким-то образом сделать его работать снова. но, здесь вы не можете переименовать столбчик, если он является частью кластерного ключа. В конце концов, они решили отрезать стол и начать снова против написания кода миграции. Показатель выигрыша Несмотря на требуемую работу по моделированию данных, миграция хорошо оплачивалась. Каждый узел в настоящее время обрабатывает 4-5 Тб. В настоящее время они обрабатывают около 10K записей в секунду с задержкой P99 последовательно ниже миллисекунды. Перечень блоков дает около 2000 паркетных файлов в час; с их фильтрами цветения они обрабатываются менее чем за 20 миллисекунд. Для 50K файлов это менее 500 миллисекунд. Но для файлов 50K Parquet 500 миллисекунд вполне соответствует их потребностям. В области обработки метаданных в столбце P50 довольно хорош, но имеет высокую задержку хвоста. Себастьян объяснил: «Проблема в том, что если у нас есть файлы 50K Parquet, наши исполнители собирают все эти файлы параллельно. Скачать ScyllaDB Примечательно, что Coralogix перешел от первого открытия ScyllaDB к поступлению в производство с терабайтами данных всего за 2 месяца (и это была миграция SQL в NoSQL, требующая работы по моделированию данных, а не гораздо более простая миграция Cassandra или DynamoDB). Реализация была написана в Rust на вершине И они нашли , , и Поскольку для Coralogix важно предложить своим клиентам альтернативу низкой стоимости для наблюдения, команда Coralogix была довольна благоприятными ценовыми характеристиками своей инфраструктуры ScyllaDB: 3-узловым кластером с: ScyllaDB Rust водитель Оператор ScyllaDB для Kubernetes Мониторинг ScyllaDB ScyllaDB менеджер 8 ВПК 32 ГБ памяти Оружие / Гравитон Объемы EBS (gp3) с пропускной способностью 500 Мбит/с и 12 000 IOPS Использование ARM снижает затраты, и решение использовать объемы EBS (gp3) в конечном итоге сводилось к доступности, гибкости и ценовой эффективности. Уроки выучены Ключевые уроки, которые они получили здесь... Наибольшее различие в работе с ScyllaDB против работы с Postgres заключается в том, что вы должны очень тщательно думать о ваших разделах и разделах. Keep an eye on partition sizes: Вы также должны тщательно подумать о закономерностях чтения и письма.Ваша нагрузка читается тяжело? Это связано с хорошим сочетанием чтения и письма? Или, это преимущественно тяжелое? рабочая нагрузка Coralogix довольно тяжелое, потому что они постоянно поглощают данные, но они должны отдавать приоритет чтению, потому что задержка чтения является наиболее критической для их бизнеса. Think about read/write patterns: Команда признает, что им было предупреждено не использовать EBS: «Мы не слушали, но мы, вероятно, должны. если вы рассматриваете использование ScyllaDB, это, вероятно, будет хорошей идеей посмотреть на инстанции, которые имеют локальные SSD вместо того, чтобы пытаться использовать объемы EBS». Avoid EBS: Будущие планы: WebAssembly UDF с Rust В будущем они хотят найти середину между написанием достаточно больших кусочков и чтением ненужных данных.Они разделяют кусочки на ~8000 строк и считают, что они могут разделить их дальше на 1000 строк, что может ускорить их вставки. Их конечная цель заключается в том, чтобы отгрузить еще больше работы в ScyllaDB, используя С их существующим кодом Rust интеграция UDF исключит необходимость отправки данных обратно в приложение, обеспечивая гибкость для корректировки и потенциальных улучшений. Функции, определяемые пользователем (UDF) с помощью WebAssembly Себастьян делится: «У нас уже есть все написано в Rust. Было бы очень хорошо, если бы мы могли начать использовать UDF, чтобы нам не пришлось ничего отправлять обратно в приложение. Смотреть полный технический разговор Вы можете посмотреть полный технический разговор и скаймировать через палубу в нашей библиотеке технических разговоров. О компании Cynthia Dunlop Синтия является старшим директором по стратегии контента в ScyllaDB. Она пишет о разработке программного обеспечения и инженерии качества более 20 лет.
