Faiblesses avec différents types de bases de données NoSQL

10

Voici ma question: quelles sont les faiblesses des différents types de bases de données NoSQL? Plus précisément, quelles sont les faiblesses des magasins de valeurs-clés, des magasins de données graphiques et des magasins de documents?

J'ai eu du mal à trouver des forces, mais les documents sur les faiblesses semblent être plus rares.

Edit: Par rapport à l'autre et aux bases de données relationnelles.

database database-design nosql

— Aedilum
source

7

La plus grande force / faiblesse de tout magasin de données distribuées provient du théorème CAP. Voir http://blog.nahurst.com/visual-guide-to-nosql-systems pour un aperçu rapide de ce que cela signifie dans la pratique pour un grand nombre de systèmes NoSQL qui existent.

— btilly
source

1

Notez que ce n'est pas vraiment un inconvénient particulier de NOSQL. Le théorème CAP s'applique également à tout magasin de données distribuées: SQL, NOSQL, relationnel ou non relationnel.

— nvogel

6

Si vous les comparez à des bases de données relationnelles, la faiblesse évidente est que les magasins de valeurs-clés ne sont pas relationnels. Par conséquent, il peut être plus difficile d'écrire des rapports à l'aide de magasins de valeurs-clés qu'à l'aide d'une base de données relationnelle, pour laquelle ces rapports et l'extraction de données sont spécifiquement conçus.

— Robert Harvey
source

D'accord, qu'en est-il des deux autres? Autant que je sache, les bases de données de graphiques concernent toutes les relations, par exemple.

— Aedilum

1

@Aedilum: Mon expérience concerne principalement les bases de données relationnelles, mais je pense que les magasins de valeurs-clés, les magasins de données graphiques et les magasins de documents résolvent tous des problèmes spécifiques. D'une manière générale, chacun va être fort dans le domaine problématique pour lequel il est spécifiquement conçu, et plus faible dans les autres domaines.

— Robert Harvey

2

C'est très subjectif, ce que vous pensez pourrait être une faiblesse, quelqu'un d'autre pourrait penser que c'est sa plus grande force.

Toutes les bases de données NoSQL qui sont actuellement populaires traitent des problèmes auxquels les systèmes SGBDR existants étaient faibles, et ils sont généralement hautement spécialisés dans un problème particulier que l'auteur avait et essayait de résoudre.

Ainsi, toute faiblesse des produits est son incapacité à faire ce que vous avez besoin de faire d'une manière efficace dans le temps ou l'espace.

En effet, l'une des choses que j'ai apprises sur NoSQL, c'est qu'elles sont toutes conçues pour résoudre des problèmes que les SGBDR ont du mal à résoudre, comme des quantités massives d'opérations dans des délais courts ou des relations complexes.

— Aedilum

1

Je commencerai par noter que j'aime les bases de données NoSQL et que je suis en train d'abandonner nos bases de données et applications SQL là où cela a du sens. Ce processus a mis en évidence une faiblesse majeure - l'histoire opérationnelle n'est tout simplement pas encore là. Je veux dire par là:

NoSQL est toujours une cible en évolution rapide. Vous devez le connaître assez intimement pour savoir ce qui a changé entre les versions. D'un point de vue opérationnel, cela crée quelques difficultés - les administrateurs système sont habitués à des documents raisonnablement documentés avec les meilleures pratiques. Lorsque les meilleures pratiques n'ont pas été définies, cela devient un peu effrayant pour elles.
Très, très peu de gens connaissent leur fonctionnement au-delà de la communauté du développement. Cela en fait un défi lorsque vous souhaitez transférer le produit aux opérations et en finir avec lui.
Les meilleurs types d'opérations ont tendance à être capables de gérer du SQL léger et au moins à le reconnaître. Json ou tout ce que votre nosql parle est un peu une courbe d'apprentissage.
La réputation est une chose délicate - la perte de données fait très peur aux types d'opérations. Ils ont fini par croire que les bases de données SQL survivront à l'holocauste nucléaire. NoSQL sera un peu un travail de vente là-bas.

Il est parfois difficile de créer des rapports: de nombreux outils de l'espace utilisateur peuvent être connectés directement aux bases de données SQL, NoSQL nécessite toujours qu'un développeur traverse ce pont.

— Wyatt Barnett
source

Donc, en fin de compte ... Il n'y a pas de véritables faiblesses à tous les niveaux qui ne soient pas liées à l'enfance des produits NoSQL?

— Aedilum

@Aedilum: Cette petite enfance est une très grosse mise en garde.

— Robert Harvey

@Robert Harvey: exactement, la petite enfance engendre beaucoup de problèmes. @Aedilum: en tant que genre, il n'y a pas de faiblesse horrible en supposant que vous faites des choses avec votre base de données NoSQL qui ont du sens et vous avez les côtelettes pour le gérer, y compris rouler votre propre solution dans l'obscurité de la nuit lorsque la production est en baisse car il n'y a pas de manuel ni de support payant. Ça a du sens?

— Wyatt Barnett