J'ai lu un article disant que le SGBDR tel que MySQL n'est pas bon pour l'évolutivité, mais que NoSQL tel que MongoDB peut bien être fragmenté. Je veux savoir quelle fonctionnalité fournie par le SGBDR ne peut pas bien scinder.Pourquoi NoSQL dit que le RDBMS traditionnel n'est pas bon à l'échelle
La plupart des systèmes RDBMS garantissent la soi-disant ACID properties. La plupart de ces propriétés se résument à consistance; Toute modification de vos données transférera votre base de données d'un état cohérent à un autre état cohérent.
Par exemple, si vous mettez à jour plusieurs enregistrements dans une même transaction, la base de données garantit que les enregistrements concernés ne seront pas modifiés par d'autres requêtes, tant que la transaction n'est pas terminée. Ainsi, au cours de la transaction, plusieurs tables peuvent être verrouillées pour modification. Si ces tables sont réparties sur plusieurs partitions/serveurs, il faudra plus de temps pour acquérir les verrous appropriés, mettre à jour les données et libérer les verrous.
Les CAP theorem stipule qu'une distribution (c.-à-évolutive) système ne peut pas garantir toutes les propriétés suivantes en même temps:
SGBDR les systèmes garantissent la cohérence. Sharding rend le système tolérant au partitionnement. Du théorème suit que le système ne peut pas garantir la disponibilité. C'est pourquoi un SGBDR standard ne peut pas très bien évoluer: il ne pourra pas garantir la disponibilité. Et à quoi sert une base de données si vous ne pouvez pas y accéder?
Les bases de données NoSQL abandonnent la cohérence au profit de la disponibilité. C'est pourquoi ils sont meilleurs en termes d'évolutivité. Je ne dis pas que les systèmes de SGBDR ne peuvent pas évoluer du tout, c'est juste plus difficile. This article décrit certains des schémas de partitionnement possibles et les problèmes que vous pouvez rencontrer. La plupart des approches sacrifient la cohérence, qui est l'une des caractéristiques les plus importantes des systèmes de SGBDR, et qui empêche la mise à l'échelle.
requêtes impliquant plusieurs tessons sont complexes (F.E. Jointures entre les tables dans différents tessons)
Et si je n'utilise jamais de jointure dans le SGBDR, le SGBDR deviendra-t-il facilement un fragment? Si tel est le cas, il ne semble pas nécessaire d'implémenter une nouvelle base de données appelée NoSQL. – shuitu
Les SGBDR sont destinés à être un système de gestion pour une base de données «relationnelle». Et les relations entre les données sont exposées par JOINs entre les tables. Si vous n'utilisez pas JOINs, cela signifie que votre base de données n'est pas relationnelle, vous pouvez donc déplacer des NoSQL qui sont des magasins de clés/valeurs. –
Pourquoi dudes NoSQL et dudettes n'aiment pas Jointures: http://www.dbms2.com/2010/05/01/ryw-read-your-writes-consistency/
Voulez-vous dire "partagé", ou "Shard"? – StingyJack
Ou partagé? (comme dans Lucene)? – bmargulies
[Shard] (http://en.wikipedia.org/wiki/Shard_%28database_architecture%29), comme pour partitionner votre base de données en partitions séparées. –