Das Jahr der Grafik: Anschaulich werden, nativ werden, die Landschaft neu gestalten

Video: Was gibt es Neues in der Welt der Graphdatenbanken? Hier ist eine kurze Zusammenfassung

Es ist offiziell: Graphdatenbanken sind eine Sache. Das ist hier der Konsens Groß auf Daten unter Mitwirkenden Andrew Brust Und Tony Bär. Wenn AWS eine Domäne betritt, signalisiert dies offiziell den Aufwärtstrend des Hype-Zyklus. Es ist ein bisschen wie neu entdecktes Land – zuerst ist es weitgehend unbekannt und von Einheimischen bewohnt, dann zeigen die Pioniere, dass es Möglichkeiten gibt, und dann werden die Schwergewichte versuchen, es zu kolonisieren.

Der kürzliche Enthüllung von AWS Neptune scheint selbst einst selbsternannte Grafikskeptiker wie Brust und Baer überzeugt zu haben. Warum jetzt, fragen Sie? Ähnlich wie zum Beispiel beim maschinellen Lernen geht es nicht so sehr darum, dass es einen großen Durchbruch in der Technologie gibt, sondern vor allem um eine Frage der Reife.

Hardware- und Softwarefähigkeiten wie günstige Speicher- und Verarbeitungskapazitäten in der Cloud und vor Ort, Verständnis für die technischen Herausforderungen für die verteilte Indizierung und Abfrage von Diagrammen und die Erkenntnis, dass genügend große und verbundene Datensätze vorhanden sind, haben alle zum perfekten Diagramm beigetragen Sturm.

Grafisch werden

Wie immer, wenn eine bisherige Nischentechnologie zum Mainstream wird, besteht die Gefahr, dass sie missverstanden oder überbewertet wird bis zu dem Punkt, an dem es zu einem bedeutungslosen Schlagwort wird, zu einem Hammer, der auf jedes Problem angewendet wird, unabhängig davon, ob es sich um ein Problem handelt Nagel. Also, faire Warnung: Wenn sich etwas nicht wie ein Diagramm anfühlt, versuchen Sie nicht, es zu erzwingen.

Ihre Videos machen sich wahrscheinlich ganz gut in dem Objektladen, in dem Sie sie derzeit haben. Ein Verkaufsbuchsystem, das auf einer relationalen Datenbank basiert, funktioniert dort wahrscheinlich ganz gut, und ebenso ist ein Dokumentenspeicher möglicherweise genau der richtige Ort, um Ihre Dokumente zu speichern. „Verwenden Sie das richtige Werkzeug für den Job“ bleibt also hier ein ebenso gültiger Satz wie anderswo.

Ein Grund für die Attraktivität von Graphen liegt jedoch zum Teil darin, dass es in vielen Fällen eine natürliche Möglichkeit ist, die Welt zu modellieren. Natürlicher als das gute alte relationale Modell? Für bestimmte Domänen und Anwendungsfälle, wenn die von Ihnen gespeicherten Daten ihrer Natur nach untrennbar miteinander verbunden sind, ja. Zum einen fühlt es sich bei Anwendungsfällen mit vielen Hops auf jeden Fall einfacher an und bietet eine bessere Leistung, eine Diagrammdatenbank abzufragen als eine relationale Datenbank.

Das Durchlaufen einer Reihe von Verknüpfungen in der relationalen Algebra, um beispielsweise Freunde von Freunden von Freunden zu finden, ist umständlich zu schreiben und zu pflegen und beeinträchtigt die Leistung. Ein Diagrammmodell und eine Abfragesprache können natürlicher und effizienter sein – aber das Schlüsselwort darin ist „kann“. Nicht alles, was wie ein Diagramm aussieht, ist tatsächlich ein Diagramm, und nicht alle Diagramme verfügen über die gleichen Abfragefunktionen.

Um Tony Baer zu zitieren: „Ich hatte immer das Gefühl, dass Graph besser geeignet sei, unter der Haube eingebettet zu werden, weil es sich um eine seltsame neue Datenbank ohne Standards de facto oder anders handelte.“ Aber ich fange an, meine Einstellung zu ändern – jeder große Datenplattformanbieter verfügt jetzt entweder über eine Diagrammdatenbank oder eine API/Engine.“ Dies verdeutlicht zwei wichtige Punkte: den Unterschied zwischen einem nativen Diagramm und einer Diagramm-API und das Fehlen von Standards.

Geht heimisch

Verschiedene Leute verwenden unterschiedliche Definitionen von Engines und APIs, aber letztendlich geht es nur um Datenstrukturen. Wenn Ihre Datenbank auf Datenstrukturen basiert, die nicht für ein Diagramm geeignet sind, und nicht über die richtige Indizierung verfügt, Dann lassen sich Ihre Abfragen zwar mit einer darüber liegenden Graph-API einfacher schreiben, ihre Leistung kann jedoch nur so gut sein wie Ihre Datenbank.

Um ein Beispiel aus der Microsoft-Welt zu nennen und Andrew Brust zu zitieren: „Die Grafikverarbeitungsfunktionen in SQL Server 2017 sind eindeutig eine Abstraktionsschicht und nicht nativ.“ Obwohl Knoten- und Kantentabellentypen eine echte Sache sind. Aber was ist mit Cosmos DB? „Graph“ ist nur eine Betriebsart, aber ich würde es trotzdem als nativ betrachten.“

Dieses Kriterium ist wichtig, aber nicht das einzige, und es ist nicht möglich, im Kontext eines Artikels einen Sinn für einen entstehenden Markt zu finden, der alles berücksichtigt. Sie können von uns in naher Zukunft mit umfangreicheren Arbeiten hierzu rechnen, aber wenn Sie noch möchten 10-Minuten-Version der Graph Database Landscape, Sie können die von Yu Xu, dem CEO von TigerGraph, verfasste Version sehen, zusätzlich zu unserem vergangene Berichterstattung.

TigerGraph gehört zu den Diagrammdatenbanken, die wir 2017 behandelt haben AllegroGraph, GraphDB Und Neo4j. GraphDB und Neo4j gehören ebenfalls dazu Graphdatenbanken, die offiziell auf AWS angeboten werden – Dies bedeutet jedoch nicht, dass andere Graphdatenbanken nicht auf AWS bereitgestellt werden können.

Das ist das übliche Kooperationsszenario, mit dem Cloud-Anbieter und -Anbieter zu leben gelernt haben, auch wenn es in diesem Fall komplizierter sein kann als üblich.

Die anderen beiden Diagrammdatenbanken, die von AWS offiziell unterstützt werden, sind JanusGraph und OrientDB. JanusGraph hieß früher Titan und nach der Muttergesellschaft von Titan benannt Aurelius wurde von DataStax übernommen Titan war wurde als JanusGraph gespalten und wird jetzt von IBM unterstützt, ebenfalls ein Cloud-Anbieter. Auch OrientDB wurde kürzlich vom Unternehmenssoftwareanbieter CallidusCloud übernommen.

Auspacken von AWS Neptune

Was AWS Neptune (immer noch in der privaten Betaphase) betrifft, können wir zwar nicht damit rechnen, dass es in Bezug auf die internen Abläufe sehr viele Offenlegungen geben wird, dennoch können wir ein paar Dinge feststellen.

Wie Tony Baer kürzlich schrieb: Cloud-Speicher wird de facto zum Speichersee. Auf AWS verwenden die Leute S3 und verfügen inzwischen sogar über SQL-Abfragefunktionen dafür. Hätte AWS Neptune direkt auf S3 aufbauen können, und wäre das sinnvoll?

Wir wissen es nicht wirklich, aber wahrscheinlich nicht. AWS spricht von der Möglichkeit eines kontinuierlichen Backups von Neptune auf S3, was durchaus aussagekräftig ist. Wenn S3 der für Neptune verwendete Speicher wäre, wären S3-Backups sinnlos, da sich die Daten bereits auf S3 befänden und lediglich die Replikation aktiviert werden müsste. Aber da gibt es noch einen weiteren Hinweis.

AWS verkauft die Option, JanusGraph mit Amazon DynamoDB als Speicher-Backend zu verwenden. DynamoDB ist eine Schlüsselwertdatenbank, und eine Schlüsselwertmetapher und -struktur eignet sich gut für die grafische Darstellung. Das ist es tatsächlich, was Titan und jetzt auch JanusGraph als Back-End-Speicher für ihre Diagramme verwenden, daher ist es sinnvoll, dass AWS Neptune auf DynamoDB aufgebaut hat.

Um auf den Big on Data-Contributor-Diagramm-Showdown zurückzukommen und Andrew Brust zu zitieren: „In der Datenbankwelt kommt es auf Schlüssel-Wert-Paare an.“ Wenn Sie also über eine Datenbank mit diesem Kernkonstrukt verfügen, haben Sie das Potenzial, fast alles zu tun, was Sie wollen. Obwohl Sie nach dem Auspacken möglicherweise nicht viel tun können.

Könnte es also sein, dass AWS Neptune tatsächlich eine ausgefeilte Schicht über DynamoDB ist, die einem zugrunde liegenden Schlüsselwertspeicher eine Diagrammmetapher und eine API hinzufügt? Das klingt vielleicht zu stark vereinfacht, erscheint aber plausibel.

Man könnte argumentieren, dass Titan und seine Nachkommen, JanusGraph und DSE Graph, von Natur aus ähnlich sind, und AWS bringt Recht hervorzuheben, wie die steckbare Architektur von Titan es einfach macht, mit der Nutzung von DynamoDB zu beginnen, ohne die Anwendungen wechseln zu müssen. Aber wie effizient ist das?

Zum jetzigen Zeitpunkt liegen uns keine wirklichen Indikatoren für die Leistung von AWS Neptune vor, auch wenn AWS erwartungsgemäß ins Schwärmen gerät Andere Anbieter weisen schnell auf alle Vor- und Nachteile der Funktionsfähigkeit verteilter Diagramme hin, die AWS möglicherweise falsch machen könnte.

Fakt ist jedoch, dass es bei AWS nicht wirklich darum geht, etwas falsch zu machen, und seine schiere Schwere macht es zu einer Macht, mit der man rechnen muss. Das sagt der CEO von Neo4j, der derzeit führenden Graphdatenbank in der Markteinführung. Auch andere Grafikanbieter sind sich der Tatsache bewusst, dass ihr Markt deutlich wachsen dürfte. und sich darauf vorzubereiten, angesichts der zunehmenden Konkurrenz zu kämpfen.

Standards, zu viele oder keine

Was wir jedoch über AWS Neptune wissen, was uns zum zweiten wichtigen Punkt bringt – Standards – ist Folgendes: Neptune unterstützt den beliebten Graphen Die Abfragesprachen Apache TinkerPop Gremlin und SPARQL des W3C ermöglichen es Benutzern, auf einfache Weise Abfragen zu erstellen, mit denen sie effizient in stark vernetzten Bereichen navigieren können Datensätze.

In einer Welt, in der es scheinbar nicht das Äquivalent zu dem gibt, was SQL in der relationalen Welt ist – ein De-facto-Standard für Abfragen – ist dies ziemlich wichtig. Dies bedeutet, dass Neptune seinen Benutzern maximale Flexibilität bietet, und es ist ein kluger und pragmatischer Schritt von AWS.

In der Grafik gibt es konkurrierende Modelle und Abfragesprachen, und die Möglichkeit, Neptune mit zwei der beliebtesten abzufragen, erweitert die potenzielle Benutzerbasis und Anwendungsfälle von Neptune. Damit ist AWS nicht allein, aber es könnte einen Unterschied machen, wenn man dies deutlich anspricht und es benutzerfreundlicher macht.

Wir haben schon behandelte SPARQL und einige der Dinge, für die es verwendet werden kann. Im nächsten Teil dieser Miniserie zum Thema Grafik werden wir uns darauf konzentrieren Apache TinkerPop, seine Abfragesprache namens Gremlin, seine Funktionen und die Rolle, die es in der Welt der Graphdatenbanken und darüber hinaus spielen kann.

Bisherige und verwandte Berichterstattung

Hadoop 3 stellt sich den Realitäten des Speicherwachstums

Während Hadoop auf Basis einer Standard-Infrastruktur entwickelt wurde, sieht sich Hadoop 3.x mit der Realität konfrontiert, dass zu viel billiger Speicher teuer werden kann.

Big Data 2018: Cloud-Speicher wird de facto zum Datensee

Während KI, IoT und DSGVO für Schlagzeilen sorgen, sollten Sie nicht vergessen, welche generationsübergreifenden Auswirkungen Cloud-Migration und -Streaming auf Big-Data-Implementierungen haben werden.