SQL (MySQL) vs NoSQL (CouchDB) [fechado]

Estou no meio do projeto de um aplicativo altamente escalável, que deve armazenar muitos dados. Por exemplo, ele armazenará muito sobre os usuários e, em seguida, coisas como muitas de suas mensagens, comentários, etc. Eu sempre usei o MySQL antes, mas agora pretendo tentar algo novo como couchdb ou similar que não seja SQL.

Alguém tem alguma opinião ou orientação sobre isso?

Aqui está uma citação de uma recente postagem de blog de Dare Obasanjo .

Os bancos de dados SQL são como transmissão automática e os bancos de dados NoSQL são como transmissão manual. Depois de mudar para o NoSQL, você se torna responsável por muito trabalho que o sistema cuida automaticamente em um sistema de banco de dados relacional. Semelhante ao que acontece quando você escolhe a transmissão manual em vez da automática. Em segundo lugar, o NoSQL permite obter mais desempenho do sistema, eliminando muitas verificações de integridade feitas por bancos de dados relacionais da camada de banco de dados. Novamente, isso é semelhante a como você pode obter mais desempenho do seu carro dirigindo uma transmissão manual versus um veículo de transmissão automática.

No entanto, a semelhança mais notável é que, assim como a maioria de nós não pode realmente tirar proveito dos benefícios de um veículo de transmissão manual, porque a maioria de nossa direção está parada no trânsito a caminho do e para o trabalho, existe uma realidade similar pois a maioria dos sites não está na escala do Google ou do Facebook e, portanto, não precisa de um Bigtable ou Cassandra.

Ao qual posso acrescentar apenas a mudança do MySQL, onde você tem pelo menos alguma experiência, para o CouchDB, onde você não tem experiência, significa que você terá que lidar com todo um novo conjunto de problemas e aprender diferentes conceitos e práticas recomendadas. Embora por si só isso seja maravilhoso (estou brincando em casa com o MongoDB e gosto muito), será um custo que você precisará calcular ao estimar o trabalho para esse projeto, além de trazer riscos desconhecidos e, ao mesmo tempo, prometer benefícios desconhecidos. Será muito difícil julgar se você pode fazer o projeto no prazo e com a qualidade que deseja / precisa para ter sucesso, se for baseado em uma tecnologia que você não conhece.

Agora, se você tem na equipe um especialista no campo NoSQL, dê uma boa olhada nela. Mas sem nenhuma experiência na equipe, não use o NoSQL para um novo projeto comercial.

Atualização : Apenas para jogar gasolina no fogo aberto que você começou, aqui estão dois artigos interessantes de pessoas no campo SQL. :-)

Não posso esperar que o NoSQL morra (o artigo original se foi, aqui está uma cópia )
Combatendo a mentalidade do NoSQL, embora essa não seja uma
atualização de peça anti-NoSQL : Bem, aqui está um artigo interessante sobre o NoSQL
Compreendendo o NoSQL

Parece que apenas hoje as soluções reais giram em torno de expansão ou sharding. Todos os bancos de dados modernos (NoSQLs e NewSQLs) suportam o dimensionamento horizontal imediatamente, na camada do banco de dados, sem a necessidade de o aplicativo ter código de fragmentação ou algo assim.

Infelizmente, para o bom e velho MySQL confiável, o sharding não é fornecido "pronto para uso". O ScaleBase (isenção de responsabilidade: eu trabalho lá) é um fabricante de uma solução completa de dimensionamento horizontal, uma "máquina de fragmentação automática", se desejar. O ScaleBae analisa seus dados e o fluxo SQL, divide os dados entre os nós do banco de dados e agrega em tempo de execução - para que você não precise! E é download gratuito.

Não me interpretem mal, os NoSQLs são ótimos, são novos, novos são mais opções e sempre são boas !! Mas escolher o NoSQL vem com um preço, verifique se você pode pagá-lo ...

Você pode ver aqui mais alguns dados sobre MySQL, NoSQL ...: http://www.scalebase.com/extreme-scalability-with-mongodb-and-mysql-part-1-auto-sharding

Espero que tenha ajudado.

Uma das melhores opções é optar pelo MongoDB (NOSql dB), que oferece suporte à escalabilidade. para garantir a garantia de dados que mantém vários servidores tendo o servidor db primário como base. Linguagem independente. Flexível para usar