Regarding paging, we support three paging modes of ES, you can refer to the following table and choose according to your needs.

Paging Method	Performance	Advantages	Disadvantages	Application Scenarios
from+size	Low	Good flexibility, easy to implement	Deep paging problem	The amount of data is relatively small, can tolerate deep paging problems
scroll	Medium	Solved the problem of deep paging	Unable to reflect the real-time nature of data	Export of massive data requires querying the data of massive result sets
search_after	High	The best performance, there is no deep paging problem, and it can reflect real-time changes in data	The implementation is complex, requiring a globally unique field. The implementation of continuous paging will be more complicated, because each query requires the last query As a result, it is not suitable for large page jump queries	paging of massive data

from+size

    // 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, based on size+from shallow paging mode, which is suitable for query data less than 10,000, if you need In some high-level syntax usage scenarios, there are currently known aggregate field returns, which our pager cannot support yet. You need to encapsulate the paging by yourself. Other scenarios can basically be perfectly supported, and it is extremely simple to use. Note that PageInfo is provided by this framework. If you already have the most popular open source paging plugin PageHelper in your project, please be careful not to introduce errors when importing the package. EE uses the same return fields as PageHelper, so you don't need to worry about the field names The extra workload caused by non-uniformity.

Example of use:

    @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 perform a large amount of data query and paging requirements, you can use scrolling query to achieve it. Regarding scrolling query, we have actually provided getSearchSourceBuilder API to quickly construct SearchSourceBuilder. With the scrolling query API provided above, it can help you quickly Implement scrolling queries Of course, we recommend that you use the following searchAfter method for paging, not only the API is better encapsulated and easier to use, but also has other natural advantages.

searchAfter

Example of use:

    @Test
    public void testSearchAfter() {
        LambdaEsQueryWrapper<Document> lambdaEsQueryWrapper = EsWrappers.lambdaQuery(Document.class);
        lambdaEsQueryWrapper.size(10);
        // A sorting rule must be specified, and the sorting field value must be unique. Here I choose to use id to sort. Actually, it can be freely specified according to the business scenario. It is not recommended to use the creation time, because it may be the same        lambdaEsQueryWrapper.orderByDesc(Document::getStarNum);
        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());
    }

提示

When using searchAfter, you must specify the ordering. If there is no ordering, it will not only report an error, but also be unfriendly to page jumps. It is necessary to keep the searchAfter sorting unique, otherwise the paging will be invalid. It is recommended to use id, uuid, etc. for sorting.