Discussion :

[jmguiche]

Maîtriser, c'est le mot !

Mais pour maîtriser, encore faut-il être capable de sortir le nez de la technologie que l'on utilise depuis 20 ans et admettre la possibilité qu'une nouvelle façon de faire soit meilleure sur certains plans...

Pour comparer deux techno, il faut les connaitre un peu, c'est raisonnable.

Je ne suis pas totalement d'accord sur le "... certains plans.".
Nous devons avoir une approche globale et technico-économique. Ce qui compte c'est le 'time to market', le cout d'aquisition, le cout de possession (qui doit inclure l'évaluation des couts de maintenance évolutive).
Il est certain, qu'en fonction du type de projet, on peut arriver à des résultats totalement diférents en terme d'architecture.

[trinoo]

Certains informaticiens considèrent leurs outils de travail comme une religion. Et finalement on se retrouve dans les croisades; Mon Dieu est plus puissant, prosternes toi, ton truc est nulll !!!.

On tombe des fois sur des comparatifs de carottes avec des pneus d'hiver !!!

Pour moi les noSQL répondent parfaitement à ce que je cherchais depuis longtemps, une base de données sans structure tabulaire. Bien avant, j'avais opté pour l'utilisation de l'XML vue que c'est un structure en arborescence flexible évolutive.

Ce qui ne veux pas dire que je vais migrer d'SQL pour rejoindre noSQL.

Ce n'est pas la techno qui choisie son application, c'est plutot le contraire.
Donc, SQL n'est pas mort, et il sera encore une technologie fiable qui a fait ces preuves et continuera d'exister.

On pourra même utiliser deux SGBD voir plus pour une seule application; Du SQL là ou les données demandent une structure rigide, des contraintes, de l'intégrité,...etc.. et une autre noSQL pour du contenu qui demande une flexibilité et évolution dans le temps.

J'ai connu aussi d'autres apotres SQL, qui ont la foi en l'intégrité référentielle et chasse le démon présent dans les doublons.

Je pense qu'il ne doit pas y avoir des dogmes en informatique et que chaque règle trouve toujours un cas particuliers pour la contredire.

Quand je vois plus de 2 SELECT imbriqués pour gagner une place au paradis avec l'intégrité référentielle. J'opte pour le triden du diable en rajoutant un champs en doublons dans d'autre tables. (J'entends déjà gueulé les fidèles)

En fin de compte c'est impressionnant de voir le nombre de commentaires sollicités par l'apparition des noSQL. Les nouveaux à école ont toujours droit à un séance de bizutage, par la suite on ne le remarque plus..

[SQLpro]

Il faut comparer les fonctionnalités, le prix et la facilité de mise en oeuvre.

- Avec un SGBDR, on commence par acheter un serveur, genre Core 2/4 + disques SCSI 200Go en RAID 5 (pour la tolérance de panne). Et puis, lorsque les bases sont pleines, on rachète encore des disques en RAID 5. On arrête le serveur, on ajoute/configure le raid, et on étend les tablespaces. Et puis, quand c'est plein, on achète une baie SAN + disques. On arrête le serveur, on crée des nouveaux tablespaces sur la baie et on migre les données. Et puis, maintenant qu'on a un gros volume de données, c'est lent. On achète un deuxième serveur. On arrête le 1er serveur et on monte un cluster avec les 2 serveurs. etc. etc.

- Avec un truc genre BigTable, on commence par utiliser un PC "entrée de gamme" (c-a-d pentium 4 + disque 200Go) qu'on branche sur le réseau. On en prend un deuxième, on le branche aussi sur le réseau et on le configure en copie/backup (pour la tolérance de panne). Lorsque les bases sont pleines, on prend un 3ème PC, on le branche sur le réseau et on le configure en extension. idem avec un 4ème PC, 5ème PC, ... , 100ème PC ! Pas de problèmes de lenteur car plus de PC = plus de perf.

Ce que vous dites est faux... Il y a longtemps que Oracle, SQL Server ou IBM DB2 savent faire cela à chaud avec les serveurs adéquats. Pas besoin d'arrêter un serveur pour ajouter un disque ou une baie SAN. Pas besoin d'arrêter un serveur pour déplacer les fichiers d'une base, les partitionner ou les consolider. Ceci fait même partit des critères de base pour savoir si l'on a affaire à un SGBDR depuis les années 80. Voici le papier de Codd sur le sujet :
http://sqlpro.developpez.com/SGBDR/ReglesCodd/
(12 règles de COdd, et en particulier les règles 8 et 11)

Bref, encore une fois : ignorance du sujet !

[B.AF]

Non ce qu'il dit est plutôt juste au sens où la plupart des SGBD utilisent des instances machine physique. Le fait est que le point soulevé n'est pas le fait de redémarrer, il est le fait de pouvoir construire une architecture scalable avec un coût technique réduit.
Il y a des techniques et fonctionnalités qui permettent de penser que oui, mais ce n'est pas du tout le fonctionnement des moteurs SGBD actuels, d'où d'ailleurs pour le web la généralisation des solutions de cache distribué qui comble ce vide.

[pseudocode]

Voici le papier de Codd sur le sujet :
http://sqlpro.developpez.com/SGBDR/ReglesCodd/
(12 règles de COdd, et en particulier les règles 8 et 11)

Bref, encore une fois : ignorance du sujet !

Les règles 8 et 11 expliquent que le langage (SQL) doit être indépendant de la technique de stockage (physique) des données. C'est à dire qu'on ne devrait pas réécrire son code SQL si on "migre" sa base de données.

Ca n'a absolument aucun rapport avec la facilité/transparence d'upgrade des SGBD. Et je met au défi un DBA (même confirmé) de migrer facilement et de façon totalement transparente un serveur "P4 + disques internes" vers un serveur "cluster x100 + baie SAN"

[B.AF]

Bref, encore une fois : ignorance du sujet !

[Jester]

Pour moi les noSQL répondent parfaitement à ce que je cherchais depuis longtemps, une base de données sans structure tabulaire.

"NoSQL is a fast, portable, relational database management system without arbitrary limits" donc tabulaire.

[cyrianox]

Certains informaticiens considèrent leurs outils de travail comme une religion. Et finalement on se retrouve dans les croisades; Mon Dieu est plus puissant, prosternes toi, ton truc est nulll !!!.

dans ma religion c'est nothing

Quand je vois plus de 2 SELECT imbriqués pour gagner une place au paradis avec l'intégrité référentielle. J'opte pour le triden du diable en rajoutant un champs en doublons dans d'autre tables. (J'entends déjà gueulé les fidèles)

oui mais. Je ne suis pas intégriste, mais je préfère me casser un peu la tête et ne pas créer de doublons, pas par "respect" de la doctrine, mais parce que je sais que mon application sera plus facile à maintenir à long terme.

[B.AF]

dans ma religion c'est nothing mais parce que je sais que mon application sera plus facile à maintenir à long terme.

Tu as raison, c'est un vrai probléme. Même avec une énorme documentation, j'ai toujours reconnu qu'il vaut mieux une base bien modélisée avec des procédures stockée bien faites, les bonnes relations, indexée, les bonnes vues, les bons triggers.

Seulement dans ce cas que j'ai déjà rencontré, c'est une horreur à maintenir.
Disons même que le coût de maintenance pourrait être l'exponentiel de la complexité fonctionnelle du sujet auquel l'application répond.

Et parfois, c'est aussi le premier facteur de dégradation de la base.

[SQLpro]

Les règles 8 et 11 expliquent que le langage (SQL) doit être indépendant de la technique de stockage (physique) des données. C'est à dire qu'on ne devrait pas réécrire son code SQL si on "migre" sa base de données.

Ca n'a absolument aucun rapport avec la facilité/transparence d'upgrade des SGBD. Et je met au défi un DBA (même confirmé) de migrer facilement et de façon totalement transparente un serveur "P4 + disques internes" vers un serveur "cluster x100 + baie SAN"

Défi accepté. Cela se fait sans aucune interruption de service avec, par exemple, le mirroring synchrone de base de données.

A +

[B.AF]

Je ne vois pas le rapport.

[pseudocode]

Défi accepté. Cela se fait sans aucune interruption de service avec, par exemple, le mirroring synchrone de base de données.

A +

Je n'ai pas dit que ce n'était pas possible. J'ai dit que ce ne serait pas facile meme pour un DBA confirmé. Passer d'un PC standard à un cluster de 100 machines, ce n'est pas une "petite opération" de maintenance.

En tout cas, je trouve cela plus compliqué que de pluguer 100 PC sur un backbone et laisser la DHT se mettre à jour, façon emule.

[voran]

Il faut comparer les fonctionnalités, le prix et la facilité de mise en oeuvre.

- Avec un SGBDR, on commence par acheter un serveur, genre Core 2/4 + disques SCSI 200Go en RAID 5 (pour la tolérance de panne). Et puis, lorsque les bases sont pleines, on rachète encore des disques en RAID 5. On arrête le serveur, on ajoute/configure le raid, et on étend les tablespaces. Et puis, quand c'est plein, on achète une baie SAN + disques. On arrête le serveur, on crée des nouveaux tablespaces sur la baie et on migre les données. Et puis, maintenant qu'on a un gros volume de données, c'est lent. On achète un deuxième serveur. On arrête le 1er serveur et on monte un cluster avec les 2 serveurs. etc. etc.

- Avec un truc genre BigTable, on commence par utiliser un PC "entrée de gamme" (c-a-d pentium 4 + disque 200Go) qu'on branche sur le réseau. On en prend un deuxième, on le branche aussi sur le réseau et on le configure en copie/backup (pour la tolérance de panne). Lorsque les bases sont pleines, on prend un 3ème PC, on le branche sur le réseau et on le configure en extension. idem avec un 4ème PC, 5ème PC, ... , 100ème PC ! Pas de problèmes de lenteur car plus de PC = plus de perf.

Pour ma culture personnel, un truc genre BigTable ... kezako ???

A part ça on atteint un niveau de crédibilité professionnelle proche de zéro avec la démarche suivante :
- la base est pleine, j'ajoute un serveur et ainsi de suite jusqu`à arrivé au mode cluster ...

[voran]

En tout cas, je trouve cela plus compliqué que de pluguer 100 PC sur un backbone et laisser la DHT se mettre à jour, façon emule.

Encore une fois on parle de quoi au juste ?
Cette solution existe chez qui ?

[pseudocode]

Encore une fois on parle de quoi au juste ?

On parle de stocker/indexer/rechercher d'énormes quantité de données.

Cette solution existe chez qui ?

C'est utilisé par des petites startup du genre Amazon ou Google.

[SQLpro]

Encore une fois ce n'est que de la recherche, pas de la transaction. Une base de données relationnelle est faite à la fois pour les données écriture concurrentes et lectures concurrentes. Et là c'est pas avec du Bigtable que vous y arriverez !

A +

[pseudocode]

Encore une fois ce n'est que de la recherche, pas de la transaction. Une base de données relationnelle est faite à la fois pour les données écriture concurrentes et lectures concurrentes. Et là c'est pas avec du Bigtable que vous y arriverez !

Oui, je suis bien d'accord que le SGDB Relationels ont tout un tas de fonctions que les key/value-store n'ont pas. Comme je l'ai déjà dit, je ne suis pas un opposant au SGBDR : je prétend juste que le SGBDR n'est pas la solution universelle a tous les problèmes de stockage/recherche et qu'il y a un marché pour les kv-store.

Si on prend l'exemple des transactions ACID, ce sont des fonctions qu'il est toujours possible de rajouter "au dessus" du kv-store (par exemple avec des techniques de commit en 2 passes).

[SQLpro]

Si on prend l'exemple des transactions ACID, ce sont des fonctions qu'il est toujours possible de rajouter "au dessus" du kv-store (par exemple avec des techniques de commit en 2 passes).

C'est justement là ou le bât blesse. En effet le COMMIT à deux phases (TWO PHASES COMMIT ou 2PC) ne garantit aucunement que la transaction sera atomique. En effet même si la phase 1 de prévalidation dit que tous les serveurs sont capable de valider, à la phase 2 d'imposition, l'un des serveurs peut être en état d'impossibilité de valider.... ce qui conduit au désastre car les données seront validées sur tous les serveurs sauf 1 !
Personne à ce jour n'est capable de résoudre ce cas de figure hélas courant !

A +

[pseudocode]

C'est justement là ou le bât blesse. En effet le COMMIT à deux phases (TWO PHASES COMMIT ou 2PC) ne garantit aucunement que la transaction sera atomique. En effet même si la phase 1 de prévalidation dit que tous les serveurs sont capable de valider, à la phase 2 d'imposition, l'un des serveurs peut être en état d'impossibilité de valider.... ce qui conduit au désastre car les données seront validées sur tous les serveurs sauf 1 !
Personne à ce jour n'est capable de résoudre ce cas de figure hélas courant !

A +

Là ce n'est pas un problème lié au kv-store, mais lié à l'architecture distribuée. Potentiellement un noeud du réseau peut cesser d'être opérationnel entre les deux phases. D'ailleurs la problématique est la même pour une transaction impliquant un SGBDR distribué, ou plusieurs SGBDR. Des algos comme PAXOS permettent de gérer un peu mieux ces problèmes.

Mais effectivement, le kv-store ne s'occupe que du "stockage" et pas du tout de l'aspect transaction. Ce ne sont pas les mêmes problématiques, raison de plus pour faire une petite place au kv-store.

[SQLpro]

Mais effectivement, le kv-store ne s'occupe que du "stockage" et pas du tout de l'aspect transaction. Ce ne sont pas les mêmes problématiques, raison de plus pour faire une petite place au kv-store.

Note bien que les KV-store comme tu les appellent ne sont autre que des choses qui ont déjà existé et sont mort du fait du Darwinisme. Cela s'appelait autrefois les bases de données multivaluées. Champion du genre Pick dans les années 70... pas vraiment nouveau !
Bref, on fait du neuf avec du vieux en faisant croire que c'est beaucoup mieux que le reste... Cela s'appelle du marketing !

A +