Como os bancos de dados colunares são mais rápidos para consultas?

Geralmente, há três razões principais pelas quais o armazenamento de dados colunar é preferido para cargas de trabalho de data warehousing e análise:

1. O armazenamento de colunas normalmente é compactado melhor do que o armazenamento de linhas porque os valores são todos do mesmo tipo de dados e geralmente têm valores semelhantes. A compactação aprimorada pode beneficiar o armazenamento na memória e o armazenamento persistente.

2. As consultas geralmente selecionam apenas algumas colunas de uma tabela. Em vez de buscar a linha inteira do armazenamento na memória, apenas as colunas necessárias são carregadas. Isso reduz ainda mais a E/S e o uso de memória.

3. As CPUs modernas são muito mais rápidas que a memória principal. Melhorias significativas de desempenho podem ser encontradas fazendo melhor uso dos caches no chip relativamente pequenos, mas de alta velocidade, e usando instruções vetoriais de CPU como SIMD em dados semelhantes. Preencher linhas de cache com dados de coluna geralmente é mais eficiente do que carregar linhas inteiras, onde muitos dos valores não são necessários para a consulta.

O armazenamento de linha é preferido para cargas de trabalho transacionais, onde pequenos números de registros podem ser encontrados rapidamente com buscas de árvore b. Também há benefícios de gravação porque uma única linha pode ser gravada de uma só vez, enquanto o armazenamento colunar precisa atualizar diversas estruturas separadamente e geralmente tem uma sobrecarga de CPU maior para compactação.

No meu entender, as pessoas preferem bancos de dados colunares porque são mais rápidos para consultas devido ao fato de que a CPU seria capaz de armazenar em cache os próximos valores de forma previsível.

Meu entendimento nesta área é que bancos de dados colunares são mais rápidos para determinados padrões de acesso , devido a uma única coluna de dados ser sequencial no armazenamento (ou seja, em disco).

Um caso específico que ouvi ser mais eficiente é quando a carga de trabalho principal agrega subintervalos de dados de séries temporais - como pode ser típico de certos tipos de análise financeira.

Não entendo todos os detalhes das implementações ou suas áreas de aplicação, mas suspeito que não haja uma razão simples e decisiva pela qual os bancos de dados colunares sejam mais rápidos para determinadas cargas de trabalho, mas sim uma série de melhorias marginais em diferentes camadas e funções do implementação do banco de dados quando sob carga simultânea.

No entanto, os bancos de dados colunares são definitivamente para aplicações especiais e não são mais rápidos em geral para cargas OLTP.

Como os bancos de dados colunares são mais rápidos para consultas?

Eles não são, holisticamente falando. Eles apenas oferecem uma maneira diferente de armazenar dados e, quando usados ​​corretamente, podem ser eficientes para casos de uso específicos. Bancos de dados específicos não colunares podem ser usados ​​de maneira igualmente eficiente quando usados ​​adequadamente.

Por que tantas pessoas preferem bancos de dados colunares?

Em mais de uma década de minha carreira, raramente encontrei alguém que tivesse alguma preferência específica por bancos de dados colunares em vez de bancos de dados específicos não-colunares. (Observe que continuo usando esse termo especificamente porque existem sistemas de banco de dados focados em rowstore que também oferecem armazenamento de dados colunar sobre a tabela rowstore*, como o Microsoft SQL Server.)

No meu entender, as pessoas preferem bancos de dados colunares porque são mais rápidos para consultas devido ao fato de que a CPU seria capaz de armazenar em cache os próximos valores de forma previsível.

Eu não acredito que isso esteja correto. Nunca ouvi falar disso antes e, honestamente, estou tendo dificuldade em conceituar o significado disso.

Se a aceleração vier do cache, os bancos de dados baseados em linhas não seriam tão eficazes para consultas?

Claro. Os sistemas de banco de dados rowstore típicos aproveitam a memória para armazenar em cache automaticamente os dados comumente usados ​​para melhorar o desempenho.

As poucas pessoas com quem conversei que estavam interessadas em bancos de dados colunares específicos eram pessoas que pareciam não entender como os bancos de dados funcionam tão bem e estavam tentando migrar seus fluxos de trabalho OLTP para algo como o Snowflake, o que é bobagem. Suspeito que você tenha conversado com pessoas que pensam da mesma forma. Não me interpretem mal, não há nada explicitamente errado com um banco de dados colunar, mas eles não têm um desempenho magicamente melhor do que um sistema de banco de dados rowstore, assim como o NoSQL também não é automaticamente mais rápido. E quando usado de forma inadequada, você passará por momentos difíceis, independentemente do tipo de sistema que escolher.

_{* O SQL Server 2014 e versões posteriores também oferecem armazenamento colunar como armazenamento primário (“clustered columnstore”) onde nenhum rowstore subjacente é usado). A partir do SP1 2016, todas as edições oferecem suporte ao columnstore. Antes disso, a Enterprise Edition era necessária.}