Уроки создания эффективной базы данных: опыт и перспективы Polar Signals

Крипто-кошельки Налоги и криптовалюта

Разработка собственной базы данных – задача, которая требует глубоких технических знаний и стратегического видения. Опыт компании Polar Signals, которая создала FrostDB, позволяет понять, как шаг за шагом можно построить систему, отвечающую требованиям современного рынка непрерывного профилирования. Эта работа дала ценные уроки, которые стали основой для будущих решений и новых подходов в области хранения и обработки данных. Изначально проектирование базы данных началось с изучения уже существующих решений и понимания, каких особенностей не хватает для специфических нужд непрерывного профилирования. В качестве отправной точки была выбрана платформа Prometheus, которая хорошо зарекомендовала себя в мониторинге и работе с временными рядами.

Однако стандартная архитектура Prometheus не удовлетворяла потребностями по работе с профилирующими данными в виде бинарных pprof-форматов, что подтолкнуло к ребрендингу и развитию системы в рамках проекта ConProf. Основной подчеркнутой задачей стало создание продукта, предназначенного для ежедневного использования профессионалами, включая самих разработчиков. Важным условием была открытость решений, что соответствует духу open source. Унаследовать удобство использования Prometheus в формате одного исполняемого файла — ключевая идея, от которой отталкивались при формировании архитектуры FrostDB. Эту базу данных отличала способность работать с произвольно широкими колонками, что позволяло гибко обрабатывать метки пользователей, а также встроенная поддержка Go, что существенно упрощало интеграцию.

На первых этапах FrostDB идеально справлялась с обеспечением функционала в рамках проекта Parca, однако с ростом требований и масштабов стало ясно, что необходимо обеспечить работу продукта в масштабах облачных решений с множеством клиентов. Это привело к разработке нового слоя, обеспечивающего масштабируемость, отказоустойчивость и управление многопользовательскими средами. В основе новой архитектуры лежало разделение хранения и вычислений, что делало систему более гибкой и экономически выгодной при увеличении нагрузки. Отказ от необходимости напрямую управлять дисковыми ресурсами в пользу объектного хранилища крупных облачных провайдеров существенно снизил сложность эксплуатации и сопутствующие расходы. Для небольшой команды Polar Signals стало критически важно избегать слишком сложных инфраструктур, таких как кластеры сообщений на базе Kafka, которые требуют постоянного внимания и увеличивают стоимость владения.

Принятая методика включала развертывание нескольких инстансов FrostDB, при котором записи данных распределялись между ними, а каждый запрос разбивался на части, обрабатываемые соответствующими узлами. При достижении определённого объёма в оперативной памяти данные сериализовались в формат Parquet и сохранялись в облачное хранилище. Такой подход обеспечил баланс между простотой управления, экономичностью и эффективностью использования ресурсов. В качестве одного из способов оптимизации расходов была выбрана модель использования прерываемых облачных инстансов (preemptible instances), которые облачный провайдер может в любой момент отключить, что позволяет значительно экономить средства. Система поддерживала корректную работу, сохраняя данные перед завершением работы и восстанавливаясь после повторного запуска.

Тем не менее при росте числа пользователей и увеличении объёмов данных возникла проблема потери данных при недостаточно быстрой записи в объектное хранилище во время принудительного завершения работы инстансов. Внедрение журнала предварительной записи (Write Ahead Log, WAL) позволило защититься от потерь, однако потребовало возврата к необходимости работы с дисковыми состояниями, что противоречило первоначальной цели по упрощению эксплуатации. Использование WAL дало устойчивость, но увеличило время восстановления после сбоев. Накопление записей на диске и необходимость их последовательного воспроизведения привели к замедлению запуска нод, что негативно сказывалось на доступности базы. Для ускорения восстановления была осуществлена миграция на твердотельные накопители, но и это решение рассматривалось как временная мера.

Для повышения отказоустойчивости была внедрена репликация данных, благодаря которой узлы могли обслуживать запросы и принимать новые записи даже при выходе из строя отдельных инстансов. Однако дублирование данных увеличило затраты на хранение и поддержание инфраструктуры. Этот компромисс между надёжностью и экономичностью стал одной из главных дилемм разработки. Появилась потребность в дополнительной координации между узлами для синхронизации данных. Новый уровень управления позволил узлам обмениваться информацией о транзакциях и запрашивать пропущенные данные напрямую у друг друга, избавляя распределитель запросов от хранения больших объёмов буферной информации.

Это существенно улучшило устойчивость к сбоям и снизило нагрузку на центральные компоненты. С другой стороны, введение координационного слоя сделало систему более сложной в эксплуатации. Неожиданные сценарии сбоев, например массовые прерывания работы инстансов облачного провайдера, приводили к росту потребления ресурсов во время восстановления, что в ряде случаев вызывало циклы сбоев и падений узлов из-за нехватки памяти. В итоге текущая версия базы данных хорошо функционирует, но уже не соответствует изначальным замыслам упрощённости, экономичности и разделения вычислительной мощности и хранения данных. Опыт создания решения практически в «полетных» условиях, с постепенным приближением к «посадке», стал фундаментом для новых проектов, где учитываются все выявленные ограничения и ошибки.

Polar Signals анонсировали работу над новым поколением базы данных, в котором будет возвращено постепенное достижение изначальных целей разработки: гибкость, простота управления и масштабируемость без значительного роста расходов. Следующий крупный пост блога обещает раскрыть детали этой кардинально переработанной архитектуры. Путь создания FrostDB и его эволюция демонстрируют типичные сложности при построении специализированных систем хранения данных для узкоспециализированных задач. Они показывают, что важность постоянного анализа архитектурных решений и готовность к компромиссам являются неотъемлемой частью технологического прогресса. Изучение опыта Polar Signals может стать полезным источником знаний для инженеров, архитекторов и менеджеров, планирующих собственные разработки баз данных или сервисов хранения больших объёмов профильных данных.

Баланс между производительностью, надёжностью и стоимостью – сложная, но достижимая задача при грамотном подходе и внимательном учёте уроков прошлого.