Architecture et architecture de base de données évolutive

Question

J'ai essayé d'en savoir plus sur la mise à l'échelle d'une base de données dans un système distribué, et je suis coincé entre le SGBDR et le NoSQL.

Certains articles en ligne suggèrent que NoSQL est la solution aux Big Data modernes. D'autres disent que NoSQL est juste un battage médiatique et que le SGBDR peut être tout aussi évolutif avec une bonne conception, et qu'il fournit une bonne structure de données. Au lieu de lire les opinions des autres, j'aimerais les juger moi-même, mais je ne comprends pas exactement ce qui est requis pour un SGBDR évolutif et un NoSQL évolutif. J'ai fait un peu plus de lectures sur le SGBDR, et il semble que la solution nécessite de tirer parti de memcache et de sharding pour réduire la taille de la base de données et le nombre de requêtes DB. Y a-t-il d'autres astuces? Pouvez-vous toujours utiliser des tables avec plusieurs colonnes? Ou utilisez moins de colonnes et plus de jointures? Comme pour NoSQL, j'ai lu un peu à propos de MongoDB. Je comprends qu'il encourage l'agrégation de données. Mais comment cela rend-il plus évolutif? Je commence aussi à apprendre Cassandra parce que j'ai lu qu'il est bien plus évolutif que MongoDB, mais je n'ai aucune idée de comment il est plus évolutif. J'apprécierais beaucoup une base (ou avancé, si vous avez la patience de le dactylographier) explication condensée et down-to-the-core sur l'échelle SGBDR et NoSQL, ou de bons articles en ligne ou livres qui expliquent le sujet. :)

Answer 1

Je ne couvre pas les moyens, vous pouvez l'échelle en mettant en place des choses sur votre propre et de mettre un serveur memcache entre ... Je vais juste couvrir ce qui vient juste de la boîte ...

Commençons d'abord avec SGBDR:

Je pense que la mise en place d'un groupe de SGBDR est plus compliqué qu'un groupe NoSQL, mais c'est juste mon avis. Habituellement, ce que vous avez est un maître et plusieurs esclaves. Vous devez envoyer toutes vos écritures au maître et pouvez lire de n'importe quel esclave que vous voulez. Puisque vous avez des SGBDR et des ACID, le système devrait vous garantir que vous ne liriez pas les anciennes données. Donc la chose ici, c'est que vous supposez que votre application écrit une fois et lit souvent (comme c'est généralement le cas). À ces fins, un serveur pour lire/écrire et plusieurs serveurs pour lire est génial. Le problème est que si vous écrivez si souvent que vous ne pouvez plus les suivre sur une machine. C'est votre goulot d'étranglement. En plus des solutions intégrées d'Oracle - qui sont énormes - il y a aussi http://www.scalearc.com/ qui peut mettre en cache des requêtes, ... et gérer la mise à l'échelle pour vous.

NoSQL:

Il n'y a pas 1 schéma NoSQL qui est mis en œuvre par tous les blocs de données. Chaque système est un peu différent. MongoDB par exemple est assez similaire à RDBMS, il a aussi un seul maître et plusieurs esclaves auxquels il peut répliquer des données, mais vous pouvez également créer des fragments. Les données sont réparties entre les fragments et répliquées sur les esclaves. Ainsi, vous pourriez avoir plusieurs maîtres différents qui sont responsables de petites pièces. Ensuite, lorsque vous lisez, vous pouvez choisir si vous voulez lire à partir de plusieurs esclaves, du maître ou de n'importe quel esclave - selon l'urgence dont vous avez besoin des dernières données.

Cassandra d'autre part fonctionne totalement différemment. Je ne suis pas sûr si vous pouvez écrire à plusieurs serveurs ou comment cela fonctionne, mais fondamentalement les serveurs tiennent un journal de toutes les écritures. Ainsi, même s'ils ne peuvent pas traiter les écritures immédiatement, ils sont stockés dans un journal pour vous donner une réponse rapide.Ensuite, quand vous lisez, vous pouvez dire à nouveau avec quelle urgence vous voulez avoir les nouvelles données, et si vous voulez vraiment les dernières données, Cassandra devra vérifier le journal, s'il y a des mises à jour écrites, et cela vous coûtera un beaucoup de temps.

Les magasins de valeurs-clés tels que ElasticSearch, CouchDB, CouchBase fonctionnent différemment. Ici l'objet est haché, et basé sur le hachage, envoyé à un noeud qui en sera responsable. De cette façon, lorsque vous lisez après que la clé a été écrite, vous obtenez à nouveau des informations à jour, car vous lirez à partir du même nœud. L'idée de cette conception est, qu'aucune clé unique ne sera de l'intérêt de tout le monde, mais la charge sera distribuée. Ce sont aussi les DB qui, selon moi, évoluent au mieux, et rendent le plus facile d'ajouter plus de serveurs au cluster, mais vous perdez la puissance des requêtes complexes, comme vous l'avez dans MongoDB et Cassandra - et bien sûr RDBMS. ElasticSearch a quelques requêtes de recherche simples, et CouchDB et CouchBase ont seulement des vues qui sont produites par MapReduce, où vous pouvez obtenir des données que vous voulez, si elle correspond à la vue. Sinon, vous ne pouvez y accéder que par la clé.

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis - est un résumé très complet des bases de données NoSQL les plus courantes, de leurs forces et faiblesses et des scénarios d'utilisation les plus courants. En fin de compte, la question est aussi: pourquoi voulez-vous mettre à l'échelle? Combien de dossiers allez-vous avoir dans la base de données? Quelques millions ne sont pas du tout un problème. Quelques centaines de millions ne sont pas non plus un problème pour la plupart des SGBDR sur un serveur assez puissant. Et si conçu la DB et ses indices correctement, même un milliard d'enregistrements par an devrait être encore bien.