Desempenho do driver do conector Java do MariaDB

DESEMPENHO DO CONECTOR MARIADB JAVA

• MariaDB 1.5.3
• MySQL 5.1.39
• Regue 1.4

O REFERENCIAL

public class BenchmarkSelect1RowPrepareText extends BenchmarkSelect1RowPrepareAbstract {

    @Benchmark
    public String mysql(MyState state) throws Throwable {
        return select1RowPrepare(state.mysqlConnectionText, state);
    }

    @Benchmark
    public String mariadb(MyState state) throws Throwable {
        return select1RowPrepare(state.mariadbConnectionText, state);
    }
  
    @Benchmark
    public String drizzle(MyState state) throws Throwable {
        return select1RowPrepare(state.drizzleConnectionText, state);
    }
  
}

public abstract class BenchmarkSelect1RowPrepareAbstract extends BenchmarkInit {
    private String request = "SELECT CAST(? as char character set utf8)";

    public String select1RowPrepare(Connection connection, MyState state) throws SQLException {
        try (PreparedStatement preparedStatement = connection.prepareStatement(request)) {
            preparedStatement.setString(1, state.insertData[state.counter++]);
            try (ResultSet rs = preparedStatement.executeQuery()) {
                rs.next();
                return rs.getString(1);
            }
        }
    }
}

AMBIENTE

• Java(TM) SE Runtime Environment (build 1.8.0_101-b13) 64 bits (última versão real ao executar este benchmark)
• Ubuntu 16.04 64 bits
• 512 MB de memória
• 1 processador
• banco de dados MariaDB “10.1.17-MariaDB”, MySQL Community Server build “5.7.15-0ubuntu0.16.04.1”
  usando arquivos de configuração padrão e estas opções adicionais:
  
  • max_allowed_packet =40 milhões de pacotes #exchange podem ter até 40 MB
  • character-set-server =utf8 #para usar UTF-8 como padrão
  • collation-server =utf8_unicode_ci #para usar UTF-8 como padrão

AMOSTRAS DE EXPLICAÇÕES DE RESULTADOS

Benchmark                                           Score     Error  Units
BenchmarkSelect1RowPrepareText.mariadb              62.715 ±  2.402  µs/op
BenchmarkSelect1RowPrepareText.mysql                88.670 ±  3.505  µs/op
BenchmarkSelect1RowPrepareText.drizzle              78.672 ±  2.971  µs/op

Isso significa que essa consulta simples levará um tempo médio de 62,715 microssegundos usando o driver MariaDB com uma variação de ± 2,402 microssegundos para 99,9% das consultas.
A mesma execução usando o driver drizzle levará um tempo médio de 88,670 microssegundos, e 78,672 microssegundos usando o conector MySQL (menor tempo de execução, melhor).

As porcentagens exibidas são definidas de acordo com o primeiro resultado do mariadb como referência (100%), permitindo comparar facilmente outros resultados.

COMPARAÇÕES DE DESEMPENHO

Protocolo de texto

Protocolo binário

1. PREPARE – Prepara a instrução para execução.
2. EXECUTAR – Enviar parâmetros
3. DEALLOCATE PREPARE – Libera uma declaração preparada.

Reescrever

• Os IDs de incremento automático não podem ser recuperados usandoStatement.html#getGeneratedKeys().
• Multi-consultas em uma execução são habilitadas. Isso não é um problema paraPreparedStatement, mas se o aplicativo usar Statement isso pode ser uma degradação da segurança (injeção de SQL).

RESULTADOS DE REFERÊNCIA

Resultados do driver MariaDB

CONSULTA DE SELEÇÃO ÚNICA

private String request = "SELECT CAST(? as char character set utf8)";

public String select1RowPrepare(Connection connection, MyState state) throws SQLException {
    try (PreparedStatement preparedStatement = connection.prepareStatement(request)) {
        preparedStatement.setString(1, state.insertData[state.counter++]); //a random 100 bytes.
        try (ResultSet rs = preparedStatement.executeQuery()) {
            rs.next();
            return rs.getString(1);
        }
    }
}

LOCAL DATABASE:
BenchmarkSelect1RowPrepareHit.mariadb               58.267 ±  2.270  µs/op
BenchmarkSelect1RowPrepareMiss.mariadb             118.896 ±  5.500  µs/op
BenchmarkSelect1RowPrepareText.mariadb              62.715 ±  2.402  µs/op

DISTANT DATABASE:
BenchmarkSelect1RowPrepareHit.mariadb               394.354 ±  13.102  µs/op
BenchmarkSelect1RowPrepareMiss.mariadb              709.843 ±  31.090  µs/op
BenchmarkSelect1RowPrepareText.mariadb              422.215 ±  15.858  µs/op

Quando o resultado PREPARE para esta consulta exata já estiver em cache (cache hit), a consulta será mais rápida (7,1% neste exemplo) do que usando o protocolo de texto. Devido às trocas PREPARE e DEALLOCATE de solicitação adicional, o cache miss é 68,1% mais lento.

Isso enfatiza as vantagens e inconvenientes de usar um protocolo binário. Cache HIT é importante.

CONSULTA DE INSERÇÃO ÚNICA

private String request = "INSERT INTO blackholeTable (charValue) values (?)";

public boolean executeOneInsertPrepare(Connection connection, String[] datas) throws SQLException {
    try (PreparedStatement preparedStatement = connection.prepareStatement(request)) {
        preparedStatement.setString(1, datas[0]); //a random 100 byte data
        return preparedStatement.execute();
    }
}

LOCAL DATABASE:
BenchmarkOneInsertPrepareHit.mariadb                 61.298 ±  1.940  µs/op
BenchmarkOneInsertPrepareMiss.mariadb               130.896 ±  6.362  µs/op
BenchmarkOneInsertPrepareText.mariadb                68.363 ±  2.686  µs/op

DISTANT DATABASE:
BenchmarkOneInsertPrepareHit.mariadb                379.295 ±  17.351  µs/op
BenchmarkOneInsertPrepareMiss.mariadb               802.287 ±  24.825  µs/op
BenchmarkOneInsertPrepareText.mariadb               415.125 ±  14.547  µs/op

Os resultados para INSERTs são semelhantes aos resultados de SELECTs.

LOTE:1.000 INSERIR CONSULTA

private String request = "INSERT INTO blackholeTable (charValue) values (?)";

public int[] executeBatch(Connection connection, String[] data) throws SQLException {
  try (PreparedStatement preparedStatement = connection.prepareStatement(request)) {
    for (int i = 0; i < 1000; i++) {
      preparedStatement.setString(1, data[i]); //a random 100 byte data
      preparedStatement.addBatch();
    }
    return preparedStatement.executeBatch();
  }
}

LOCAL DATABASE:        
PrepareStatementBatch100InsertPrepareHit.mariadb    5.290 ±  0.232  ms/op
PrepareStatementBatch100InsertRewrite.mariadb       0.404 ±  0.014  ms/op
PrepareStatementBatch100InsertText.mariadb          6.081 ±  0.254  ms/op

DISTANT DATABASE:        
PrepareStatementBatch100InsertPrepareHit.mariadb    7.639 ±   0.476  ms/op
PrepareStatementBatch100InsertRewrite.mariadb       1.164 ±   0.037  ms/op
PrepareStatementBatch100InsertText.mariadb          8.148 ±   0.563  ms/op

O uso do protocolo binário é aqui mais significativo, tendo resultados 13% mais rápidos do que o uso do protocolo de texto.

As inserções são enviadas em massa e os resultados são lidos de forma assíncrona (que corresponde a optionuseBatchMultiSend). Isso permite ter resultados distantes com desempenho não muito distante dos locais.

Rewrite tem um desempenho incrível, mas não terá ids de incremento automático. Se você não precisa de ids imediatamente e não usa ORM, esta solução será a mais rápida. Alguns ORM permitem que a configuração lide com a sequência internamente para fornecer IDs de incremento, mas essas sequências não são distribuídas, portanto, não funcionarão em clusters.

COMPARAÇÃO COM OUTROS MOTORISTAS

SELECT consulta com resultado de uma linha

BenchmarkSelect1RowPrepareHit.mariadb                58.267 ±  2.270  µs/op
BenchmarkSelect1RowPrepareHit.mysql                  73.789 ±  1.863  µs/op
BenchmarkSelect1RowPrepareMiss.mariadb              118.896 ±  5.500  µs/op
BenchmarkSelect1RowPrepareMiss.mysql                150.679 ±  4.791  µs/op
BenchmarkSelect1RowPrepareText.mariadb               62.715 ±  2.402  µs/op
BenchmarkSelect1RowPrepareText.mysql                 88.670 ±  3.505  µs/op
BenchmarkSelect1RowPrepareText.drizzle               78.672 ±  2.971  µs/op
BenchmarkSelect1RowPrepareTextHA.mariadb             64.676 ±  2.192  µs/op
BenchmarkSelect1RowPrepareTextHA.mysql              137.289 ±  4.872  µs/op

HA significa “High Availability” usando a configuração Master-Slave
(URL de conexão é “jdbc:mysql:replication://localhost:3306,localhost:3306/testj”).

Esses resultados são devidos a muitas opções de implementação diferentes. Aqui estão algumas razões que explicam as diferenças de tempo:

• O driver MariaDB é otimizado para UTF-8, permitindo menos criação de array de bytes, evitando cópia de array e consumo de memória.
• Implementação de alta disponibilidade:os drivers MariaDB e MySQL usam uma classe proxy dinâmica Java localizada entre objetos Statement e soquetes, permitindo adicionar comportamento de failover. Essa adição custará uma sobrecarga de 2 microssegundos por consulta (62,715 sem se tornar 64,676 microssegundos).
  Na implementação do MySQL, quase todos os métodos internos são proxy, adicionando uma sobrecarga para muitos métodos que não têm nada a ver com failover, adicionando uma sobrecarga total de 50 microssegundos para cada consulta.

"Selecionar 1.000 linhas"

private String request = "select * from seq_1_to_1000"; //using the sequence storage engine

private ResultSet select1000Row(Connection connection) throws SQLException {
  try (Statement statement = connection.createStatement()) {
    try (ResultSet rs = statement.executeQuery(request)) {
      while (rs.next()) {
        rs.getString(1);
      }
      return rs;
    }
  }

BenchmarkSelect1000Rows.mariadb                     244.228 ±  7.686  µs/op
BenchmarkSelect1000Rows.mysql                       298.814 ± 12.143  µs/op
BenchmarkSelect1000Rows.drizzle                     406.877 ± 16.585  µs/op

Ao usar muitos dados, o tempo é gasto principalmente na leitura do soquete e no armazenamento do resultado na memória para enviá-lo de volta ao cliente. Se o benchmark estivesse apenas executando o SELECT sem ler os resultados, o tempo de execução do MySQL e do MariaDB seria equivalente. Como o objetivo de uma consulta SELECT é ter resultados, o driver MariaDB é otimizado para retornar resultados (evitando a criação de arrays de bytes).

"Inserir 1.000 linhas"

LOCAL DATABASE:        
PrepareStatementBatch100InsertPrepareHit.mariadb    5.290 ±  0.232  ms/op
PrepareStatementBatch100InsertPrepareHit.mysql      9.015 ±  0.440  ms/op
PrepareStatementBatch100InsertRewrite.mariadb       0.404 ±  0.014  ms/op
PrepareStatementBatch100InsertRewrite.mysql         0.592 ±  0.016  ms/op
PrepareStatementBatch100InsertText.mariadb          6.081 ±  0.254  ms/op
PrepareStatementBatch100InsertText.mysql            7.932 ±  0.293  ms/op
PrepareStatementBatch100InsertText.drizzle          7.314 ±  0.205  ms/op

DISTANT DATABASE:        
PrepareStatementBatch100InsertPrepareHit.mariadb     7.639 ±   0.476  ms/op
PrepareStatementBatch100InsertPrepareHit.mysql      43.636 ±   1.408  ms/op
PrepareStatementBatch100InsertRewrite.mariadb        1.164 ±   0.037  ms/op
PrepareStatementBatch100InsertRewrite.mysql          1.432 ±   0.050  ms/op
PrepareStatementBatch100InsertText.mariadb           8.148 ±   0.563  ms/op
PrepareStatementBatch100InsertText.mysql            43.804 ±   1.417  ms/op
PrepareStatementBatch100InsertText.drizzle          38.735 ±   1.731  ms/op

A inserção em massa do MySQL e do Drizzle é como a do X INSERT:Driver envia 1 INSERT, espera o resultado da inserção e envia a próxima inserção. A latência de rede entre cada inserção diminuirá a velocidade das inserções.

Procedimentos da loja

LIGAÇÃO DE PROCEDIMENTO

//CREATE PROCEDURE inoutParam(INOUT p1 INT) begin set p1 = p1 + 1; end
private String request = "{call inOutParam(?)}";

private String callableStatementWithOutParameter(Connection connection, MyState state) 
		throws SQLException {
  try (CallableStatement storedProc = connection.prepareCall(request)) {
    storedProc.setInt(1, state.functionVar1); //2
    storedProc.registerOutParameter(1, Types.INTEGER);
    storedProc.execute();
    return storedProc.getString(1);
  }
}

BenchmarkCallableStatementWithOutParameter.mariadb   88.572 ±  4.263  µs/op
BenchmarkCallableStatementWithOutParameter.mysql    714.108 ± 44.390  µs/op

As implementações do MySQL e do MariaDB diferem completamente. O driver MySQL usará muitas consultas ocultas para obter o resultado de saída:

• SHOW CREATE PROCEDURE testj.inoutParam para identificar os parâmetros IN e OUT
• SET @com_mysql_jdbc_outparam_p1 = 1 para enviar dados de acordo com os parâmetros IN / OUT
• CALL testj.inoutParam(@com_mysql_jdbc_outparam_p1) procedimento de chamada
• SELECT @com_mysql_jdbc_outparam_p1 para ler o resultado de saída

CONCLUSÃO

1. com um banco de dados MariaDB 10.1.17 local, distante
2. com um banco de dados MySQL Community Server 5.7.15 (compilação 5.7.15-0ubuntu0.16.04.1) local