Про базы данных

Обеспечение надежного сохранения данных и их восстановления после сбоев — ключевая задача систем обработки данных. Любая ошибка записи может привести к потере транзакций или повреждению данных, а масштабные системы требуют при этом высокой производительности и быстрой доступности после сбоя. Мы в OtterBrix тоже столкнулись с задачей проектирования собственного WAL, и довольно быстро выяснили, что универсального рецепта здесь не существует.

Проектирование WAL — это поиск инженерного компромисса между скоростью записи, временем фиксации транзакций, временем восстановления после сбоя и надёжностью системы хранения. В зависимости от требований, для каждой отдельной СУБД этот компромисс будет решатся по-разному.

В докладе я покажу модель принятия решений при проектировании WAL на примере PostgreSQL, SQLite и DuckDB, а также расскажу, как в OtterBrix мы построили собственный WAL.

Greenplum стал closed source. Но мы продолжаем развивать его в Apache Cloudberry. Как емко заметил в свое время Andy Pavlo, основной проблемой Greenplum было то, что никто больше не ставил его добровольно. Мы хотим это изменить. Например, добавили новый формат хранения PAX. PAX - колоночное хранилище для гибридной транзакционной и аналитической обработки. Ближайший аналог - parquet/orc. Зачем еще один формат? Краткий ответ - для производительности, потому нужны еще и улучшения в движок выполнения запросов, чтобы сделать аналог zone maps и bloom filter из parquet. Детали нового формата PAX и улучшений в движке запросов расскажу в докладе.

Больше Постгресов богу Постгреса! Давайте на своём ноуте накодим себе доработанный напильником Постгрес: соберём, изучим внутренности, что-то улучшим, что-то сломаем, всё протестируем и надёжно склеим скотчем.

В нашей системе аналитики события проходят путь от шины данных через сервис сбора событий, попадают в Kafka, а затем — в ClickHouse с помощью Kafka-Engine. В архитектуре — три кластера ClickHouse (main, replica, sandbox) с настроенной репликацией, каждый из которых обслуживает свою зону ответственности: сбор, BI, пользовательские запросы.

Мы провели серию нагрузочных и отказоустойчивых тестов, чтобы убедиться, что система выдерживает реальные и экстремальные сценарии. В докладе расскажем:

• Как устроен наш стриминговый пайплайн: от шины данных до ClickHouse.
• Как сервис сбора событий справляется с миллиардами событий.
• Какие тесты проводили:
• 9 млрд событий в сутки;
• 15 млрд событий в сутки;
• 24 млрд событий в сутки — предел, к которому стремились;
• внезапный скачок нагрузки х2;
• сбой кластера ClickHouse и как он проявился;
• сбой Kafka и поведение пайплайна;
• запись всех событий в один проект вместо 50+ — и к чему это привело;
• Kafka-Engine vs Kafka-Connect — замеры, сравнение, выбор.
• Как организовали мониторинг и метрики, на что смотрели в Grafana и ClickHouse.
• Какие баги, затыки и инсайты мы получили и как это повлияло на прод.
• Дополнительный тюнинг ClickHouse для приема 100 млрд событий в сутки

Доклад будет интересен всем, кто работает с ClickHouse под высокой нагрузкой, собирает real-time-данные, использует Kafka и хочет понять, где тонко и как не порвать.

Расскажу, как MongoDB работает в реальной продакшн-среде: как хранилище, кеш, брокер сообщений, time-series и распределенная база данных. Покажу, где она действительно справляется и позволяет упростить стек, а где на практике пришлось перейти на специализированные решения: Redis, Kafka, VictoriaMetrics. Поделюсь архитектурными компромиссами, эксплуатационными нюансами и выводами, которые помогают трезво выбирать инструменты.