postgreSQL vs Cassandra vs MongoDB vs Voldemort?

Question

Qual banco de dados decidir? Alguma comparação?

• Existente: postgresql
  
• problemas     
  • Não é escalável horizontalmente. Precisa sharding etc
        
  • O cluster não resolve o problema de crescimento de dados
      
  
• Procurando por: qualquer banco de dados que seja facilmente dimensionável horizontalmente     
  • Cassandra (o Twitter usa isso?)
        
  • MongoDB (ganhando popularidade rapidamente)
        
  • Voldemort
        
  • Outro?
      
  
• Por quê?     
  • Dados crescendo com efeito de bola de neve
        
  • tabela de bloqueios postgresql existente etc para tarefas de vácuo periodicamente
        
  • Atualmente, os dados de arquivamento são limitados
        
  • Interação humana envolvida em arquivo existente, vácuo, ... processo periodicamente
        
  • Precisa de um 'set it. esqueça. basta adicionar outro servidor quando os dados aumentarem mais. tipo de solução
      

Answer 1

Primeira pergunta: Por que você está em um banco de dados relacional para começar, se você não precisa de propriedades ACID? Parece que você está fazendo algum tipo de trabalho não transacional, portanto, obter um RDMBS com transações provavelmente é muito pesado para seu ambiente.

Segunda pergunta: Que tipo de dados você está armazenando? Parece que você precisa de um banco de dados de armazenamento de colunas e que é para algum tipo de projeto de data warehouse.

Terceira pergunta: Se você está preso ao PostgreSQL (que é um bom banco de dados como está), é a versão atual? Versões antigas anteriores a 8.x são notoriamente lentas, mas muito de trabalho foi aprimorado desde então, e alguns dos problemas que você mencionou - como o autovacuum - agora são facilmente abordados com "set-and-set". Esqueça "configurações.

*  Data growing with snowball effect

Algumas informações adicionais sobre isso seriam boas. Por que é bola de neve? Você pode normalizá-lo para reduzir o armazenamento?

* existing postgresql locks table etc for vaccuum tasks periodically

Se isso for um problema, já posso dizer que você está executando uma versão mais antiga. As versões mais recentes têm controles por tabela para isso e você pode até desligá-lo totalmente.

* Archiving data is tideous currently

É difícil fazer qualquer tipo de julgamento aqui porque não há muito com o que trabalhar. Qual mídia o arquivo está sendo despejado? Quanta E / S sustentada está envolvida? Em que período de tempo você está operando? Quantos dados? Precisa ser um depósito "quente" ou pode ser "frio"?

* Human interaction involved in existing archive, vaccuum, ... process periodically

Estou tentando ver como o uso "normal" exigiria intervenção manual, porque não deveria. O vácuo é automático agora e (como mencionado antes) pode ser configurado para não ocorrer, e a maioria dos backups é feita em script (e quando você pode criar scripts, pode agendar). Então, como isso ocorre?

* Need a 'set it. forget it. just add another server when data grows more.' type of solution

Você está falando sobre um acordo de servidor em cluster.

Parece-me o seguinte:

1. Você está em um RDBMS e a natureza transacional não é adequada para seu aplicativo.
2. Seu aplicativo parece querer um estilo de banco de dados principalmente lido. Também não parece que você precisa ter integridade transacional.
3. O volume de dados que você está lidando provavelmente não está normalizado, e nenhuma tentativa foi feita para normalizá-lo.
4. Você está fazendo muito a mão waaaaaay e precisa de mais automação.
5. Você gosta da ideia de uma solução em cluster, possivelmente computação em "estilo de nuvem".

Além disso, não há informações suficientes aqui para descobrir o que seria um bom ajuste.

    

Answer 2

Você pode considerar também o HBase e o HyperTable; mas, novamente, como Avery Payne mencionou, você não nos dá nenhuma informação sobre sua aplicação atual, apenas sua plataforma de banco de dados.

Algumas coisas para ter em mente:

As junções são feitas manualmente nas plataformas não-SQL. Eles não farão coisas como chaves estrangeiras, agregados, etc. Tudo isso é manual.

As aplicações existentes não são necessariamente fáceis de portar. Dependendo do custo de sua portabilidade, pode ser mais econômico escalar seu servidor PostgreSQL verticalmente (em vez de horizontalmente).

Você não obtém ACID e precisa gerenciar manualmente a simultaneidade. Dependendo da sua aplicação, isso pode ser um problema. Você também não pode impor regras de conservação globais da maneira tradicional, novamente devido à falta de atomicidade.

    

Answer 3

O Cassandra é a melhor opção onde você sabe que precisa escalar.

Eu recomendaria alguns dos artigos de Estudos de caso do link

    

Answer 4

O que você pode fazer para resolver alguns dos seus problemas é:

• O postgresql existente bloqueia a tabela etc para tarefas de vácuo periodicamente

A tabela não está bloqueada, apenas apresenta um desempenho lento. Isso é feito pelo postgresql para evitar a invasão do ID da transação. Você pode reduzir a frequência escrevendo várias linhas em lotes e, em seguida, confirmar. Você poderia usar uma fila (como rabbitmq) para gravações intermediárias: application- > queue- > db. Isso também aumentará muito seu desempenho de gravação.

• Atualmente, os dados de arquivamento são limitados

Se os seus dados forem muito grandes nas ordens de vários TB, sugiro que você mude para a nuvem, porque o despejo não é uma opção. Use o AWS ou o Google Cloud e use instantâneos. Por exemplo. Os snapshots do EBS, que são muito rápidos, são replicados em todos os continentes e resolvem a necessidade de backup.

Se por arquivamento você quer dizer excluir dados e mover para um "arquivo", use os espaços de tabela, que são rotacionados por data. Existem algumas implementações online para isso.