À quelle taille de données devient-il avantageux de passer de SQL à NoSQL?
En tant que programmeur de bases de données relationnelles (la plupart du temps), j'ai lu des articles sur la façon dont les bases de données relationnelles ne s'adaptent pas, et les solutions NoSQL comme MongoDB le font. Comme la plupart des bases de données que j'ai développées jusqu'à présent sont de petite à moyenne échelle, je n'ai jamais eu de problème qui n'a pas été résolu par une indexation, une optimisation des requêtes ou une refonte du schéma.
Avec quelle taille devrais-je m'attendre à voir MySQL lutter avec. Combien de lignes?
(Je sais que cela dépendra de l'application et du type de données stockées. Celui qui m'a obtenu était essentiellement une base de données génétiques, donc aurait une table principale, avec 3 ou 4 tables de recherche. La table principale contiendra entre entre autres choses, une référence chromosomique et une coordonnée de position. Il sera probablement demandé un certain nombre d'entrées entre deux potions sur un chromosome, pour voir ce qui y est stocké).
Quelle est la taille des données?
Il existe deux seuils importants:
- des données entières tiennent dans la RAM
- les données d'index entières tiennent dans la RAM
Avec des SSD rapides, le premier seuil est devenu un peu moins problématique, sauf si vous avez un trafic élevé et fou.
Acidité
L'un des problèmes avec la mise à l'échelle des SGBDR est que, par conception, ils sont ACID, ce qui signifie des transactions et des verrous au niveau des lignes (ou même au niveau de la table dans certains SGBDR plus anciens/plus simples). Cela peut être un facteur limitant si vous avez beaucoup de requêtes modifiant beaucoup de données en cours d'exécution en même temps. Les solutions NoSQL optent généralement pour le modèle cohérence éventuelle .
Comment le SGBDR évolue-t-il en fonction de la taille des données?
Ce n'est pas tout à fait vrai que le SGBDR ne peut pas évoluer en fonction de la taille des données, il existe deux alternatives: partitionnement vertical et partitionnement horizontal (aka sharding).
Le partitionnement vertical consiste essentiellement à conserver des tables non liées sur des serveurs de base de données distincts, ce qui maintient la taille de chacun sous les seuils mentionnés ci-dessus. Cela rend la jointure de ces tables à l'aide de SQL simple moins simple et moins efficace.
Le sharding signifie la distribution des données d'une table entre différents serveurs, en fonction d'une clé spécifique. Cela signifie que pour les recherches, vous savez quel serveur interroger en fonction de cette clé. Cependant, cela complique les requêtes qui ne sont pas des recherches sur la clé de partitionnement.
Dans le cas des deux types de partitionnement, si vous allez à l'extrême, vous vous retrouvez essentiellement avec la même situation que les bases de données NoSQL.
Je ne pense pas que la taille des données soit le seul facteur. Le "modèle de données" est également un élément très important.
Les pages du catalogue du commerce électronique (Solr, ElasticSearch), les données d'analyse Web (Riak, Cassandra), les cours des actions (Redis), les relations de relations dans les réseaux sociaux (Neo4J, FleetDB) ne sont que quelques exemples lorsqu'une solution NoSQL brille vraiment.
À mon humble avis, le modèle de données a un rôle plus important que la taille des données lors de l'examen d'une solution NoSQL ou RDBMS.
Si les bases de données relationnelles ne sont pas évolutives, rien ne le fait. Ne vous inquiétez pas des problèmes de mise à l'échelle.
SQL a des problèmes avec certaines sortes d'analyses, mais cela ne prend pas beaucoup de données pour déclencher le problème. Par exemple, considérons une table unique avec une colonne qui fait référence à d'autres lignes en fonction d'une clé unique. En règle générale, cela peut être utilisé pour créer une structure arborescente. Vous pouvez écrire des instructions SQL rapides qui référencent la ligne associée. Ou la ligne associée de la ligne associée. En fait, vous pouvez effectuer un nombre spécifique de sauts. Mais si, pour chaque ligne, vous souhaitez sélectionner un champ sur la première ligne associée de la chaîne qui répond à un critère, cela devient compliqué.
Considérez un tableau des emplacements des bureaux aux niveaux de la nation, de la province/de l'état, du comté, de la ville et du village, chaque bureau faisant référence au bureau auquel il fait rapport. Il y a non garantie que le bureau déclarant de chaque bureau n'est qu'à un niveau supérieur. Pour un ensemble sélectionné de bureaux, pas tous sur un seul niveau, vous souhaitez répertorier le bureau national associé de chacun. Cela nécessite des boucles d'instructions SQL et prendra encore beaucoup de temps aujourd'hui. (J'obtenais 30 secondes sur une sélection de 30 bureaux, mais c'était il y a long fois) et le passage aux procédures stockées m'a un peu aidé.)
Donc, l'alternative est de mettre toute la structure en un seul gros bloc de données, de l'étiqueter et de la stocker. Lorsque vous souhaitez analyser les données, lisez-les toutes en mémoire d'un coup, en configurant des pointeurs pour suivre la structure, et vous pouvez traiter quelques millions de bureaux en un clin d'œil.
Rien de tout cela n'a beaucoup à voir avec la quantité de données. La clé est la nature de l'organisation des données. Si une mise en page relationnelle aide, alors un SGBDR est ce que vous voulez. Sinon, une sorte de stockage en vrac sera plus rapide, voire légèrement quadrillaire.
Notez que si l'un de ces ensembles de données devient trop volumineux pour tenir en mémoire, votre base de données non SQL ne fonctionne plus. Un autre problème est lorsque vous avez besoin de données provenant de plusieurs blocs à la fois; vous pouvez le faire if, et only if, tous les blocs tiennent en mémoire à la fois. Et l'utilisateur doit attendre pendant que vous les chargez.
Si votre base de données relationnelle va vous causer des problèmes, elle le fera avant que vous y ayez mis beaucoup de données. Le seul problème de mise à l'échelle que vous pourriez avoir est avec votre programme lorsque le bloc de données que vous assemblez pour une base de données nosql - si vous devez en utiliser un - devient trop gros pour lui. (Lisez les erreurs de mémoire insuffisante. Les nouvelles langues font parfois des choses étranges avec la mémoire.)
Je pense que la première raison d'aller à une solution NoSQL ou distribuée n'est pas tant la taille de toutes les données, mais la taille des tables. Ce que les solutions distribuées font bien, c'est de diviser les tables en différents nœuds, puis lorsque vous devez interroger les tables, chaque nœud traitera sa partie de la table.
Les SGBDR peuvent le faire, mais la nouvelle vague de bases de données NoSQL a été conçue pour cela. Oracle, MSSQL, MySQL ont pris leur modèle centralisé et l'ont modifié pour le faire fonctionner dans un environnement distribué. Cependant, ils adhèrent toujours à des règles ACID strictes tandis que certaines des nouvelles bases de données n'adhèrent pas aux règles strictes, par exemple en utilisant une cohérence éventuelle.
Il n'y a pas de quantité de données définie pour laquelle vous devriez choisir l'une plutôt que l'autre. Ce qui doit être pris en compte sont les besoins de la base de données et la quantité d'utilisation qu'elle reçoit. Les bases de données NoSQL peuvent traiter des ensembles de données plus volumineux plus rapidement tandis que les bases de données relationnelles vous garantissent que vos données sont correctes avec les principes ACID.
Mongo peut être installé sur plusieurs ordinateurs/nœuds. PostgreSQL ne fournit pas d'outil intégré pour le sharding, cependant citus est là.
MongoDB prend en charge les bases de données jusqu'à 64 téraoctets et la taille du document est de 16 mégaoctets.
MySQL a une limite de base de données de 256 téraoctets, 64 téraoctets la taille maximale pour une table et une limite d'enregistrement de 4 gigaoctets
PostgreSQL n'a pas de limite sur la base de données (4 téraoctets existent quelque part pour les tests) et il a une limite de 1 gigaoctet pour la taille de n'importe quel champ dans un table et encore 64 téraoctets la taille maximale pour une table.
Il peut également être utile de mentionner que votre modèle de données a une grande influence sur les choses. Si vous devez créer une forme d'arborescence (c'est-à-dire que vous avez une clé étrangère auto-référencée sur une table qui contient ladite clé étrangère dans une clé primaire composée), vous devriez probablement envisager de le faire dans une forme de base de données qui gère ces types de données très bien (comme mongodb ou couchdb).
Comme d'autres personnes l'ont dit, vous devez également prendre en compte ce qui se passe dans votre candidature. si vous avez vraiment besoin d'ACID sur plusieurs tables, vous devez vraiment vous en tenir à un SGBDR, mais si vous avez quelque chose où vous pouvez avoir des données légèrement périmées et que vous avez besoin de la flexibilité d'un schéma NoSQL (appelez-le sans schéma si vous le souhaitez, mais il a toujours une forme de schéma implicite), alors vous pourriez envisager de saisir un magasin NoSQL ( http://www.10gen.com/customers/craigslist voici un exemple de la raison pour laquelle craigslist est passé ... mais certes, ils archivent ~ 10 To de données, ce qui, je le sais, ne correspond pas du tout à la taille de votre base de données de petite à moyenne taille. Mais le cas d'utilisation pourrait être utile).
Gardez à l'esprit que les systèmes NoSQL ne sont pas nécessairement là pour remplacer les RDMS mais dans de nombreux cas, vous pouvez compléter votre RDBMS grâce à l'idée de Polyglot Persistence et vous pouvez stocker la plupart de vos données dans un RDBMS mais dans des instances de niche spécifiques, vous pouvez décharger une partie de votre données à une certaine forme de magasin NoSQL.