Exemple concret pour chaque type de base de données (cas réels) [en attente]

• d'autres unités d'affaires de exécution rapide des requêtes relationnelles afin de ne pas avoir à ré-écrire tout, puis de l'utilisation d'une base de données qui prend en charge SQL.

* à opérez dans le nuage et profitez automatiquement de toutes les fonctionnalités du nuage, alors nous n'en sommes peut-être pas encore là.

* prise en charge de index secondaires pour que vous puissiez rechercher des données par différentes clés puis regarder les bases de données relationnelles et Cassandra 's nouveau index secondaire prise en charge.

• créer un ensemble toujours croissant de données (vraiment BigData ) qui est rarement accessible alors regardez Bigtable Clone qui diffusera les données sur un système de fichiers distribués.

• l'intégration avec d'autres services , puis vérifiez si la base de données fournit une sorte d'écriture derrière fonctionnalité de synchronisation de sorte que vous pouvez capturer les modifications de base de données et à les transférer dans d'autres systèmes afin d'assurer la cohérence.

• tolérance de panne vérifier comment les Écritures durables sont dans les pannes de courant de face, les cloisons, et d'autres scénarios de défaillance.

• pour travailler sur une plate-forme mobile alors regardez CouchDB/ couchbase Mobile .

Usage Général Cas (NoSQL)

• Grandeur . Le NoSQL est vu comme un élément clé d'une nouvelle donnée de la pile à l'appui: big data, de grands nombres d'utilisateurs, un grand nombre d'ordinateurs, big chaînes d'approvisionnement, big science, et ainsi de suite. Quand quelque chose devient si massif qu'il doit être massivement distribué, NoSQL est là, bien que tous les systèmes NoSQL ne ciblent pas grand. Bigness peut être à travers de nombreuses dimensions différentes, pas seulement en utilisant beaucoup d'espace disque.

• Massif des performances d'écriture. c'est probablement l'usage canonique basé sur L'influence de Google. Le volume est élevé. Facebook doit stocker 135 milliards de messages par mois ^{(en 2010)} . Twitter, par exemple, a le problème de stocker 7 TB/données par jour ^{(en 2010)} avec la perspective de cette exigence doubler plusieurs fois par an. Ce sont les données est trop grand pour s'adapter sur un problème de noeud. À 80 MB / s, il faut un jour pour stocker 7TB, donc les Écritures doivent être distribuées sur un cluster, ce qui implique l'accès aux valeurs clés, MapReduce, réplication, tolérance aux défauts, problèmes de cohérence, et tout le reste. Pour des Écritures plus rapides, des systèmes en mémoire peuvent être utilisés.

• Fast valeur-clé d'accè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 la clé et la lecture de la valeur directement de la mémoire ou dans aussi peu qu'un disque cherchent. Tous les produits NoSQL ne sont pas axés sur l'accès rapide, certains sont davantage axés sur la fiabilité, par exemple. mais ce que les gens veulent depuis longtemps, c'est un meilleur memcached et de nombreux systèmes NoSQL offrent cela.

• Flexible schéma flexible et les types de données. les produits NoSQL prennent en charge toute une gamme de nouveaux types de données, et il s'agit d'un domaine majeur d'innovation 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 aiment éviter les schémas complexes et ORM cadres. Le manque de structure permet beaucoup plus de souplesse. Nous avons aussi des types de données compatibles, comme JSON, qui sont compatibles avec les programmes et les programmeurs.

• Schéma de migration. Schemalessness rend plus facile de traiter avec schema migrations sans tellement inquiétant. Les schémas sont dans un sens dynamiques parce qu'ils sont imposés par l'application à l'exécution, de sorte que différentes parties d'une application peuvent avoir une vue différente du schéma.

• Write disponibility. vos écrits doivent-ils réussir quoi qu'il arrive? Puis nous pouvons entrer dans le partitionnement, CAP , consistance éventuelle et tout ce jazz.

• facilité de maintenance, d'administration et d'exploitation. C'est très spécifique au produit, mais de nombreux fournisseurs de NoSQL essaient d'obtenir l'adoption en facilitant l'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 conduire à des coûts d'exploitation plus faibles car le code spécial n'a pas à être écrit à l'échelle d'un système qui n'a jamais été prévu pour être utilisé de cette façon.

• Aucun point de défaillance unique. tous les produits ne répondent pas à cette exigence, mais nous observons une convergence certaine sur une grande disponibilité relativement facile à configurer et à gérer avec l'équilibrage automatique de la charge et le dimensionnement des clusters. Un partenaire cloud parfait.

• Généralement disponibles de calcul parallèle. nous voyons MapReduce cuit en produits, ce qui rend le calcul parallèle quelque chose qui sera une partie normale du développement à l'avenir.

• Programmeur facilité d'utilisation. accéder à 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. Programmeurs grok clés, valeurs, JSON, procédures stockées Javascript, HTTP, et ainsi de suite. NoSQL est pour les programmeurs. C'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 un très bien informé DBA , obtenir votre schéma d'accord, dénormaliser un peu, etc., les programmeurs préféreraient un système qu'ils peuvent faire fonctionner pour eux-mêmes. Ça ne devrait pas être si dur de rendre un produit performant. L'argent est une partie de la question. Si cela coûte cher de dimensionner un produit, alors n'irez-vous pas avec le produit meilleur marché, que vous contrôlez, qui est plus facile à utiliser, et qui est plus facile à dimensionner?

• 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ème. Beaucoup d'efforts ont été déployés, par exemple, pour caler les opérations des graphes 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 consistant à tenter de trouver la meilleure adéquation entre un problème et une solution.

• Evitez de frapper le mur. de nombreux projets ont heurté un mur dans leur projet. Ils ont épuisé toutes les options pour faire leur échelle système ou effectuer correctement et vous vous demandez quelle est la prochaine étape? Il est réconfortant de choisir un produit et une approche qui peuvent sauter par-dessus le mur en adoptant une échelle linéaire à l'aide de ressources incrémentalement ajoutées. À une époque, ce n'était pas possible. Il a fallu tout construire sur mesure, mais ça a changé. Nous voyons maintenant des produits hors de la boîte utilisables qu'un projet peut facilement adopter.

• Distribuée des systèmes de soutien. tout le monde N'est pas inquiet au sujet de l'échelle ou de la performance 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é capable de couvrir les datacenters tout en manipulant des scénarios de défaillance sans problème. NoSQL systèmes, parce qu'ils ont mis l'accent sur l'échelle, ont tendance à exploiter les partitions, ont tendance à ne pas utiliser de lourds protocoles de cohérence stricte, et sont donc bien positionnés pour fonctionner dans des scénarios distribués.

• réglage de la PAC compromis . NoSQL systèmes sont généralement les seuls produits avec un "curseur" pour choisir où ils veulent atterrir sur le spectre CAP. Les bases de données relationnelles trouvent une forte cohérence, ce qui signifie qu'elles ne peuvent tolérer une défaillance de la partition. En fin de compte, c'est une décision d'affaires et doit être décidé au cas par cas. Est-ce que votre application se soucie même de cohérence? Quelques gouttes OK? Votre application a-t-elle besoin d'une cohérence forte ou faible? La disponibilité est-elle plus importante ou l'uniformité est-elle plus importante? Est-ce que ça coûtera plus cher d'être déprimé que d'avoir tort? C'est agréable d'avoir des produits de que vous donner un choix.

• Plus Spécifiques Du Cas D'Utilisation

• Gestion de grands flux de données non transactionnelles: logs Apache, journaux d'application, MySQL des journaux, clickstreams, etc.

• temps de réponse Rapide, en vertu de toutes les charges.

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

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

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

• Dynamique de la création de la table.

• données Séquentielles de lecture. 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 des lectures séquentielles.

• découpage d'une partie du service qui pourrait nécessiter une meilleure performance/évolutivité sur son propre système. Par exemple, les logins des utilisateurs peuvent devoir être très performants et cette fonctionnalité pourrait utiliser un service dédié pour atteindre ces objectifs.