J'ai entendu des choses à propos de NoSQL et qu'il pourrait éventuellement devenir le remplacement des méthodes de stockage SQL DB en raison du fait que l'interaction DB est souvent un goulot d'étranglement pour la vitesse sur le Web.
J'ai donc juste quelques questions:
Qu'est-ce que c'est exactement?
Comment ça marche?
Pourquoi serait-il préférable d'utiliser une base de données SQL? Et à quel point est-ce mieux?
La technologie est-elle encore trop récente pour être mise en œuvre ou vaut-elle la peine d'y jeter un coup d'œil?
Réponses:
Qu'est-ce que c'est exactement?
D'une part, un système spécifique , mais il est également devenu un mot générique pour une variété de nouveaux backends de stockage de données qui ne suivent pas le modèle de base de données relationnelle.
Comment ça marche?
Chacun des systèmes étiquetés avec le nom générique fonctionne différemment, mais l'idée de base est d'offrir une meilleure évolutivité et de meilleures performances en utilisant des modèles de base de données qui ne prennent pas en charge toutes les fonctionnalités d'un SGBDR générique, mais toujours suffisamment de fonctionnalités pour être utiles. D'une certaine manière, c'est comme MySQL, qui à un moment n'a pas pris en charge les transactions mais, précisément à cause de cela, a réussi à surpasser d'autres systèmes de base de données. Si vous pouviez écrire votre application d'une manière qui ne nécessitait pas de transactions, c'était génial.
Pourquoi serait-il préférable d'utiliser une base de données SQL? Et à quel point est-ce mieux?
Ce serait mieux lorsque votre site doit évoluer de manière si massive que le meilleur SGBDR fonctionnant sur le meilleur matériel que vous pouvez vous permettre et optimisé autant que possible ne peut tout simplement pas suivre la charge. Cela dépend du cas d'utilisation spécifique (beaucoup d'activité de mise à jour combinée à beaucoup de jointures est très difficile sur les SGBDR "traditionnels") - pourrait bien être un facteur de 1000 dans les cas extrêmes.
La technologie est-elle encore trop récente pour être mise en œuvre ou vaut-elle la peine d'y jeter un coup d'œil?
Cela dépend principalement de ce que vous essayez d'accomplir. Il est certainement assez mature pour être utilisé. Mais peu d'applications ont vraiment besoin de faire évoluer cela massivement. Pour la plupart, un SGBDR traditionnel est suffisant. Cependant, avec l'utilisation d'Internet de plus en plus omniprésente, il est fort probable que les applications qui le font deviendront plus courantes (mais probablement pas dominantes).
la source
transaction?Il n’existe pas de NoSQL!
NoSQL est un mot à la mode.
Pendant des décennies, quand les gens parlaient de bases de données, ils parlaient de bases de données relationnelles. Et quand les gens parlaient de bases de données relationnelles, ils parlaient de ceux que vous contrôlez avec le langage de requête structuré d'Edgar F. Codd. Stocker les données d'une autre manière? La démence! Tout le reste n'est que des fichiers plats.
Mais au cours des dernières années, les gens ont commencé à remettre en question ce dogme. Les gens se demandaient si les tableaux avec des lignes et des colonnes étaient vraiment le seul moyen de représenter des données. Les gens ont commencé à réfléchir et à coder, et ont proposé de nombreux nouveaux concepts pour organiser les données. Et ils ont commencé à créer de nouveaux systèmes de bases de données conçus pour ces nouvelles façons de travailler avec les données.
Les philosophies de toutes ces bases de données étaient différentes. Mais une chose que toutes ces bases de données avaient en commun, était que le langage de requête structuré n'était plus un bon moyen de les utiliser. Ainsi, chaque base de données a remplacé SQL par ses propres langages de requête. C'est ainsi que le terme NoSQL est né, en tant qu'étiquette pour toutes les technologies de base de données qui défient le modèle de base de données relationnelle classique.
Alors, qu'est-ce que les bases de données NoSQL ont en commun?
En fait, pas grand-chose.
Vous entendez souvent des phrases comme:
Est-ce vrai? Eh bien, certaines de ces déclarations peuvent être vraies pour certaines bases de données communément appelées NoSQL, mais chacune d'entre elles est également fausse pour au moins une autre. En fait, la seule chose que les bases de données NoSQL ont en commun, c'est que ce sont des bases de données qui n'utilisent pas SQL. C'est tout. La seule chose qui les définit est ce qui les distingue les uns des autres.
Alors, qu'est-ce qui distingue les bases de données NoSQL?
Nous avons donc précisé que toutes ces bases de données communément appelées NoSQL sont trop différentes pour les évaluer ensemble. Chacun d'entre eux doit être évalué séparément pour décider s'ils conviennent bien pour résoudre un problème spécifique. Mais par où commencer? Heureusement, les bases de données NoSQL peuvent être regroupées dans certaines catégories, qui conviennent à différents cas d'utilisation:
Orienté document
Exemples: MongoDB, CouchDB
Points forts: Données hétérogènes, travail orienté objet, développement agile
Leur avantage est qu'ils ne nécessitent pas une structure de données cohérente. Ils sont utiles lorsque vos besoins et donc la mise en page de votre base de données changent constamment, ou lorsque vous avez affaire à des ensembles de données qui vont ensemble mais qui ont toujours une apparence très différente. Lorsque vous avez un grand nombre de tables avec deux colonnes appelées «clé» et «valeur», cela peut valoir la peine d'être examiné.
Bases de données graphiques
Exemples: Neo4j, GiraffeDB.
Points forts: exploration de données
Alors que la plupart des bases de données NoSQL abandonnent le concept de gestion des relations de données, ces bases de données l'adoptent encore plus que ces soi-disant bases de données relationnelles.
Leur objectif est de définir les données par leur relation avec d'autres données. Lorsque vous avez beaucoup de tables avec des clés primaires qui sont les clés primaires de deux autres tables (et peut-être des données décrivant la relation entre elles), alors celles-ci pourraient être quelque chose pour vous.
Magasins de valeurs clés
Exemples: Redis, Cassandra, MemcacheDB
Points forts: recherche rapide des valeurs par clés connues
Ils sont très simplistes, mais cela les rend rapides et faciles à utiliser. Lorsque vous n'avez pas besoin de procédures stockées, de contraintes, de déclencheurs et de toutes ces fonctionnalités de base de données avancées et que vous voulez simplement un stockage et une récupération rapides de vos données, alors ce sont pour vous.
Malheureusement, ils supposent que vous savez exactement ce que vous recherchez. Vous avez besoin du profil User157641? Pas de problème, cela ne prendra que quelques microsecondes. Mais que se passe-t-il lorsque vous voulez connaître les noms de tous les utilisateurs âgés de 16 à 24 ans, avoir des «gaufres» comme nourriture préférée et se connecter au cours des dernières 24 heures? Mauvais chance. Lorsque vous ne disposez pas d'une clé définie et unique pour un résultat spécifique, vous ne pouvez pas la sortir de votre magasin KV aussi facilement.
SQL est-il obsolète?
Certains partisans de NoSQL affirment que leur base de données NoSQL préférée est la nouvelle façon de faire les choses, et SQL appartient au passé.
Ont-ils raison?
Non, bien sûr qu'ils ne le sont pas. Bien qu'il y ait des problèmes pour lesquels SQL ne convient pas, il a toujours ses avantages. De nombreux modèles de données sont simplement mieux représentés comme un ensemble de tableaux qui se référencent les uns les autres. Surtout parce que la plupart des programmeurs de bases de données ont été formés pendant des décennies à penser les données de manière relationnelle, et essayant d'imposer cet état d'esprit à une nouvelle technologie qui n'était pas faite pour cela se termine rarement bien.
Les bases de données NoSQL ne remplacent pas SQL - elles constituent une alternative.
La plupart des écosystèmes logiciels autour des différentes bases de données NoSQL ne sont pas encore aussi matures. Bien qu'il y ait des progrès, vous n'avez toujours pas d'outils supplémentaires aussi matures et puissants que ceux disponibles pour les bases de données SQL populaires.
De plus, il y a beaucoup plus de savoir-faire pour SQL. Des générations d'informaticiens ont consacré des décennies de leur carrière à la recherche se concentrant sur les bases de données relationnelles, et cela montre: La littérature écrite sur les bases de données SQL et la modélisation de données relationnelles, à la fois pratiques et théoriques, pourrait remplir plusieurs bibliothèques pleines de livres. Comment créer une base de données relationnelle pour vos données est un sujet si bien documenté qu'il est difficile de trouver un cas d'angle où il n'y a pas de bonnes pratiques généralement acceptées.
La plupart des bases de données NoSQL, en revanche, en sont encore à leurs balbutiements. Nous cherchons toujours la meilleure façon de les utiliser.
la source
Puisque quelqu'un a dit que mon précédent post était hors sujet, je vais essayer de compenser :-) NoSQL n'est pas, et n'a jamais été, destiné à remplacer des bases de données SQL plus traditionnelles, mais quelques mots sont nécessaires pour obtenir les choses dans la bonne perspective.
Au cœur même de la philosophie NoSQL se trouve la considération que, peut-être pour des raisons commerciales et de portabilité, les moteurs SQL ont tendance à ne pas tenir compte de l'énorme puissance du système d'exploitation UNIX et de ses dérivés.
Avec une base de données basée sur le système de fichiers, vous pouvez profiter immédiatement des capacités et de la puissance toujours croissantes du système d'exploitation sous-jacent, qui ne cessent d'augmenter depuis de nombreuses années maintenant conformément à la loi de Moore. Avec cette approche, de nombreuses commandes du système d'exploitation deviennent automatiquement également des "opérateurs de base de données" (pensez à "ls" "sort", "find" et aux autres utilitaires shell UNIX innombrables).
Avec cela à l'esprit et un peu de créativité, vous pouvez en effet concevoir une base de données basée sur un système de fichiers capable de surmonter les limites de nombreux moteurs SQL courants, au moins pour des modèles d'utilisation spécifiques, ce qui est tout le point derrière la philosophie de NoSQL, le façon dont je le vois.
Je dirige des centaines de sites Web et ils utilisent tous NoSQL dans une plus ou moins grande mesure. En fait, ils n'hébergent pas d'énormes quantités de données, mais même si certaines d'entre elles le faisaient, je pourrais probablement penser à une utilisation créative de NoSQL et du système de fichiers pour surmonter les goulots d'étranglement. Quelque chose qui serait probablement plus difficile avec les "prisons" SQL traditionnelles. Je vous exhorte à rechercher sur Google "unix", "manis" et "shaffer" pour comprendre ce que je veux dire.
la source
Si je me souviens bien, cela fait référence à des types de bases de données qui ne suivent pas nécessairement la forme relationnelle. Je pense aux bases de données de documents, aux bases de données sans structure spécifique et qui n'utilisent pas SQL comme langage de requête spécifique.
Il est généralement mieux adapté aux applications Web qui reposent sur les performances de la base de données et qui n'ont pas besoin de fonctionnalités plus avancées des moteurs de base de données Relation. Par exemple, un magasin Key-> Value fournissant une interface de requête simple par identifiant peut être 10 à 100 fois plus rapide que l'implémentation de serveur SQL correspondante, avec un coût de maintenance du développeur inférieur.
Un exemple est cet article pour un magasin OLTP Tuple, qui a sacrifié les transactions pour un traitement à thread unique (aucun problème de concurrence car aucune concurrence n'est autorisée) et a conservé toutes les données en mémoire; obtenir des performances 10 à 100 fois supérieures par rapport à un système basé sur un SGBDR similaire . Fondamentalement, il s'éloigne de la vue «One Size Fits All» des systèmes SQL et de base de données.
la source
En pratique, NoSQL est un système de base de données qui prend en charge un accès rapide aux grands objets binaires (docs, jpgs, etc.) en utilisant une stratégie d'accès basée sur des clés. Il s'agit d'une rupture avec l'accès SQL traditionnel qui n'est suffisant que pour les valeurs alphanumériques. Non seulement la stratégie de stockage interne et d'accès, mais aussi la syntaxe et les limitations du format d'affichage restreignent le SQL traditionnel. Les implémentations BLOB des bases de données relationnelles traditionnelles souffrent également de ces restrictions.
Dans les coulisses, c'est un aveu indirect de l'échec du modèle SQL à prendre en charge toute forme d'OLTP ou à prendre en charge de nouveaux formats de données. «Support» signifie non seulement le stockage, mais des capacités d'accès complet - par programmation et par requête en utilisant le modèle standard.
Les passionnés de relation n'ont pas tardé à modifier la définition de NoSQL de Not-SQL à Not-Only-SQL pour garder SQL toujours dans l'image! Ce n'est pas bon, surtout quand on voit que la plupart des programmes Java ont aujourd'hui recours au mappage ORM du modèle relationnel sous-jacent. Un nouveau concept doit avoir une définition claire. Sinon, cela finira comme SOA.
La base des systèmes NoSQL réside dans la paire clé-valeur aléatoire. Mais ce n'est pas nouveau. Les systèmes de base de données traditionnels comme IMS et IDMS prenaient en charge les clés ramdom hachées (sans utiliser d'index) et ils le font toujours. En fait, IDMS a déjà un mot-clé NONSQL où ils prennent en charge l'accès SQL à leur ancienne base de données réseau qu'ils appelaient NONSQL.
la source
C'est comme Jacuzzi: à la fois une marque et un nom générique. Ce n'est pas seulement une technologie spécifique, mais plutôt un type de technologie spécifique , dans ce cas faisant référence à des «bases de données» à grande échelle (souvent rares) comme BigTable ou CouchDB de Google.
la source
NoSQL, le programme actuel semble être une base de données relationnelle implémentée dans awk en utilisant des fichiers plats sur le backend. Bien qu'ils affirment, "NoSQL n'a essentiellement pas de limites arbitraires et peut fonctionner là où d'autres produits ne le peuvent pas. Par exemple, il n'y a pas de limite sur la taille des champs de données, le nombre de colonnes ou la taille des fichiers", je ne pense pas que ce soit la base de données à grande échelle du futur.
Comme le dit Joel, les bases de données massivement évolutives comme BigTable ou HBase , sont beaucoup plus intéressantes. GQL est le langage de requête associé à BigTable et App Engine. Il a été largement modifié en SQL pour éviter les fonctionnalités que Google considère comme des goulots d'étranglement (comme les jointures). Cependant, je n'ai jamais entendu parler de "NoSQL" auparavant.
la source
NoSQL est un système de base de données qui n'utilise pas de requêtes SQL basées sur des chaînes pour récupérer des données.
Au lieu de cela, vous créez des requêtes à l'aide d'une API qu'ils fourniront, par exemple Amazon DynamoDB est un bon exemple de base de données NoSQL.
Les bases de données NoSQL sont meilleures pour les grandes applications où l'évolutivité est importante.
la source
Oui, NoSQL est différent de RDBMS et OLAP. Il utilise des modèles de cohérence plus souples que les bases de données relationnelles traditionnelles.
Les modèles de cohérence sont utilisés dans les systèmes distribués tels que les systèmes de mémoire partagée distribuée ou le magasin de données distribué.
Les systèmes de base de données NoSQL sont souvent hautement optimisés pour les opérations de récupération et d'ajout et offrent souvent peu de fonctionnalités au-delà du stockage des enregistrements (par exemple, les magasins de valeurs clés). La flexibilité d'exécution réduite par rapport aux systèmes SQL complets est compensée par des gains notables d'évolutivité et de performances pour certains modèles de données.
Il peut fonctionner sur des données structurées et non structurées. Il utilise des collections au lieu de tables
Regardez SQL vs NoSQL: Battle of the Backends ; ça explique tout.
la source