Apache Doris 4.1: Búsqueda vectorial, almacenamiento en JSON, OLAP y Lakehouse

Apache Doris 4.1 sigue la línea de la versión 4.0, la que introdujo la búsqueda vectorial, la búsqueda híbrida y la función search() al proyecto para que pudiera servir a agentes de IA, RAG, sistemas de observabilidad de IA y análisis en tiempo real. La versión 4.1 avanza en la misma dirección con el objetivo de que un único motor gestione tanto el almacenamiento como la recuperación de datos para cargas de trabajo de IA y búsqueda. Las notas de lanzamiento se centran en los problemas que enfrentan los equipos al llevar aplicaciones de IA a producción:

• mantener volúmenes grandes de datos de IA a un costo razonable,
• combinar la búsqueda vectorial, la búsqueda de texto completo y los filtros estructurados en un solo sistema,
• incorporar documentos largos y registros semiestructurados extensos en una sola tabla,
• responder consultas en tiempo real y preguntas relacionadas con la observabilidad para LLMs, agentes y RAG,
• mantener la velocidad de OLAP y lakehouse por la que es conocido el proyecto, y

Combinación de procesos ETL a gran escala con pipelines en tiempo real.

Los puntos más destacados son los siguientes:

• Búsqueda vectorial: nuevos índices IVF e IVF_ON_DISK diseñados para colecciones de mil millones de elementos o más.
• Búsqueda de texto completo: la función search() ahora incluye puntuación BM25 y sintaxis compatible con Elasticsearch.
• Almacenamiento de contexto largo: un único documento JSON puede alcanzar ahora 100 MB, destinado al almacenamiento de memoria de agentes y a trabajos que requieren contexto extenso.
• Velocidad OLAP: el proyecto reporta mejoras de hasta 22.6% en TPC-H, 19.1% en TPC-DS y 14.3% en SSB, además de ocupar el primer lugar en consultas “frías” en ClickBench.
• Lago de datos: lectura y escritura para Apache Iceberg V2/V3, DDL para Apache Paimon a través de SQL, y un caché de páginas en formato Parquet que aporta aproximadamente un 20% de mejora.
• Separación entre cómputo y almacenamiento: un modelo que, según el proyecto, se utiliza en más de 2,000 empresas, ofreciendo una mejor visibilidad del caché, elasticidad y comportamiento en consultas de datos poco utilizados.

Todos los valores de rendimiento que se presentan a continuación provienen del anuncio oficial del proyecto, por lo que deben considerarse cifras proporcionadas por el proveedor y verificarse con sus propios datos.

1. IA y búsqueda

Búsqueda vectorial

IVF se une a HNSW. La versión 4.0 ofrecía HNSW como su índice vectorial. La versión 4.1 añade IVF (archivo invertido) para conjuntos de datos más grandes. La idea es agrupar los vectores por adelantado en contenedores y luego buscar únicamente dentro de aquellos que tienen más probabilidades de contener vecinos, sacrificando algo de precisión a cambio de una gran mejora en la velocidad. En comparación con HNSW, IVF permite manejar colecciones más grandes con menos memoria, aunque a un costo de una recuperación ligeramente menor. Puedes activarlo estableciendo "index_type"="ivf" en las propiedades del índice:

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. Bibliotecas como Faiss funcionan bien con decenas de millones de vectores porque almacenan todo el índice en RAM. Al llegar a decenas de miles de millones, el costo de memoria aumenta drásticamente. Doris desarrolló IVF_ON_DISK sobre la base de IVF, siguiendo el enfoque de la investigación SPANN de Microsoft, y combina una caché en memoria con una caché en el sistema de archivos local para eliminar vectores de manera eficiente y económica.

• Gracias a la separación entre procesamiento y almacenamiento, permite una eliminación y recuperación rápidas y económicas a escala muy grande.
• En comparación con DiskANN, se dice que la creación del índice cuesta mucho menos, lo que ofrece una vía realista para búsquedas a escala de trillones.
• Es probable que se utilice en bases de conocimiento de IA, sistemas de recomendación y almacenamientos de embeddings a gran escala.

Cambiar a este método es casi igual que usar IVF, con "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");

Cuantización. Además del algoritmo de índice, se admiten tres métodos de cuantización: escalar INT8, escalar INT4 y cuantización por producto (PQ). Para reducir ligeramente la pérdida en el recuerdo, reducen el índice a entre una cuarta parte y una octava de su memoria original, y combinado con IVF_ON_DISK reducen aún más los costos de hardware en sistemas de recuperación a gran escala. El DDL a continuación muestra la compresión PQ en vectores de 128 dimensiones:

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

Consultas más rápidas. Una nueva optimización llamada “Ann Index Only Scan” permite que una consulta vectorial omita las operaciones de E/S en disco sobre las columnas originales, lo que reduce considerablemente la carga adicional. El proyecto afirma que las consultas con índices vectoriales son hasta cuatro veces más rápidas que en la versión 4.0. En una prueba con un millón de vectores en una máquina de 16 núcleos y 64 GB, se dice que Doris alcanza unos 900 QPS con un porcentaje de recuperación del 97%, lo cual es suficiente para la mayoría de las operaciones de búsqueda en producción.

El anuncio también menciona cifras públicas de VectorDBBench (a fecha de enero de 2026) según las cuales Doris crea índices vectoriales más rápido que Milvus, Qdrant y pgvector, atribuyéndolo a su arquitectura de capas de datos. En la versión 4.1, los vectores se agrupan en memoria durante su creación y el índice se construye por lotes, lo que aumenta el paralelismo sin afectar la calidad del índice.

La función search()

Mientras que la búsqueda vectorial se encarga de la recuperación semántica, la búsqueda de texto completo aborda la búsqueda por palabras clave, la resolución de problemas, la búsqueda en registros y el análisis de texto. La nueva función search() la integra en SQL para que una sola consulta pueda filtrar y agregar datos al mismo tiempo.

• Acepta la sintaxis de query_string de Elasticsearch, lo que debería facilitar la migración desde este sistema.
• Los operadores incluyen TERM, PHRASE, WILDCARD, REGEXP, PREFIX, NOT y NESTED; todos ellos pueden anidarse y combinarse entre sí.
• Está incorporado un sistema de puntuación de relevancia BM25, con optimización TopN en la capa de almacenamiento para que no se transmitan conjuntos completos de resultados.
• Junto con el tipo VARIANT, NESTED permite examinar arrays JSON anidados.

La búsqueda multi-campo admite best_fields (una coincidencia precisa dentro de un único campo) y cross_fields (una coincidencia distribuida en varios campos).

Una consulta típica se ve así:

-- 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() devuelve un predicado booleano, por lo que puede participar en uniones, funciones de ventana y subconsultas, lo que convierte la búsqueda de texto completo en una parte habitual de SQL.

Documentos JSON de hasta 100 MB

Los agentes de IA, los sistemas RAG y las aplicaciones de múltiples turnos con contexto extenso desean cada vez más almacenar todo el contexto de la interacción en un solo lugar. Doris 4.1 permite que una sola fila almacene documentos JSON de hasta 100 MB, de modo que todos los datos de la sesión pueden permanecer en la base de datos: conversaciones de múltiples turnos, textos largos, transcripciones de audio y video, registros de ejecuciones de agentes, logs de llamadas a herramientas y el contexto utilizado para RAG. No es necesario dividir, acortar ni mover estos datos a almacenamiento externo. Una vez escritos, estos documentos se comportan como cualquier otro dato, permitiendo el uso de filtros, consultas condicionales, agregaciones y uniones, convirtiendo así el voluminoso contexto de IA en un recurso estructurado y consultable.

Según el proyecto, almacenar grandes archivos JSON de esta manera permite a los equipos:

• evitar la dependencia de un almacén de objetos separado,
• omitar la lógica necesaria para mantener coherentes los metadatos y el contenido en bruto,
• saltarse el trabajo de almacenamiento por bloques y su posterior reensamblaje, y
• lograr una menor latencia en las consultas, garantías transaccionales más sólidas y operaciones más simples.

Segmento V3 y tablas amplias

Las cargas de trabajo de búsqueda e inteligencia artificial suelen generar datos amplios, dispersos y semiestructurados con muchos campos, esquemas cambiantes y patrones claros de acceso según si los datos son “calientes” o “fríos”. Estas aplicaciones necesitan lecturas aleatorias eficientes, búsquedas puntuales y escrituras concurrentes intensivas.

Antes de la versión 4.1, Doris utilizaba el formato Segmento V2, que guardaba los metadatos en el pie de página del archivo. Esto es adecuado para búsquedas por lotes, pero las lecturas aleatorias y las consultas de rango reducido deben cargar todo el pie de página cada vez, lo que incrementa la carga de E/S en disco y los costos de análisis.

El segmento V3, influenciado por formatos más recientes como Lance y Vortex, separa los metadatos del pie de página y los carga bajo demanda. Está diseñado para solucionar el exceso de metadatos, la lentitud al abrir archivos y la alta carga generada por lecturas aleatorias. Entre los casos de uso adecuados se encuentran tablas amplias, tablas repletas de subcolumnas VARIANT, tareas en las que la latencia al iniciar por primera vez el almacenamiento de objetos representa un problema, y datos semiestructurados de inteligencia artificial o telemetría de vehículos que se leen con frecuencia de forma aleatoria. En una tabla con 7,000 columnas y 10,000 segmentos, se dice que V3 permite abrirla hasta 16 veces más rápido y utiliza hasta 60 veces menos memoria. Para activarlo, establezca "storage_format" = "V3" en las propiedades de la tabla:

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

Columnas dispersas

El JSON de gran tamaño suele tener una larga lista de rutas poco consultadas y unas pocas muy utilizadas. Doris 4.1 modifica el mecanismo de lectura dispersa para que esta larga lista no genere cuellos de botella en una sola columna dispersa.

• Separación de rutas activas y pasivas: las rutas utilizadas con frecuencia permanecen como subcolumnas, mientras que las rutas poco consultadas se almacenan de forma dispersa, lo que evita que las subcolumnas aumenten en número.
• Sharding disperso: variant_sparse_hash_shard_count distribuye las rutas poco consultadas entre varias columnas dispersas, reduciendo la amplificación de lecturas en cualquiera de ellas.
• Caché disperso: un caché de lectura para columnas dispersas disminuye las operaciones repetidas en el disco, así como la decodificación y deserialización.

Esto es adecuado para JSON de gran tamaño proveniente de telemetría de vehículos, perfiles de usuarios y registros de eventos, en cualquier caso donde un registro tenga muchos campos pero solo unas docenas o unos pocos cientos de rutas reciban consultas frecuentes:

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

Modo DOC

Cuando la prioridad es la eficiencia en escritura o la recuperación de documentos JSON completos, el modo DOC es la mejor opción. Mantiene el JSON en bruto al momento de la escritura y pospone la extracción de subcolumnas hasta el proceso de compactación, lo que reduce los costos y la amplificación al escribir.

• Materialización diferida: el JSON en bruto se conserva al escribir, lo que disminuye la carga de trabajo en lotes pequeños.
• Sharding de DOC: variant_doc_hash_shard_count divide el Doc Store en varios shards, lo que facilita tanto la lectura de documentos completos como la extracción de rutas.
• Límite: variant_doc_materialization_min_rows determina cuándo se activa la materialización; los lotes más pequeños esperan hasta el proceso de compactación.

Está dirigido a las salidas de los LLM, los datos de seguimiento, las capturas de contexto y la reproducción de eventos, trabajos que a menudo devuelven documentos completos. Para configurarlo, active variant_enable_doc_mode, y luego ajuste el umbral y la cantidad de fragmentos según el volumen de sus datos. El modo DOC y las columnas dispersas se excluyen mutuamente, así que elija uno de ellos y úselo junto con 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 más rápido

Doris se hizo famosa por su OLAP rápido en tiempo real, y la versión 4.1 sigue mejorándolo al reducir el cálculo innecesario, transferir menos datos y ejecutar de manera más eficiente, de modo que las consultas complejas sigan siendo rápidas incluso bajo cargas reales.

Pruebas de rendimiento con múltiples tablas y tablas anchas

En pruebas estándar de unión y agregación, la versión actual muestra las siguientes mejoras respecto a 4.0: un 22.6% en TPC-H, un 19.1% en TPC-DS y un 14.3% en SSB.

Para tablas anchas, ClickBench utiliza 100 GB de datos y 43 consultas complejas para poner a prueba el almacenamiento columnar, la ejecución vectorizada y la compresión, lo que la convierte en una de las pruebas de rendimiento más exigentes para una sola tabla. En instancias c7a.metal-48xl, el proyecto indica que Doris 4.1 ocupa el primer lugar en consultas “frías” y en espacio de almacenamiento, y el segundo lugar en general, solo por detrás de ClickHouse (web).

A continuación se describen las optimizaciones que explican esas cifras.

Reducción de la agregación mediante uniones

Esta optimización divide las operaciones de agregación intensivas y las distribuye en ambos lados de una unión. Cada tabla se agrega localmente, los resultados reducidos se unen y la agregación global finaliza al final. Comprimir primero y unir después disminuye los datos que ingresan a la unión, lo que tiene un efecto notable en la memoria y la latencia. En las pruebas del proyecto, el rendimiento general aumentó en más del 200%; en más de la mitad de los casos se logró un aumento de más del 50%, y en casi un tercio, un aumento de más de 100 veces.

Agrupación de conjuntos

El motor ahora detecta el grupo de mayor detalle y su ratio de agregación, y cambia la estrategia de agregar muchos grupos en paralelo a un plan en dos pasos: primero completar la agregación más detallada para reducir los datos, y luego derivar los demás grupos a partir de ese resultado. La mejora general reportada es superior al 10%, con más de una quinta parte de los casos obteniendo un aumento de más del 20%, un caso óptimo del 160% y una regresión mínima inferior al 5%.

Recorte de columnas anidadas

El motor comprende con mayor precisión la estructura de campos anidados. Cuando una consulta solo afecta a un subcampo, solo se leen los datos relevantes y se omiten los demás, lo que ahorra operaciones de E/S en disco. En la versión 4.1 funciona tanto con tablas internas como con datos externos en formatos ORC y Parquet. La ganancia general reportada es superior al 60%, y superior al 700% en casos extremos.

Caché de condiciones

Los análisis a gran escala suelen reutilizar los mismos filtros de una consulta a otra:

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

Ejecutar un filtro idéntico una y otra vez sobre los mismos segmentos agota la CPU y la E/S del disco. El caché de condiciones almacena el resultado del filtro para cada segmento para consultas posteriores, reduciendo así los análisis y cálculos redundantes. En cargas de trabajo de consultas complejas, la mejora obtenida supera el 10%.

Caché de consultas

Las cargas de trabajo analíticas también repiten la misma agregación sobre datos inmutables:

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

Cada ejecución escanea las mismas tablas y vuelve a calcular los mismos agregados. El caché de consultas almacena los resultados intermedios de la agregación y, cuando el contexto de la consulta coincide, los devuelve directamente, lo que ahorra recursos de procesamiento y operaciones de E/S en disco.

CASE WHEN

CASE WHEN es una estructura fundamental para la clasificación empresarial, la lógica a nivel de fila y la agregación condicional. La versión 4.1 añade la fusión de ramas, la eliminación de ramas, la extracción de subexpresiones comunes, así como la extracción y aplicación directa de valores enum. En el conjunto de pruebas, el aumento promedio es superior al 200%, con valores extremos que superan las 50 veces.

3. Separación entre procesamiento y almacenamiento

Según el proyecto, la arquitectura de separación entre procesamiento y almacenamiento ya funciona para más de 2,000 usuarios en entornos de producción, por lo que la estabilidad y el rendimiento de las consultas se han convertido en las principales áreas de enfoque.

Caché de archivos

Los metadatos del caché de archivos ahora se persisten, lo que evita la intensa operación de E/S en el disco que requerían las versiones anteriores para reconstruir el estado del caché al iniciar. Una nueva tabla del sistema, information_schema.file_cache_info, muestra detalles del caché a nivel de bloque mediante SQL y puede consultarse por tablet_id, be_id, cache_path y type. Esto facilita encontrar datos frecuentemente utilizados, diagnosticar cachés desequilibrados y detectar un crecimiento anormal.

Un uso de esta función es inspeccionar la composición del caché de una sola tabla:

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

Otra opción es agregar la distribución para evaluar el equilibrio y el uso de recursos en los nodos 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;

Elasticidad, consultas frías y más

• Escala elástica: en este modo, las operaciones de escalamiento entre millones de tablets se completan en minutos, ya que la programación ya no depende del conteo total de tablets a nivel global.
• Consultas frías: la precarga basada en las semánticas de escaneo de páginas de Doris acelera las consultas frías en tablas internas, y el ajuste de parámetros permite a Doris utilizar una mayor parte del ancho de banda de almacenamiento remoto.
• Despliegues a gran escala: los objetos de réplica y tablet en el FE se simplificaron, reduciendo el uso de memoria del FE en más del 30% incluso con millones de tablets.
• Servicio meta: una capa de caché disminuye las solicitudes repetidas al Servicio Meta y aumenta el rendimiento de los metadatos, además de optimizarse las rutas de acceso a algunas tablas del sistema.

Costo de almacenamiento de objetos: en el caso de importaciones frecuentes, la fusión de solicitudes a nivel de nodo reduce la cantidad de solicitudes al almacenamiento de objetos y los archivos pequeños, y el proyecto indica que el costo total puede disminuir hasta en un 90%.

Compresión y codificación: una codificación binaria más eficiente con decodificación previa disminuye el costo de decodificación durante la ejecución, y el algoritmo de compresión predeterminado está pasando gradualmente a ZSTD para equilibrar la relación entre la compresión y la velocidad de descompresión. En el caso de tablas amplias y detalladas, esto debería significar un almacenamiento menor y lecturas más rápidas incluso cuando los datos no se utilizan con frecuencia.

4. Data lakehouse

La versión 4.1 impulsa las capacidades del lakehouse en términos de cobertura de formatos, velocidad de consultas y compatibilidad con el ecosistema. Con Doris SQL se pueden leer, escribir y gestionar los principales formatos de tablas abiertas como Apache Iceberg y Apache Paimon únicamente con Doris SQL, sin necesidad de Spark u otro motor externo.

Gestión del ciclo de vida

La creación de tablas, la inserción, actualización y eliminación se realizan todas a través de Doris SQL, por lo que un único motor cubre todo el flujo de trabajo del lake.

• Lectura y escritura en Iceberg V2/V3: Se admiten INSERT, UPDATE, DELETE y MERGE INTO, además de las funciones de V3 como Deletion Vector y Row Lineage. La ingesta, actualizaciones y eliminaciones se realizan de forma integral sin necesidad de motores externos.
• Gestión de Paimon: CREATE DATABASE, CREATE TABLE y otras instrucciones DDL se ejecutan directamente en Doris SQL. La escritura en tablas de Paimon está prevista para versiones futuras.

Rendimiento de las consultas en datos del lake

• Escripción ordenada de Iceberg: los datos pueden escribirse en un orden específico, lo que genera metadatos ordenados (límites inferior y superior) que el motor utiliza para filtrar archivos. En TPC-DS esto supone una mejora del rendimiento de las consultas de aproximadamente un 15%.

Almacenamiento en caché de manifiestos de icebergs: el almacenamiento en caché de los metadatos a nivel de manifiesto evita lecturas y análisis repetidos durante la planificación, reduciendo el uso de E/S del disco y la CPU. Según se informa, bajo consultas frecuentes, la resolución de metadatos complejos llega al rango de cientos de milisegundos.

Caché de páginas Parquet: las páginas descomprimidas se almacenan en caché en la memoria, lo que disminuye las descompresiones y lecturas del disco, y reduce notablemente la latencia en consultas frecuentes. En ClickBench, el rendimiento general aumentó en aproximadamente un 20%.

Usabilidad de la analítica federada

• Control de admisión al caché: las reglas en los niveles de usuario, catálogo, base de datos y tabla deciden qué consultas pueden escribir en el caché, evitando que los datos poco utilizados expulsen a los datos frecuentes y aumentando las tasas de éxito en los puntos críticos. Las reglas son archivos JSON en un directorio designado que se vuelven a cargar en tiempo real al modificarse, sin necesidad de reiniciar el servidor front-end, y EXPLAIN muestra las decisiones de admisión para poder observar el ajuste.
• Escribimientos en MaxCompute: CREATE TABLE y INSERT ahora funcionan en el catálogo externo de MaxCompute, completando así la ruta de exportación desde Doris a MaxCompute. Se admite el acceso entre cuentas mediante ARN, lo que facilita la integración con el ecosistema de Alibaba Cloud.

Inspección de metadatos de Parquet: una nueva función con valor de tabla expone estadísticas de particiones, grupos de filas y columnas a través de SQL, útil para depurar la estructura de los archivos, verificar el recorte de particiones y ajustar las consultas.

5. Procesamiento por lotes

Doris sigue intentando unificar el análisis interactivo y el procesamiento en grandes lotes en un único motor, lo que reduce la complejidad arquitectónica de ejecutar varios sistemas simultáneamente. La versión 4.1 refuerza aún más las capacidades nativas de ETL y ELT.

MERGE INTO

Una única instrucción SQL estándar MERGE INTO gestiona operaciones de INSERT, UPDATE y DELETE (un upsert), simplificando los trabajos de fusión incremental como el CDC y reduciendo el esfuerzo de desarrollo y mantenimiento:

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

Mejor manejo de datos en disco

Las uniones grandes, las agregaciones con alta cardinalidad y los ordenamientos globales consumen mucha memoria, y la versión 4.1 extiende este mecanismo a esos operadores:

• el vertido recursivo y multinivel permite que los datos intermedios pasen por varias etapas, evitando así una presión repentina en la memoria,
• funciona con operadores de JOIN, agregación y ordenamiento, y
• el activación dinámica del vertido equilibra el uso de memoria con la operación de E/S en disco para mantener estables las consultas.

Gracias a estos cambios, según el proyecto Doris puede ejecutar todas las consultas TPC-DS de 10 TB en un nodo BE con 8 GB de memoria, lo que se presenta como un rendimiento superior a un costo de recursos menor que en las configuraciones tradicionales de Hadoop, Greenplum o Spark. Como ocurre con todos los datos aquí presentados, se trata de una afirmación que vale la pena verificar por uno mismo.

6. Usabilidad

La versión 4.1 completa la sintaxis analítica, mejora la expresividad en escenarios complejos y trabaja en la compatibilidad con otros sistemas.

Extensiones del motor de ejecución

UNNEST. El UNNEST nativo simplifica el análisis de arrays y estructuras anidadas en datos JSON y de registros sin la necesidad de reescribir funciones de forma engorrosa:

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

CTE recursivo. Ahora puede escribir consultas recursivas para recorrer organigramas, jerarquías y rutas de gráfico, o para analizar otras relaciones que requieran recorrido:

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;

UNIÓN ASOF. Realiza la unión con la coincidencia más cercana a lo largo de una columna de tiempo (<= o >=), útil para cargas de trabajo financieras, de IoT y de monitoreo que necesitan alineación de series temporales y búsquedas del valor más cercano:

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

Ingestión y ruta de escritura

• Importación continua desde S3: se pueden crear tareas continuas a partir de fuentes en S3, y el sistema detecta nuevos archivos e impulsa su importación de forma continua, lo que permite una ingestión incremental desde el almacenamiento de objetos.
• Sincronización con MySQL y PostgreSQL: Doris ahora puede mantenerse actualizada en tiempo real a partir de MySQL y PostgreSQL, cubriendo tanto la inicialización completa como la sincronización incremental. Esto simplifica la creación de pipelines en tiempo real a partir de bases de datos operativas, para almacenamiento en tiempo real, consolidación de datos y aceleración de análisis.

Escribir y actualizar modelos

• Programación adaptativa de escrituras: el grupo de hilos de vaciado de MemTable se ajusta según la carga del clúster y equilibra la concurrencia de escrituras con las condiciones actuales, mejorando el rendimiento, el uso de recursos y la estabilidad ante grandes volúmenes de escrituras.

Actualizaciones multi-flujo en el modelo de clave primaria: sequence_mapping permite combinar actualizaciones provenientes de varios flujos. Diferentes flujos pueden actualizar columnas distintas de una misma tabla y fusionarse según sus propios campos de secuencia, lo cual es adecuado para actualizaciones en tiempo real concurrentes además de rellenos fuera de línea.

Carga rutinaria: actualizaciones parciales flexibles en columnas que no son clave primaria, cambios dinámicos de parámetros y agrupamiento adaptativo mejoran la estabilidad a altos volúmenes de trabajo.

Auditoría de importaciones: la actividad de Stream Load puede registrarse en la tabla del sistema de auditoría, de modo que el historial, la depuración y las auditorías comparten un mismo lugar para consultas.

TIMESTAMPTZ

Las cargas de trabajo globales como los registros entre regiones, el análisis del comportamiento de los usuarios y las transacciones financieras incluyen zonas horarias explícitas. Con un DATETIME sin zona, la conversión se realiza dentro de la aplicación, lo que genera errores y requiere más desarrollo. Doris 4.1 introduce TIMESTAMPTZ (marca de tiempo con zona horaria) para un manejo estándar que tenga en cuenta las zonas horarias:

• los valores se almacenan en UTC al escribirse,
• las lecturas se convierten a la zona horaria que utilice la sesión,
• la entrada, con o sin zona, se analiza y convierte automáticamente, y
• TIMESTAMPTZ y DATETIME pueden convertirse entre sí y funcionar con las funciones existentes.

Esto traslada el manejo de las zonas horarias del código de la aplicación al núcleo de la base de datos, mejorando la consistencia entre los sistemas y reduciendo la complejidad en el manejo de datos con múltiples zonas horarias.

Beneficios obtenidos

En conjunto, 4.1 representa un paso significativo hacia la posición de Doris como capa de datos esencial para aplicaciones de IA y análisis en tiempo real: el índice IVF extiende la búsqueda vectorial a colecciones mucho más grandes, los documentos JSON de 100 MB permiten conversaciones con contexto extenso, y el rendimiento de OLAP y lakehouse muestra mejoras medibles respecto a 4.0. La propuesta consiste en una única infraestructura para búsqueda vectorial, búsqueda de texto completo, análisis en tiempo real y lakehouse, lo que reduce la necesidad de bases de datos vectoriales, motores de búsqueda y motores de consultas independientes. Si esta consolidación rinde frutos dependerá de su escala, sus objetivos de latencia y de cómo se comporten las cifras reportadas por el proveedor en su propio trabajo de carga.

Lecturas relacionadas

• Diez errores silenciosos en la recuperación de información en RAG en producción, y cómo solucionar cada uno — Desde el tamaño y la superposición de los fragmentos hasta la búsqueda híbrida, RRF, el reclasificado, la elección de embeddings y las evaluaciones de CI: diez errores en la recuperación que causan respuestas incorrectas en RAG y sus soluciones.
• Medición de un pipeline RAG: tasa de aciertos, MRR y búsqueda híbrida — Cómo crear un conjunto de datos de referencia, evaluar la recuperación con tasa de aciertos y MRR, y comparar la búsqueda de texto, vectorial e híbrida en 360 preguntas.

Búsqueda híbrida para RAG: fusión de BM25, vectores y rango recíproco en la práctica — Por qué el RAG basado únicamente en vectores pierde identificadores exactos, cómo la RRF fusiona BM25 con embeddings, dónde la búsqueda híbrida rinde peor y por qué los filtros de metadatos deben aplicarse antes de la fusión.

Runbooks de búsqueda, no los pegues: un pequeño path RAG citado en LangChain — Crea un path de recuperación en dos pasos en LangChain: carga los runbooks, córtalos en fragmentos, realiza búsquedas con consultas específicas, conserva los metadatos, exige IDs de fuentes citadas y pruébalo sin embeddings pagados.

GraphRAG vs Vector RAG: Elegir una estrategia de recuperación según la pregunta — La búsqueda vectorial encuentra texto similar, pero las preguntas de múltiples pasos requieren relaciones. Aprenda cuándo es adecuado GraphRAG, la recuperación híbrida o por palabras clave, y cuánto cuesta ejecutar un grafo.