OrientDB - Ajuste del rendimiento

En este capítulo, puede obtener algunos consejos generales sobre cómo optimizar su aplicación que usa OrientDB. Hay tres formas de aumentar el rendimiento para diferentes tipos de bases de datos.

• Document Database Performance Tuning - Utiliza una técnica que ayuda a evitar la creación de documentos para cada nuevo documento.

• Object Database Performance Tuning - Utiliza las técnicas genéricas para mejorar el rendimiento.

• Distributed Configuration Tuning - Utiliza diferentes metodologías para mejorar el rendimiento en configuración distribuida.

Puede lograr un ajuste de rendimiento genérico cambiando la configuración de memoria, JVM y conexión remota.

Configuraciones de memoria

Existen diferentes estrategias en la configuración de la memoria para mejorar el rendimiento.

Configuración integrada y del servidor

Esta configuración es válida tanto para el componente de servidor como para la JVM donde se ejecuta la aplicación Java usando OrientDB en modo Embedded, directamente usando plocal.

Lo más importante al ajustar es asegurarse de que la configuración de la memoria sea correcta. Lo que puede marcar una diferencia real es el equilibrio correcto entre el montón y la memoria virtual que utiliza Memory Mapping, especialmente en conjuntos de datos grandes (GB, TB y más) donde las estructuras de caché de inmemory cuentan menos que las E / S sin procesar.

Por ejemplo, si puede asignar un máximo de 8 GB al proceso de Java, generalmente es mejor asignar un búfer de caché de disco pequeño y grande (memoria fuera del montón).

Pruebe el siguiente comando para aumentar la memoria del montón.

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

los storage.diskCache.bufferSize configuración (con el antiguo almacenamiento "local" era file.mmap.maxMemory) está en MB e indica cuánta memoria se debe utilizar para el componente Disk Cache. Por defecto es 4GB.

NOTE - Si la suma del búfer de caché de disco y el montón máximo es demasiado alta, podría hacer que el sistema operativo se intercambie con una gran ralentización.

Configuración de JVM

La configuración de JVM está codificada en archivos por lotes server.sh (y server.bat). Puede cambiarlos para ajustar la JVM de acuerdo con su uso y la configuración de hw / sw. Agregue la siguiente línea en el archivo server.bat.

-server -XX:+PerfDisableSharedMem

Esta configuración inhabilitará la escritura de información de depuración sobre la JVM. En caso de que necesite perfilar la JVM, simplemente elimine esta configuración.

Conexiones remotas

Hay muchas formas de mejorar el rendimiento cuando accede a la base de datos mediante una conexión remota.

Estrategia de búsqueda

Cuando trabaja con una base de datos remota, debe prestar atención a la estrategia de búsqueda utilizada. De forma predeterminada, el cliente OrientDB carga solo el registro contenido en el conjunto de resultados. Por ejemplo, si una consulta devuelve 100 elementos, pero si cruza estos elementos desde el cliente, el cliente OrientDB carga los elementos con pereza con una llamada de red más al servidor por cada registro perdido.

Grupo de conexiones de red

Cada cliente, por defecto, usa solo una conexión de red para hablar con el servidor. Varios subprocesos en el mismo cliente comparten el mismo grupo de conexiones de red.

Cuando tiene varios subprocesos, podría haber un cuello de botella ya que se pasa mucho tiempo esperando una conexión de red gratuita. Esta es la razón por la que es importante configurar el grupo de conexiones de red.

La configuración es muy simple, solo 2 parámetros -

• minPool- Es el tamaño inicial del grupo de conexiones. El valor predeterminado se configura como parámetros globales "client.channel.minPool".

• maxPool- Es el tamaño máximo que puede alcanzar el grupo de conexiones. El valor predeterminado se configura como parámetros globales "client.channel.maxPool".

Si todas las conexiones del grupo están ocupadas, el hilo del cliente esperará la primera conexión libre.

Ejemplo de comando de configuración usando propiedades de la base de datos.

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

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

Ajuste de configuración distribuida

Hay muchas formas de mejorar el rendimiento en la configuración distribuida.

Usar transacciones

Incluso cuando actualice gráficos, siempre debe trabajar en transacciones. OrientDB le permite trabajar fuera de ellos. Los casos comunes son consultas de solo lectura o operaciones masivas y no concurrentes que se pueden restaurar en caso de falla. Cuando se ejecuta en una configuración distribuida, el uso de transacciones ayuda a reducir la latencia. Esto se debe a que la operación distribuida ocurre solo en el momento de la confirmación. Distribuir una gran operación es mucho más eficiente que transferir pequeñas operaciones múltiples, debido a la latencia.

Replicación vs fragmentación

La configuración distribuida de OrientDB está establecida en replicación completa. Tener varios nodos con la misma copia de la base de datos es importante para las lecturas de escala. De hecho, cada servidor es independiente para ejecutar lecturas y consultas. Si tiene 10 nodos de servidor, el rendimiento de lectura es 10x.

Con escrituras, es lo contrario: tener múltiples nodos con replicación completa ralentiza las operaciones, si la replicación es sincrónica. En este caso, la fragmentación de la base de datos en varios nodos le permite escalar las escrituras, porque solo un subconjunto de nodos está involucrado en la escritura. Además, podría tener una base de datos más grande que un nodo de servidor HD.

Amplíe las escrituras

Si tiene una red lenta y tiene una replicación sincrónica (predeterminada), podría pagar el costo de la latencia. De hecho, cuando OrientDB se ejecuta sincrónicamente, espera al menos lawriteQuorum. Esto significa que si el writeQuorum es 3 y tiene 5 nodos, el nodo del servidor coordinador (donde se inicia la operación distribuida) tiene que esperar la respuesta de al menos 3 nodos para proporcionar la respuesta al cliente.

Para mantener la coherencia, writeQuorum debe establecerse en la mayoría. Si tiene 5 nodos, la mayoría es 3. Con 4 nodos, sigue siendo 3. Establecer el valor de writeQuorum en 3 en lugar de 4 o 5 permite reducir el costo de latencia y aún mantener la consistencia.

Replicación asincrónica

Para acelerar las cosas, puede configurar la replicación asincrónica para eliminar el cuello de botella de latencia. En este caso, el nodo servidor coordinador ejecuta la operación localmente y da la respuesta al cliente. Toda la réplica estará en segundo plano. En caso de que no se alcance el quórum, los cambios se revertirán de forma transparente.

Escale las lecturas

Si ya configuró writeQuorum en la mayoría de los nodos, puede dejar el readQuoruma 1 (el predeterminado). Esto acelera todas las lecturas.