Oak Lucene Index - Improve the query performance in AEM | How to Configure Oak Lucene Index in AEM скачать в хорошем качестве

Oak Lucene Index - Improve the query performance in AEM | How to Configure Oak Lucene Index in AEM

#AdobeExperienceManager #aem #lucene For queries to perform well, Oak supports the indexing of content that is stored in the repository. When a JCR query gets executed, usually it searches the index first. If there is no index, the query executes for the entire content. This is time-consuming and overhead for the AEM. A query can be executed without an index, but for large datasets, it will execute very slowly, or even abort. There are three types of indexing mode available that define how comparing is performed, and when the index content gets updated Synchronous Indexing - Under synchronous indexing, the index content gets updates as part of the commit itself. Changes to both the main content, as well as the index content, are done atomically in a single commit. Asynchronous Indexing - Asynchronous indexing (also called async indexing) is performed using periodically scheduled jobs. As part of the setup, Oak schedules certain periodic jobs which perform diff of the repository content, and update the index content based on that Near Real-Time (NRT) Indexing - This method indicates that the index is a near-real-time index. Indexing uses Commit Editors. Some of the editors are of type IndexEditor, which are responsible for updating index content based on changes in main content. Currently, Oak has the following inbuilt editors: PropertyIndexEditor ReferenceEditor LuceneIndexEditor SolrIndexEditor There are 3 main types of indexes available in AEM : Lucene – asynchronous (full text and property) - Recommended Property – synchronous [ Prefer only when you need synchronous results ] Solr – asynchronous Let see how to configure Lucene Index in AEM Oak supports Lucene based indexes to support both property constraint and full-text constraints. Depending on the configuration a Lucene index can be used to evaluate property constraints, full-text constraints, path restrictions, and sorting. If multiple indexers are available for a query, each available indexer estimates the cost of executing the query. Oak then chooses the indexer with the lowest estimated cost. select * from [nt:unstructured] where [jcr:path] like '/content/sampledata/%' and id LIKE '%1111%' queryLimitReads value can be changed but the query fails again after reaching the limit and also this will impact the overall system performance. @console/configMgr/org.apache.jackrabbit.oak.query.QueryEngineSettingsService testindex - jcr:primaryType - oak:QueryIndexDefinition type - lucene includedPaths - /content/sampledata fullTextEnabled - false evaluatePathRestrictions - true compatVersion - 2 async - async, nrt id: propertyIndex - true ordered - true name - id isRegexp - false multiple properties can be added here The query generator can be also used to generate the query definitions - @e/index, some properties may vary in AEM Change the reindex property to true to initiate the asynchronous indexing Now the query is working without any issues and with better performance. This is the best practice to review the slow running custom queries and configure the required indexing to improve the performance