Show Menu
TÓPICOS×

Práticas recomendadas para consultas e indexação

Juntamente com a transição para o Oak no AEM 6, algumas alterações importantes foram feitas na forma como consultas e índices são gerenciados. Em Jackrabbit 2, todo o conteúdo era indexado por padrão e podia ser consultado livremente. No Oak, os índices devem ser criados manualmente no oak:index nó. Uma consulta pode ser executada sem um índice, mas para grandes conjuntos de dados, ela será executada muito lentamente, ou até mesmo aborta.
Este artigo descreverá quando criar índices e quando eles não forem necessários, truques para evitar o uso de consultas quando elas não forem necessárias e dicas para otimizar seus índices e consultas a fim de executar da melhor forma possível.
Além disso, leia a documentação do Oak em consultas e índices de gravação. Além de os índices serem um novo conceito no AEM 6, há diferenças sintáticas nas consultas do Oak que precisam ser levadas em conta ao migrar o código de uma instalação anterior do AEM.

Quando usar consultas

Design de repositório e taxonomia

Ao conceber a taxonomia de um repositório, devem ser tidos em conta vários fatores. Isso inclui controles de acesso, localização, herança de propriedade de componente e página, entre outros.
Ao projetar uma taxonomia que aborde essas preocupações, também é importante considerar a "versabilidade" do design de indexação. Neste contexto, a navegabilidade é a capacidade de uma taxonomia que permite que o conteúdo seja acessado previsivelmente com base em seu caminho. Isso possibilitará um sistema mais eficiente, mais fácil de manter do que um que exigirá que muitas consultas sejam executadas.
Além disso, ao projetar uma taxonomia, é importante considerar se a ordem é importante. Nos casos em que a ordem explícita não é obrigatória e um grande número de nós irmãos é esperado, é preferível usar um tipo de nó não ordenado, como sling:Folder ou oak:Unstructured . Nos casos em que a encomenda é obrigatória, nt:unstructured e sling:OrderedFolder seria mais apropriado.

Consultas nos componentes

Como as consultas podem ser uma das operações de tributação mais realizadas em um sistema AEM, convém evitá-las em seus componentes. Ter várias consultas executadas sempre que uma página é renderizada pode, com frequência, diminuir o desempenho do sistema. Há duas estratégias que podem ser usadas para evitar a execução de consultas ao renderizar componentes: atravessando nós e buscando resultados .

Nós de navegação

Se o repositório for projetado de modo a permitir o conhecimento prévio da localização dos dados necessários, o código que recupera esses dados dos caminhos necessários pode ser implantado sem a necessidade de executar consultas para encontrá-los.
Um exemplo disso seria a renderização de conteúdo que se encaixe em uma determinada categoria. Uma abordagem seria organizar o conteúdo com uma propriedade de categoria que possa ser consultada para preencher um componente que mostre itens em uma categoria.
Uma melhor abordagem seria estruturar esse conteúdo em uma taxonomia por categoria para que ele possa ser recuperado manualmente.
Por exemplo, se o conteúdo for armazenado em uma taxonomia semelhante a:
/content/myUnstructuredContent/parentCategory/childCategory/contentPiece

o /content/myUnstructuredContent/parentCategory/childCategory nó pode simplesmente ser recuperado, seus filhos podem ser analisados e usados para renderizar o componente.
Além disso, ao lidar com um conjunto de resultados pequeno ou homogêneo, pode ser mais rápido atravessar o repositório e coletar os nós necessários, em vez de criar uma consulta para retornar o mesmo conjunto de resultados. De um modo geral, as questões devem ser evitadas sempre que possível.

Resultados da Pré-busca

Às vezes, o conteúdo ou os requisitos em torno do componente não permitirão o uso do nó transversal como um método de recuperação dos dados necessários. Nesses casos, as consultas necessárias precisam ser executadas antes que o componente seja renderizado para garantir o desempenho ideal para o usuário final.
Se os resultados necessários para o componente puderem ser calculados no momento da criação e não houver expectativa de que o conteúdo será alterado, a consulta poderá ser executada quando o autor aplicar as configurações na caixa de diálogo.
Se os dados ou o conteúdo forem alterados regularmente, a consulta poderá ser executada de acordo com uma programação ou por meio de um ouvinte para atualizações dos dados subjacentes. Em seguida, os resultados podem ser gravados em um local compartilhado no repositório. Qualquer componente que precise desses dados pode então retirar os valores desse único nó sem precisar executar uma consulta em tempo de execução.

Otimização da consulta

Ao executar uma consulta que não esteja usando um índice, os avisos serão registrados em relação ao nó transversal. Se esta for uma consulta que será executada com frequência, um índice deverá ser criado. Para determinar qual índice uma determinada consulta está usando, a ferramenta Explicar consulta Explicar consulta é recomendada. Para obter informações adicionais, o registro DEBUG pode ser ativado para as APIs de pesquisa relevantes.
Após modificar uma definição de índice, o índice precisa ser reconstruído (reindexado). Dependendo do tamanho do índice, isso pode levar algum tempo para ser concluído.
Durante a execução de consultas complexas, pode haver casos em que dividir a consulta em várias consultas menores e unir os dados por meio do código após o fato é mais eficiente. A recomendação para estes casos é comparar o desempenho das duas abordagens para determinar qual opção seria melhor para o caso de utilização em questão.
O AEM permite gravar consultas de uma das três maneiras:
  • Por meio das APIs do QueryBuilder (recomendado)
  • Uso do XPath (recomendado)
  • Uso do SQL2
Embora todas as consultas sejam convertidas em SQL2 antes de serem executadas, a sobrecarga da conversão de consulta é mínima e, portanto, a maior preocupação ao escolher um idioma de consulta será a capacidade de leitura e o nível de conforto da equipe de desenvolvimento.
Ao usar o QueryBuilder, ele determinará a contagem de resultados por padrão, que é mais lenta no Oak em comparação às versões anteriores do Jackrabbit. Para compensar isso, você pode usar o parâmetro thinkTotal .

A ferramenta Explicar consulta

Como em qualquer linguagem de consulta, a primeira etapa para otimizar uma consulta é entender como ela será executada. Para ativar essa atividade, você pode usar a ferramenta Consulta de Explicação que faz parte do Painel de Operações. Com essa ferramenta, uma consulta pode ser conectada e explicada. Será mostrado um aviso se a consulta causar problemas em um repositório grande, bem como no tempo de execução e nos índices que serão usados. A ferramenta também pode carregar uma lista de consultas lentas e populares que podem ser explicadas e otimizadas.

Registro DEBUG para consultas

Para obter informações adicionais sobre como o Oak escolhe qual índice usar e como o mecanismo de consulta está executando uma consulta, uma configuração de registro DEBUG pode ser adicionada para os seguintes pacotes:
  • org.apache.Jackrabbit.oak.plugins.index
  • org.apache.Jackrabbit.oak.query
  • com.day.cq.search
Certifique-se de remover esse agente de log quando terminar de depurar sua consulta, pois ela produzirá muita atividade e poderá eventualmente preencher seu disco com arquivos de log.
Para obter mais informações sobre como fazer isso, consulte a documentação de registro.

Estatísticas de índice

Lucene registra um Bean JMX que fornecerá detalhes sobre o conteúdo indexado, incluindo o tamanho e o número de documentos presentes em cada um dos índices.
Você pode acessá-lo acessando o Console JMX em https://server:port/system/console/jmx
Depois que você estiver conectado ao console JMX, execute uma pesquisa por Estatísticas do Índice Lucene para encontrá-lo. Outras estatísticas de índice podem ser encontradas no IndexStats MBean.
Para obter estatísticas de consulta, consulte o MBean chamado Oak Query Statistics .
Se você quiser acessar seus índices usando uma ferramenta como Luke , será necessário usar o console Oak para descarregar o índice do diretório NodeStore para um diretório filesystem. Para obter instruções sobre como fazer isso, leia a documentação do Lucene.
Você também pode extrair os índices no seu sistema no formato JSON. Para fazer isso, é necessário acessar https://server:port/oak:index.tidy.-1.json

Limites de consulta

Durante o desenvolvimento
Defina limites baixos para oak.queryLimitInMemory (por exemplo, 10000) e carvalho. queryLimitReads (por exemplo, 5000) e otimize a consulta cara ao clicar em UnsupportedOperationException dizendo "A consulta leu mais de x nós..."
Isso ajuda a evitar consultas de uso intensivo de recursos (ou seja, não suportado por qualquer índice ou apoiado por um índice de cobertura menor). Por exemplo, uma consulta que lê 1 milhão de nós levaria ao aumento da E/S e afetaria negativamente o desempenho geral do aplicativo. Qualquer consulta que falhar devido aos limites acima deve ser analisada e otimizada.

Pós-implantação

  • Monitore os registros para obter consultas que acionam o grande consumo de memória do nó transversal ou grande: "
    • *WARN* ... java.lang.UnsupportedOperationException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.
    • Otimizar a consulta para reduzir o número de nós atravessados
  • Monitore os registros para obter consultas que acionam grande consumo de memória heap:
    • *WARN* ... java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped
    • Otimizar a consulta para reduzir o consumo de memória heap
Para versões do AEM 6.0 - 6.2, é possível ajustar o limite para a passagem de nó pelos parâmetros JVM no script de início do AEM para impedir que consultas grandes sobrecarreguem o ambiente.
Os valores recomendados são:
  • -Doak.queryLimitInMemory=500000
  • -Doak.queryLimitReads=100000
No AEM 6.3, os 2 parâmetros acima são OOTB pré-configurados e podem ser mantidos por meio das Configurações do QueryEngine do OSGi.

Dicas para criar índices eficientes

Devo criar um índice?

A primeira pergunta a ser feita ao criar ou otimizar índices é se eles são realmente necessários para uma determinada situação. Se você só executará a consulta em questão uma vez ou apenas ocasionalmente e fora do horário de pico do sistema por um processo em lote, talvez seja melhor não criar um índice.
Depois de criar um índice, sempre que os dados indexados forem atualizados, o índice também deverá ser atualizado. Uma vez que isso acarreta implicações de desempenho para o sistema, os índices só devem ser criados quando forem realmente necessários.
Além disso, os índices só são úteis se os dados contidos no índice forem exclusivos o suficiente para garantir que sejam. Considere um índice em um livro e os tópicos que ele aborda. Ao indexar um conjunto de tópicos em um texto, normalmente haverá centenas ou milhares de entradas, o que permite que você pule rapidamente para um subconjunto de páginas para encontrar rapidamente as informações que está procurando. Se esse índice tivesse apenas duas ou três entradas, cada uma apontando para várias centenas de páginas, o índice não seria muito útil. Esse mesmo conceito se aplica aos índices do banco de dados. Se houver apenas alguns valores únicos, o índice não será muito útil. Dito isto, um índice também pode tornar-se demasiado grande para ser útil. Para ver as estatísticas de índice, consulte Estatísticas de índice acima.

Índices Lucene ou de propriedade?

Os índices Lucene foram introduzidos no Oak 1.0.9 e oferecem algumas otimizações poderosas sobre os índices de propriedade que foram introduzidos na primeira inicialização do AEM 6. Ao decidir se usar índices Lucene ou índices de propriedade, considere o seguinte:
  • Os índices de Lucene oferecem muito mais recursos do que os índices de propriedade. Por exemplo, um índice de propriedade só pode indexar uma única propriedade enquanto um índice Lucene pode incluir muitos. Para obter mais informações sobre todos os recursos disponíveis nos índices Lucene, consulte a documentação .
  • Os índices de Lucene são assíncronos. Embora isso ofereça um aumento considerável no desempenho, também pode induzir um atraso entre quando os dados são gravados no repositório e quando o índice é atualizado. Se for vital que as consultas retornem resultados 100% precisos, um índice de propriedade será necessário.
  • Por serem assíncronos, os índices de Lucene não conseguem impor restrições de exclusividade. Se isso for necessário, um índice de propriedade precisará ser implementado.
Em geral, recomenda-se usar índices Lucene, a menos que haja uma necessidade imperiosa de usar índices de propriedade para que você possa obter os benefícios de maior desempenho e flexibilidade.

Indexação Solr

O AEM também oferece suporte para indexação Solr por padrão. Isso é aproveitado principalmente para suportar a pesquisa de texto completo, mas também pode ser usado para suportar qualquer tipo de consulta JCR. A Solr deve ser considerada quando as instâncias do AEM não têm capacidade de CPU para lidar com o número de consultas necessárias em implantações de pesquisa intensiva, como sites orientados por pesquisa com um alto número de usuários simultâneos. Como alternativa, a Solr pode ser implementada em uma abordagem baseada em rastreador para aproveitar alguns dos recursos mais avançados da plataforma.
Índices solares podem ser configurados para serem executados no servidor AEM para ambientes de desenvolvimento ou podem ser descarregados para uma instância remota para melhorar a escalabilidade da pesquisa nos ambientes de produção e armazenamento temporário. Embora a descarga da pesquisa melhore a escalabilidade, ela introduzirá latência e, por isso, não é recomendada, a menos que seja necessário. Para obter mais informações sobre como configurar a integração do Solr e como criar índices do Solr, consulte a documentação Consultas e indexação do Oak.
Ao utilizar a abordagem de pesquisa integrada do Solr, será possível descarregar a indexação em um servidor Solr. Se os recursos mais avançados do servidor Solr forem usados por meio de uma abordagem baseada em crawler, será necessário um trabalho de configuração adicional. O cabo de alimentação criou um conector de fonte aberta para acelerar esses tipos de implementações.
O lado negativo dessa abordagem é que, embora por padrão, as consultas do AEM respeitem as ACLs e, portanto, ocultem os resultados aos quais um usuário não tem acesso, a externalização da pesquisa para um servidor Solr não oferecerá suporte a esse recurso. Para que a pesquisa seja externalizada desta forma, é necessário ter um cuidado especial para garantir que os utilizadores não sejam apresentados com resultados que não devem ver.
Casos de utilização potencial em que esta abordagem possa ser adequada são casos em que podem ser necessários agregados dados de pesquisa de várias fontes. Por exemplo, você pode ter um site sendo hospedado no AEM, bem como um segundo site hospedado em uma plataforma de terceiros. A Solr pode ser configurada para rastrear o conteúdo de ambos os sites e armazená-los em um índice agregado. Isso permitiria pesquisas entre sites.

Design Considerations

A documentação do Oak para índices Lucene lista várias considerações a serem feitas ao projetar índices:
  • Se a consulta usar restrições de caminho diferentes, utilize evaluatePathRestrictions . Isso permitirá que a consulta retorne o subconjunto de resultados sob o caminho especificado e, em seguida, filtre-os com base na consulta. Caso contrário, a consulta procurará todos os resultados que correspondem aos parâmetros de consulta no repositório e, em seguida, os filtrará com base no caminho.
  • Se a consulta usar a classificação, tenha uma definição de propriedade explícita para a propriedade classificada e defina ordered para true ela. Isso permitirá que os resultados sejam ordenados como tal no índice e salvos em operações de classificação dispendiosas no tempo de execução da consulta.
  • Coloque apenas o que é necessário no índice. Adicionar recursos ou propriedades desnecessárias fará com que o índice cresça e diminua o desempenho.
  • Em um índice de propriedade, ter um nome de propriedade exclusivo ajudaria a reduzir o tamanho em um índice, mas para os índices Lucene, o uso de nodeTypes e mixins deve ser feito para alcançar índices coesos. Consultar um item específico nodeType ou mixin terá mais desempenho do que consultar nt:base . Ao usar essa abordagem, defina indexRules para o nodeTypes em questão.
  • Se suas consultas estiverem sendo executadas somente em determinados caminhos, crie esses índices nesses caminhos. Os índices não precisam permanecer na raiz do repositório.
  • Recomenda-se usar um único índice quando todas as propriedades que estão sendo indexadas estiverem relacionadas para permitir que Lucene avalie nativamente o máximo possível de restrições de propriedade. Além disso, uma consulta usará apenas um índice, mesmo durante a execução de uma junção.

CopyOnRead

Nos casos em que o NodeStore é armazenado remotamente, uma opção chamada CopyOnRead pode ser ativada. A opção fará com que o índice remoto seja gravado no sistema de arquivos local quando ele for lido. Isso pode ajudar a melhorar o desempenho de consultas que são frequentemente executadas em relação a esses índices remotos.
Isso pode ser configurado no console OSGi sob o serviço LuceneIndexProvider e é ativado por padrão a partir do Oak 1.0.13.

Removendo Índices

Ao remover um índice, é sempre recomendável desativar temporariamente o índice definindo a type propriedade como disabled e fazer testes para garantir que seu aplicativo funcione corretamente antes de excluí-lo. Observe que um índice não é atualizado enquanto está desativado, portanto, talvez ele não tenha o conteúdo correto se for reativado e talvez precise ser indexado novamente.
Após remover um índice de propriedade em uma instância TarMK, será necessário executar a compactação para recuperar qualquer espaço em disco que estivesse em uso. Para índices Lucene, o conteúdo de índice real fica no BlobStore, portanto, seria necessário uma coleta de lixo do armazenamento de dados.
Ao remover um índice em uma instância MongoDB, o custo da exclusão é proporcional ao número de nós no índice. Como a exclusão de um índice grande pode causar problemas, a abordagem recomendada é desativar o índice e excluí-lo somente durante uma janela de manutenção, usando uma ferramenta como oak-mongo.js . Observe que essa abordagem não deve ser empregada para o conteúdo normal de nós, pois pode introduzir inconsistências de dados.
Para obter mais informações sobre oak-mongo.js, consulte a seção Ferramentas de linha de comando da documentação do Oak.

Indexação novamente

Esta seção descreve os únicos motivos aceitáveis para reindexar os índices Oak.
Fora dos motivos descritos abaixo, iniciar novamente índices de Oak não alterará o comportamento ou resolverá problemas e aumentará desnecessariamente a carga no AEM.
A reindexação de índices Oak deve ser evitada, a menos que seja coberta por uma razão nas tabelas abaixo.
Antes de consultar as tabelas abaixo para determinar se a reindexação é útil, sempre verifique:
  • a consulta está correta
  • a consulta é resolvida para o índice esperado (usando Explicar Consulta )
  • o processo de indexação foi concluído

Alterações na configuração do índice Oak

As únicas condições de não erro aceitáveis para reindexar os índices Oak são se a configuração de um índice Oak foi alterada.
A reindexação deve ser sempre abordada com a devida consideração sobre o impacto no desempenho geral do AEM e executada durante períodos de baixa atividade ou janelas de manutenção.
Os seguintes detalhes podem ser discutidos em conjunto com as resoluções:

Alteração da Definição do Índice de Propriedades

  • Aplica-se a/se:
  • Sintomas:
    • Nós existentes antes da atualização de definição do índice de propriedade ausentes dos resultados
  • Como verificar:
    • Determine se nós ausentes foram criados/modificados antes da implantação da definição de índice atualizada.
    • Verifique as propriedades jcr:created ou jcr:lastModified de qualquer nó ausente em relação ao tempo modificado do índice
  • Como resolver:
    • Indexar novamente o índice de lúcene
    • Como alternativa, toque (execute uma operação de gravação benigna) nos nós ausentes
      • Requer toques manuais ou código personalizado
      • Requer que o conjunto de nós ausentes seja conhecido
      • Exige alterar qualquer propriedade no nó

Alteração da Definição do Índice Lucene

  • Aplica-se a/se:
  • Sintomas:
    • O índice Lucene não contém os resultados esperados
    • Os resultados da consulta não refletem o comportamento esperado da definição de índice
    • O plano de consulta não relata a saída esperada com base na definição do índice
  • Como verificar:
    • Verifique se a definição do índice foi alterada usando o método Lucene Index statistics JMX Mbean (LuceneIndex) diffStoredIndexDefinition .
  • Como resolver:
    • Versões de carvalho anteriores à versão 1.6:
    • Oak versões 1.6+
      • Se o conteúdo existente não for afetado pelas alterações, somente uma atualização será necessária
        • Atualize o índice de lúcene definindo # @refresh=true
      • Caso contrário, reindexe o índice de lúcene
        • Observação: O estado do índice da última reindexação boa (ou indexação inicial) será usado até que uma nova reindexação seja acionada

Erros e situações excepcionais

A tabela a seguir descreve as únicas situações de erro aceitáveis e excepcionais em que a reindexação de índices Oak resolverá o problema.
Se ocorrer um problema no AEM que não corresponda aos critérios descritos abaixo, não indexe novamente nenhum índice, pois isso não resolverá o problema.
Os seguintes detalhes podem ser discutidos em conjunto com as resoluções:

Binário do Índice Lucene ausente

  • Aplica-se a/se:
  • Sintomas:
    • O índice Lucene não contém os resultados esperados
  • Como verificar:
    • O arquivo de log de erros contém uma exceção informando que um binário do índice Lucene está ausente
  • Como resolver:
    • Executar uma verificação de repositório de percurso; por exemplo:
      atravessar o repositório determina se outros binários (além de arquivos lúdicos) estão ausentes
    • Se estiverem faltando binários diferentes de índices de lúcene, restaure a partir do backup
    • Caso contrário, indexe novamente todos os índices de lúcene
    • Nota:
      Essa condição é indicativa de um armazenamento de dados configurado incorretamente que pode resultar em QUALQUER binário (por exemplo, binários de ativos) para ficar ausente.
      Nesse caso, restaure para a última versão em boas condições do repositório para recuperar todos os binários ausentes.

O Binário do Índice Lucene está corrompido

  • Aplica-se a/se:
  • Sintomas:
    • O índice Lucene não contém os resultados esperados
  • Como verificar:
    • O AsyncIndexUpdate (a cada 5s) falhará com uma exceção no error.log:
      ...a Lucene index file is corrupt...
  • Como resolver:
    • Remover a cópia local do índice de lúcene
      1. Parar o AEM
      2. Excluir a cópia local do índice de lucene em crx-quickstart/repository/index
      3. Reiniciar o AEM
    • Se isso não resolver o problema e as AsyncIndexUpdate exceções persistirem, então:
      1. Voltar a indexar o índice de erro
      2. Também é possível arquivar um ticket de suporte da Adobe

Como reindexar

No AEM 6.5, oak-run.jar é o ÚNICO método compatível para reindexação em repositórios MongoMK ou RDBMK.

Indexação dos índices de propriedade

Indexação dos índices de propriedade do Lucene

  • Use oak-run.jar para indexar novamente o índice da propriedade Lucene.
  • Defina a propriedade async-reindex como true no índice da propriedade lucene
    • [oak:queryIndexDefinition]@reindex-async=true
A seção anterior resume e enquadra a orientação de reindexação do Oak a partir da documentação do Apache Oak no contexto do AEM.

Pré-extração de texto de binários

A pré-extração de texto é o processo de extração e processamento de texto de binários, diretamente do Data Store por meio de um processo isolado e expondo diretamente o texto extraído a reindexações subsequentes de índices Oak.
  • A pré-extração de texto de Oak é recomendada para reindexar os índices Lucene em repositórios com grandes volumes de arquivos (binários) que contêm texto extraível (por exemplo, PDFs, Word Docs, PPTs, TXT etc.) que se qualificam para pesquisa em texto completo por meio de índices Oak implantados; por exemplo /oak:index/damAssetLucene .
  • A pré-extração de texto beneficiará somente a reindexação de índices Lucene e de índices de propriedade NOT Oak, já que os índices de propriedade não extraem texto de binários.
  • A pré-extração de texto tem um impacto positivo alto quando a reindexação de texto completo de binários com texto pesado (PDF, Doc, TXT etc.), onde, como repositório de imagens, não terá a mesma eficiência, pois as imagens não contêm texto extraível.
  • A pré-extração de texto realiza a extração de texto completo do texto relacionado à pesquisa de uma maneira extra eficiente, e o expõe ao processo de reindexação/reclassificação do Oak de uma forma que é extremamente eficiente de consumir.

Quando pode ser usada a pré-extração de texto?

Reindexação de um índice de lúceno existente com extração binária ativada
  • Reindexação do processamento de todo o conteúdo candidato no repositório; quando os binários dos quais extrair o texto completo são numerosos ou complexos, uma carga computacional aumentada para executar a extração de texto completo é colocada no AEM. A pré-extração de texto move o "trabalho computacionalmente caro" da extração de texto para um processo isolado que acessa diretamente o Data Store do AEM, evitando sobrecarga e contenção de recursos no AEM.
Suporte à implantação de um novo índice de lúcene no AEM com extração binária ativada
  • Quando um novo índice (com extração binária ativada) é implantado no AEM, o Oak indexa automaticamente todo o conteúdo candidato na próxima execução do índice de texto completo assíncrono. Pelas mesmas razões descritas na reindexação acima, isso pode resultar em carga indevida no AEM.

Quando pode a pré-extração de texto NÃO ser usada?

A pré-extração de texto não pode ser usada para novos conteúdos adicionados ao repositório, nem é necessária.
O novo conteúdo é adicionado ao repositório será indexado de forma natural e incremental pelo processo de indexação assíncrona de texto completo (por padrão, a cada 5 segundos).
Em operação normal do AEM, por exemplo, fazer upload de ativos por meio da interface do usuário da Web ou da assimilação programática de ativos, o AEM indexará automaticamente e incrementalmente o novo conteúdo binário. Como a quantidade de dados é incremental e relativamente pequena (aproximadamente a quantidade de dados que pode ser mantida no repositório em 5 segundos), o AEM pode executar a extração de texto completo dos binários durante a indexação sem afetar o desempenho geral do sistema.

Pré-requisitos para usar a pré-extração de texto

  • Você reindexará um índice de lúcene que executa extração binária de texto completo ou implantará um novo índice que fará binários de índice de texto completo do conteúdo existente
  • O conteúdo (binários) a partir do qual extrair o texto deve estar no repositório
  • Uma janela de manutenção para gerar o arquivo CSV E executar a reindexação final
  • Versão do Oak: 1.0.18+, 1.2.3+
  • oak-run. jarversion 1.7.4+
  • Uma pasta/compartilhamento do sistema de arquivos para armazenar o texto extraído acessível das instâncias de indexação do AEM
    • A configuração de OSGi de pré-extração de texto requer um caminho do sistema de arquivos para os arquivos de texto extraídos, de modo que eles devem estar acessíveis diretamente da instância de AEM (unidade local ou montagem de compartilhamento de arquivos)

Como executar pré-extração de texto

Os comandos oak-run.jar descritos abaixo são completamente enumerados em https://jackrabbit.apache.org/oak/docs/query/pre-extract-text.html
O diagrama acima e as etapas abaixo servem para explicar e complementar as etapas de pré-extração do texto técnico descritas na documentação do Apache Oak.
Gerar lista de conteúdo para pré-extração
Execute a Etapa 1(a-b) durante uma janela de manutenção/período de baixo uso, à medida que o armazenamento de nós for percorrido durante essa operação, o que pode causar carga significativa no sistema.
1 bis. Execute oak-run.jar --generate para criar uma lista de nós que terão seu texto pré-extraído.
1 ter. A lista de nós (1a) é armazenada no sistema de arquivos como um arquivo CSV
Observe que o Node Store inteiro é atravessado (conforme especificado pelos caminhos no comando oak-run) sempre que --generate é executado e um novo arquivo CSV é criado. O arquivo CSV não é reutilizado entre execuções discretas do processo de pré-extração de texto (Etapas 1 - 2).
Pré-extrair texto para o sistema de arquivos
A Etapa 2(a-c) pode ser executada durante a operação normal do AEM, pois só interage com o Data Store.
2 bis. Executar oak-run.jar --tika para pré-extrair texto para os nós binários enumerados no arquivo CSV gerado em (1b)
2 ter. O processo iniciado em (2a) acessa diretamente os nós binários definidos no CSV no Data Store e extrai o texto.
2-C. O texto extraído é armazenado no sistema de arquivos em um formato ingerível pelo processo de reindexação Oak (3a)
O texto pré-extraído é identificado no CSV pela impressão digital binária. Se o arquivo binário for o mesmo, o mesmo texto pré-extraído poderá ser usado em instâncias do AEM. Como a publicação de AEM é normalmente um subconjunto do autor de AEM, o texto pré-extraído do autor de AEM também pode ser usado para reindexar a publicação de AEM (supondo que a publicação de AEM tenha acesso do sistema de arquivos aos arquivos de texto extraídos).
O texto pré-extraído pode ser adicionado gradualmente ao longo do tempo. A pré-extração de texto ignorará a extração de binários extraídos anteriormente, portanto, a prática recomendada é manter o texto pré-extraído caso a reindexação deva ocorrer novamente no futuro (supondo que o conteúdo extraído não seja proibitivamente grande). Se estiver, avalie o zipamento do conteúdo no intervalo, já que o texto compacta bem).
Indexar novamente índices Oak, obter texto completo de arquivos de Texto extraído
Execute a reindexação (Etapas 3a-b) durante um período de manutenção/baixo uso, à medida que o armazenamento de nós for percorrido durante essa operação, o que pode causar carga significativa no sistema.
3-A. O reíndice de índices Lucene é chamado no AEM
3 ter. A configuração do Apache Jackrabbit Oak DataStore PreExtractedTextProvider OSGi (configurada para apontar para o texto extraído por um caminho de sistema de arquivos) instrui o Oak a obter o texto de texto completo dos arquivos extraídos e evita que os dados armazenados no repositório sejam acessados e processados diretamente.