Gute Praktiken zwischen SQL und elasticsearch

Question

Stellen Sie sich vor Sie haben eine SQL-Datenbank wie MySQL oder Postgresql. Sie haben zwei Tabellen: Benutzer und Auto. Ein Benutzer kann N Autos fahren, ein Auto kann von N Benutzern gefahren werden, so dass Sie eine dritte "Laufwerk" -Tabelle mit zwei Fremdschlüsseln haben.

Jetzt möchten Sie, dass Ihre Tabelle Benutzer elasticsearch geht, weil Sie Benutzer nach Name, E-Mail ... etc suchen möchten ... Vielleicht müssen Sie auch einige Suche auf der Autotabelle tun.

Ich sehe drei Weg, dies zu erreichen, ich d'gerne wissen, was der beste Weg ist:

1) Abandon die SQL-Datenbank. Alle deine Tische sind jetzt auf elasticsearch. Sie können suchen, was Sie wollen, aber Sie müssen alle Ihre Einschränkungen manuell behandeln.

2) Halten Sie die Struktur auf der SQL-Datenbank, behalten Sie Ihre drei Tabellen, die Primärschlüssel und die Fremdschlüssel. Ihre Tabellen enthalten jedoch nur die Elasticsearch-ID der zugehörigen Zeile in elasticsearch. Zum Beispiel in Tabelle Benutzer, halten Sie user_id und fügen Sie eine user_elasticsearch_id, die auf die elasticsearch Zeile, wo Sie den Namen, die E-Mail ... etc ... Also haben Sie Ihre SQL-Einschränkungen, können Sie suchen, aber Sie müssen beibehalten zwei Tische.

3) Duplizieren. Sie berühren Ihre SQL-Datenbank nicht, Sie duplizieren alle Zeilen in der ElasticSearch-Datenbank. Sie haben Ihre Beschränkungen, Sie können suchen, aber wieder müssen Sie zwei Tabellen verwalten, und Sie haben zweimal die Daten und zweimal den Speicher.

Nun, tapferer Kollege von stackoverflow, was würdest du in diesem Fall tun?

Vielen Dank.

Answer 1

Da Sie möglicherweise viele Geschäftsregeln in Ihre Datenbank und Anwendung gemischt haben, würde ich konservativ sein und die DB behalten. Verwenden Sie ES, um die Benutzerattribute zu indexieren, nach denen ich suchen möchte. ES würde erzielte Ergebnisse zurückgeben. Wenn ein Ergebnis ausgewählt wird, würde ich zu DB wechseln, um alle Informationen und Beziehungen abzurufen.

Also würde ich 2b wählen: DB behalten und PK in ES speichern, nicht ID in DB).

Bedenken Sie, dass Sie die ID in ES erzwingen können. Es könnte "user_PK" oder etwas ähnliches sein.

Answer 2

Das am häufigsten verwendete Setup für kritische Geschäftsdaten ist z. eine SQL-Datenbank als primärer Datenspeicher und Elasticsearch als zusätzlichen Suchindex. (= deine Lösung 3).

Eine Alternative für nicht geschäftskritische Daten wie Logs usw. ist die eigenständige Verwendung von Elasticsearch.

Lösung 2 scheint verdrahtet, ist keine Option für mich.