Der Entwickler arbeitet direkt auf dem Graphenmodell mit einem Java-API, das die flexible Struktur exponiert, oder kann die Anbindungen an andere Programmiersprachen anwenden, so wie Java, Scala, JRuby, Python, Clojure und unterschiedliche REST-Wrapper. Typische Charakteristiken für Neo4j sind Folgende:

• optionale oder keine Schemas für leichte Datenveränderungen
• vollständige und leichte Modellierung von normalerweise komplexen Datenbeständen und -strukturen, z. B. Zugriffsrechte in einem CMS als Access Control Lists, Objektdatenbankstrukturen, TripleStores und andere
• typische Anwendungen in Bereichen wie Semantic Web und RDF, LinkedData, GIS, Genomanalysen, Modellierung von sozialen Netwerken, tiefen Empfehlungsalgorithmen u. v. a.

Aber auch bei den "klassischen" RDBMS-Anwendungen findet man häufig Graphen in Verzeichnisstrukturen mit freier Tiefe, Produktkonfigurationen, Sortimenten, Medienmetadaten. Semantic Trading, Fraud Detection in der finanziellen Industrie und anderen wieder.

Neo4j hat eine Menge von optionalen Komponenten, um z. B. über ein Metamodell mehr Struktur in den Graphen zu bringen, einen SAIL-kompatiblen RDF TripleStore zu implementieren oder gebräuchliche Algorithmen zu unterstützen.

In Fällen, in denen man Neo4j als einen separaten Server betreiben möchte, stehen sowohl JRuby- als auch Java-basierte REST-komponenten zur Verfügung. Das bietet sich bei z. B. Architekturen wie dem bisherigen LAMP-Modell an und eignet sich außerdem gut für HTTP-Memcached und Apache-basierte Caching-Komponenten.

High Performance?

Bei Benchmarks ist es sehr schwer, allgemeingültige Performanceaussagen zu treffen, da gerade bei der Hardware sehr viel von der jeweiligen Konfiguration, Lese- und Schreibgeschwindigkeit usw. abhängt. Neo4j hantiert ohne Probleme Graphen von mehreren Milliarden Knoten, Kanten und Eigenschaften. Es ist normal, mit Neo4j Leseleistungen von über 2000 Kantenschritten pro Millisekunde (also ca. 2 Millionen Schritte pro Sekunde) mit warmen Caches zu erreichen. Bei den untenstehenden Beispielen ist Neo4j bei einem Netzwerk von 1000 Personen und dem Freunde-meiner-Freunde-Problem schon 1000 Mal schneller als MySQL, der Unterschied steigt exponentiell mit der Größe des Graphen.

Der Vorteil ist hier, dass die Traversierung entlang der Kanten in Neo4j mit konstanter Geschwindigkeit unabhängig von der Größe des Graphen erfolgt. Es werden also keine Einbußen wegen größerer Setoperationen wie in den RDBMS-Joins gemacht. Neo4j lädt lazy, sodass Knoten und Relationen erst eingelesen werden, wenn man sie wirklich im ResultSet abfragt, was die Performance bei großen und tiefen (z. B. 1000 Kanten tief) Traversierungen optimiert.

Schreibgeschwindigkeiten hängen vor allem vom Seek-Speed des Dateisystems ab. SSD-Disks und ext3 sind eine gute Kombination und geben mit vollem ACID unter Leselast von 100 000 Operationen pro Sekunde.

Skalierbarkeit: Ein Beispiel – die Matrix

Der Graph

Wie schon vorher gesagt, stellen soziale Netzwerke nur einen Bruchteil der Anwendungsfälle von Graphen dar, sind aber sehr leicht verständlich. Um die Grundfunktionalität zu demonstrieren, wird nachstehend ein kleiner Graph aus dem Film Matrix erstellt, visualisiert mit dem Eclipse-RCP-basierten Neoclipse für Neo4j:

Der Graph ist mit dem Referenzknoten (meist der Knoten mit der ID 0) verbunden, um ohne Probleme von einem bekannten Startpunkt wieder in das Netzwerk zu finden. Das ist nicht notwendig, erweist sich aber in der Praxis als anwendbar.