Exemple pratique pour chaque type de base de données (cas réels)

Question

Il existe plusieurs types de bases de données à des fins différentes, mais normalement MySQL est utilisé pour tout, car il s'agit de la base de données la plus connue. Juste pour donner un exemple dans mon entreprise, une application de big data a une base de données MySQL à un stade initial, ce qui est incroyable et entraînera de graves conséquences pour l'entreprise. Pourquoi MySQL? Tout simplement parce que personne ne sait comment (et quand) utiliser un autre SGBD.

Donc, ma question ne concerne pas les fournisseurs, mais le type de bases de données. Pouvez-vous me donner un exemple pratique de situations (ou applications) spécifiques pour chaque type de base de données où il est fortement recommandé de l'utiliser?

Exemple:

• Un réseau social doit utiliser le type X à cause de Y.

• MongoDB ou divan DB ne peut pas prendre en charge les transactions, donc Document DB n'est pas adapté à une application pour une banque ou un site d'enchères.

Etc...

Relationnel: MySQL , PostgreSQL , SQLite , Firebird , MariaDB , Oracle DB , serveur SQL , IBM DB2 , IBM Informix , Teradata

Objet: ZODB , DB4O , - Eloquera , Versant , DB d'objectivité , VelocityDB

Bases de données graphiques: AllegroGraph , Neo4j , OrientDB , - InfiniteGraph , graphbase , sparkledb , flockdb , BrightstarDB

Magasins de valeurs clés: Amazon DynamoDB , Redis , Riak , Voldemort , FoundationDB , leveldb , BangDB , KAI , hamsterdb , Tarantool , Maxtable , HyperDex , Genom , Memcachedb

Famille de colonnes: Big table , Hbase , hyper table , Cassandra , Apache Accumulo

Magasins RDF: Apache Jena , Sesame

Bases de données multimodèles: arangodb , Datomic , Orient DB , - FatDB , AlchemyDB

Document: Mongo DB , Couch DB , Rethink DB , DB Raven , terrastore , Jas DB , Raptor DB , djon DB , - EJDB , denso DB , Couchbase

Bases de données XML: BaseX , Sedna , eXist

Hiérarchique: InterSystems Caché , GT.M merci à @Laurent Parenteau

daniel__ · Accepted Answer

J'ai trouvé deux articles impressionnants sur ce sujet. Tous les crédits à highscalability.com . Les informations contenues dans cette réponse sont transcrites à partir de ces articles:

5+ cas d'utilisation pour choisir votre prochaine base de données NoSQL

Pourquoi diable utilisez-vous réellement NoSQL?

Si votre application a besoin ...

• transactions complexes parce que vous ne pouvez pas vous permettre de perdre des données ou si vous souhaitez un modèle de programmation de transactions simple, regardez une base de données relationnelle ou de grille.

• Exemple: un système d'inventaire qui pourrait vouloir plein ACIDE . J'étais très mécontent quand j'ai acheté un produit et ils ont dit plus tard qu'ils étaient en rupture de stock. Je ne voulais pas de transaction compensée. Je voulais mon article!

• à l'échelle alors NoSQL ou SQL peut fonctionner. Recherchez les systèmes qui prennent en charge la mise à l'échelle, le partitionnement, l'ajout et la suppression en direct de machines, l'équilibrage de charge, le partage et le rééquilibrage automatiques et la tolérance aux pannes.

• pour toujours pouvoir écrire dans une base de données car vous avez besoin disponibilité alors regardez Bigtable Clones qui présentent une cohérence éventuelle.

• pour gérer de nombreuses petites lectures et écritures continues , qui peuvent être volatiles, puis regardez le document ou la valeur-clé ou les bases de données offrant un accès rapide en mémoire . Considérez également SSD .

• pour implémenter les opérations de réseaux sociaux , vous voudrez peut-être d'abord une base de données Graph ou une seconde, une base de données comme Riak qui prend en charge les relations. Une base de données relationnelle en mémoire avec de simples jointures SQL peut suffire pour de petits ensembles de données. Redis 'Les opérations de définition et de liste peuvent également fonctionner.

• pour opérer sur une grande variété de modèles d'accès et de types de données puis consulter une base de données de documents, ils sont généralement flexibles et fonctionnent bien.

• rapports hors ligne puissants avec de grands ensembles de données puis regardez Hadoop premier et deuxième, les produits qui prennent en charge MapReduce =. Soutenir MapReduce n'est pas la même chose que d'être bon dans ce domaine.

• pour s'étendre sur plusieurs centres de données puis regarder Bigtable Clones et autres produits qui offrent une option distribuée qui peut gérer le long latences et sont partition tolérantes .

• pour construire [~ # ~] crud [~ # ~] applications puis regarder une base de données de documents, elles facilitent l'accès à des données complexes sans jointures .

• recherche intégrée puis regardez Riak .

• pour opérer sur les structures de données comme les listes, les ensembles, les files d'attente, publier-s'abonner puis regarder Redis . Utile pour le verrouillage distribué, les journaux plafonnés et bien plus encore.

• convivialité du programmeur sous la forme de types de données conviviaux comme JSON, HTTP, REST, Javascript, puis regardez d'abord les bases de données de documents, puis les bases de données de valeurs-clés .

• transactions combinées avec vues matérialisées pour flux de données en temps réel puis regardez VoltDB . Idéal pour les cumuls de données et fenêtrage temporel .

• prise en charge au niveau de l'entreprise et SLA recherchez ensuite un produit qui se fait un devoir de répondre à ce marché. Membase est un exemple.

• pour enregistrer des flux continus de données qui peuvent ne pas avoir de garanties de cohérence nécessaires, puis regardez Bigtable Clones car ils fonctionnent généralement sur les systèmes de fichiers distribués qui peuvent gérer de nombreuses écritures.

• être aussi simple que possible à opérer puis chercher une solution hébergée ou PaaS car ils feront tout le travail pour toi.

• à vendre à clients entreprises puis envisager une base de données relationnelle car ils sont habitués à la technologie relationnelle.

• pour construire dynamiquement des relations entre des objets qui ont des propriétés dynamiques puis considérer un Base de données de graphes car souvent ils ne nécessitent pas de schéma et les modèles peuvent être construits de manière incrémentielle par programmation.

• pour prendre en charge les grands médias puis regarder les services de stockage comme S . NoSQL les systèmes ont tendance à ne pas gérer les gros BLOBS , bien que MongoDB possède un service de fichiers.

• pour télécharger en masse beaucoup de données rapidement et efficacement, puis recherchez un produit qui prend en charge ce scénario. La plupart ne le feront pas car ils ne prennent pas en charge les opérations en masse.

• un chemin de mise à niveau plus facile puis utilisez un système de schéma fluide comme une base de données de documents ou une base de données de valeurs-clés car il prend en charge les champs facultatifs, l'ajout de champs et le champ suppressions sans avoir à créer une infrastructure de migration de schéma complète.

• pour implémenter les contraintes d'intégrité puis choisir une base de données qui supporte SQL DDL , implémenter les dans des procédures stockées, ou les implémenter dans le code d'application.

• a profondeur de jointure très profonde puis utilisez une base de données graphique car elles prennent en charge une navigation extrêmement rapide entre les entités.

• pour déplacer le comportement près des données afin que les données n'aient pas à être déplacées sur le réseau, puis regardez les procédures stockées d'une sorte ou d'une autre. Ceux-ci peuvent être trouvés dans les bases de données relationnelles, de grille, de document et même de valeur-clé.

• pour mettre en cache ou stocker les données BLOB puis regarder un magasin de valeurs-clés. La mise en cache peut contenir des bits de pages Web ou enregistrer des objets complexes dont la connexion dans une base de données relationnelle était coûteuse, pour réduire la latence, etc.

• un antécédent prouvé comme ne pas corrompre les données et simplement travailler puis choisir un produit établi et lorsque vous appuyez sur la mise à l'échelle (ou d'autres problèmes) utilisez l'un des solutions de contournement courantes (mise à l'échelle, optimisation, memcached, sharding , dénormalisation , etc.).

• types de données fluides car vos données ne sont pas de nature tabulaire, ou nécessitent un nombre flexible de colonnes, ou ont une structure complexe, ou varient selon l'utilisateur (ou autre), puis regardez les bases de données Document, Key-value et Bigtable Clone. Chacun a beaucoup de flexibilité dans ses types de données.

• d'autres unités commerciales pour exécuter des requêtes relationnelles rapides afin que vous n'ayez pas à tout réimplémenter puis à utiliser une base de données qui prend en charge SQL.

• pour fonctionner dans le cloud et profiter automatiquement de toutes les fonctionnalités du cloud, nous ne serons peut-être pas encore là.

• prise en charge des index secondaires afin que vous puissiez rechercher des données par différentes clés puis consulter les bases de données relationnelles et Cassandra nouveau - index secondaire support.

• créer un ensemble de données toujours croissant (vraiment BigData ) auquel on accède rarement, puis regarder Bigtable Clone qui répartira les données sur un système de fichiers distribué.

• pour intégrer avec d'autres services puis vérifier si la base de données fournit une sorte de fonctionnalité de synchronisation en écriture afin que vous puissiez capturer les modifications de la base de données et les introduire dans d'autres systèmes pour assurer la cohérence.

• tolérance aux pannes vérifiez la durabilité des écritures face aux pannes de courant, aux partitions et aux autres scénarios de panne.

• Pousser l'enveloppe technologique dans une direction que personne ne semble aller alors la construire soi-même car c'est ce qu'il faut parfois pour être génial.

• travailler sur une plateforme mobile puis regarder CouchDB/ Mobile couchbase .

Cas d'utilisation généraux (NoSQL)

• Bigness . NoSQL est considéré comme un élément clé d'une nouvelle pile de données prenant en charge: les mégadonnées, le grand nombre d'utilisateurs, le grand nombre d'ordinateurs, les grandes chaînes d'approvisionnement, la grande science, etc. Quand quelque chose devient si massif qu'il doit devenir massivement distribué, NoSQL est là, bien que tous les systèmes NoSQL ne visent pas gros. Bigness peut être dans de nombreuses dimensions différentes, pas seulement en utilisant beaucoup d'espace disque.

• Performances d'écriture massives. Il s'agit probablement de l'usage canonique basé sur l'influence de Google. Volume élevé. Facebook doit stocker 135 milliards de messages par mois ^{(en 2010)}. Twitter, par exemple, a le problème de stocker 7 To/données par jour ^{(en 2010)} avec la perspective de doubler cette exigence plusieurs fois par an. Il s'agit de données trop volumineuses pour tenir sur un problème de nœud. À 80 Mo/s, il faut une journée pour stocker 7 To, les écritures doivent donc être réparties sur un cluster, ce qui implique un accès par valeur-clé, MapReduce, la réplication, la tolérance aux pannes, les problèmes de cohérence et tout le reste. Pour des écritures plus rapides, des systèmes en mémoire peuvent être utilisés.

• Accès rapide aux valeurs-clés. C'est probablement la deuxième vertu la plus citée de NoSQL dans l'état d'esprit général. Lorsque la latence est importante, il est difficile de battre le hachage sur une clé et de lire la valeur directement depuis la mémoire ou en une seule recherche de disque. Tous les produits NoSQL ne concernent pas un accès rapide, certains sont plus axés sur la fiabilité, par exemple. mais ce que les gens voulaient depuis longtemps était un meilleur memcached et de nombreux systèmes NoSQL le proposent.

• Schéma flexible et types de données flexibles. Les produits NoSQL prennent en charge toute une gamme de nouveaux types de données, ce qui constitue un domaine d'innovation majeur dans NoSQL. Nous avons: orienté colonne, graphique, structures de données avancées, orienté document et valeur-clé. Les objets complexes peuvent être facilement stockés sans beaucoup de mappage. Les développeurs adorent éviter les schémas complexes et les frameworks ORM . Le manque de structure permet beaucoup plus de flexibilité. Nous avons également des types de données compatibles avec les programmes et les programmeurs comme JSON.

• Migration de schéma. La non-schématisation facilite le traitement des migrations de schéma sans trop de soucis. Les schémas sont dans un sens dynamiques car ils sont imposés par l'application au moment de l'exécution, de sorte que différentes parties d'une application peuvent avoir une vue différente du schéma.

• Disponibilité en écriture. Vos écritures ont-elles besoin de réussir quoi qu'il arrive? Ensuite, nous pouvons entrer dans le partitionnement, CAP , cohérence éventuelle et tout ce jazz.

• Facilité de maintenance, administration et opérations plus faciles. Ceci est très spécifique au produit, mais de nombreux fournisseurs NoSQL tentent de gagner en adoption en facilitant leur adoption par les développeurs. . Ils consacrent beaucoup d'efforts à la facilité d'utilisation, à l'administration minimale et aux opérations automatisées. Cela peut entraîner une baisse des coûts d'exploitation, car il n'est pas nécessaire d'écrire du code spécial pour mettre à l'échelle un système qui n'a jamais été conçu pour être utilisé de cette façon.

• Aucun point de défaillance unique. Tous les produits n'offrent pas cela, mais nous constatons une convergence certaine vers une configuration relativement facile et facile à gérer et une haute disponibilité avec équilibrage automatique de la charge et dimensionnement du cluster. Un partenaire cloud parfait.

• Informatique parallèle généralement disponible. Nous voyons MapReduce incorporé dans des produits, ce qui fait de l'informatique parallèle quelque chose qui sera une partie normale du développement à l'avenir.

• Facilité d'utilisation du programmeur. L'accès à vos données devrait être facile. Bien que le modèle relationnel soit intuitif pour les utilisateurs finaux, comme les comptables, il n'est pas très intuitif pour les développeurs. Les programmeurs gèrent les clés, les valeurs, JSON, les procédures stockées Javascript, HTTP, etc. NoSQL est destiné aux programmeurs. Ceci est un coup d'État dirigé par les développeurs. La réponse à un problème de base de données ne peut pas toujours être d'embaucher une personne vraiment bien informée DBA , obtenir un schéma correct, dénormaliser un peu, etc., les programmeurs préféreraient un système qu'ils peuvent faire travailler pour eux-mêmes. Il ne devrait pas être si difficile de faire fonctionner un produit. L'argent fait partie du problème. Si la mise à l'échelle d'un produit coûte cher, n'allez-vous pas choisir le produit moins cher que vous contrôlez, qui est plus facile à utiliser et plus facile à mettre à l'échelle?

• Utilisez le bon modèle de données pour le bon problème. Différents modèles de données sont utilisés pour résoudre différents problèmes. Par exemple, beaucoup d'efforts ont été déployés pour caler les opérations de graphe dans un modèle relationnel, mais cela ne fonctionne pas. N'est-il pas préférable de résoudre un problème de graphe dans une base de données de graphe? Nous voyons maintenant une stratégie générale pour essayer de trouver la meilleure adéquation entre un problème et une solution.

• Évitez de toucher le mur. De nombreux projets ont heurté un type de mur dans leur projet. Ils ont épuisé toutes les options pour faire évoluer leur système ou fonctionner correctement et se demandent quoi de plus? Il est réconfortant de sélectionner un produit et une approche qui peuvent sauter par-dessus le mur en évoluant linéairement en utilisant des ressources ajoutées progressivement. À une époque, ce n'était pas possible. Il a fallu tout construire sur mesure, mais cela a changé. Nous voyons maintenant des produits prêts à l'emploi utilisables qu'un projet peut facilement adopter.

• Prise en charge des systèmes distribués. Tout le monde n'est pas préoccupé par l'échelle ou les performances au-delà de ce qui peut être réalisé par des systèmes non-NoSQL. Ce dont ils ont besoin, c'est d'un système distribué qui peut s'étendre sur les centres de données tout en gérant les scénarios de défaillance sans hoquet. Les systèmes NoSQL, parce qu'ils se sont concentrés sur l'échelle, ont tendance à exploiter les partitions, à ne pas utiliser de protocoles de cohérence strictes et sont donc bien positionnés pour fonctionner dans des scénarios distribués.

• compromis CAP ajustables . Les systèmes NoSQL sont généralement les seuls produits avec un "curseur" pour choisir où ils veulent atterrir. le spectre de la PAC. Les bases de données relationnelles choisissent une cohérence forte, ce qui signifie qu'elles ne peuvent tolérer une défaillance de partition. En fin de compte, il s'agit d'une décision commerciale qui devrait être décidée au cas par cas. Votre application se soucie-t-elle même de la cohérence? Est-ce que quelques gouttes sont OK? Votre application a-t-elle besoin d'une cohérence forte ou faible? La disponibilité est-elle plus importante ou la cohérence? La baisse coûtera-t-elle plus cher que de se tromper? C'est bien d'avoir des produits qui vous donnent le choix.

• Cas d'utilisation plus spécifiques

• Gestion de grands flux de données non transactionnelles: journaux Apache, journaux d'applications, journaux MySQL , flux de clics, etc.

• Synchronisation des données en ligne et hors ligne. C'est une niche CouchDB a ciblé.

• Temps de réponse rapides sous toutes les charges.

• Éviter les jointures lourdes lorsque la charge des requêtes pour les jointures complexes devient trop importante pour un RDBMS .

• Systèmes logiciels temps réel où une faible latence est critique. Les jeux en sont un exemple.

• Applications où une grande variété de modèles d'écriture, de lecture, de requête et de cohérence différents doivent être pris en charge. Il existe des systèmes optimisés pour 50% de lectures, 50% d'écritures, 95% d'écritures ou 95% de lectures. Applications en lecture seule nécessitant une vitesse et une résilience extrêmes, des requêtes simples et pouvant tolérer des données légèrement périmées. Applications nécessitant des performances modérées, accès en lecture/écriture, requêtes simples, données entièrement autorisées. Une application en lecture seule qui nécessite des requêtes complexes.

• Équilibrage de charge pour tenir compte des données et des concentrations d'utilisation et pour aider à occuper les microprocesseurs.

• Insertions, mises à jour et requêtes en temps réel.

• Données hiérarchiques comme les discussions filetées et l'explosion de pièces.

• Création de table dynamique.

• Applications à deux niveaux où les données à faible latence sont mises à disposition via une interface NoSQL rapide, mais les données elles-mêmes peuvent être calculées et mises à jour par des applications Hadoop à latence élevée ou d'autres applications à faible priorité.

• Lecture séquentielle des données. Le bon modèle de stockage de données sous-jacent doit être sélectionné. Un arbre B n'est peut-être pas le meilleur modèle pour les lectures séquentielles.

• Découpage d'une partie du service qui peut nécessiter de meilleures performances/évolutivité sur son propre système. Par exemple, les connexions utilisateur peuvent nécessiter des performances élevées et cette fonctionnalité peut utiliser un service dédié pour atteindre ces objectifs.

• Mise en cache. Un niveau de mise en cache haute performance pour les sites Web et autres applications. Un exemple est un cache pour le système d'agrégation de données utilisé par le grand collisionneur de hadrons. Vote.

• Compteurs de pages vues en temps réel.

• Enregistrement utilisateur, profil et données de session.

• Systèmes de gestion de documents, de catalogues et de gestion de contenu. Ceux-ci sont facilités par la possibilité de stocker des documents complexes dans leur ensemble plutôt qu'organisés en tableaux relationnels. Une logique similaire s'applique à l'inventaire, aux paniers d'achat et à d'autres types de données structurées.

• Archivage. Stockage d'un grand flux continu de données qui est toujours accessible en ligne. Bases de données orientées document avec un schéma flexible qui peut gérer les modifications de schéma au fil du temps.

• Analytics. Utilisez MapReduce, Hive ou Pig pour effectuer des requêtes analytiques et des systèmes évolutifs qui prennent en charge des charges d'écriture élevées.

• Travailler avec types de données hétérogènes , par exemple, différents types de supports à un niveau générique.

• Systèmes embarqués. Ils ne veulent pas les frais généraux de SQL et des serveurs, ils utilisent donc quelque chose de plus simple pour le stockage.

• Un jeu de "marché", où vous possédez des bâtiments dans une ville. Vous voulez que la liste de construction de quelqu'un s'affiche rapidement, de sorte que vous partitionnez sur la colonne propriétaire de la table de construction, de sorte que la sélection soit partitionnée. Mais quand quelqu'un achète le bâtiment de quelqu'un d'autre, vous mettez à jour la colonne propriétaire avec le prix.

• JPL utilise SimpleDB pour stocker rover les attributs du plan. Les références sont conservées dans un blob de plan complet dans S . ^(source)

• Organismes fédéraux chargés de l'application des lois suivi des Américains en temps réel en utilisant des cartes de crédit, des cartes de fidélité et des réservations de voyage.

• Détection de fraude en comparant les transactions aux modèles connus en temps réel.

• Aide au diagnostic la typologie des tumeurs en intégrant l'histoire de chaque patient.

• Base de données en mémoire pour les situations de mise à jour élevée, comme un site Web qui affiche l'heure "dernière activité" de chacun (pour le chat peut-être). Si les utilisateurs effectuent une activité toutes les 30 secondes, vous serez à peu près à votre limite avec environ 5000 utilisateurs simultanés.

• Gestion des requêtes multi-partitions à basse fréquence à l'aide de vues matérialisées tout en continuant à traiter les données de streaming à haute fréquence.

• Files d'attente prioritaires.

• Exécution de calculs sur des données mises en cache, en utilisant une interface conviviale pour le programme, sans avoir à passer par un ORM .

• niq un grand ensemble de données en utilisant de simples colonnes clé-valeur.

• Pour continuer à interroger rapidement, les valeurs peuvent être regroupées en différentes tranches de temps.

• Calcul de l'intersection de deux ensembles massifs, où une jointure serait trop lente.

• A chronologie sur Twitter .

Redis use cases, VoltDB use cases and more find here .

scalabl3 · Answer

Cette question est presque impossible à répondre en raison de la généralité. Je pense que vous cherchez une sorte de réponse facile problème = solution. Le problème est que chaque "problème" devient de plus en plus unique à mesure qu'il devient une entreprise.

Comment appelez-vous un réseau social? Gazouillement? Facebook? LinkedIn? Débordement de pile? Ils utilisent tous des solutions différentes pour différentes pièces, et il peut exister de nombreuses solutions utilisant l'approche polyglotte. Twitter a un concept semblable à un graphique, mais il n'y a que des connexions à 1 degré, des suiveurs et des suivis. LinkedIn, d'autre part, montre comment les gens sont connectés au-delà du premier degré. Il s'agit de deux besoins de traitement et de données différents, mais tous deux sont des "réseaux sociaux".

Si vous avez un "réseau social" mais ne faites aucun mécanisme de découverte, vous pouvez facilement utiliser n'importe quel magasin de valeurs-clés de base le plus probable. Si vous avez besoin de hautes performances, d'une échelle horizontale et que vous aurez des index secondaires ou une recherche en texte intégral, vous pouvez utiliser Couchbase .

Si vous effectuez un apprentissage automatique en plus des données de journal que vous collectez, vous pouvez intégrer Hadoop avec Hive ou Pig, ou Spark/Shark. Ou vous pouvez faire une architecture lambda et utiliser de nombreux systèmes différents avec Storm.

Si vous effectuez une découverte via des requêtes de type graphique qui vont au-delà des sommets du 2e degré et filtrent également les propriétés Edge, vous envisagerez probablement des bases de données graphiques au-dessus de votre magasin principal. Cependant, les bases de données graphiques ne sont pas de bons choix pour le magasin de sessions ou comme magasins à usage général, vous aurez donc besoin d'une solution polyglotte pour être efficace.

Quelle est la vitesse des données? échelle? comment voulez-vous le gérer. Quelles sont les compétences dont vous disposez dans l'entreprise ou la startup. Il y a plusieurs raisons pour lesquelles ce n'est pas une simple question et réponse.

naXa · Answer

Une courte lecture utile spécifique à la sélection de la base de données: Comment choisir une base de données NoSQL? . Je vais souligner les points clés dans cette réponse.

Valeur-clé vs orienté document

Magasins de valeurs-clés

Si vous avez une structure de données claire définie de sorte que toutes les données aient exactement une clé, optez pour un magasin de valeurs-clés. C'est comme si vous disposiez d'une grande table de hachage, et les gens l'utilisent principalement pour les magasins de cache ou des données clairement basées sur des clés. Cependant, les choses commencent à devenir un peu désagréables lorsque vous devez interroger les mêmes données sur la base de plusieurs clés!

Certains magasins de valeurs clés sont: memcached , Redis , Aerospike .

La conception de votre modèle de données autour d'un magasin de valeurs-clés comporte deux éléments importants:

Vous devez connaître tous les cas d'utilisation à l'avance et vous ne pouvez pas modifier les champs interrogeables dans vos données sans une nouvelle conception.
N'oubliez pas que si vous souhaitez conserver plusieurs clés autour des mêmes données dans un magasin de valeurs-clés, les mises à jour de plusieurs tables/compartiments/collections/tout ce qui n'est PAS atomique. Vous devez vous en occuper vous-même.

Orienté document

Si vous vous éloignez simplement du SGBDR et que vous souhaitez conserver vos données de la manière la plus objective et la plus proche possible d'une structure de type tableau, la structure du document est la solution! Particulièrement utile lorsque vous créez une application et que vous ne souhaitez pas vous occuper de la conception des tables RDBMS dès le début (au stade du prototypage) et votre schéma pourrait changer radicalement au fil du temps. Notez cependant:

Les indices secondaires peuvent ne pas fonctionner aussi bien.
Les transactions ne sont pas disponibles.

Les bases de données orientées documents les plus courantes sont: MongoDB , Couchbase .

Comparaison des bases de données NoSQL à valeur-clé

memcached

Cache en mémoire
Pas de persistance
TTL pris en charge
clustering côté client uniquement (le client stocke la valeur sur plusieurs nœuds). Évolutivité horizontale via le client.
Pas bon pour les valeurs/documents de grande taille

Redis

Cache en mémoire
Disque pris en charge - sauvegarde et reconstruction à partir du disque
TTL pris en charge
Super rapide (voir benchmarks )
Prise en charge de la structure de données en plus de la valeur-clé
Le support de clustering n'est pas encore suffisamment mature. Évolutivité verticale (voir spécification Redis Cluster )
La mise à l'échelle horizontale peut être délicate.
Prend en charge index secondaires

Aerospike

Comparaison des bases de données NoSQL orientées document

MongoDB

Vite
Mature et stable - riche en fonctionnalités
Prise en charge des basculements
Lectures évolutives horizontalement - lecture à partir d'une réplique/secondaire
Écrit pas évolutif horizontalement sauf si vous utilisez des fragments de mongo
Prend en charge les requêtes avancées
Prend en charge plusieurs index secondaires
L'architecture Shards devient délicate, non évolutive au-delà d'un point où vous avez besoin d'index secondaires. Le déploiement de fragments élémentaires nécessite au moins 9 nœuds.
Les verrous au niveau du document sont un problème si vous avez un taux d'écriture très élevé

Serveur Couchbase

Vite
Amas éclaté au lieu de maître-esclave de mongodb
Prise en charge du basculement à chaud
Évolutif horizontalement
Prend en charge les index secondaires via les vues
Courbe d'apprentissage plus grande que MongoDB
Prétend être plus rapide