Назад
Огляд DuckDB v2.0: серверний режим, тригери та новий формат зберігання
SiTech AI Team3 წთ. საკითხავი

Огляд DuckDB v2.0: серверний режим, тригери та новий формат зберігання

Аналітична база даних отримає режим клієнт-сервер, повну підтримку тригерів, тип VARIANT як повноцінний елемент і асинхронний ввід-вивід. Версія 2.0 під назвою Cyanoptera вийде цієї осені.

DuckDB опублікувала огляд версії 2.0 — наступного великого випуску аналітичної бази даних, що працює в процесі. Реліз очікується цієї осені й отримає назву Cyanoptera, на честь коричної чирки. Він включає понад 10 000 комітів після v1.5, що вийшла в березні, і сам проєкт називає його початком «року DuckDB як сервера».

Нарешті серверний режим

Головна зміна — підтримка клієнт-серверної роботи. Розширення quack, показане в травні, реалізує власний протокол DuckDB і стає стабільним у v2.0: будь-який процес DuckDB може віддавати свої бази в мережу, а інший DuckDB під'єднується до нього й спрямовує туди запити новим оператором CONNECT. CONNECT не обмежується DuckDB: націлений на сервер PostgreSQL або MySQL, він надсилає SQL безпосередньо віддаленій системі замість перетягування таблиць мережею — через новий оптимізатор remote pushdown. Команда зазначає, що DuckDB від початку була транзакційною базою з повним MVCC, і перевага цього тепер проявляється в багатокористувацьких, довготривалих розгортаннях. З тієї ж причини переробили метрики та логування.

VARIANT, тригери та доповнення SQL

Тип VARIANT, представлений у v1.5, стає повноцінним: роздільне зберігання («shredding») працює безпосередньо зі сховища, вилучення передається у сканування, читання й запис Parquet його підтримують, додається родина функцій variant_*. Розробники планують незабаром після релізу підвести під VARIANT і звичайний тип JSON, тож наявні JSON-навантаження отримають ті самі переваги без зміни запитів.

Тригери з'являються повністю: BEFORE і AFTER, FOR EACH ROW і FOR EACH STATEMENT, таблиці переходів через REFERENCING OLD/NEW TABLE, кілька тригерів на одну подію, RETURNING і DROP TRIGGER. Класичний сценарій — таблиця аудиту, що фіксує зміни.

Діалект SQL отримує top-k пошук схожості як умову join (APPROX NEAREST — для векторних навантажень), DML усередині CTE, вкладені схеми, синтаксис $variable, функції зміни JSON на кшталт json_set і рекурсивні CTE з агрегацією USING KEY.

Швидший ввід-вивід, швидші запити, підписані розширення

Асинхронний ввід-вивід тепер працює в усьому рушії, тож рівень вводу-виводу масштабується незалежно від обробки запитів: спершу Parquet, далі CSV і власний формат DuckDB, а також нові режими MMAP і DIRECT_IO. Найбільший виграш — на мережевих сховищах. На боці запитів часткові агрегати просуваються під join, рушій рекурсивних CTE переписали, агрегації скидаються на диск, коли не вміщуються в пам'ять, а Windows CLI став приблизно у 2,2 раза швидшим на багатопотоковій матеріалізації результатів.

Розширення отримують перероблений стабільний C API і, поки що в розробці, репозиторії, які реєструють самі користувачі: вони поширюють підписані RSA розширення, а під час реєстрації друкуються SHA-256 відбитки кожного ключа. Восени DuckDB Foundation додасть наглядову раду зацікавлених сторін, яка даватиме поради щодо розвитку DuckDB, DuckLake і Quack. Попередні збірки вже містять більшість цих можливостей, хоча команда попереджає, що деталі можуть змінитися до осіннього релізу.

SSiTech

SiTech — веброзробка з підтримкою AI

Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.