7 dures vérités sur la révolution NoSQL

Le mot à la mode NoSQL métastase depuis plusieurs années. L'excitation suscitée par ces magasins de données rapides a été enivrante, et nous sommes aussi coupables que quiconque d'avoir vu l'attrait révolutionnaire de NoSQL. Pourtant, la lune de miel touche à sa fin, et il est temps de commencer à équilibrer notre enthousiasme avec des vérités dures aux yeux vrillés.

Ne vous méprenez pas. Nous sommes toujours en train d'essayer la dernière expérience de création d'un mécanisme simple de stockage des données. Nous trouvons toujours une valeur profonde dans MongoDB, CouchDB, Cassandra, Riak et d'autres standouts NoSQL. Nous prévoyons toujours de jeter certaines de nos données les plus fiables dans ces piles de code, car elles se développent de mieux en mieux et sont de plus en plus testées au combat chaque jour.

[Aussi sur: NoSQL hors concours: nouvelles bases de données pour de nouvelles applications | Premier coup d'œil: Oracle NoSQL Database | Obtenez un résumé des histoires clés chaque jour dans le bulletin quotidien. ]

Mais nous commençons à ressentir le frottement, car les systèmes NoSQL sont loin d'être parfaitement adaptés et se frottent souvent dans le mauvais sens. Les développeurs les plus intelligents le savaient depuis le début. Ils n'ont pas brûlé les manuels SQL et n'ont pas envoyé de nastygrammes à la force de vente de leur fournisseur SQL autrefois dévoué. Non, les développeurs intelligents de NoSQL ont simplement noté que NoSQL signifiait "Not Only SQL". Si les masses ont mal interprété l'acronyme, c'était leur problème.

Cette liste de reproches, petits et grands, est donc une tentative de documenter ce fait et de purifier l'air. Il vise à mettre les choses au clair dès maintenant afin que nous puissions faire un meilleur travail en comprenant les compromis et les compromis.

NoSQL dure vérité n ° 1: les jointures sont synonymes

L'un des premiers reproches que les gens ont à propos des systèmes SQL est le coût de calcul de l'exécution d'un JOIN entre deux tables. L'idée est de stocker les données dans un et un seul endroit. Si vous conservez une liste de clients, vous mettez leurs adresses civiques dans un tableau et utilisez leurs identifiants client dans tous les autres tableaux. Lorsque vous extrayez les données, le JOIN connecte les ID aux adresses et tout reste cohérent.

Le problème est que les JOIN peuvent être coûteux, et certains DBA ont concocté des commandes JOIN complexes qui époustouflent l'esprit, transformant même le matériel le plus rapide en boue. Il n'était pas surprenant que les développeurs NoSQL aient transformé leur manque de JOIN en une fonctionnalité: gardons simplement l'adresse du client dans la même table que tout le reste! La méthode NoSQL consiste à stocker des paires clé-valeur pour chaque personne. Le moment venu, vous les récupérez tous.

Hélas, les personnes qui veulent que leurs tables soient cohérentes ont toujours besoin de JOIN. Une fois que vous commencez à stocker les adresses des clients avec tout le reste à leur sujet, vous vous retrouvez souvent avec plusieurs copies de ces adresses dans chaque table. Et lorsque vous avez plusieurs copies, vous devez toutes les mettre à jour en même temps. Parfois cela fonctionne, mais quand ce n'est pas le cas, NoSQL n'est pas prêt à vous aider avec les transactions.

Attendez, dites-vous, pourquoi ne pas avoir un tableau séparé avec les informations du client? De cette façon, il n'y aura qu'un seul enregistrement à modifier. C'est une excellente idée, mais maintenant vous pouvez écrire vous-même le JOIN dans votre propre logique.

NoSQL dure vérité n ° 2: transactions délicates

Disons que vous êtes d'accord pour vivre sans REJOINDRE des tables parce que vous voulez la vitesse. C'est un compromis acceptable, et parfois les administrateurs de base de données SQL dénormalisent les tables pour cette raison.

Le problème est que NoSQL rend difficile la cohérence des différentes entrées. Il n'y a souvent aucune transaction pour s'assurer que les modifications apportées à plusieurs tables sont effectuées ensemble. Pour cela, vous êtes seul, et un crash pourrait faire en sorte que les tables deviennent incohérentes.

Les premières implémentations NoSQL ont fait un pied de nez à ces transactions. Ils offriraient des listes de données cohérentes, sauf lorsqu'elles ne l'étaient pas. En d'autres termes, ils sont allés chercher les données les plus faibles où les erreurs ne feraient aucune différence importante.

Maintenant, certaines implémentations NoSQL offrent quelque chose qui s'approche d'une transaction. Le produit NoSQL d'Oracle, par exemple, offre un contrôle transactionnel sur les données écrites sur un nœud et vous permet de choisir une quantité flexible de cohérence sur plusieurs nœuds. Si vous voulez une cohérence parfaite, vous devez attendre chaque écriture pour atteindre tous les nœuds. Plusieurs autres magasins de données NoSQL expérimentent l'ajout de plus de structure et de protection comme celle-ci.

NoSQL dure vérité n ° 3: les bases de données peuvent être intelligentes

De nombreux programmeurs NoSQL aiment se vanter de la façon dont leur code léger et leur mécanisme simple fonctionnent extrêmement rapidement. Ils ont généralement raison lorsque les tâches sont aussi simples que l'intérieur de NoSQL, mais cela change lorsque les problèmes deviennent plus difficiles.

Considérez l'ancien défi d'un JOIN. Une fois que les programmeurs NoSQL commencent à générer leurs propres commandes JOIN dans leur propre logique, ils commencent à essayer de le faire efficacement. Les développeurs SQL ont passé des décennies à développer des moteurs sophistiqués pour gérer les commandes JOIN le plus efficacement possible. Un développeur SQL m'a dit qu'il essayait de synchroniser son code avec le disque dur en rotation afin de ne demander des données que lorsque la tête était juste au-dessus du bon endroit. Cela peut sembler extrême, mais les développeurs SQL travaillent sur des hacks similaires depuis des décennies.

Il ne fait aucun doute que les programmeurs passent des jours à s'arracher les cheveux à essayer de structurer leurs requêtes SQL pour tirer parti de toute cette intelligence latente. Ce n'est peut-être pas simple à taper, mais lorsque le programmeur le comprend, les bases de données peuvent vraiment chanter.

Un langage de requête sophistiqué comme SQL a toujours le potentiel de surpasser un langage de requête non sophistiqué comme ceux trouvés dans NoSQL. Cela n'a peut-être pas d'importance avec des résultats simples, mais lorsque l'action devient complexe, le SQL est exécuté sur la machine juste à côté des données. Il a peu de frais généraux pour récupérer les données et faire le travail. Un serveur NoSQL doit généralement envoyer les données là où elles vont.

NoSQL dure vérité n ° 4: trop de modèles d'accès

En théorie, SQL est censé être un langage standard. Si vous utilisez SQL pour une base de données, vous devriez pouvoir exécuter la même requête dans une autre version conforme. Cette revendication peut fonctionner avec quelques requêtes simples, mais chaque DBA sait que cela peut prendre des années pour apprendre les particularités de SQL pour différentes versions de la même base de données. Les mots clés sont redéfinis et les requêtes qui fonctionnaient sur une version ne fonctionneront pas avec une autre.

NoSQL est encore plus obscur. C'est comme la tour de Babel. Depuis le début, les développeurs NoSQL ont chacun essayé d'imaginer le meilleur langage possible, mais ils ont des imaginations très différentes. Ce foyer d'expérimentation est bon - jusqu'à ce que vous essayiez de passer d'un outil à l'autre. Une requête pour CouchDB est exprimée sous la forme d'une paire de fonctions JavaScript pour le mappage et la réduction. Les premières versions de Cassandra utilisaient une API brute de bas niveau appelée Thrift; les versions plus récentes offrent CQL, un langage de requête de type SQL qui doit être analysé et compris par le serveur. Chacun est différent à sa manière.

Chaque outil n'a pas seulement ses propres particularités, il arbore une philosophie et une façon de l'exprimer complètement différentes. Il n'y a pas de moyen facile de basculer entre les magasins de données et il vous reste souvent à écrire des tonnes de code de colle juste pour vous donner la possibilité de changer à l'avenir. Cela peut ne pas être trop difficile lorsque vous insérez des paires de clés et de valeurs dans le système, mais cela peut devenir de plus en plus aggravant à mesure que vous introduisez de la complexité.

La dure vérité NoSQL n ° 5: la flexibilité du schéma est un problème qui attend de se produire

L'une des grandes idées du modèle NoSQL ne nécessite pas de schéma. En d'autres termes, les programmeurs n'ont pas besoin de décider à l'avance quelles colonnes seront disponibles pour chaque ligne d'un tableau. Une entrée peut avoir 20 chaînes attachées, une autre peut avoir 12 entiers et une autre peut être complètement vide. Les programmeurs peuvent prendre la décision chaque fois qu'ils ont besoin de stocker quelque chose. Ils n'ont pas besoin de demander la permission du DBA, et ils n'ont pas besoin de remplir tous les documents pour ajouter une nouvelle colonne.

Toute cette liberté semble enivrante, et entre de bonnes mains, elle peut accélérer le développement. Mais est-ce vraiment une bonne idée pour une base de données qui pourrait vivre à travers trois équipes de développeurs? Est-ce même réalisable pour une base de données qui pourrait durer plus de six mois?

En d'autres termes, les développeurs voudront peut-être avoir la liberté de jeter n'importe quelle ancienne paire dans une base de données, mais voulez-vous être le cinquième développeur à venir après que quatre d'entre eux aient choisi leurs propres clés? Il est facile d'imaginer une variété de représentations de «anniversaire», chaque développeur choisissant sa propre représentation comme clé lors de l'ajout de l'anniversaire d'un utilisateur à une entrée. Une équipe de développeurs pourrait imaginer presque tout: "bday", "b-day", "birthday".

La structure NoSQL n'offre aucun support pour limiter ce problème car cela impliquerait de repenser le schéma. Cela ne veut pas nuire à la douceur des développeurs totalement cool. Un schéma gênerait.

Le fait est que l'ajout d'une colonne à une table n'est pas un gros problème et que la discipline peut en fait être bonne pour le développeur. Tout comme cela aide à forcer les développeurs à désigner des types de variables, cela aide également à forcer les développeurs à désigner le type de données attachées à une colonne. Oui, le DBA peut forcer le développeur à remplir un formulaire en trois exemplaires avant de joindre cette colonne, mais ce n'est pas aussi grave que de traiter une demi-douzaine de clés différentes créées à la volée par un programmeur.

NoSQL dure vérité n ° 6: pas d'extras

Disons que vous ne voulez pas toutes les données dans toutes les lignes et que vous voulez la somme d'une seule colonne. Les utilisateurs SQL peuvent exécuter une requête avec l'opération SUM et vous renvoyer un seul numéro.

Les utilisateurs NoSQL reçoivent toutes les données qui leur sont renvoyées et peuvent ensuite effectuer eux-mêmes l'ajout. L'ajout n'est pas le problème car il faut à peu près le même temps pour additionner les nombres sur n'importe quelle machine. Cependant, l'expédition des données est lente et la bande passante nécessaire pour expédier toutes ces données peut être coûteuse.

Il y a peu d'extras dans les bases de données NoSQL. Si vous voulez faire autre chose que stocker et récupérer des données, vous allez probablement le faire vous-même. Dans de nombreux cas, vous allez le faire sur une machine différente avec une copie complète des données. Le vrai problème est qu'il peut souvent être utile de faire tout le calcul sur la machine contenant les données car l'expédition des données prend du temps. Mais dur pour toi.

Des solutions NoSQL émergent. La structure de requête Map and Reduce de MongoDB vous donne une structure JavaScript arbitraire pour résumer les données. Hadoop est un mécanisme puissant pour distribuer le calcul à travers la pile de machines qui contient également les données. Il s'agit d'une structure en évolution rapide qui offre des outils qui s'améliorent rapidement pour construire des analyses sophistiquées. C'est très cool, mais toujours nouveau. Et techniquement, Hadoop est un mot à la mode entièrement différent de NoSQL, bien que la distinction entre eux s'estompe.

NoSQL dure vérité n ° 7: moins d'outils

Bien sûr, vous pouvez installer et exécuter votre pile NoSQL sur votre serveur. Bien sûr, vous pouvez écrire votre propre code personnalisé pour pousser et extraire vos données de la pile. Mais que faire si vous voulez en faire plus? Et si vous souhaitez acheter l'un de ces packages de reporting sophistiqués? Ou un package graphique? Ou pour télécharger des outils open source pour créer des graphiques?

Désolé, la plupart des outils sont écrits pour les bases de données SQL. Si vous souhaitez générer des rapports, créer des graphiques ou faire quelque chose avec toutes les données de votre pile NoSQL, vous devrez commencer à coder. Les outils standard sont prêts à capturer les données d'Oracle, Microsoft SQL, MySQL et Postgres. Vos données sont en NoSQL? Ils y travaillent.

Et ils y travailleront un peu. Même s'ils sautent à travers tous les obstacles pour être opérationnels avec l'une des bases de données NoSQL, ils devront tout recommencer depuis le début pour gérer le système suivant. Il existe plus de 20 choix NoSQL différents, tous arborant leur propre philosophie et leur propre façon de travailler avec les données. Il était déjà assez difficile pour les fabricants d'outils de prendre en charge les idiosyncrasies et les incohérences dans SQL, mais il est encore plus compliqué de faire fonctionner les outils avec chaque approche NoSQL.

C'est un problème qui disparaîtra lentement. Les développeurs peuvent ressentir l'excitation de NoSQL, et ils vont modifier leurs outils pour travailler avec ces systèmes, mais cela prendra du temps. Peut-être qu'ils commenceront alors sur MongoDB, ce qui ne vous aidera pas car vous exécutez Cassandra. Les standards aident dans des situations comme celle-ci, et NoSQL n'est pas très exigeant.

Les lacunes de NoSQL en un mot

Toutes ces lacunes de NoSQL peuvent être réduites à une simple déclaration: NoSQL jette les fonctionnalités pour la vitesse. Si vous n'avez pas besoin de la fonctionnalité, tout ira bien, mais si vous en avez besoin à l'avenir, vous serez désolé.

Les révolutions sont endémiques à la culture technologique. Un nouveau groupe arrive et se demande pourquoi la dernière génération a construit quelque chose d'aussi complexe et a entrepris de démolir les anciennes institutions. Après un moment, ils commencent à comprendre pourquoi toutes les anciennes institutions étaient si complexes et ils recommencent à implémenter les fonctionnalités.

Nous voyons cela dans le monde NoSQL, car certains des projets commencent à ajouter des éléments qui ressemblent à des transactions, des schémas et des normes. Telle est la nature du progrès. Nous démolissons les choses uniquement pour les reconstruire. NoSQL est terminé avec la première phase de la révolution et il est maintenant temps pour la seconde. Le roi est mort. Longue vie au roi.

Articles Liés

  • NoSQL: de nouvelles bases de données pour de nouvelles applications
  • Premier aperçu: base de données Oracle NoSQL
  • Flexing NoSQL: MongoDB en revue
  • 10 conseils de performance essentiels pour MySQL
  • 10 outils MySQL essentiels pour les administrateurs
  • Maîtrisez MySQL dans le cloud Amazon
  • Le temps des normes NoSQL est maintenant

Cette histoire, «7 dures vérités sur la révolution NoSQL», a été publiée à l'origine sur .com. Suivez les derniers développements en matière de gestion de données sur .com. Pour connaître les derniers développements dans l'actualité des technologies commerciales, suivez .com sur Twitter.