Social Icons

21 de set. de 2016

Otimizando desempenho de LOBs com SSD



Olá pessoal,

     No post de hoje quero compartilhar com vocês uma experiência excepcional e recente que tive com o desempenho de LOBs em discos SSD no Oracle Database, eu um servidor de produção.

     Se você já tem bons conhecimentos em arquitetura do banco de dados Oracle e colunas do tipo LOB (CLOB ou BLOB), você sabe que por padrão os valores de colunas desse tipo de dado não são armazenados em cache (buffer cache da SGA), portanto, leituras de dados do tipo LOB não são muito rápidas, pois além dos dados normalmente serem grandes, ocorrerão sempre (na configuração padrão) leituras físicas (ao invés de leituras lógicas, que normalmente são mais rápidas). Essa configuração pode ser alterada  (ver artigo Gerenciando o armazenamento/desempenho de colunas LOB), porém não faça a alteração sem uma boa análise, pois é bem provável que a Buffer Cache do Banco de Dados não tenha espaço suficiente para armazenar os dados dos LOBs. Neste caso, sugiro avaliar outras alternativas para otimizar o desempenho dessas leituras.
  
      Uma alternativa que eu implementei recentemente e que fiquei muito contente com o resultado, foi mudar o armazenamento dos datafiles dos dados de colunas do tipo LOB, de discos rígidos para discos SSD. Seguem abaixo as especificações desses discos:
          - Discos rígidos (HDD): 3 X discos em RAID 5 de 15K (Storage Hitachi AMS 2500);
          - SSD: Hot Plug SFF SAS SSD (Server HP DL 380p Gen8).



Performance de HDD X SSD
       
        Um dos sistemas utilizados na empresa em que trabalho, tem como objetivo principal efetuar o gerenciamento de processos, e ele possui atualmente, aproximadamente, 148 GB de documentos em colunas do tipo BLOB, em uma tabela que vou atribuir aqui um nome fictício de XPTO. Uma das funcionalidades mais utilizadas nesse sistema é a visualização de documentos. Logo após a alteração dos LOBs para discos SSD, testei essa funcionalidade e notei um grande ganho de performance no acesso aos documentos, então resolvi criar alguns scripts para comprovar e medir o ganho nas leituras e escritas dos LOBs em SSD. Seguem abaixo os detalhes deste teste:

1- Características da tabela XPTO (com nomes fictícios):
        a) Colunas:
                - CD_DOC NOT NULL VARCHAR2(18);
                - IM_DOC BLOB.
        b) Tamanho do segmento da tabela (sem a coluna IM_DOC): 216 MB;
        c) Tamanho do segmento da coluna BLOB: 148,32 GB.
  
2- Tablespaces utilizados:
        a) TESTE_HD: Tablespace contendo 1 datafile armazenado nos discos rígidos.
        b) TESTE_SSD: Tablespace contendo 1 datafile armazenado no disco SSD.  

3- Script criado para clonar a tabela XPTO com apenas 20.000 linhas (aprox. 5% do total) no tablespace TESTE_HD e medir o tempo de gravação nos discos rígidos:
     create table TB_XPTO_HD TABLESPACE TESTE_HD AS
     SELECT * FROM XPTO where rownum < 20000; 
Tempo de execução deste script: 844,84s
4- Script criado para clonar a tabela XPTO com apenas 20.000 linhas (aprox. 5% do total) no tablespace TESTE_SSD e medir o tempo de gravação no disco SSD:
     create table TB_XPTO_SSD TABLESPACE TESTE_SSD AS
     SELECT * FROM XPTO where rownum < 20000;
Tempo de execução deste script: 162s
5- Script criado para ler a tabela clonada em discos rígidos e medir o tempo de leitura:
     DECLARE
       V_VALOR VARCHAR2(32767);
     BEGIN
       FOR LINHA IN (select dbms_lob.substr(IM_DOC,2000,1) AS IM_DOC
                                    from TB_XPTO_HD)
       LOOP
           V_VALOR := LINHA.IM_DOC;
       END LOOP;
     END;
Tempo médio de leitura (3 testes consecutivos): 1.146,27s
6- Script criado para ler a tabela clonada em disco SSD e medir o tempo de leitura:
     DECLARE
       V_VALOR VARCHAR2(32767);
     BEGIN
       FOR LINHA IN (select dbms_lob.substr(IM_DOC,2000,1) AS IM_DOC
                                    from TB_XPTO_SSD)
       LOOP
           V_VALOR := LINHA.IM_DOC
       END LOOP;
     END;
Tempo médio de leitura (3 testes consecutivos): 78,79s
  
     Observe que o tempo de gravação nos discos SSD teve um ganho de desempenho de 521% (844,84/162*100), enquanto que, nas operações de leitura o ganho médio foi maior, com um índice de 1.424,84%, ou seja, a leitura em SSD foi 14,54 X mais rápida. Bom né? Sim, muito bom, eu diria excelente! Uma simples alteração de armazenamento para SSD conseguiu fazer uma monstruosa otimização nos SQLs do sistema!
  
     Não contente com estes resultados, resolvi fazer mais alguns testes de desempenho, alterando a coluna BLOB da tabela TB_XPTO_HD para armazenar seus dados em CACHE. Vejam abaixo os resultados:

a) Testes de leitura no BLOB sem cache:
     DECLARE
       V_VALOR VARCHAR2(32767);
     BEGIN
       FOR LINHA IN (select dbms_lob.substr(IM_DOC,2000,1) AS IM_DOC
                     from TB_XPTO_HD WHERE ROWNUM < 10000)
       LOOP
           V_VALOR := LINHA.IM_DOC;
       END LOOP;
     END; -- 37,407s, 7,012s, 1,572s, 1,47s
Tempo médio de leitura (4 testes consecutivos, ignorando a 1ª execução que normalmente demora mais, quando o 1º acesso faz leitura física): 3,35s

a) Testes de leitura no BLOB com cache:
     DECLARE
       V_VALOR VARCHAR2(32767);
     BEGIN
       execute immediate 'ALTER TABLE TB_XPTO_HD MODIFY LOB(IM_DOC)(CACHE)';
       FOR LINHA IN (select dbms_lob.substr(IM_DOC,2000,1) AS IM_DOC
                     from   TB_XPTO_HD WHERE ROWNUM < 10000)
       LOOP
           V_VALOR := LINHA.IM_DOC;
       END LOOP;
     END; -- 19,417s, 0,516s, 0,502s, 0,502s
Tempo médio de leitura (4 testes consecutivos, ignorando a 1ª execução que normalmente demora mais, quando o 1º acesso faz leitura física): 0,506s

     Observe que agora fizemos um teste diferente, lendo metade das linhas da tabela, e o tempo médio de leitura dos dados BLOB em cache teve um ganho de desempenho de 662% em relação ao desempenho da leitura física em discos rígidos, ou seja, a leitura foi 6,62 X mais rápida com cache. Ainda assim, o desempenho do cache (leitura lógica) foi menor que o desempenho dos discos SSD (leitura física). Estranho não? Eu achei que o desempenho das leituras lógicas do LOB teriam que ser mais rápidas que as leituras físicas no SSD, pois é isso que normalmente vejo ocorrer com outros tipos de dados menores! Tenho algumas suspeitas do porquê disso ter ocorrido, mas irei investigar mais antes de escrever qualquer coisa que possa estar errada. Se você souber a resposta, deixe aqui o seu comentário para aprendermos juntos! Só sei de uma coisa: SSD é o futuro! Ele vai baratear e sua durabilidade vai aumentar. E tem mais (agora vou dar uma de "Nostradamus"), acredito que daqui há uns 10 anos a maior parte dos servidores disponíveis no mercado não terão mais discos rígidos!

  
[]s e até a próxima!





4 comments:

  1. Obrigado por compartilhar Fabio.
    Ficou bem documentado.

    ResponderExcluir
  2. É viável colocar os arquivos de redo e undo em SSD?

    ResponderExcluir
    Respostas
    1. Não recomendo. Veja os artigos http://nervinformatica.com.br/blog/index.php/2014/02/01/nao-coloque-redo-logs-em-ssd/ e https://itpeernetwork.intel.com/should-you-put-oracle-database-redo-on-solid-state-disks-ssds/.

      Excluir

 

LINKS ÚTEIS

Total de visualizações de página

Seguidores

Meu One Drive (antigo Sky Drive)