Comment être compatible avec MySQL + ES + MongoDB pour réaliser une pagination approfondie de centaines de millions de données ?

Questions d'entretien et expériences réelles

Question d'entretien : Comment réaliser une pagination approfondie lorsque la quantité de données est importante ?

Vous pouvez rencontrer les questions ci-dessus lors d'entretiens ou lors de la préparation d'entretiens. La plupart des réponses consistent essentiellement à diviser des bases de données et des tableaux pour créer des index. C'est une bonne réponse très standard, mais la réalité est toujours difficile. , donc l'intervieweur vous demandera généralement, maintenant que la période de construction est insuffisante et que le personnel est insuffisant, comment pouvons-nous réaliser une pagination approfondie ?

En ce moment, les étudiants qui n'ont aucune expérience pratique sont fondamentalement engourdis. Alors, s'il vous plaît, écoutez-moi.

Une leçon douloureuse

Tout d'abord, il faut être clair : la pagination en profondeur peut être effectuée, mais la profondeur est aléatoire. Les sauts de page doivent absolument être interdits.

Photo précédente :

Devinez que si je clique sur la page 142360, le service va-t-il exploser ?

Comme MySQL, la base de données MongoDB est correcte. C'est une base de données professionnelle en soi. Elle n'est pas bien traitée et est au mieux lente. Mais si elle implique ES, la nature est différente. faire une boucle L'obtention de données implique un problème d'utilisation de la mémoire. Si le code n'est pas écrit avec élégance, cela peut directement conduire à un débordement de mémoire.

Pourquoi les sauts de page en profondeur aléatoires ne peuvent pas être autorisés

Parlons des raisons pour lesquelles les sauts de page en profondeur aléatoires ne peuvent pas être autorisés d'un point de vue technique, ou pourquoi la pagination profonde n'est-elle pas recommandée ?

MySQL

Le principe de base de la pagination :

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

LIMIT 10000, 20 signifie analyser 10020 lignes qui remplissent les conditions et les jeter. Supprimez les 10 000 premières lignes et renvoyez les 20 dernières lignes. S'il s'agit d'une LIMITE, 1 000 000, 100, 1 000 100 lignes doivent être analysées. Dans une application hautement concurrente, chaque requête doit analyser plus de 100 W de lignes. Ce serait étrange qu'elle n'explose pas.

MongoDB

Principe de base de la pagination :

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

De même, à mesure que le numéro de page augmente, les éléments ignorés par skip augmenteront également. , et cette opération est implémentée via l'itérateur du curseur. La consommation du CPU sera très évidente. Lorsque le numéro de page est très grand et fréquent, il va inévitablement exploser.

ElasticSearch

D'un point de vue commercial, ElasticSearch n'est pas une base de données typique, c'est un moteur de recherche. Si les données souhaitées ne sont pas trouvées dans les conditions de filtrage, vous. vous ne trouverez pas les données souhaitées si vous continuez la pagination approfondie. Pour prendre du recul, si nous utilisons ES comme base de données pour les requêtes, nous rencontrerons certainement la limite de max_result_window lors de la pagination. L'avez-vous vu ? La limite de décalage est de dix mille.

Processus de requête :

• Si vous interrogez la page 501, avec 10 éléments par page, le client envoie une requête à un nœud

• Ce nœud diffuse des données à chaque fragment, et chaque fragment interroge les 5010 premiers éléments de données

• Les résultats de la requête sont renvoyés au nœud, puis les données sont intégrées et le 5010 premières données sont extraites

• Retour au client

De là, nous pouvons voir pourquoi le décalage doit être limité en plus. , si vous utilisez une méthode de défilement telle que la requête de saut de page en profondeur de l'API Search After nécessite également de faire défiler des milliers d'éléments à chaque fois. Il peut être nécessaire de faire défiler des millions ou des dizaines de millions de données au total, uniquement pour les 20 dernières données. L'efficacité peut être imaginée.

Reprenez contact avec le produit

Comme le dit le proverbe, si la technologie ne peut pas résoudre les problèmes, laissez les entreprises les résoudre !

Lors de mon stage, j'ai cru au mal du produit et j'ai dû mettre en place une pagination profonde + des sauts de page. Maintenant, je dois corriger le chaos et apporter les changements suivants dans l'entreprise :

Ajouter. conditions de filtrage par défaut autant que possible. Par exemple : période de temps, le but est de réduire la quantité de données affichées

Modifier la méthode d'affichage des sauts de page, passer à l'affichage défilant, ou des sauts de page dans une petite plage.

Image de référence de l'affichage défilant :

Image de référence de saut de page à petite échelle :

Solution générale

La solution rapide en peu de temps est principalement les points suivants :

• Obligatoire : Pour trier les champs et conditions de filtrage, assurez-vous de définir l'index

• Core : utiliser des données connues de numéros de page à petite plage, ou des données connues de chargement par défilement, pour réduire les décalages

• Extra : Si vous rencontrez une situation difficile à gérer, vous pouvez également obtenir des données excédentaires et effectuer certaines interceptions, et l'impact sur les performances n'est pas significatif

MySQL

SQL de pagination d'origine :

# 第一页
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;

Par le contexte, réécrit comme :

# 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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!