Frage

Meine Grundanforderungen aus einer GraphDB:

  • Reif (produktionsbereit)
  • Native .NET- oder C ++ - Sprachbindung
  • Horizontale Skalierbarkeit: beides
    • Automatisierte Datenredundanz und Sharding
    • Verteilte Diagrammalgorithmen / Abfrageausführung

      Derzeit habe ich Folgendes disqualifiziert:

      • InfiniteGraph: Keine C ++ / .NET-Sprachbindung
      • HyperGraphDB: Keine C ++ / .NET-Sprachbindung
      • Microsoft Trinity: Nicht ausgereift
      • Neo4j: nicht verteilt

        Ich bin mir nicht sicher, ob Folgendes skalierbar ist:

        • Sparsity DEX
        • Franz Inc. AllegroGraph
        • Sones GraphDB

          Ich fand die verfügbaren Informationen zu horizontalen Skalierbarkeitsfunktionen ziemlich allgemein.Ich denke, dafür gibt es gute Gründe.

          Alle Informationen sind willkommen.

War es hilfreich?

Lösung

Leider erweitern Ihre Grundvoraussetzungen bereits das heutige allgemeine Verständnis von Grafiken - auch im akademischen Bereich. Keine aufgelistete reine Grafikdatenbank kann alle Ihre Anforderungen erfüllen. Algorithmen für verteilte Graphen, die große verteilte, aber miteinander verbundene Graphen kennen, sind immer noch ein großes Forschungsproblem. Für Ihre Anwendung ist es daher möglicherweise am besten, eine gut passende Grafikdatenbank, einen Grafikverarbeitungsstapel oder einen RDF-Store zu finden und die fehlenden Teile selbst zu implementieren. Wenn Ihre Anwendung hauptsächlich OLTP (Online Transactional Graph Processing) (schwer lesbar / schreibgeschützt) mit Schwerpunkt auf den Scheitelpunkten ist und Sie für einen Moment auf die verteilten Algorithmen verzichten können, verwenden Sie eine der folgenden Methoden:

  • Neo4j
  • OrientDB
  • DEX
  • HyperGraphDB
  • InfiniteGraph
  • InfoGrid
  • Microsoft Horton

    Wenn es mehr um Online Analytical Processing (OLAP) (meistens gelesen) geht, bei dem es immer noch auf die Eckpunkte und die Verteilung ankommt, dann ist es wirklich wichtig:

    • Apache Hama (Frühphasenprojekt)
    • Microsoft Trinity (Forschungsprojekt)
    • Golden Orb (gut, aber nur Java)
    • Signalisieren / Sammeln (http://www.ifi.uzh.ch/ddis/research/sc, aber ein Forschungsprojekt)

      Oder liegt der Fokus mehr auf den Kanten, dem logischen Denken / Mustervergleich und Sie müssen oder sollten besser mit einer Verteilung auf Kantenebene wie im Semantic Web leben, als einen dieser RDF- / Triple- / Quadstores zu verwenden:

      • AllegroGraph (okay, es handelt sich um einen Graphdb / Rdf-Store-Hybrid;)
      • Jena
      • Sesam
      • Stardog
      • Virtuose
      • ... und viele weitere RDF-Stores

        Gute Ausgangspunkte könnten DEX oder Neo4j sein: Wenn Sie nach einem guten und wirklich schnellen Graphdb-Kernel für C ++ suchen, ist DEX vielleicht am besten, aber Sie müssten eine Menge Netzwerk- und Distributionsmaterial selbst implementieren. Neo4j hat viel Verteilung und Fehlertoleranz, aber im Moment eher auf Vertex-Sharding-Ebene und sein Kernel ist Java. Ideen und Anregungen zur Implementierung verteilter Graph-Algorithmen finden Sie unter Golden Orb und Signal / Collect. Ein alternativer Ansatz könnte mit AllegroGraph oder Stardog beginnen. Besonders AllegroGraph kann am Anfang etwas knifflig sein, bis Sie sich an ihre Denkweise gewöhnt haben. Stardog ist noch jung und Java, aber schnell und schon ziemlich ausgereift.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top