OrientDB - Ajuste de Desempenho

Neste capítulo, você pode obter algumas dicas gerais sobre como otimizar seu aplicativo que usa OrientDB. Existem três maneiras de aumentar o desempenho para diferentes tipos de banco de dados.

• Document Database Performance Tuning - Ele usa uma técnica que ajuda a evitar a criação de documentos para cada novo documento.

• Object Database Performance Tuning - Ele usa as técnicas genéricas para melhorar o desempenho.

• Distributed Configuration Tuning - Utiliza diferentes metodologias para melhorar o desempenho na configuração distribuída.

Você pode obter um ajuste de desempenho genérico alterando as configurações de memória, JVM e conexão remota.

Configurações de memória

Existem diferentes estratégias na configuração da memória para melhorar o desempenho.

Configurações de servidor e incorporadas

Essas configurações são válidas para o componente do servidor e a JVM onde o aplicativo Java é executado usando OrientDB no modo incorporado, usando diretamente plocal.

O mais importante no ajuste é garantir que as configurações de memória estejam corretas. O que pode fazer uma diferença real é o equilíbrio certo entre o heap e a memória virtual usada pelo mapeamento de memória, especialmente em grandes conjuntos de dados (GBs, TBs e mais) onde as estruturas de cache de memória contam menos do que o IO bruto.

Por exemplo, se você pode atribuir no máximo 8 GB ao processo Java, geralmente é melhor atribuir um heap pequeno e um buffer de cache de disco grande (memória fora do heap).

Tente o seguinte comando para aumentar a memória heap.

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

o storage.diskCache.bufferSize configuração (com o antigo armazenamento "local" era file.mmap.maxMemory) está em MB e informa a quantidade de memória a ser usada para o componente Disk Cache. Por padrão, é de 4 GB.

NOTE - Se a soma do heap máximo e do buffer do cache de disco for muito alta, isso pode fazer com que o sistema operacional troque com grande lentidão.

Configurações JVM

As configurações de JVM são codificadas em arquivos em lote server.sh (e server.bat). Você pode alterá-los para ajustar o JVM de acordo com seu uso e configurações de hw / sw. Adicione a seguinte linha no arquivo server.bat.

-server -XX:+PerfDisableSharedMem

Essa configuração desabilitará a gravação de informações de depuração sobre a JVM. Caso você precise criar o perfil da JVM, apenas remova esta configuração.

Conexões Remotas

Existem muitas maneiras de melhorar o desempenho ao acessar o banco de dados usando uma conexão remota.

Estratégia de busca

Ao trabalhar com um banco de dados remoto, você deve prestar atenção à estratégia de busca usada. Por padrão, o cliente OrientDB carrega apenas o registro contido no conjunto de resultados. Por exemplo, se uma consulta retornar 100 elementos, mas se você cruzar esses elementos do cliente, o cliente OrientDB carrega lentamente os elementos com mais uma chamada de rede para o servidor para cada registro perdido.

Pool de conexão de rede

Cada cliente, por padrão, usa apenas uma conexão de rede para se comunicar com o servidor. Vários threads no mesmo cliente compartilham o mesmo pool de conexão de rede.

Quando você tem vários threads, pode haver um gargalo, pois muito tempo é gasto esperando por uma conexão de rede gratuita. É por isso que é importante configurar o pool de conexão de rede.

A configuração é muito simples, apenas 2 parâmetros -

• minPool- É o tamanho inicial do pool de conexão. O valor padrão é configurado como parâmetros globais "client.channel.minPool".

• maxPool- É o tamanho máximo que o pool de conexão pode atingir. O valor padrão é configurado como parâmetros globais "client.channel.maxPool".

Se todas as conexões do pool estiverem ocupadas, o encadeamento do cliente aguardará a primeira conexão livre.

Exemplo de comando de configuração usando propriedades do banco de dados.

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

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

Ajuste de configuração distribuída

Existem muitas maneiras de melhorar o desempenho na configuração distribuída.

Use transações

Mesmo quando você atualiza gráficos, você deve sempre trabalhar em transações. OrientDB permite que você trabalhe fora deles. Casos comuns são consultas somente leitura ou operações massivas e não simultâneas podem ser restauradas em caso de falha. Quando você executa em configuração distribuída, o uso de transações ajuda a reduzir a latência. Isso ocorre porque a operação distribuída acontece apenas no momento da confirmação. Distribuir uma grande operação é muito mais eficiente do que transferir pequenas operações múltiplas, devido à latência.

Replicação vs Sharding

A configuração distribuída do OrientDB está definida para replicação completa. Ter vários nós com a mesma cópia do banco de dados é importante para leituras de escala. Na verdade, cada servidor é independente na execução de leituras e consultas. Se você tiver 10 nós de servidor, a taxa de transferência de leitura é 10x.

Com gravações, é o oposto: ter vários nós com replicação completa retarda as operações, se a replicação for síncrona. Nesse caso, fragmentar o banco de dados em vários nós permite aumentar as gravações, porque apenas um subconjunto de nós está envolvido na gravação. Além disso, você pode ter um banco de dados maior que um nó de servidor HD.

Amplie as gravações

Se você tiver uma rede lenta e uma replicação síncrona (padrão), poderá pagar o custo da latência. Na verdade, quando o OrientDB é executado de forma síncrona, ele espera pelo menos pelowriteQuorum. Isso significa que se o writeQuorum for 3 e você tiver 5 nós, o nó do servidor coordenador (onde a operação distribuída é iniciada) deve aguardar a resposta de pelo menos 3 nós para fornecer a resposta ao cliente.

Para manter a consistência, o writeQuorum deve ser definido como a maioria. Se você tiver 5 nós, a maioria é 3. Com 4 nós, ainda é 3. Definir o writeQuorum para 3 em vez de 4 ou 5 permite reduzir o custo de latência e ainda manter a consistência.

Replicação Assíncrona

Para acelerar as coisas, você pode configurar a replicação assíncrona para remover o gargalo de latência. Nesse caso, o nó do servidor coordenador executa a operação localmente e dá a resposta ao cliente. Toda a replicação ficará em segundo plano. Caso o quorum não seja atingido, as alterações serão revertidas de forma transparente.

Amplie as leituras

Se você já definiu o writeQuorum para a maioria dos nós, pode deixar o readQuorumpara 1 (o padrão). Isso acelera todas as leituras.