Apache Doris 4.1: векторний пошук, зберігання у форматі JSON, OLAP та Lakehouse
Огляд нововведень Apache Doris 4.1: векторні індекси IVF, функція пошуку BM25(), документи JSON об’ємом 100 МБ, версія Segment V3, кешування запитів, запис у форматі Iceberg, оператори MERGE INTO та TIMESTAMPTZ.
Джерела: Apache Doris 4.1: Unified Storage and Retrieval for AI & Search
Apache Doris 4.1 продовжує традиції версії 4.0, яка ввела у проект функції векторного пошуку, гібридного пошуку та функцію search(), щоб дозволити йому обслуговувати AI-агентів, системи типу RAG, забезпечувати можливості моніторингу AI та аналітику в реальному часі. Версія 4.1 рухається в тому ж напрямку та має на меті зробити один двигун відповідальним як за зберігання, так і за пошук даних для завдань AI та пошуку. У примітках до випуску наголошується на проблемах, з якими стикаються команди під час впровадження AI-застосунків у промислове використання:
- збереження доступної вартості зберігання великих обсягів даних AI,
- об’єднання векторного пошуку, пошуку повного тексту та структурованих фільтрів у одній системі,
- зберігання довгих документів та великих напівструктурованих записів у одній таблиці,
- відповідь на запити в реальному часі та задачі моніторингу для LLM, агентів та систем типу RAG,
- збереження швидкості обробки даних у стилі OLAP та lakehouse, за якою відомий проект, та
Основні нововведення такі:
- Пошук за векторами: нові індекси IVF та IVF_ON_DISK, призначені для колекцій обсягом у мільярди елементів та більше.
- Пошук повного тексту: функція
search()отримала систему оцінювання BM25 та синтаксис, сумісний з Elasticsearch. - Зберігання довгих контекстів: один JSON-документ тепер може мати обсяг до 100 МБ, що призначено для використання як пам’ять агента та для роботи з довгими контекстами.
- Швидкість OLAP: проект повідомляє про покращення на 22,6% у тесті TPC-H, 19,1% у тесті TPC-DS та 14,3% у тесті SSB; крім того, досягнуто першого місця у тестах на холодні запити в ClickBench.
- Дата-лейк: можливість читання та запису даних у форматах Apache Iceberg V2/V3, створення DDL для Apache Paimon через SQL, а також кешування сторінок у форматі Parquet, що забезпечує економію приблизно 20%.
- Розділення обчислень та зберігання: режим, який, за словами проекту, використовується більш ніж у 2 000 компаніях, з кращою видимістю кешу, еластичністю та поведінкою під час виконання запитів до «холодних» даних.
Усі наведені нижче показники продуктивності походять з офіційного оголошення проекту, тому сприймайте їх як дані, надані виробником, та перевіряйте їх за допомогою власних даних.
1. Штучний інтелект та пошук
Векторний пошук
IVF приєднується до HNSW. У версії 4.0 як векторний індекс був запропонований HNSW. У версії 4.1 додано IVF (inverted file) для більших наборів даних. Ідея полягає у тому, щоб заздалегідь групувати вектори у бакети, а потім шукати лише всередині тих бакетів, які найімовірніше містять сусідні вектори, жертвуючи певною точністю заради значного прискорення. Порівняно з HNSW, IVF дозволяє обробляти більші колекції за менше місця в пам’яті, але з дещо нижчою точністю пошуку. Щоб увімкнути цей режим, необхідно встановити "index_type"="ivf" у властивостях індексу:
CREATE TABLE sift_1M (
id int NOT NULL,
embedding array<float> NOT NULL COMMENT "",
INDEX ann_index (embedding) USING ANN PROPERTIES(
"index_type"="ivf",
"metric_type"="l2_distance",
"dim"="128",
"nlist"="1024"
)
) ENGINE=OLAP
DUPLICATE KEY(id) COMMENT "OLAP"
DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES (
"replication_num" = "1"
);
IVF_ON_DISK. Бібліотеки на кшталт Faiss ефективно працюють з десятками мільйонів векторів, оскільки зберігають весь індекс у оперативній пам’яті. Однак при кількості векторів у десятки мільярдів витрати на пам’ять різко зростають. Doris створила IVF_ON_DISK на основі IVF, слідуючи підходу досліджень SPANN від Microsoft, та поєднує кеш у оперативній пам’яті з кешем локальної файлової системи для ефективного та недорогого відбору векторів.
- Завдяки розділенню обчислень та зберігання це дозволяє здійснювати швидкий та недорогий відбір та пошук у дуже великих масштабах.
- Порівняно з DiskANN, створення індексу коштує значно менше, що робить його реалістичним варіантом для пошуку у масштабах трильйонів елементів.
- Ймовірно використовується у базах знань штучного інтелекту, системах рекомендацій та великих сховищах ембеддингів.
Перехід на цей підхід майже такий самий, як використання IVF, з параметром "index_type"="ivf_on_disk":
CREATE TABLE for_ivf_on_disk (
id BIGINT NOT NULL,
embedding ARRAY<FLOAT> NOT NULL,
INDEX idx_emb (embedding) USING ANN PROPERTIES (
"index_type"="ivf_on_disk",
"metric_type"="l2_distance",
"dim"="128",
"nlist"="1024"
)
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 8
PROPERTIES ("replication_num" = "1");
Квантування. Окрім алгоритму індексації підтримуються три методи квантування: скалярне INT8, скалярне INT4 та квантування добутком (PQ). Щоб трохи зменшити втрати при поверненні даних, вони скорочують розмір індексу до рівня від чверті до восьмої частини його початкової пам’яті, а у поєднанні з IVF_ON_DISK ще більше знижують витрати на обладнання для великих систем пошуку. Наведений нижче DDL демонструє компресію за допомогою PQ для 128-вимірних векторів:
CREATE TABLE product_quant (
id BIGINT NOT NULL,
embedding ARRAY<FLOAT> NOT NULL,
INDEX idx_emb (embedding) USING ANN PROPERTIES (
"index_type"="ivf_on_disk",
"metric_type"="l2_distance",
"dim"="128",
"nlist"="1024",
"quantizer"="pq",
"pq_m"=64,
"pq_nbits"=8
)
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 8
PROPERTIES ("replication_num" = "1");
Швидші запити. Нова оптимізація „Ann Index Only Scan“ дозволяє векторним запитам оминати операції вводу-виводу з диска над сирими стовпцями, що значно зменшує накладні витрати. За твердженням розробників, векторні запити до індексу працюють у чотири рази швидше, ніж у версії 4.0. У тестах з мільйоном векторів на пристрої з 16 ядрами та 64 ГБ пам’яті Doris досягає приблизно 900 запитів на секунду з рівнем відтворення даних 97%, що достатньо для більшості задач пошуку в продакшені.
У оголошенні також наводяться публічні дані VectorDBBench (станом на січень 2026 року), згідно з якими Doris створює векторні індекси швидше, ніж Milvus, Qdrant та pgvector, завдяки своїй архітектурі шарування даних. У версії 4.1 вектори обробляються пакетно в пам’яті під час створення, а індекс будується пакетами, що підвищує паралелізм без погіршення якості індексу.
Функція search()
Де векторний пошук забезпечує семантичне відтворення результатів, там як повнотекстовий пошук використовується для пошуку ключових слів, усунення проблем, пошуку в журналах та аналізу тексту. Нова функція search() інтегрує це в SQL, щоб один запит міг одночасно фільтрувати та агрегувати дані.
- Вона підтримує синтаксис
query_stringElasticsearch, що має полегшити перехід від Elasticsearch. - Оператори включають TERM, PHRASE, WILDCARD, REGEXP, PREFIX, NOT та NESTED; усі вони можуть бути вкладеними та поєднаними між собою.
- Вбудована оцінка релевантності BM25 з оптимізацією TopN на рівні зберігання, щоб усі набори результатів не передавалися повністю.
- У поєднанні з типом VARIANT функція
NESTEDможе аналізувати вкладені масиви JSON.
best_fields (точна збіг у одному полі) та cross_fields (збіг, що охоплює кілька полів).Типовий запит виглядає так:
-- Multi-condition: TERM + PHRASE + NOT evaluated in a single pass
SELECT request_id, error_msg, latency_ms
FROM inference_logs
WHERE search('
level:ERROR
AND error_msg:"CUDA out of memory"
AND NOT module:healthcheck
AND model_name:gpt*
')
AND log_time > NOW() - INTERVAL 1 HOUR
ORDER BY latency_ms DESC LIMIT 100;
-- BM25 relevance scoring
SELECT request_id, error_msg, score() AS relevance
FROM inference_logs
WHERE search('error_msg:"memory allocation failed" OR error_msg:"CUDA error"')
ORDER BY relevance DESC LIMIT 20;
-- Nested search: query inside a VARIANT array
SELECT * FROM agent_logs
WHERE search('NESTED(steps, status:error AND tool:code_exec)');
-- search + aggregation: filter and analyze in one query
SELECT model_name, COUNT(*) AS error_count,
PERCENTILE_APPROX(latency_ms, 0.99) AS p99_latency
FROM inference_logs
WHERE search('level:ERROR AND error_msg:"CUDA out of memory"')
AND log_time > NOW() - INTERVAL 1 HOUR
GROUP BY model_name ORDER BY error_count DESC;
search() повертає булеве присудок, тому він може брати участь у об’єднаннях, функціях вікна та підзапитах, що робить пошук повного тексту звичайною частиною SQL.
Документи JSON об’ємом до 100 МБ
Штучні інтелектуальні агенти, технології RAG та багатокрокові додатки з довгим контекстом все частіше хочуть зберігати довгий контекст взаємодії в одному місці. Doris 4.1 підтримує окремі рядки, які містять документи JSON об’ємом до 100 МБ, тож усі дані сесії можуть зберігатися в базі даних: багатокрокові розмови, довгі тексти, транскрипції аудіо та відео, записи роботи агентів, журнали викликів інструментів та контекст, який використовується для RAG. Не потрібно нічого розділяти, скорочувати чи переміщувати до зовнішнього зберігання. Після запису ці документи поводяться як інші дані — працюють фільтрація, умовні запити, агрегація та об’єднання, тож об’ємний контекст ШІ стає структурованим ресурсом, який можна шукати.
Згідно з проектом, зберігання великих JSON-даних у такий спосіб дозволяє командам:
- позбутися залежності від окремого сховища об’єктів,
- уникнути логіки, яка підтримує консистентність метаданих та первинного контенту,
- пропустити процес часткового зберігання та їх повторної об’єднання, а також
- отримати меншу затримку запитів, сильніші гарантії транзакцій та простіші операції.
Segment V3 та широкі таблиці
Завдання пошуку та штучного інтелекту зазвичай генерують широкі, розріджені, напівструктуровані дані з багатьма полями, змінюваними схемами та чіткими моделями доступу до „гарячих“ та „холодних“ даних. Вони потребують ефективних випадкових читань, точкового пошуку та інтенсивних одночасних записів.
До версії 4.1 Doris використовував формат Segment V2, який зберігає метадані у футері файлу. Це підходить для пакетного сканування, але випадкові читання та запити на невеликі діапазони змушують щоразу завантажувати весь футер, що збільшує навантаження на диск та витрати на обробку.
Сегмент V3, під впливом новіших форматів на кшталт Lance та Vortex, відокремлює метадані від нижньої частини сторінки та завантажує їх за потреби. Він спрямований на боротьбу з надмірним обсягом метаданих, повільним відкриттям файлів та високими витратами на випадкове читання. Кандидатами на використання цього формату є таблиці з великою кількістю стовпців, таблиці, наповнені підстовпцями типу VARIANT, ситуації, коли затримка під час початкового завантаження даних у об’єктному сховищі є проблемою, а також напівструктуровані дані для штучного інтелекту чи телематики транспортних засобів, які часто читаються випадковим чином. У таблиці з 7 000 стовпцями та 10 000 сегментами V3, за повідомленнями, забезпечує відкриття до 16 разів швидше та використовує до 60 разів менше пам’яті. Щоб увімкнути цей режим, встановіть "storage_format" = "V3" у властивостях таблиці:
CREATE TABLE table_v3 (
id BIGINT,
data VARIANT
)
DISTRIBUTED BY HASH(id) BUCKETS 32
PROPERTIES (
"storage_format" = "V3"
);
Розріджені стовпці
У великих JSON-даних зазвичай є довгий „хвіст“ рідко використовуваних шляхів та кілька активних. Doris 4.1 переробляє механізм читання розріджених даних так, щоб цей „хвіст“ не ставав перешкодою для одного конкретного розрідженого стовпця.
- Розділення активних та неактивних шляхів: часто використовувані шляхи залишаються у вигляді підстовпців, а шляхи з довгим „хвостом“ переміщуються у розріджене зберігання, що запобігає множенню підстовпців.
- Розріджене шардингування: параметр
variant_sparse_hash_shard_countрозподіляє шляхи з довгим „хвостом“ між кількома розрідженими стовпцями, зменшуючи навантаження на будь-який з них під час читання. - Розріджена кеш-пам’ять: кеш для розріджених стовпців зменшує кількість повторних операцій з диском, а також процеси декодування та десеріалізації.
Це підходить для великих JSON-даних з телематики транспортних засобів, профілів користувачів та журналів подій — у будь-яких випадках, коли запис має багато полів, але лише кілька десятків чи кілька сотень шляхів піддаються частим запитам:
CREATE TABLE user_feature_wide (
uid BIGINT,
features VARIANT<
'user_id' : BIGINT,
'region' : STRING,
properties(
'variant_max_subcolumns_count' = '2048',
'variant_sparse_hash_shard_count' = '32'
)
>
)
DUPLICATE KEY(uid)
DISTRIBUTED BY HASH(uid) BUCKETS 32
PROPERTIES (
"storage_format" = "V3"
);
Режим DOC
Якщо пріоритетом є ефективність запису чи отримання цілих JSON-документів, режим DOC є кращим вибором. Він зберігає необроблений JSON під час запису та відкладає видобуток підрозділів даних до моменту стиснення, що знижує витрати на запис та ефект посилення даних під час запису.
- Відкладена матеріалізація: необроблений JSON зберігається під час запису, що зменшує навантаження для невеликих пакетів даних.
- Шардування DOC: параметр
variant_doc_hash_shard_countділить сховище Doc на кілька шардів, що полегшує як читання цілих документів, так і видобуток конкретних елементів. - Поріг: параметр
variant_doc_materialization_min_rowsвизначає межу, після якої починається матеріалізація; пакети, які менші за цю межу, чекають до моменту стиснення.
Він орієнтований на результати роботи LLM, дані трасування, знімки контексту та повторну відтворення подій — завдання, які часто повертають цілі документи. Щоб налаштувати його, увімкніть variant_enable_doc_mode, а потім налаштуйте поріг та кількість шардів відповідно до обсягу ваших даних. Режим DOC та розріджені стовпці виключають один одного, тому оберіть один з них та поєднайте його з storage_format = „V3“:
CREATE TABLE trace_archive (
ts DATETIME,
trace_id STRING,
span VARIANT<
'service_name' : STRING,
properties(
'variant_enable_doc_mode' = 'true',
'variant_doc_materialization_min_rows' = '100000',
'variant_doc_hash_shard_count' = '32'
)
>
)
DUPLICATE KEY(ts, trace_id)
DISTRIBUTED BY HASH(trace_id) BUCKETS 32
PROPERTIES (
"storage_format" = "V3"
);
2. Швидший OLAP
Doris здобула свою популярність завдяки швидкому, реальночасному OLAP, і версія 4.1 продовжує працювати над цим, скорочуючи зайві обчислення, передаючи менше даних та ефективніше їх обробляючи, щоб складні запити залишалися швидкими навіть при реалістичному навантаженні.
Тестування багатотабличних та широких таблиць
У стандартних тестах об’єднання даних та агрегації нова версія показує таке покращення порівняно з 4.0: 22,6% у TPC-H, 19,1% у TPC-DS та 14,3% у SSB.
Для широких таблиць ClickBench використовує 100 ГБ даних та 43 складні запити для перевірки колонкового зберігання, векторизованої обробки та стиснення, що робить його одним із найвимогливіших тестів для однотабличних структур. На інстанціях c7a.metal-48xl проект стверджує, що Doris 4.1 посідає перше місце за швидкістю обробки холодних запитів та за економією простору зберігання, а також друге місце в загальному заліку, поступаючись лише ClickHouse (версія для вебу).
Оптимізації, які лежать в основі цих показників, описані далі.
Агрегація шляхом об’єднання таблиць
Ця оптимізація розділяє складну агрегацію та переміщує її на обидві сторони об’єднання. Кожна таблиця агрегується локально, потім об’єднуються отримані результати, а глобальна агрегація виконується в кінці. Спочатку компресування даних, а потім їх об’єднання зменшує обсяг даних, які надходять для об’єднання, що суттєво впливає на використання пам’яті та час виконання. У тестах проекту загальна продуктивність зросла більш ніж на 200%, у понад половини випадків — більш ніж на 50%, а майже у третини — більш ніж у 100 разів.
Групування наборів даних
Зараз двигун виявляє найдрібнішу групу та її коефіцієнт агрегації та змінює стратегію з одночасної агрегації багатьох груп на двокроковий план: спочатку завершується найбільш детальна агрегація для скорочення обсягу даних, а потім інші групи формуються на основі цього результату. Загальне покращення становить понад 10%, причому у більш ніж п’ятій частини випадків покращення перевищує 20%, у найкращому випадку — 160%, а у найгіршому — регресія становить менше 5%.
Видалення вкладених стовпців
Двигун точніше розуміє структуру вкладених полів. Коли запит стосується лише одного підполя, зчитуються лише відповідні дані, а решта ігнорується, що дозволяє заощадити ресурси диска. У версії 4.1 це функціонує як для внутрішніх таблиць, так і для зовнішніх даних у форматах ORC та Parquet. Загальне покращення становить понад 60%, а у екстремальних випадках — понад 700%.
Кеш умов
Під час аналізу великих обсягів даних часто повторно використовуються ті самі фільтри з одного запиту до іншого:
SELECT * FROM orders WHERE region = 'ASIA';
SELECT count(*) FROM orders WHERE region = 'ASIA';
Постійне застосування однакового фільтра до тих самих сегментів споживає багато ресурсів процесора та здійснює інтенсивну роботу з диском. Кеш умов зберігає результати фільтрації для кожного сегмента для подальших запитів, що дозволяє уникнути зайвих сканувань та обчислень. Для складних завдань на обробку запитів ефективність покращується більш ніж на 10%.
Кеш запитів
У аналітичних завданнях також повторюється однакова агрегація даних, які не змінювалися:
SELECT region, SUM(revenue) FROM orders WHERE dt = '2024-01-01' GROUP BY region;
Кожен запуск сканує ті самі таблиці та перераховує ті самі агрегати. Кеш запитів зберігає проміжні результати агрегації, і коли контекст запиту збігається, повертає їх безпосередньо, що дозволяє заощадити ресурси обчислень та операції введення-виведення з диска.
CASE WHEN
CASE WHEN є основним інструментом для класифікації даних, логіки на рівні рядків та умовної агрегації. Версія 4.1 додає можливості об’єднання гілок, їх видалення, видобутку спільних підвиразів, а також видобутку та переміщення значень типу enum. На наборі тестів середнє підвищення продуктивності становить понад 200%, а в окремих випадках — більше ніж у 50 разів.
3. Розділення обчислень та зберігання
За даними проекту, архітектура з розділенням обчислень та зберігання вже використовується більш ніж 2 000 користувачами у продакшені, тому стабільність та продуктивність запитів стали основними пріоритетами.
Кеш файлів
Тепер метадані кешу файлів зберігаються, що усуває інтенсивну роботу з диском, яка була необхідна попереднім версіям для відновлення стану кешу під час запуску. Нова системна таблиця information_schema.file_cache_info відображає деталі кешу на рівні блоків через SQL та може бути звернена за допомогою tablet_id, be_id, cache_path та type. Це полегшує пошук активних даних, діагностику нерівномірного кешування та виявлення аномального зростання.
Одним із способів використання є перевірка складу кешу окремого таблета:
mysql> select * from information_schema.file_cache_info where TABLET_ID = 1761571031445;
+----------------------------------+---------------+-------+--------+-------------+-----------------+---------------+
| HASH | TABLET_ID | SIZE | TYPE | REMOTE_PATH | CACHE_PATH | BE_ID |
+----------------------------------+---------------+-------+--------+-------------+-----------------+---------------+
| 468448215c52334ae5bee147259b1027 | 1761571031445 | 15120 | index | | /mnt/disk1/project/filecache | 1761571031251 |
| 71bb73d34cd8ffe280b16dd329df5ba1 | 1761571031445 | 13117 | index | | /mnt/disk1/project/filecache | 1761571031251 |
| 77c6b69d1a7c4fe740a11bab5c1bbaa3 | 1761571031445 | 12249 | index | | /mnt/disk1/project/filecache | 1761571031251 |
+----------------------------------+---------------+-------+--------+-------------+-----------------------------------------------------------------------------+---------------+
Ще один спосіб — це об’єднати дані про розподіл, щоб оцінити баланс та використання ресурсів між вузлами BE:
SELECT be_id, tablet_id, type, SUM(size) AS cache_bytes
FROM information_schema.file_cache_info
WHERE tablet_id = 1761571031445
GROUP BY be_id, tablet_id, type
ORDER BY cache_bytes DESC;
Еластичність, запити до „холодних“ даних та інше
- Еластичне масштабування: у цьому режимі операції масштабування серед мільйонів таблеток завершуються протягом кількох хвилин, оскільки планування більше не залежить від загальної кількості таблеток.
- Запити до „холодних“ даних: попереднє завантаження даних на основі семантики сканування сторінок Doris прискорює обробку запитів до внутрішніх таблеток, а налаштування параметрів дозволяють Doris ефективніше використовувати пропускну здатність віддаленого сховища.
- Великомасштабні розгортання: об’єкти-репліки та таблетки у FE були оптимізовані, що дозволило зменшити використання пам’яті FE більш ніж на 30% при мільйонах таблеток.
- Мета-сервіс: шар кешування зменшує кількість повторних запитів до мета-сервісу та підвищує пропускну здатність метаданих; крім того, були оптимізовані шляхи доступу до деяких системних таблеток.
4. Data lakehouse
Версія 4.1 розвиває можливості lakehouse у плані підтримки форматів, швидкості запитів та сумісності з екосистемою. За допомогою Doris SQL можна читати, записувати та керувати основними форматами відкритих таблиць, такими як Apache Iceberg та Apache Paimon, використовуючи лише Doris SQL, без Spark чи інших зовнішніх двигунів.
Управління життєвим циклом
Створення таблиць, вставка, оновлення та видалення даних здійснюються через Doris SQL, тож один двигун охоплює весь процес роботи з даними.
- Читання та запис у Iceberg V2/V3: підтримуються операції INSERT, UPDATE, DELETE та MERGE INTO, а також функції V3, такі як Deletion Vector та Row Lineage. Процеси імпорту, оновлення та видалення відбуваються повністю без зовнішніх двигунів.
- Управління Paimon: команди
CREATE DATABASE,CREATE TABLEта інші DDL-операції виконуються безпосередньо в Doris SQL. Запис даних у таблиці Paimon планується до майбутніх версій.
Продуктивність запитів до даних у форматі lake
- Сортований запис у Iceberg: дані можна записувати у обраному порядку сортування, що створює відповідну сортовану метадани (нижні та верхні межі), яку двигун використовує для фільтрації файлів. За даними TPC-DS це покращує продуктивність запитів приблизно на 15%.
Зручність використання федерованих аналітичних інструментів
- Контроль дозволу на використання кешу: правила на рівні користувача, каталогу, бази даних та таблиці визначають, які запити можуть зберігати дані у кеші, запобігаючи видаленню «холодних» даних на користь «гарячих» та підвищуючи частку успішних запитів до найбільш використовуваних даних. Ці правила зберігаються у форматі JSON у відведеній директорії та автоматично оновлюються при змінах без необхідності перезапуску сервісу FE; команда
EXPLAINвідображає рішення щодо дозволу, що дозволяє спостерігати за процесом налаштувань. - Записи у MaxCompute: команди
CREATE TABLEтаINSERTтепер працюють у зовнішньому каталозі MaxCompute, завершуючи процес експорту даних з Doris до MaxCompute. Підтримується доступ між рахунками через ARN, що полегшує інтеграцію з екосистемою Alibaba Cloud.
5. Пакетна обробка
Doris продовжує намагатися об’єднати інтерактивний аналіз та масштабну пакетну обробку в один двигун, що зменшує архітектурну складність роботи кількох систем паралельно. Версія 4.1 ще більше посилює вбудовані функції ETL та ELT.
MERGE INTO
Одне стандартне SQL-речення MERGE INTO обробляє операції INSERT, UPDATE та DELETE (upsert), що спрощує інкрементальні завдання на злиття даних, такі як CDC, та зменшує зусилля з розробки та обслуговування:
MERGE INTO target t
USING source s
ON t.id = s.id
WHEN MATCHED THEN
UPDATE SET t.value = s.value
WHEN NOT MATCHED THEN
INSERT (id, value) VALUES (s.id, s.value);
Краща передача даних на диск у разі нестачі пам’яті
Великі операції об’єднання, агрегації з високою кардинальністю та глобальне сортування потребують багато пам’яті, і версія 4.1 розширює можливості передачі даних на диск для цих операцій:
- рекурсивна, багатоетапна передача даних дозволяє проміжним даним проходити кілька етапів та уникати раптового навантаження на пам’ять,
- це функціонує як для операцій JOIN, так і для агрегації та сортування, і
- динамічне запускання передачі даних на диск забезпечує баланс між використанням пам’яті та операціями введення-виведення з диска для стабільності запитів.
Завдяки цим змінам, за словами розробників, Doris може виконувати всі запити TPC-DS обсягом 10 ТБ на одному вузлі BE з 8 ГБ пам’яті, що є кращою продуктивністю за нижчою вартістю ресурсів порівняно з традиційними рішеннями Hadoop, Greenplum чи Spark. Як і з кожною цифрою тут, це твердження варто перевірити самостійно.
6. Зручність використання
Версія 4.1 доповнює аналітичну синтаксис, покращує здатність до опису складних сценаріїв та працює над сумісністю з іншими системами.
Розширення двигуна виконання
UNNEST. Вбудована функція UNNEST спрощує аналіз масивів та вкладених структур у даних JSON та журналів без необхідності складних переписувань функцій:
SELECT user_id, tag
FROM user_profile,
UNNEST(tags) AS t(tag);
Рекурсивний CTE. Тепер ви можете писати рекурсивні запити для просування по організаційних схемах, ієрархіях та графічних шляхах, або для аналізу інших взаємозв’язків, які потребують обходу:
WITH RECURSIVE org_tree AS (
SELECT id, parent_id, name
FROM org
WHERE parent_id IS NULL
UNION ALL
SELECT o.id, o.parent_id, o.name
FROM org o
JOIN org_tree t ON o.parent_id = t.id
)
SELECT * FROM org_tree;
З’єднання за часом. Цей спосіб з’єднує дані за найближчим значенням у стовпці часу (<= або >=), що корисно для фінансових систем, IoT та завдань моніторингу, які потребують узгодження часових рядів та пошуку найближчих значень:
SELECT t1.ts, t1.value, t2.price
FROM trades t1
ASOF JOIN prices t2
ON t1.symbol = t2.symbol
AND t1.ts >= t2.ts;
Завантаження та шлях запису
- Постійний імпорт з S3: можна створювати постійні завдання з джерел S3, і система виявляє нові файли та продовжує їх імпортувати, що дозволяє здійснювати інкрементальне завантаження з об’єктного сховища.
- Синхронізація з MySQL та PostgreSQL: Doris тепер може автоматично оновлюватися з MySQL та PostgreSQL у режимі реального часу, здійснюючи повну ініціалізацію та інкрементальну синхронізацію. Це спрощує створення потоків обробки даних у режимі реального часу на основі операційних баз даних для зберігання даних у реальному часі, консолідації даних та прискорення аналітики.
Запис та оновлення моделей
- Адаптивне планування запису: пул потоків для очищення MemTable коригується під навантаження кластера та пристосовує паралелізм запису до поточних умов, що покращує пропускну здатність, використання ресурсів та стабільність під великим навантаженням на записи.
sequence_mapping дозволяє об’єднувати оновлення з кількох потоків. Різні потоки можуть оновлювати різні стовпці однієї таблиці та об’єднуватися за допомогою власних полів послідовності, що підходить для одночасних оновлень у реальному часі та додаткового заповнення даних офлайн.TIMESTAMPTZ
Глобальні навантаження, такі як журнали між регіонами, аналітика поведінки користувачів та фінансові операції, містять чітко визначені часові зони. За допомогою типу DATETIME без зон перетворення відбувається у самому додатку, що призводить до помилок та додаткових зусиль з розробки. Doris 4.1 вводить тип TIMESTAMPTZ (часовий мітка з часовою зоною) для стандартної обробки з урахуванням часових зон:
- значення зберігаються у форматі UTC під час запису,
- під час зчитування вони перетворюються у часову зону, яку використовує сесія,
- дані з чи без вказання зони автоматично аналізуються та перетворюються, і
TIMESTAMPTZтаDATETIMEможна взаємно перетворювати та використовувати разом із існуючими функціями.
Це переміщує обробку часових зон із коду додатку до ядра бази даних, покращуючи послідовність між системами та зменшуючи складність при роботі з даними у кількох часових зонах.
Які це дає переваги
У сукупності версія 4.1 є значним кроком у напрямку позиціонування Doris як основного шару даних для AI-застосунків та аналітики в реальному часі: індекс IVF розширює можливості векторного пошуку для набагато більших колекцій, документи у форматі JSON об’ємом 100 МБ дають можливість для довгих розмов у контексті, а продуктивність OLAP та lakehouse демонструє помітне покращення порівняно з версією 4.0. Йдеться про єдину інфраструктуру для векторного пошуку, пошуку повнотекстового контенту, аналітики в реальному часі та lakehouse, що дозволяє зменшити кількість окремих векторних баз даних, пошукових та запитувальних механізмів. Чи принесе це об’єднання користі, залежатиме від масштабу вашої системи, цілей щодо затримок та того, наскільки дані, надані виробником, відповідатимуть реальному навантаженню.