Как появился тренд встраиваемых баз данных
Новые тренды иногда представляют как противостояние одних типов нейросетей другим типам, или одного типа языка другому, или одной базы другой. Но интереснее рассмотреть понятие новых трендов шире. Например, как решения новых задач, которые возникли на стыке прошлых трендов. С 2010 года в профессиональном сообществе обсуждают, что монолиты — это плохо и сложно и вместо них нужно писать микросервисы. Есть решения, которые продолжают тему микросервисов и монолитов, только под другим углом, — это встраиваемые базы данных. Все привыкли видеть их в мобильных устройствах, но возможная область применения встраиваемых баз данных гораздо шире.
Тренд встраиваемых баз данных запустили аналитики, когда возникла задача посчитать статистику. Дальше он начал развиваться: есть Web3, а также блокчейны, в которых тоже нужна своя база. Пик развития случился в тот момент, когда появился инструмент, который позволяет сделать суперстранное: SQLite Dump & Restore. То есть в работающем приложении вы можете переписать всю базу.
После этого тренд продолжает развиваться. ClickHouse может развернуть поверх скиллайт-файла целую таблицу и обрабатывать её по столбцам. PostgreSQL поддерживает импорт, экспорт и возможность разворачивания. MySQL предлагает множество решений, которые легче кастомизировать.
В какой-то момент тренд встраиваемых баз начал жить сам по себе. Он выглядит всё время по-разному. Но история показывает, что тренду есть место.
Особенности основных игроков на рынке встраиваемых баз
SQLite — понятный, простой и всеми любимый.
DuckDB — модный, умеет быть мини-ClickHouse.
Otterbrix — есть проблемы с индексами, но он может притвориться колоночной, маленькой встраиваемой базой данных.
Встраиваемые базы применяются в мобильных приложениях, а также для предварительной фильтрации данных на бэкенде.
Оптимизация работы крупной компании на примере криптобиржи
В работе любой биржи есть большие нагрузки и сложные задачи, которые нужно решать. Дальше мы разберём два варианта выявления рисковых ситуаций на бирже: стандартный и с помощью встраиваемой базы данных.
Стандартный подход
У любой криптобиржи есть ядро. У неё есть отображение свечек и некоторые инструментарии для того, чтобы приложение удобно могло показывать котировки. Каждый из сервисов генерит миллионы событий в секунду.
Эти события нужно агрегировать и складировать. Для этого есть кластер Kafka. Также есть холодный DWH — Greenplum, в который добавляют немного обработанные венты. Также обычно используется быстрый и удобный ClickHouse и Databricks — традиционный игрок на рынке, который предлагает понятные решения. Но у такого подхода есть особенности: много Park, Cloud и высокая цена. Чтобы это всё собирать и управлять, пишут ETL с большим количеством модулей.
У ETL есть две основные задачи:
- Создавать отчёты для руководства и регуляторов
- Отправлять в риск-мониторинг все события, которые на бирже после работы ETL сочли подозрительными
В результате такой работы в риск-аналитику попадает информация о миллионах подозрительных событий. И дальше с этой информацией разбираются люди.
У такого подхода к организации работы есть особенности:
- Железо и лицензии для риск-аналитики стоят дорого
- Выгрузка данных для расследования инцидента занимает недели
- Ложноположительные инциденты тратят дорогое время специалистов
Отчёты создаются неделями, иногда месяцами, что недопустимо при работе с финансами. Особенно если это риск-аналитика — чем раньше поймали угрозу, тем лучше. На ложные срабатывания отвлекаются живые люди — получается дорого и не очень эффективно.
Использование встраиваемых баз
Оптимизировать стандартную схему работы криптобиржи можно с помощью встраиваемых баз данных. Если уже есть кластер Kafka, то зачем ломать текущий пайплайн обработки информации и изменять все процессы? Чтобы снизить стоимость работ и увеличить скорость отзывчивости, добавим ещё одного слушателя. Он с помощью очень тривиальной модели без машинного обучения просто находит и маркирует подозрительных людей, группу людей или подозрительные события, которые относятся к этим людям. Затем из ETL убираем часть бизнес-логики, которая не нужна на данном этапе.
В тот момент, когда машинное обучение чувствует, что группа людей была распознана, небольшой сервис начинает слушать Kafka. Из общего потока он вынимает маленькие элементы, которые относятся только к тем объектам, которые разметили как подозрительные. А дальше сервис свои результаты складывает в ETL для общей группировки, чтобы не сломать общий пайплайн. Затем всё то же самое: сначала в риск-мониторинг, потом в Control Panel.
Под «капотом» у маленького простого докер-контейнера — Python Script, в который поместили большую часть логики, за которой ходили в ClickHouse. И использовали DuskDB, потому что эти данные нужны, только пока происходит анализ рисков. В дальнейшем всегда можно остановить контейнер, выгрузить данные, положить в мастер.
Но есть некоторые наборы событий, которые нельзя так решать. Тогда приходится обращаться не только в ClickHouse, но и в Databricks, но Databricks обрабатывает запрос очень долго. Чтобы уменьшить это время, вынимаем много логики из Databricks, ClickHouse, Python. Добавляем всё в маленькие контейнеры, которые работают со своими маленькими ограниченными наборами данных.
Чего получилось добиться с EDB:
- Стоимость серверов и лицензий для риск-аналитики сократилась на 50%
- Инциденты расследуются за часы, а не за недели
- Первые сигналы можно получить за минуты, а не за часы
Плюсы и минусы разных систем хранения и обработки хранения данных
Как мы рассмотрели выше, есть случаи, в которых встраиваемые базы помогают оптимизировать процессы работы. Для решения одной и той же задачи можно использовать разные встраиваемые базы. Но у каждого решения есть свои плюсы и минусы. Чтобы понять, какое выбрать в конкретной ситуации, важно знать основные особенности каждого из игроков на рынке EDB.
Чтобы было понятно, как выбирать встраиваемые базы данных, их нужно нормировать. У нас есть классические игроки на рынке.
ClickHouse — про аналитику и OLAP-нагрузку в чистом виде.
Mongo — классические представители OLTP-нагрузки с лёгкими попытками уйти в аналитику.
PostgreSQL — больше про LTP, но в нём есть возможность немножечко заниматься аналитикой.
EDB — хорошо показывает себя, когда непонятен профиль нагрузки или нужно новое приложение, им приятно и удобно пользоваться.
SQLite — новый игрок, который классически про OLTP. Он немножко умеет в JSON, но это не означает, что он про аналитику.
Otterbrix — это фреймворк, поэтому что выберете, то и будет у вас гибко.
DuckDB — пытается уйти в чистую аналитику и работать с этим настолько, насколько это возможно.