Semana passada assisti a uma palestra do Eduardo Sato da Sybase na qual ele explicou a tecnologia por trás do Sybase IQ, um banco de dados relacional usado em ambientes analíticos, como data warehousing e aplicações de Business Intelligence em geral.
A tecnologia em questão se chama column-oriented DBMS e é essencialmente uma forma não-tradicional de armazenar os dados das tabelas em disco. Normalmente, os dados de uma tabelas são armazenadas por linhas, i.e., todos os campos de uma linha são armazenados de maneira contígua no disco. Já num SGBD orientado a colunas os dados de uma tabela são armazenados por coluna, i.e., todos os campos de uma coluna da tabela são armazenados de maneira contígua.
Essa diferença aparentemente trivial modifica totalmente as características de desempenho do banco de dados. O armazenamento por linhas é ideal para acessos de linha inteira. Pense num insert ou num update que modifique todos os campos da linha. Ou mesmo, num select *. De fato, a forma de armazenamento por linha é a que garante melhor desempenho para a maioria das aplicações transacionais.
Agora pense num ambiente analítico, no qual os inserts e updates são quase inexistentes e a maioria absoluta das consultas são de selects. Normalmente, as tabelas usadas nestes ambientes são "tabelões", com um grande número de colunas, resultado da agregação de várias tabelas extraídas de sistemas transacionais, planilhas e arquivos texto. Além disso, em ambientes analíticos é comum ocorrerem consultas ad hoc para as quais não se pode planejar a manutenção de índices e que acabam resultando muitas vezes na necessidade de full scans nas tabelas para executar a consulta.
O exemplo concreto que o Eduardo Sato usou na palestra pra explicar os ganhos que podem ser obtidos envolvia uma tabela com 10 milhões de linhas de 800 bytes cada uma. Considerando uma representação em disco usando páginas de 16KB, pra fazer um full scan nesta tabela seriam necessários 500 mil I/Os. Se esse full scan tivesse sido motivado por um select envolvendo apenas três colunas da tabela, usando uma representação em colunas poderia reduzir o número de I/Os para apenas 234. (Não é 234 mil. É 234 unidades!)
Além do ganho de eficiência nos selects, a representação em colunas também consegue ser mais compacta que a representação em linhas. Uma razão é que os campos NULL podem ser indicados pela mera ausência, ao passo que na representação em linhas eles precisam ser indicados por um código explícito. Outra razão é que é muito mais fácil compactar dados de um tipo único que dados de múltiplos tipos, como ocorre na representação em linhas.
Ainda outra vantagem da representação em colunas é que as alterações de esquema são muito mais fáceis e rápidas. Afinal é muito mais fácil inserir, remover ou alterar uma coluna quando ela está armazenada de forma contígua que quando seus dados estão "espalhados" pelas linhas da tabela.
O Sybase IQ não é a única implementação desta tecnologia. A página da wikipedia mostra uma lista de implementações concorrentes. Achei duas promissoras: o MonetDB e o Vertica.
A tecnologia em questão se chama column-oriented DBMS e é essencialmente uma forma não-tradicional de armazenar os dados das tabelas em disco. Normalmente, os dados de uma tabelas são armazenadas por linhas, i.e., todos os campos de uma linha são armazenados de maneira contígua no disco. Já num SGBD orientado a colunas os dados de uma tabela são armazenados por coluna, i.e., todos os campos de uma coluna da tabela são armazenados de maneira contígua.
Essa diferença aparentemente trivial modifica totalmente as características de desempenho do banco de dados. O armazenamento por linhas é ideal para acessos de linha inteira. Pense num insert ou num update que modifique todos os campos da linha. Ou mesmo, num select *. De fato, a forma de armazenamento por linha é a que garante melhor desempenho para a maioria das aplicações transacionais.
Agora pense num ambiente analítico, no qual os inserts e updates são quase inexistentes e a maioria absoluta das consultas são de selects. Normalmente, as tabelas usadas nestes ambientes são "tabelões", com um grande número de colunas, resultado da agregação de várias tabelas extraídas de sistemas transacionais, planilhas e arquivos texto. Além disso, em ambientes analíticos é comum ocorrerem consultas ad hoc para as quais não se pode planejar a manutenção de índices e que acabam resultando muitas vezes na necessidade de full scans nas tabelas para executar a consulta.
O exemplo concreto que o Eduardo Sato usou na palestra pra explicar os ganhos que podem ser obtidos envolvia uma tabela com 10 milhões de linhas de 800 bytes cada uma. Considerando uma representação em disco usando páginas de 16KB, pra fazer um full scan nesta tabela seriam necessários 500 mil I/Os. Se esse full scan tivesse sido motivado por um select envolvendo apenas três colunas da tabela, usando uma representação em colunas poderia reduzir o número de I/Os para apenas 234. (Não é 234 mil. É 234 unidades!)
Além do ganho de eficiência nos selects, a representação em colunas também consegue ser mais compacta que a representação em linhas. Uma razão é que os campos NULL podem ser indicados pela mera ausência, ao passo que na representação em linhas eles precisam ser indicados por um código explícito. Outra razão é que é muito mais fácil compactar dados de um tipo único que dados de múltiplos tipos, como ocorre na representação em linhas.
Ainda outra vantagem da representação em colunas é que as alterações de esquema são muito mais fáceis e rápidas. Afinal é muito mais fácil inserir, remover ou alterar uma coluna quando ela está armazenada de forma contígua que quando seus dados estão "espalhados" pelas linhas da tabela.
O Sybase IQ não é a única implementação desta tecnologia. A página da wikipedia mostra uma lista de implementações concorrentes. Achei duas promissoras: o MonetDB e o Vertica.
Nenhum comentário:
Postar um comentário