Quand utiliser CouchDB vs RDBMS
Je regarde CouchDB, qui a un certain nombre de fonctionnalités attrayantes sur les bases de données relationnelles, notamment:
- interface REST/HTTP intuitive
- réplication facile
- données stockées sous forme de documents, plutôt que de tableaux normalisés
J'apprécie que ce n'est pas un produit mature et doit donc être adopté avec prudence, mais je me demande s'il s'agit en fait d'un remplacement viable pour un SGBDR (malgré la page d'introduction disant le contraire - http: //couchdb.Apache .org/docs/intro.html ).
- Dans quelles circonstances CouchDB serait-il un meilleur choix de base de données qu'un SGBDR (par exemple MySQL), par exemple en termes d'évolutivité, de conception + temps de développement, de fiabilité et de maintenance.
- Y a-t-il encore des cas où un SGBDR est toujours clairement le bon choix?
- Est-ce un choix, ou une solution hybride est-elle plus susceptible d'émerger comme meilleure pratique?
J'ai récemment assisté à la conférence NoSQL à Londres et je pense avoir une meilleure idée maintenant comment répondre à la question d'origine. J'ai également écrit un article de blog , et il y en a quelques autres bonns .
Points clés:
- Nous avons accumulé probablement 30 ans de connaissances en administration de bases de données relationnelles, nous ne devons donc pas les remplacer sans un examen attentif; les magasins de données non relationnels sont moins matures que les magasins relationnels, et sont donc intrinsèquement plus risqués à adopter
- Il existe différents types de stockage de données non relationnelles; certains sont des magasins de valeurs-clés, certains sont des magasins de documents, certains sont des bases de données graphiques
- Vous pouvez utiliser une approche hybride, par exemple une combinaison de SGBDR et de stockage de données graphiques pour un site de logiciel social
- Les magasins de données de document (par exemple CouchDB et MongoDB) sont probablement les plus proches des bases de données relationnelles et fournissent une structure de données JSON avec tous les champs présentés hiérarchiquement, ce qui évite d'avoir à faire des jointures de table et (certains pourraient soutenir) est une amélioration par rapport à l'objet traditionnel. cartographie relationnelle que la plupart des applications utilisent actuellement
- Les bases de données non relationnelles prennent en charge la réplication (y compris maître-maître); les bases de données relationnelles prennent également en charge la réplication, mais elles peuvent ne pas être aussi complètes que l'option non relationnelle
- De très grands sites tels que Twitter, Digg et Facebook utilisent Cassandra, qui est conçu à partir de zéro pour prendre en charge le clustering
- Les bases de données relationnelles conviennent probablement à 90% des cas
En résumé, le consensus semble être "procéder avec prudence".
Jusqu'à ce que quelqu'un donne une réponse plus approfondie, voici quelques avantages et inconvénients pour CouchDB
Avantages:
- vous n'avez pas besoin d'ajuster vos données dans l'une de ces formes normales embêtantes d'ordre supérieur
- vous pouvez à tout moment modifier le "schéma" de vos données
- vos données seront indexées exactement pour vos requêtes, vous obtiendrez donc des résultats en temps constant.
Les inconvénients:
- vous devez créer des vues pour chaque requête, c'est-à-dire que les requêtes de type ad hoc (telles que la concaténation de WHERE et de SORT dynamiques dans un SQL) ne sont pas disponibles.
- soit vous aurez des données redondantes, soit vous finirez par implémenter vous-même la logique de jointure et de tri "côté client" (par exemple, trier une relation plusieurs-à-plusieurs sur plusieurs champs)
Avantages ou inconvénients:
- créer vos vues n'est pas aussi simple qu'en SQL, c'est plus comme résoudre un puzzle. Dépend de votre type si c'est un pro ou un con :)
CouchDB est l'un des nombreux magasins de clés/valeurs disponibles, d'autres incluent des anciens comme BDB , des sites Web comme Persévérer , MongoDB et CouchDB, nouveaux super-rapides comme memcached (RAM uniquement) et Tokyo Cabinet , et d'énormes magasins comme Hadoop et BigTable de Google (MongoDB prétend également être sur cet espace).
Il y a certainement de la place pour les magasins de clés/valeurs et les bases de données relationnelles. Traditionnellement, la plupart des RDB sont considérés comme une couche supérieure à la clé/valeur. Par exemple, MySQL utilisait BDB comme backend optionnel pour les tables. En bref, les clés/valeurs ne connaissent rien aux champs et aux relations, qui sont les fondements de SQL.
Les magasins de clés/valeur sont généralement plus faciles à mettre à l'échelle, ce qui en fait un choix attrayant lors d'une croissance explosive, comme Twitter l'a fait. Bien sûr, cela signifie que toutes les relations entre les valeurs stockées doivent être gérées sur votre code, au lieu d'être simplement déclarées en SQL. L'approche de CouchDB consiste à stocker de gros "documents" dans la partie valeur, les rendant (principalement) autonomes, afin que vous puissiez obtenir la plupart des données nécessaires en une seule requête. De nombreux cas d'utilisation correspondent à cette idée, d'autres non.
Le thème actuel que je vois est qu'après le "Rails ne se redimensionne pas !!" peur, maintenant beaucoup de gens se rendent compte qu'il ne s'agit pas de votre framework web; mais sur le cache intelligent, pour éviter de frapper la base de données, et même la webapp lorsque cela est possible. L'étoile montante là-bas est memcached.
Comme toujours, tout dépend de vos besoins.
Celui-ci est une question difficile à répondre. Je vais donc essayer de mettre en évidence les domaines dans lesquels CouchDB pourrait travailler contre vous.
Les deux plus grandes sources de difficultés sur les listes de diffusion Couch Users et Dev que les gens ont sont:
- Jointures complexes de données.
- Carte/réduction en plusieurs étapes.
Couch Views est à peu près des îles en soi. Si vous devez agréger/fusionner/intersecter un ensemble de vues, vous devez à peu près le faire dans la couche application pour l'instant. Il existe quelques astuces que vous pouvez effectuer avec le classement des vues et des clés complexes pour faciliter les jointures, mais celles-ci ne vont jusqu'à présent que pour certains types de données. Cela peut ou non être habitable pour différentes applications. Cela étant dit, ce problème peut être réduit ou éliminé plusieurs fois en structurant vos données différemment.
Les commentaires des autres personnes sur cette question démontrent certains des différents types de données qui conviennent bien à CouchDB.
Une autre chose à garder à l'esprit est que la plupart du temps, les données dont vous pourriez avoir besoin pour combiner/fusionner/intersecter seraient de toute façon des données que vous feriez hors ligne dans une base de données SGBDR afin que vous ne perdiez rien en faisant de même dans CouchDB.
Réponse courte: Je pense que finalement CouchDB sera capable de gérer tout type de problème que vous souhaitez lui poser. Mais le niveau de confort que vous avez utilisé peut différer d'un développeur à l'autre. C'est un peu subjectif je pense. Il se trouve que j'aime utiliser un langage complet pour interroger mes données et garder plus de logique dans la couche application. Votre kilométrage peut varier.
Sam, vous devez prendre une autre approche avec CouchDB et en général avec une base de données basée sur une carte ou un document. Vous ne pouvez pas définir une contrainte, une telle unique, mais vous pouvez interroger des données pour vérifier si cet e-mail est utilisé et si cette connexion est également utilisée. C'est la bonne approche, vous devez changer d'avis.
Corrigez-moi si je me trompe. Couchdb est inutile dans les cas où vous devez valider l'unicité des documents sur plusieurs champs. Par exemple, il est impossible d'appliquer une règle de validation telle que "la connexion et le courrier électronique doivent être uniques" et conserver les données dans un état cohérent. Vous pouvez vérifier cela avant d'enregistrer le document, mais quelqu'un peut pousser avant vous et les données deviennent incohérentes.
Si vous travaillez avec des données tabulaires où il n'y a qu'une hiérarchie de données peu profonde, un système SGBDR est probablement votre meilleur choix. Il s'agit de l'utilisation principale des systèmes SGBDR, et la documentation et le support des outils sont très bons.
Pour des données plus imbriquées comme xml, une base de données de documents devrait fournir un accès plus rapide à vos données. De plus, le modèle de stockage ressemble davantage à celui des données, donc la récupération devrait être plus simple.