Apache Doris 4.1 : Recherche vectorielle, stockage JSON, OLAP et Lakehouse

Apache Doris 4.1 reprend la lignée de la version 4.0, celle qui a introduit la recherche vectorielle, la recherche hybride ainsi que la fonction search() afin de permettre au projet de servir les agents d’IA, les systèmes RAG, les outils d’observabilité pour l’IA et les analyses en temps réel. La version 4.1 poursuit dans la même direction et vise à faire en sorte qu’un seul moteur gère à la fois le stockage et la récupération des données pour les charges de travail liées à l’IA et aux recherches. Les notes de version mettent en avant les problèmes auxquels se heurtent les équipes lorsqu’elles déplacent des applications d’IA en production :

• rendre abordables de grandes quantités de données d’IA,
• combiner la recherche vectorielle, la recherche de texte complet et les filtres structurés dans un seul système,
• intégrer des documents longs et des enregistrements semi-structurés volumineux dans une seule table,
• répondre en temps réel aux requêtes et aux questions d’observabilité pour les LLM, les agents et les systèmes RAG,
• préserver la vitesse d’exécution typique du projet en matière de OLAP et de lakehouse, et

Fusion des gros lots ETL avec des pipelines en temps réel.

Voici les points principaux :

• Recherche vectorielle : de nouveaux index IVF et IVF_ON_DISK conçus pour des collections de l’ordre du milliard de documents ou plus.
• Recherche de texte intégral : la fonction search() intègre maintenant un système de notation BM25 ainsi qu’une syntaxe compatible avec Elasticsearch.
• Stockage de contextes longs : un seul document JSON peut désormais atteindre 100 MB, ce qui est adapté à la mémoire des agents et aux travaux nécessitant de longs contextes.
• Vitesse OLAP : le projet affiche des améliorations de 22,6 % sur TPC-H, 19,1 % sur TPC-DS et 14,3 % sur SSB, avec la première place pour les requêtes froides sur ClickBench.
• Lake de données : lecture et écriture pour Apache Iceberg V2/V3, DDL pour Apache Paimon via SQL, ainsi qu’un cache de pages Parquet offrant une économie d’environ 20 %.
• Séparation des calculs et du stockage : un mode qui, selon le projet, est utilisé par plus de 2 000 entreprises, offrant une meilleure visibilité du cache, de l’élasticité et un comportement optimal pour les requêtes froides.

Tous les chiffres de performance ci-dessous proviennent de l’annonce officielle du projet ; considérez-les donc comme des données fournies par le fabricant et vérifiez-les à l’aide de vos propres données.

1. Intelligence artificielle et recherche

Recherche vectorielle

IVF s’ajoute à HNSW. La version 4.0 proposait HNSW comme index vectoriel. La version 4.1 ajoute IVF (fichier inversé) pour des ensembles de données plus importants. L’idée est de regrouper les vecteurs à l’avance en buckets, puis de ne consulter que ceux qui sont susceptibles d’abriter des voisins, au prix d’une légère perte de précision pour un gain significatif en vitesse. Par rapport à HNSW, IVF permet de gérer des collections plus grandes avec moins de mémoire, mais à un coût d’un taux de rappel légèrement inférieur. Vous pouvez l’activer en définissant "index_type"="ivf" dans les propriétés de l’index :

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. Des bibliothèques comme Faiss fonctionnent bien jusqu’à des dizaines de millions de vecteurs, car elles conservent tout l’index en RAM. Lorsque le nombre de vecteurs atteint des dizaines de milliards, les coûts en mémoire augmentent fortement. Doris a développé IVF_ON_DISK sur la base d’IVF, en suivant l’approche de la recherche SPANN de Microsoft, et combine un cache en mémoire avec un cache du système de fichiers local afin de supprimer efficacement et à moindre coût les vecteurs inutiles.

• Grâce à la séparation entre calcul et stockage, cela permet une suppression et un rappel rapides et peu coûteux à très grande échelle.
• Par rapport à DiskANN, la création de l’index coûte nettement moins cher, ce qui offre une solution réaliste pour des recherches à l’échelle de trillions de vecteurs.
• Ses applications possibles incluent les bases de connaissances basées sur l’IA, le rappel de recommandations et les grands entrepôts d’embeddings.

Passer à cette solution est presque identique à l’utilisation d’IVF, avec "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");

Quantification. En plus de l’algorithme d’indexation, trois méthodes de quantification sont prises en charge : scalaire INT8, scalaire INT4 et quantification par produit (PQ). Pour réduire légèrement la perte en termes de précision, elles réduisent l’index à un quart ou un huitième de sa mémoire initiale, et en combinaison avec IVF_ON_DISK elles diminuent encore les coûts matériels pour les grands systèmes de recherche. Le DDL ci-dessous montre la compression PQ sur des vecteurs à 128 dimensions :

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

Requêtes plus rapides. Une nouvelle optimisation appelée « Ann Index Only Scan » permet à une requête vectorielle d’éviter les opérations d’entrée/sortie disque sur les colonnes brutes, ce qui réduit considérablement la charge supplémentaire. Le projet affirme que les requêtes d’index vectoriel fonctionnent jusqu’à quatre fois plus vite qu’en version 4.0. Lors d’un test avec un million de vecteurs sur une machine à 16 cœurs et 64 Go, Doris atteindrait environ 900 QPS avec un taux de rappel de 97 %, ce qui est suffisant pour la plupart des opérations de recherche en production.

L’annonce cite également des chiffres publics de VectorDBBench (en janvier 2026) selon lesquels Doris crée des index vectoriels plus rapidement que Milvus, Qdrant et pgvector, grâce à son architecture de couchage des données. En version 4.1, les vecteurs sont regroupés en lots dans la mémoire lors de leur création, et l’index est construit lot par lot, ce qui améliore le parallélisme de construction sans nuire à la qualité de l’index.

La fonction search()

Lorsque la recherche vectorielle gère le rappel sémantique, la recherche de texte complet s’occupe de la recherche par mots-clés, du dépannage, de la recherche dans les journaux et de l’analyse de texte. La nouvelle fonction search() l’intègre à SQL afin qu’une seule requête puisse filtrer et agréger en même temps.

• Elle accepte la syntaxe query_string d’Elasticsearch, ce qui devrait faciliter les migrations hors d’Elasticsearch.
• Les opérateurs incluent TERM, PHRASE, WILDCARD, REGEXP, PREFIX, NOT et NESTED, tous pouvant être imbriqués et combinés.
• Le scoring de pertinence BM25 est intégré, avec une optimisation TopN au niveau du stockage afin que l’ensemble des ensembles de résultats ne soit pas transféré inutilement.
• En combinaison avec le type VARIANT, NESTED peut examiner des tableaux JSON imbriqués.

La recherche multi-champs prend en charge best_fields (une correspondance précise au sein d’un seul champ) et cross_fields (une correspondance répartie sur plusieurs champs).

Une requête typique ressemble à ceci :

-- 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() renvoie un prédicat booléen, ce qui lui permet de participer à des jointures, des fonctions de fenêtre et des sous-requêtes, faisant ainsi de la recherche plein texte une partie intégrante de SQL.

Documents JSON allant jusqu’à 100 MB

Les agents d’IA, les systèmes RAG ainsi que les applications à plusieurs échanges et à long contexte souhaitent de plus en plus conserver le contexte des interactions dans un seul endroit. Doris 4.1 prend en charge les lignes individuelles contenant des documents JSON d’une taille allant jusqu’à 100 MB, ce qui permet aux données de toute une session d’être stockées dans la base de données : conversations à plusieurs échanges, textes longs, transcriptions audio et vidéo, traces des exécutions des agents, journaux des appels aux outils, ainsi que le contexte utilisé pour RAG. Aucun document n’a besoin d’être divisé, tronqué ou transféré vers un stockage externe. Une fois enregistrés, ces documents se comportent comme les autres données, permettant l’utilisation de filtres, de requêtes conditionnelles, d’agrégations et de jointures, ce qui transforme un contexte d’IA volumineux en un actif structuré et consultable.

Selon le projet, stocker de gros fichiers JSON de cette manière permet aux équipes :

• d’éviter la dépendance à un stockage d’objets distinct,
• de se passer de la logique nécessaire pour maintenir la cohérence entre les métadonnées et le contenu brut,
• d’échapper aux tâches liées au stockage en tranches et à leur réassemblage, et
• d’obtenir une latence de requête plus faible, des garanties transactionnelles plus solides et des opérations simplifiées.

Segment V3 et tables étendues

Les charges de travail liées à la recherche et à l’IA génèrent généralement des données semi-structurées, étendues et sparses, avec de nombreux champs, des schémas changeants ainsi que des modèles d’accès clairement différenciés entre données fréquemment consultées et données moins utilisées. Ces cas nécessitent des lectures aléatoires performantes, des recherches ciblées et des écritures concurrentes intensives.

Au préalable à la version 4.1, Doris utilisait le format Segment V2, qui stocke les métadonnées dans la partie inférieure du fichier. Cela convient aux scans par lots, mais les lectures aléatoires et les requêtes sur de courtes plages doivent charger l’intégralité de cette partie inférieure à chaque fois, ce qui augmente la consommation en E/S disque et les coûts de parsing.

Le segment V3, influencé par des formats plus récents tels que Lance et Vortex, sépare les métadonnées du pied de page et les charge sur demande. Il vise à réduire l’encombrement des métadonnées, les temps d’ouverture lents des fichiers ainsi que la charge liée aux lectures aléatoires intensives. Les cas d’usage potentiels incluent les tables étendues, celles remplies de sous-colonnes VARIANT, les tâches où la latence de démarrage sur le stockage d’objets est un problème, ainsi que les données semi-structurées pour l’intelligence artificielle ou la télémétrie de véhicules qui sont fréquemment lues de manière aléatoire. Sur une table comptant 7 000 colonnes et 10 000 segments, V3 permettrait une ouverture jusqu’à 16 fois plus rapide et consommerait jusqu’à 60 fois moins de mémoire. Pour l’activer, définissez "storage_format" = "V3" dans les propriétés de la table :

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

Colonnes sparses

Les JSON de grande taille présentent généralement une longue série de chemins rarement consultés ainsi que quelques chemins très fréquents. Doris 4.1 réorganise le mécanisme de lecture sparsa afin que cette longue série ne crée pas de goulot d’étranglement pour une seule colonne sparsa.

• Séparation chemins fréquents/chemins rares : les chemins utilisés fréquemment restent sous forme de sous-colonnes, tandis que les chemins peu utilisés sont stockés de manière sparsa, ce qui empêche l’augmentation exponentielle du nombre de sous-colonnes.
• Sharding sparsa : variant_sparse_hash_shard_count répartit les chemins peu utilisés sur plusieurs colonnes sparses, réduisant ainsi l’amplification des lectures sur n’importe quelle colonne en particulier.
• Caché sparsa : un cache de lecture pour les colonnes sparses diminue les opérations d’entrée/sortie disque répétées, ainsi que le décodage et la désérialisation.

Cela convient aux JSON de grande taille provenant de la télémétrie des véhicules, des profils d’utilisateurs et des journaux d’événements, là où un enregistrement contient de nombreux champs mais seuls quelques dizaines ou quelques centaines de chemins font l’objet de requêtes fréquentes :

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

Mode DOC

Lorsque la priorité est donnée à l’efficacité de l’écriture ou au récupération de documents JSON complets, le mode DOC est le choix optimal. Il conserve le JSON brut au moment de l’écriture et reporte l’extraction des sous-colonnes à la phase de compactage, ce qui réduit les coûts d’écriture et l’amplification des données.

• Matérialisation différée : le JSON brut est conservé lors de l’écriture, ce qui diminue la charge de travail pour de petits lots.
• Sharding DOC : variant_doc_hash_shard_count divise le Doc Store en plusieurs shards, ce qui facilite à la fois la lecture des documents complets et l’extraction des chemins.
• Seuil : variant_doc_materialization_min_rows définit le moment à partir duquel la matérialisation commence ; les lots plus petits attendent jusqu’à la phase de compactage.

Celui-ci vise les sorties des LLM, les données de suivi, les captures de contexte ainsi que la répétition d’événements, des charges de travail qui renvoient souvent des documents complets. Pour le configurer, activez variant_enable_doc_mode, puis ajustez la seuil et le nombre de shards en fonction du volume de vos données. Le mode DOC et les colonnes sparses s’excluent mutuellement, il faut donc en choisir un seul et l’associer à 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 plus rapide

Doris s’est fait un nom grâce à un OLAP rapide en temps réel, et la version 4.1 continue d’améliorer ce aspect en réduisant les calculs inutiles, en transférant moins de données et en exécutant plus efficacement, afin que les requêtes complexes restent rapides même sous des charges réalistes.

Benchmarks multi-tables et tables larges

Au sein des suites standard de jointures et d’agrégations, cette version affiche les améliorations suivantes par rapport à 4.0 : 22,6 % sur TPC-H, 19,1 % sur TPC-DS et 14,3 % sur SSB.

Pour les tables larges, ClickBench utilise 100 GB de données et 43 requêtes complexes pour mettre à l’épreuve le stockage colonne par colonne, l’exécution vectorisée et la compression, ce qui en fait l’un des benchmarks les plus exigeants pour une seule table. Sur les instances c7a.metal-48xl, Doris 4.1 occupe la première place pour les requêtes froides et en termes d’espace de stockage, ainsi que la deuxième place au total, devancé uniquement par ClickHouse (web).

Les optimisations à l’origine de ces résultats sont décrites ci-après.

Pushdown des agrégations via les jointures

Cette optimisation divise les agrégations lourdes et les exécute des deux côtés d’une jointure. Chaque table est agrégée localement, les résultats simplifiés sont ensuite joints, et l’agrégation globale a lieu en dernier. Compresser les données d’abord puis effectuer la jointure réduit le volume de données traitées, ce qui a un impact significatif sur la mémoire et la latence. Lors des tests du projet, les performances globales ont augmenté de plus de 200 % ; dans plus de la moitié des cas, l’amélioration a dépassé 50 %, et près d’un tiers a vu une amélioration de plus de 100 fois.

Grouper les ensembles

L’engine identifie désormais le groupe au niveau de granularité le plus fin ainsi que son taux d’agrégation, et change de stratégie : au lieu d’agréger de nombreux groupes en parallèle, il adopte un plan en deux étapes — d’abord effectuer l’agrégation la plus détaillée pour réduire les données, puis dériver les autres groupes à partir de ce résultat. L’amélioration globale constatée dépasse 10 %, avec plus d’un cinquième des cas affichant une amélioration supérieure à 20 %, un meilleur résultat atteignant 160 % et une régression la plus mauvaise inférieure à 5 %.

Élagage des colonnes imbriquées

L’engine comprend désormais plus précisément la structure des champs imbriqués. Lorsqu’une requête ne concerne qu’un seul sous-champ, seuls les données pertinentes sont lues et le reste est ignoré, ce qui permet d’économiser les opérations d’entrée/sortie disque. Dans la version 4.1, cette fonctionnalité fonctionne tant pour les tables internes que pour les données ORC et Parquet externes. L’amélioration globale constatée dépasse 60 %, et atteint plus de 700 % dans les cas extrêmes.

Caché des conditions

L’analyse à grande échelle réutilise souvent les mêmes filtres d’une requête à l’autre :

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

Exécuter à plusieurs reprises un filtre identique sur les mêmes segments consomme de la puissance CPU et des ressources d’entrée/sortie disque. Le cache de conditions stocke le résultat du filtre pour chaque segment en vue de futures requêtes, réduisant ainsi les analyses et les calculs redondants. Pour les charges de travail de requêtes complexes, l’amélioration obtenue dépasse 10 %.

Cache de requêtes

Les charges de travail analytiques répètent également la même agrégation sur des données inchangées :

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

Chaque exécution scanne les mêmes tablettes et recalcule les mêmes agrégats. Le cache de requêtes conserve les résultats d’agrégation intermédiaires et, lorsque le contexte de la requête correspond, les restitue directement, ce qui permet d’économiser des ressources de calcul et des opérations d’entrée/sortie disque.

CASE WHEN

CASE WHEN est une construction fondamentale pour la classification commerciale, la logique au niveau des lignes et l’agrégation conditionnelle. La version 4.1 ajoute la fusion de branches, l’élimination de branches, l’extraction de sous-expressions communes, ainsi que l’extraction et le transfert vers le bas des valeurs enum. Sur l’ensemble de tests, l’amélioration moyenne est supérieure à 200 %, avec des valeurs extrêmes dépassant 50 fois.

3. Séparation du calcul et du stockage

D’après le projet, l’architecture de séparation du calcul et du stockage fonctionne désormais pour plus de 2 000 utilisateurs en production, ce qui a fait de la stabilité et des performances des requêtes les principaux axes d’attention.

Cache de fichiers

Les métadonnées du cache de fichiers sont maintenant persistées, ce qui évite les opérations lourdes d’entrée/sortie disque que les versions précédentes devaient effectuer pour reconstituer l’état du cache au démarrage. Une nouvelle table système, information_schema.file_cache_info, affiche les détails du cache au niveau des blocs via SQL et peut être consultée en fonction de tablet_id, be_id, cache_path et type. Cela facilite la recherche de données fréquemment utilisées, le diagnostic des caches déséquilibrés et la détection d’une croissance anormale.

Une utilisation possible consiste à examiner la composition du cache d’une seule tablette :

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

Une autre méthode consiste à regrouper les données de distribution afin d’évaluer l’équilibre et l’utilisation des ressources entre les nœuds 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;

Elasticité, requêtes froides et bien plus encore

• Echelle élastique : dans ce mode, les opérations d’échelle sur des millions de tablettes s’achèvent en quelques minutes, car le planification ne dépend plus du nombre total de tablettes.
• Requêtes froides : le préchargement basé sur la sémantique de balayage des pages de Doris accélère les requêtes froides sur les tables internes, et l’ajustement des paramètres permet à Doris d’utiliser davantage de bande passante du stockage distant.
• Déploiements à grande échelle : les objets de réplique et de tablette dans le FE ont été simplifiés, réduisant l’utilisation de la mémoire du FE de plus de 30 % même avec des millions de tablettes.
• Métaservice : une couche de mise en cache diminue les requêtes répétées vers le Métaservice et augmente le débit des métadonnées, de plus les chemins d’accès à certaines tables système ont été optimisés.

Cost de stockage des objets : pour les importations fréquentes, le regroupement des requêtes au niveau du nœud réduit le nombre de demandes de stockage d’objets ainsi que la taille des fichiers ; selon le projet, les coûts globaux peuvent chuter de jusqu’à 90 %.

Compression et encodage : un encodage binaire plus efficace associé à un pré-décodage diminue les coûts de décodage en temps réel, et l’algorithme de compression par défaut passe progressivement à ZSTD afin d’équilibrer le rapport qualité/vitesse de décompression. Pour les tables étendues et détaillées, cela se traduit par un stockage réduit et de meilleures performances lors des lectures en mode « froid ».

4. Data lakehouse

La version 4.1 améliore les capacités du lakehouse en termes de couverture des formats, de vitesse de requête et de compatibilité avec l’écosystème. Grâce à Doris SQL, vous pouvez lire, écrire et gérer les principaux formats de tables ouverts tels qu’Apache Iceberg et Apache Paimon uniquement avec Doris SQL, sans avoir recours à Spark ou à un autre moteur externe.

Gestion du cycle de vie

La création de tables, l’insertion, la mise à jour et la suppression s’effectuent toutes via Doris SQL, de sorte qu’un seul moteur couvre l’ensemble du flux de travail lié aux données.

• Lecture et écriture Iceberg V2/V3 : INSERT, UPDATE, DELETE et MERGE INTO sont pris en charge, ainsi que les fonctionnalités V3 telles que le Deletion Vector et le Row Lineage. L’ingestion, les mises à jour et les suppressions s’effectuent en continu sans recourir à d’autres moteurs.
• Gestion de Paimon : CREATE DATABASE, CREATE TABLE et d’autres commandes DDL s’exécutent directement dans Doris SQL. L’écriture dans les tables Paimon est prévue pour des versions ultérieures.

Performance des requêtes sur les données stockées

• Écritures triées Iceberg : les données peuvent être écrites dans un ordre de tri choisi, ce qui génère des métadonnées triées (limites inférieure et supérieure) que le moteur utilise pour filtrer les fichiers. Sur TPC-DS, cela permettrait d’améliorer les performances des requêtes d’environ 15 %.

Mémorisation des manifestes d’iceberg : la mise en cache des métadonnées au niveau du manifeste évite les lectures et analyses répétées pendant la planification, réduisant ainsi l’activité d’entrée/sortie disque et la consommation de CPU. En cas de requêtes fréquentes, la résolution des métadonnées complexes prendrait selon certains rapports entre cent et quelques centaines de millisecondes.

Mémorisation en cache des pages Parquet : les pages décompressées sont mémorisées en mémoire, ce qui diminue les opérations de décompression répétées et les lectures disque, faisant chuter notablement la latence lors de requêtes fréquentes. Sur ClickBench, les performances globales ont augmenté d’environ 20 %.

Utilisabilité de l’analyse fédérée

• Contrôle d’accès au cache : des règles au niveau de l’utilisateur, du catalogue, de la base de données et de la table déterminent quelles requêtes peuvent écrire dans le cache, empêchant ainsi les données peu fréquentées d’évincer les données fréquemment utilisées et augmentant le taux de réussite pour les points chauds. Ces règles se trouvent dans des fichiers JSON situés dans un répertoire spécifié, qui sont rechargés en temps réel en cas de modification, sans nécessiter de redémarrage du front-end, et l’instruction EXPLAIN affiche les décisions prises concernant l’accès, ce qui permet d’observer les ajustements à effectuer.
• Écritures dans MaxCompute : les commandes CREATE TABLE et INSERT fonctionnent désormais dans le catalogue externe de MaxCompute, complétant ainsi le chemin d’exportation depuis Doris vers MaxCompute. L’accès entre comptes via ARN est pris en charge, ce qui facilite l’intégration avec l’écosystème Alibaba Cloud.

Vérification des métadonnées du parquet : une nouvelle fonction à valeur de tableau expose les statistiques des partitions, des groupes de lignes et des colonnes via SQL, ce qui est utile pour déboguer la structure des fichiers, vérifier le tri des partitions et optimiser les requêtes.

5. Traitement par lots

Doris s’efforce constamment d’unifier l’analyse interactive et le traitement de gros volumes en un seul moteur, ce qui réduit la complexité architecturale liée à l’exécution de plusieurs systèmes en parallèle. La version 4.1 renforce encore les fonctionnalités ETL et ELT natives.

MERGE INTO

Une seule instruction SQL standard MERGE INTO gère les opérations INSERT, UPDATE et DELETE (upsert), ce qui simplifie les tâches de fusion incrémentale telles que le CDC et diminue les efforts de développement et de maintenance :

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

Déversement vers le disque amélioré

Les jointures volumineuses, les agrégations à haute cardinalité et les triages globaux consomment beaucoup de mémoire, et la version 4.1 étend le déversement vers le disque à ces opérateurs :

• le déversement récursif à plusieurs niveaux permet aux données intermédiaires de passer par plusieurs étapes, évitant ainsi une pression mémoire soudaine,
• cela fonctionne avec les opérateurs de JOIN, d’agrégation et de tri,
• le déclenchement dynamique du déversement équilibre l’utilisation de la mémoire et les opérations d’entrée/sortie sur disque pour maintenir la stabilité des requêtes.

Avec ces modifications, le projet affirme que Doris peut exécuter toutes les requêtes TPC-DS de 10 TB sur un seul nœud BE disposant de 8 GB de mémoire, ce qui représente selon eux des performances supérieures à un coût en ressources inférieur par rapport aux configurations traditionnelles basées sur Hadoop, Greenplum ou Spark. Comme pour tous les chiffres présentés ici, il s’agit d’une affirmation qu’il convient de vérifier soi-même.

6. Utilisabilité

La version 4.1 complète la syntaxe analytique, améliore l’expressivité dans les scénarios complexes et travaille à la compatibilité avec d’autres systèmes.

Extensions du moteur d’exécution

UNNEST. La fonction UNNEST native simplifie l’analyse des tableaux et des structures imbriquées dans les données JSON et de journalisation, sans nécessiter de réécritures complexes des fonctions :

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

CTE récursive. Vous pouvez maintenant écrire des requêtes récursives pour parcourir les organigrammes, les hiérarchies et les chemins de graphe, ou pour analyser d’autres relations nécessitant un parcours :

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;

JOIN ASOF. Ce type de jointure utilise la correspondance la plus proche dans une colonne temporelle (<= ou >=), utile pour les charges de travail financières, IoT et de surveillance qui nécessitent un alignement des séries temporelles ainsi que des recherches de la valeur la plus proche :

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

Ingestion et chemin d’écriture

• Import continu depuis S3 : il est possible de créer des tâches continues à partir de sources S3, et le système détecte les nouveaux fichiers pour continuer leur importation, ce qui permet une ingestion incrémentale depuis le stockage d’objets.
• Synchronisation avec MySQL et PostgreSQL : Doris peut désormais se mettre à jour en temps réel depuis MySQL et PostgreSQL, gérant à la fois l’initialisation complète et la synchronisation incrémentale. Cela simplifie la création de pipelines en temps réel à partir de bases de données opérationnelles, pour le stockage en temps réel, la consolidation des données et l’accélération de l’analyse.

Écriture et mise à jour des modèles

• Planification adaptative des écritures : le pool de threads d’effacement des MemTable s’adapte à la charge du cluster et ajuste la concurrence des écritures en fonction des conditions actuelles, améliorant ainsi le débit, l’utilisation des ressources et la stabilité en cas d’écritures intensives.

Mises à jour multi-flux sur le modèle de clé primaire : sequence_mapping permet de fusionner les mises à jour provenant de plusieurs flux. Différents flux peuvent mettre à jour différentes colonnes d’une même table et être fusionnés en fonction de leurs propres champs de séquence, ce qui convient aux mises à jour en temps réel concurrentes ainsi qu’aux remplissages hors ligne.

Charge de routine : mises à jour partielles flexibles sur des colonnes non clés primaires, modifications dynamiques de paramètres et agrégation adaptative qui améliorent la stabilité à un fort débit.

Auditing des importations : les activités de Stream Load peuvent être enregistrées dans la table du système d’audit, permettant ainsi d’accéder à l’historique, aux outils de débogage et aux audits depuis un même endroit.

TIMESTAMPTZ

Les charges de travail mondiales telles que les journaux inter-régions, l’analyse du comportement des utilisateurs et les transactions financières impliquent explicitement des zones horaires. Avec un DATETIME sans zone, la conversion s’effectue dans l’application, ce qui favorise les erreurs et nécessite un développement supplémentaire. Doris 4.1 introduit TIMESTAMPTZ (timestamp avec zone horaire) pour une gestion standard tenant compte des zones horaires :

• les valeurs sont stockées en UTC au moment de l’écriture,
• les lectures sont converties en fonction de la zone horaire utilisée par la session,
• les entrées avec ou sans zone sont analysées et converties automatiquement, et
• TIMESTAMPTZ et DATETIME peuvent être convertis l’un en l’autre et fonctionner avec les fonctions existantes.

Cela permet de déplacer la gestion des zones horaires hors du code de l’application et vers le noyau de la base de données, améliorant ainsi la cohérence entre les systèmes et réduisant la complexité pour les données multi-zones.

Quelles en sont les conséquences

Dans son ensemble, la version 4.1 représente une avancée significative pour positionner Doris comme couche de données centrale pour les applications d’IA et l’analyse en temps réel : l’index IVF étend la recherche vectorielle à des collections bien plus grandes, les documents JSON de 100 MB permettent des conversations à long contexte, et les performances en OLAP ainsi qu’en lakehouse affichent des améliorations mesurables par rapport à 4.0. L’objectif est de disposer d’une seule infrastructure pour la recherche vectorielle, la recherche plein texte, l’analyse en temps réel et le lakehouse, afin de réduire le nombre de bases de données vectorielles, de moteurs de recherche et de moteurs de requêtes indépendants nécessaires. Le fait que cette consolidation soit rentable dépendra de l’échelle de votre activité, de vos objectifs en matière de latence et de la fiabilité des chiffres communiqués par le fournisseur dans votre propre environnement de travail.