Apache Doris 4.1: Vektorabfrage, JSON-Speicherung, OLAP und Lakehouse

Apache Doris 4.1 setzt an der 4.0-Version an, die Vektorabfragen, hybride Suchmethoden sowie die search()-Funktion in das Projekt einführte, damit es KI-Agenten, RAG, KI-Überwachungsfunktionen sowie Echtzeit-Analysen unterstützen kann. Version 4.1 geht in derselben Richtung voran und zielt darauf ab, einen einzigen Motor dafür zu schaffen, sowohl die Speicherung als auch die Abfrage von Daten für KI- und Suchanwendungen zu bewältigen. In den Veröffentlichungshinweisen werden die Herausforderungen thematisiert, mit denen Teams konfrontiert sind, wenn sie KI-Anwendungen in die Produktion bringen:

• die Kosten für große Mengen an KI-Daten in Grenzen zu halten,
• Vektorabfragen, Volltextsuche und strukturierte Filter in einem System zu kombinieren,
• lange Dokumente sowie umfangreiche halbstrukturierte Datensätze in eine einzige Tabelle unterzubringen,
• Echtzeitabfragen sowie Fragen zur Überwachung von LLMs, Agenten und RAG zu beantworten,
• die für das Projekt bekannte Geschwindigkeit von OLAP- und Lakehouse-Lösungen beizubehalten, und

Verbindung großer Batch-ETL-Prozesse mit Echtzeit-Pipelines.

Die wichtigsten Neuerungen sind folgende:

• Vektorabfrage: neue IVF- und IVF_ON_DISK-Indizes für Sammlungen im Milliardenbereich und größer.
• Volltextabfrage: Die Funktion search() verfügt nun über eine BM25-Bewertungsmethode sowie eine mit Elasticsearch kompatible Syntax.
• Lange Kontextspeicherung: Ein einzelnes JSON-Dokument kann nun 100 MB groß sein und dient der Speicherung von Agentenmemorien sowie für Arbeiten mit langen Kontexten.
• OLAP-Geschwindigkeit: Laut dem Projekt gibt es Verbesserungen von 22,6 % bei TPC-H, 19,1 % bei TPC-DS und 14,3 % bei SSB – zudem Platz eins bei kalten Abfragen auf ClickBench.
• Data Lake: Lesen und Schreiben für Apache Iceberg V2/V3, DDL für Apache Paimon über SQL sowie ein Parquet-Seitencache, der etwa 20 % Geschwindigkeitsvorteile bringt.
• Trennung von Rechenleistung und Speicher: ein Modus, der laut dem Projekt in mehr als 2.000 Unternehmen eingesetzt wird und eine bessere Cache-Sichtbarkeit, Elastizität sowie ein verbessertes Verhalten bei Abfragen an ungenutzten Daten bietet.

Sämtliche unten aufgeführten Leistungsdaten stammen aus der offiziellen Ankündigung des Projekts; betrachten Sie sie daher als von dem Anbieter gemeldete Werte und überprüfen Sie diese anhand Ihrer eigenen Daten.

1. KI und Suchfunktionen

Vektor-Suchfunktion

IVF wird zu HNSW hinzugefügt. Version 4.0 bot HNSW als Vektorindex an. Version 4.1 fügt IVF (inverted file) für größere Datensätze hinzu. Die Idee besteht darin, Vektoren im Voraus in Behälter zu gruppieren und anschließend nur in den Behältern nachzusehen, die am ehesten Nachbervektoren enthalten – dabei wird etwas an Präzision geopfert, um eine erhebliche Geschwindigkeitssteigerung zu erzielen. Im Vergleich zu HNSW kann IVF größere Sammlungen mit weniger Speicher verarbeiten, allerdings zu Lasten einer etwas geringeren Trefferquote. Sie aktivieren es, indem Sie in den Indexeigenschaften "index_type"="ivf" festlegen:

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. Bibliotheken wie Faiss funktionieren gut bis zu Zehntausenden von Vektoren, da sie den gesamten Index im RAM speichern. Bei Zehn Milliarden Vektoren steigen die Speicherkosten jedoch stark an. Doris basiert auf IVF_ON_DISK auf der IVF-Technologie und folgt dabei dem Ansatz aus Microsofts SPANN-Forschung; sie kombiniert einen In-Memory-Cache mit einem lokalen Dateisystem-Cache, um Vektoren effizient und kostengünstig zu filtern.

• Durch die Trennung von Rechenleistung und Speicherung ist ein kostengünstiges, schnelles Filtern sowie Abrufen bei sehr großen Skalen möglich.
• Im Vergleich zu DiskANN kostet der Indexaufbau deutlich weniger, was einen realistischen Weg für Suchoperationen im Trillionen-Bereich bietet.
• Mögliche Anwendungsbereiche umfassen KI-Wissensbasen, Empfehlungssysteme sowie große Embedding-Speicher.

Der Wechsel darauf ist im Grunde genauso wie die Verwendung von IVF, wobei lediglich "index_type"="ivf_on_disk" verwendet wird:

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");

Quantisierung. Neben dem Indexalgorithmus werden drei Quantisierungsverfahren unterstützt: INT8-Skalar, INT4-Skalar und Produktquantisierung (PQ). Um einen geringen Verlust bei der Trefferquote zu vermeiden, werden die Indizes auf ein Viertel bis ein Achtel ihrer ursprünglichen Speicherkapazität verkleinert, und in Kombination mit IVF_ON_DISK werden die Hardwarekosten für große Suchsysteme weiter gesenkt. Die folgende DDL zeigt die PQ-Kompression von 128-dimensionalen Vektoren:

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");

Schnellere Abfragen. Eine neue Optimierung namens „Ann Index Only Scan“ ermöglicht es vectorbasierten Abfragen, die Dateneingabe/Ausgabe auf den Rohspalten zu umgehen, wodurch der Overhead erheblich reduziert wird. Laut dem Projekt laufen vectorbasierte Indexabfragen bis zu viermal schneller als in Version 4.0. In einem Test mit einer Million Vektoren auf einem 16-Kern-, 64-GB-System soll Doris etwa 900 Abfragen pro Sekunde erreichen bei einer Rückgaberate von 97 % – was für die meisten Produktivanwendungen ausreicht.

In der Ankündigung werden außerdem öffentliche VectorDBBench-Werte (Stand Januar 2026) zitiert, wonach Doris Vector-Indizes schneller erstellen kann als Milvus, Qdrant und pgvector – und dies seiner Architektur mit mehreren Datenschichten zugeschrieben wird. In Version 4.1 werden Vektoren während der Erstellung in der Speicherung gebündelt und der Index Schritt für Schritt erstellt, wodurch die Parallelisierung bei der Erstellung erhöht wird, ohne die Qualität des Index zu beeinträchtigen.

Die search()-Funktion

Während die Vektorsuche die semantische Wiederauffindung bewältigt, befasst sich die Volltextsuche mit der Suche nach Schlüsselwörtern, Fehlerbehebung, Log-Suchen und Textanalyse. Die neue search()-Funktion bringt diese Funktionen in SQL ein, sodass eine einzige Abfrage gleichzeitig filtern und aggregieren kann.

• Sie akzeptiert die Elasticsearch-query_string-Syntax, was den Umstieg von Elasticsearch erleichtern sollte.
• Zu den Operatoren gehören TERM, PHRASE, WILDCARD, REGEXP, PREFIX, NOT und NESTED, wobei alle miteinander verschachtelt und kombiniert werden können.
• Die Relevanzbewertung nach BM25 ist integriert, wobei eine TopN-Optimierung auf der Speicherschicht erfolgt, damit nicht ganze Ergebnismengen übertragen werden müssen.
• In Kombination mit dem VARIANT-Typ kann NESTED in verschachtelte JSON-Arrays blicken.

Die Mehrfeldsuche unterstützt best_fields (eine präzise Übereinstimmung innerhalb eines Feldes) sowie cross_fields (eine Übereinstimmung, die sich über mehrere Felder erstreckt).

Eine typische Abfrage sieht so aus:

-- 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() gibt ein boolesches Prädikat zurück, sodass es an Join-Operationen, Fensterfunktionen und Unterabfragen teilnehmen kann – wodurch die Volltextsuche zu einem normalen Bestandteil von SQL wird.

JSON-Dokumente bis zu 100 MB

KI-Agenten, RAG-Systeme sowie mehrstufige, langkontextuelle Anwendungen möchten zunehmend den gesamten Interaktionskontext an einem Ort speichern. Doris 4.1 unterstützt einzelne Zeilen, die JSON-Dokumente von bis zu 100 MB enthalten können, sodass alle Sitzungsdaten in der Datenbank aufbewahrt werden können: mehrstufige Konversationen, lange Texte, Transkripte von Audio- und Videomaterial, Protokolle der Agentenausführungen, Logs von Toolaufrufen sowie der für RAG verwendete Kontext. Es ist nicht notwendig, diese Dokumente zu teilen, abzukürzen oder in externe Speicher zu übertragen. Sobald sie geschrieben wurden, verhalten sich diese Dokumente wie andere Daten – Filtern, bedingte Abfragen, Aggregationen und Join-Operationen funktionieren weiterhin, wodurch umfangreicher KI-Kontext zu einem abfragbaren, strukturierten Asset wird.

Laut dem Projekt ermöglicht das Speichern großer JSON-Daten auf diese Weise den Teams:

• die Abhängigkeit von einem separaten Objektspeicher zu vermeiden,
• die Logik zu umgehen, die Metadaten und Rohinhalte konsistent hält,
• die Arbeit mit in Blöcken gespeicherten Daten sowie deren Wiedervereinigung zu ersparen, und
• eine geringere Abfragedauer, stärkere Transaktionsgarantien sowie einfachere Operationen zu erzielen.

Segment V3 und breite Tabellen

Such- und KI-Aufgaben erzeugen in der Regel breite, spärliche, halbstrukturierte Daten mit vielen Feldern, wechselnden Schemata sowie klaren Mustern für häufige und seltene Zugriffe. Dafür sind starke zufällige Lesevorgänge, punktgenaue Abfragen sowie intensive gleichzeitige Schreibvorgänge erforderlich.

Vor Version 4.1 verwendete Doris das Segment V2-Format, bei dem die Metadaten im Fußteil der Datei gespeichert wurden. Dies eignet sich für Batch-Scans, doch bei zufälligen Lesevorgängen und Abfragen auf kleine Bereiche muss jedes Mal der gesamte Fußteil geladen werden, was zu höheren Disk-I/O-Kosten und zusätzlichen Parsing-Aufwänden führt.

Segment V3, beeinflusst von neueren Formaten wie Lance und Vortex, trennt Metadaten vom Fußteil und lädt sie auf Anfrage. Es zielt auf übermäßiges Metadatenvolumen, langsame Dateiöffnungen sowie hohe Kosten durch zufällige Lesevorgänge ab. Geeignete Anwendungsfälle sind breite Tabellen, Tabellen voller VARIANT-Unterspalten, Anwendungen, bei denen die Latenz beim ersten Zugriff auf Objektspeicher problematisch ist, sowie halbstrukturierte KI- oder Fahrzeugtelematikdaten, die häufig zufällig gelesen werden. Bei einer Tabelle mit 7.000 Spalten und 10.000 Segmenten soll V3 bis zu 16 Mal schneller öffnen und bis zu 60 Mal weniger Speicher verbrauchen. Um es zu aktivieren, setzen Sie in den Tabelleigenschaften "storage_format" = "V3" ein:

CREATE TABLE table_v3 (
    id BIGINT,
    data VARIANT
)
DISTRIBUTED BY HASH(id) BUCKETS 32
PROPERTIES (
    "storage_format" = "V3"
);

Sparse-Spalten

JSON mit vielen Feldern weist in der Regel eine große Anzahl seltener genutzter Pfade sowie einige häufig genutzte auf. Doris 4.1 überarbeitet den Mechanismus für das Lesen solcher Spalten, sodass die seltener genutzten Pfade keine Engpässe in einer einzelnen Sparse-Spalte verursachen.

• Trennung von häufig und selten genutzten Pfade: Häufig genutzte Pfade bleiben als Spaltensubspalten erhalten, während seltener genutzte Pfade in sparsamen Speicher übertragen werden, wodurch sich die Anzahl der Subspalten nicht unkontrolliert vermehrt.
• Sparse-Sharding: variant_sparse_hash_shard_count verteilt die seltener genutzten Pfade auf mehrere Sparse-Spalten, wodurch die Leselast auf einer einzigen Spalte verringert wird.
• Sparse-Cache: Ein Lesecache für Sparse-Spalten reduziert wiederholte Dateneingriffe auf der Festplatte sowie die Notwendigkeit zur Dekodierung und Deserialisierung.

Dies eignet sich für JSON mit vielen Feldern aus Fahrzeugtelematik, Benutzerprofilen und Ereignisprotokollen – überall dort, wo eine Datenspur viele Felder aufweist, aber nur Dutzende oder wenige Hundert Pfade häufig abgerufen werden:

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-Modus

Wenn Schreibeffizienz oder das Abrufen ganzer JSON-Dokumente im Vordergrund stehen, ist der DOC-Modus die bessere Wahl. Er speichert das rohe JSON beim Schreiben und verschiebt die Extraktion von Unterkolumnen auf den Zeitpunkt der Komprimierung, wodurch die Schreibkosten und die Schreibvergrößerung verringert werden.

• Aufgeschobene Materialisierung: Das rohe JSON wird beim Schreiben beibehalten, was die Overhead-Kosten bei kleinen Datensätzen senkt.
• DOC-Sharding: variant_doc_hash_shard_count teilt den Doc Store in mehrere Shards auf, was sowohl das Lesen ganzer Dokumente als auch die Extraktion von Pfaden erleichtert.
• Schwellenwert: variant_doc_materialization_min_rows legt fest, ab welcher Größe die Materialisierung einsetzt; kleinere Datensätze warten bis zur Komprimierung.

Dies richtet sich auf Ausgaben von LLMs, Trace-Daten, Kontext-Snapshots sowie Event-Playback-Funktionen – Aufgaben, bei denen oft ganze Dokumente zurückgegeben werden. Um es zu konfigurieren, aktivieren Sie variant_enable_doc_mode, und passen Sie anschließend die Schwellenwerte sowie die Anzahl der Shards an das Volumen Ihrer Daten an. DOC-Modus und sparsame Spalten schließen sich gegenseitig aus, daher wählen Sie einen davon und kombinieren ihn mit 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. Schnellere OLAP

Doris hat seinen Ruf auf schnellem, Echtzeit-OLAP aufgebaut, und 4.1 setzt dies fort, indem es überflüssige Berechnungen reduziert, weniger Daten verarbeitet und effizienter ausführt, sodass komplexe Abfragen auch unter realistischem Lastaufkommen schnell bleiben.

Mehrtabellen- und Breittabellen-Benchmarks

Bei standardmäßigen Join- und Aggregations-Szenarien weist die neue Version im Vergleich zu 4.0 folgende Verbesserungen auf: 22,6 % bei TPC-H, 19,1 % bei TPC-DS und 14,3 % bei SSB.

Für Breittabellen verwendet ClickBench 100 GB an Daten sowie 43 komplexe Abfragen, um die Leistung von kolonialer Speicherung, vektorisierter Ausführung und Kompression zu prüfen – wodurch es zu den anspruchsvollsten Einzeltabellen-Benchmarks zählt. Auf c7a.metal-48xl-Instanzen belegt Doris 4.1 laut dem Projekt den ersten Platz bei kalten Abfragen sowie hinsichtlich des benötigten Speicherplatzes und den zweiten Platz insgesamt, nur hinter ClickHouse (Web).

Die Optimierungen hinter diesen Zahlen werden im Folgenden beschrieben.

Aggregation durch Zusammenführung mittels Join-Operationen

Diese Optimierung teilt aufwändige Aggregationen auf und führt sie an beiden Seiten eines Join durch. Jede Tabelle wird lokal aggregiert, die erweiterten Ergebnisse werden anschließend zusammengeführt, wobei die globale Aggregation zuletzt erfolgt. Durch Komprimieren zuerst und Zusammenführen später wird die Menge der in den Join eintretenden Daten reduziert, was sich deutlich auf Speicherverbrauch und Latenz auswirkt. In den Tests des Projekts stieg die Gesamtleistung um mehr als 200 %, in über der Hälfte der Fälle um mehr als 50 % und in fast einem Drittel sogar um mehr als 100-mal.

Gruppierung von Datensätzen

Der Motor erkennt nun die feinste Gruppierung sowie deren Aggregationsverhältnis und wechselt die Strategie von der parallelen Aggregation vieler Gruppen zu einem zweistufigen Plan: Zunächst wird die detaillierteste Aggregation abgeschlossen, um die Datenmenge zu verringern, anschließend werden die anderen Gruppen aus diesem Ergebnis abgeleitet. Die gemeldete Gesamtverbesserung liegt bei über 10 %, wobei mehr als ein Fünftel der Fälle eine Verbesserung von über 20 % aufweist, im besten Fall sogar 160 %, während im schlimmsten Fall eine Regression von unter 5 % auftritt.

Nestierte Spaltenkürzung

Der Motor versteht die nestierten Feldstrukturen genauer. Wenn eine Abfrage nur ein Unterfeld betrifft, werden nur die relevanten Daten gelesen und der Rest übersprungen, was Speicherzugriffe spart. In Version 4.1 funktioniert dies für interne Tabellen sowie für externe ORC- und Parquet-Daten. Die gemeldete Gesamtsteigerung liegt bei über 60 %, in extremen Fällen sogar bei über 700 %.

Bedingungskache

Bei großangelegten Analysen werden oft dieselben Filter von einer Abfrage zur nächsten wiederverwendet:

SELECT * FROM orders WHERE region = 'ASIA';
SELECT count(*) FROM orders WHERE region = 'ASIA';

Das wiederholte Anwenden desselben Filters auf dieselben Segmente verbraucht viel CPU-Ressourcen sowie Festplattenein-/Ausgaben. Der Bedingungsspeicher speichert das Ergebnis des Filters pro Segment für spätere Abfragen und reduziert so überflüssige Scans sowie Rechenoperationen. Bei komplexen Abfragen liegt die angegebene Verbesserung bei über 10 %.

Abfragespeicher

Auch analytische Arbeitslasten wiederholen dieselbe Aggregation an unveränderten Daten:

SELECT region, SUM(revenue) FROM orders WHERE dt = '2024-01-01' GROUP BY region;

Jeder Ausführungsvorgang scannt die gleichen Tabellen und berechnet erneut die gleichen Aggregaten. Der Abfragespeicher speichert die Zwischenergebnisse der Aggregation und gibt sie direkt zurück, sobald der Abfragekontext übereinstimmt, wodurch Rechenleistung und Datenträgerzugriffe eingespart werden.

CASE WHEN

CASE WHEN ist ein zentrales Konstrukt für die Geschäftsklassifizierung, Logik auf Zeilenebene sowie bedingte Aggregationen. Version 4.1 fügt die Verschmelzung von Branches, deren Eliminierung, die Extraktion gemeinsamer Unterexpressionen sowie die Extraktion und Weitergabe von Enum-Werten hinzu. Im Benchmark-Set liegt der durchschnittliche Gewinn bei über 200 %, wobei extreme Werte sogar mehr als das Fünffache betragen.

3. Trennung von Rechen- und Speicherkapazität

Laut dem Projekt wird die Architektur mit getrennter Rechen- und Speicherkapazität derzeit von mehr als 2.000 Produktivnutzern genutzt, wodurch Stabilität und Abfragedatenleistung zu den wichtigsten Schwerpunkten geworden sind.

Dateispeicher

Die Metadaten des Dateicaches werden nun persistent gespeichert, wodurch die intensive Festplatten-Ein-/Ausgabe vermieden wird, die frühere Versionen beim Neustart zum Wiederherstellen des Cache-Zustands benötigten. Eine neue Systemtabelle, information_schema.file_cache_info, zeigt detaillierte Informationen zum Cache auf Blockebene über SQL an und kann anhand von tablet_id, be_id, cache_path sowie type abgefragt werden. Dadurch wird es einfacher, häufig genutzte Daten zu finden, unausgeglichene Caches zu diagnostizieren und ungewöhnliches Wachstum zu erkennen.

Eine Anwendung besteht darin, die Cache-Zusammensetzung einer einzelnen Tabelle zu überprüfen:

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 |
+----------------------------------+---------------+-------+--------+-------------+-----------------------------------------------------------------------------+---------------+

Eine weitere Methode besteht darin, die Verteilung zu aggregieren, um das Gleichgewicht sowie den Ressourcenverbrauch zwischen den BE-Node zu bewerten:

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;

Elastizität, kühle Abfragen und mehr

• Elastisches Skalieren: In diesem Modus werden Skalierungsoperationen bei Millionen von Tablets innerhalb weniger Minuten abgeschlossen, da die Planung nicht mehr vom globalen Tablet-Zahl bestimmt wird.
• Kühle Abfragen: Das Vorausladen auf der Grundlage der Seiten-Scanningsemantik von Doris beschleunigt Abfragen an internen Tabellen, und die Parameteranpassung ermöglicht es Doris, mehr Bandbreite des entfernten Speichers zu nutzen.
• Große Implementierungen: Replikate sowie Tablet-Objekte im Frontend wurden vereinfacht, wodurch der Speicherverbrauch des Frontends bei Millionen von Tablets um mehr als 30 % reduziert wird.
• Meta-Dienst: Eine Caching-Schicht verringert wiederholte Anfragen an den Meta-Dienst und erhöht die Durchsatzrate der Metadaten, zudem wurden die Zugriffswege für einige Systemtabellen optimiert.

Kosten für Objektspeicherung: Bei häufigen Importen verringert das Zusammenführen von Anfragen auf Node-Ebene die Anzahl der Anfragen an den Objektspeicher sowie die Größe der Dateien, wodurch laut dem Projekt die Gesamtkosten um bis zu 90 % sinken können.

Kompression und Kodierung: Eine effizientere binäre Kodierung in Kombination mit vorheriger Dekodierung senkt die Laufzeitkosten der Dekodierung. Der Standard-Kompressionsalgorithmus wechselt allmählich zu ZSTD, um ein gutes Verhältnis zwischen Kompressionsgrad und Dekompressionsgeschwindigkeit zu erreichen. Bei breiten und detaillierten Tabellen bedeutet dies kleinere Speicherkapazitäten sowie bessere Leistungen bei langsamen Lesevorgängen.

4. Data Lakehouse

Version 4.1 bringt Verbesserungen im Lakehouse-Ansatz hinsichtlich der Formatunterstützung, der Abfragegeschwindigkeit und der Kompatibilität mit dem Ökosystem. Mit Doris SQL können Sie die wichtigsten offenen Tabellformate wie Apache Iceberg und Apache Paimon ausschließlich mit Doris SQL lesen, schreiben und verwalten – ohne Spark oder einen anderen externen Motor.

Lifecycle-Management

Die Erstellung von Tabellen sowie das Einfügen, Aktualisieren und Löschen erfolgen alle über Doris SQL, sodass ein einziger Engine den gesamten Workflow abdeckt.

• Lese- und Schreibvorgänge mit Iceberg V2/V3: INSERT, UPDATE, DELETE und MERGE INTO werden unterstützt, ebenso wie V3-Funktionen wie Deletion Vector und Row Lineage. Die Einpflege, Aktualisierungen und Löschvorgänge laufen vollständig ohne externe Engines ab.
• Paimon-Management: CREATE DATABASE, CREATE TABLE sowie andere DDL-Befehle werden direkt in Doris SQL ausgeführt. Das Schreiben in Paimon-Tabellen ist für zukünftige Versionen vorgesehen.

Abfragedatenbankleistung bei Lake-Daten

• Gesortete Schreibvorgänge mit Iceberg: Die Daten können in einer gewählten Sortierreihenfolge geschrieben werden, wodurch sortierte Metadaten (Unter- und Obergrenzen) erzeugt werden, die von der Engine zur Filterung der Dateien genutzt werden. Bei TPC-DS soll dies die Abfragedatenbankleistung um etwa 15 % verbessern.

Eisberg-Manifest-Caching: Das Caching von Metadaten auf Manifest-Ebene vermeidet wiederholte Lese- und Parsvorgänge während der Planung, wodurch die Festplatten-I/O-Auslastung sowie der CPU-Verbrauch reduziert werden. Bei häufigen Abfragen sinkt die Auflösung komplexer Metadaten dem Bericht zufolge auf den Bereich von hundert Millisekunden.

Parquet-Seiten-Caching: Entpackte Seiten werden im Speicher gekacht, wodurch wiederholte Entpackvorgänge sowie Festplatten-Lesevorgänge vermieden werden und die Latenz bei häufigen Abfragen deutlich abnimmt. Auf ClickBench stieg die Gesamtleistung um etwa 20 %.

Nutzbarkeit von federierten Analysen

• Kontrolle der Cache-Zugriffe: Regeln auf Benutzer-, Katalog-, Datenbank- und Tabellenebene entscheiden, welche Abfragen in den Cache schreiben dürfen. Dadurch werden kältere Daten daran gehindert, heiße Daten zu verdrängen, und die Trefferquote bei häufig genutzten Bereichen erhöht. Die Regeln sind JSON-Dateien in einem bestimmten Verzeichnis, die bei Änderungen sofort neu geladen werden, ohne dass der Frontend-Server neu gestartet werden muss. Mit EXPLAIN können die Zugriffsentscheidungen angezeigt werden, sodass eine Anpassung möglich ist.
• Schreibvorgänge in MaxCompute: CREATE TABLE und INSERT funktionieren nun im externen Katalog von MaxCompute, wodurch der Exportweg von Doris zu MaxCompute abgeschlossen wird. Der Zugriff über ARN zwischen Konten ist unterstützt, was die Integration in das Alibaba Cloud-Ökosystem erleichtert.

Prüfung der Parquet-Metadaten: Eine neue tabellenbasierte Funktion stellt Statistiken zu Partitionen, Zeilengruppen und Spalten über SQL zur Verfügung, was beim Debuggen der Dateistruktur, Überprüfen des Partition-Pruning sowie bei der Optimierung von Abfragen hilfreich ist.

5. Batchverarbeitung

Doris versucht weiterhin, interaktive Analytik und große Batchverarbeitungen in einem einzigen Engine zu vereinen, wodurch die architektonische Komplexität des Betriebs mehrerer Systeme nebeneinander verringert wird. Version 4.1 stärkt die eingebauten ETL- und ELT-Funktionen weiter.

MERGE INTO

Eine standardmäßige SQL-Anweisung MERGE INTO kümmert sich um INSERT-, UPDATE- und DELETE-Aufgaben (einen Upsert-Vorgang), wodurch inkrementelle Merge-Aufgaben wie CDC vereinfacht werden und die Entwicklung sowie Wartungskosten sinken:

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);

Stärkere Übertragung auf Festplatte

Größere Join-Operationen, Aggregationen mit hoher Kardinalität sowie globale Sortierungen verbrauchen viel Speicher. 4.1 erweitert die Übertragung auf Festplatte auf diese Operator:

• durch rekursive, mehrstufige Übertragungen können Zwischendaten durch mehrere Phasen geleitet werden, wodurch plötzlicher Speicherdruck vermieden wird,
• es funktioniert bei JOIN-, Aggregations- und Sortieroperatorn sowie
• dynamische Auslösung der Übertragung sorgt für ein Gleichgewicht zwischen Speichernutzung und Festplatten-I/O, um Abfragen stabil zu halten.

Laut dem Projekt ermöglichen diese Änderungen es Doris, alle TPC-DS 10 TB-Abfragen auf einem BE-Node mit 8 GB Speicher auszuführen – was als bessere Leistung bei geringeren Ressourcenkosten im Vergleich zu herkömmlichen Hadoop-, Greenplum- oder Spark-Setups dargestellt wird. Wie bei jeder Zahl hier gilt auch hier: Das ist eine Behauptung, die man selbst überprüfen sollte.

6. Benutzerfreundlichkeit

Version 4.1 vervollständigt die analytische Syntax, verbessert die Ausdrucksfähigkeit in komplexen Szenarien und arbeitet an der Kompatibilität mit anderen Systemen.

Erweiterungen des Ausführungsmotors

UNNEST. Die eingebettete Funktion UNNEST vereinfacht die Analyse von Arrays und verschachtelten Strukturen in JSON- sowie Protokolldaten, ohne umständliche Funktionsumschreibungen erforderlich zu machen:

SELECT user_id, tag
FROM user_profile,
UNNEST(tags) AS t(tag);

Rekursive CTE. Sie können nun rekursive Abfragen schreiben, um Organigramme, Hierarchien und Graphenpfade durchzugehen oder andere Beziehungen zu analysieren, die eine Durchquerung erfordern:

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. Dabei wird anhand des nächsten Übereinstimmungswerts in einer Zeitspalte (<= oder >=) verbunden, was für Finanz-, IoT- und Überwachungsaufgaben nützlich ist, die eine Ausrichtung von Zeitreihen sowie die Suche nach dem nächsten Wert erfordern:

SELECT t1.ts, t1.value, t2.price
FROM trades t1
ASOF JOIN prices t2
ON t1.symbol = t2.symbol
AND t1.ts >= t2.ts;

Eingabe und Schreibweg

• Kontinuierliche S3-Importe: Es können kontinuierliche Aufgaben aus S3-Quellen erstellt werden, wobei das System neue Dateien erkennt und weiterhin importiert, was einen schrittweisen Eingang aus Objektspeichern ermöglicht.
• Synchronisierung mit MySQL und PostgreSQL: Doris kann sich nun in Echtzeit aus MySQL und PostgreSQL aktualisieren, wobei sowohl eine vollständige Initialisierung als auch schrittweise Synchronisation möglich sind. Dadurch wird der Aufbau von Echtzeit-Pipelines aus Betriebsdatenbanken vereinfacht, was wiederum die Nutzung für Echtzeit-Lagerung, Datenkonsolidierung und beschleunigte Analyse ermöglicht.

Modell schreiben und aktualisieren

• Anpassungsfähige Schreibplanung: Der Thread-Pool zum Ausschreiben von MemTables passt sich der Last des Clusters an und stellt die Schreibkonkurrenz den aktuellen Bedingungen entsprechend ein, wodurch die Durchsatzrate, der Ressourcenverbrauch sowie die Stabilität bei hohen Schreibbelastungen verbessert werden.

Mehrström-Updates im Primärschlüssel-Modell: sequence_mapping ermöglicht das Zusammenführen von Updates aus mehreren Strömen. Verschiedene Ströme können unterschiedliche Spalten derselben Tabelle aktualisieren und entsprechend ihren eigenen Sequenzfeldern zusammenführen, was konkurrierende Echtzeit-Updates sowie Offline-Auffüllungen unterstützt.

Routine Load: Flexible Teil-Updates an nicht-primärschlüsselbehafteten Spalten, dynamische Parameteranpassungen sowie adaptive Batching-Verfahren steigern die Stabilität bei hohem Durchsatz.

Import-Auditing: Die Aktivitäten von Stream Load können in die Auditsystemtabelle protokolliert werden, sodass Historie, Fehlerbehebung und Audits an einem Ort abgefragt werden können.

TIMESTAMPTZ

Globale Arbeitslasten wie cross-regionale Logs, Analysen des Benutzerverhaltens und Finanztransaktionen beinhalten explizit angegebene Zeitzonen. Mit einem zonenlosen DATETIME findet die Umrechnung in der Anwendung statt, was zu Fehlern und zusätzlicher Entwicklungsaufwand führt. Doris 4.1 stellt TIMESTAMPTZ (Zeitstempel mit Zeitzone) zur standardmäßigen, zeitzonebewussten Verarbeitung vor:

• Die Werte werden beim Schreiben in UTC gespeichert,
• Lesungen werden in die Zeitzone umgerechnet, die von der Sitzung verwendet wird,
• Eingaben mit oder ohne Zeitzone werden automatisch analysiert und umgerechnet, und
• TIMESTAMPTZ sowie DATETIME können untereinander umgewandelt werden und funktionieren mit bestehenden Funktionen.

Dadurch wird die Zeitzone-Verarbeitung aus dem Anwendungscode in den Datenbankkern verlagert, was die Konsistenz zwischen Systemen verbessert und die Komplexität bei mehrzeitzonenbezogenen Daten verringert.

Was das bedeutet

Insgesamt stellt 4.1 einen bedeutenden Schritt dar, um Doris als zentrale Datenschicht für KI-Anwendungen und Echtzeit-Analysen zu etablieren: Der IVF-Index erweitert die Vektorabfrage auf weitaus größere Datensammlungen, 100 MB große JSON-Dokumente ermöglichen Gespräche mit langen Kontexten, und die Leistung von OLAP-Systemen sowie Lakehouses zeigt im Vergleich zu 4.0 messbare Verbesserungen. Es handelt sich dabei um eine Infrastruktur für Vektorabfragen, Volltextsuche, Echtzeit-Analysen sowie Lakehouses, wodurch weniger eigenständige Vektordatenbanken, Suchmaschinen und Abfragesysteme benötigt werden. Ob diese Konsolidierung sich lohnt, hängt von Ihrer Skalierung, Ihren Latenzzielen sowie davon ab, wie sich die vom Anbieter gemeldeten Werte in Ihrer eigenen Arbeitslast verhalten.