O que torna os bancos de dados colunares adequados para a ciência de dados?
Respostas:
Um banco de dados orientado a colunas (= armazenamento de dados colunar) armazena os dados de uma tabela coluna por coluna no disco, enquanto um banco de dados orientado a linhas armazena os dados de uma tabela linha por linha.
Há duas vantagens principais de usar um banco de dados orientado a colunas em comparação com um banco de dados orientado a linhas. A primeira vantagem está relacionada à quantidade de dados que uma pessoa precisa ler, caso realizemos uma operação com apenas alguns recursos. Considere uma consulta simples:
SELECT correlation(feature2, feature5)
FROM records
Um executor tradicional lê a tabela inteira (ou seja, todos os recursos):
Em vez disso, usando nossa abordagem baseada em colunas, apenas precisamos ler as colunas que estão interessadas em:
A segunda vantagem, que também é muito importante para grandes bancos de dados, é que o armazenamento baseado em colunas permite uma melhor compactação, pois os dados em uma coluna específica são realmente homogêneos do que em todas as colunas.
A principal desvantagem de uma abordagem orientada a colunas é que manipular (pesquisar, atualizar ou excluir) uma linha inteira é ineficiente. No entanto, a situação deve ocorrer raramente nos bancos de dados para análise ("armazenamento"), o que significa que a maioria das operações é somente leitura, raramente lê muitos atributos na mesma tabela e as gravações são apenas anexos.
Alguns RDMS oferecem uma opção de mecanismo de armazenamento orientado a colunas. Por exemplo, o PostgreSQL não possui originalmente nenhuma opção para armazenar tabelas de maneira baseada em colunas, mas o Greenplum criou uma de código fechado (DBMS2, 2009). Curiosamente, o Greenplum também está por trás da biblioteca de código-fonte aberto para análises escaláveis no banco de dados, MADlib (Hellerstein et al., 2012), o que não é coincidência. Mais recentemente, o CitusDB, uma startup que trabalha em bancos de dados analíticos de alta velocidade, lançou sua própria extensão de armazenamento colunar de código-fonte aberto para PostgreSQL, CSTORE (Miller, 2014). O sistema do Google para aprendizado de máquina em larga escala Sibyl também usa o formato de dados orientado a colunas (Chandra et al., 2010). Essa tendência reflete o crescente interesse em torno do armazenamento orientado a colunas para análises em grande escala. Stonebraker et al. (2005) discutem ainda mais as vantagens do DBMS orientado a colunas.
Dois casos de uso concretos: como a maioria dos conjuntos de dados para aprendizado de máquina em larga escala é armazenada?
(a maior parte da resposta vem do Apêndice C de: BeatDB: uma abordagem de ponta a ponta para revelar saliências de conjuntos de dados de sinal massivos. Franck Dernoncourt, SM, tese, Departamento de EECS do MIT )
Depende do que você faz.
Os armazenamentos de colunas têm dois benefícios principais:
- colunas inteiras podem ser puladas
- a compactação de execução funciona melhor em colunas (para determinados tipos de dados; em particular com poucos valores distintos)
No entanto, eles também têm desvantagens:
- muitos algoritmos precisarão de todas as colunas e só gravarão de cada vez (por exemplo, k-means) ou podem até precisar calcular uma matriz de distância em pares
- técnicas de compactação funcionam bem apenas em tipos e fatores de dados esparsos, mas não em dados contínuos de valor duplo
- anexos em lojas de colunas são caros, portanto, não é ideal para transmitir / alterar dados
O armazenamento colunar é realmente popular para OLAP, também conhecido como "análise estúpida" (Michael Stonebraker) e, claro, para pré-processamento, onde você pode realmente estar interessado em descartar colunas inteiras (mas você precisaria ter dados estruturados primeiro - você não armazena JSONs em colunas) formato). Porque o layout colunar é realmente bom para, por exemplo, contar quantas maçãs você vendeu na semana passada.
Para grande parte dos casos de uso de ciência / dados científicos, os bancos de dados de matriz parecem ser o caminho a seguir (além, é claro, de dados não estruturados de entrada). Por exemplo, SciDB e RasDaMan.
Em muitos casos (por exemplo, aprendizado profundo), matrizes e matrizes são os tipos de dados que você precisa, não colunas. O MapReduce etc. ainda pode ser útil no pré-processamento, é claro. Talvez até os dados da coluna (mas o banco de dados da matriz geralmente também suporte uma compactação do tipo coluna).
Não usei um banco de dados colunar, mas usei um formato de arquivo colunar de código aberto chamado Parquet, e acho que os benefícios provavelmente são os mesmos - processamento mais rápido de dados quando você só precisa consultar um pequeno subconjunto de um grande numero de colunas. Eu tinha uma consulta em execução em cerca de 50 terabytes de arquivos Avro (um formato de arquivo orientado a linhas) com 673 colunas que levavam cerca de uma hora e meia em um cluster Hadoop de 140 nós. Com o Parquet, a mesma consulta levou cerca de 22 minutos, porque eu precisava apenas de 5 colunas.
Se você tivesse um pequeno número de colunas ou estivesse usando uma grande proporção de suas colunas, não acho que um banco de dados colunar faria muita diferença em relação a um orientado a linhas, porque você ainda precisaria basicamente varrer todos os seus dados. Acredito que os bancos de dados colunares armazenam colunas separadamente, enquanto os bancos de dados orientados a linhas armazenam linhas separadamente. Sua consulta será mais rápida sempre que você conseguir ler menos dados do disco.
Este link explica mais detalhes.
Nota: Esta é a minha pergunta e sou muito grato pelas respostas maravilhosas aqui, que me ajudaram a entender o conceito.
Então, eu explicaria o conceito da maneira que entendi:
Geralmente, os dados nos bancos de dados são armazenados na memória nos seguintes formatos:
Considere este dado:
X1 X2
1 0.7091409 -1.4061361
2 -1.1334614 -0.1973846
3 2.3343391 -0.4385071
Em um armazenamento baseado em linha relacional, ele é armazenado assim:
1, 0.7091409, -1.4061361, 2, -1.1334614, -0.1973846, 3, 2.3343391, -0.4385071
na forma de linhas.
No armazenamento colunar, ele seria armazenado assim:
1, 2, 3, 0.7091409 ,-1.1334614, 2.3343391, -1.4061361, -0.1973846, -0.4385071
na forma de colunas.
Então o que isso quer dizer?
Isso significa que a inserção (e a atualização) e as exclusões são rápidas no armazenamento de colunas com base em linhas, pois é apenas a remoção dos últimos valores ou dos primeiros. No entanto, não é o caso em armazenamentos colunares, pois o valor em cada armazenamento de bloco precisa ser removido.
No entanto, quando há a necessidade de agregados e operações em colunas, os armazenamentos em colunas têm uma vantagem sobre suas contrapartes baseadas em linhas, pois eles são armazenados em colunas e, como resultado, o acesso a colunas individuais é muito fácil.