With regard to paging, we support three paging modes of ES. Please refer to the table below and choose as needed.

Paging mode	Performance	Advantages	Disadvantages	Application scenarios
from+size Shallow Paging	Low	Good flexibility and simple implementation	Deep Paging problem	The data volume is small and can tolerate deep paging problem
scroll query	Middle	Solved the problem of deep paging	Unable to reflect the real-time performance of data	The export of massive data needs to query the data of massive result sets
search_after	High performance	Best performance, no deep paging problem, and ability to reflect real-time changes of data	It is complicated to realize continuous paging with a globally unique field, because every query needs the result of the last query, and it is not suitable for large-scale page skipping queries	Paging of massive data

Shallow paging

//physical paging
EsPageInfo<T> pageQuery(LambdaEsQueryWrapper<T> wrapper, Integer pageNum, Integer pageSize);

tips

You can use paging query without integrating any plug-ins. This query belongs to physical paging, and it is based on the shallow paging mode of size+from, which is suitable for the case that the query data is less than 10,000, if you need it. In some usage scenarios of high-level grammar, the currently known return of aggregate fields is not supported by our pagination machine, so you need to encapsulate pagination yourself, and other scenarios can basically support it perfectly, which is extremely simple to use. Note that PageInfo is provided by this framework. If you already have the most popular open source paging plug-in PageHelper in your project, please be careful not to introduce errors when introducing the package. EE uses the same return fields as PageHelper, so you don't need to worry about the extra workload caused by the inconsistent field names.

use examples:

@Test
public void testPageQuery() {
LambdaEsQueryWrapper<Document> wrapper = new LambdaEsQueryWrapper<>();
Wrapper.match (document:: gettitle, "old man");
EsPageInfo<Document> documentPageInfo = documentMapper.pageQuery(wrapper,1,10);
System.out.println(documentPageInfo);
}

Scroll query

//Scroll query
SearchResponse scroll(SearchScrollRequest searchScrollRequest, RequestOptions requestOptions) throws IOException;

提示

If you need to query and paginate a large amount of data, you can use rolling query to realize it. As for rolling query, we have actually provided getSearchSourceBuilderAPI to quickly construct SearchSourceBuilder, which can help you realize rolling query quickly with the rolling query API provided above. Of course, we recommend that you use the following searchAfter method to paginate, which not only makes the API better packaged and easier to use, but also has other natural advantages.

searchAfter

use examples:

@Test
public void testSearchAfter() {
LambdaEsQueryWrapper<Document> lambdaEsQueryWrapper = EsWrappers.lambdaQuery(Document.class);
lambdaEsQueryWrapper.size(10);
//You must specify a sort rule, and the value of the sort field must be unique. Here I choose to sort by id. Actually, I can specify it freely according to the business scenario, and it is not recommended to use the creation time, because it may be the same.
lambdaEsQueryWrapper.orderByDesc(Document::getId);
SAPageInfo<Document> saPageInfo = documentMapper.searchAfterPage(lambdaEsQueryWrapper, null, 10);
//The first page
System.out.println(saPageInfo);
Assertions.assertEquals(10, saPageInfo.getList().size());

//Get the next page
List<Object> nextSearchAfter = saPageInfo.getNextSearchAfter();
SAPageInfo<Document> next = documentMapper.searchAfterPage(lambdaEsQueryWrapper, nextSearchAfter, 10);
Assertions.assertEquals(10, next.getList().size());
}

提示

You must specify a sort when using searchAfter. If there is no sort, you will not only report an error, but also be unfriendly to page skipping. It is necessary to keep the searchAfter sorting unique, otherwise it will lead to page failure. It is recommended to use id,uuid and so on for sorting.