13 513
правок
Изменения
Нет описания правки
== Велосипед от Тинькова (SAGE DB) ==
'''Александр Бирюков (Тинькофф) — Когда нужно делать свою базу данных'''
...под логи.
Было плюс-минус интересно послушать про устройство индексаторов логов. ElasticSearch — обратные индексы, поэтому ЖРЁТ сторадж, Loki — вообще никаких индексов, только дискретное деление по файлам, поэтому тормозит, OpenObserve — новее и круче, паркеты (Parquet), точнее FDAP (Flight, DataFusion, Arrow, Parquet — на эту же связку уже перешли InfluxDB и Parseable), в паркетах есть сжатие, блум фильтры, индексы и всё такое, но фиксированная схема и вроде как не выходит реализовать какие-то оптимизации из-за абстрактности формата. В Clickhouse — тоже схема, а они хотели без схемы вообще (хз, зачем).
Проект SAGE у них начался в 2019, когда им не захотел продлевать лицензию Splunk. Сначала сделали на эластике, потом в силу вышеописанных архитектурных нюансов решили писать своё, допилить эластик силами 3-4 лиц не осилили бы. Сначала пробовали сделать свои обратные индексы на RocksDB, но быстро упёрлись. В итоге сделали своё подобие FDAP, но без схемы. Причём даже формат сериализации свой без декодирования и без схемы, и Flexbuffers почему-то не подошёл, хотя Flexbuffers это дословно формат без декодирования и без схемы. Тоже со сжатием (zstd + словарным для ключей) и блум-фильтрами. Общая схема в итоге похожа на Loki поверх S3.
Замеры: по скорости помедленнее эластика, условно 0.5 сек 50% квантиль против 0.15 сек. Но зато на эластике 350 серверов и 7 ПБ, а на SageDB 270 серверов и 700 ТБ. По облачным ценам экономия примерно 360 млн руб в год. Но работают пока обе схемы в параллель, полный переход ещё не состоялся, пока что все запросы зеркалируются. Пилили 3 года.
Ну хз. А чего было просто не взять Кекхауз (Clickhouse)? Ну схема, да, но ведь в логах не так чтобы прямо много разных форматов и колонок. Сложилось же бы, наверное.
== PATCH в S3 ==
