PostgreSQL (Volltextsuche) vs ElasticSearch

Hallo, ich recherchiere, bevor ich die Suchfunktion in meinen Dienst implementiere. Ich verwende derzeit PostgreSQL als Hauptspeicher. Ich könnte definitiv die in PostgreSQL integrierte Volltextsuche verwenden, aber das Problem ist, dass ich Daten in mehreren Tabellen verteilt habe.

Mein Service ist eine E-Commerce-Website. Wenn ein Kunde nach "guter Apple-Laptop" sucht, muss ich BrandTabelle, postTabelle und reviewTabelle verbinden (1 Beitrag ist eine Kombination aus mehreren Bewertungen + einer kurzen Zusammenfassung), um alle Beiträge vollständig zu durchsuchen. Wenn ich elasticsearch verwenden würde, könnte ich vollständige Beiträge durch Vorverarbeitung einfügen.

Nach meinen Recherchen haben einige Leute gesagt, dass FTS und Elasticsearch von PostgreSQL eine ähnliche Leistung haben, und einige Leute sagten, dass Elasticsearch schneller ist. Welche wäre die bessere Lösung für meinen Fall?

Danke im Voraus

postgresql elasticsearch full-text-search

— JSC
quelle

Woher wissen Sie, dass das Suchschlüsselwort mit einigen Tabellen zusammenhängt, die Sie in Ihrer Datenbank gespeichert haben?

— Nadelbäume

Ich habe nicht darüber nachgedacht, alle möglichen Spalten in verschiedenen Tabellen zusammenzufügen und sie in ts_vector umzuwandeln. Gibt es bessere Lösungen?

— JSC

Hmm, dies wird mit semantischen Erkennungsproblemen verbunden sein und es ist eine andere Geschichte ...

— Conifers

Antworten:

-5

Kurze Antwort: Elasticsearch ist besser

Erläuterung: PostgreSQL und Elasticsearch sind zwei verschiedene Datenbanken. Elasticsearch ist leistungsstark für die Dokumentensuche und PostgreSQL ist immer noch ein traditionelles RDBMS. Überprüfen Sie Ihr Ziel, ob Sie in einigen Posts nach Text suchen möchten. Unabhängig davon, wie gut PostgreSQL bei der Volltextsuche funktioniert, wurde Elasticsearch für die Suche in riesigen Texten und Dokumenten (oder Datensätzen) entwickelt. Und je größer die Größe ist, in der Sie suchen möchten, desto besser ist Elasticsearch in der Leistung als PostgreSQL. Darüber hinaus können Sie viel Nutzen und eine hervorragende Leistung erzielen, wenn Sie die Beiträge in mehreren Feldern und Indizes vorverarbeiten, bevor Sie sie in Elasticsearch speichern.

Wenn Sie sicherlich eine Volltextfunktion benötigen, können Sie MSSQL in Betracht ziehen, das möglicherweise besser als PostgreSQL ist.

Antwort auf Kommentare: Es sollte der gesunde Menschenverstand für den Eigenschaftenvergleich für diese verschiedenen Typ-DBs sein. Da OP nicht angegeben hat, welche Menge und Größe der Daten gespeichert sind. Wenn es sich um kleine Daten in der Suche handelt, wählen Sie möglicherweise Postgre oder ES sind beide in Ordnung. Wenn jedoch das Transaktions- und Datenrepository in Zukunft so groß wird, wird ES davon profitieren.

Sie können diese Site überprüfen , um die aktuelle Rangfolge der einzelnen DB-Typen zu ermitteln und die beste unter Ihren Anforderungen, Ihrer Architektur und Ihrem Datenwachstum für die Zukunft Ihrer Anwendungen auszuwählen.

— Nadelbäume
quelle

Einig über die Rethorik, aber wenn Sie Beweise oder andere Quellen haben, wird es zuverlässiger sein.

— Jaisus

Ihre Antwort basiert nur auf Ihrer Meinung, Sie haben kein Beispiel, keinen Benchmark oder Link geschrieben, um Ihren Standpunkt zu belegen, und ich kann keine anderen Ihrer Antworten zu diesem Thema sehen, die beweisen, dass Sie über diese Software Bescheid wissen. Ich sehe, dass Sie ein neuer Mitwirkender sind, daher würde ich Ihnen für das nächste Mal empfehlen, keinen absoluten Satz zu schreiben und Ihre Erfahrungen, realen Daten oder Links zu melden, um Ihre These zu beweisen.

— Paolo Melchiorre

@conifers gut das Update und die Klarstellung Ihrer Antwort, aber der Link, den Sie hinzugefügt haben, beweisen nicht Ihren Standpunkt. Ich war interessiert, ob Sie eine URL mit einem Vergleich oder einem Benchmark hinzugefügt hätten.

— Paolo Melchiorre

Ein Ranking nach Beliebtheit bedeutet nicht, dass Elasticsearch PostgreSQL bei der Volltextsuche übertrifft. "Besser" und "Es sollte der gesunde Menschenverstand sein" bedeuten, dass wir einen Benchmark oder Test erwarten, der diese beiden Technologien in Ihrer Antwort vergleicht, die es nicht gibt.

— Yasser Sinjab

Wenn sich PostgreSQL bereits in Ihrem Stapel befindet, verwenden Sie am besten die PostgreSQL-Volltextsuche.

Warum Volltextsuche (FTS) in PostgreSQL?

Denn sonst müssen Sie Datenbankinhalte an externe Suchmaschinen weitergeben.

Externe Suchmaschinen (zB Elasticsearch) sind schnell, ABER :

Sie können nicht alle Dokumente indizieren - können vollständig virtuell sein
Sie haben keinen Zugriff auf Attribute - keine komplexen Abfragen
Sie müssen beibehalten werden - Kopfschmerzen für DBA
Manchmal müssen sie zertifiziert werden
Sie bieten keine sofortige Suche (benötigen Zeit, um neue Daten herunterzuladen und neu zu indizieren)
Sie bieten keine Konsistenz - Suchergebnisse können bereits aus der Datenbank gelöscht werden

Wenn Sie mehr über FTS in PostgreSQL lesen möchten, gibt es eine großartige Präsentation von Oleg Bartunov (ich habe die obige Liste von hier extrahiert): "Benötigen Sie eine Volltextsuche in PostgreSQL? "

Dies ist ein kurzes Beispiel dafür, wie Sie ein "Dokument" (lesen Sie die Textsuchdokumentation ) aus mehr als einer Tabelle in SQL erstellen können :

SELECT to_tsvector(posts.summary || ' ' || brands.name) 
FROM posts
INNER JOIN brands ON (brand_id = brands.id);

Wenn Sie Django für Ihre E-Commerce-Website verwenden, können Sie auch diesen Artikel lesen, den ich über " Volltextsuche in Django mit PostgreSQL " geschrieben habe.

— Paolo Melchiorre
quelle

Etwas an der Aussage von elasticsearch ist falsch ... Sie können nicht alle Dokumente indizieren: Sicher können Sie! Wenn Sie es bereits während der Indizierung identifiziert und in Ihre Konfiguration umgewandelt haben, müssen Sie wie in PostgreSQL zuerst die DDL definieren. Sie haben keinen Zugriff auf Attribute : Ja, es könnte wahr sein, weil PostgreSQL aufgrund allgemein verwendeter Datenbanken CRUD gut unterstützen muss. Sie müssen gepflegt werden : Muss PostgreSQL nicht gepflegt werden? ... Die routinemäßige Sicherung und Leistungsoptimierung ist unabhängig vom DB-Typ weiterhin erforderlich.

— Nadelbäume

Sie bieten keine sofortige Suche : Nun, ES ist nur stark in der sofortigen Suche ... bitte versuchen Sie es zuerst mit Kibana. Sie bieten keine Konsistenz : Dies ist möglicherweise die einzig wahre Aussage, da RDBMS für ACID-Eigenschaften erforderlich ist.

— Nadelbäume

Der vollständige Satz lautet: Sie bieten keine sofortige Suche (benötigen Zeit, um neue Daten herunterzuladen und neu zu indizieren) : Wenn Ihr Benutzer auf der E-Commerce-Website (wie in der Frage) das letzte verfügbare Element1 kauft, werden diese Informationen sofort gespeichert unter PostgreSQL und wenn Sie die Volltextsuche von PostgreSQL verwenden, finden andere Benutzer Item1 nicht im Suchbereich. Andernfalls benötigen Sie bei Verwendung von Elasitcsearch Zeit, um diese neuen Informationen an Elasticsearch zu senden und neu zu indizieren, bevor andere Benutzer Item1 nicht mehr im Suchergebnis sehen. Vielleicht versuchen sie es zu kaufen, aber es ist nicht mehr verfügbar. :-(

— Paolo Melchiorre

Zu allen anderen Punkten in der Liste möchte ich nur eines schreiben: In der ursprünglichen Frage @jsc wurde geschrieben, dass sie bereits PostgreSQL in ihrem Stapel haben, sodass die Daten bereits dort gespeichert sind. Sie haben bereits Zugriff auf alle Attribute, um Volltext auszuführen Suche mit relationaler Abfrage. ABER wenn Sie Elasticsearch verwenden, müssen Sie Zeit hinzufügen, um einen kleinen Teil der Daten (nicht alle Attribute) von PG an ES zu senden, Zeit, um Daten in ES neu zu indizieren. Am Ende haben Sie mit ES einen weiteren Dienst zum Verwalten, mehr Speicher belegt, mehr Speicherplatz zum Speichern redundanter Daten und Verzögerungen in Ihrem gesamten Prozess.

— Paolo Melchiorre