SQL ou NoSQL, quelle est votre préférence en 2018 ? Avez-vous adopté le NoSQL ?

SQL ou NoSQL, quelle est votre préférence en 2018 ? Avez-vous adopté le NoSQL ?
Vous êtes invités à voter et partager votre avis sur le NoSQL (Not only SQL)

Avec la croissance élevée et continue des volumes de données dans certains environnements telles que les plateformes Web et les environnements de réseaux sociaux, les bases de données relationnelles ont présenté des contraintes, qui ont justifié que les administrateurs (DBA) et les développeurs explorent d’autres horizons pour atteindre des niveaux d’extensibilité plus que nécessaires, pour ces cas là. C’est ainsi que Google aurait construit son SGBD propriétaire BigTable, orienté colonnes, suivi plus tard par Facebook avec Cassandra puis HBase, SourceForge avec MongoDB, et bien d’autres grands acteurs du Web.

Les systèmes de gestion de bases de données (SGBD) NoSQL semblent réussir à s’être affirmés comme une alternative valable au SGBD SQL.

Pièce jointe 424833

Cependant le NoSQL ne semble pas couvrir toutes les attentes pour le stockage structurel des données. Le SQL aurait donc encore de bien longs jours devant lui. Mais la question de savoir laquelle des deux architectures répondrait de mieux en mieux aux exigences des applications et à la logique de gestion des données mérite d’être posée.
Un sondage en 2017 présentait SQL en première position avec plus de 31 voix sur 42 votants.

Certains langages de programmation Web, comme PHP, offrent de plus en plus des facilités à s’orienter vers du NoSQL. Et plusieurs systèmes de gestion de bases de données adoptant cette architecture voient le jour.

Vous êtes donc invités à voter pour votre préférence entre SGBD SQL et SGBD NoSQL sur la base de :

• Stabilité et gestion de la montée en charge,
• Scalabilité et extension dans la gestion des volumes de données,
• Facilité d’intégration à la programmation,
• Gestion et optimisation des ressources de stockage,
• Bien d’autres points que vous pourrez relever.

Bien que votre vote soit le bienvenu, votre contribution dans les commentaires serait appréciée pour développer un débat de qualité.

Voir aussi

:fleche: SQL Vs NoSQL, quel est votre préféré ?~~ Participez au sondage et au débat puis donnez-nous vos avis
:fleche: Forum SQL
:fleche: Forum NoSQL
:fleche: Rtrouvez les meilleurs cours et tutoriels pour apprendre le NoSQL
:fleche: La Rubrique NoSQL

Dans mon job on utilise SQL avec énormément de relation entre les tables, des vue, des procédures stockés, et donc je me demande comment on pourrait faire aussi bien, propre etc avec du NOSQL

par contre dans mes projets perso j'utilise NOSQL, et je sais que je pourrais jamais faire aussi vite, simplement, et facilement les choses avec SQL, car j'aime bien éviter les relations entre les tables/document quand c'est possible.

j'aimerai bien voir l'utilisation du NOSQL dans des projets d'envergure pour savoir comment c'est utilisé !

Il ne s'agit pas de choisir , mais exploiter au mieux ces technologies . Un projet n'est pas égal à un sgbd .

Vous êtes plutôt voiture, avion ou marche à pied ?

Ca dépend... pour aller à New York, à Rennes ou à la boulangerie ?


Pour le NoSQL c'est la même chose. Ca dépend des besoins du projet.

Pour ma part, j'ai utilisé du NoSQL (MongoDB, Redis, BerkeleyDB) sur desprojets. J'aime bien ces technos mais elle ne remplacent pas un SGBDR lorsqu'on en a besoin.

Autre, pas de préférence et des cas d'utilisation différents.. :zoubi:

Je l'ai adopté pour un projet cette année. J'ai utilisé Azure Cosmos DB. Et à vrai dire je m'en mords un peu les doigts... Ça a de très bons côtés (très facile de modéliser des données complexes, pas besoin de tables de jointures etc, performances excellentes, etc), mais le manque de certaines features (ACID, transactions, contraintes d'intégrité, d'unicité, etc) se fait cruellement ressentir. D'autant plus avec Cosmos où le modèle de facturation fait qu'on a plutôt intérêt à mettre toutes les données dans une seule collection :/

Si c'était à refaire, je pense que je m'orienterais plutôt vers MongoDB (qui a le support d'ACID depuis la v4) ou RavenDB.

Perso j'ai l'impression que la donne a un peu changé depuis les débuts du NoSQL. C'est toujours pareil : au début une nouvelle techno débarque et rafle la mise car elle seule sur un créneau, mais les autres ne restent pas les bras croisés et compensent progressivement leurs lacunes jusqu'à parfois repasser devant.

Je dis ça part rapport à Postgres en particulier qui a quand même bien su évoluer et s'adapter aux besoins à la marge du SQL traditionnel. Je continue d'utiliser Mongo pour du prototypage rapide, mais une fois que le modèle de données est mieux maîtrisé, SQL se montre très intéressant.

Tiens, je fais seulement maintenant le parallèle avec le débat langages dynamiques vs fortement typés.

Le choix est inepte... par ce qu'il existe aujourd'hui des SGBD Relationnels capable de faire du NoSQL et du Big Data tout à la fois dans une même base de données ... !

Exemple : Microsoft SQL Server est à la fois un SGBD relationnel +

• table de graphe (nœuds et arcs avec le langage de navigation dans le graphe qui va avec)
• table de paire Key/Value en mémoire avec les tables In Memory et le ColumnStore index
• table de document avec FILESTREAM et FILETABLE + indexation textuelle et sémantique
• table "big" avec le concept de "sparse columns", le partitionnement et le mode strecht

et bien entendu le big data avec Apach spark et Kubernetes

Comme le disait récemment une étude du groupe forrester, dans les années à venir la plupart des produits NoSQL d'aujourd'hui seront morts. Ne subsisterons que quelque uns des produits les plus achevés (mongodb, neo4J, Redis, Cassandra...
Pensez à ce qui est arrivé aux SGBD Objets....
Pensez à ce qui est arrivé aux SGBD XML...

A +

Notez que Oracle fait à peu de chose près la même chose, sauf que les index verticaux ne sont pas disponibles pour les tables relationnelles.

adoption de NOSQL, par nécessité , mais couplé à une base SQL,

Dans les faits le NoSQL c'est surtout utilisé par les baltringues incompétents en bases de données qui n'ont jamais rien compris au magnifique langage qu'est le SQL 8-)

:dehors:

Citation:

---

Envoyé par SQLpro

Comme le disait récemment une étude du groupe forrester, dans les années à venir la plupart des produits NoSQL d'aujourd'hui seront morts. Ne subsisterons que quelque uns des produits les plus achevés (mongodb, neo4J, Redis, Cassandra...

---

J'ai pas trouvé cette étude de Forrester mais j'ai trouvé celle-ci de Gartner qui doit en fait être celle que tu mentionnes:
https://www.enterprisedb.com/fr/blog...magic-quadrant

Précisons quand même que ces 2 cabinets d'analyse sont très optimistes sur l'avenir du NoSQL. Après se pose l'éternelle question de parier sur le bon cheval.

Gartner c'est quand même très orienté grands comptes. Dans la culture devops qui s'impose à l'heure actuelle, les outils propriétaires comme Oracle ou SqlServer n'ont aucune place. On aime ou pas, mais c'est comme ça.

Ce qui est malgré tout important pour une boite c'est la perennité de son investissement.
Quand tu prends du Sqlserver/Oracle (bdd commerciales) tu sais que dans 10 ans, 15 ans tu auras encore du support et que la boite sera encore là vue leur taille.
On fait de l'oracle depuis 1997 et on a pu migrer nos systemes complexes entiers depuis tout ce temps sans soucis et on sait que dans 10 ans ce sera encore pareil. Ces memes sgbd commerciaux suivent les technos et intégrent les nouveautés a chaque nouvelle version; c'est pas comme s'ils n'evoluaient pas.
On a essayé nosql (hors oracle) mais on est vite revenu a nos fondamentaux. Ca facilité la vie du developpeur (parce qu'il va manipuler des données en json) mais la perennité sur le long terme est pas garantie et l'incompatibilité plus que probable (avec tout ce qui est nouveau/hype, la notion de compatibilité ascendante n'est plus un element essentiel alors qu'il l'es toujours pour les BDDs existantes depuis longtemps -c'est entre autre comme ca qu'ils fidelisent leurs usagers). Apres faut savoir ce que l'on veut, c'est chaque boite qui choisit en fonction de ses priorités.

PS : oui dans mon cas on fait des systemes de plusieurs dizaines de serveurs (en archi soa micro services) et pas de simples applications - pour des grands comptes mais aussi des entreprises de taille moyenne. On est en organisation devops egalement.

Pour prévoir l'avenir du NoSQL, je conseille de lire au moins l'intro de: A Relational Model of Data for Large Shared Data Banks E. F. CODD qui explique pourquoi on est passé de modèles hierarchiques et réseau (comme ceux du diagramme 'Non SQL Databases' de cet article) au modéle relationel et language SQL. Il est amusant de voir que ce sont ces arguments qui sont parfois avancés à tort aujourd'hui par les architectes pour aller vers du NoSQL, pour éviter l'effort de la conception d'un système d'information durable.

Un Google Translate rapide pour les francophones:

Citation:

---

Les futurs utilisateurs de grandes banques de données doivent éviter de savoir comment les données sont organisées dans la machine (la représentation interne). [...] la plupart des programmes d'application ne doivent pas être affectés lorsque la représentation interne des données est modifiée [...].
Les systèmes de données formatés non inférentiels existants fournissent aux utilisateurs des fichiers structurés en arborescence ou des modèles de réseau un peu plus généraux. La section 1 présente les insuffisances de ces modèles. [...]

---

Les bases NoSQL sont liées à une structure, à un language. Pas de jointures, pas de ACID. Et surtout, un modéle optimisé pour un seul use-case. Ok pour une appli spécifique chez Google ou Amazon. Pas vraiment pour un système d'information d'entreprise.

Autre lecture rapide, les raison pour lequelles le CERN est parti sur du relationnel à l'époque (Oracle 2.3 en 1982). Justement pour sortir des contraintes des structures hierarchiques et réseau. Grâce au tables et aux jointures, le modèle relationnel est évolutif. Visiblement un bon choix vu que 32 ans plus tard, le PetaBytes est dépassé dans ces bases relationnelles.

Un Google Translate d'un extrait:

Citation:

---

Les systèmes hiérarchiques ne [...] permettent que des possibilités limitées de structuration des données. Les systèmes de réseau nécessitent des techniques de navigation pour accéder aux données ayant une structure prédéfinie. Les systèmes relationnels transforment des structures de données complexes en simples tables bidimensionnelles faciles à visualiser. Ces systèmes sont destinés aux applications où la planification préalable est difficile et sont conçus pour offrir une facilité d'utilisation [...]

---

Le 'non structured data' et 'schema on read' pour faciliter la scalabilité et la flexibilité, c'est une illusion très court-terme. On peut enregistrer n'importe quel document, mais il faut que le code soit adapté à chacune de ces structures. Ce n'est valable que pour des applis/données qui ont une durée de vie très courte (regardez les use-case Google, Facebook, Twitter... sur ces technos NoSQL - leur ERP reste SQL bien sûr). Pour saisir des données qu'on est guaranti de pouvoir lire et faire évoluer dans 10 ans, de toujours lire lorsque PHP, Java, et autres languages de 3ème génération qui se succèdent, seront passés de mode, et dont on a la guarantie de la cohérence des données, les bases SQL sont toujours indispensables. Le relationnel (la principale approche scientifique de la modélisation de donnée), et le SQL (seul language de 4ème génération utilisé en entreprise aujourd'hui) évoluent mais n'ont pas d'alternatives globales.

Citation:

---

Envoyé par SQLpro

Notez que Oracle fait à peu de chose près la même chose, sauf que les index verticaux ne sont pas disponibles pour les tables relationnelles.

---

C'est quoi un index vertical? Il y a quelques fonctionalités columnar de puis longtemps chez Oracle. Ca commence en 1993 avec Bitmap Index. Et ça continue avec Hybrid Columnar Compression et In-memory Column Store.

Citation:

---

Envoyé par pachot

C'est quoi un index vertical? Il y a quelques fonctionalités columnar de puis longtemps chez Oracle. Ca commence en 1993 avec Bitmap Index. Et ça continue avec Hybrid Columnar Compression et In-memory Column Store.

---

Indexation verticale Oracle = Colum Store. Et ce n'est disponible que pour les tables "In Memory". Par pour les tables relationnelles classique du genre OLTP, contrairement à SQL Server qui le permet sur du relationnel. Quand à parler d'indexation verticale sur du BitMap… j'espère que c'est une plaisanterie suisse !

A +

In-Memory Column Store est un storage additionel (comme un index ou une vue materialisée) pour des tables relationnelles. Toutes les modifications sont faites sur le row store. Le Column Store est invalidé par les modifications, et mis à jour de manière asynchrone. Les requêtes analytiques peuvent en bénéficier - l'optimiseur choisit. Et si, bitmap index est la première approche columnar. Un index par colonne, bitmaps combinés pour aller trouver les lignes ensuite. Mais ce n'est pas pour de l'OLTP bien sûr.

Citation:

---

Envoyé par pachot

Mais ce n'est pas pour de l'OLTP bien sûr.

---

Alors que le ColumsStore de SQL Server est fait pour de l'OLTP comme pour de l'OLAP… En sus de l'indexation en Hash ou range du In Memory…

A +

Citation:

---

Envoyé par Chuck 3.50

Dans mon job on utilise SQL avec énormément de relation entre les tables, des vue, des procédures stockés, et donc je me demande comment on pourrait faire aussi bien, propre etc avec du NOSQL

par contre dans mes projets perso j'utilise NOSQL, et je sais que je pourrais jamais faire aussi vite, simplement, et facilement les choses avec SQL, car j'aime bien éviter les relations entre les tables/document quand c'est possible.

j'aimerai bien voir l'utilisation du NOSQL dans des projets d'envergure pour savoir comment c'est utilisé !

---

Grand risque de duplication de données

Tout depend de la volumetrie.