L'interprétation polie de "NoSQL" est devenue Not Only SQL . Si vous disposez de données véritablement relationnelles, ou si votre fonctionnalité dépend d'éléments tels que les jointures et ACIDity, vous devez stocker ces données de manière relationnelle. Dans cet article, j'expliquerai comment j'utilise MySQL avec deux Magasins de données NoSQL. Le stockage de données moderne à l'échelle du Web consiste à comprendre comment choisir le ou les meilleurs outils pour le ou les travaux.
Cela dit, NoSQL est vraiment une réaction au fait que la méthode et la façon de penser relationnelles ont été appliquées à des problèmes où ce n'est pas vraiment un très bon ajustement (généralement d'énormes tables avec des dizaines de millions de lignes ou plus). Une fois que les tables deviennent aussi volumineuses, la "meilleure pratique" SQL typique consiste à partager manuellement les données -- c'est-à-dire en plaçant les enregistrements 1 à 10 000 000 dans la table A, 10 000 001 à 20 000 001 dans la table B, etc. Ensuite, généralement dans la couche de modèle d'application, les recherches sont effectuées selon ce schéma. C'est ce qu'on appelle application-aware mise à l'échelle. Cela prend beaucoup de temps et est sujet aux erreurs, mais pour faire évoluer quelque chose tout en maintenant MySQL pour le magasin de tables longues, c'est devenu un MO plus ou moins standard. NoSQL représente, pour moi, le application-unaware alternative.
Valeur-clé
Quand un prototype MySQL a commencé à devenir trop gros pour son propre bien, j'ai personnellement déplacé autant de données que possible vers la rapide comme l'éclair Membase , qui surpasse Memcached et ajoute de la persistance. Membase est un magasin de clé-valeur distribué qui évolue plus ou moins linéairement (Zynga l'utilise pour gérer un demi-million d'opérations par seconde, par exemple) en ajoutant plus de serveurs de base dans un cluster - c'est donc un excellent adapté à l'ère du cloud d'Amazon EC2 , Joyent , etc.
Il est bien connu que les magasins de clé-valeur distribués sont le meilleur moyen d'obtenir une échelle linéaire énorme. La faiblesse de la clé-valeur est l'interrogation et l'indexation. Mais même dans le monde relationnel, la meilleure pratique en matière d'évolutivité consiste à décharger autant d'efforts que possible sur les serveurs d'applications, en effectuant des jointures en mémoire sur les serveurs d'applications de base au lieu de demander au cluster RDB central de gérer toute cette logique. Depuis simple select plus application logic sont vraiment le meilleur moyen d'atteindre une échelle massive même sur MySQL, la transition vers quelque chose comme Membase (ou ses concurrents comme Riak
) n'est pas vraiment trop mal.
Magasins de documents
Parfois - même si je dirais moins souvent que beaucoup ne le pensent - la conception d'une application nécessite intrinsèquement des index secondaires, une capacité d'interrogation de plage, etc. L'approche NoSQL pour cela passe par un document store comme MongoDB
. Comme Membase, Mongo est très bon dans certains domaines où les bases de données relationnelles sont particulièrement faibles, comme application-unaware mise à l'échelle, auto-sharding , et maintaining flat response times even as dataset size balloons . C'est beaucoup plus lent que Membase et un peu plus délicat à faire une échelle horizontale pure, mais l'avantage est qu'il est très interrogeable. Vous pouvez effectuer des requêtes sur des paramètres et des plages en temps réel, ou vous pouvez utiliser Map/Reduce pour effectuer des opérations par lots complexes sur des ensembles de données vraiment énormes.
Sur le même projet que j'ai mentionné ci-dessus, qui utilise Membase pour servir des tonnes de données de joueurs en direct, nous utilisons MongoDB pour stocker des données d'analyse/métriques, ce qui est vraiment là où MongoDB brille.
Pourquoi garder les choses en SQL
J'ai brièvement évoqué le fait que les informations "vraiment relationnelles" doivent rester dans les bases de données relationnelles. Comme le souligne le commentateur Dan K., j'ai raté la partie où je discute des inconvénients de quitter le SGBDR, ou du moins de le quitter complètement.
Premièrement, il y a SQL lui-même. SQL est bien connu et est un standard de l'industrie depuis longtemps. Certaines bases de données "NoSQL" comme App Engine
de Google Datastore (construit sur Big Table) implémente son propre langage de type SQL (celui de Google s'appelle, joliment, GQL pour Google Query Language ). MongoDB adopte une nouvelle approche du problème d'interrogation avec ses délicieux objets de requête JSON
. Pourtant, SQL lui-même est un outil puissant pour extraire des informations des données, ce qui est souvent tout l'intérêt des bases de données.
La raison la plus importante de rester avec RDBMS est ACID
, ou Atomicity, Consistency, Isolation, Durability . Je ne re-hacherai pas l'état d'Acid-NoSQL, car il est bien traité dans ce message
sur SO. Qu'il suffise de dire qu'il existe une raison rationnelle le SGBDR d'Oracle
a un marché si énorme qui ne va nulle part :certaines données ont besoin d'une pure conformité ACID . Si vos données le font (et si c'est le cas, vous êtes probablement bien conscient de ce fait), alors votre base de données le fait aussi. Gardez ce pH
faible !
Modifier : Consultez le message d'Aaronaught ici. Il représente la perspective interentreprises bien mieux que moi, en partie parce que j'ai passé toute ma carrière dans le domaine de la consommation.
