Quelles sont les «étapes mentales» qu'un développeur doit suivre pour passer du SQL à NO-SQL (CouchDB, FathomDB, MongoDB, etc.)?

Question

Je pense fermement aux bases de données relationnelles et au codage efficace de celles-ci. La plupart de mon expérience est avec MySQL et SQL. J'aime beaucoup les choses que j'entends au sujet des bases de données basées sur des documents, particulièrement quand quelqu'un dans un podcast récent a mentionné d'énormes avantages de performance. Donc, si je vais suivre cette voie, quelles sont les étapes mentales que je dois suivre pour passer de SQL à NO-SQL?

Si cela fait une différence dans votre réponse, je suis un développeur C# principalement (aujourd'hui, de toute façon). Je suis habitué aux ORM comme EF et Linq à SQL. Avant les ORM, j'ai roulé mes propres objets avec des génériques et des gestionnaires de données. Peut-être que cela compte, peut-être que non.

Voici quelques-uns plus spécifiques:

1. Comment dois-je penser à joint?
2. Comment vais-je interroger sans une instruction SELECT?
3. Qu'arrive-t-il à mes objets stockés existants lorsque j'ajoute une propriété dans mon code?

(ne hésitez pas à ajouter vos propres questions ici)

Answer 1

Premièrement, chaque magasin NoSQL est différent. Ce n'est donc pas comme choisir entre Oracle ou Sql Server ou MySQL. Les différences entre eux peuvent être vastes. Par exemple, avec CouchDB, vous ne pouvez pas exécuter de requêtes ad-hoc (requêtes dynamiques si vous le souhaitez). Il est très bon pour les scénarios en ligne et hors ligne, et est suffisamment petit pour fonctionner sur la plupart des appareils. Il a une interface RESTful, donc pas de pilotes, pas de bibliothèques ADO.NET. Pour l'interroger, vous utilisez MapReduce (maintenant c'est très courant dans l'espace NoSQL, mais pas omniprésent) pour créer des vues, et celles-ci sont écrites dans plusieurs langues, bien que la plupart de la documentation soit pour Javascript. CouchDB est également conçu pour planter, c'est-à-dire si quelque chose ne va pas, il ne fait que redémarrer le processus (le processus Erlang, ou le groupe de processus liés qui est, et pas toute l'instance de CouchDB). MongoDB est conçu pour être très performant, avoir des pilotes, et semble être moins efficace pour beaucoup de gens dans le monde .NET à cause de cela. Je crois cependant que dans les situations de crash il est possible de perdre des données (cela n'offre pas le même niveau de garanties transactionnelles autour des écritures que fait CouchDB). Maintenant, les deux sont des bases de données de documents, et en tant que tels, ils partagent en commun que leurs données sont non structurées. Il n'y a pas de tables, pas de schéma défini - elles sont sans schémas. Ils ne sont pas comme un magasin de valeurs-clés, car ils insistent sur le fait que les données que vous persistez leur sont intelligibles. Avec CouchDB cela signifie l'utilisation de JSON, et avec MongoDB cela signifie l'utilisation de BSON.

Il y a beaucoup d'autres différences entre MongoDB et CouchDB et celles-ci sont considérées dans l'espace NoSQL comme très proches dans leur conception!

À part les bases de données de documents, il s'agit de solutions axées sur le réseau comme Neo4J, les banques de colonnes (orientées sur les colonnes plutôt que sur les lignes dans la persistance des données) et bien d'autres.Quelque chose qui est commun à la plupart des solutions NoSQL, autres que MapReduce, est qu'elles ne sont pas des bases de données relationnelles et que la majorité n'utilise pas la syntaxe de style SQL. L'interrogation typique suit un mode impératif de programmation plutôt que le style déclaratif de SQL.

Un autre trait généralement commun est que la cohérence absolue, telle qu'elle est généralement fournie par les bases de données relationnelles, est échangée contre d'éventuels modèles de cohérence. Mon conseil à tous ceux qui cherchent à utiliser une solution NoSQL serait de comprendre d'abord les exigences qu'ils ont, de comprendre les SLA (quel est le niveau de latence requis, quelle doit être la permanence de cette latence lorsque les solutions évoluent, quelle échelle la charge est-elle prévisible, la charge est-elle cohérente ou va-t-elle augmenter la cohérence de l'affichage des données si les utilisateurs voient toujours leurs propres écritures lorsqu'ils interrogent, si leurs écritures sont immédiatement visibles par tous les autres utilisateurs? ..). Comprenez que vous ne pouvez pas tout avoir, lisez le théorème de Brewers CAP, qui dit essentiellement que vous ne pouvez pas avoir une consistance absolue, une disponibilité à 100% et être tolérant à la partition (faire face lorsque les nœuds ne peuvent pas communiquer). Ensuite, examinez les différentes solutions NoSQL et commencez à éliminer celles qui ne sont pas conçues pour répondre à vos besoins, comprenez que le transfert d'une base de données relationnelle n'est pas trivial et a un coût associé (j'ai trouvé le coût de déplacement d'une organisation cette direction, en termes de réunions, de discussions, etc ... elle-même est très élevée, empêchant de se concentrer sur d'autres domaines de bénéfice potentiel). La plupart du temps vous n'aurez pas besoin d'ORM (la partie R de cette équation est simplement manquante), parfois la sérialisation binaire peut être correcte (avec quelque chose comme DB4O par exemple, ou un magasin de valeurs-clés), des choses comme le Newtonsoft JSON/BSON library peut aider, tout comme automapper. Je trouve que travailler avec C# 3 theere est un coût défini par rapport à travailler avec un langage dynamique comme, disons Python. Avec C# 4 cela peut s'améliorer un peu avec des choses comme ExpandoObject et Dynamic du DLR.

Pour regarder vos 3 questions spécifiques, avec tout cela dépend de la solution NoSQL vous adoptez, donc pas d'une réponse est possible, mais avec cette mise en garde, en termes très généraux:

1. Si la persistance du objet (ou agrégé plus probable) dans son ensemble, vos jointures seront généralement dans le code, même si vous pouvez faire cela via MapReduce.

2. Encore, cela dépend, mais avec Couch vous exécuteriez un GET sur HTTP contre une ressource spécifique, ou contre une vue MapReduce.

3. Très probablement rien. Gardez un œil sur les scénarios de sérialisation et de désérialisation. La difficulté que j'ai trouvée vient de la façon dont vous gérez les versions de votre code. Si la propriété est purement pour pousser à une interface (interface graphique, service Web), alors il a tendance à être moins un problème. Si la propriété est une forme d'état interne sur laquelle s'appuiera le comportement, cela peut devenir plus délicat.

Espérons que ça aide, bonne chance!

Answer 2

Il suffit de cesser de penser à la base de données.

Pensez à la modélisation de votre domaine. Construisez vos objets pour résoudre le problème en suivant de bons modèles et pratiques et ne vous inquiétez pas de la persistance.