Wie kann man mit MySQL + ES + MongoDB kompatibel sein, um ein tiefes Paging von Hunderten Millionen Daten zu erreichen?

Interviewfragen & echte Erfahrungen

Interviewfrage: Wie erreicht man Deep Paging, wenn die Datenmenge groß ist?

Die oben genannten Fragen können bei Vorstellungsgesprächen oder bei der Vorbereitung auf Vorstellungsgespräche auftreten. Bei den meisten Antworten geht es grundsätzlich darum, Datenbanken und Tabellen zu unterteilen, um Indizes zu erstellen, aber die Realität ist immer so Schwer, daher wird der Interviewer Sie normalerweise fragen: Wie können wir jetzt, da die Bauzeit nicht ausreicht und das Personal nicht ausreicht, ein tiefes Paging erreichen?

Studenten, die keine praktische Erfahrung haben, sind derzeit grundsätzlich taub. Hören Sie mir also bitte zu.

Eine schmerzhafte Lektion

Zunächst einmal muss klar sein: Deep Paging ist möglich, aber Tiefe ist zufällig. Seitensprünge müssen unbedingt verboten werden.

Vorheriges Bild:

Ratet mal, wenn ich auf Seite 142360 klicke, wird der Dienst dann explodieren?

Wie MySQL ist die MongoDB-Datenbank an sich in Ordnung. Sie wird nicht gut verarbeitet und ist bestenfalls langsam. Wenn es sich jedoch um ES handelt, ist die Natur eine andere Das Abrufen von Daten in einer Schleife ist mit dem Problem der Speichernutzung verbunden. Wenn der Code nicht elegant geschrieben ist, kann dies direkt zu einem Speicherüberlauf führen.

Warum Seitensprünge mit zufälliger Tiefe nicht zulässig sind

Lassen Sie uns darüber sprechen, warum Seitensprünge mit zufälliger Tiefe aus technischer Sicht nicht zulässig sind, oder warum Wird Deep Paging nicht empfohlen?

MySQL

Das Grundprinzip des Paging:

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

LIMIT 10000, 20 bedeutet, dass 10020 Zeilen gescannt werden, die die Bedingungen erfüllen und sie wegwerfen. Die ersten 10.000 Zeilen löschen und die letzten 20 Zeilen zurückgeben. Wenn es LIMIT 1000000 ist, müssen 100, 1000100 Zeilen gescannt werden. In einer hochgradig gleichzeitigen Anwendung muss jede Abfrage mehr als 100 W Zeilen scannen. Es wäre seltsam, wenn sie nicht explodiert.

MongoDB

Grundprinzip des Pagings:

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

In ähnlicher Weise werden mit zunehmender Seitenzahl auch die durch Skip übersprungenen Elemente größer , und dieser Vorgang wird über den Iterator des Cursors implementiert. Wenn die Seitenzahl sehr groß und häufig ist, wird sie unweigerlich explodieren.

ElasticSearch

Aus geschäftlicher Sicht handelt es sich bei ElasticSearch nicht um eine typische Datenbank, sondern um eine Suchmaschine. Wenn die gewünschten Daten unter den Filterbedingungen nicht gefunden werden Wenn Sie mit dem Deep-Paging fortfahren, werden die gewünschten Daten nicht gefunden. Wenn wir ES als Datenbank für die Abfrage verwenden, werden wir beim Paging definitiv auf das Limit von max_result_window stoßen Die Offset-Grenze beträgt zehntausend.

Abfrageprozess:

• Wenn Sie beispielsweise Seite 501 mit 10 Elementen pro Seite abfragen, sendet der Client eine Anfrage an einen Knoten

• Dieser Knoten sendet Daten an jeden Shard, und jeder Shard fragt die ersten 5010 Daten ab

• Die Abfrageergebnisse werden an den Knoten zurückgegeben, und dann werden die Daten zurückgegeben integriert und die ersten 5010 Daten werden herausgenommen

• Zurück zum Client

Daraus können wir erkennen, warum der Offset begrenzt werden sollte Wenn Sie außerdem eine Bildlaufmethode wie die Deep-Page-Jump-Abfrage der Search After API verwenden, kann es erforderlich sein, insgesamt Millionen oder Dutzende von Daten zu scrollen, allein für die letzten 20 Die Effizienz kann man sich vorstellen.

Nehmen Sie erneut Kontakt mit dem Produkt auf

Wie das Sprichwort sagt: Wenn Technologie Probleme nicht lösen kann, lassen Sie sie vom Unternehmen lösen!

Während meines Praktikums glaubte ich an das Böse des Produkts und musste Deep Paging + Page Jumps implementieren. Jetzt muss ich das Chaos korrigieren und die folgenden Änderungen im Geschäft vornehmen:

Standardfilterung hinzufügen Bedingungen so weit wie möglich. Zum Beispiel: Zeitraum, der Zweck besteht darin, die Menge der angezeigten Daten zu reduzieren

Ändern Sie die Anzeigemethode für Seitensprünge, ändern Sie sie in eine scrollende Anzeige oder springen Sie in einem kleinen Bereich zu Seiten

Referenzbild für scrollende Anzeige:

Referenzbild für Seitensprünge im kleinen Maßstab:

Allgemeine Lösung

Die schnelle Lösung in kurzer Zeit besteht hauptsächlich aus folgenden Punkten:

• Unverzichtbar: Zum Sortieren von Feldern und Filtern Stellen Sie unter bestimmten Bedingungen sicher, dass Sie den Index festlegen

• Kern: Verwenden Sie bekannte Daten für Seitenzahlen mit kleinem Bereich oder bekannte Daten für das Scrollen, um Offsets zu reduzieren

• Extra: Wenn Sie auf eine schwierig zu handhabende Situation stoßen, können Sie auch überschüssige Daten abrufen und bestimmte Abfangvorgänge durchführen, ohne dass die Auswirkungen auf die Leistung erheblich sind

MySQL

Original-Paging-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;

Durch Kontext neu geschrieben als:

# 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

Das obige ist der detaillierte Inhalt vonWie kann man mit MySQL + ES + MongoDB kompatibel sein, um ein tiefes Paging von Hunderten Millionen Daten zu erreichen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!