nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Algunas dudas sobre transactional queries

spilby

Buenas,

acabamos de pasar a la versión 5.0.2 de Alfresco (veníamos de la 4.1.6) con la intención, sobretodo, de mejorar el tiempo de respuesta en las búsquedas, que con grandes cantidades de información se hacía excesivamente lento.

El principal cambio se producirá en las llamadas "transactional queries", que buscarán en BD en lugar de pasar por los índices de Solr. Me gustaría confirmar en algunas puntos su correcta utilización, y comentarlo con quienes tenéis seguro ya experiencia usándolas.

1. Por una parte debemos activarlas en el alfresco-global.properties. Por defecto solr.query.fts.queryConsistency está en modo TRANSACTIONAL_IF_POSSIBLE, por lo que entiendo que si no añado nada al properties, ya se ejecutarán de forma transaccional si la query así lo indica. ¿Es así?

Otra forma de forzar que sea transaccional por código es mediante el parámetro

params.setQueryConsistency(QueryConsistency.TRANSACTIONAL);
‍‍‍

Aquí viene mi primera duda. No sé si entiendo bien la diferencia entre "TRANSACTIONAL" y "TRANSACTIONAL_IF_POSSIBLE". ¿Quiere decir que TRANSACCIONAL fuerza sí o sí a que sea transaccional aunque no añada el setQueryConsistency transactional en el código? ¿Y que si añado en el properties el IF_POSSIBLE (o lo que es lo mismo, no pongo nada) sólo será transaccional si así lo obligo mediante el setQueryConsistency por código java?

2. Hay un apartado en la documentación que habla de "Configuring an optional patch for upgrade" y dice: "To enable the patch that adds the required indexes to the database, set the following property in the alfresco-global.properties file: system.metadata-query-indexes.ignored=false "

¿Esta property es la que me permitirá hacer las consultas transaccionales usando índices de BD? ¿Debo definir aparte esos índices o ya se añaden automáticamente cuando en el XML del modelo indico: index enabled="true"? ¿O no tiene nada que ver una cosa con la otra? Lo de que sea opcional me despista y no comprendo bien su propósito.

3. Según he entendido, hay queries que anularían automáticamente el uso transaccional de la query. Es decir, que dejaría de ser transaccional e iría a buscar al solr en lugar de a BD dependiendo de qué ponga en la query.

Utilizar un OR, por ejemplo, causaría ese efecto. O utilizar el PATH.

En cambio utilizar el TYPE o buscar por title, permite la transaccionalidad. ¿Y buscar por un valor concreto de un metadato propio? ¿Se considera full text search por lo que iría al SOLR?

Merci por la ayuda!

Find more posts tagged with

Comments

angelborroy

Esta pregunta no es fácil de responder. Intentaré aportarte mis opiniones aunque, como es natural, pueden no ser lo suficientemente acertadas o precisas.

En primer lugar creo que el principal motivo por el que se incluyeron las consultas de metadatos sobre base de datos fue por la inmediatez de los resultados, no por el rendimiento. Esto es, cuando SOLR indexa lo hace por encuesta, lo que quiere decir que los cambios no están disponibles hasta unos segundos después de que se han producido. Por tanto, bajo mi punto de vista, esta funcionalidad no ayudará a incrementar la velocidad de las búsquedas sino su fidelidad.

En cuanto a las diferencia de los diferentes valores de

solr.query.fts.queryConsistency‍

, te recomendaría que le echases un vistazo a la implementación en https://github.com/Alfresco/community-edition/blob/master/projects/repository/source/java/org/alfresco/repo/search/impl/solr/DbOrIndexSwitchingQueryLanguage.java. Creo que el propio código fuente resolverá tus dudas.

Tienes que establecer la propiedad

system.metadata-query-indexes.ignored=false‍

y volver a arrancar Alfresco para que aplique el parche de base de datos que crea los índices de búsqueda de metadatos en la base de datos. Una vez que lo hayas hecho, ya puedes volver a borrar esta propiedad (o dejarla, como quieras, no influirá en adelante).

En cuanto a si los tipos y metadatos propios son buscados en base de datos, lo cierto es que desconozco la respuesta. Intuitivamente te diría que sí, ya que se almacenan de manera análoga al resto de tipos y aspectos predefinidos de Alfresco (document, folder, dublincore…) en una "tabla de tablas", por lo que los índices y las consultas serán compartidas.

No obstante, con Alfresco 5 y SOLR 4, lo que sí te recomendaría es que los separases en dos servidores de aplicaciones diferentes. Eso te permitirá ajustar mejor el rendimiento del sistema, ya que podrás aplicar políticas específicas al nodo de SOLR.

spilby

Ok, Ángel. Muchas gracias por las aclaraciones, así lo haré!

Una duda sólo, sobre los índices de búsqueda de metadatos que crea el parche en la BD.

¿Los índices que crea en BD son los índices que especifico en el model.xml con index enabled="true"? Es decir, va al modelo y ahí sabe qué índices debe crear. ¿O crea los índices según su criterio y no tiene nada que ver con lo que ponga en el model.xml?

Lo digo más que nada porque si no tienen relación, entiendo que el indexado en el modelo no serviría para nada si pongo el modo TRANSACTIONAL, ya que nunca iría al SOLR.

angelborroy

Son índices de base de datos (http://dev.alfresco.com/resource/AlfrescoOne/5.0/configuration/alfresco/dbscripts/upgrade/4.2/org.hibernate.dialect.Dialect/metadata-query-indexes.sql😞

CREATE INDEX idx_alf_node_mdq ON alf_node (store_id, type_qname_id, id);  –(optional)
CREATE INDEX idx_alf_node_cor ON alf_node (audit_creator, store_id, type_qname_id, id);  –(optional)
CREATE INDEX idx_alf_node_crd ON alf_node (audit_created, store_id, type_qname_id, id);  –(optional)
CREATE INDEX idx_alf_node_mor ON alf_node (audit_modifier, store_id, type_qname_id, id);  –(optional)
CREATE INDEX idx_alf_node_mod ON alf_node (audit_modified, store_id, type_qname_id, id);  –(optional)

CREATE INDEX idx_alf_nprop_s ON alf_node_properties (qname_id, string_value, node_id);  –(optional)
CREATE INDEX idx_alf_nprop_l ON alf_node_properties (qname_id, long_value, node_id);  –(optional)

CREATE INDEX idx_alf_conturl_sz ON alf_content_url (content_size, id);  –(optional)
‍‍‍‍‍‍‍‍‍‍‍‍

Las propiedades del XML solo sirven para SOLR.

spilby

Oks, de acuerdo. Por BD entonces parece que indexa todos los metadatos. No sé muy bien como funciona, porque entiendo que indexarlo todo hace que no sirvan los índices. Pensaba que tendría que especificar qué metadatos en concreto quiero indexar.

Decidir entonces donde hacer las búsquedas es más complejo de lo que creía.

Utilizar queries transaccionales ofrece la ventaja de ir a BD y poder encontrar todos los resultados pese a no estar aún indexados en SOLR, pero en cambio pierdo la velocidad de los índices de SOLR, ya que los índices especificados en algunos metadatos del modelo no se usan en BD.

Queda por comprobar entonces si encontrar un metadato en BD es más rápido que encontrarlo en SOLR pese a estar indexado. No sé si por tu experiencia has podido comprobar qué es mejor, en grandes cantidades de documentos.

Por otra parte, utilizar según qué búsquedas anula el hacerlo sobre BD, como he podido leer en otro hilo, y que dejo aquí por si es útil la información:

"In general, do not use PATH, SITE, ANCESTOR, OR, any d:content, d:boolean or d:any (among others) properties in your query or it will not be executable against the DB. Also, any property checks must be expressed in a form that means "identical value check" as querying the DB does not provide the same tokenization / similarity capabilities as the SOLR index. E.g. instead of my

roperty:"value" you'd have to use =my

roperty:"value" and "value" must be written in the proper case the value is stored in the DB."

Uilizar un OR o un PATH hará que vaya directamente a SOLR. Lo del "d:content" no comprendo muy bien lo que es, si es cualquier metadato propio que cree, y el uso del "=" no me queda claro si también lleva a usar únicamente SOLR al no permitirse en búsqueda por BD, por lo que para hacer búsquedas exactas no sé si sirven las queries transaccionales.

angelborroy

"d:content" es para buscar sobre el contenido de un documento.
Para activar la búsqueda por base de datos debes usar "=" y pasarle el "value" exacto de base de datos (mayúsculas, minúsculas, acentos…)

spilby

Ah ok, es que en mis búsquedas ya utilizaba el = en la versión 4.1.6 para buscar valores exactos. Así que lo dejaré igual entonces.

En el model.xml especifico que no distinga entre mayúsculas, acentos, etc. Y si utilizo funciones como UPPER, no están permitidas en BD. Así que entiendo que si necesito buscar algo que no distinga, mejor ir directamente por SOLR. Y si busco algo exacto iré por BD usando el =.

Sobre el tema índices, si en el modelo he definido que algunos de mis metadatos propios se indexen por SOLR, para que sea igual de eficiente si busco por BD, ¿he de modificar el script que me has indicado antes para que cree un índice para esos 5? ¿O no hace falta y el Alfresco ya se apaña?

Por optimizar la velocidad de respuesta lo que pueda, lo digo. ¿Tú crees que entre buscar un dato indexado en SOLR y buscarlo por BD no hay diferencia? Por experiencia propia. Lo digo porque si fuera lo mismo, no haría falta especificar en el modelo qué metadatos indexar, si al final voy a ir por BD si es igual de rápido.