OrientDB - Leistungsoptimierung

In diesem Kapitel erhalten Sie einige allgemeine Tipps zur Optimierung Ihrer Anwendung, die OrientDB verwendet. Es gibt drei Möglichkeiten, die Leistung für verschiedene Datenbanktypen zu steigern.

Document Database Performance Tuning - Es wird eine Technik verwendet, mit der die Erstellung von Dokumenten für jedes neue Dokument vermieden wird.
Object Database Performance Tuning - Es verwendet die generischen Techniken, um die Leistung zu verbessern.
Distributed Configuration Tuning - Es werden verschiedene Methoden verwendet, um die Leistung in der verteilten Konfiguration zu verbessern.

Sie können eine allgemeine Leistungsoptimierung erzielen, indem Sie die Einstellungen für Speicher, JVM und Remoteverbindung ändern.

Speichereinstellungen

Es gibt verschiedene Strategien bei der Speichereinstellung, um die Leistung zu verbessern.

Server- und eingebettete Einstellungen

Diese Einstellungen gelten sowohl für die Serverkomponente als auch für die JVM, in der die Java-Anwendung mit OrientDB im eingebetteten Modus direkt ausgeführt wird plocal.

Das Wichtigste beim Einstellen ist, sicherzustellen, dass die Speichereinstellungen korrekt sind. Was einen echten Unterschied machen kann, ist das richtige Gleichgewicht zwischen dem Heap und dem virtuellen Speicher, der von der Speicherzuordnung verwendet wird, insbesondere bei großen Datenmengen (GBs, TBs und mehr), bei denen die Speicher-Cache-Strukturen weniger zählen als rohe E / A.

Wenn Sie dem Java-Prozess beispielsweise maximal 8 GB zuweisen können, ist es normalerweise besser, einen kleinen Heap und einen großen Festplatten-Cache-Puffer (Off-Heap-Speicher) zuzuweisen.

Versuchen Sie den folgenden Befehl, um den Heapspeicher zu erhöhen.

java -Xmx800m -Dstorage.diskCache.bufferSize=7200 ...

Das storage.diskCache.bufferSize Einstellung (mit altem "lokalem" Speicher war es file.mmap.maxMemory) ist in MB angegeben und gibt an, wie viel Speicher für die Festplatten-Cache-Komponente verwendet werden soll. Standardmäßig sind es 4 GB.

NOTE - Wenn die Summe aus maximalem Heap- und Festplatten-Cache-Puffer zu hoch ist, kann dies dazu führen, dass das Betriebssystem mit einer enormen Verlangsamung ausgetauscht wird.

JVM-Einstellungen

JVM-Einstellungen werden in Batchdateien von server.sh (und server.bat) codiert. Sie können sie ändern, um die JVM entsprechend Ihrer Nutzung und den Einstellungen für hw / sw anzupassen. Fügen Sie die folgende Zeile in die Datei server.bat ein.

-server -XX:+PerfDisableSharedMem

Diese Einstellung deaktiviert das Schreiben von Debug-Informationen zur JVM. Wenn Sie die JVM profilieren müssen, entfernen Sie einfach diese Einstellung.

Remote-Verbindungen

Es gibt viele Möglichkeiten, die Leistung zu verbessern, wenn Sie über eine Remoteverbindung auf die Datenbank zugreifen.

Strategie holen

Wenn Sie mit einer entfernten Datenbank arbeiten, müssen Sie auf die verwendete Abrufstrategie achten. Standardmäßig lädt der OrientDB-Client nur den in der Ergebnismenge enthaltenen Datensatz. Wenn eine Abfrage beispielsweise 100 Elemente zurückgibt, Sie diese Elemente jedoch vom Client aus kreuzen, lädt der OrientDB-Client die Elemente für jeden fehlenden Datensatz träge mit einem weiteren Netzwerkaufruf an den Server.

Netzwerkverbindungspool

Jeder Client verwendet standardmäßig nur eine Netzwerkverbindung, um mit dem Server zu kommunizieren. Mehrere Threads auf demselben Client teilen sich denselben Netzwerkverbindungspool.

Wenn Sie mehrere Threads haben, kann es zu einem Engpass kommen, da viel Zeit für das Warten auf eine kostenlose Netzwerkverbindung aufgewendet wird. Aus diesem Grund ist es wichtig, den Netzwerkverbindungspool zu konfigurieren.

Die Konfiguration ist sehr einfach, nur 2 Parameter -

minPool- Dies ist die anfängliche Größe des Verbindungspools. Der Standardwert ist als globaler Parameter "client.channel.minPool" konfiguriert.
maxPool- Dies ist die maximale Größe, die der Verbindungspool erreichen kann. Der Standardwert ist als globaler Parameter "client.channel.maxPool" konfiguriert.

Wenn alle Poolverbindungen belegt sind, wartet der Client-Thread auf die erste freie Verbindung.

Beispielbefehl für die Konfiguration mithilfe von Datenbankeigenschaften.

database = new ODatabaseDocumentTx("remote:localhost/demo"); 
database.setProperty("minPool", 2); 
database.setProperty("maxPool", 5);  

database.open("admin", "admin");

Verteilte Konfigurationsoptimierung

Es gibt viele Möglichkeiten, die Leistung bei verteilten Konfigurationen zu verbessern.

Verwenden Sie Transaktionen

Auch wenn Sie Diagramme aktualisieren, sollten Sie immer in Transaktionen arbeiten. Mit OrientDB können Sie außerhalb von ihnen arbeiten. Häufige Fälle sind schreibgeschützte Abfragen oder massive und nicht gleichzeitige Vorgänge können im Fehlerfall wiederhergestellt werden. Wenn Sie eine verteilte Konfiguration verwenden, können Sie durch die Verwendung von Transaktionen die Latenz verringern. Dies liegt daran, dass die verteilte Operation nur zum Festschreibungszeitpunkt ausgeführt wird. Das Verteilen einer großen Operation ist aufgrund der Latenz viel effizienter als das Übertragen kleiner mehrerer Operationen.

Replikation gegen Sharding

Die verteilte OrientDB-Konfiguration ist auf vollständige Replikation eingestellt. Für Skalierungslesevorgänge ist es wichtig, mehrere Knoten mit derselben Datenbankkopie zu haben. Tatsächlich ist jeder Server unabhängig von der Ausführung von Lese- und Abfragen. Wenn Sie 10 Serverknoten haben, beträgt der Lesedurchsatz das 10-fache.

Beim Schreiben ist das Gegenteil der Fall: Wenn mehrere Knoten mit vollständiger Replikation vorhanden sind, werden die Vorgänge verlangsamt, wenn die Replikation synchron ist. In diesem Fall können Sie durch Sharding der Datenbank über mehrere Knoten hinweg Schreibvorgänge skalieren, da nur eine Teilmenge der Knoten am Schreibvorgang beteiligt ist. Darüber hinaus könnte eine Datenbank größer als ein Serverknoten HD sein.

Skalieren Sie auf Writes

Wenn Sie ein langsames Netzwerk und eine synchrone (Standard-) Replikation haben, können Sie die Kosten für die Latenz bezahlen. In der Tat, wenn OrientDB synchron läuft, wartet es zumindest auf diewriteQuorum. Dies bedeutet, dass, wenn das writeQuorum 3 ist und Sie 5 Knoten haben, der Koordinatorserverknoten (wo der verteilte Vorgang gestartet wird) auf die Antwort von mindestens 3 Knoten warten muss, um dem Client die Antwort zu geben.

Um die Konsistenz aufrechtzuerhalten, sollte das writeQuorum auf die Mehrheit gesetzt werden. Wenn Sie 5 Knoten haben, ist die Mehrheit 3. Bei 4 Knoten ist es immer noch 3. Wenn Sie das writeQuorum auf 3 anstelle von 4 oder 5 setzen, können Sie die Latenzkosten reduzieren und die Konsistenz beibehalten.

Asynchrone Replikation

Um die Arbeit zu beschleunigen, können Sie die asynchrone Replikation einrichten, um den Latenzengpass zu beseitigen. In diesem Fall führt der Koordinatorserverknoten die Operation lokal aus und gibt dem Client die Antwort. Die gesamte Replikation befindet sich im Hintergrund. Wird das Quorum nicht erreicht, werden die Änderungen transparent zurückgesetzt.

Skalieren Sie die Lesevorgänge

Wenn Sie das writeQuorum bereits auf die meisten Knoten festgelegt haben, können Sie das verlassen readQuorumauf 1 (Standardeinstellung). Dies beschleunigt alle Lesevorgänge.