MySQL + ES + MongoDB と互換性を持たせて、数億のデータのディープ ページングを実現するにはどうすればよいでしょうか?

ランダムな深さのページ ジャンプが許可されない理由

MySQL

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

MongoDB

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

ElasticSearch

• ページあたり 10 項目でページ 501 をクエリすると、クライアントは特定のノードにリクエストを送信します

• このノードはデータを各シャードにブロードキャストし、各シャードは最初の 5010 個のデータをクエリします。

• クエリ結果はノードに返され、データが統合されます

• クライアントに戻る

もう一度製品と合わせてください

##一般的な解決策短期間での迅速な解決策には、主に次の点が含まれます。

必須: 並べ替えフィールドとフィルター条件の場合、インデックスを設定する必要があります
コア: 狭い範囲のページ番号の既知のデータ、またはローリング ロードの既知のデータを使用して、オフセットを削減します
補足: 対処が難しい状況に遭遇した場合は、過剰なデータを取得してある程度まで傍受することもでき、パフォーマンスへの影響は大きくありません

元のページング 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