Porque é que NoSQL é melhor a "escalar" do que RDBMS?
li o seguinte texto num blog técnico a discutir as vantagens e desvantagens do NoSQL
" Por anos, a fim de melhorar o desempenho em servidores de banco de dados, administradores de banco de dados tiveram que comprar muito mais servidores à medida que a carga do banco de dados aumenta (scaling up) em vez de distribuir o banco de dados em várias "hosts" à medida que a carga aumenta (dimensionamento). Os RDBMS normalmente não se expandem facilmente, mas as bases de dados NoSQL mais recentes são na verdade projetado para expandir facilmente para tirar proveito de novos nós e são geralmente projetados com hardware de baixo custo em mente. "
Fiquei confuso sobre a escalabilidade dos RDBMS e NoSQL.a minha confusão é:
-
Porque é que as RDBMS são menos capazes de escalar? E a razão de comprar servidores maiores em vez de comprar mais baratos.
Porque é que o NoSQL é mais capaz de escalar?
4 answers
As RDBMS têm ácido ( http://en.wikipedia.org/wiki/ACID ) e suporta transacções. Escalar "para fora" com RDBMS é mais difícil de implementar devido a estes conceitos.
As soluções NoSQL geralmente oferecem um nível recorde de atomicidade, mas não podem garantir que uma série de operações sejam bem sucedidas (transação).Resume-se a: para manter a integridade dos dados e suportar transacções, um RDBMS multi-servidor precisaria de ter um canal de comunicação de infra-estrutura rápida para sincronizar tudo o que for possível transactions and writes, while preventing / handling deadlock.
É por isso que normalmente só se vê 1 mestre (escritor) e vários escravos (leitores).ACID vs BASE - NoSQL normalmente deixa de fora algumas das características ácidas de SQL, uma espécie de 'batota' é o caminho para um maior desempenho, deixando esta camada de abstração para o programador. Isto já foi coberto por cartazes anteriores.
Escala Horizontal - a verdadeira vantagem da NoSQL é a escala horizontal, também conhecida como sharding. Considerando que os 'documentos' de NoSQL são uma espécie de objeto 'auto-contido', objetos podem estar em diferentes servidores sem se preocupar com a junção de linhas de vários servidores, como é o caso com o modelo relacional.
post {
id: 1
title: 'My post'
content: 'The content'
comments: {
comment: {
id: 1
}
comment: {
id: 2
}
...
views: {
view: {
user: 1
}
view: {
user: 2
}
...
}
}
No entanto, com o DBs relacional, o post teria de se juntar aos comentários da tabela comments, bem como as opiniões da tabela views. Isto não seria um problema em SQL ~até~ o DB ser dividido em fragmentos, caso em que 'Comentário 1' poderia estar em um servidor DB, enquanto 'comentário 2' ainda em outro servidor DB. Isso torna muito mais difícil criar o mesmo objeto em um RDBMS que foi dimensionado horizontalmente do que em um NoSQL DB.
Os RDBMSs típicos dão fortes garantias sobre consistência. Isto requer uma comunicação estendida entre nós para cada transação. Isso limita a capacidade de escalar, porque mais nós significa mais Comunicação
Os sistemas NoSql fazem trocas diferentes. Por exemplo, eles não garantem que uma segunda sessão irá ver imediatamente dados commitidos por uma primeira sessão. Dissociando assim a transacção de armazenamento de alguns dados do processo de disponibilização desses dados para cada utilizador. Google "eventualmente consistente". Assim, uma única transação não precisa esperar por qualquer comunicação (ou por muito menos) entre nós. Portanto, eles são capazes de utilizar uma grande quantidade de nós muito mais facilmente.
Para um sem SQL, 1.Toda a criança relacionada a uma coleção está no mesmo lugar e assim no mesmo servidor e não há nenhuma operação de junção para procurar dados de outro servidor .
2.Não existe nenhum esquema, por isso não são necessários bloqueios em nenhum servidor e o tratamento de transações é deixado para os clientes .
Os dois acima economizam um monte de sobrecarga de escala em NO-SQL.