OrientDB - Réglage des performances

Dans ce chapitre, vous pouvez obtenir des conseils généraux sur la façon d'optimiser votre application qui utilise OrientDB. Il existe trois façons d'augmenter les performances pour différents types de base de données.

  • Document Database Performance Tuning - Il utilise une technique qui permet d'éviter la création de documents pour chaque nouveau document.

  • Object Database Performance Tuning - Il utilise les techniques génériques pour améliorer les performances.

  • Distributed Configuration Tuning - Il utilise différentes méthodologies pour améliorer les performances en configuration distribuée.

Vous pouvez obtenir un réglage générique des performances en modifiant les paramètres de connexion Mémoire, JVM et à distance.

Paramètres de mémoire

Il existe différentes stratégies de réglage de la mémoire pour améliorer les performances.

Serveur et paramètres intégrés

Ces paramètres sont valides pour le composant Serveur et la JVM où l'application Java est exécutée à l'aide d'OrientDB en mode Embedded, en utilisant plocal.

La chose la plus importante lors du réglage est de s'assurer que les paramètres de la mémoire sont corrects. Ce qui peut faire une réelle différence, c'est le bon équilibre entre le tas et la mémoire virtuelle utilisée par Memory Mapping, en particulier sur les grands ensembles de données (Go, To et plus) où les structures de cache en mémoire comptent moins que les E / S brutes.

Par exemple, si vous pouvez attribuer un maximum de 8 Go au processus Java, il est généralement préférable d'attribuer un petit tas et un grand tampon de cache disque (mémoire hors tas).

Essayez la commande suivante pour augmenter la mémoire du tas.

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

le storage.diskCache.bufferSize paramètre (avec l'ancien stockage "local", c'était file.mmap.maxMemory) est en Mo et indique la quantité de mémoire à utiliser pour le composant Cache de disque. Par défaut, il est de 4 Go.

NOTE - Si la somme du tas maximal et du tampon de cache disque est trop élevée, cela pourrait entraîner un échange du système d'exploitation avec un ralentissement énorme.

Paramètres JVM

Les paramètres JVM sont codés dans les fichiers de commandes server.sh (et server.bat). Vous pouvez les modifier pour régler la JVM en fonction de votre utilisation et des paramètres hw / sw. Ajoutez la ligne suivante dans le fichier server.bat.

-server -XX:+PerfDisableSharedMem

Ce paramètre désactivera l'écriture des informations de débogage sur la JVM. Au cas où vous auriez besoin de profiler la JVM, supprimez simplement ce paramètre.

Connexions à distance

Il existe de nombreuses façons d'améliorer les performances lorsque vous accédez à la base de données à l'aide d'une connexion à distance.

Stratégie de récupération

Lorsque vous travaillez avec une base de données distante, vous devez faire attention à la stratégie de récupération utilisée. Par défaut, le client OrientDB charge uniquement l'enregistrement contenu dans le jeu de résultats. Par exemple, si une requête renvoie 100 éléments, mais si vous croisez ces éléments à partir du client, le client OrientDB charge paresseusement les éléments avec un autre appel réseau au serveur pour chaque enregistrement manqué.

Pool de connexions réseau

Chaque client, par défaut, utilise une seule connexion réseau pour parler avec le serveur. Plusieurs threads sur le même client partagent le même pool de connexions réseau.

Lorsque vous avez plusieurs threads, il peut y avoir un goulot d'étranglement car beaucoup de temps est passé à attendre une connexion réseau gratuite. C'est la raison pour laquelle il est important de configurer le pool de connexions réseau.

La configuration est très simple, juste 2 paramètres -

  • minPool- Il s'agit de la taille initiale du pool de connexions. La valeur par défaut est configurée en tant que paramètres globaux "client.channel.minPool".

  • maxPool- Il s'agit de la taille maximale que le pool de connexions peut atteindre. La valeur par défaut est configurée en tant que paramètres globaux "client.channel.maxPool".

Si toutes les connexions du pool sont occupées, le thread client attendra la première connexion libre.

Exemple de commande de configuration à l'aide des propriétés de la base de données.

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

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

Réglage de la configuration distribuée

Il existe de nombreuses façons d'améliorer les performances de la configuration distribuée.

Utiliser les transactions

Même lorsque vous mettez à jour des graphiques, vous devez toujours travailler dans les transactions. OrientDB vous permet de travailler en dehors d'eux. Les cas courants sont les requêtes en lecture seule ou les opérations massives et non simultanées peuvent être restaurées en cas d'échec. Lorsque vous exécutez sur une configuration distribuée, l'utilisation de transactions permet de réduire la latence. En effet, l'opération distribuée se produit uniquement au moment de la validation. La distribution d'une seule grande opération est beaucoup plus efficace que le transfert de petites opérations multiples, en raison de la latence.

Réplication vs sharding

La configuration distribuée OrientDB est définie sur la réplication complète. Il est important d'avoir plusieurs nœuds avec la même copie de la base de données pour les lectures à l'échelle. En fait, chaque serveur est indépendant de l'exécution des lectures et des requêtes. Si vous avez 10 nœuds de serveur, le débit de lecture est de 10x.

Avec les écritures, c'est le contraire: avoir plusieurs nœuds avec une réplication complète ralentit les opérations, si la réplication est synchrone. Dans ce cas, le partage de la base de données sur plusieurs nœuds vous permet d'augmenter les écritures, car seul un sous-ensemble de nœuds est impliqué lors de l'écriture. De plus, vous pourriez avoir une base de données plus grande qu'un nœud de serveur HD.

Augmentez vos écritures

Si vous avez un réseau lent et que vous avez une réplication synchrone (par défaut), vous pourriez payer le coût de la latence. En fait, lorsque OrientDB s'exécute de manière synchrone, il attend au moins lewriteQuorum. Cela signifie que si le writeQuorum est 3 et que vous avez 5 nœuds, le nœud du serveur coordinateur (où l'opération distribuée est lancée) doit attendre la réponse d'au moins 3 nœuds pour fournir la réponse au client.

Afin de maintenir la cohérence, writeQuorum doit être défini sur la majorité. Si vous avez 5 nœuds, la majorité est de 3. Avec 4 nœuds, c'est toujours 3. Mettre le writeQuorum à 3 au lieu de 4 ou 5 permet de réduire le coût de latence tout en maintenant la cohérence.

Réplication asynchrone

Pour accélérer les choses, vous pouvez configurer la réplication asynchrone pour supprimer le goulot d'étranglement de latence. Dans ce cas, le nœud serveur coordinateur exécute l'opération localement et donne la réponse au client. La réplication entière sera en arrière-plan. Si le quorum n'est pas atteint, les modifications seront annulées de manière transparente.

Augmentez vos lectures

Si vous définissez déjà writeQuorum sur la majorité des nœuds, vous pouvez laisser le readQuorumà 1 (valeur par défaut). Cela accélère toutes les lectures.