수억 개의 데이터에 대한 딥 페이징을 달성하기 위해 MySQL + ES + MongoDB와 호환되는 방법은 무엇입니까?

인터뷰 질문 및 실제 경험

인터뷰 질문: 데이터 양이 많을 때 어떻게 딥 페이징을 달성할 수 있나요?

면접을 할 때나 면접을 준비할 때 위와 같은 질문을 접하게 됩니다. 대부분의 답변은 기본적으로 데이터베이스와 테이블을 나누어 인덱스를 구축하는 것에 관한 것이지만, 현실은 항상 매우 얄팍합니다. 면접관은 보통 건설 기간과 인력이 부족한 상황에서 딥 페이징을 어떻게 구현하는지 묻습니다.

실습 경험이 없는 학생들은 기본적으로 이때는 무감각하니 꼭 들어주세요.

고통스러운 교훈

우선 분명히 해야 할 점은 딥 페이징을 수행할 수 있지만 딥 랜덤 페이지 점프는 절대적으로 금지되어야 한다는 것입니다.

이전 사진:

맞아요, 142360페이지를 클릭하면 서비스가 폭발할까요?

MySQL과 마찬가지로 MongoDB 데이터베이스도 괜찮습니다. 그 자체로는 처리가 좋지 않고, 기껏해야 느리지만, ES를 포함한다면 성격이 다릅니다. 이는 메모리 사용량 문제와 관련이 있습니다. 코드가 우아하게 작성되지 않으면 메모리 오버플로가 직접 발생할 수 있습니다.

임의의 깊이 페이지 점프가 허용되지 않는 이유

기술적인 관점에서 왜 임의의 깊이 페이지 점프가 허용될 수 없는지, 딥 페이징이 권장되지 않는 이유를 간략하게 이야기해보겠습니다

MySQL

페이징의 기본 원칙:

SELECT * FROM test ORDER BY id DESC LIMIT 10000, 20;

LIMIT 10000, 20은 조건을 충족하는 10020개의 행을 검색하고 처음 10000개의 행을 삭제하고 마지막 20개의 행을 반환한다는 의미입니다. LIMIT 1000000, 100, 1000100개의 행을 스캔해야 하는 경우 동시성 애플리케이션에서는 각 쿼리가 100W 이상의 행을 스캔해야 합니다.

MongoDB

페이징의 기본 원리:

db.t_data.find().limit(5).skip(5);

마찬가지로 페이지 수가 증가할수록 건너뛰는 항목도 늘어나는데, 이 작업은 커서의 반복자를 통해 구현됩니다. 매우 분명합니다. 페이지 번호가 매우 크고 빈번하면 필연적으로 폭발할 것입니다.

ElasticSearch

비즈니스 관점에서 ElasticSearch는 일반적인 데이터베이스가 아닌 검색 엔진입니다. 필터 조건에서 원하는 데이터를 검색하지 않으면 원하는 데이터를 찾을 수 없습니다. 계속 딥 페이징을 진행하려면 ES를 쿼리용 데이터베이스로 사용하면 페이징 시 반드시 max_result_window의 한계에 직면하게 됩니다. 공식에서 최대 오프셋 한도가 10,000이라고 말하는 것을 보셨나요?

쿼리 프로세스:

• 예를 들어 페이지당 10개의 항목이 있는 501페이지를 쿼리하면 클라이언트는 노드에 요청을 보냅니다.

• 이 노드는 데이터를 각 샤드에 브로드캐스트하고 각 샤드는 처음 5010개의 데이터가

• 쿼리 결과가 노드로 반환된 후 데이터가 통합되고 처음 5010개의 데이터가 꺼내

• 클라이언트로 반환됩니다

From 이를 통해 오프셋을 제한해야 하는 이유를 알 수 있습니다. 또한 이 스크롤 API를 사용하면 심층적인 페이지 이동 쿼리를 수행할 수도 있습니다. 또한 매번 수백만 또는 수천만 개의 항목을 스크롤해야 할 수도 있습니다. 마지막 20개의 데이터에 대해서만 총 데이터의 효율성을 상상할 수 있습니다.

제품에 다시 문의하세요

격언처럼 기술이 문제를 해결할 수 없다면 기업이 문제를 해결하도록 하세요!

인턴 기간 동안 저는 제품의 폐해를 믿었고 딥 페이징 + 페이지 점프를 구현해야 합니다. 이제 혼란을 바로잡아야 하며 비즈니스에서는 다음과 같은 변화가 이루어져야 합니다.

기본 필터링 조건을 최대한 추가하세요. 가능한 한 기간, 표시되는 데이터의 양을 줄이는 것이 목적입니다

페이지 점프 표시 방법 수정, 스크롤 표시 또는 소규모 페이지 점프로 변경

스크롤 표시 참고 사진:

소규모 페이지 점프 참고 사진:

일반 해결 방법

단시간에 빠르게 해결할 수 있는 해결 방법은 주로 다음 사항입니다.

• 필수: 반드시 설정하세요. 정렬 필드에 대한 인덱스 및 필터 조건

• Core: 작은 범위의 데이터에서 알려진 페이지 번호를 사용하거나 알려진 데이터의 롤링 로딩, 오프셋 감소

• Extra: 어려운 상황에 직면한 경우 처리하기 위해 초과 데이터를 확보하여 어느 정도 가로챌 수도 있으며 성능에 미치는 영향은 크지 않습니다

MySQL

원본 페이징 SQL:

# 第一页
SELECT * FROM `year_score` where `year` = 2017 ORDER BY id limit 0, 20;
# 第N页
SELECT * FROM `year_score` where `year` = 2017 ORDER BY id limit (N - 1) * 20, 20;

컨텍스트를 통해 다시 작성됨:

# XXXX 代表已知的数据
SELECT * FROM `year_score` where `year` = 2017 and id > XXXX ORDER BY id limit 20;

在 没内鬼，来点干货！SQL优化和诊断 一文中提到过，LIMIT会在满足条件下停止查询，因此该方案的扫描总量会急剧减少，效率提升Max！

ES

方案和MySQL相同，此时我们就可以随用所欲的使用 FROM-TO Api，而且不用考虑最大限制的问题。

MongoDB

方案基本类似，基本代码如下：

相关性能测试：

如果非要深度随机跳页

如果你没有杠过产品经理，又该怎么办呢，没关系，还有一丝丝的机会。

在 SQL优化 一文中还提到过MySQL深度分页的处理技巧，代码如下：

# 反例（耗时129.570s）
select * from task_result LIMIT 20000000, 10;
# 正例（耗时5.114s）
SELECT a.* FROM task_result a, (select id from task_result LIMIT 20000000, 10) b where a.id = b.id;
# 说明
# task_result表为生产环境的一个表，总数据量为3400万，id为主键，偏移量达到2000万

该方案的核心逻辑即基于聚簇索引，在不通过回表的情况下，快速拿到指定偏移量数据的主键ID，然后利用聚簇索引进行回表查询，此时总量仅为10条，效率很高。

因此我们在处理MySQL，ES，MongoDB时，也可以采用一样的办法：

• 限制获取的字段，只通过筛选条件，深度分页获取主键ID

• 通过主键ID定向查询需要的数据

瑕疵：当偏移量非常大时，耗时较长，如文中的 5s

推荐教程：《MySQL教程》

文章来源：https://juejin.im/post/5f0de4d06fb9a07e8a19a641

위 내용은 수억 개의 데이터에 대한 딥 페이징을 달성하기 위해 MySQL + ES + MongoDB와 호환되는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!