• CDB — это формат, оптимизированный для чтения и случайных поисков, но не для записи, что делает его полезным для специфических сценариев использования.
• Он не поддерживает обновление данных, вместо этого требуется перезаписывать весь файл, что делает его неподходящим для больших баз данных.
• Некоторые участники обсуждения отметили, что CDB может быть полезен для конфигурационных файлов, DNS записей, или других сценариев, где данные нечасто обновляются.
• Были упомянуты альтернативы, такие как RocksDB, которые могут быть более подходящими для других сценариев.
• В конце обсуждение перешло к тому, что CDB — это просто еще один инструмент в наборе, и его полезность зависит от конкретного сценария.

TernFS — экзабайтная распределенная файловая система с поддержкой нескольких регионов

XTX — алгоритмическая торговая фирма, использующая статистические модели для прогнозирования цен. По мере роста вычислительных мощностей потребности в хранилищах также увеличивались. Изначально использовались NFS и коммерческие решения, но в итоге было принято решение разработать собственную файловую систему — TernFS.

TernFS теперь доступна как открытое ПО на GitHub. В статье объясняется её архитектура и ключевые детали реализации.

Зачем ещё одна файловая система?

Крупные tech-компании часто разрабатывают собственные распределенные файловые системы из-за их критической важности. XTX оказалась в аналогичной ситуации и создала TernFS как универсальное решение для хранения — от «холодных» данных до временных файлов для обмена между GPU-задачами.

Возможности TernFS:

• Масштабируемость до десятков экзабайт, триллионов файлов и миллионов одновременных клиентов.
• Избыточное хранение данных для защиты от сбоев дисков.
• Отсутствие единой точки отказа в службах метаданных.
• Поддержка снимков файлов для защиты от случайного удаления.
• Работа в нескольких регионах.
• Агностичность к оборудованию, использование TCP/IP.
• Эффективное использование разных типов хранилищ (SSD, HDD).
• Доступ через собственный API (TCP/UDP) и модуль ядра Linux.
• Минимальные зависимости для сборки (C++, Go, RocksDB).

Ограничения:

• Файлы неизменяемы после записи.
• Не подходит для очень маленьких файлов (медиана — 2 МБ).
• Ограниченная пропускная способность при создании/удалении директорий.
• Отсутствие встроенной системы разрешений.

Разработка началась в 2022 году, с 2023 года система используется в production. К середине 2024 года все ML-задачи работают на TernFS. По состоянию на сентябрь 2025 года система хранит более 500 ПБ на 30 000 дисках и 10 000 SSD в трёх дата-центрах, с пиковой пропускной способностью в несколько ТБ/с. Потерь данных не зафиксировано.

Высокоуровневая архитектура

Основной API TernFS реализован четырьмя службами:

• Шарды метаданных — хранят структуру директорий и метаданные файлов.
• Координатор междиректорных транзакций (CDC) — выполняет транзакции между шардами.
• Службы блоков — хранят содержимое файлов.
• Реестр — хранит информацию обо всех службах и мониторит их.

Диаграмма взаимодействия служб TernFS и клиентов.

Далее подробно рассматривается каждая служба и другие аспекты реализации, включая мультирегиональность.

• Обсуждение технических особенностей TernFS: отсутствие RDMA, использование TCP/IP, репликация данных, ограничение на минимальный размер файла (~2MB), специализированная система метаданных.
• Сравнение с другими файловыми системами (CephFS, Lustre, GPFS): различия в архитектуре, производительности, поддержке POSIX и целевых use cases.
• Вопросы о бизнес-модели и масштабах данных XTX: хранение >500PB для ML-моделей в трейдинге, критика "отсутствия реальной ценности".
• Обсуждение лицензии (GPLv2-or-later/Apache-2.0) и предложения по улучшению документации (добавление примеров использования).
• Замечания о нишевых решениях для больших данных: акцент на immutable-данные, сложности с метаданными для tiny files, специализация под конкретные задачи.

Проблема
При промахе кэша Readyset выполняет запрос с нуля. Для «расколотых» соединений (предикаты есть и в WHERE, и в ON) старый hash-join читал обе таблицы полностью:

• фильтр по email возвращал 1 строку users;
• фильтр по status='SHIPPED' — 99 % таблицы orders.
  Материализовав миллионы лишних строк, система строила хэш-таблицу и лишь потом отбрасывала ненужное. Профилирование показало: 30 % времени уходило на распаковку RocksDB, затем на 10 K IOPS и 81 % загрузки NVMe.

Решение: Index Condition Pushdown
Новый план использует индексы и «проталкивает» условия вниз:

1. Сначала выбираем 1 строку users по индексу email.
2. Для каждой найденной u.id делаем индексный lookup в orders с условием user_id = u.id AND status='SHIPPED'.
   Так читаются только нужные строки orders, объём I/O падает на порядки, а хэш-таблица больше не строится.

Результат
ICP устраняет лишнее чтение и распаковку, превращая холодный straddled-join из многомиллисекундной операции в субмиллисекундную.

• Пользователи жалуются, что планировщик запросов не продавливает фильтры к индексам, и считают это багом производительности.
• Многие разработчики вынуждены сами заниматься индексами, партиционированием и анализом EXPLAIN, потому что DBA лишь «держат свет».
• В RonDB и ReadySet показали примеры «pushdown-joins» и Index Condition Pushdown, дав ускорение до 450×.
• ReadySet описывают как «кеш-прокси» поверх MySQL/Postgres, который по логу репликации инкрементально обновляет материализованные представления.
• Часть участников считает, что современные оптимизаторы должны делать такие оптимизации автоматически, и не понимает, зачем изобретать велосипед.

HorizonDB — новая гео-БД на Rust, заменившая Elasticsearch и MongoDB.
Обрабатывает 1 млрд вызовов/день, 1 000 QPS на ядро, 50 мс прямого и <1 мс обратного геокодирования.

Проблемы старого стека

• Elasticsearch: шардирование, дорогие батчи, отсутствие отката.
• MongoDB: нет нормального bulk-импорта, переподбор ресурсов, сложный откат.

Архитектура HorizonDB

• Однопроцессный многопоточный бинарник.
• Данные Spark → S3 → RocksDB (версионные ассеты).
• Индексы: S2 (гео), Tantivy (поиск), FST (префиксы), LightGBM/FastText (ML-ранжирование).

Почему Rust

• Скомпилирован, без GC, предсказуемая латентность.
• Абстракции высокого уровня, pattern matching.
• Один процесс вместо Node.js-кластера → экономия памяти.

Ключевые компоненты

• RocksDB — быстрая запись/чтение с SSD.
• S2 — O(1) point-in-polygon через квадродерево.
• FST — компрессия префиксов, кэш «happy path» в МБ.
• Tantivy — встроенный инвертированный индекс, избегаем сетевого Elasticsearch.

Итог: одна бинарная служба, линейное масштабирование, простые релизы и откаты.

• Пост вызывает много вопросов: детали шардирования, отказоустойчивость, latency и open-source-статус не раскрыты.
• Альтернативы: Typesense, DuckDB+spatial, Quickwit/Tantivy — всё open-source и уже показывает высокую производительность.
• RocksDB хвалят за надёжность и производительность, но кто-то вспоминает старые проблемы LevelDB.
• LMDB/OSM Express тоже предлагают более лёгкое решение для геопоиска.
• Многие считают, что 95 % задач решаются обычным Postgres/SQLite, а «заменить ES» сейчас модный лозунг.