Discussion :

[julieng31]

Bonjour,

je suis actuellement en train d'écrire un programme qui fait un calcul sur diverses configurations. L'objectif est de pouvoir faire un milliard de configurations en quelques jours. Pour chacune des configurations, j'aimerais enregistrer quelques paramètres d'entrée, des résultats intermédiaires et les résultats finaux (disons l'équivalent de 20 variables de type double). Les calculs étant déjà lourds, il faudrait que le temps d'écriture ne prenne pas trop de temps.

Une fois les calculs terminés, j'aimerais avoir la possibilité de visualiser n'importe quelle configuration pour vérifier que tout s'est bien passé mais aussi analyser les données : les présenter sous forme de carte, sous forme de graphiques... Donc parser les données de manières très variées et ceci pratiquement en temps réel (ie réponse en une dizaine de secondes).

Un calcul rapide me fait penser que je serai dans un ordre de grandeur de quelques dizaines voir centaines de Go.

J'aimerais donc savoir comment pouvoir gérer cela. Voici mes idées, mais j'imagine qu'il existe des techniques plus efficaces :
* stocker chaque paramètre dans un fichier binaire :
- avantage = je peux aller chercher une info assez rapidement avec un seekg()
- inconvénient = plusieurs fichiers ouverts en parallèle => est-ce que ce ne sera pas limitant au moment d'écrire sur le disque
- question : un thread dédié à l'écriture, ça a un sens ?
* stocker tout ça en XML
- avantage : tout dans le même fichier et simple à lire pour l'utilisateur
- inconvénient : XML verbeaux et même en SAX, ça risque d'être long à parser ?
* j'ai lu qu'il existait des formats XML compressés comme du EXI ?
* base de donées : efficace avec un tel volume de données ?

Auriez-vous des conseils à me donner ? Merci d'avance.

[bacelar]

>Auriez-vous des conseils à me donner ?
Ne pas réinventer la roue. Des solutions "Big Data", il y en a des dizaines, dont un bon nombre en Open Source.

[julieng31]

Bonjour bacelar et merci pour cette première réponse.

En cherchant sur Google, j'ai trouvé STXXL. Est-ce de cela dont tu parles ? Est-ce que tu aurais un ou 2 noms de solutions open source car je n'en trouve pas beaucoup, je ne dois pas utiliser les bons mots clés. Avec quelques noms de solutions, je pourrai plus facilement cibler des solutions adaptées.

[bacelar]

Des solutions open source, il y a pléthore :
http://www.datamation.com/data-cente...ig-data-3.html
Il faut caractériser votre problème.
L'avantage des solutions Big Data, c'est qu'elles occupent des aspects parallélisassion, résistance aux pannes, de la distribution sur des fermes de serveurs, de la mise en forme pour de l'addichage BI ...

La solution STXXL semble être juste pour faire tous les calculs et autres mise en forme dans un seul noeud.
Vous aurez des problèmes de mise à l'échelle avec la croissance de la taille des données.

[julieng31]

Merci encore bacelar,

je suis en train de lire ce que propose le lien (et de découvrir car je n'avais jamais été confronté à ce genre de problématique). Pour caractériser un peu mieux le problème en attendant, je dirais que ça ressemble à ceci :

Une interface graphique (Qt/C++) avec 2 onglets :
* un onglet qui contient un bouton calcul, utilisé lorsque toutes les configurations sont mises en place. Il lance un code de ce type (pseudo code) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
for(unsigned long int i=0; i<nb_tirage; i++) { // nb_tirage pouvant aller jusqu'à 1 milliard
    double inputs[], outputs[];
    inputs[x] = generate_random_laws(); // Génère aléatoirement une série de valeurs
    outputs[x] = compute_scenario(inputs[]); // Génère une série de résultats
    store(i, inputs[], outputs[]); // Un stockage au fil de l'eau
}

=> Le calcul est très complexe et prend plusieurs jours. Il faudrait donc que le 'store' ne prenne pas trop de temps pour ne pas rallonger l'ensemble. Disons que si ça prend quelques heures par rapport à quelques jours, c'est un bon ordre de grandeur
* un onglet analyse qui permet par exemple
- aller chercher toutes les valeurs d'un type entre i=X et i=Y pour l'afficher sous forme de courbe
- aller chercher toutes les valeurs de 2 ou 3 types pour en faire un plot 2D ou 3D
- aller chercher toute les valeurs d'un type pour en faire une statistique.
=> L'objectif serait d'avoir quelque chose de réactif (ie que ça réponde en une dizaine de secondes). C'est la contrainte prioritaire.

Tout cela sur un PC puissant (8 à 16 coeurs en général) et en local (sur disque dur de la machine).

Je ne sais pas si c'est assez complet pour aiguiller le choix. Et si cela est faisable, bien sûr.

[ternel]

Si ca reste en local, alors une base de données devrait suffire.

Normalement, les solutions big data sont pensée pour des systèmes comme l'indexation des pages web.
Des quantités de données énormes. Vraiment énormes.
Qui requiert des dizaines de serveurs pour le stockage, et d'autres encore pour le calcul.

Dans ton cas, vu que tu restes dans le cadre d'un seul poste, ce n'est pas vraiment adapté.

[julieng31]

Merci leternel.

Après une recherche sur Internet, j'ai vu plusieurs fois que SQLite (que j'avais déjà utilisé) n'était pas très performant pour des gros volumes de données. J'ai lu plusieurs fois que Berkeley DB était rapide même sur de gros volumes. Ca semble un bon choix ?

[bacelar]

>Tout cela sur un PC puissant (8 à 16 coeurs en général) et en local (sur disque dur de la machine).

Vous ne pourrez jamais atteindre du "que ça réponde en une dizaine de secondes" si le traitement de base "Le calcul est très complexe et prend plusieurs jours".

Il faut passer à l'echelle avec Cloud/Cluster/DataCenter et Big Data vous permettrait gérer cela "facilement".

Vos requêtes semblent plus adapter à des bases OLAP/DataMining qu'à des bases OLTP classique.

Pour moi, sauf erreurs d'implémentation du traitement "de base", vous ne gagnerez, AU MAXIMUM, qu'un facteur 16 (nombres de coeur-virtuelle) via une parallélisation "massive".

Qu'est-ce que vous avez tout au début ?
Moi, j'ai l'impression que vous générez toutes les données à la volée.
Le Big Data, c'est pour traiter beaucoup de données peu structurées, pas pour en générer.
Et si vous générez les données, vous avez beaucoup plus de latitude sur le système de stockage intermédiaire.

[julieng31]

Vous ne pourrez jamais atteindre du "que ça réponde en une dizaine de secondes" si le traitement de base "Le calcul est très complexe et prend plusieurs jours".

L'application est en 2 étapes :
* une première phase de calcul qui dure plusieurs jours. Pour cela, je n'ai pas de contrainte trop forte. Je calcule 1 milliards de configurations et je voudrais stocker entre 10 et 20 données par configuration.
* c'est sur la deuxième étape que j'ai une contrainte de réactivité acceptable (dizaine de secondes). L'opération est alors : aller chercher les bonnes données et pouvoir les afficher sous diverses formes. Elle est réalisée une fois la première étape terminée.

Vos requêtes semblent plus adapter à des bases OLAP/DataMining qu'à des bases OLTP classique.

Je vais me renseigner, je ne connais pas cela.

Qu'est-ce que vous avez tout au début ?
Moi, j'ai l'impression que vous générez toutes les données à la volée.
Le Big Data, c'est pour traiter beaucoup de données peu structurées, pas pour en générer.
Et si vous générez les données, vous avez beaucoup plus de latitude sur le système de stockage intermédiaire.

Une boucle "for" avec 1 milliard d'itérations qui génère des données structurées en "numéro d'itération, entrée 1, entrée 2.., résultat intermédiaire 1, résultat intermédiaire 2,... , résultat final 1, résultat intermédiaire 2...". Maintenant, j'en suis à l'étape : "comment stocker toutes ces données quelque part" (il y en a beaucoup) et comment les analyser rapidement. Le tout dans une application Qt/C++.

Que voulez-vous dire avec une structure intermédiaire ? Par exemple un std::vector de structures qui contiennent les données ? Ca va faire plusieurs dizaines de Go.

[bacelar]

Le plus simple est de choisir le type de base de données en fonction du type de requêtage que vous allez lui demander.

[ternel]

Pour information, SQLite est un moteur SQL à embarquer, qui ne s'intéresse qu'à des bases situées dans un fichier unique.
Ainsi, pour installer une telle base, il suffit de copier le fichier.
Il n'y a pas de serveur à installer à côté de votre programme.

Par contre, c'est un fichier unique, donc potentiellement lent.

Je reprends votre situation:
1 Giga Situation * 20 données.
Si la moitié des données sont du texte, ca fait environ 10 Tera de données (un demi ko par données)

C'est clairement trop pour SQLite, certes.

Mais c'est largement dans la portée des systèmes SQL standard (par exemple, MariaDB, le successeur de MySQL)

Ton problème sera alors d'écrire tes tables intelligemment.
Si tu parviens à définir une clé unique identifiant chaque configuration, trouver l'une d'entre elle doit être environ "immédiat".
En trouver plusieurs sera environ "presque immédiat".

BerkeleyDB n'est pas souvent un bon choix, mais il faut se poser la question, en effet.

Mon avis, c'est que vous n'avez pas encore manipulé les bases de données.

Faites une maquette avec 10 000 configurations, et par exemple SQLite, ca vous donnera le temps de goûter le problème.
Ensuite, il sera temps de voir si votre problème est réellement si immensément énorme qu'il faut recourir à une solution distribué (Big Data) ou simplement une base de données. (je ne pense pas que vous ayez besoin de l'artillerie lourde)

Si vous avez besoin d'aide dans la conception de votre base de données, je vous conseille d'aller faire un tour dans le forum dédié.
N'hésitez alors pas à faire un lien sur cette discussion.

[julieng31]

Merci d'avoir pris le temps de répondre. J'étais plutôt inquiet sur le volume global de données mais je pense comprendre que ça se gère bien, même avec du SQL. Je vais donc commencer à faire des essais !