OrientDB - Ottimizzazione delle prestazioni

In questo capitolo, puoi ottenere alcuni suggerimenti generali su come ottimizzare la tua applicazione che usa OrientDB. Esistono tre modi per aumentare le prestazioni per diversi tipi di database.

• Document Database Performance Tuning - Utilizza una tecnica che aiuta a evitare la creazione di documenti per ogni nuovo documento.

• Object Database Performance Tuning - Utilizza le tecniche generiche per migliorare le prestazioni.

• Distributed Configuration Tuning - Utilizza diverse metodologie per migliorare le prestazioni nella configurazione distribuita.

È possibile ottenere l'ottimizzazione delle prestazioni generiche modificando le impostazioni di Memoria, JVM e Connessione remota.

Impostazioni di memoria

Esistono diverse strategie nell'impostazione della memoria per migliorare le prestazioni.

Impostazioni server e incorporate

Queste impostazioni sono valide sia per il componente Server che per la JVM in cui l'applicazione Java viene eseguita utilizzando OrientDB in modalità Embedded, utilizzando direttamente plocal.

La cosa più importante durante la messa a punto è assicurarsi che le impostazioni della memoria siano corrette. Ciò che può fare davvero la differenza è il giusto bilanciamento tra l'heap e la memoria virtuale utilizzata da Memory Mapping, specialmente su set di dati di grandi dimensioni (GB, TB e altro) dove le strutture della cache in memoria contano meno dell'IO grezzo.

Ad esempio, se è possibile assegnare un massimo di 8 GB al processo Java, di solito è meglio assegnare un piccolo heap e un grande buffer della cache del disco (memoria fuori heap).

Prova il seguente comando per aumentare la memoria heap.

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

Il storage.diskCache.bufferSize impostazione (con il vecchio archivio "locale" era file.mmap.maxMemory) è in MB e indica la quantità di memoria da utilizzare per il componente Disk Cache. Per impostazione predefinita è 4 GB.

NOTE - Se la somma dell'heap massimo e del buffer della cache del disco è troppo alta, il sistema operativo potrebbe cambiare con un enorme rallentamento.

Impostazioni JVM

Le impostazioni JVM sono codificate in file batch server.sh (e server.bat). È possibile modificarli per regolare la JVM in base all'utilizzo e alle impostazioni hw / sw. Aggiungi la seguente riga nel file server.bat.

-server -XX:+PerfDisableSharedMem

Questa impostazione disabiliterà la scrittura delle informazioni di debug sulla JVM. Nel caso in cui sia necessario creare il profilo della JVM, è sufficiente rimuovere questa impostazione.

Connessioni remote

Esistono molti modi per migliorare le prestazioni quando si accede al database utilizzando una connessione remota.

Recupero della strategia

Quando lavori con un database remoto devi prestare attenzione alla strategia di recupero utilizzata. Per impostazione predefinita, il client OrientDB carica solo il record contenuto nel gruppo di risultati. Ad esempio, se una query restituisce 100 elementi, ma se si incrociano questi elementi dal client, il client OrientDB carica pigramente gli elementi con un'altra chiamata di rete al server per ogni record mancato.

Pool di connessioni di rete

Ogni client, per impostazione predefinita, utilizza solo una connessione di rete per parlare con il server. Più thread sullo stesso client condividono lo stesso pool di connessioni di rete.

Quando si hanno più thread, potrebbe esserci un collo di bottiglia poiché molto tempo viene speso in attesa di una connessione di rete gratuita. Questo è il motivo per cui è importante configurare il pool di connessioni di rete.

La configurazione è molto semplice, solo 2 parametri -

• minPool- È la dimensione iniziale del pool di connessioni. Il valore predefinito è configurato come parametri globali "client.channel.minPool".

• maxPool- È la dimensione massima che il pool di connessioni può raggiungere. Il valore predefinito è configurato come parametri globali "client.channel.maxPool".

Se tutte le connessioni del pool sono occupate, il thread del client attenderà la prima connessione libera.

Comando di esempio di configurazione utilizzando le proprietà del database.

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

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

Ottimizzazione della configurazione distribuita

Esistono molti modi per migliorare le prestazioni nella configurazione distribuita.

Usa transazioni

Anche quando aggiorni i grafici, dovresti sempre lavorare sulle transazioni. OrientDB ti consente di lavorare al di fuori di essi. I casi comuni sono query di sola lettura o operazioni massicce e non simultanee possono essere ripristinate in caso di errore. Quando si esegue su una configurazione distribuita, l'utilizzo delle transazioni aiuta a ridurre la latenza. Questo perché l'operazione distribuita avviene solo al momento del commit. La distribuzione di una grande operazione è molto efficiente rispetto al trasferimento di piccole operazioni multiple, a causa della latenza.

Replica vs Sharding

La configurazione distribuita di OrientDB è impostata sulla replica completa. Avere più nodi con la stessa copia del database è importante per le letture in scala. In effetti, ogni server è indipendente dall'esecuzione di letture e query. Se si dispone di 10 nodi del server, la velocità effettiva di lettura è 10x.

Con le scritture, è l'opposto: avere più nodi con replica completa rallenta le operazioni, se la replica è sincrona. In questo caso, il partizionamento orizzontale del database su più nodi consente di aumentare la scala delle scritture, poiché solo un sottoinsieme di nodi è coinvolto nella scrittura. Inoltre, potresti avere un database più grande di un nodo server HD.

Aumenta la scala sulle scritture

Se disponi di una rete lenta e hai una replica sincrona (predefinita), potresti pagare il costo della latenza. Infatti, quando OrientDB viene eseguito in modo sincrono, attende almeno il filewriteQuorum. Ciò significa che se writeQuorum è 3 e si hanno 5 nodi, il nodo del server coordinatore (dove viene avviata l'operazione distribuita) deve attendere la risposta da almeno 3 nodi per fornire la risposta al client.

Per mantenere la coerenza, writeQuorum dovrebbe essere impostato sulla maggioranza. Se hai 5 nodi la maggioranza è 3. Con 4 nodi, è ancora 3. L'impostazione di writeQuorum su 3 invece di 4 o 5 consente di ridurre il costo di latenza e mantenere comunque la coerenza.

Replica asincrona

Per velocizzare le cose, puoi configurare la replica asincrona per rimuovere il collo di bottiglia della latenza. In questo caso, il nodo del server coordinatore esegue l'operazione localmente e fornisce la risposta al client. L'intera replica sarà in background. Nel caso in cui il quorum non venga raggiunto, le modifiche verranno annullate in modo trasparente.

Aumenta le letture

Se hai già impostato writeQuorum sulla maggior parte dei nodi, puoi lasciare il readQuoruma 1 (impostazione predefinita). Questo accelera tutte le letture.