apache-doris vector-search olap data-lakehouse sql

Apache Doris 4.1: вектарны пошук, захоўванне JSON, OLAP і lakehouse

Агляд навінак Apache Doris 4.1: вектарныя індэксы IVF, пошук BM25 праз search(), JSON-дакументы да 100 МБ, Segment V3, кэшы запытаў, запіс у Iceberg, MERGE INTO і TIMESTAMPTZ.

Выдавец: REACTAPP.TOPДададзена на сайт 28 кас 202618 хв чытання4072 слоў

Крыніцы: 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, за якую вядомы праект, і

Случэйнае адзначэнне вялікіх пакетаў дадзеных ETL з трубопрацэсамі у рэальны час.

Галоўныя пункты ёсць такія:

Пошук за вектарамі: новыя індэксы IVF і IVF_ON_DISK, прызначаныя для колекцый мерыльніка мільярда і больш.
Пошук у цэлым тэксце: функцыя search() атрымала метрактыкую сістэму BM25 і сынтаксіс, сумэжны з Elasticsearch.
Зберагчык длігіх кантэкстаў: адны документ у фармаце JSON цяпер можа мячыць 100 MB, што праглядаеся для выкарыстоўвання як памяць агента і для працы з длігімі кантэкстамі.
Скорасць 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, добра працуюць з дзесяткамі мільйонаў вектараў, тым што зберагаюць усі індэксы ў RAM. Калі колькасць вектараў доходзіць да дзесяткаў мільярдаў, вартасць памяці роśnie стрэмгана. Doris створыла IVF_ON_DISK на адной засадзе з IVF, следуя падходу з доследжэння SPANN кампаніі Microsoft, і спалучае кеш у памяці з кешам локальной файловай сістэмы, ўпорадковуючы вектары эфектывна і дэшава.

Завдзяк раз’ядруванню вычысленняў і зберохвату гэта дазволяе дэшава і шыбка адбіраты і вярнаваць даныя у вельмі большых масштабах.
Поруч з DiskANN, стварэнне індэкса кажуць, коштуе значна меней, што стварае рэалістычны спосаб для пошуку у масштабах трыльянаў.
Ў яго можа быць вікорыстана база знанняў AI, функція рэкамендацый і велікія хранілішча эмбеддынгаў.

Пераключэнне на яго практычна такое ж, як і вікорыстанне 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_string Elasticsearch, што павінна спрыяць пераходу з 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 MB

Агенты AI, сістэмы RAG і прыкладненні з дзейнарамі длігага кантэксту все чырэз больш хочуць зберагаць длігі кантэкст взаімадзеяў у аднам месцы. Doris 4.1 падтрымляе адзіныя радкі, якія можа хаваць документы JSON размерам да 100 MB, таму весь даныя сесіі можа застацца ў базе дадзенаў: дзвінкі з калькуляцыяй крокаў, длігія тэксты, транскрыпціі аудыо і відэа, логі запускаў агентаў, логі вызываў інструментаў і кантэкст, які выкорыстоўваецца для RAG. Не трэба нічога дзеліць, скрацваць чы пераносіць у зовнішню памяць. Пасля запісу гэтыя документы паводзяцца як іншыя даныя: працююць фільтрацыя, умовныя запыткі, агрэгацыя і з’еднання, таму вялікі кантэкст AI стае структураваным актываў, які можна запытваць.

Згідна з праектом, такій спосіб зберыгання велікіх JSON-даных дозволяе командам:

відмовітыся ад залежносты ад окрэмого сховішча об’ектыв,
унікнуты логікі, якая підтрымуе послідовнісць метаданіх і необробленого вмісту,
пропустыты працэс часткового зберыгання і перэкомпіляціі, а таксама
отрыматы ніжчу затрымку запітыв, сільнішы гарантыі транзакцій і простышы операціі.

Фармат Segment V3 і табліці шырокого фармату

Задачы пошуку і працы з ШЫ зазвічай створуюць велікі, розрыджэні, напівструктуровані даныя з многімі полямі, што вімагаюць змінніх схем і чыткіх мадэляў доступу до даных. Для гэтага потрыбні ефектывні віпадкові чытання, точковій пошук і інтэнсівні одночасні запісі.

До версіі 4.1 Doris вікорыстовувала фармат Segment V2, у якому метадані зберыгаліся в футэры файлу. Гэта підходыло для пакетного сканування, але віпадкові чытання і запіты на невелікі дыяпазоні змушувалі завантажуваты весь футэр шчоразу, што збільшувало навантажэння на дыск і вітраты на апрацоўку.

Сегмент V3, які выкарыстоўваецца новейшыя фарматы, такія як Lance і Vortex, аддзеляе метаданы ад ніжней часткі структуры і завантажае іх за патрэбай. Ён спрыяе усуненню занадто велікага колькасці метаданых, сповальнага ачынання файлоў і вялікіх затрат на віпадковы чытанне. До сцэнарыяў выкарыстоўвання належаць шырокія табелі, табелі, заполненыя падколамі VARIANT, задачы, у яых затрымкі пад час першага завантажэння дадзеных у сховішчы аб’ектаў маюць значны патэнціял, а таксі як напамер касаверкавыя даны AI чы аб’ектаў тэлематыкі, якія часта чытаюцца віпадкова. У табелі з 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 дзеліць хранэнне дакументаў на калькі, што спрыяе чытанню цэлых дакументаў і выкарыстоўванню патоў.
Прага: параметр 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.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';

Парадоксальна праця з аднаковым фільтрам на тых сабе сегментах парадоксальна — гэта спрачоўвае CPU і дысковыя операцыі вводу-выходу. Кэш умов стоіць рэзультаты фільтраў для кожнага сегмента, каб у майбутніх запытках усунуць зайвыя сканування і вычысленні. Для складных завантажэнняў запыткаў ступень павышэння эфектывнасці перавышае 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;

Эластычнасць, запыткі з малайшым навантажэнням і ўсё іншае

Эластычнае масштабаванне: у гэтым рэжыме операцыі масштабавання сярод мільйонав тэблет завершаюцца за калькі хвілін, таму што планаванне больш не залежыць ад загальнага колькіства тэблет.
Запыткі з малайшым навантажэнням: прадзейсвенна загрузка на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойчынку на аднойч

Косц стоімасці хранення об’ектаў: пад час частага імпорту злучэнне запыткаў на рэвэле цёлаў зменшае колькасць запыткаў да хранення об’ектаў і малых файлаў, і праект стварае абставіны, калі загальная косц можа знізіцца аж на 90%.

Компрэсія і кодаванне: болей эфектывае бінарныя кодаванне з падчасовым дэкадаваннем зменшае косц дэкадавання пад час выканання, а стандартны алгорытм компрэсіі поступова заменяецца на ZSTD, каб падбіраць справядлівы баланс межаў компрэсіі і швайнасці дэкомпрэсіі. Для шырых і дэталізаваных табелей гэта абяцвае меншыя запатрэбаванні на храненне і крашчую працэздатнасц пад час чытання дадзеных.

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 плануецца да выканання ў будучых версіях.

Працэс выканання запытаў над дадзенымі з базы

Запісь дадзеных у сортаваным фармаце Iceberg: дадзеныя можна запісаць у выбраным парадку сортавання, чыгунэць сортаваных метадаў (ніжняя і верхняя межы), якія сістэма вікорыстоўвае для фільтрацыі файлаў. За данымі TPC-DS, гэта павышае працэс выканання запытаў прыблізна на 15%.

Кэшаванне маніфеста айсберга: кэшаванне метаданных на рэвэлі маніфеста запобегае павтаральным чытанням і аналізу падчас планавання, чым зменшае навантажэнне на дыск і процэсар. Пад час частых запыткаў, як паведамляецца, час адпаведнага аналізу метаданных зніжваецца да рэгістру сотняў мілісекунд.

Кэш паркетных сторанак: распакаваныя сторанкі кэшуюцца ў памяці, таму зменшаецца колькасць павтаральнага распакоўвання і чытання з дыска, а затрымкі пад час частых запыткаў значна зменшаюцца. На ClickBench агульная працэсная здатнасць вырасла прыблізна на 20%.

Іспользаваннасць федэраваных аналітычных супрацоў

Контроль адмісіі ў кэш: правілы на роўні карыстальніка, каталагу, базы дадзеных і табелю вялікай значнасці адлучаюць, якія запыткі могу зберагаць даныя у кэш, запобiegаючы вытрыманню холадных даных замест гарачых і падвышаючы частка успехоў для актуальных рэгіонаў. Правілы выкладзеныя ў файлах JSON у спецыяльным каталазе, якія перзаваначваюцца без адпускання сервера FE, а команда EXPLAIN паказвае рашэнняя пра адмісію, што дапамагае стварыць адповідную наладу.
Запісы ў MaxCompute: команды CREATE TABLE і INSERT цяпер працуюць у зовнішнім каталазе MaxCompute, завершаючы шлях экспорту з Doris у MaxCompute. Падтрымліваецца доступ межа акаунтамі праз ARN, што спрыяе інтэграцыі з экасістэмай Alibaba Cloud.

Перагляд метадаў Parquet: новая функцыя з значэнням у вачох табліцы адкрывае статыстыку партыцый, групаў рэядоў і столбцаў праз SQL, што дапамагае у налагоджэнні структуры файлу, перакантролюванні працэса партыцыйнае аптымізацыі і налагоджэнні запытаў.

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 распрастраńвае механізм вывароту дадзеных на дыск на гэтыя аператары:

рэкурзіўны, багатаслоўны выварот дазволяе проміжным дадзенням праходзіць праз калькі етапаў і запобегае раптовам напору на памяць,
гэта працюе з аператарамі JOIN, агрэгацыі і сортавання, і
дынамічны запуск вывароту дадзеных на дыск збалансавае выкарыстоўванне памяці і працу дыска, ўтрымліваючы стабільнасць запытаў.

За словамі распрацоўшчыкаў, завдзяк гэтым змянам Doris можа выконваць усе запыты TPC-DS 10 TB на аднаму вузле BE з 8 GB памяці, што являе сабою лепшую працэздатнасць за меньшыя рэсурсныя вітраты, чым традыцыйныя рашэнні 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;

ASOF JOIN. Гэты спосаб з’еднае элементы па найбліжшам адпаведніку ў столцы часу (<= або >=), ён корыстны для фінансовых, 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 дазваляе з’едынаць апдэты з калькольнікаў. Разныя калькольнікі можу апдэюваць разныя столбцы адной табелі і з’едынаць іх за дапамою сваіх полей парады, што падходзіць для адночасных апдэтаў у рэальны час і заполнення дадзеных па звычайным спосабам.

Рутынны завантажэнне: гнучкія частковыя апдэты столбцоў, якія не ўтвараюць асновны ключ, дынамічныя змены параметраў і адаптатыўнае групаванне павышаюць стабільнасьць пры высокай праўоце.

Аўдыт імпорту: дзеянні Stream Load можна задаць у таблі сістэмы аўдыту, таму історыя, адлагоджэнне і аўдыты магуць быць выкарыстоўваныя з аднаго месца для запытанняў.

TIMESTAMPTZ

Глобальныя навантажэння, такія як логі з розных рэгіонаў, аналіз паведання корыстуначаў і фінансавыя транзакцыі, маюць чыста вказаныя часовыя зоны. За дапамогою DATETIME без часовай зоны пераклад відбываецца ў самай аплікацыі, што прыводзіць да памылак і дадатковай працы над развіццем. Doris 4.1 адкрывае TIMESTAMPTZ (таймстамп з часовой зоны) для стандартнага керавання з урахоўванням часовых зон:

значэнні зберагаюцца ў UTC пад час запісу,
даныя, якія чытаюцца, перакладаюцца на тую часовую зону, якая вікорыстоўваецца ў сесіі,
вхідныя даны з часовай зоной або без яе парсуюцца і перакладаюцца самыя, і
TIMESTAMPTZ і DATETIME можна перакладаць аднаго ў другі і яны можу працаваць з існуючымі функціямі.

Гэта вывалюе керавання часовымі зонамі з коду аплікацыі ў ядро базы дадзенаў, павышаючы адноснаст у розных сістэмах і зменшаючы складнасць працы з дадзеннямі з калькольнай колькасцю часовых зон.

Што гэта дае

У сукупнасці версія 4.1 ўособліва важыліва для таго, каб Doris стала асновным шаром дадзейнаў для прыкладнікаў AI і аналізу дадзэйнаў у рэальны час: індэкс IVF распрашвае вектарны пошук для значна большых колекцыяў, дакументы JSON размерам 100 MB адкрываюць можлівасць дыялогаў з довгім кантэкстам, а прыдатнасць OLAP і lakehouse паказвае значныя падыгрышы працэсу у пораўнанні з версіяй 4.0. Мова йдэ пра адну інфраструктуру, якая падтрымлівае вектарны пошук, пошук цэлаг тэксту, аналіз дадзэйнаў у рэальны час і lakehouse, таму трэба менш адскальных вектарных баз дадзейнаў, пошуковых і запытных механізмаў. Тое, чы рэалізуецца такая кансолідацыя, залежыць ад вашага масштабу, целей па затрымкам і ад таго, якія показнікі, апаведамлены вэндорам, будуць у вашай справе.

← Усе артыкулы Даслаць брыф