Cassandra vs postgresql

Com a introdução do Postgres XL, ele voltou a aparecer e testes recentes mostram que está superando muitos motores NoSql como o Mongodb com bastante facilidade. Embora Cassandra ainda seja um dos DB de melhor desempenho.

No postgres XL, você tem um bom suporte de chaves relacionais, SQL e é fácil de implementar com os recursos SQL existentes, mas o uso do Cassandra na ausência de junções etc. é um pouco diferente e precisa aumentar as habilidades, pois precisam de implementação muito diferente.

Porém, ao considerar qualquer coisa para Big Data, é sempre importante considerar a escalabilidade vertical em Postres, mas horizontal em Cassandra. É aqui que Cassandra tem vantagem sobre o Postgres.

Para implementação na web, o Postgres suporta vários idiomas do lado do servidor que faltam no Cassandra. Além disso, a lógica de negócios pode ser implementada no Postgres usando procedimentos que não podem ser feitos no Cassandra.

Está comparando maçãs e aviões.

O Postgres é um RDBMS relacional com conformidade com ANSI SQL. A versão pura de código-fonte aberto não possui recursos de cluster, mas existem várias implementações comerciais (Greenplum, Netezza (empresa), Actian Matrix).

Cassandra é um armazenamento de família de colunas de valor-chave que usa uma linguagem semelhante ao SQL para ler e gravar dados. É uma arquitetura inerentemente distribuída que fragmenta com base na chave. Falta a capacidade de fazer coisas no RDBMS tradicional, como transformar dados. Você notará que não há nenhuma função SUM () ou uma maneira de juntar dados através de "tabelas" no Cassandra (

CQL

)

A comparação aqui é literalmente entre dois bancos de dados muito diferentes. Tudo depende da intenção de uso. Tudo se resumia às necessidades da sua aplicação. Embora a matriz de comparação seja enorme quando você estiver fazendo esse tipo de comparação disjunta, tentarei fazer justiça a alguns dos pontos-chave específicos aqui.

Transações

O PostgreSQL é um banco de dados relacional com fortes garantias de transação. Se o seu aplicativo precisar de forte suporte transacional, pode ser o candidato certo.

O Cassandra, por outro lado, fornece transações leves, limitadas ao isolamento no nível da linha. Também não há capacidade de reversão, etc.

Como as transações do Cassandra são diferentes das transações do RDBMS?

Isso pode ter algum viés do Datastax na comparação, mas ainda é uma avaliação justa.

Escala

Nenhum banco de dados SQL como o Cassandra é projetado em arquitetura com escala além de um único nó como critério principal de design. Portanto, se o aplicativo precisar ser dimensionado além de um único nó (geralmente uma grande porcentagem de pessoas é otimista o suficiente para pensar que seu aplicativo seria dimensionado além do nó único, normalmente não é o caso, a maioria dos aplicativos pode caber em uma máquina em termos de suas necessidades rendimento ou conjunto de trabalho.

Comparação de instâncias do Amazon EC2

Por exemplo, um r4.2xlarge com 61 GB de RAM pode manter o conjunto de trabalho para a maioria dos aplicativos. Pode-se optar por ir com as instâncias suportadas pelo EBS se a escala for necessária no armazenamento, etc.

A vantagem de trabalhar com um único nó é a facilidade de gerenciamento do banco de dados, especialmente o gerenciamento de pontos problemáticos de um banco de dados fragmentado. (

Por que você não quer estilhaçar.

)

Mas, novamente, se você é o próximo Netflix, bancos de dados como o Cassandra realmente brilham. Os critérios de escala na lista seriam o fator decisivo para se trabalhar.

Para não perder, o PostgreSQL também pode ser escalado além do nó único, mas a escala em termos de Big Data em hardware comum é bem feita com os bancos de dados No SQL. Veja no PostgresXL como você pode usar um cluster de vários nós com o PostgreSQL.

Cluster de Banco de Dados SQL Escalável de Código Aberto

Se a intenção é armazenar PB de dados, o Cassandra pode ser um candidato melhor em comparação com o PostgreSQL. Mas, novamente, se apenas alguns GB do PB são acessados ​​pelo aplicativo, pode-se pensar em uma arquitetura de dados em que o Hot Data é acessado através do PostgreSQL e os dados frios são armazenados em alguma loja de baixo custo como o S3

Amazon Simple Storage Service (S3) - Armazenamento em nuvem - AWS

ou geleira

Amazon Glacier - Arquivo em nuvem

(Em uma nota lateral, aqui é uma conversa muito boa sobre armazenamento de dados

Esta é uma das minhas folhas de dicas de armazenamento favoritas

Latência

A latência é geralmente definida pelas necessidades específicas do aplicativo. Por exemplo, se o aplicativo tiver muita leitura nas cargas de trabalho, manter os dados inteiramente na memória faria mais sentido; se o aplicativo tiver muita gravação, como armazenar informações de log de fluxo otimizando leituras, não seria preferido. Outro aspecto da latência é que não é um número único alvo. Latência de uma única solicitação é o que você talvez não esteja vendo quando realmente prefere uma boa promessa de latência com alto rendimento

Por exemplo, como é o perfil de latência quando há 10000 solicitações atingindo o nó.

Se considerarmos apenas o design do Cassandra, podemos vê-lo otimizado para gravações. A abordagem baseada em árvores LSM, adotada por Cassandra, usa gravações imutáveis, evita atualizações no local e modifica gravações no fluxo sequencial de modificações no disco.

A árvore de mesclagem estruturada em log (árvore LSM)

Mecanismos relacionais como o PostgreSQL são baseados na abordagem de buffer pool em cache, onde as páginas lidas pelo Mecanismo de Banco de Dados são armazenadas em cache na memória.

Ajustando o servidor PostgreSQL

Mas, novamente, de maneira alguma você deve considerar esses designs pelo valor nominal, pois sua milhagem pode diferir com base no perfil e no uso do aplicativo.

API / modelagem de dados

Cassandra e PostgreSQL têm paradigmas de modelagem de dados muito diferentes. O PostgreSQL, sendo um mecanismo de banco de dados relacional, ditaria as melhores práticas em torno de um bom design normalizado

Normalização de banco de dados - Wikipedia

. Como bancos de dados relacionais como o PostgreSQL suportam JOIN, isso funciona muito bem, evitando redundância e mantendo os dados normalizados, otimizando gravações / atualizações.

A modelagem no Cassandra envolveria o uso de um chapéu de normalização DE e tentaria modelar as entidades de dados para evitar consultas redundantes. O Cassandra não suporta JOINs, portanto, ter dados normalizados em diferentes partições significaria que o aplicativo precisa fazer várias consultas para obter os dados necessários. Isso também pode significar que as garantias de consistência ficariam fracas assim que você deixar o limite da linha no Cassandra.

Resumindo

Resumir essa resposta pode se estender a uma comparação entre o design de banco de dados orientado a SQL e o design de banco de dados relacional. Acesse bem as necessidades do seu aplicativo e tente ver qual solução se encaixa para o aplicativo. Palavras-chave como Big Data fazem uma boa terminologia nas áreas de Marketing, mas como arquiteto de aplicativos é realmente crítico que você entenda como o aplicativo seria usado pelos clientes finais e como ele evoluiria no uso com o Time.