DuckDB¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: DuckDB 1.4.3, embedded native storage. Проверка источников: 2026-11-02.

1. Архитектура и модель данных¶

FACT. Embedded OLAP engine выполняет SQL внутри процесса приложения; database file не является самостоятельным HA-сервисом. Vectorized execution подходит для batch analytics и локального исследования Parquet. Рассматриваем native DuckDB storage, а не отдельные продукты с распределённым catalog.

flowchart LR
  App[One writer process] --> Engine[Vectorized SQL engine]
  Engine --> Native[Native file and WAL]
  Engine --> Parquet[Parquet files]
  Engine --> Temp[Temporary spill]

2. Физическое хранение и путь записи¶

Persistent database использует колонночные row groups/segments, compression, metadata и WAL до checkpoint. Query execution может spill промежуточные данные на disk, но не все алгоритмы становятся неограниченными по памяти. CHECKPOINT переносит журналируемое состояние в основной файл; копировать активно изменяемый файл без согласованной процедуры backup опасно.

Источники механизма: документация 2, документация 5.

3. Индексы и путь чтения¶

Zone maps отсекают диапазоны данных; физическая сортировка повышает selectivity. ART indexes поддерживают нужные constraints и некоторые point/high-selectivity queries, но не ускоряют любой GROUP BY. При чтении Parquet predicate/projection pushdown уменьшает I/O; отсутствие подходящей статистики или мелкие файлы увеличивают planning/open cost.

Источники механизма: документация 3.

4. Транзакции и consistency guarantees¶

ACID транзакции в native database используют MVCC и optimistic concurrency. В baseline 1.4 несколько потоков одного процесса могут писать; конфликтующие изменения требуют retry. Несколько независимых процессов могут открывать базу read-only при отсутствии writer; автоматическая поддержка нескольких writer processes не предоставляется. Запись внешних файлов и транзакция native table — разные границы.

Источники механизма: документация 1.

5. Репликация, partitioning и sharding¶

Встроенных server replicas, leader election и transparent distributed sharding в 1.4 нет. Parquet partition directories помогают pruning, но не создают согласованный catalog сами по себе. Делить workload по отдельным файлам/процессам можно на уровне приложения с явным lifecycle данных.

Источники механизма: документация 1.

6. Конкурентная запись и конфликты¶

Append из потоков не конфликтует так же, как competing updates одной строки; optimistic conflict завершает одну операцию ошибкой. Нельзя использовать сетевую shared filesystem как способ «добавить HA writers». Для конкурентного operational state нужен серверный coordination/storage layer.

Источники механизма: документация 1.

7. Отказы и восстановление¶

WAL обеспечивает crash recovery native файла; восстановление зависит от целостности файла и журнала. Для аналитики из immutable Parquet часто проще повторить запрос, сохранив input manifest. Backup проверять открытием восстановленной копии и контрольными агрегатами. Потеря локального temp disk может прервать запрос, даже если source data сохранены.

Источники механизма: документация 5.

8. Масштабирование и ограничения¶

Ограничения — RAM, temp disk, cores и I/O одного процесса/хоста. Parallel scan не равен distributed query. Ограничивать memory_limit/threads и размещение temp_directory с учётом соседних workloads. Встраивание в API требует лимитов на размер запроса и concurrency.

9. Performance trade-offs¶

Хорошее соотношение простоты и аналитической мощности для bounded datasets. Частые маленькие OLTP transactions, network serving и global state — другая нагрузка. Сортировка/компрессия уменьшают scan bytes ценой подготовки. Не выводить cost из отсутствия отдельного сервера: оплачиваются compute, RAM, object requests и время обработки.

10. Мониторинг и эксплуатация¶

EXPLAIN ANALYZE, profiling, memory/temp usage и query progress; контролировать версии extensions и external access policy. Фиксировать порядок и schema входных файлов. Обновление binary/database format и extensions проверять на копии данных, сохраняя возможность восстановления.

11. Сценарии FinTech и iGaming¶

INFERENCE. Reconciliation выгрузок ledger, анализ snapshot ставок, расследование fraud на ограниченной выборке. Хранить manifest input и SQL, чтобы воспроизвести расчёт; результат не становится authoritative только из-за SQL constraints в локальной копии.

12. Когда не выбирать¶

Не выбирать embedded 1.4 как общий write endpoint для множества приложений или автоматически отказоустойчивую систему. Не считать чтение случайного набора текущих S3 files единым snapshot без table format/catalog.

13. Вопросы на собеседовании¶

Почему multi-thread не равно multi-process writer? MVCC/координация writers существуют внутри одного процесса выбранного режима.

Заменяет ли ART сортировку для аналитики? Нет; scans, pruning и compression часто важнее point lookup.

Где transaction boundary при COPY TO? Нужно отдельно проверить семантику внешнего side effect; ACID native table не обещает atomic публикацию произвольного набора объектов.

14. Практические SQL/config примеры¶

duckdb.sql выполнен на DuckDB 1.4.3: транзакция, aggregation, Parquet round-trip, checkpoint и reopening файла. Это локальный smoke check, не benchmark и не проверка concurrent writers/crash recovery. Практика: сравнить EXPLAIN ANALYZE на отсортированных и перемешанных данных, сохраняя одинаковый фильтр.

15. Дополнительные источники¶

Политика версий и ограничений: реестр.

Типичные ошибки проектирования¶

Открывать файл из нескольких writer processes; считать external file listing транзакционным snapshot; игнорировать temp disk.

Практические упражнения¶

Запустите snippet на временной базе; проверьте result, rollback и Parquet schema. Затем ограничьте память и наблюдайте temp files.