Quais devem ser as considerações para escolher SQL/NOSQL? [fechado

Question

O Target Application é um site de médio porte criado para suportar várias centenas a vários milhares de usuários por hora, com a opção de escalar acima disso. O modelo de dados é bastante simples e o potencial de cache é bastante alto (~ 10: 1 proporção de leitura para editar ações).

Quais devem ser as considerações ao escolher entre um armazenamento de dados relacionais baseado em SQL para uma opção NoSQL (como HBase e Cassandra)?

Answer 1

Para mim, você não tem nenhum problema em particular para resolver. Se você precisar de acidez, use um banco de dados; Se não, então não importa. No final, basta construir seu aplicativo. E deixe -me citar NoSQL: se fosse tão fácil tão fácil:

O verdadeiro a apontar é que, se você está sendo impedido de fazer algo super incrível porque não pode escolher um banco de dados, está fazendo errado. Se você conhece o MySQL, basta usá -lo. Otimize quando você realmente precisar. Use -o como AK/V Store, use -o como um RDBMS, mas, pelo amor de Deus, construa seu aplicativo assassino! Nada disso será importante para a maioria dos aplicativos. O Facebook ainda usa muito o MySQL. A Wikipedia usa muito o MySQL. FriendFeed usa MySQL, muito. O NOSQL é uma ótima ferramenta, mas certamente não será sua vantagem competitiva, não vai deixar seu aplicativo quente e, acima de tudo, seus usuários não darão a mínima para nada disso.

Answer 2

Digg tem alguns interessante Artigos sobre esta pergunta. Essencialmente, você está mudando o ônus do processamento para gravar, em vez de leituras, o que pode ser desejável em aplicativos altamente escaláveis. Cassandra também está altamente disponível.

Simplicamente, o Cassandra é um banco de dados distribuído com um modelo de dados BigTable em execução em um dínamo como a infraestrutura. É orientado para a coluna e permite o armazenamento de dados relativamente estruturados. Possui um modelo totalmente descentralizado; Cada nó é idêntico e não há um único ponto de falha. Também é extremamente tolerante a falhas; Os dados são replicados para vários nós e entre data centers. Cassandra também é muito elástico; Leia e escreva a taxa de transferência aumenta linearmente à medida que novas máquinas são adicionadas.

Answer 3

Gostei da regra de polegar de Ian Eure: "Se você está implantando o Memcache no topo do seu banco de dados, está inventando seu próprio sistema ad-hoc, difícil de manter o sistema NOSQL".

http://www.rackspacecloud.com/blog/2010/02/25/should-you-switch-tonsql-too/

Answer 4

Quando você diz, o Data Modell é bastante simples, isso pode falar pela opção NoSQL.

Quando você tem muitos atributos para fazer seleções, carga de transação pesada ou estruturas de tabela complicadas, que falavam pelas tabelas SQL tradicionais.

Eu recomendaria descobrir como seria difícil implementar o Data Modell com um ou dois bancos de dados NoSQL. Quando isso é bastante difícil, você também pode fazer com que um esquema de tabela clássico se compare.

Quando você tem dificuldades com o NoSQL, isso pode falar pela opção SQL. Mas também pode ser que a carga pesada seja melhor tratada com o NOSQL - mas também pode ser que um bom banco de dados SQL escala o suficiente ...

O buffer também pode ser feito com um simples servidor de proxy ...

Em dificuldades, uma mistura de NoSQL e SQL também pode ser considerada.