SCM Join Um Algoritmo de Junção para Memória SCM

Transcrição

1 SCM Join Um Algoritmo de Junção para Memória SCM Júlio Alcântara Tavares 1, José de Aguiar Moraes Filho 1, Angelo Brayner 1 1 Programa de Pós Graduação em Informática Aplicada Universidade de Fortaleza (UNIFOR) Caixa Postal Fortaleza CE Brazil {julio,jaguiar,brayner}@unifor.br Nível: Mestrado Ano de ingresso no programa: 2011 Exame de qualificação: Mês de Novembro/2012 Época esperada de conclusão: Mês de Junho/2013 Resumo. A SCM (Storage Class Memory) é uma categoria de dispositivos de armazenamento que oferece um vasto campo de pesquisa e, devido as suas características intrínsecas, está intimamente relacionada com o redesenho dos principais componentes do SGBD. Os componentes de processamento de consultas, recuperação/logging e indexação, quando revisitados para aderir a este novo paradigma, poderiam trazer grandes benefícios relacionados a vazão e ao desempenho do sistema, elevando o a um outro nível de desempenho. Pensar em novas abordagens para os algoritmos atuais (clássicos) representa boa parte desta questão. Grandes fornecedores de servidores de armazenamento (como por exemplo, Oracle Exadata, a linha CX da EMC e a linha Dell Compellent) aderiram a esta realidade e já disponibilizam hardware especializado em SCM para armazenamento e cache de dados. Neste trabalho, pretendemos explorar as características e tradeoffs da SCM para repensar e replanejar componentes da infraestrutura dos SGBDs, especificamente na área de processamento de consultas, propondo um novo algoritmo de junção que leva em consideração o armazenamento dos dados em mídia SCM. Dessa forma, pretende se evidenciar que, com o avanço e popularização destas novas mídias, se os principais algoritmos que atualmente estão em execução nos SGBDs comerciais fossem sensíveis ao contexto e às características da mídia de armazenamento subjacente, seria possível obter ganhos que vão muito além da velocidade física da SCM. Palavras Chave: banco de dados 1, operador de junção 2, storage class memory (SCM) 3 7

2 SCM Join - Um Algoritmo de Junção para Memória SCM Júlio A. Tavares 1, José de Aguiar Moraes Filho 1, Angelo Brayner 1 1 Programa de Pós-Graduação em Informática Aplicada - Universidade de Fortaleza (UNIFOR) Fortaleza CE Brasil 1. Introdução {julio,jaguiar,brayner}@unifor.br Nas últimas décadas a velocidade dos processadores aumentou exponencialmente. Enquanto isso, o número de entradas/saídas por segundo (IOPS) proporcionadas pelos discos rígidos (HDDs) aumentou apenas ligeiramente, não acompanhando a taxa de crescimento imposta pelos processadores. Para amenizar esse problema, um conjunto de novas mídias de armazenamento, denominada Storage Class Memory (SCM), surgiu como uma solução bastante eficiente para esta questão. Exemplos de SCM incluem a memória flash, PCM (phase-change memory), SSDs (discos de estado sólido), dentre outros. Três características principais devem ser destacadas na SCM: (i) não volatilidade, (ii) baixo tempo de acesso, (iii) alta vazão (# IOPS) e (iv) assimetria no tempo de leitura/gravação. As duas primeiras têm um benefício direto para os sistemas de banco de dados. A última característica representa grandes desafios para os sistemas gerenciadores de banco de dados, podendo levar a uma proporção de 1:200 em relação aos tempos de leitura e escrita de dados na SCM [Nath and Kansal 2007]. Realizamos uma bateria de experimentos para termos indícios das características e das melhores práticas a serem seguidas no projeto de um algoritmo de junção para mídias SCM. Utilizamos um servidor Intel Quad Core 1,83 GHz usando o Windows 7 64-bits, com 4-GB de memória RAM. Executamos experimentos com bancos de dados armazenados em um disco rígido (HDD) e em um disco de estado sólido (SSD). O HDD utilizado foi um SATA II da Samsung (modelo 502HI) com 500 Gbytes, 7200 rpm e cache de 16 MB. O disco SSD utilizado foi um Corsair Force GT de 120 GB, ligado ao servidor através de interface SATA II. As bases de dados utilizadas nos experimentos foram criadas utilizando o SQL Server 2008 (64bits), utilizando o HDD e o SSD. Antes de executar cada experimento, o serviço do banco de dados foi reinicializado para diminuir a influência do gerenciador do buffer e da política de alocação de memória nos testes executados. Para cada execução, utilizamos o mesmo tamanho de buffer do SGBD. O SSD foi preenchido por completo, a cada teste, para que não existissem blocos de dados livres para a escrita (ou apenas estivessem livres a minoria necessária para a execução do experimento), pois isso poderia levar a maiores flutuações na coleta dos resultados. Essa ação também visou a simulação do pior caso, já que todos os blocos estavam escritos (alocados). Investigamos a influência de algoritmos de junção (nested-loop join, merge join e hash join) e tempos de resposta de consultas com 12 das 23 consultas utilizadas no TPC-H (consultas 2, 3, 5, 10, 11, 12, 14, 16, 17, 18, 19 e 23). O critério de seleção destas consultas foi a participação de tabelas grandes, especialmente a tabela LineItem, que mesmo tendo sido criada com fator de escala 1 possuia mais de 6.5x10 6 tuplas. Cada uma destas consultas foi executada forçando o uso de um algoritmo específico de junção. Junções que utilizaram o nested-loop join apresentaram os piores re- 8

3 sultados em SSD, em relação aos planos que utilizaram os operadores hash-join e mergejoin. Isto ocorreu porque o uso do nested-loop-join consumiu mais espaço temporário durante a sua execução, o que implica mais operações de escrita em um maior espaço de armazenamento no SSD, resultando em pior desempenho. (a) Consultas 05, 17, 18 (TPCH) (b) Consultas 02, 03, 14 (TPCH) (c) Consultas 16, 19, 23 (TPCH) (d) Consultas 10, 11, 12 (TPCH) Figure 1. Desempenho dos Algoritmos em mídia SCM Com relação ao hash join e ao merge join, é importante ressaltar que para criar os buckets (partições) durante a etapa de particionamento (hash-join) e para ordenar os dados antes de realizar a junção (merge join), também é necessário a utilização de espaço temporário. Por exemplo, na Consulta 3 o merge-join obteve melhor desempenho no HDD, sendo menos eficiente no SSD. A razão para tal comportamento é novamente o número de operações de gravação para classificar os blocos utilizados pelo resultado temporário gerado. Analisando especificamente o merge-join e o hash-join, não há nenhum vencedor evidente. Em geral, observamos a seguinte regra: quanto mais resultados temporários são gerados, maior é o tempo de resposta da consulta no SSD. Dessa forma, entendemos essa característica como sendo umas das principais questões a serem analisadas durante o projeto de um algoritmo de junção para mídia SCM, o que também reflete a importância de tratar a assimetria de E/S desta mídia. Percebemos também que, de um modo geral, os tempos de execução dos algoritmos clássicos em HDD e SSD são parecidos, embora diferentes em termos absolutos. Isso pode ser um indício de que heurísticas similares as que são utilizadas no HDDs poderiam ser aplicadas também para o SSD. Estudos mais detalhados precisam ser feitos para comprovar esta hipótese. Entretanto, houve situações onde o nested-loop join apresentou um desempenho melhor que o do hash-join e do merge-join. Por exemplo, nas consultas 3 e 19 os planos 9

4 que utilizaram o nested-loop apresentaram melhor desempenho do que os demais planos de execução, quando executados no SSD. Procuramos entender este comportamento e detalhamos a execução da consulta para averiguar as informações dos resultados obtidos. Após análise, descobrimos que esses planos utilizaram o nested-loop-join usando índices (index nested-loop-join). As consultas 3 e 19 utilizaram a tabela LineItem, uma tabela que armazenava uma quantidade relevante de tuplas. O algoritmo de junção executado nos planos que envolviam o nested-loop e que estavam relacionados com as consultas 3 e 19 utilizou um índice na tabela LineItem como operando interno da junção. Percebemos que esta situação acelerou bastante a execução do plano, o que gera indícios sobre a validade de utilizar índices mesmo quando utilizando mídias SCM. Levando em consideração os argumentos expostos anteriormente, podemos formular as seguintes hipóteses: (i) A fim de tornar as técnicas de processamento de consulta capazes de tirar proveito do uso de mídia SCM, é necessário desenvolver algoritmos que fazem uso de pipeline ou de adaptabilidade, visando diminuir a geração de resultados temporários. (ii) Além disso, é de fundamental importância a concepção de um novo modelo de custo visando adequá-lo em um novo paradigma de processamento de consultas. Neste modelo, não apenas o número de páginas transferidas deve ser avaliado, mas também deveremos avaliar o número de páginas escritas durante a execução do plano, as quais devem ter um peso maior do que o aplicado para as páginas transferidas da memória secundária (SSD) para a memória principal, levando em consideração as características de assimetria de E/S da SCM. Pretendemos realizar um estudo empírico sobre o uso da SCM em sistemas gerenciadores de banco de dados, especificamente dentro da área de processamento de consultas. Para isso, propomos um novo algoritmo de junção, denominado SCM Join, que reúne características necessárias para obter um desempenho eficaz na realização de junções em mídias do tipo SCM. 2. O Algoritmo SCM Join Como contribuições, podemos mencionar: (i) A evidenciação da necessidade de repensar a arquitetura de elementos chave dos SGBDs, como o processamento de consultas, para que estes possam usufruir das características da SCM; (ii) A realização de experimentos que geram indícios acerca das melhores práticas a serem adotadas no projeto de algoritmos e componentes arquiteturais do SGBD que levam em consideração a assimetria de E/S; (iii) A implementação de um algoritmo de junção para mídias SCM utilizando o SGBD PostgreSql; e (iv) A evidenciação de que um modelo de custo específico para mídia SCM pode trazer grandes benefícios para os SGBDs atuais. Tentamos projetar o SCM Join, que é um tipo de hash join para SCM, com as seguintes diretrizes: (i) Tratamento do transbordamento de memória levando em consideração o contexto específico da mídia SCM; (ii) Utilização de técnicas de compressão para gerar menos resultados intermediários, visando diminuir o total de escritas na mídia; e (iii) Explorar as rápidas leituras randômicas oferecidas pela SCM. Consideramos que o tamanho de um bucket (partição) tem o mesmo tamanho que o bloco físico da mídia SCM (linhas 3 4), visando evitar escritas randômicas desnecessárias na mídia. Usamos técnicas de compressão (linha 20) para armazenar mais tuplas em cada bucket. Assim, o algoritmo tende a apresentar menor frequen- 10

5 cia de situações de estouro de partição (transbordamento de memória). Estamos também analisando técnicas específicas que processam e comprimem várias tuplas adjacentes de uma só vez, reduzindo o custo de compressão (CPU e Overhead de Espaço) [Abadi et al. 2006]. Listing 2. Métodos Auxiliares. Listing 1. Algoritmo SCM Join. 1 Begin 2 BufferMap. a l o c a ( ) ; 3 p a r t i c i o n a (R) ; 4 p a r t i c i o n a ( S ) ; 5 For t u p l a R in BktR ( i ) de R loop 6 For t u p l a S in BktS ( i ) de S loop 7 if ( t u p l a R. a t r J u n c a o = 8 t u p l a S. a t r J u n c a o ) then 9 Pipe ( tuplar, t u p l a S ) ; 10 end i f ; 11 end loop ; 12 end loop ; 13 End ; 14 Procedure p a r t i c i o n a ( t a b e l a ) Begin 15 For t u p l a T in t a b e l a loop 16 p a r t i c a o := hash ( t u p l a. a t r J u n c a o ) ; 17 If o v e r f l o w ( p a r t i c a o ) then 18 d e s c a r r e g a ( p a r t i c a o ) ; 19 else 20 tuplacomp := compactar ( t u p l a ) ; 21 i n s e r e T u p l a P a r t i c a o ( tuplacomp, p a r t i c a o ) ; 22 end i f ; 23 end loop ; 24 End p a r t i c i o n a ; 25 Procedure d e s c a r r e g a ( b u c k e t ) Begin 26 BufferMap. a t u a l i z a ( b u c k e t ) ; 27 g r a v a B u c k e t ( b u c k e t ) ; 28 End d e s c a r r e g a ; Necessitamos de uma estrutura de mapeamento auxiliar no controle do estouro de buckets (linhas 25 28). Sempre que isto ocorre o bucket é então descarregado para o disco e a estrutura de mapeamento é atualizada para mapear corretamente os buckets que estão em disco e os buckets que estão em memória. A estrutura de mapeamento possui 3 campos: o endereço físico do bloco para onde foi descarregado o bucket na mídia SCM, o ID do bucket e um indicador que informa se o bucket está ou não armazenado em memória principal. Forma-se assim uma espécie de lista de buckets que sofreram transbordamento de memória. Esta estrutura pode ser perfeitamente implementada como uma tabela hash, valendo-se, naturalmente, da velocidade de acesso randômico da mídia SCM. A comparação das tuplas compactadas se faz sem a necessidade de prévia descompactação (linhas 7 8), seguindo [Graefe and Shapiro 1991]. Quanto ao modelo de custos, sugerimos ser levado em consideração o uso de compressão de dados no algoritmo e de um componente de custo para páginas escritas, adicional ao tradicional páginas transferidas do disco. Dever-se-ia ser também atribuído um peso maior para as páginas escritas (i) quando não houver pipeline, e (ii) quando for necessário a materialização de resultados intermediários. Uma forma de mitigar o problema das escritas ocasionadas pela geração dos resultados intermediários seria através da estratégia Late Materialization [Tsirogiannis et al. 2009]. Entretanto, é importante ressaltar que o uso desta abordagem pode gerar impactos na geração dos planos de execução. Analisaremos a viabilidade deste modelo, bem como realizaremos experimentos para gerar indícios necessários à comprovação destas hipóteses. A nossa escolha pelo algoritmo hash Join deveu-se a este ser um algoritmo clássico já presente na grande maioria dos SGBDs comerciais, o que poderia facilitar a sua adaptação para o contexto da mídia SCM. Ressaltamos que os demais algoritmos (p.e., nested-loop, merge) poderiam também obter benefícios quando adaptados para SCM. 3. Trabalhos Relacionados na Área Em [Graefe et al. 2010], foram idealizados dois operadores (flash scan e flash join) que operam em mídia SCM, porém além da abordagem limitar-se apenas ao uso do layout baseado em colunas, durante a execução da junção é gerado um índice temporário, 11

6 o que pode ocasionar prejuízos no desempenho devido às escritas adicionais. Esse modo de operação pode ocasionar mais escritas na mídia SCM, fazendo com que o desempenho seja degradado quanto maior for o tamanho das relações participantes na junção, não apresentando bom desempenho para predicados de baixa seletividade. Em [Tsirogiannis et al. 2009], discute-se estruturas de dados que aproveitam a baixa latência de leitura dos SSDs para acelerar as operações de seleção, projeção e junção. Estas estruturas utilizam o layout baseado em colunas aliado à menor granularidade da unidade de leitura (páginas) dos SSDs para aumentar o desempenho das consultas. Em [Do and Patel 2009], são revistas algumas das principais lições aprendidas, nas últimas três décadas, relacionadas ao projeto de algoritmos utilizados em projetos de banco de dados. Este trabalho gera indícios de que muitas técnicas já utilizadas em HDDs podem ser reaproveitadas em SSDs, mesmo que devido a motivações diferentes. Como exemplo, podemos citar a E/S baseada em blocos, muito utilizada nos HDDs, e que também se faz de fundamental importância nos dispositivos SSDs. Em [Clementsen and He 2010] existem técnicas de grande relevância para o desenvolvimento deste trabalho, voltadas para aspectos de particionamento vertical e para a otimização de técnicas de Hashing. 4. Estado Atual do Trabalho Atualmente estamos aprimorando a proposta através da realização de experimentos com outros SGBDs (Oracle e PostgreSql), visando observar o comportamento dos algoritmos de junção clássicos quando estes são executados sobre dados armazenados em SCM. Adicionalmente, estamos estudando a incorporação do SCM Join no PostgreSql de modo a realizarmos os experimentos comparativos e a avaliação dos resultados. References Abadi, D. J., Madden, S., and Ferreira, M. (2006). Integrating compression and execution in column-oriented database systems. In Chaudhuri, S., Hristidis, V., and Polyzotis, N., editors, SIGMOD Conference, pages ACM. Clementsen, D. S. and He, Z. (2010). Vertical partitioning for flash and hdd database systems. J. Syst. Softw., 83(11): Do, J. and Patel, J. M. (2009). Join processing for flash ssds: remembering past lessons. In Proceedings of the Fifth International Workshop on Data Management on New Hardware, DaMoN 09, pages 1 8, New York, NY, USA. ACM. Graefe, G., Harizopoulos, S., Kuno, H. A., Shah, M. A., Tsirogiannis, D., and Wiener, J. L. (2010). Designing database operators for flash-enabled memory hierarchies. IEEE Data Eng. Bull., 33(4): Graefe, G. and Shapiro, L. D. (1991). Data compression and database performance. In In Proc. ACM/IEEE-CS Symp. On Applied Computing, pages Nath, S. and Kansal, A. (2007). Flashdb: dynamic self-tuning database for nand flash. In Abdelzaher, T. F., Guibas, L. J., and Welsh, M., editors, IPSN, pages ACM. Tsirogiannis, D., Harizopoulos, S., Shah, M. A., Wiener, J. L., and Graefe, G. (2009). Query processing techniques for solid state drives. In Çetintemel, U., Zdonik, S. B., Kossmann, D., and Tatbul, N., editors, SIGMOD Conference, pages ACM. 12