Was die Anwendungsfälle von Graph-basierten Datenbanken sind (http://neo4j.org/)? [geschlossen]

Question

Ich habe Relationale DB viel verwendet und entschied sich für andere Arten zu wagen zur Verfügung.

Dieses besondere Produkt sieht gut aus und vielversprechend: http://neo4j.org/

Hat jemand verwendet Graph-basierten Datenbanken? Was sind die Vor- und Nachteile von Usability prespective?

Haben Sie diese in einer Produktionsumgebung eingesetzt? Was war die Anforderung, dass Sie aufgefordert, sie zu benutzen?

Answer 1

Ich habe eine Graph-Datenbank in einem früheren Job. Wir wurden mit Neo4j nicht, es war ein hauseigenes Ding oben auf Berkeley DB gebaut, aber es war ähnlich. Es wurde in der Produktion verwendet (es ist immer noch).

Der Grund, warum wir eine Graph-Datenbank verwendet wurde, war, dass die Daten durch das System gespeichert werden und die Operationen wurde das System mit den Daten zu tun waren genau die Schwachstelle von relationalen Datenbanken und waren genau die starke Stelle von Graph-Datenbanken. Das System zur Speicherung von Sammlungen von Objekten benötigt, die ein festes Schema fehlen und sind miteinander durch Beziehungen verknüpft. Vernunft über die Daten, das System benötigt, um eine Vielzahl von Operationen zu tun, die ein paar Querungen in einer Graph-Datenbank sein würde, aber das wäre ziemlich komplexe Abfragen in SQL.

Die wichtigsten Vorteile des Graphen-Modell waren schnelle Entwicklungszeit und Flexibilität. Wir können schnell neue Funktionen hinzufügen, ohne dass bestehende Installationen zu beeinträchtigen. Wenn ein potenzieller Kunde einen Teil ihrer eigenen Daten und pfropft es oben auf unserem Modell importieren wollte, könnte es in der Regel vor Ort durch den Vertriebsmitarbeiter erfolgen. Flexibilität auch dazu beigetragen, als wir ein neues Feature entwerfen, sparen uns von dem Versuch, neue Daten in ein starres Datenmodell zu drücken.

Mit einer seltsamen Datenbank lassen uns viele unserer anderen seltsamen Technologien bauen, uns viele secret-Sauce geben unser Produkt von denen unserer Wettbewerber zu unterscheiden.

Der größte Nachteil war, dass wir die Standard-relationale Datenbank-Technologie nicht verwenden, was ein Problem sein kann, wenn Ihre Kunden enterprisey sind. Unsere Kunden fragen würden, warum können wir nicht nur unsere Daten hosten auf ihrer riesigen Oracle Cluster (unsere Kunden hatten in der Regel große Datenzentren). Einer der Mannschaft neu geschrieben tatsächlich die Datenbankschicht Oracle zu verwenden (oder PostgreSQL oder MySQL), aber es war etwas langsamer als das Original. Mindestens ein großes Unternehmen hatte sogar eine Oracle-nur Politik, aber glücklicherweise Oracle gekauft Berkeley DB. Wir hatten auch eine Menge zusätzlicher Werkzeuge schreiben -. Wir Crystal Reports nicht nur zum Beispiel verwenden könnte

Der andere Nachteil unserer Graph-Datenbank war, dass wir es selbst gebaut, was bedeutete, dass, wenn wir ein Problem treffen (in der Regel mit der Skalierbarkeit) hatten wir es sie zu lösen. Wenn wir eine relationale Datenbank verwendet hätten, wäre der Verkäufer bereits vor dem Problem 10 Jahren gelöst hat.

Wenn Sie ein Produkt für enterprisey Kunden den Aufbau und Ihre Daten passt in das relationale Modell, verwenden Sie eine relationale Datenbank, wenn Sie können. Wenn Ihre Anwendung nicht das relationale Modell paßt aber das Grafik-Modell paßt, verwenden Sie eine Graph-Datenbank. Wenn es nur etwas anderes passt, dass verwenden.

Wenn Ihre Anwendung muss nicht in die aktuelle blub Architektur passen, verwenden Sie ein Graph-Datenbank oder CouchDB oder BigTable, oder was auch immer Ihre Anwendung passt und Sie denken, ist cool. Es könnte Ihnen einen Vorteil geben, und es macht Spaß, neue Dinge auszuprobieren.

Was auch immer Sie gewählt haben, versuchen Sie nicht, die Datenbank-Engine selbst, wenn Sie wirklich zu bauen wie Datenbank-Engines zu bauen.

Answer 2

Wir haben seit über einem Jahr mit dem Neo-Team arbeitet jetzt und waren sehr zufrieden. Wir modellieren wissenschaftliche Artefakte und deren Beziehungen, die für einen Graphen db genau das Richtige ist, und führen Sie Empfehlungsalgorithmen über das Netzwerk.

Wenn Sie bereits in Java arbeiten, denke ich, dass die Modellierung mit Neo4j ist sehr einfach und es hat die flachste / schnellste Leistung für R / W von anderen Lösungen, die wir ausprobiert.

Um ehrlich zu sein, ich habe eine harte Zeit nicht in Form einer Grafik / Netzwerkes zu denken, weil es so viel einfacher, als die Gestaltung gewundene Tabellenstrukturen Objekteigenschaften und Beziehungen zu halten.

Dass gesagt wird, speichern wir einige Informationen in MySQL einfach, weil es für die Business-Seite leichter gegen schnelle SQL-Abfragen auszuführen. Um die gleichen Funktionen mit Neo ausführen würden wir brauchen, Code zu schreiben, die wir einfach nicht die Bandbreite für jetzt haben. Sobald wir jedoch tun, ich bin all diese Daten zu Neo Bewegung!

Viel Glück.

Answer 3

Zwei Punkte:

Als erste auf den Daten Ich habe mit den letzten 5 Jahren in SQL Server arbeiten, ich habe vor kurzem der Skalierbarkeit Wand für die Art von Abfragen mit SQL schlägt wir (verschachtelte relationhsips laufen müssen ... Sie wissen. ..graphs). Ich habe mit Neo4j herumgespielt, und meine Lookup-Zeiten sind um mehrere Größenordnungen schneller, wenn ich diese Art von Lookup müssen.

Zweitens, bis zu dem Punkt, die Graph-Datenbanken veraltet sind. Äh ... nein. Schon früh, wie die Leute auf Figur versuchen, wie effizient Daten zu speichern und Lookup, erstellt sie und spielte mit Grafik und Netzwerk-Stil Datenbankmodellen. Diese wurden so konzipiert, das physikalische Modell das logische Modell reflektiert, so dass ihre Effizienz so groß war nicht. Diese Art der Datenstruktur war gut für semi-strukturierte Daten, aber nicht so gut für strukturierte dichte Daten. Also, das IBM Geck namens Codd erforschte effiziente Weise zu ordnen und strukturierte Daten zu speichern und kam auf die Idee für das relationale Datenbankmodell auf. Und es war gut, und die Menschen waren glücklich.

Was haben wir denn hier? Zwei Werkzeuge für zwei verschiedene Zwecke. Graphdatenbankmodelle sind sehr gut für die Darstellung von semi-strukturierten Daten und die Beziehungen zwischen den Entitäten (dh existieren kann oder auch nicht). Relationale Datenbanken sind gut für strukturierte Daten, die ein sehr statisches Schema hat, und wo Tiefen kommen nicht gehen sehr tief. Man ist gut für eine Art von Daten, das andere ist gut für andere Arten von Daten.

, um die Phrase zu prägen, gibt es keinen Königsweg. Es ist sehr kurzsichtig zu sagen, dass Graph-Datenbank Modelle veraltet sind und zu verwenden ein 40 Jahre Fortschritt aufgibt. Das ist wie wenn man sagt mit C aufgibt alle technologischen Fortschritte, die wir durchgemacht haben Dinge wie Java und C # zu erhalten. Das ist aber nicht wahr. C ist ein Werkzeug, das für bestimmte Aufgaben benötigt wird. Und Java ist ein Werkzeug für andere Aufgaben.

Answer 4

Ich habe seit Jahren MySQL unter Verwendung von Engineering-Daten zu verwalten, und es hat gut funktioniert, aber eines der Probleme hatten wir (aber nicht erkennen, wir hatten) war, dass wir immer das Schema up-front planen mussten. Ein weiteres Problem, wir wussten, dass wir hatten, war die Abbildung der Daten bis zu Domänenobjekten und zurück.

Jetzt haben wir gerade erst begonnen Neo4j ausprobiert und es sieht aus wie es beiden Probleme für uns zu lösen. Die Fähigkeit, unterschiedliche Eigenschaften zu jedem Knoten (und Beziehung) hinzuzufügen, hat uns erlaubt, zu überdenken, unsere gesamte Herangehensweise an Daten. Es ist wie dynamisch im Vergleich zu statischen Sprachen (Rubin im Vergleich zu Java), aber für Datenbanken. Der Aufbau des Datenmodells in der Datenbank kann in einer wesentlich agiler und dynamischer Art und Weise durchgeführt werden, und das ist unser Code drastisch vereinfacht wird.

Und da im Code das Objektmodell im Allgemeinen eine Graphenstruktur ist, die Kartierung aus der Datenbank ist auch einfacher, mit weniger Code und damit weniger Fehlern.

tatsächlich ausführt schneller als die vorherige Version MySQL

Und als zusätzlichen Bonus, unser erster Prototyp-Code für unsere Daten in Neo4j geladen. Ich habe keine festen Zahlen auf diesem (noch) nicht, aber das war eine nette Zusatzfunktion.

Aber am Ende des Tages sollte die Wahl wohl vor allem auf die Art Ihrer Domain-Modell basieren. Ist wo es sich besser auf Tabellen oder Grafiken? Entscheiden Sie, indem Sie einige Prototypen zu tun, um die Daten laden und mit ihm spielen. Verwenden Sie neoclipse bei verschiedenen Sichten auf die Daten zu suchen. Sobald Sie das getan haben, hoffentlich wissen Sie, wenn Sie auf eine gute Sache sind oder nicht.

Answer 5

Ich baue ein Intranet in meinem Unternehmen.

Ich interessiere mich für das Verständnis, wie die Daten zu laden, die in den Tabellen (Oracle, MySQL, SQL Server, Excel, Access, verschiedene zufällige Listen) und laden sie in Neo4j oder einer anderen Graph-Datenbank gespeichert wurden. Specifcally, was passiert, wenn gemeinsame Daten vorhandene Daten überlappen bereits im System.

Ja, ich weiß, einige Daten am besten in RDBMS modelliert ist, aber ich habe diese Idee mir Juckreiz, dass, wenn Sie mehrere verschiedene Tabellen überlagern müssen, die Grafik-Modell ist besser als der Tabellenstruktur.

Zum Beispiel arbeite ich in einer Produktionsumgebung. Es ist ein großes Projekt arbeiten wir an und aufgrund der Komplexität hat jede Abteilung eine separate Excel-Tabelle erstellt, die eine

Hier ist ein guter Artikel, die über die Bedürfnisse sprechen, dass nicht relationale Datenbanken füllen: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

Es macht einen guten Job bei den Hinweis auf (abgesehen von dem Namen), dass relationale Datenbanken Arent fehlerhaft oder falsch, es ist nur, dass in diesen Tagen beginnen die Menschen mehr und mehr Daten in den Mainstream-Software und Websites zu verarbeiten, und dass relationale Datenbanken nur wont Maßstab für diese Bedürfnisse.

vielleicht ein bisschen spät, aber es gibt eine wachsende Zahl von Projekten Neo4j verwenden, die besser bekannten aufgelistet unter ihre Kunden

_{Hinweis: Ich bin ein Teil des Neo4j Teams}

Answer 6

Answer 7

Answer 8

Answer 9

Answer 10

Hier ist ein guter Artikel, die über die Bedürfnisse sprechen, dass nicht relationale Datenbanken füllen:

Answer 11

vielleicht ein bisschen spät, aber es gibt eine wachsende Zahl von Projekten Neo4j verwenden, die besser bekannten aufgelistet unter ihre Kunden

_{Hinweis: Ich bin ein Teil des Neo4j Teams}