Discussion :

[altair8080]

Bonjour,
1/ Je ne parle pas du choix entre Nosql et SGBDR

2/Le besoin
- haute performance
- scalable
- réparti dans des lieux géographiques potentiellement différent pour la base locale (genre proxy )
- centralisation des données sur une base centrale (agregation des données des bases locales)

L'usage : remonté des milliers d'indicateurs par minutes divers et variés
avec des structures de données différentes et évolutives de façon indépendante

sur chaque base et sur la principale :
- suivi des indicateurs
- agregations
- filtrage
- enrichissement
- fusion
- modification

et à l'inverse des modifications, actions sont renvoyées vers les programmes autonomes pour modifier les comportements


Donc je ne sais quel type de base utiliser
- je suis plutot dans la direction Document mais je ne suis pas certains du choix optimum

Merci

[el_muchacho]

La quantité totale de disque utilisé est limitée à combien sur les bases locales et la base centrale ? Ces indicateurs peuvent être supprimés au bout d'un certains temps ou ils sont destinés à être stockés et utilisés ad vitam aeternam ?
Peut-on pré-calculer un certains nombre d'agrégats/filtres sur les bases locales histoire de décharger la base centrale ? Sur la base centrale, les opérations se feront-elles sur l'ensemble des données récupérées des diverses bases locales ?

[altair8080]

Effectivement les bases locales sont là pour décharger la base centrale de certaines tâches : contrôle, agrégation ...
Mais les données brutes doivent tout de même remonter pour pouvoir traiter d'autres demandes.

L'objectif général concerne la gestion de parc informatique de sites distants qui peuvent appartenir ou non à un même groupe/entreprise.

Les bases locales sont pour la supervision locale
Mais la base centrale permet de superviser l'ensemble pour être alerté un d'un problème ou à l'inverse envoyer des actions/parametrages

On doit donc pouvoir conserver un historique de données assez important pour voir des courbes de tendances mais aussi pour voir l'évolution des états dans le temps

[el_muchacho]

Mettons 3000 insert/mn, soit 50/sec, ça fait 1,6 milliard/an. SQLPro pourrait confirmer ou infirmer, mais je pense que les traditionnels Oracle/Sybase/SQL server sont capables de gérer cela au moins sur un an sans faillir. Un test permettra de vérifier. Après, il faut faire une coûteuse course à l'armement (Oracle RAC, etc) . Sinon pour des volumes de données plus importants (aucune suppression de données dans le temps) et les facilités de réplication, je dirais HBase ou Cassandra. Compte tenu du fait que vos données sont immutables (il n'y aura pas d'update), la consistence éventuelle ne devrait pas poser de problème. Mais les opérations possibles sur ces bases sont très limitées. En gros, on ne peut pratiquement faire des requêtes que sur la clef primaire. Pour toutes les opérations sur les colonnes, il faut rajouter du Hadoop ou effectivement faire faire les opérations d'aggrégation, etc par d'autres bases en temps différé. Sinon des produits spécifiques comme Greenplum sont capables de faire cela, mais le coût risque d'être rapidement très élevé si vous gardez toutes les données dans le temps (30 000$/To). MongoDB est p-ê mieu armé pour cela, mais je me méfie du lock niveau base. Enfin, pour la remontée d'alarmes et les opérations en temps réel, utiliser un complex event processor comme Storm, Esper ou des équivalents commerciaux. Ce système peut aussi faire des précalculs et des préaggrégations que l'on peut insérer en base en prévision des requêtes futures (par ex. le nombre de machines down pour chaque site durant la dernière minute). Ce sera bien plus efficace que d'effectuer de grosses requêtes sur l'ensemble des données.

[SQLpro]

C'est du pipi de chat pour un SGBDR ou en compte en générale en transaction et non en simple commande SQL, une transaction étant un ou plusieurs ordres SQL devant être joués en tout ou rien !
Un petit exemple est Itaù banque avec une base de 50 To :
4 milliards de calculs effectués chaque jour en moins d'une heure...

A lire : http://blog.developpez.com/sqlpro/p1...-en-petaoctets

En sus pour votre système vous aurez besoin d'implémenter une réplication de données, et là il n'y a pas beaucoup d'offres toutes faites dans le NoSQL. En comparaison, SQL Server propose 5 modes différents de réplication, dont 4 sont fait par des assistants que l'on peut mettre en œuvre, même sur une grosse réplication, en moins d'une journée !

• réplication transactionnelle
• réplication par cliché (snapshot)
• réplication de fusion
• réplication peer to peer
• service broker

A +