Suchergebnisse anzeigen und Leistungsprobleme

Eines der typischen Szenarien in allen uns vertrauten Anwendungen ist die Suche nach Daten anhand bestimmter Kriterien und deren Ausgabe in einem lesbaren Format. Hierbei können auch zusätzliche Funktionen wie Sortierung, Gruppierung und paginierte Ausgabe vorhanden sein. Die Aufgabe scheint trivial zu sein, doch viele Entwickler machen bei der Lösung eine Reihe von Fehlern, die sich negativ auf die Leistung auswirken. Lassen Sie uns verschiedene Lösungsmöglichkeiten für dieses Problem betrachten und Empfehlungen für die Auswahl der effektivsten Implementierung formulieren.

Paginierungsoption #1

Die einfachste Lösung, die man sich vorstellen kann, ist die paginierte Ausgabe der Suchergebnisse in der klassischsten Form.

Angenommen, die Anwendung nutzt eine relationale Datenbank. In diesem Fall müssen zur Anzeige der Informationen in dieser Form zwei SQL-Abfragen durchgeführt werden:

• Die Zeilen für die aktuelle Seite abrufen.
• Die Gesamtanzahl der Zeilen zählen, die den Suchkriterien entsprechen – dies ist notwendig, um die Seiten anzuzeigen.

Betrachten wir die erste Abfrage am Beispiel einer Test-MS-SQL-Datenbank. AdventureWorks für den 2016-Server. Zu diesem Zweck verwenden wir die Tabelle Sales.SalesOrderHeader:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Die obige Abfrage gibt die ersten 50 Bestellungen aus der Liste zurück, die absteigend nach Hinzufügungsdatum sortiert sind, mit anderen Worten – die letzten 50 Bestellungen.

Diese Abfrage wird schnell auf der Testdatenbank ausgeführt, aber schauen wir uns den Ausführungsplan und die E/A-Statistik an:

Tabelle 'SalesOrderHeader'. Scan-Zähler 1, logische Reads 698, physische Reads 0, Read-Ahead Reads 0, LOB logische Reads 0, LOB physische Reads 0, LOB Read-Ahead Reads 0.

Die E/A-Statistik für jede Abfrage kann erhalten werden, indem im Abfrageausführungsumfeld der Befehl SET STATISTICS IO ON ausgeführt wird.

Wie aus dem Ausführungsplan hervorgeht, ist die sortieren von allen Zeilen der Ursprungstabelle nach Hinzufügungsdatum am ressourcenintensivsten. Und das Problem besteht darin, dass je mehr Zeilen in der Tabelle vorhanden sind, desto „schwerer“ wird die Sortierung. In der Praxis sollte man solche Situationen vermeiden, daher fügen wir einen Index auf dem Hinzufügungsdatum hinzu und prüfen, ob die Ressourcennutzung sich geändert hat:

Tabelle 'SalesOrderHeader'. Scan-Zähler 1, logische Reads 165, physische Reads 0, Read-Ahead Reads 5, LOB logische Reads 0, LOB physische Reads 0, LOB Read-Ahead Reads 0.

Offensichtlich ist es viel besser geworden. Aber sind alle Probleme gelöst? Lassen Sie uns die Suchanfrage für Bestellungen ändern, bei denen der Gesamtwert der Produkte 100 Dollar übersteigt:

SELECT * FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Tabelle 'SalesOrderHeader'. Scan-Anzahl 1, logische Lesevorgänge 1081, physische Lesevorgänge 0, Vorablesevorgänge 0, lob logische Lesevorgänge 0, lob physische Lesevorgänge 0, lob Vorablesevorgänge 0.

Wir haben eine lustige Situation: Der Abfrageplan ist nicht viel schlechter als der vorherige, aber die tatsächliche Anzahl der logischen Lesevorgänge ist fast doppelt so hoch wie bei einem vollständigen Tabellenscan. Es gibt einen Ausweg — wenn wir den bereits vorhandenen Index zusammensetzen und das zweite Feld den Gesamtpreis der Produkte hinzuzufügen, erhalten wir wieder 165 logische Lesevorgänge:

CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);

Diese Reihe von Beispielen lässt sich noch lange fortsetzen, aber zwei Hauptgedanken, die ich hier äußern möchte, sind folgende:

• Die Hinzufügung eines neuen Kriteriums oder einer neuen Sortierreihenfolge in der Suchanfrage kann die Ausführungsgeschwindigkeit erheblich beeinflussen.
• Wenn wir jedoch nur einen Teil der Daten abfragen müssen und nicht alle Ergebnisse, die den Suchkriterien entsprechen, gibt es viele Möglichkeiten, eine solche Abfrage zu optimieren.

Kommen wir jetzt zur zweiten Abfrage, die zu Beginn erwähnt wurde — die, die die Anzahl der Datensätze zählt, die den Suchkriterien entsprechen. Nehmen wir dasselbe Beispiel — die Suche nach Bestellungen, die mehr als 100 Dollar kosten:

SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100

Mit dem oben genannten zusammengesetzten Index erhalten wir:

Tabelle 'SalesOrderHeader'. Scan-Zähler 1, logische Reads 698, physische Reads 0, Read-Ahead Reads 0, LOB logische Reads 0, LOB physische Reads 0, LOB Read-Ahead Reads 0.

Dass die Abfrage über den gesamten Index ausgeführt wird, ist nicht überraschend, da das Feld SubTotal nicht an erster Stelle steht, und daher kann die Abfrage nicht davon profitieren. Das Problem lässt sich lösen, indem ein weiterer Index auf dem Feld SubTotal hinzugefügt wird, und am Ende ergibt sich bereits nur noch 48 logische Lesevorgänge.

Es lassen sich noch einige weitere Beispiele für Abfragen zur Zählung anführen, aber die Grundsätze bleiben die gleichen: Die Abfrage von Daten und die Zählung der Gesamtanzahl sind zwei grundlegend verschiedene Abfragen, und jede erfordert ihre eigenen Maßnahmen zur Optimierung. Im Allgemeinen wird es nicht möglich sein, eine Kombination von Indizes zu finden, die für beide Abfragen gleichermaßen gut funktioniert.

Daher ist eine der wichtigen Anforderungen, die bei der Entwicklung einer solchen Suchlösung geklärt werden muss, ob es für das Geschäft wichtig ist, die Gesamtzahl der gefundenen Objekte zu sehen. Oft ist dem nicht so. Und die Navigation zu bestimmten Seitenzahlen ist meiner Meinung nach eine Lösung mit einem sehr engen Anwendungsbereich, da die meisten Szenarien mit Paging wie „zur nächsten Seite wechseln“ aussehen.

Paging-Option #2

Angenommen, den Benutzern ist die Kenntnis der Gesamtzahl der gefundenen Objekte nicht wichtig. Lassen Sie uns die Suchseite vereinfachen:

Tatsächlich hat sich nur geändert, dass es keine Möglichkeit gibt, zu bestimmten Seitenzahlen zu wechseln, und jetzt muss diese Tabelle für die Anzeige nicht wissen, wie viele es insgesamt geben könnte. Aber die Frage stellt sich – wie erfährt die Tabelle, ob es Daten für die nächste Seite gibt (um den Link „Weiter“ korrekt anzuzeigen)?

Die Antwort ist ganz einfach: Man kann einen Datensatz mehr aus der Datenbank abfragen, als für die Anzeige benötigt wird, und das Vorhandensein dieses „zusätzlichen“ Datensatzes zeigt, ob eine weitere Portion vorhanden ist. Auf diese Weise muss nur eine Abfrage ausgeführt werden, um eine Seite von Daten zu erhalten, was die Leistung erheblich verbessert und die Unterstützung einer solchen Funktionalität erleichtert. Ich habe in der Praxis einen Fall erlebt, bei dem der Verzicht auf die Zählung der Gesamtzahl der Datensätze die Ergebnisse um das 4- bis 5-fache beschleunigt hat.

Für diesen Ansatz gibt es mehrere Optionen für die Benutzeroberfläche: die Schaltflächen „zurück“ und „vorwärts“, wie im obigen Beispiel, eine Schaltfläche „mehr laden“, die einfach eine neue Portion zu den angezeigten Ergebnissen hinzufügt, und „unendliches Scrollen“, das nach dem Prinzip „mehr laden“ funktioniert, bei dem das Scrollen des Benutzers an das Ende aller angezeigten Ergebnisse das Signal für das Abrufen der nächsten Portion ist. Wie auch immer die visuelle Lösung aussieht, das Prinzip der Datenauswahl bleibt dasselbe.

Details zur Implementierung von Paging

In allen oben genannten Anfragen wird der Ansatz „Offset + Anzahl“ verwendet, bei dem im Antrag angegeben wird, von welcher Zeile im Ergebnis und wie viele Zeilen zurückgegeben werden sollen. Zuerst betrachten wir, wie man die Übergabe der Parameter in diesem Fall am besten organisiert. In der Praxis habe ich verschiedene Methoden gefunden:

• Die Seitenzahl des angeforderten Dokuments (pageIndex), die Seitengröße (pageSize).
• Die Reihenfolge der ersten zu zurückgebenden Datensätze (startIndex), die maximale Anzahl der Datensätze im Ergebnis (count).
• Die Reihenfolge der ersten zu zurückgebenden Datensätze (startIndex), die Reihenfolge der letzten zu zurückgebenden Datensätze (endIndex).

Auf den ersten Blick könnte man denken, dass dies so einfach ist, dass es keinen Unterschied macht. Das ist aber nicht der Fall – die praktischste und universellste Variante ist die zweite (startIndex, count). Dafür gibt es mehrere Gründe:

• Für den Ansatz mit dem Lesen von +1 Datensatz, wie oben beschrieben, ist die erste Variante mit pageIndex und pageSize äußerst unpraktisch. Zum Beispiel wollen wir 50 Datensätze auf einer Seite anzeigen. Laut dem oben beschriebenen Algorithmus müssen wir einen Datensatz mehr lesen als nötig. Wenn dieses "+1" nicht auf dem Server berücksichtigt wird, bedeutet das, dass wir für die erste Seite die Datensätze von 1 bis 51 anfordern müssen, für die zweite von 51 bis 101 usw. Wenn wir die Seitengröße auf 51 festlegen und pageIndex erhöhen, gibt die zweite Seite die Datensätze von 52 bis 102 zurück usw. Dementsprechend ist im ersten Ansatz die einzige Möglichkeit, den Button für die nächste Seite ordnungsgemäß zu implementieren, das Einrechnen eines "überflüssigen" Datensatzes auf dem Server, was ein sehr unauffälliger Aspekt sein wird.
• Der dritte Ansatz macht überhaupt keinen Sinn, da für die Durchführung von Anfragen in den meisten Datenbanken dennoch die Anzahl und nicht der Index des letzten Datensatzes übergeben werden muss. Es ist zwar eine einfache arithmetische Operation, das subtrahieren von startIndex von endIndex, aber sie ist hier überflüssig.

Nun sollten die Nachteile der Implementierung von Paging über "Offset + Anzahl" beschrieben werden:

• Das Abrufen jeder nächsten Seite wird aufwendiger und langsamer sein als die vorherige, da die Datenbank dennoch alle Datensätze "von Anfang an" entsprechend den Such- und Sortierkriterien durchgehen muss, bevor sie an dem benötigten Abschnitt stoppt.
• Nicht alle Datenbankmanagementsysteme unterstützen diesen Ansatz.

Es gibt Alternativen, aber auch diese sind nicht ideal. Der erste solcher Ansätze wird als „Keyset Paging“ oder „Seek-Methode“ bezeichnet und besteht darin, dass man nach dem Abrufen eines Teils die Werte der Felder im letzten Datensatz auf der Seite speichern kann, und diese dann verwenden, um den nächsten Teil abzurufen. Zum Beispiel haben wir eine solche Anfrage durchgeführt:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

In dem letzten Eintrag erhielten wir den Bestellungstermin '2014-06-29'. Um die nächste Seite zu erhalten, könnte man versuchen, Folgendes auszuführen:

SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Das Problem ist, dass OrderDate kein eindeutiges Feld ist und die oben angegebene Bedingung mit hoher Wahrscheinlichkeit viele benötigte Zeilen überspringen wird. Um Eindeutigkeit in diese Abfrage zu bringen, muss ein eindeutiges Feld zur Bedingung hinzugefügt werden (nehmen wir an, dass 75074 der letzte Wert des Primärschlüssels aus der ersten Charge ist):

SELECT * FROM Sales.SalesOrderHeader
WHERE (OrderDate = '2014-06-29' AND SalesOrderID < 75074)
   OR (OrderDate < '2014-06-29')
ORDER BY OrderDate DESC, SalesOrderID DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Diese Variante wird korrekt funktionieren, aber allgemein wird es schwierig sein, sie zu optimieren, da die Bedingung den Operator OR enthält. Wenn der Wert des Primärschlüssels mit steigendem OrderDate wächst, kann die Bedingung vereinfacht werden, indem nur der Filter nach SalesOrderID beibehalten wird. Wenn jedoch zwischen den Werten des Primärschlüssels und dem Feld, nach dem das Ergebnis sortiert ist, keine strikte Korrelation besteht, wird es in den meisten DBMS nicht möglich sein, dieses OR zu vermeiden. Eine mir bekannte Ausnahme ist PostgreSQL, das den Vergleich von Tupeln vollumfänglich unterstützt. Die oben genannte Bedingung kann als 'WHERE (OrderDate, SalesOrderID) < ('2014-06-29', 75074)' formuliert werden. Bei Vorhandensein eines zusammengesetzten Schlüssels mit diesen beiden Feldern sollte eine solche Abfrage recht einfach sein.

Einen alternativen Ansatz findet man beispielsweise in ElasticSearch Scroll API oder Cosmos DB — wenn die Abfrage neben den Daten einen speziellen Identifikator zurückgibt, mit dem die nächste Charge von Daten abgerufen werden kann. Wenn dieser Identifikator unbegrenzte Lebensdauer hat (wie in Cosmos DB), ist es eine hervorragende Möglichkeit, Paging mit sequenziellen Übergängen zwischen den Seiten zu implementieren (Variante #2, die oben erwähnt wurde). Mögliche Nachteile: wird nicht von allen DBMS unterstützt; der erhaltene Identifikator der nächsten Charge kann eine begrenzte Lebensdauer haben, was im Allgemeinen nicht für die Interaktion mit Benutzern geeignet ist (wie beispielsweise bei der ElasticSearch Scroll API).

Komplexe Filterung

Wir erschweren die Aufgabe weiter. Angenommen, es gibt die Anforderung, eine sogenannte facettierte Suche zu implementieren, die allen aus Online-Shops bekannt ist. Die oben genannten Beispiele basieren auf der Bestellungstabelle, sind in diesem Fall jedoch nicht sehr aussagekräftig, also wechseln wir zur Produkttabelle aus der AdventureWorks-Datenbank:

Was ist die Idee der facettierten Suche? Es ist so, dass für jedes Filterelement die Anzahl der Datensätze angezeigt wird, die diesem Kriterium entsprechen. unter Berücksichtigung der Filter, die in allen anderen Kategorien ausgewählt wurden..

Wenn wir in diesem Beispiel die Kategorie Fahrräder und die Farbe Schwarz auswählen, zeigt die Tabelle nur schwarze Fahrräder an, aber dabei:

• Für jedes Kriterium der Gruppe «Kategorien» wird die Anzahl der Produkte aus dieser Kategorie in Schwarz angezeigt.
• Für jedes Kriterium der Gruppe «Farben» wird die Anzahl der Fahrräder in dieser Farbe angezeigt.

Hier ist ein Beispiel für die Ausgabe des Ergebnisses unter solchen Bedingungen:

Wenn wir zusätzlich die Kategorie «Bekleidung» auswählen, zeigt die Tabelle auch schwarze Kleidung an, die verfügbar ist. Die Anzahl der Produkte in Schwarz in der Rubrik «Farben» wird ebenfalls gemäß den neuen Bedingungen neu berechnet, aber in der Rubrik «Kategorien» bleibt alles unverändert… Ich hoffe, diese Beispiele sind ausreichend, um den gewohnten Algorithmus der funktionsfähigen Suche zu verstehen.

Stellen wir uns nun vor, wie dies in einer relationalen Datenbank umgesetzt werden kann. Jede Gruppe von Kriterien, wie Kategorie und Farbe, erfordert eine separate Abfrage:

SELECT pc.ProductCategoryID, pc.Name, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
  INNER JOIN Production.ProductCategory pc ON ps.ProductCategoryID = pc.ProductCategoryID
WHERE p.Color = 'Black'
GROUP BY pc.ProductCategoryID, pc.Name
ORDER BY COUNT(1) DESC

SELECT Color, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
WHERE ps.ProductCategoryID = 1 --Fahrräder
GROUP BY Color
ORDER BY COUNT(1) DESC

Was ist also das Problem mit dieser Lösung? Ganz einfach – sie ist schlecht skalierbar. Jeder Abschnitt des Filters erfordert eine separate Abfrage zur Zählung der Mengen, und diese Abfragen sind nicht sehr leicht. In Online-Shops kann es in einigen Kategorien mehrere Dutzend Filterabschnitte geben, was zu einem ernsthaften Leistungsproblem werden kann.

Normalerweise schlagen mir nach diesen Aussagen einige Lösungen vor, nämlich:

• Alle Zählungen in eine Anfrage zusammenfassen. Technisch ist das möglich mit dem Schlüsselwort UNION, allerdings hilft das der Leistung nicht wirklich — die Datenbank muss dennoch jeden der Teile "von Grund auf" ausführen.
• Mengen cachen. Das wird mir praktisch jedes Mal vorgeschlagen, wenn ich das Problem beschreibe. Der Knackpunkt ist, dass dies im Allgemeinen unmöglich ist. Angenommen, wir haben 10 „Facetten“, von denen jede 5 Werte hat. Dies ist eine sehr „modeste“ Situation im Vergleich zu dem, was man in denselben Online-Shops sehen kann. Die Auswahl eines Facettenelements beeinflusst die Mengen in 9 anderen, mit anderen Worten, für jede Kombination von Kriterien können die Mengen unterschiedlich sein. In unserem Beispiel gibt es insgesamt 50 Kriterien, die der Benutzer auswählen kann, was bedeutet, dass es 250 mögliche Kombinationen gibt. Um ein solches Datenarray zu füllen, reicht weder der Speicher noch die Zeit aus. Man könnte einwenden, dass nicht alle Kombinationen realistisch sind und die Benutzer selten mehr als 5-10 Kriterien auswählen. Ja, es ist möglich, ein lazy loading und Caching der Menge nur für das zu machen, was jemals ausgewählt wurde, aber je mehr Auswahlmöglichkeiten es gibt, desto weniger effektiv wird dieses Cache und desto deutlicher werden die Probleme mit der Reaktionszeit (insbesondere wenn sich der Datensatz regelmäßig ändert).

Glücklicherweise gibt es für eine solche Aufgabe bereits seit langem ausreichend effiziente Lösungen, die vorhersehbar bei großen Datenmengen funktionieren. Für jede dieser Optionen ergibt es Sinn, die Neuberechnung der Facetten und das Abrufen der Ergebnisseite in zwei parallele Anfragen an den Server zu unterteilen und die Benutzeroberfläche so zu gestalten, dass das Laden der Facettendaten die Anzeige der Suchergebnisse "nicht stört".

• Rufen Sie die vollständige Neuberechnung der "Facetten" so selten wie möglich auf. Zum Beispiel sollten Sie nicht bei jeder Änderung der Suchkriterien alle berechnen, sondern stattdessen die Gesamtanzahl der Ergebnisse ermitteln, die den aktuellen Bedingungen entsprechen, und dem Benutzer anbieten, diese anzuzeigen – „1425 Einträge gefunden, anzeigen?“ Der Benutzer kann entweder weiterhin die Suchkriterien ändern oder auf die Schaltfläche „anzeigen“ klicken. Nur im zweiten Fall werden alle Anfragen zur Ergebnisbeschaffung und zur Neuberechnung der Anzahl der „Facetten“ ausgeführt. Dabei ist es offensichtlich, dass man mit der Anfrage zur Ermittlung der Gesamtanzahl der Ergebnisse und deren Optimierung umgehen muss. Diese Vorgehensweise findet man in vielen kleinen Online-Shops. Offensichtlich ist dies kein Allheilmittel für das Problem, kann aber in einfachen Fällen ein guter Kompromiss sein.
• Verwenden Sie Suchmaschinen wie Solr, ElasticSearch, Sphinx und andere zur Ergebnissuche und zur Zählung der Facetten. All diese sind darauf ausgelegt, „Facetten“ zu generieren, und tun dies dank des invertierten Indexes recht effektiv. Wie Suchmaschinen funktionieren, warum sie in solchen Fällen effektiver sind als allgemeine Datenbanken, welche Praktiken und Fallstricke es gibt – das ist ein Thema für einen eigenen Artikel. Hier möchte ich darauf hinweisen, dass eine Suchmaschine nicht das Hauptdatenspeicher ersetzen kann; sie wird als Ergänzung verwendet: Alle Änderungen in der Hauptdatenbank, die für die Suche von Bedeutung sind, werden mit dem Suchindex synchronisiert; der Suchmechanismus interagiert normalerweise nur mit der Suchmaschine und greift nicht auf die Hauptdatenbank zu. Einer der wichtigsten Punkte hierbei ist, wie man diese Synchronisation zuverlässig organisiert. Alles hängt von den Anforderungen an die „Reaktionszeit“ ab. Wenn die Zeit zwischen einer Änderung in der Hauptdatenbank und deren „Erscheinung“ in der Suche nicht kritisch ist, kann man einen Dienst erstellen, der alle paar Minuten nach kürzlich geänderten Datensätzen sucht und diese indexiert. Wenn die minimal mögliche Reaktionszeit erforderlich ist, kann man etwas wie transactional outbox zum Senden von Updates an den Suchdienst implementieren.

Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

1. Die Umsetzung von Paging auf der Serverseite ist eine ernsthafte Komplexität und sollte nur für schnell wachsende oder einfach große Datensätze sinnvoll eingesetzt werden. Es gibt kein absolut präzises Rezept, um »groß« oder »schnell wachsend« zu bewerten, aber ich würde mich an einen solchen Ansatz halten:
   • Wenn das Abrufen einer vollständigen Datensammlung unter Berücksichtigung der Serverzeit und der Netzwerkübertragung innerhalb der Leistungsanforderungen liegt, macht ein Paging auf der Serverseite keinen Sinn.
   • Es kann die Situation eintreten, dass in naher Zukunft keine Leistungsprobleme zu erwarten sind, da die Datenmenge gering ist, die Datensammlung jedoch ständig wächst. Wenn ein bestimmter Datensatz in der Zukunft möglicherweise die vorherige Anforderung nicht mehr erfüllt, ist es besser, das Paging gleich von Anfang an vorzusehen.
2. Wenn vonseiten des Geschäfts keine strenge Forderung besteht, die Gesamtanzahl der Ergebnisse oder die Seitenzahlen anzuzeigen, und in Ihrem System kein Suchmaschinen-Engine vorhanden ist, ist es besser, diese Punkte nicht zu implementieren und die Variante #2 in Betracht zu ziehen.
3. Wenn es eine klare Anforderung für facettiertes Suchen gibt, haben Sie zwei Möglichkeiten, die Leistung nicht zu beeinträchtigen:
   • Nicht alle Mengen bei jeder Änderung der Suchkriterien neu zu berechnen.
   • Suchmaschinen wie Solr, ElasticSearch, Sphinx und andere zu verwenden. Man sollte jedoch verstehen, dass sie die Hauptdatenbank nicht ersetzen können und als Ergänzung zu dem Hauptspeicher für die Lösung von Suchanfragen verwendet werden sollten.
4. Auch im Falle des facettierten Suchens macht es Sinn, das Abrufen der Suchergebnisse und das Zählen der Mengen in zwei parallele Anfragen zu unterteilen. Das Zählen der Mengen kann länger dauern als das Abrufen der Ergebnisse, während die Ergebnisse für den Benutzer wichtiger sind.
5. Wenn Sie eine SQL-Datenbank für die Suche verwenden, sollte jede Codeänderung in diesem Bereich gut auf Leistung bei den entsprechenden Datenmengen getestet werden (über die Menge in einer »lebendigen« Datenbank). Es ist auch ratsam, die Ausführungszeiten von Abfragen auf allen Datenbankinstanzen zu überwachen, insbesondere auf der »lebenden«. Selbst wenn in der Entwicklungsphase mit den Abfrageplänen alles gut war, kann sich die Situation mit wachsender Datenmenge merklich ändern.

Quelle: habr.com