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(), позволив тем самым обслуживать ИИ-агентов, решения типа RAG, системы наблюдаемости за ИИ и инструменты аналитики в реальном времени. Версия 4.1 движется в том же направлении и нацелена на то, чтобы один движок обрабатывал как хранение, так и поиск данных для задач ИИ и поиска. В примечаниях к выпуску основное внимание уделяется проблемам, с которыми сталкиваются команды при запуске ИИ-приложений в производство:
- сохранение доступной стоимости хранения больших объемов данных ИИ,
- сочетание векторного поиска, полнотекстового поиска и структурированных фильтров в одной системе,
- хранение длинных документов и объемных полуструктурированных записей в одной таблице,
- ответы на запросы в реальном времени и вопросы, связанные с наблюдаемостью за 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.
- Data lake: возможности чтения и записи для Apache Iceberg V2/V3, DDL для Apache Paimon через SQL, а также кэш страниц в формате Parquet, приносящий примерно 20% экономии ресурсов.
- Разделение вычислений и хранилища: режим, который, по словам проекта, используется более чем в 2 000 компаниях и обеспечивает лучшую видимость кэша, эластичность и работу с запросами к холодным данным.
Все приведенные ниже показатели производительности взяты из собственного объявления проекта, поэтому рассматривайте их как данные, предоставленные производителем, и проверяйте их с помощью собственных данных.
1. Искусственный интеллект и поиск
Векторный поиск
IVF объединяется с HNSW. Версия 4.0 предлагала HNSW в качестве векторного индекса. Версия 4.1 добавляет IVF (обратный файл) для более крупных наборов данных. Суть заключается в заранее группировке векторов по контейнерам, после чего ищут только в тех контейнерах, которые с наибольшей вероятностью содержат соседние векторы, тем самым жертвуя небольшой точностью ради значительного ускорения. По сравнению с 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, что должно облегчить миграцию с этой системы. - Среди операторов — 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 Store на несколько шардов, что способствует как чтению целых документов, так и извлечению данных по путям. - Пороговое значение: параметр
variant_doc_materialization_min_rowsопределяет момент, когда начинается процесс материализации; пакеты, меньшие по размеру, ожидают до момента сжатия.
Он предназначен для обработки результатов работы больших языковых моделей, данных трассировки, снимков контекста и воспроизведения событий — задач, при которых часто возвращаются целые документы. Чтобы настроить его, включите 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.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 добавляет возможности объединения веток, устранения веток, извлечения общих подвыражений, а также извлечения и передачи значений из перечислений. На наборе тестов средний прирост производительности превышает 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 в специальном каталоге, которые автоматически перезагружаются при изменениях без необходимости перезапуска сервера приложений; команда
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 (упсерт), упрощая задачи по постепенному слиянию данных, такие как 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 расширяет функцию записи данных на диск для этих операторов:
- рекурсивная многоступенчатая запись данных позволяет промежуточным данным проходить через несколько этапов, тем самым избегая внезапного давления на память,
- эта функция работает с операторами объединения, агрегации и сортировки, и
- динамическое запускание записи на диск позволяет сбалансировать использование памяти и объем операций ввода-вывода с диска для стабильной работы запросов.
Благодаря этим изменениям, по заявлению разработчиков, 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;
СОЕДИНЕНИЕ ПО БЛИЖЕМУ СООТВЕТСТВИЮ. Этот способ совершает соединение по ближайшему значению в столбце времени (<= или >=); он полезен для финансовых систем, устройств Интернета вещей и задач мониторинга, которым требуется синхронизация временных рядов и поиск ближайших значений:
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 основным слоем хранения данных для приложений искусственного интеллекта и аналитики в реальном времени: индекс IVF позволяет использовать векторный поиск с гораздо более крупными наборами данных, документы в формате JSON объемом 100 МБ обеспечивают возможность ведения длинных диалогов с учетом всего контекста, а производительность решений OLAP и lakehouse демонстрирует заметное улучшение по сравнению с версией 4.0. Суть заключается в создании единой инфраструктуры для векторного поиска, полнотекстового поиска, аналитики в реальном времени и работы с lakehouse, что позволяет сократить количество отдельных векторных баз данных, поисковых систем и движков запросов. То, принесет ли такая консолидация пользу, будет зависеть от масштабов вашей работы, заданных показателей задержек и того, насколько цифры, приведенные поставщиком, соответствуют реальной нагрузке в вашей среде.