Dynamic index

Although each of our mappers can already determine the index of the current CRUD, users can operate different indexes according to different mappers, which is the same as different mappers in MP corresponding to different tables. However, there is a scene in ES that requires dynamic indexing. For example, a company's logs are stored in ES, but the amount of logs is extremely large, and users usually only pay attention to the logs in the last three months, so the index is established by year or month. It can not only improve the query speed and performance, but also classify the data better. However, the index in EE is written in the code through the annotation @IndexName, which leads users to change the code again when they want to switch the index. And restart the project, which is obviously not a good solution, so we provide additional support for dynamic indexing.

-Mode 1 directly setting the index name corresponding to the current mapper is simple and rude.

@Test
public void testActiveIndex(){
//Set the index corresponding to the current mapper, for example, the original index name is document. After setting, all the CRUD indexes corresponding to documentMapper will be changed to the specified index name, for example,' 2023-03-11'.
String indexName = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));
documentMapper.setCurrentActiveIndex(indexName);
}

提示

Although this scheme is simple, rude and easy, there are two details to pay attention to: -Distributed environment is not supported, because the index of each mapper is stored in the jvm cache, and the current setting operation can only be applied to the current machine. If distributed environment is to be supported, users need to perform this method on each machine. -Atomicity is not guaranteed. If other threads are executing CRUD of data during index change, this operation will not block other threads from executing CRUD, so atomicity cannot be guaranteed in high concurrency scenarios.

-Mode 2: The granularity of the index name passed in through specific methods in wrapper or mapper is the smallest.

@Test
public void testSelect() {
//Support setting indexes of multiple queries, just separate them with commas.
LambdaEsQueryWrapper<Document> wrapper = new LambdaEsQueryWrapper<>();
Wrapper.eq(Document::getTitle, "old man")
. index ("index name 1 you want to query", "index name 2 you want to query");
Document document = documentMapper.selectOne(wrapper);
System.out.println(document);
}

@Test
public void testInsert() {
//In some cases where there is no wrapper, such as insert and update, method overloading is provided in mapper, and the index name can be directly passed in.
Document document = new Document();
document.setEsId("5");
Document.setTitle ("old man");
//Support setting indexes of multiple queries, just separate them with commas.
Intsuccesscount = documentmapper.insert (document, "index name 1 you want to insert", "index name 2 you want to insert");
Assertions.assertEquals(successCount, 1);
}

Landing plan

In the previous chapter, we introduced the API of manual indexing. With the index activation scheme provided here, dynamic indexing can be easily realized.

@Test
public void testCreateIndexByEntity() {
//Suitable for the scenario that scheduled tasks create indexes by date.
String indexName = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));
documentMapper.createIndex(indexName);
}

-1. The write timing task calls the Create Index API to create an index, and the index name is generated in the date format you want and placed in the redis cache.

-2. After the generation is completed, globally set the index name corresponding to the current mapper as the latest index name stored in redis or get the latest index name from redis when CRUD.

Of course, the above is only a feasible reference scheme, and users can also design personalized solutions according to the capabilities provided by API and the characteristics of their own projects.