Configurar índices de rango y compuestos
Las aplicaciones de inteligencia artificial usan diversos patrones de recuperación de datos para ofrecer resultados a los usuarios. Una plataforma de búsqueda semántica puede filtrar documentos por tipo, ordenar los resultados por puntuación de relevancia y fecha y realizar búsquedas de similitud vectorial. Todas estas operaciones pueden producirse dentro de una sola solicitud de usuario. Cada patrón de consulta requiere configuraciones de índice específicas para ejecutarse de forma eficaz. Los índices mal diseñados obligan a Azure Cosmos DB a examinar particiones o contenedores completos, lo que aumenta considerablemente la latencia y el consumo de unidades de solicitud (RU). Entender cómo diseñar índices para patrones comunes de recuperación de IA te ayuda a construir aplicaciones que proporcionan un rendimiento consistente y rentable.
Diseñar índices de intervalo para las operaciones de filtro
Los índices de intervalo admiten las operaciones de filtro más comunes en las aplicaciones de inteligencia artificial. Las consultas que filtran documentos por tipo, estado, categoría, intervalos de fechas o umbrales numéricos usan índices de intervalo para buscar elementos coincidentes sin examinar todo el contenedor.
Considere una aplicación de búsqueda de documentos que almacena metadatos sobre los archivos cargados. Los usuarios filtran documentos por tipo (pdf, docx, image) y fecha de carga. La consulta siguiente usa índices de intervalo en ambas propiedades:
SELECT * FROM c
WHERE c.documentType = 'pdf'
AND c.uploadDate > '2024-01-01'
Cuando tanto documentType como uploadDate tienen índices de intervalo, Azure Cosmos DB utiliza los índices para buscar documentos coincidentes de forma eficaz. Sin índices, la consulta realiza un examen completo de la partición, que consume RU proporcionales al tamaño de los datos en lugar del tamaño del resultado.
Los índices de intervalo también admiten funciones de cadena que las aplicaciones de IA usan para la coincidencia de texto. Funciones como CONTAINS, STARTSWITHy ENDSWITH pueden usar índices de intervalo cuando la propiedad indizada aparece como primer argumento. Estas funciones permiten la coincidencia parcial de texto sin necesidad de infraestructura de búsqueda de texto completo.
Configuración de índices compuestos para la ordenación de varias propiedades
Las consultas que ordenan los resultados por varias propiedades requieren índices compuestos. El índice compuesto debe coincidir con la secuencia exacta de propiedades y direcciones de ordenación de la ORDER BY cláusula . Las aplicaciones de inteligencia artificial suelen ordenar los resultados por puntuación de relevancia y, a continuación, por fecha o por categoría y, después, por título.
La consulta siguiente ordena los documentos por puntuación de relevancia (descendente) y, a continuación, por fecha de carga (descendente):
SELECT * FROM c
ORDER BY c.relevanceScore DESC, c.uploadDate DESC
Sin un índice compuesto que coincida con este patrón exacto, la consulta produce un error que indica que se requiere un índice compuesto. La siguiente directiva de indexación agrega el índice compuesto necesario:
{
"compositeIndexes": [
[
{ "path": "/relevanceScore", "order": "descending" },
{ "path": "/uploadDate", "order": "descending" }
]
]
}
Los índices compuestos también admiten consultas con el criterio de ordenación opuesto en todas las rutas de acceso. Un índice compuesto definido como (relevanceScore DESC, uploadDate DESC) también admite ORDER BY c.relevanceScore ASC, c.uploadDate ASC. Sin embargo, no admite pedidos mixtos como ORDER BY c.relevanceScore DESC, c.uploadDate ASC. Ese patrón requiere un índice compuesto independiente.
Optimización de consultas con filtros y ORDER BY
Muchos patrones de recuperación de IA filtran por una propiedad y ordenan por otra. Por ejemplo, los usuarios pueden filtrar documentos por categoría y ordenar los resultados por fecha. Puede optimizar estas consultas al incluir la propiedad de filtro en la ORDER BY cláusula, que permite que un único índice compuesto atienda a la consulta.
Tenga en cuenta esta consulta que filtra por tipo de documento y ordena por fecha de carga:
SELECT * FROM c
WHERE c.documentType = 'pdf'
ORDER BY c.uploadDate DESC
Esta consulta usa un índice de intervalo para el filtro y requiere que se ordenan los resultados. Al volver a escribir la consulta para incluir la propiedad de filtro en ORDER BY, se habilita el uso de un índice compuesto:
SELECT * FROM c
WHERE c.documentType = 'pdf'
ORDER BY c.documentType, c.uploadDate DESC
La consulta reescrita usa un índice compuesto en (documentType ASC, uploadDate DESC). Esta optimización reduce significativamente el consumo de RU para las consultas que filtran por una propiedad y ordenan por otra. La siguiente directiva de indexación admite combinaciones comunes de filtro y ordenación:
{
"compositeIndexes": [
[
{ "path": "/documentType", "order": "ascending" },
{ "path": "/uploadDate", "order": "descending" }
],
[
{ "path": "/category", "order": "ascending" },
{ "path": "/relevanceScore", "order": "descending" }
]
]
}
Esta directiva define dos índices compuestos que optimizan el filtrado de consultas por tipo de documento o categoría mientras se ordenan por puntuación de fecha o relevancia.
Uso de índices compuestos para filtros de varias propiedades
Las consultas que filtran en varias propiedades pueden beneficiarse de índices compuestos. Al diseñar índices compuestos para filtros, coloque primero los filtros de igualdad en la definición de índice. Cada índice compuesto admite como máximo un filtro de intervalo, que debe ser la última propiedad del índice.
La consulta siguiente filtra por tres propiedades:
SELECT * FROM c
WHERE c.category = 'reports'
AND c.department = 'finance'
AND c.createdDate > '2024-06-01'
Los filtros de igualdad (category y department) deben aparecer primero en el índice compuesto, seguido del filtro de intervalo (createdDate). El siguiente índice compuesto optimiza esta consulta:
{
"compositeIndexes": [
[
{ "path": "/category", "order": "ascending" },
{ "path": "/department", "order": "ascending" },
{ "path": "/createdDate", "order": "ascending" }
]
]
}
Si una consulta tiene varios filtros de intervalo, necesita varios índices compuestos porque cada índice solo admite un filtro de intervalo. Para un filtrado de consultas en age > 18 y timestamp > someValue con un filtro de igualdad en name, necesita dos índices compuestos independientes:
-
(name ASC, age ASC)para el primer filtro de intervalo -
(name ASC, timestamp ASC)para el segundo filtro de intervalo
Azure Cosmos DB usa ambos índices juntos para evaluar la consulta completa.
Configuración de índices de tupla para el filtrado de elementos de matriz
Las aplicaciones de inteligencia artificial suelen almacenar datos estructurados dentro de matrices, como fragmentos de documento con posiciones y texto, etiquetas con categorías y pesos, o eventos con marcas de tiempo y tipos. Cuando las consultas filtran varias propiedades dentro de los elementos de matriz, los índices de tupla mejoran la eficacia de las consultas.
Considere un documento que almacena fragmentos de texto con información de posición:
{
"id": "doc-123",
"title": "Annual Report 2024",
"chunks": [
{ "position": 0, "text": "Executive summary...", "tokens": 150 },
{ "position": 1, "text": "Financial highlights...", "tokens": 200 },
{ "position": 2, "text": "Market analysis...", "tokens": 180 }
]
}
Consulta que busca fragmentos en posiciones específicas con filtros mínimos de recuentos de tokens tanto en position como tokens en el mismo elemento de matriz:
SELECT c.id, chunk.text
FROM c
JOIN chunk IN c.chunks
WHERE chunk.position >= 0
AND chunk.position < 3
AND chunk.tokens > 100
Un índice de tupla en la chunks matriz mejora la eficacia de esta consulta mediante la indexación de las combinaciones de propiedades dentro de cada elemento de matriz. La siguiente expresión de ruta de acceso define un índice de tupla:
{
"includedPaths": [
{ "path": "/*" },
{ "path": "/chunks/[]/{position, tokens}/?" }
]
}
La ruta de tuplas /chunks/[]/{position, tokens}/? indexa la combinación de position y tokens para cada elemento del array chunks. Los índices de tupla son especialmente valiosos para las aplicaciones de inteligencia artificial que almacenan documentos fragmentados en los que las consultas filtran con frecuencia la posición del fragmento, el tamaño u otros metadatos.
Equilibrar el rendimiento de lectura y escritura
Cada índice aumenta la latencia de escritura y el consumo de RU porque Azure Cosmos DB actualiza los índices de forma sincrónica durante las operaciones de escritura. Las aplicaciones de inteligencia artificial con un alto rendimiento de escritura, como aquellos que ingieren documentos, actualizan las incrustaciones o procesan datos en tiempo real, deben equilibrar la cobertura de índices con respecto al rendimiento de escritura.
Tenga en cuenta estas directrices al diseñar índices para cargas de trabajo de IA:
Incluya solo las propiedades consultadas: Si una propiedad se almacena pero nunca aparece en los filtros o
ORDER BYcláusulas de consulta, excluya de la indexación.Analizar la frecuencia de consulta: Cree índices compuestos para las consultas que se ejecutan con frecuencia. Es posible que las consultas poco frecuentes no justifican la sobrecarga de escritura de índices adicionales.
Supervisar el consumo de RU: compruebe el costo de RU de las escrituras con y sin índices específicos. Si las escrituras son la carga de trabajo dominante, es posible que menos índices proporcionen un mejor rendimiento general.
Use la indexación selectiva: En lugar de indexar todas las propiedades con
/*, solo se incluyen explícitamente las rutas de acceso que necesitan las consultas.
Descripción del comportamiento de la transformación de índices
Al modificar una directiva de indexación, Azure Cosmos DB realiza una transformación asincrónica para actualizar los índices. Comprender este comportamiento le ayuda a planear los cambios de índice sin interrumpir el rendimiento de la aplicación.
Adición de índices: Los nuevos índices no mejoran el rendimiento de las consultas hasta que se completa la transformación. Durante la transformación, las consultas continúan usando índices existentes o pasan a los exámenes.
Quitar índices: Al quitar un índice, las consultas dejan de usarlo inmediatamente y se revierten a los escaneos. Esto sucede antes de que se complete la transformación.
Reemplazo de índices: Si va a reemplazar un patrón de índice por otro, agregue primero el nuevo índice y espere a que se complete la transformación. A continuación, quite el índice anterior. Este enfoque garantiza que las consultas siempre tengan compatibilidad con índices adecuada.
Puede realizar un seguimiento del progreso de la transformación de índices mediante Azure Portal o SDK. En el caso de contenedores grandes con millones de elementos, las transformaciones pueden tardar mucho tiempo. Planee los cambios de índice durante períodos de tráfico bajo cuando sea posible para minimizar el impacto en el rendimiento aprovisionado.