Consultas en componentes
AEM Dado que las consultas pueden ser una de las operaciones más gravosas realizadas en un sistema de, es aconsejable evitarlas en los componentes. Tener varias consultas ejecutándose cada vez que se procesa una página puede a menudo degradar el rendimiento del sistema. Hay dos estrategias que se pueden usar para evitar la ejecución de consultas al procesar componentes: nodos de recorrido y resultados de recuperación previa.
Recorrido de nodos
Si el repositorio está diseñado de manera que permita un conocimiento previo de la ubicación de los datos necesarios, se puede implementar un código que recupere estos datos de las rutas necesarias sin tener que ejecutar consultas para encontrarlos.
Un ejemplo de esto sería procesar contenido que se ajuste a una categoría determinada. Un método sería organizar el contenido con una propiedad category que se pueda consultar para rellenar un componente que muestre los elementos de una categoría.
Un mejor enfoque sería estructurar este contenido en una taxonomía por categoría para que se pueda recuperar manualmente.
Por ejemplo, si el contenido se almacena en una taxonomía similar a:
/content/myUnstructuredContent/parentCategory/childCategory/contentPiece
El nodo /content/myUnstructuredContent/parentCategory/childCategory simplemente se puede recuperar, sus elementos secundarios se pueden analizar y utilizar para procesar el componente.
Además, cuando se trata de un conjunto de resultados pequeño u homogéneo, puede ser más rápido atravesar el repositorio y recopilar los nodos necesarios, en lugar de crear una consulta para devolver el mismo conjunto de resultados. Como consideración general, las consultas deben evitarse siempre que sea posible hacerlo.
Resultados de recuperación previa
A veces, el contenido o los requisitos relacionados con el componente no permiten el uso del recorrido de nodos como método para recuperar los datos necesarios. En estos casos, es necesario ejecutar las consultas necesarias antes de procesar el componente para garantizar un rendimiento óptimo para el usuario final.
Si los resultados necesarios para el componente se pueden calcular en el momento en que se crea y no hay expectativas de que el contenido cambie, la consulta se puede ejecutar cuando el autor aplique la configuración en el cuadro de diálogo.
Si los datos o el contenido cambian con regularidad, la consulta se puede ejecutar en una programación o a través de un oyente para actualizaciones de los datos subyacentes. A continuación, los resultados se pueden escribir en una ubicación compartida del repositorio. Cualquier componente que necesite estos datos puede extraer los valores de este nodo único sin necesidad de ejecutar una consulta en tiempo de ejecución.
Optimización de consultas
Al ejecutar una consulta que no utiliza un índice, se registran advertencias sobre el recorrido del nodo. Si se trata de una consulta que se va a ejecutar con frecuencia, cree un índice. Para determinar qué índice está usando una consulta determinada, se recomienda la herramienta Explicar consulta. Para obtener más información, se puede habilitar el registro de DEPURACIÓN para las API de búsqueda relevantes.
NOTEAl ejecutar consultas complejas, puede haber casos en los que desglosar la consulta en varias consultas más pequeñas y unir los datos a través del código después del hecho sea más eficaz. La recomendación para estos casos es comparar el rendimiento de los dos enfoques para determinar qué opción sería mejor para el caso de uso en cuestión.
AEM escribir consultas de una de las tres maneras siguientes:
- A través de las API de QueryBuilder (recomendado)
- Uso de XPath (recomendado)
- Uso de SQL2
Aunque todas las consultas se convierten a SQL2 antes de ejecutarse, la sobrecarga de la conversión de consultas es mínima y, por lo tanto, la mayor preocupación al elegir un idioma de consulta será la legibilidad y el nivel de comodidad del equipo de desarrollo.
NOTELa herramienta de consulta Explicar
Al igual que con cualquier idioma de consulta, el primer paso para optimizar una consulta es comprender cómo se ejecutará. Para habilitar esta actividad, puede usar la herramienta Explicar consulta que forma parte del tablero de operaciones. Con esta herramienta, se puede conectar una consulta y explicarla. Se muestra una advertencia si la consulta causa problemas con un repositorio grande y con el tiempo de ejecución y los índices utilizados. La herramienta también puede cargar una lista de consultas lentas y populares que luego se pueden explicar y optimizar.
Registro DEBUG para consultas
Para obtener información adicional acerca de cómo elige Oak qué índice utilizar y cómo ejecuta realmente el motor de consultas una consulta, se puede agregar una configuración de registro DEBUG para los siguientes paquetes:
- org.apache.jackrabbit.oak.plugins.index
- org.apache.jackrabbit.oak.query
- com.day.cq.search
Asegúrese de eliminar este registrador cuando haya terminado de depurar la consulta. Tiende a generar una gran cantidad de actividad y eventualmente puede llenar su disco con archivos de registro.
Para obtener más información sobre cómo hacerlo, consulte la Documentación de registro.
Estadísticas de índice
Lucene registra un bean JMX que proporcionará detalles sobre el contenido indexado, incluido el tamaño y el número de documentos presentes en cada uno de los índices.
Puede acceder a él desde la consola JMX en https://server:port/system/console/jmx
Una vez que haya iniciado sesión en la consola JMX, realice una búsqueda de Estadísticas de índice de Lucene para encontrarlas. Se pueden encontrar otras estadísticas de índice en el MBean IndexStats.
Para obtener estadísticas de consultas, observe el MBean denominado Estadísticas de consultas de Oak.
Si desea profundizar en sus índices usando una herramienta como Luke, debe usar la consola de Oak para volcar el índice desde NodeStore a un directorio del sistema de archivos. Para obtener instrucciones sobre cómo hacerlo, lea la documentación de Lucene.
También puede extraer los índices del sistema en formato JSON. Para ello, debe tener acceso a https://server:port/oak:index.tidy.-1.json
Límites de la consulta
Durante el desarrollo
Defina umbrales bajos para oak.queryLimitInMemory (por ejemplo, 10000) y Oak. queryLimitReads (por ejemplo, 5000) y optimizar la consulta costosa al alcanzar una excepción UnsupportedOperationException diciendo "La consulta leyó más de x nodos…"
Esto ayuda a evitar consultas que requieren muchos recursos (es decir, que no estén respaldadas por ningún índice o que estén respaldadas por un índice que cubra menos). Por ejemplo, una consulta que lee 1 millón de nodos produciría un aumento de E/S y afectaría negativamente al rendimiento general de la aplicación. Cualquier consulta que falle debido a los límites anteriores debe analizarse y optimizarse.
Implementación de Post
-
Monitorice los registros para consultas que activen un recorrido de nodos grande o un gran consumo de memoria de montón: "
*WARN* ... java.lang.UnsupportedOperationException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.- Optimizar la consulta para reducir el número de nodos atravesados
-
Monitorice los registros para consultas que activen un gran consumo de memoria
*WARN* ... java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped- Optimizar la consulta para reducir el consumo de memoria
AEM AEM Para las versiones 6.0 - 6.2, puede ajustar el umbral para el recorrido de nodos a través de los parámetros JVM en el script de inicio de la para evitar que las consultas grandes se sobrecarguen en el entorno.
Los valores recomendados son:
-Doak.queryLimitInMemory=500000-Doak.queryLimitReads=100000
AEM En 6.3, los dos parámetros anteriores están preconfigurados de forma predeterminada y se pueden mantener a través de OSGi QueryEngineSettings.
Más información disponible en: https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Slow_Queries_and_Read_Limits
Sugerencias para crear índices eficientes
¿Debería crear un índice?
La primera pregunta que se debe hacer al crear o optimizar índices es si son necesarios para una situación determinada. Si sólo va a ejecutar la consulta en cuestión una vez o sólo ocasionalmente y en un momento de menor actividad para el sistema mediante un proceso por lotes, puede ser mejor no crear ningún índice.
Después de crear un índice, cada vez que se actualicen los datos indexados, también se debe actualizar el índice. Dado que esto tiene implicaciones de rendimiento para el sistema, los índices solo deben crearse cuando sean necesarios.
Además, los índices solo son útiles si los datos contenidos en ellos son lo suficientemente únicos como para justificarlos. Considere un índice en un libro y los temas que cubre. Al indexar un conjunto de temas en un texto, normalmente habrá cientos o miles de entradas, lo que le permite ir rápidamente a un subconjunto de páginas para encontrar rápidamente la información que está buscando. Si ese índice solo tuviera dos o tres entradas, cada una de las cuales indicara varios cientos de páginas, no sería útil. Este mismo concepto se aplica a los índices de base de datos. Si solo hay un par de valores únicos, el índice no será útil. Dicho esto, un índice también puede llegar a ser demasiado grande para ser útil. Para ver las estadísticas de índice, consulte Estadísticas de índice más arriba.
¿Lucene o índices de propiedades?
Los índices Lucene se introdujeron en Oak AEM 1.0.9 y ofrecen algunas optimizaciones potentes sobre los índices de propiedad que se introdujeron en el primer inicio de la versión 6 de. Al decidir si utilizar índices de Lucene o índices de propiedad, tenga en cuenta lo siguiente:
- Los índices de Lucene ofrecen muchas más funciones que los índices de propiedades. Por ejemplo, un índice de propiedad solo puede indexar una sola propiedad, mientras que un índice Lucene puede incluir muchas. Para obtener más información sobre todas las características disponibles en los índices Lucene, consulte la documentación.
- Los índices de Lucene son asíncronos. Aunque esto ofrece un aumento considerable del rendimiento, también puede provocar un retraso entre el momento en que se escriben los datos en el repositorio y el momento en que se actualiza el índice. Si es vital que las consultas devuelvan resultados 100 % precisos, se requeriría un índice de propiedad.
- Debido a su carácter asincrónico, los índices Lucene no pueden aplicar restricciones de exclusividad. Si es necesario, es necesario establecer un índice de propiedades.
En general, se recomienda utilizar índices de Lucene a menos que exista una necesidad imperiosa de utilizar índices de propiedad para poder obtener los beneficios de un rendimiento y una flexibilidad mayores.
Indexación de Solr
AEM También admite la indexación de Solr de forma predeterminada. Se utiliza para admitir la búsqueda de texto completo, pero también se puede utilizar para admitir cualquier tipo de consulta JCR. AEM Solr se debe tener en cuenta cuando las instancias de no tienen la capacidad de CPU para gestionar la cantidad de consultas necesarias en implementaciones que requieren mucha búsqueda, como sitios web impulsados por búsquedas con un alto número de usuarios simultáneos. Como alternativa, Solr se puede implementar con un enfoque basado en rastreadores para utilizar algunas de las funciones más avanzadas de la plataforma.
AEM Los índices de Solr se pueden configurar para que se ejecuten incrustados en el servidor de para entornos de desarrollo o para que se puedan descargar en una instancia remota a fin de mejorar la escalabilidad de búsqueda en los entornos de producción y ensayo. Aunque la descarga de búsquedas mejora la escalabilidad, introduce latencia y, por ello, no se recomienda a menos que sea necesario. Para obtener más información sobre cómo configurar la integración de Solr y cómo crear índices de Solr, consulte la documentación sobre consultas e indexación de Oak.
NOTEAEM El inconveniente de este enfoque es que, aunque de forma predeterminada, las consultas de la aplicación respetan las ACL y, por lo tanto, ocultan los resultados a los que un usuario no tiene acceso, la externalización de la búsqueda en un servidor Solr no admite esta función. Si la búsqueda se va a externalizar de esta manera, se debe tener especial cuidado para garantizar que los usuarios no reciban resultados que no deberían ver.
Casos de uso potenciales en los que este método puede ser adecuado son casos en los que puede ser necesario acumular datos de búsqueda de múltiples fuentes. AEM Por ejemplo, es posible que tenga un sitio en el que se aloje y un segundo sitio en el que se aloje en una plataforma de terceros. Solr se puede configurar para que rastree el contenido de ambos sitios y los almacene en un índice agregado. Esto permitiría búsquedas entre sitios.
Consideraciones de diseño
La documentación de Oak para índices de Lucene enumera varias consideraciones que se deben tener en cuenta al diseñar índices:
-
Si la consulta usa diferentes restricciones de ruta, use
evaluatePathRestrictions. Esto permite que la consulta devuelva el subconjunto de resultados bajo la ruta especificada y, a continuación, los filtre según la consulta. De lo contrario, la consulta busca todos los resultados que coincidan con los parámetros de consulta en el repositorio y, a continuación, los filtra en función de la ruta. -
Si la consulta usa la ordenación, tenga una definición de propiedad explícita para la propiedad ordenada y establezca
orderedentruepara ella. Esto permite ordenar los resultados como tales en el índice y ahorrar en costosas operaciones de ordenación en el momento de la ejecución de la consulta. -
Inserte únicamente lo que sea necesario en el índice. Añadir características o propiedades innecesarias hace que el índice crezca y reduzca el rendimiento.
-
En un índice de propiedad, tener un nombre de propiedad único ayudaría a reducir el tamaño de un índice, pero para los índices Lucene, se debe usar
nodeTypesymixinspara lograr índices coherentes. Consultar un(a)nodeTypeomixinespecífico(a) resultará más eficaz que consultarnt:base. Al utilizar este enfoque, definaindexRulesparanodeTypesen cuestión. -
Si las consultas solo se ejecutan en determinadas rutas, cree esos índices en esas rutas. Los índices no son necesarios para residir en la raíz del repositorio.
-
Utilice un solo índice cuando todas las propiedades que se están indexando estén relacionadas para permitir que Lucene evalúe tantas restricciones de propiedad como sea posible de forma nativa. Además, una consulta solo utilizará un índice, incluso cuando realice una unión.
CopiarAlLeer
En los casos en que NodeStore se almacene de forma remota, se puede habilitar una opción denominada CopyOnRead. La opción hace que el índice remoto se escriba en el sistema de archivos local cuando se lee. Esto puede ayudar a mejorar el rendimiento de las consultas que a menudo se ejecutan con estos índices remotos.
Esto se puede configurar en la consola OSGi bajo el servicio LuceneIndexProvider y está habilitado de forma predeterminada a partir de Oak 1.0.13.
Eliminación de índices
Al eliminar un índice, siempre se recomienda deshabilitarlo temporalmente estableciendo la propiedad type en disabled y realizar pruebas para asegurarse de que la aplicación funciona correctamente antes de eliminarlo. Un índice no se actualiza mientras está deshabilitado, por lo que es posible que no tenga el contenido correcto si se vuelve a habilitar y sea necesario reindexarlo.
Después de quitar un índice de propiedad en una instancia de TarMK, se debe ejecutar la compactación para recuperar cualquier espacio en disco que esté en uso. Para los índices Lucene, el contenido del índice real se encuentra en el BlobStore, por lo que se requeriría una recopilación de elementos no utilizados del almacén de datos.
Al eliminar un índice en una instancia de MongoDB, el coste de eliminación es proporcional al número de nodos del índice. Dado que eliminar un índice grande puede causar problemas, el método recomendado es deshabilitar el índice y eliminarlo solamente durante una ventana de mantenimiento, con una herramienta como oak-mongo.js. Tenga en cuenta que este método no debe utilizarse para el contenido de nodo normal, ya que puede introducir incoherencias en los datos.
NOTE