Pourquoi les bases de données relationnelles ayant des problèmes d'évolutivité?
Recenctly j'ai lu quelques articles en ligne qui indique les bases de données relationnelles ont des questions d'échelle et pas bon à utiliser quand il s'agit de big data. Spécialement dans le cloud computing, où les données sont grandes. Mais je ne pouvais pas trouver de bonnes et solides raisons pour lesquelles elle n'est pas évolutive beaucoup, par googler. Pouvez-vous svp m'expliquer les limites des bases de données relationnelles quand il s'agit de l'évolutivité?
Grâce.
- Définissent pas "scalable". Beaucoup de Poissons et un Débordement de Pile dans l'utilisation de bases de données relationnelles et ils ont des millions de visites par jour.
- Mon point est que beaucoup de gens qui disent que la base de données relationnelle n'est pas de l'échelle sont les mêmes que ceux qui ne savent pas comment les utiliser efficacement.
- Oui. Je vois que vous avez un point. Des Sites comme dépassement de pile à obtenir des millions de hits par jour et clairement les bases de données relationnelles ont la capacité de le gérer. Mais je suis en train d'essayer de clarifier moi, c'est, peut-être le problème, c'est avec l'efficacité ou peut être le coût, etc... c'est ce Que je veux savoir. Je suis juste essayer de garder un esprit ouvert 😉
- Pour répondre à votre question. Des bases de données relationnelles ACIDE - c'est cher. De nombreuses solutions NoSQL supprimer un ou plusieurs des contraintes de l'ACIDE impose (donc un compromis entre l'ACIDE et de la vitesse).
- Double Possible de Pourquoi le NoSQL est préférable à "l'échelle" de SGBDR?
Vous devez vous connecter pour publier un commentaire.
Bases de données relationnelles fournir solide, mature services selon les L'ACIDE propriétés. Nous obtenons transaction, la gestion efficace de journalisation afin de permettre la récupération etc. Ces sont les services de base des bases de données relationnelles, et de celles auxquelles ils sont bons. Ils sont difficiles à personnaliser, et pourrait être considérée comme un goulot d'étranglement, surtout si vous n'en avez pas besoin dans une application donnée (par exemple. servir le contenu du site web avec une faible importance; dans ce cas, par exemple, largement utilisé MySQL ne permet pas de fournir le traitement des transactions avec le moteur de stockage par défaut, et ne remplit donc pas ACIDE). Beaucoup de "big data", les problèmes ne nécessitent pas de ces strictes contraintes, par exemple le web analytique, la recherche sur le web ou de traitement de l'objet en mouvement trajectoires, qu'ils comprennent déjà l'incertitude par la nature.
Lorsque l'on atteint les limites de l'ordinateur (mémoire, CPU, disque: les données sont trop gros, ou le traitement de données est trop complexe et coûteux), la distribution de ce service est une bonne idée. Beaucoup de relationnel et de bases de données NoSQL offre de stockage distribué. Dans ce cas cependant, l'ACIDE s'avère être difficile à satisfaire: la Théorème CAP états un peu similaire, que la disponibilité, la cohérence et la partition de la tolérance ne peut pas être réalisée à la même époque. Si nous donnons de l'ACIDE (satisfaire de BASE par exemple), l'évolutivité peut être augmenté.
Voir cette post par exemple. pour la catégorisation des méthodes de stockage selon la PAC.
Un autre goulot d'étranglement peut être flexible et intelligent tapé modèle relationnel lui-même avec les opérations SQL: dans de nombreux cas, un modèle plus simple avec une simplification des opérations serait suffisante et plus efficace (comme de type clé-valeur des magasins). La commune de la ligne sage de stockage physique modèle pourrait également être un facteur limitant: par exemple, il n'est pas optimal pour la compression de données.
Il y a cependant rapide et évolutive de l'ACIDE conforme bases de données relationnelles, y compris les nouvelles, comme le VoltDB, la technologie de bases de données relationnelles est mature, bien documenté et très répandue. Nous avons juste à sélectionner une solution appropriée pour le problème donné.
Imaginer deux types de carrefour.
On a des feux de circulation ou des officiers de police de la réglementation de la circulation, le mouvement sur le carrefour est à une vitesse limitée, et il y a un chien de garde de l'inscription précisément ce que la voiture roulait sur le carrefour en ce moment précisément, et dans quelle direction il allait.
L'autre a rien de tout cela, et tout le monde qui arrive à la croisée des chemins, à la vitesse qu'il est dans la voiture, juste des plongées et veut passer à travers aussi rapide que possible.
L'ancien est tout traditionnelle moteur de base de données. Le carrefour est la donnée elle-même. Les voitures sont les opérations qui veulent avoir accès aux données. Les feux de circulation ou un agent de police est le SGBD. Le chien de garde de garde les journaux et les revues.
Le dernier est un NOACID type de moteur.
Les deux ont un point de saturation, à quel point l'arrivée des voitures sont obligés de commencer la mise en attente jusqu'à l'entrée des points. Les deux ont un débit maximal. Ce seuil se situe à une valeur plus faible pour le premier type de carrefour, et la raison en est évidente.
L'avantage de l'ancien type de carrefour devrait toutefois être aussi évident. De façon moins l'occasion pour les accidents de se produire. Sur le deuxième type de carrefour, vous pouvez vous attendre à des accidents de ne pas se produire que si la densité du trafic est beaucoup beaucoup plus bas que le théorique maximale du débit de la croisée des chemins. Et dans la traduction de gestion de données, moteurs, elle se traduit par une garantie de cohérence et de résultats cohérents, dont seul le premier type de carrefour (le classique moteur de base de données, que ce soit relationnel ou en réseau, ou hiérarchique) peut offrir.
L'analogie peut être étendu plus loin. Imaginez ce qui arriverait si un accident NE se produise. Sur le deuxième type de carrefour, la principale préoccupation sera probablement pour dégager la route aussi rapide que possible, de sorte que le trafic puisse reprendre, et quand c'est fait, ce que l'info est toujours disponible pour enquêter sur la responsabilité de l'accident, et comment ? Rien du tout. Il ne sera pas connu. Le carrefour est ouvert juste en attente pour le prochain accident se produise. Le règlement du carrefour, il y a l'agent de police de la régulation de la circulation qui ont vu ce qui s'est passé et peut en témoigner. Il y a les journaux disant que la voiture est entré à ce moment précisément, à quel point d'entrée, précisément, à quelle vitesse, précisément, beaucoup de matériel est disponible pour inspection afin de déterminer la cause de l'accident. Mais bien sûr, rien de tout cela n'est gratuit.
Coloré suffisant comme explication ?
Prendre l'exemple le plus simple: insérer une ligne avec l'ID généré. Depuis Id doit être unique dans la table de base de données doit en quelque sorte de verrouiller certains de tri de la persistance de compteur de sorte qu'aucune autre INSÉREZ utilise la même valeur. Vous avez donc deux choix: soit autoriser qu'une seule instance d'écrire des données ou ont distribué de la serrure. Les deux solutions sont l'une des principales bouteille de beck, et est l'exemple le plus simple!