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.
Pra quem não se deu ao trabalho de entender, o enredo é o seguinte. Estou numa janela de comandos do Windows e num diretório que contém um arquivo chamado file.txt contendo oito bytes. Daí eu invoco o comando de linha "ftp" e me conecto a um servidor remoto. Verifico que não existe no servidor FTP um arquivo com o mesmo nome e me engano usando o comando "get file.txt" ao invés do "put file.txt".
