Escolher uma tecnologia de banco de dados

Question

Estamos preparando para criar uma plataforma on -line (API, servidores, dados, Wahoo!). Para contexto, imagine que precisamos construir algo como o Twitter, mas com os comentários (tweets) organizados em torno de um evento ao vivo. As informações sobre o evento ao vivo devem ser entregues aos clientes o mais rápido e consistentemente possível, enquanto os comentários sobre o evento provavelmente podem esperar um pouco mais para serem entregues. Estaremos com a leitura após o término do evento ao vivo.

A escalabilidade é muito importante. Queremos começar a alugar fatias de VPS e escalar a partir daí. Sou um grande fã da nuvem e gostaria de permanecer lá o maior tempo possível. Provavelmente estaremos usando Ruby.

Estou convencido de que quero experimentar uma loja de documentos em vez de um RDBMS. Gosto da idéia de armazenamento sem esquema e das promessas de escalabilidade mais fácil, concentrando-se no valor-chave.

O problema é que não sei qual tecnologia é a mais apropriada para a nossa plataforma. Eu olhei para Couch, Mongo, Gabinete de Tóquio, Cassandra e um RDBMS com documentos Blobbed. Alguma ajuda para escolher a ferramenta certa para este trabalho em particular?

Answer 1

Confira a comparação de alternativas não SQL por BJ Clark.

A escalabilidade é muito importante.

Então você precisa considerar os trechos do blog dele:

1. Gabinete de Tóquio - não escala
2. Redis - não escala
3. Projeto Voldemort - Escalas
4. MongoDB - lamado (o sharding foi implementado)
5. Cassandra - escalas
6. Amazon S3 - Escalas
7. Sofá - Não escala (Clustering & replicação)
8. Mysql - não escala

E considere Hipertável. Este também é um candidato sério em alternativas NO-SQL. É uma implementação de código aberto do conceito BigTable do Google. Acredito que ele escala bem porque é amplamente usado pelo mecanismo de busca chinês Baidu e portal de entretenimento Rediff.

Você estava dizendo:

As informações sobre o evento ao vivo devem ser entregues aos clientes o mais rápido e consistentemente possível, enquanto os comentários sobre o evento provavelmente podem esperar um pouco mais para serem entregues. Estaremos com a leitura após o término do evento ao vivo.

Isso é algo como a abordagem do Twitter. Sua seleção de linguagem de programação também é muito importante, porque o Twitter foi inicialmente com Ruby para entrega de mensagens de back-end, mas Eles estavam dizendo Não é uma escolha correta e eles mudaram todo o sistema de entrega de mensagens para o Scala Língua.

Eles ainda estão usando Ruby para o front-end. Se você deseja ir com um sistema altamente confiável e tolerante a falhas que é adequado para ambientes escaláveis, você deve considerar Scala ou Erlang.

Answer 2

Ramesh tem um bom resumo. Eu acrescentaria que o Cassandra tem um modelo de dados mais rico do que os clones do Dynamo de baunilha (como Voldemort ou Dynomite): linhas com colunas classificadas nomeadas em vez de apenas chave/valor. Cassandra está sendo usada pelo Twitter, Mahalo, Ooyala, Simplegeo, WebEx e outros (http://n2.nabble.com/cassandra-users-survey-td4040068.html), pelo menos alguns dos quais estão executando clusters Cassandra em EC2 ou Rackspace Cloud Servers.

Answer 3

Se você deseja dimensionar horizontalmente (distribua seus dados em mais de um nó), deve levar em consideração o teorema do CAP.

http://www.julianbrowne.com/article/viewer/berewers-cap-theorem

Não é coisa fácil, mas você tem que escolher, sempre há algum tipo de troca.