Глоссарий — DuckDB

Встраиваемая аналитическая OLAP-СУБД с открытым кодом (MIT). Колоночное хранение, векторизованный push-based движок, диалект SQL близкий к PostgreSQL. Работает внутри хост-процесса без сервера. Актуальная stable-версия на май 2026 — 1.5.2, LTS — линия 1.4.x «Andium».

СУБД, которая исполняется прямо внутри процесса приложения (Python, R, Java и т.д.), как библиотека. Нет отдельного процесса-сервера, нет сетевого соединения, нет сериализации при обмене данными. DuckDB и SQLite — in-process; PostgreSQL и MySQL — серверные.

Синоним in-process: база встроена в приложение, поставляется как один бинарник или библиотека без зависимостей. Не требует установки, демона, администрирования. DuckDB — embedded OLAP-движок.

Online Analytical Processing — аналитические нагрузки: сканирование больших объёмов, агрегации, JOIN, оконные функции, отчёты. Противоположность OLTP. DuckDB спроектирован под OLAP: колоночное хранение и векторизация.

Online Transaction Processing — транзакционные нагрузки: частые мелкие INSERT/UPDATE/DELETE отдельных строк, высокая конкурентность записи. Сильная сторона PostgreSQL и SQLite. DuckDB для OLTP не предназначен.

Позиционирование DuckDB: аналитический аналог SQLite. SQLite — стандарт de facto для встраиваемого OLTP; DuckDB занимает ту же нишу «встраиваемой базы без сервера», но для аналитических (OLAP) нагрузок.

Centrum Wiskunde & Informatica — национальный исследовательский институт математики и информатики в Амстердаме. Группа Database Architecture в CWI создала MonetDB, линию X100/Vectorwise и DuckDB.

Компания, отделившаяся от CWI в июле 2021 года. Ведёт разработку DuckDB, нанимает core-команду, разрабатывает DuckLake. Сам DuckDB остаётся под лицензией MIT.

Создатели DuckDB в группе Database Architecture института CWI. Представили проект в demo-статье «DuckDB: an Embeddable Analytical Database» на конференции SIGMOD 2019.

Колоночная аналитическая СУБД, разработанная в CWI — предшественница DuckDB по идеям. На её основе вырос проект MonetDB/X100, где и появилась векторизованная модель исполнения.

Исследовательский движок MonetDB/X100 (CWI, ~2005, работа Peter Boncz), позднее коммерциализированный как Vectorwise. Здесь зародилась векторизованная (vector-at-a-time) модель исполнения, которую унаследовал DuckDB.

Модель исполнения, обрабатывающая данные батчами фиксированного размера (векторами), а не по одной строке. Амортизирует накладные расходы интерпретации, дружелюбна к CPU-кэшам и SIMD. Ядро движка DuckDB.

Модель исполнения, в которой данные (DataChunk) проталкиваются снизу вверх по дереву операторов от source к sink. Противоположность pull/Volcano-модели, где верхний оператор «вытягивает» строки итератором. DuckDB использует push-based.

Колоночный массив значений одного типа — базовая единица данных в движке DuckDB. По умолчанию содержит до STANDARD_VECTOR_SIZE (2048) значений. Имеет физический тип (FLAT, CONSTANT, DICTIONARY и др.).

Коллекция векторов — горизонтальный срез строк по нескольким колонкам. Все векторы внутри DataChunk имеют одинаковую мощность (cardinality). Это батч, который проталкивается между операторами.

Размер вектора по умолчанию — 2048 значений. Выбран так, чтобы вектор помещался в кэши L1/L2 процессора, давал работать SIMD и амортизировал стоимость интерпретации по батчу. Все операторы оптимизированы под этот размер.

Физический тип вектора: плотный обычный массив значений в памяти. Самое прямое представление, к нему приводятся остальные типы при необходимости через unified vector format.

Физический тип вектора: хранит ровно одно значение, логически повторённое на весь батч. Экономит память и вычисления для констант и колонок с одним значением в текущем DataChunk.

Физический тип вектора: selection vector с индексами в дочерний вектор. Позволяет ленивую материализацию — например, slice или фильтр возвращают DICTIONARY-вектор без копирования данных.

Физический тип вектора: хранит только начало и шаг (start + increment), не материализуя значения. Эффективен для последовательностей вроде rowid или range без расхода памяти.

Физический тип вектора, хранящий строки в сжатом виде FSST. Позволяет операторам работать со сжатыми строками без полной распаковки, что ускоряет обработку текстовых колонок.

Массив индексов, отображающий логические позиции строк на физические позиции в векторе. Фильтры и JOIN формируют selection vector вместо копирования данных — отброшенные строки просто не индексируются.

Битовая маска: один бит на значение вектора, отмечающий, является ли значение NULL. Отделяет NULL-логику от самих данных и позволяет быстро проверять валидность блоками.

Каноническое представление вектора, через которое операторы единообразно читают вектор любого физического типа (FLAT, CONSTANT, DICTIONARY и т.д.), не разветвляя код под каждый тип.

Первая стадия конвейера запроса: превращает текст SQL в дерево разбора (токены и узлы). Не знает о каталоге, не резолвит таблицы и типы. В DuckDB 1.5 появился экспериментальный PEG-parser.

Стадия конвейера запроса после parser: резолвит имена таблиц и колонок по каталогу, определяет типы выражений, проверяет корректность. Именно binder подключает replacement scans.

Дерево логических операторов (LogicalOperator), построенное после binder. Описывает, ЧТО нужно вычислить, без выбора конкретных алгоритмов. Вход для оптимизатора.

Дерево физических операторов (PhysicalOperator) — результат работы physical planner. Описывает, КАК исполнять запрос: конкретные алгоритмы сканирования, JOIN, агрегации. Исполняется векторизованно.

Линейный участок плана исполнения: source — цепочка операторов — sink. План разбивается на пайплайны; только source и sink должны знать о параллелизме. Единица морсель-параллелизма.

Оператор, который должен полностью получить вход, прежде чем выдавать выход: build-сторона hash join, сортировка, агрегация. Разрывает пайплайн и требует синхронизации потоков.

Модель параллелизма DuckDB: входные данные нарезаются на небольшие порции (морсели), диспетчер раздаёт их рабочим потокам. Потоки исполняют операторы независимо, синхронизируясь только на pipeline breakers. Хорошо подходит для NUMA и work-stealing.

Небольшая порция входных данных (диапазон строк/байтов), которую диспетчер выдаёт рабочему потоку. Размер порции по сканированию связан с PARTIAL_CHUNK_COUNT = 50 × 2048 строк.

Колоночное хранение: значения одной колонки лежат подряд, а не строками. Даёт чтение только нужных колонок (projection pushdown), эффективное сжатие однотипных данных и SIMD-обработку. Базовый принцип DuckDB.

Однофайловый формат хранения персистентной базы DuckDB: заголовок, блоки, метаданные, row groups, колоночные сегменты с zonemap-статистикой. Версионируется числом storage version.

Сигнатура файла базы DuckDB — четыре байта `DUCK` в заголовке. Идут после uint64-контрольной суммы, перед uint64-номером storage version. Позволяют опознать файл как базу DuckDB.

Единица хранения и I/O в файле базы DuckDB, по умолчанию 256 KiB. Файл состоит из блоков; есть free list (список свободных блоков) и блоки метаданных.

Горизонтальный сегмент таблицы — по умолчанию около 122 880 строк (60 векторов × 2048). Внутри row group каждая колонка хранится отдельным сжатым сегментом. Размер настраивается через ROW_GROUP_SIZE при ATTACH.

Хранилище одной колонки в пределах одного row group — сжатый блок данных со своей схемой компрессии. Несёт zonemap-статистику (min/max) для пропуска при фильтрации.

Мини-статистика по сегменту (минимум и максимум значений). Позволяет оптимизатору и сканеру пропускать целые row groups и сегменты, если фильтр заведомо не пройдёт. Также называют min/max-индексом.

Write-Ahead Log — журнал упреждающей записи. Изменения сначала пишутся в WAL для долговечности, затем при checkpoint сливаются в основной файл. Обеспечивает durability транзакций.

Операция слияния WAL в основной файл базы. В DuckDB 1.5 появился non-blocking checkpoint — чтения и записи могут идти конкурентно во время checkpoint (около +17% пропускной способности на TPC-H SF100).

Числовая версия формата хранения. v68 соответствует 1.5.x, v67 — 1.4.x, v66 — 1.3.x, v65 — 1.2.x, v64 — линии 0.9.x–1.1.x. Записана в заголовке файла после magic bytes.

Гарантия, что новая версия DuckDB читает файлы, созданные старыми версиями. Обеспечивается начиная с v0.10 (storage version 64). Forward-совместимость (старый движок читает новый файл) — best-effort.

Параметр, позволяющий записать файл в формате, совместимом со старыми версиями DuckDB: `ATTACH 'file.db' (STORAGE_VERSION 'v1.2.0')` или `'latest'`. Есть и флаг CLI `-storage-version` (с 1.2.0).

Run-Length Encoding — сжатие последовательностей одинаковых значений в пары (значение, количество). Эффективно на отсортированных, партиционированных и NULL-насыщенных колонках.

Схема сжатия целых: отбрасываются ведущие нулевые биты, для каждых 1024 значений выбирается минимальная битовая ширина по максимуму. BIGINT может занять место INTEGER или меньше.

FOR — схема сжатия: значения хранятся как смещения от минимума («рамки») сегмента. Особенно хороша для дат и timestamp, которые хранятся как Unix-смещения. Часто комбинируется с bit packing.

Схема сжатия: уникальные значения выносятся в словарь, в данных хранятся числовые ссылки на него. Эффективна для текста с повторами и категориальных колонок.

Fast Static Symbol Table — схема сжатия строк, расширяющая dictionary: извлекает повторяющиеся подстроки внутри строк в таблицу символов. Хороша для URL, email, структурированного текста.

Схема сжатия чисел с плавающей точкой на основе алгоритма Gorilla: XOR соседних значений и использование ведущих/хвостовых нулевых битов. Коэффициент сжатия около 2.4×.

Схема сжатия чисел с плавающей точкой, развитие идеи Gorilla/Chimp, оптимизированная под скорость декомпрессии. Коэффициент сжатия около 2.1×.

Adaptive Lossless floating-Point — более новая схема сжатия чисел с плавающей точкой. Средний коэффициент около 4.3× против ~2.1× (Patas) и ~2.4× (Chimp).

Двухпроходный механизм выбора сжатия в DuckDB: фаза analyze сканирует сегмент и подбирает лучшую схему, фаза compress записывает данные блоками фиксированного размера. Дёшево, потому что сегмент помещается в кэш CPU.

Набор расширений диалекта DuckDB, делающих SQL короче и удобнее: FROM-first, SELECT * EXCLUDE/REPLACE, COLUMNS, GROUP BY ALL, QUALIFY, list comprehensions, trailing commas, prefix-алиасы и др.

Возможность писать FROM перед SELECT: `FROM tbl SELECT ...`. Можно вообще опустить SELECT — `FROM tbl` равнозначно `SELECT * FROM tbl`. Часть friendly SQL.

Конструкция friendly SQL: `SELECT * EXCLUDE (col1, col2)` выбирает все колонки, кроме перечисленных. Избавляет от ручного перечисления десятков колонок.

Конструкция friendly SQL: `SELECT * REPLACE (expr AS col)` выбирает все колонки, но заменяет одну выражением. Удобно для преобразования отдельной колонки без перечисления остальных.

Выражение DuckDB `COLUMNS(...)`, применяющее операцию сразу к множеству колонок по regex, списку, EXCLUDE/REPLACE или lambda. Например, `SELECT COLUMNS('sales_.*') * 1.1`.

Конструкция friendly SQL: `GROUP BY ALL` автоматически выводит группирующие колонки из неагрегатных элементов SELECT. Аналогично есть `ORDER BY ALL`.

Конструкция SQL для фильтрации по результату оконных функций — то же, что WHERE, но для window-функций. Избавляет от обёртки в подзапрос/CTE: `... QUALIFY row_number() OVER (...) = 1`.

Оператор DuckDB для перевода строк в колонки (и UNPIVOT — обратно). Часть friendly SQL; поддерживает автоматический вывод значений-колонок. Рядом — GROUPING SETS, CUBE, ROLLUP.

JOIN по ближайшему ключу (по условию <= или >=), а не по равенству. Предназначен для временных рядов: например, сопоставить котировку с ближайшим по времени курсом.

Механизм DuckDB, позволяющий запросить объект, которого нет в каталоге, по имени. Так Pandas/Polars/PyArrow DataFrame из локальной области видимости становится таблицей в SQL без явной регистрации. Подключается в binder.

Вложенный тип DuckDB: запись с именованными полями фиксированной схемы. Доступ к полям через точку: `s.field`. Хранится поколоночно по полям.

Вложенный тип DuckDB: упорядоченная последовательность значений одного типа переменной длины. Поддерживает slicing, list comprehensions и lambda-функции.

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

Вложенный тип DuckDB: размеченное объединение (tagged union) нескольких типов — значение может быть одним из перечисленных вариантов с тегом, указывающим текущий.

Тип DuckDB для категориальных данных: фиксированный набор строковых значений, хранимый со словарной (dictionary) семантикой — компактно и быстро для сравнения.

Полуструктурированный бинарный тип, появившийся в DuckDB 1.5. Хранит типизированные бинарные данные, поддерживает больше типов, чем JSON (DATE, TIMESTAMP), и Parquet-shredding. Функции: variant_typeof(), variant_extract().

Пространственный тип, ставший core-типом в DuckDB 1.5 (раньше жил в расширении spatial). Хранится как little-endian WKB; shredding даёт около 3× сжатия на однородных колонках; есть bounding-box статистика по row group.

Система типов DuckDB: примитивы (целые, DECIMAL, REAL/DOUBLE, VARCHAR, BLOB, BOOLEAN, UUID), дата/время (DATE, TIME, TIMESTAMP, TIMESTAMPTZ, INTERVAL), вложенные (STRUCT, LIST, MAP, UNION), ENUM, VARIANT, GEOMETRY.

Табличная функция DuckDB для чтения Parquet-файлов (алиас parquet_scan). Поддерживает globs, projection и filter pushdown. Можно и короче: `SELECT * FROM 'file.parquet'`.

Табличная функция DuckDB для чтения CSV. Опирается на CSV-sniffer для автоопределения диалекта, типов и заголовка. Параметры: sample_size, delim, header, columns и др.

Механизм автоопределения CSV в DuckDB, работающий в три фазы: dialect detection (разделитель, кавычки, экранирование — выбор самого консистентного варианта), type detection (подбор типов колонок), header detection. По умолчанию анализирует 20 480 строк.

Расширение DuckDB — файловая система для чтения и записи удалённых файлов: S3, GCS, Azure, HTTP/HTTPS. Автозагружаемое. Учётные данные задаются через механизм secrets.

Подключаемый модуль, расширяющий DuckDB новыми функциями, типами, форматами и сканерами. Управляется командами INSTALL и LOAD. Делятся на core и community.

Автоматическая установка и загрузка core-расширения при первом использовании в запросе — например, httpfs или parquet. Не все расширения автозагружаемы: spatial требует явных INSTALL/LOAD.

Core-расширения (httpfs, iceberg, delta, ducklake, postgres, spatial, fts, vss и др.) поддерживаются командой DuckDB и распространяются официально. Community-расширения — сторонние, лежат в отдельном репозитории.

Atomicity, Consistency, Isolation, Durability — свойства надёжных транзакций. DuckDB полностью ACID-совместим: транзакции атомарны, изолированы (snapshot isolation) и долговечны (WAL).

Multi-Version Concurrency Control — управление конкурентностью через версии. DuckDB хранит версии строк, чтобы читатели видели согласованный snapshot, не блокируя писателя.

Уровень изоляции транзакций: каждая транзакция видит согласованный снимок базы на момент своего старта. Реализуется через MVCC; уровень изоляции DuckDB по умолчанию.

Подсистема DuckDB, управляющая оперативной памятью под буферы, векторы и промежуточные структуры. При превышении memory_limit вытесняет данные на диск (spilling).

Конфигурационный параметр, ограничивающий объём оперативной памяти, который DuckDB использует под буферы. При его превышении операторы спиллят данные в temp_directory. Задаётся через SET.

Способность DuckDB обрабатывать датасеты больше доступной RAM за счёт спиллинга на диск (out-of-core). External hash aggregation, external hash join и external sort позволяют завершать тяжёлые запросы на ограниченной памяти.

Out-of-core агрегация (с v0.9): группы партиционируются, партиции спиллятся на диск, на втором проходе подгружаются обратно. Позволила выполнить все запросы на 50 ГБ датасете на ноутбуке с 16 ГБ RAM.

Out-of-core hash join: обе стороны партиционируются по ключу, партиции спиллятся на диск и обрабатываются по очереди партиция-за-партицией. Позволяет соединять таблицы больше RAM.

Out-of-core сортировка: k-way merge sort (полностью переписан в DuckDB 1.4), адаптивный к уже частично отсортированным данным. Спиллит промежуточные runs на диск.

Конфигурационный параметр — каталог, куда DuckDB спиллит данные при нехватке памяти. По умолчанию `<db>.tmp` для персистентной базы или `.tmp` для in-memory.

Оптимизатор запросов DuckDB: rule-based + cost-based. Проходы включают constant folding, filter pushdown, join order optimization, common subexpression extraction. Использует статистику и zonemap.

Алгоритм оптимизации порядка соединений (join order) в DuckDB — динамическое программирование по связным подграфам (Dynamic Programming connected subgraph). Опирается на статистику таблиц и колонок.

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

Оптимизация: предикаты фильтрации проталкиваются как можно ближе к источнику данных. Для Parquet и колоночных сегментов это превращается в пропуск целых row groups по zonemap.

Оптимизация: из источника читаются только те колонки, которые реально нужны запросу. Колоночное хранение и Parquet делают этот пропуск практически бесплатным.

SQL-оператор, появившийся в DuckDB 1.4: альтернатива `INSERT ... ON CONFLICT`. Не требует первичного ключа, работает по произвольному условию слияния. Применяется для upsert и инкрементальных обновлений.

Шифрование базы, появившееся в DuckDB 1.4: AES с 256-битным ключом, по умолчанию режим GCM. Покрывает основной файл базы, WAL и temp-файлы. Использует встроенный mbedtls или OpenSSL (через httpfs).

SQL-команда DuckDB для импорта и экспорта данных: экспорт результата в Parquet/CSV/JSON, импорт из файлов. Поддерживает PARTITION_BY для записи в Hive-layout.

Команда логического дампа всей базы в каталог: данные в Parquet/CSV плюс SQL-схема. Парная команда IMPORT DATABASE восстанавливает базу. Переносимо между версиями DuckDB.

Сборка DuckDB в WebAssembly: полноценный движок исполняется прямо в браузере, без сервера. Поддерживает персистентность через OPFS (пути opfs://).

Origin Private File System — приватная файловая система браузера. DuckDB-WASM использует OPFS для персистентности: состояние базы переживает перезагрузку вкладки. Параметр checkpoint_threshold='0KB' включает автосохранение.

Управляемый облачный сервис на основе DuckDB. Ключевая идея — dual execution: оптимизатор решает для каждого запроса, какие части исполнить локально на клиенте, а какие — в облаке.

Гибридное исполнение запроса MotherDuck: части плана выполняются локально на клиенте, части — удалённо в облаке. Оптимизатор выбирает раскладку так, чтобы минимизировать перемещение данных.

Открытый lakehouse-формат от DuckDB Labs (версия v1.0 — production-ready, апрель 2026). Данные лежат в Parquet на object storage, а ВСЕ метаданные — в реляционной SQL-базе-каталоге. Эталонная реализация — расширение ducklake.

SQL-база, хранящая метаданные DuckLake. Поддерживаются SQLite (встраиваемый, single-writer), PostgreSQL (сетевой, настоящий multi-writer) и DuckDB (self-contained lakehouse). Бэкенд должен уметь SQL, primary keys и хранить таблицы.

Механизм DuckLake: мелкие изменения (по умолчанию до 10 строк, DATA_INLINING_ROW_LIMIT) хранятся прямо в метаданных каталога, а не в крохотных Parquet-файлах. Решает проблему small files; CHECKPOINT выгружает их в Parquet.

Способ пометить удалённые строки без перезаписи файла данных: roaring-bitmap в Puffin-файле, отмечающий удалённые позиции. DuckLake использует deletion vectors в стиле Iceberg v3.

Программный интерфейс DuckDB для построения запросов цепочкой методов (.filter(), .aggregate(), .project() и т.д.) вместо текста SQL. Доступен, в частности, в Python-клиенте.

Обмен данными без копирования. DuckDB обменивается DataFrame'ами с Python data-стеком через Apache Arrow, разделяя буферы памяти напрямую — без сериализации и дублирования.

Кросс-языковой колоночный in-memory формат данных. Служит zero-copy мостом между DuckDB и Pandas/Polars/PyArrow: данные передаются разделяемыми буферами без копирования.

Основной клиент DuckDB — библиотека для Python: connect, execute, fetch результата в .df()/.arrow()/.pl(). Ставится `pip install duckdb`; CLI с версии 1.5 ставится отдельно — `pip install duckdb-cli`.

Команды DuckDB для подключения и отключения дополнительных баз в текущей сессии. Позволяют работать с несколькими файлами баз (и каталогами вроде DuckLake) одновременно, обращаясь к ним по имени.

Команды для просмотра плана запроса. EXPLAIN показывает физический план; EXPLAIN ANALYZE исполняет запрос и добавляет фактические тайминги и количество строк по операторам — главный инструмент диагностики.

Соглашение об организации файлов по каталогам вида `col=value/`. DuckDB автоматически распознаёт такую структуру, извлекает партиционные колонки из путей и применяет partition pruning.

Оптимизация чтения партиционированных датасетов: по фильтру на партиционную колонку DuckDB пропускает целые каталоги/файлы, не читая их. Работает для Hive-партиционированных Parquet.

Опция чтения нескольких файлов с различающимися схемами: колонки сопоставляются по имени, а не по позиции, недостающие заполняются NULL. Полезно при эволюции схемы между файлами.

Стандартный бенчмарк для аналитических СУБД (наряду с TPC-DS). DuckDB поставляет расширения tpch и tpcds для генерации данных и эталонных запросов. Используется для замеров производительности.

LTS-релиз DuckDB: 1.4.0 вышел 16 сентября 2025, последний патч линии — 1.4.4 (26 января 2026). Community-поддержка LTS — до 16 сентября 2026. С 1.4 каждый второй релиз делается LTS.

Feature-релиз DuckDB: 1.5.0 вышел 9 марта 2026, актуальный stable на май 2026 — 1.5.2 (13 апреля 2026). Принёс тип VARIANT, GEOMETRY как core-тип, friendly CLI, non-blocking checkpoint, read_duckdb.