2016-06-30 11 views
1

Unsere Firma hat mehrere Produkte und mehrere Teams. Ein Team ist für die Suche zuständig und standardisiert Elasticsearch als Nosql-Datenbank, um alle ihre Daten zu speichern. Später soll Neo4j verwendet werden, um die Suche mit Beziehungsdaten zu ergänzen.Was sind die Fallstricke für die Verwendung von ElasticSearch als Nosql-Datenbank für eine soziale Anwendung im Vergleich zu einer Diagrammdatenbank?

Mein Team ist verantwortlich für die Produktseite einer sozialen App (Menschen haben Freunde und arbeiten für Unternehmen und sind Kollegen mit allen, die in ihren Unternehmen arbeiten usw.). Wir betrachten Graph dbs als Lösung (nachdem wir das brennende Schiff verlassen haben, das sind n^2 Beziehungen in rdbms), speziell neo4j (die Cypher-Abfragesprache ist eine schöne Sache).

Eine Teilmenge unserer Daten ist ähnlich den Daten, die vom Suchteam verwendet werden, und wir müssen sicherstellen, dass die Suche ihre Daten und unsere Daten gleichzeitig durchsuchen kann. Das Search-Team drängt uns, ElasticSearch für unsere db statt für Neo4j oder irgendeine Graph db zu standardisieren. Ich glaube, das ist der Standardisierung und Konsistenz zuliebe.

Wir kommen offensichtlich von sehr verschiedenen Orten hier, suchen Sie Bedenken gegen Produkt Bedenken. Er behauptet, dass ElasticSearch alle unsere Anwendungsfälle abdecken kann, einschließlich graphischer Abfragen, um Vorschläge zu finden. Obwohl das wahrscheinlich wahr ist, möchte ich wirklich bei Neo4j bleiben und ein ElasticSearch-Plugin verwenden, um es in die Suche zu integrieren.

Gibt es in dieser Situation größere Schwierigkeiten, ElasticSearch über Neo4j für ein Produkt db (oder umgekehrt) zu wählen? Irgendwelche Richtlinien oder Anekdoten von denen, die in ähnlichen Situationen waren?

+0

[Elasticsearch bietet Graph Funktionalität] (https://www.elastic.co/products/graph). Die Frage hängt wirklich davon ab, wie Sie es verwenden möchten und ob Sie einen Datenspeicher mit einigen Grafikfunktionen gegenüber einem Diagrammdatenspeicher mit sehr wenigen Suchfunktionen wünschen. – pickypg

+0

@pickypg Korrigieren Sie mich, wenn ich falsch liege, aber das sieht aus, als würde es hauptsächlich dazu verwendet, Ihre Daten grafisch zu durchsuchen und zu visualisieren und interessante relationale Eigenschaften der Daten zu erkunden. Beide tollen Anwendungsfälle, also sollte ich klarstellen, dass ich eher daran interessiert bin, die Daten und Beziehungen einfach zu modellieren und graphenorientiert abzufragen (schmerzlos mit einem Graph db). [Es gibt Lösungen zur Integration beider] (https://neo4j.com/developer/elastic-search/), die ich für das Beste aus beiden Welten favorisieren würde. – InverseFalcon

+0

Es gibt einen ['_graph' API-Endpunkt, der damit einhergeht] (https://www.elastic.co/guide/en/graph/current/graph-api-rest.html). Ich weiß ehrlich nicht, wie es für Ihre Interessen vergleicht. – pickypg

Antwort

6

Wir sind starke Nutzer beider Technologien, und nach unserer Erfahrung würden Sie besser beide nutzen, wofür sie gut sind.

Elasticsearch ist eine super gute Software, wenn es um Suchfunktionen, Log Management und Facetten geht.

Trotz ihrer Graph-Plugin, wenn Sie eine Menge von sozialen Netzwerken und gleichermaßen Beziehungen in Elasticsearch Indizes verwenden möchten, werden Sie zwei Probleme:

  1. Sie werden jedes Mal eine Beziehung Änderungen aktualisieren Dokumente müssen, Das kann zu viel werden, wenn sich eine einzelne Entität ändert. Angenommen, Sie haben Organisationen mit Benutzern, die Beiträge zu github leisten, und Sie möchten nach Organisationen mit den besten Beitragenden in einer bestimmten Sprache suchen. Jedes Mal, wenn ein Benutzer einen Beitrag zu github leistet, müssen Sie die gesamte Organisation neu indizieren , prozentualer Anteil der Beiträge von Sprachen für alle Benutzer usw. ... Und dies ist ein einfaches Beispiel.

  2. Wenn Sie beabsichtigen, verschachtelte Felder und partent/Kind-Mapping zu verwenden, werden Sie die Leistung während der Suche, in Bezug verlieren, das Zitat aus dem „Tuning für die Suche“ Dokumentation hier: https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html#_document_modeling

Dokumente sollten so modelliert werden, dass Suchvorgänge so billig wie möglich sind.

Insbesondere sollten Verbindungen vermieden werden. verschachtelt kann Abfragen mehrmals langsamer machen und Eltern-Kind-Beziehungen können Abfragen Hunderte von Mal langsamer. Also, wenn die gleichen Fragen beantwortet werden können ohne Joins durch Denormalisierung von Dokumenten, können erhebliche Beschleunigungen erwartet werden.

Beziehungen werden in einer Graphdatenbank wie neo4j sehr gut behandelt. Im Gegensatz zu Neo4j fehlen Suchfunktionen, die elasticsearch bietet. Eine Volltext-Suche ist zwar möglich, aber nicht so performant und führt zu einer gewissen Belastung in Ihrer Anwendung.

Hinweis abgesehen: wenn Sie über "speichern" sprechen, ist elasticsearch eine Suchmaschine keine Datenbank (während es verwendet wird, wie es ist), während neo4j ist eine voll transaktionsfähige Datenbank.

jedoch beide kombiniert, ist der Gewinner Prozess, wir haben einen Artikel tatsächlich geschrieben, diesen Prozess zu beschreiben, die wir Graph-Aided Search mit einer Reihe von Open-Source-Plugins rufen für beide Elasticsearch und Neo4j Sie eine leistungsfähige Zwei-Wege-Integration bietet aus der Box .

können Sie hier mehr darüber lesen: http://graphaware.com/neo4j/2016/04/20/graph-aided-search-the-rise-of-personalised-content.html

+0

Awesome Antwort, gut, um Input von jemandem mit beiden erfahren zu bekommen! – InverseFalcon