Discussion :

[Shepard]

Je ne suis pas un pro du domaine, d'ailleurs je suis encore étudiant, mais mon avis est que SQL n'est certainement pas dépassé, et pour moi NoSQL n'est simplement pas la bonne solution.

Beaucoup d'études ont été faites dans le monde des bases de données, et de nombreuses améliorations ont été proposées. Pour n'en citer qu'une, transrelational qui, bien que critiqué, apporte d'importantes améliorations au niveau des performances et rend les index quasiment inutiles. Sans compter le gain au niveau de l'espace disque utilisé.

Malheureusement, ce genre d'améliorations n'est pas pris en compte par les SGBDR, certainement à raison, je répète que je ne suis pas un pro du domaine, toutefois je pense qu'abandonner le relationnel pour de la gestion avec des fichiers, ça c'est un véritable retour vers le passé, et si j'ai bien compris, c'est ce que propose NoSQL.

Bien que je pense ne pas être un débutant en SQL, je n'aime pas ce langage, il a énormément de mérite et l'informatique ne serait certainement pas ce qu'elle est sans lui, mais d'autres langages d'interrogation de DB relationnelles permettent un raisonnement plus logique et généralement moins verbeux.

Malheureusement les produits ne gèrent habituellement que le SQL, donc avec des index et une structure qui ne se prête pas à une évolution du système de fichiers sur lequel il repose (encore une fois, je ne citerai que transrelational ici).

C'est n'est que mon humble avis bien sûr

[fkylol]

Le modèle relationnel a le mérite de proposer un support de qualité et normalisé à l'implémentation d'un besoin fonctionnel élaboré, y compris modélisé objet ou hiérarchique. La 3ème forme normale est un repère rassurant.
Il faut néanmoins rester pragmatique et gérer les contraintes avec bon sens. Ça passe le plus souvent par une dénormalisation du modèle, par exemple en pesant le pour et le contre de l'intégrité qu'apporte une clef étrangère en regard des contorsions qu'elle impose lors de l'implémentation. Ça passe également par l'externalisation de donnée pour une raison précise, par exemple un moteur NoSQL pour des données linéaires à accéder rapidement dans de grands volumes (plein d'autres exemples dans ce lien qui a été fourni ci-dessus http://5.freshminutes.it/2010/02/17/...ql-user-group/)
NoSQL (je dirais plutôt NoRelation) ne se peut pas se substituer aux SGBDR et les SGBDR ont un domaine d'application bien plus large.
Il me semble que le coté passionné du débat NoSQL/SGBDR vient de l'incompréhension entre ceux qui travaillent pour le Web grand public et ceux de l'IT au sens large et plus particulièrement l'informatique de gestion qui couvre un spectre technologique plus riche.

[susanoo]

Je suis encore étonné que NoSQL fasse couler tant d'encre!
Dire que NoSQL est vers quoi, on reviendrait à dire que les données n'auraient plus de relations entre elles! du jour au lendemain!
NoSQL devrait se trouver un autre adversaire!! sauf si je me trompe!
Anyway

Voyageur, si tu n'as pas de chemin, fait ton chemin en marchant!

[pseudocode]

Je suis encore étonné que NoSQL face tend couler d'encre!
Dire que NoSQL est vers quoi on va reviendrait à dire que les données n'auraient plus de relations entre elles! du jour au lendemain!
NoSQL devrait se trouver un autre adversaire!! sauf si je me trompe!
Anyway

?

Personne n'a jamais dit que les données n'auraient plus de relation. NoSql se propose juste de ne pas devoir définir un modèle relationnel (donc de ne pas modéliser les relations). Un peu ce qui se passe sur ton disque-dur : tu n'as pas besoin de définir les relations entre les répertoires pour y créer des fichiers.

[JeitEmgie]

En NoSQL, les relations sont définies par le "business case"… c'est celui qui interprète les données qui
décident des "relations" qui l'intéresse… et il n'y a aucune contrainte du côté du repository quand à la validité de ces relations…

En RDMS, les relations sont définies au niveau du schéma (càd un niveau meta), et ces relations deviennent contractuelles…

or ce niveau meta n'existe que de manière extrêmement ténue en NoSQL… et beaucoup de solutions NoSQL ne prévoit même pas de définition d'un niveau meta pour pouvoir insérer des données… dans d'autres comme Cassandra, c'est vraiment extrêmement réduit par rapport à un schéma relationnel classique…

et cette absence de niveau meta, ne concerne pas que les relations… le typage des données est aussi totalement libre… puisque tout est de toute façon stocké sous forme textuelle…

le NoSQL n'est probablement que la première étape dans l'évolution de la manière dont l'on considère les données…
sans remettre en question les usages traditionnels des RDBMS…

la suite sera sans doute les Grahp Databases… (càd le stockage de triples (S,V,O) au lieu de paires (K,V) avec peut-être un retour d'un niveau meta un peu plus riche…)
et il n'y aurait rien d'étonnant d'appendre un jour que Google ait fait évoluer une version de BigTables dans ce sens pour implémenter le stockage lié à leur projet de moteur de recherche sémantique…

[Tommy31]

la suite sera sans doute les Grahp Databases… (càd le stockage de triples (S,V,O) au lieu de paires (K,V) avec peut-être un retour d'un niveau meta un peu plus riche…)
et il n'y aurait rien d'étonnant d'appendre un jour que Google ait fait évoluer une version de BigTables dans ce sens pour implémenter le stockage lié à leur projet de moteur de recherche sémantique…

Je partage ce point de vue. La représentation par triplets est universelle en ce sens qu'elle n'impose pas la nature des relations qui unit les éléments. Avec un v unique, on a l'expressivité d'une représentation par paires, avec un ensemble de v plus ou moins riche, on a l'expressivité d'un mcd, d'un modèle objet ou d'une ontologie.

Si sur le cadre théorique c'est très alléchant, il faut que les systèmes de stockage suivent, c'est-à-dire qu'ils soient performants. Or jusqu'à présent, )à ma connaissance, c'est encore au stade de la recherche.

[JeitEmgie]

JOr jusqu'à présent, )à ma connaissance, c'est encore au stade de la recherche.

FYI

http://java.dzone.com/news/nosql-graph-database-feature

[SQLpro]

mais si je ne me trompe pas SQL est un dinosaure du '92, et rien n'a changé depuis, sauf un petit soupçon d'XML et quelques verbes de plus....
Et monsieur SQL reste figé dans le temps (je me revois dans les bancs de physique à l'université).

C'est vrai qu'entre la norme SQL2 de 1992 et celle de 2003 il n'y a presque rien....
Extrait de mon ouvrage sur SQL, 2e édition, page 5:
"
La deuxième norme (appelée SQL92 ouSQL 2 d'un volume de 600 pages)...
"
quelques paragraphe après :
"
Les références de la norme SQL:2003 sont les suivantes :
[...]
Les parties 1, 2 et 11 (1 650 pages) décrivent les bases du langage. Les autres parties constituent les extensions (2 136 pages).
"
Soit une augmentation de 275 % sur la partie "core" et globalement de 631%.
C 'est dire si SQL est dans le formol !!!!

Je ne connais pas de langage qui à duré plus de 30 ans et est l'objet d'untel rajeunissement !!!!

Par exemple aujourd'hui presque tous les SGBDR ont un SIG intégré ainsi qu'un outil d'indexation textuel, tous deux étant normalisés.
http://blog.developpez.com/sqlpro/p9...ext-search-no/
http://blog.developpez.com/sqlpro/p9...n-geographiqu/

Je vous invite donc à lire mes articles, ou mieux, mon ouvrage sur SQL.

A +

[vosaray]

Tiens ca fait un bout de temps que j'ai pas vu de notif sur le sujet que je viens de relire.

ou je suis débile, mais si je ne me trompe pas SQL est un dinosaure du '92, et rien n'a changé depuis,

Bon je ne vais pas tirer sur l'ambulance, mais que dire du C dans ce cas la ? Faut t'il remplacer toutes les couches natives écrites en C par un autre langage juste parce que le C n'a pas évolué ?

Franchement, des fois il y a des paires de cla... pardon accolades qui se perdent :

Puis je vous donne une petite info vite fait : après 1 an d’expérimentation sur les bases noSql, en l’occurrence CouchDB, j'ai jeté l’éponge pour plusieurs raisons :

1. performances médiocres

Sur un volume de données somme tout pas si gros que ca, mais pas ridicule non plus ( 800.000 documents d'environ 30Ko chacun ), les perfs ne sont pas au rdv.

Certains arguent que les perfs seront les mêmes pour un volume de données gigantesque. Ok, presque vrai en terme de recherche, mais complètement faux en terme de mise à jour des index.

Donc si votre appli doit présenter des mises à jour de données dans un temps relativement court, il faut trouver autre chose ...

2. consommation disque affolante !

Donc 0.8 millions de docs, 6 indexes ça fait 45Go sur le disque rien que pour les indexes .

Chaque index utilisant un (1, uno, one .. ) ficher. On se retrouve avec des fichiers de l'ordre de 9Go.

Je vous laisse imaginer la joie de l'append du fichier en question.

Et aussi méditer sur le fait que cacher les indexes en RAM demande tout de même un budget plus que considérable.

3. pas adapté à des "requêtes applicatives"

Franchement on a beau tourner autour du pot, si votre appli présente les données dans un front-end classique, disons un tableau sortable sur plusieurs colonnes et un pager, le noSql ou en tout cas CouchDB il vaut mieux oublier.

Si vous voulez connecter un tel compo, qui est somme toute un grand classique du web sur une base CouchDb, alors il faut soit utiliser un produit d'indexage (avec le cout cpu/disque inherent) externe, soit créer un index par colonne et gerer un cache des clés (first,last) coté appli.

Donc plus d'indexes = plus de disque et un temps de mise à jour peu acceptable, tout en consommant pas mal de CPU et d'I/O. De quoi franchement saturer votre système (linux pour ma part).

Quant aux produits d'indexation externe, type Lucene, ca marche, mais la prise en compte des changements est assez lente et le tout consomme pas mal de ressources supplémentaires.

4. Sécurité ou est tu ?

Ok on peut sécuriser l'accès à la base via un login/mdp. Très bien mais il n'y a rien pour sécuriser les droits sur les documents. Donc en gros vous accédez à la base, et vous pouvez voir tous les docs qui y figurent.

Acceptable si les données n'ont pas de contraintes de "data privacy", complètement à coté de la plaque si jamais une telle contrainte apparait dans votre appli ( ce qui fut mon cas )

Le sujet est effectivement complexe mais je trouve difficilement acceptable de ne pas y songer et de refuser d'avancer dans cette direction.

Quant aux "alternatives officielles" pour bypass cette contrainte elles varient entre la bidouille et le grotesque : une base par utilisateur résout le pb. disent les "experts". Non mais franchement ....

5. Equipe de dev, pourrais tu descendre de ton nuage ?

Euuh, franchement et très subjectivement : l’équipe core est compétente sur plein de sujets, mais complètement bornée en terme de compréhension du monde "applicatif", bref de ceux qui souhaiteraient utiliser Couch comme storage.

Il y a bein eu qq tentatives de patching pour aller dans le sens (par exemple le multi-view, une manière de combiner les index/vues pour fournir du multi critère) mais elles ont été isolées jusqu'à ce que les contributeurs abandonnent leur idée ou se désintéressent du sujet ...

Ce type de comportement arrive sur pas mal de projets open source, mais je dois avouer qu'il est assez flagrant dans le cas de Couch.

Dommage je pensais que ce projet avait un avenir plus concret et ouvert en terme d’utilisation applicative ....

Conclusion :

Pour palier à tout ces maux, j'ai fini sur une solution hybride :

- tout ce qui concerne l'indexation, la recherche, la sécurité & co => SQL
- storage des documents et réplication/fédérations des données => CouchDB

Bref j’utilise couchDb comme un disque partagé accessible par http . Tout mes indexes sont dans une base sql optimisée.

Je commence vraiment à me demander à quoi me sert Couchdb car je pourrais aussi bien avoir des fichiers sur disque et les répliquer via un rsync ou autre système du genre et y accèder via un banal serveur http ...

Par ailleurs, l'idée était de partir sur du CouchDB pour éviter les réplications de bases SQL pas toujours performantes et pas toujours utilisables dans tous les cas de figure (full meshing par exemple ... ). De ce point de vue c'est raté aussi ....

Bref, tentative peu concluante pour un cout humain toutefois considérable.

Donc le prochain qui me sort que SQL c'est fini je lui colle les deux accolades vite fait bien fait et je compile le tout en %F, nouveau langage dérivé du Cbémol7 et du Hmaj7 dans une suite A/D/A sur un rythme pseudo binaire ..

[pseudocode]

@vosaray:

De un, je dirais que tu avais simplement besoin d'un indexer et pas d'une base de données. De deux, je dirais que tu n'as pas choisi la meilleur base nosql pour ta problématique. (MongoDB aurait été plus logique, si je ne m'abuse)

NoSql n'est pas un mot magique qui règle les problèmes de volumétrie et de performances. C'est une "alternative" qu'il convient de prendre en compte avant de foncer prendre la première base SQL qui traine. Ni plus, ni moins.

[vosaray]

De un, je dirais que tu avais simplement besoin d'un indexer et pas d'une base de données

Quand on a besoin de stocker, indexer et rechercher des données accèssibles par plusieurs applications ou entitiés, on pense très souvent à une BD pour ce faire.

On peut en discuter, mais en dehors de ce contexte je ne vois pas pour quelle raison utliser une bd ....

MongoDB aurait été plus logique, si je ne m'abuse)

Pas vraiement, Mongo ne supporte pas la réplication "meshed", uniquement le master/slave à la mysql.

L'avantage de Couch est justement de "fonctionner" dans un environnement largement réparti, chose que Mongo ne fait pas et ne fera pas dans un proche avenir d'après l'equipe de dev.

NoSql n'est pas un mot magique qui règle les problèmes de volumétrie et de performances

Non certainement pas, mais cela n'empeche pas que les bases NoSQL pourraient faire preuve d'un peu plus de performance et de volumetries plus raisonnables.

Dans mon cas il s'agissait de gerer des documents, en l'occurence des fichiers txt, répartis sur plusieurs sources, accessibles en http(s) avec possibilité de recoupement et de federation de données.

Je continue à penser qu'une base documentaire (comme CouchDB) reste très adaptée à la problematique initiale. Dommage que le reste ne suive pas.

Par la suite une des contraintes du projet était de faire de la réplication et répartition et peu de serveurs relationels sont capables de le faire correctement, avec un cout raisonnable.

Pour conclure, je dirais que le NoSQL n'est pas un souci en soi. Raisonner en clés/valeurs est tout à fait accèptable. Cependant il faudrait :

- pouvoir combiner les vues de manière à effectuer des recoupements ( bref faire de la recherche un minimum multi criteria )
- proposer des fichiers index (vues) un minimum plus dimensionées et pas faire de l'append systematique.

Bref, se rapprocher du monde applicatif et du point de vue intégration plutot que de proposer des solutions, disons intellectuelement valables , mais dont le champ d'application reste très restreint

[pseudocode]

Quand on a besoin de stocker, indexer et rechercher des données accèssibles par plusieurs applications ou entitiés, on pense très souvent à une BD pour ce faire.

On peut en discuter, mais en dehors de ce contexte je ne vois pas pour quelle raison utliser une bd ....

J'ai juste fait cette remarque par rapport à ta conclusion sur ta solution hybride.

Pas vraiement, Mongo ne supporte pas la réplication "meshed", uniquement le master/slave à la mysql.

Effectivement, je ne savais pas que tu avais des contraintes de ce type.

Pour conclure, je dirais que le NoSQL n'est pas un souci en soi. Raisonner en clés/valeurs est tout à fait accèptable. Cependant il faudrait :

- pouvoir combiner les vues de manière à effectuer des recoupements ( bref faire de la recherche un minimum multi criteria )
- proposer des fichiers index (vues) un minimum plus dimensionées et pas faire de l'append systematique.

Bref, se rapprocher du monde applicatif et du point de vue intégration plutot que de proposer des solutions, disons intellectuelement valables , mais dont le champ d'application reste très restreint

Il est certain que les base NoSQL sont pour l'instant uniquement des solutions techniques (à l'instar des bases SQL). Il n'y a pas encore vraiment de solutions applicatives clé-en-main.

C'est vrai que se construire un DataStore avec du NoSql ca nécessite à l'heure actuelle pas mal de plomberie, et ton système hybride me semble une bonne approche.

[vosaray]

Effectivement , j'ai peut être fait un petit post, disons à vocation "thérapeutique" histoire que "ça" sorte.

Du coup les idées sont peut être dans le désordre

Au début du projet on s’était fixé les contraintes suivantes

- un accès aux données via http
- une base de données documentaire avec possibilité de chercher sur les elements de la structure du doc
- une base répliquable en plusieurs modes, pas seulement le master/slave
- une base permettant de chercher rapidement à travers un jeu de documents relativement conséquent ( 800k docs ), quitte à indexer les docs au fur et à mesure de leur création
- une archivage facile et rapide des données

CouchDB semblait, sur papier, taillé pour ce type d'utilisation.

Si on fait sauter la réplication, on peut effectivement considérer le fait d’utiliser une base de données classique ( avec ou sans file system auxiliaire, le blob peut bien marcher pour des documents courts ).

Et c'est c'est malheureusement ce qui se passe au final avec notre solution hybride .

Il est certain que les base NoSQL sont pour l'instant uniquement des solutions techniques (à l'instar des bases SQL). Il n'y a pas encore vraiment de solutions applicatives clé-en-main.

Disons qu'avec CouchDB tu peux utiliser écrire une "CouchApp", un concept d'appli "embarquée" dans Couch !

L'idée est simple et pas bête : l'appli n’étant qu'une suite de docs autant stocker l'appli dans le serveur couch.

Sur papier c'est sympa. En pratique, développer une couch app veut dire : écrire du javascript à gogo, le dispatcher, le gérer sur la base & so on ...

Bref un joli concept technique avec comme preuve d’implémentation l'appli Futon qui administre la BD.

C'est sympa, mais Futon est une appli dont les traitements et l'ergonomie restent simplissimes voire spartiates.

Il est difficile d'imaginer une appli web avec des contraintes métiers rentrer dans la CouchApp. Et si jamais l'appli doit gerer des droits par doc/page, alors ce n'est même pas la peine .

Et ce qui me "tue" c'est que l’équipe de dev est prête à claquer du temps de dev et de discussion sur l'histoire de la "CouchApp", mais que les demandes concernant la sécurité, les perfs des i/o ou tout simplement plus de fonctionnalités sur le moteur de recherche restent lettre morte ...

HS : dsl pour la longeur des posts, mais je suis de nature bavarde

[budtucker]

Bonjour à tous,

1 an plus tard, je pense que la communauté a du prendre plus de recul sur le noSQL et sa mode.

1 an plus tard, je relance ce billet pour relancer ce débat (combat ?) entre le noSQL et le pure SQL. J'aime PostgreSQL et les dernières versions nous montrent qu'il est capable de gérer bien des choses. J'ai tenté MongoDB et malgré l’engouement de certains adeptes, je ne comprends pas comment fonder une architectures convenable et stable avec. Je m'y prends sûrement mal et ce post n'a pas à vocation à dévaloriser aucune base.

Cependant, j'aimerai que l'on m'explique pourquoi et quand utiliser noSQL. Est ce une question de performance (pourtant certains blog montrent que PostgreSQL serait plus performant, à voir), le clustering, autre...

A+

[pseudocode]

1 an plus tard, je pense que le NoSQL a trouvé sa place en tant que "Not only SQL".

SQL reste la solution la plus simple pour des applications raisonnables (données structurées, jusqu'à la centaine de Go, avec peu de modifications).

Le NoSQL reste la solution la plus performante pour gérer du "Big Data" (structures variables, +1000 Go, souvent modifiées).

Après, il y a les cas particuliers où une approche mixte/hybride vaut la peine d'être envisagée.

[rimram31]

Le NoSQL reste la solution la plus performante pour gérer du "Big Data" (structures variables, +1000 Go, souvent modifiées)...

C'est plutôt bien résumé et c'est bien ce qui me gène avec le buzz autour de NoSQL. Il est trop souvent "vendu" par des gens dont les compétences SGBD, en restant gentil, sont assez limitées et vont te proposer du NoSQL de n'avoir su utiliser correctement une SGBD et un layer efficace au dessus.

D'autant plus qu'il est le plus souvent proposé par des gens du web, qui citent Google, Facebook ... Mais quand on sait qu'une BDD est capable de plusieurs milliers de transactions seconde, comme tu le dis, pour peu qu'on ait du 80/20 voir plus de R/W, on a quand même une sérieuse marge

Après un souci de taille pour moi, concrètement, ça donne quoi a l'exploitation? Ou trouve-t-on des "DBA" NoSQL? Quel retour d'expérience en comparaison aux dizaines d'années des SGBD ???

[vosaray]

Salut,

Un an et demi plus tard, je trouve que l'offre "NoSQL" s'est plutôt bien étoffée et a gagné en maturité. Au point même de proposer du SQL aux utilisateurs (Apache Hive par exemple ). On peut trouver ca rigolo, schizophrène, mais en fait à bien y regarder tout cela se tient.

Donc pour ma part j'ai investi pas mal de temps sur Cassandra, une des implémentations de BigTable de Google reprise sous Apache.

Actuellement je travaille sur un proto, qui gère 1T de données compressées contenues dans 4 nodes Cassandra et je suis plutôt très agréablement surpris :

• Les performances de lecture sont très intéressantes (j’ai plus les chiffres en tête mais ca vaut largement une bd sql bien optimisée )
• Les performances d'insertions le sont moins, néanmoins on arrive tout de même à faire ingurgiter environ 8 Milliards de données primitives (strings ou floats) à l’heure
• Le système est vraiment linéairement scalable, on ajoute des nodes et on augmente la bande passante en R et W. (en pratique, les clusters Cassandra n'ont jamais été déployées sur plus de 400 nodes .... J'ai de la marge ...)
• Le système consomme peu d'I/Os (Memory tables, log update, async data flush) et si prend la précaution de séparer les logs du stockage on obtient un système très performant
• L'administration est simple. Plusieurs sociétés proposent de l’expertise, de la formation et on peut aussi souscrite à du support auprès de Datastax. Notez qu’il est très facile d’ajouter ou de démissionner un node.
• Le schéma est variable et column oriented. On peut altérer le schéma de manière dynamique en cours de runtime.
• L’accès peut se faire en Java, mais aussi avec n’importe quel langage
• On peut faire du Map/Reduce Hadoop sur la base car le stockage SSTables est « compatible » HDFS
• On peut faire des requêtes csql , un espèce de mini language sql like, avec possibilité de filtrages et de requêtes imbriqués ( donc relations applicatives )
• On peut ordonner les données en « cube », en fait du hash de hash , assez adapté pour du « analytics », pardon analyse de données multidimensionnelles chère à nos décideurs et data geeks

Pour les inconvénients je dirais que :

• La compression n'est pas très efficace
• Les compactions des tables est longue et consomme pas mal de ressources, pénalisant le système global
• j'ai noté plusieurs instabilités lors de tests aux limites. Malgré un sacré tuning des paramètres de la JVM j’arrive à planter les process … Un peu plus de self defense ne ferait pas mal dans le code.
• Les performances sont en grande partie dues a un design pertinent du modèle de stockage. C'est certes une généralité, mais avec Cassandra c'est flagrant. Donc si on utilise les mêmes données dans des use case différents, on a peut être interret à les dupliquer ( donc plus de place et charge ).

Dans l'ensemble je dirais qu'il s'agit d'un produit prometteur et très adaptée à la distribution, la haute dispo, la réplication et fédération de données intra et inter sites !

Je trouve qu'il lui manque juste un coté un poil plus robuste pour être proche de la solution idéale dans mon cas. Mais cela a encore le temps de s’améliorer dans les mois qui suivent.

Voilà j’avoue être très très agréablement surpris par Cassandra. Au moins autant que j’ai été décu par Couch et Mongo un an auparavant.

Après, si vous me permettez, je trouve qu'il est encore plus difficile de s'y retrouver aujourd'hui avec les nouvelles "tendances marketing" et "keywords" comme "columnar database", "big data", "analytics" et ainsi de suite.

Tout le monde aime les tartines sans savoir ce qu'on va vraiment manger

[Chavenay]

http://kkovacs.eu/cassandra-vs-mongo...uchdb-vs-redis

[el_muchacho]

http://kkovacs.eu/cassandra-vs-mongo...uchdb-vs-redis

Plus utiles, les comparaisons sur le site de Riak.
http://docs.basho.com/riak/1.2.0/ref...ed-to-MongoDB/

[SQLpro]

Le NoSQL reste la solution la plus performante pour gérer du "Big Data" (structures variables, +1000 Go, souvent modifiées).

1000 Go cela ne fait qu'un Tera octet... pas vraiment terrible, j'ai plein de client dépassant cette volumétrie dans un seul serveur...

Comme j'en avais marre de voir que les gens pensent que des bases de données relationnelles ça doit reste à quelques centaines de Go, je me suis fendu d'un article pour vous monter qu'il existe bien des bases de plus de 1 Petoctet sous MS SQL Server et ça se porte comme un charme !
J'ai fouillé certains document en interne chez MS pour vous donner cette analyse :
http://blog.developpez.com/sqlpro/p1...-en-petaoctets

A +