Banco de dados de alto desempenho, rápido e durável?

2

Até recentemente eu estava usando o mongo para tentar conter grandes atualizações do MySQL para servidores de sistema, no entanto, depois de ler isto:

link

Parei a produção de uma versão do mongo do meu site até que o mongo ganhasse mais estabilidade.

Alguns sugeriram que eu usasse o _change dentro do couche DB para criar um novo objeto mongo que resolveria os principais problemas dentro do mongo db atm, mas não tenho certeza sobre isso.

Eu examinei outros DBs, como redis e Cassandra, mas deixei Cassandra como você tem que projetar para suas consultas e isso é muito restrito para o meu site (modulização ruim). Eu não estou realmente procurando por junções etc, eu só estou olhando para a capacidade de pesquisar dentro de uma linha em vez de apenas o id da família columnf como ele pode tornar a programação bastante difícil ao tentar adicionar nova funcionalidade. Seria ótimo para um mecanismo de busca ou algo assim, mas não tão bom para um site real como o facebook em sua totalidade (em vez de apenas em sua pesquisa por email).

Eu queria saber quais experiências as pessoas aqui tiveram com a tentativa de obter uma solução viável para os problemas de velocidade do SQL. Existe um bullet bullet prata para tudo ou é apenas um caso de cerrar os dentes com o MySQL ou outro banco de dados SQL se você quer confiabilidade?

Talvez um cruzamento entre uma forma de cache e SQL (notei que o facebook usa cache pesado em suas páginas de parede, etc ... provavelmente por que).

Obrigado,

    
por Sammaye 09.07.2010 / 12:06

2 respostas

0

Você não deu nenhuma ideia da escala do seu site, o que faz uma enorme diferença em qual tecnologia / método é apropriado.

De qualquer forma, nada será uma bala mágica. A maioria das coisas que você está mencionando são sobre como tornar possível o escalonamento grande em vez de evitar o dimensionamento.

Mesmo usando algo como memcached na frente do banco de dados, é necessário um modo de pensar um pouco diferente para obter o máximo benefício dele. Uma das primeiras coisas que você precisa fazer (e pode haver grandes economias, se ainda não tiver feito isso) é analisar e otimizar o tipo de consultas que você está fazendo.

    
por 09.07.2010 / 13:15
0

Qual é o seu problema com o Mongo exatamente? Você precisará fazer backups de qualquer maneira. Agora ele suporta conjuntos de réplicas para que você não esteja realmente preso a uma falha de máquina.

Se você estiver usando 25 servidores agora, poderá executar facilmente um conjunto de réplicas de alguns servidores e não ter um único ponto de falha.

10 a 30 milhões de linhas não são muito. Especialmente desde que com uma solução noSQL você provavelmente pode consolidar algumas linhas em registros únicos. Se você tem 2 milhões de usuários, é possível que a maioria dos dados se encaixe em registros únicos. (4 mb limite é muito)

    
por 01.09.2010 / 03:05