Stocker des données "efficacement" sur le disque

Bonjour, je me posais une petite question. Pour un projet d'école, j'ai une application qui va recevoir des données venant du réseaux au fur et à mesure. Et mon application n'a pas besoin de garder les messages en entier en mémoire. Et j'ai besoin que ça soit persistant. Donc je suis obligé passer de par le disque dur.

Mon idée était donc de garder en mémoire seulement les identifiants des messages (c'est obligatoire de toute façon vu le projet) et ensuite, de récupérer (donc chercher) le message seulement quand il y a une demande par le réseau.

Seulement, je souhaitais trouver un moyen un peu sioux pour pas avoir à tout stocker dans un seul fichier mais le répartir dans plusieurs fichiers.

Si je mes tout dans un seul fichier, je n'ai pas un temps constant pour la recherche. Mon idée, c'était donc de passer par un filtre de bloom qui me permettrait de donner dans quel fichier je dois regarder.

En utilisant les bons paramètres pour un filtre de bloom et une longueur maximale à mes fichiers, j'aurais donc une temps constant sur la recherche modulo les appels systèmes.

Auriez-vous d'autres idées qui seraient meilleurs pour ce que je souhaite faire ? A savoir que je n'aurais jamais à supprimer les données stockées.

Merci d'avance,

Saroupille

Auriez-vous d'autres idées qui seraient meilleurs pour ce que je souhaite faire ?

Je n'ai jamais utilisé de filtre de bloom, aussi je ne me rends sûrement pas bien compte de l'optimisation que ça entraîne, d'autant plus que les faux positifs me posent un problème philisophique .

Aussi, au vu de l'énoncé, j'ai en tête une solution beaucoup plus bourrine:

Mon idée était donc de garder en mémoire seulement les identifiants des messages

Est-ce que les identifiants sont uniques ? (je sais, ça paraît profondément stupide comme question, mais je préfère demander) Si oui, ma solution c'est : un fichier par message, le nom du fichier étant l'identifiant du message.

Du coup, tu sais directement par appel système si le fichier existe ou non.

Problème : si tu as des messages très petits (et nombreux), tu exploses le nombre de fichiers, donc finalement tu rebalances le problème à l'OS, qui lui n'a pas autant de moyens que toi d'être sioux. De plus, pour le cache disque c'est un peu cramé …

Oui les identifiants sont globalement¹ uniques. Et la solution de mettre l'identifiant comme nom du message était ma première idée. En y repensant ça fonctionne, mais je cherchais pour le coup à être un peu plus compact.

Comme on ne peut pas supprimer de message, et au vu du protocole, je préfère envisager le cas où on pourrait avoir facilement des centaines de messages. Surtout si un pair s'amuse à faire de l'inondation.

Autre solution : séparer les champs en faisant un fichier par champ.

Exemple : si le message a:

• un id
• un contenu
• une provenance

Tu as 3 fichier, un d'id, un de contenu, un de provenance.

Du coup, certes tu as un temps de recherche variable sur les id, et tu choppes sa ligne, que je vais noter X. Ensuite, pour avoir le contenu du message, tu vas dans le fichier de contenu à la ligne X, et tu as le contenu du message. Même chose pour la provenance.

Ou alors tu charges dans un tableau le fichier d'id une bonne fois pour toute, et comme ça c'est réglé.

Et pourquoi ne pas utiliser un sgbd avec une seule table? C'est peut etre trop lourd apres tout… Mais si tu as potentiellement des centaines de messages, je pense que la place du sgbd fini par etre negligeable.

@dosmpm: en quoi ta solution est meilleure que celle que je propose avec un filtre de bloom ?

@rococotam: un SGBD c'est beaucoup, beaucoup trop lourd. J'ai vraiment pas envie d'en utiliser une.

@Saroupille, et SQLite ? c'est pas plus lourd/compliqué que gérer trouzemille fichiers.

Salut,

Si tes messages ont une taille maximale raisonnable, il est possible de conserver l'identifiant du message et sa position dans le fichier. Ainsi, pour récupérer un message, il te suffit de te déplacer à son emplacement et à le lire.

Perso je conseillerais aussi le mini-SGBD. La taille de SQLite est de l'ordre de 500 Ko, donc probablement négligeable sauf si tu es sur un système embarqué très critique en ressources.

L'avantage du SGBD sur un fatras de fichiers, c'est quand même la puissante simplicité des index; à terme avec des milliers d'enregistrements, beaucoup plus efficace que n'importe quel méthode d'indexation maison.

Mes vdd ont raisons, sqlite est vraiment lite. Ça me semble être une très bonne solution à ton problème.