ElasticSearch oder Couchbase oder etwas anderes

Question

Hintergrund: Ich habe einen riesigen Datenstrom - bis zu 1000000 Datensätze pro Stunde, ttl ist 3 Stunden ... Jedes "Dokument" enthält ca. 20 Eigenschaften, die ich suchen muss 15 Eigenschaften gleichzeitig mit "==", "IN" und "BETWEEN" Vergleich.

Da es größtenteils keine nicht durchsuchbaren Eigenschaften gibt, gibt es keinen Grund, Dokumente zweimal zu speichern (in Couchbase UND im ElasticSearch-Index), daher ist es eine gute Idee, sie nur in ElasticSearch zu speichern. Ich habe recht?

Oder vielleicht jemand kann mir bessere Datenbank für solche Aufgabe empfehlen? Ich brauche eine leicht horizontale Skalierung in Zukunft (custom sharding von MySQL ist keine Option) ... Diese Daten eine Art Cache so Eventual Consistency ist und eine schlechte Haltbarkeit ist OK ...

Nach CAP-Theorem I brauche meistens A und P ...

Answer 1

In Bezug auf die Leistung sollten Sie keine Probleme bei der Indizierung von 1 Mio. Dokumenten pro Stunde haben. Ich habe Elasticsearch gut darüber ohne Probleme laufen lassen. Es gibt eine detaillierte writeup hier, dass Sie nützlich in Bezug auf Benchmarking finden können und eine große Elasticsearch Cluster Sizing:

ElasticSearch setup for a large cluster with heavy aggregations

Für ein ephemere Caching-System mit einem TTL von nur 3 Stunden, die ich damit einverstanden ist eine Verschwendung wäre, zu speichern, die Daten in mehr als einem Repository. Sie könnten die Daten in Couchbase speichern und in Echtzeit oder nahezu in Echtzeit in Elasticsearch replizieren, aber warum sollten Sie sich damit beschäftigen? Nicht sicher, welchen Nutzen Sie daraus ziehen würden, die Daten an beiden Orten zu haben.

Bei Leistungsproblemen, die Ihren spezifischen Anwendungsfall betreffen, würde ich Ihnen ein Benchmarking dringend empfehlen. Eine Stärke von Elasticsearch (und auch Solr), die ich gefunden habe, ist ihre (für mich) überraschend starke Leistung bei der Suche in mehreren Nicht-Textfeldern. Sie neigen dazu, an ES für Textsuchzwecke zu denken (wo es sich auszeichnet), aber es ist auch eine anständige Allzweckdatenbank. Ich habe festgestellt, dass es im Vergleich zu einigen anderen NoSQL-Lösungen eine starke Leistung bei der Suche nach mehreren Parametern bietet.

Persönlich beim Benchmarking von ES in diesem Anwendungsfall würde ich eine Reihe von verschiedenen Indizierungsoptionen betrachten.ES unterstützt TTL für Dokumente so automatisch den Cache Spülen ist einfach:

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-ttl-field.html

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html

auch immer Sie mit mit verschiedenen Indizes für jede jede Stunde spielen, um möchten - eine Sache, über ES (aufgrund es ist die Verwendung von Lucene darunter für die Indizierung und Dateispeicherung) ist das löscht Arbeit anders als die meisten Datenbanken. Dokumente werden als gelöscht markiert, aber nicht entfernt. Anschließend werden die darunter liegenden Dateien (Segmente genannt) regelmäßig zusammengeführt. Zu diesem Zeitpunkt werden neue Segmente ohne die gelöschten Dokumente erstellt. Dies kann zu einer beträchtlichen Menge an Festplattenaktivitäten führen, die in einem einzelnen Index große Anwendungsfälle mit hohem Volumen löschen. Der Weg dazu besteht darin, für jede Stunde einen neuen Index zu erstellen und dann den Index in seiner Gesamtheit zu löschen, nachdem die darin enthaltenen Daten mehr als 3 Stunden alt sind.

Sie können diese vorherige Diskussion über TTL-Zeit-Serie Indizes in Elasticsearch nützlich finden: Performance issues using Elasticsearch as a time window storage

schließlich in Bezug auf einfache horizontale Skalierung Elasticsearch ist ziemlich gut hier - Sie einen neuen Knoten mit dem richtigen Clusternamen und ES hinzufügen kümmert sich um den Rest und migriert Shards automatisch auf den neuen Knoten. In Ihrem Anwendungsfall möchten Sie möglicherweise mit dem Replikationsfaktor spielen, da mehr Repliken über mehrere Knoten hinweg die einfache Möglichkeit bieten, die Abfrageleistung zu steigern.

Answer 2

Für den Anwendungsfall eines Caches (Cache-ähnliches System), ich denke, Elasticsearch wird Ihnen nur Probleme in der Zukunft geben. Ich nehme an, Sie brauchen überhaupt keine Indexierung, da Sie nicht nach Funktionen suchen.

Ich habe Couchbase nicht benutzt, aber ich habe gute Dinge darüber gehört. Ich habe Anwendungsfälle wie die Verwendung von Couchbase für mehr Filterzwecke und Elasticsearch für mehr suchähnliche Zwecke (und Dinge, die Couchbase nicht tun kann) gehört.

Für Skalierbarkeit, so weit ich kann sagen beide ähnlich aus einer sehr hohen Sicht. Beide unterstützen einfaches Sharding und Replikation mit Neuverteilung von Shards und sekundärem Replica-Heraufstufen auf Primary, wenn ein Knoten im Cluster ausfällt. Die Besonderheiten können unterschiedlich sein.

Aber in aller Ehrlichkeit müssen Sie es selbst ausprobieren und mit der Produktion wie Verkehr testen. Ich habe mit Elasticsearch zusammengearbeitet und weiß, dass man nicht immer sagen kann, ob es die richtige Wahl für den Anwendungsfall ist, weil sich das Verhalten für eine Anwendung in der Produktion anders verhalten kann.

Aber ich denke, Sie sind auf dem richtigen Weg.