Discussion :

[narmataru]

Bonjour,
Suite à ma prise de concience que je ne pouvais pas utiliser BerkelyDB dans mon projet (commercial) sans licence, je cherche une autre solution pour arriver à mes fins.
Mon but est de stocker des objets (serializble) et de les récupérer par la suite. Je sais qu'il existe la classe ObjectInputStream et ObjectOutputStream mais j'ai peur au niveau des performances. En effet, je doix poivoir stocker plusieurs millions d'objets qui eux-même comporte une liste d'objets.
J'avais choisi BerkeleyDB car apparemment niveau performance ça suivait. De plus, les objets étaient indexé par une clef ce qui aurait pus servir à d'éventuelles améliorations...

Donc pour l'instant je pense développer une petite API qui se chargera d'enregistrer les objets dans plusieurs fichiers de données. 1 fichier ne pouvant contenir qu'un nombre limité d'objet. Ainsi, la taille des fichiers pourra être maitrisé. Est-ce une bonne idée ? La taille des fichiers peut elle jouer sur les performances ?
Désérializer les objet dans une BloquingQueue qui servira de buffer d'objet pour encore augmenter les performance (j'aurais un consommateur qui se chargera de vifer la BloquingQueue).

Est-ce que ça tient la route ? Est-ce que je perd mon temps à fair eça car ça existe déjà ? Y'a-t-il d'autres solutions ?

merci

ps : je ne pense pas qu'un SGBD classique soit approprié car je n'ai pas besoin 'du mode' relationnel qui va ralentir la récupération des données je pense.

[zl]

Il existe une autre solution qui pourrait s'appuyer directement sur les BLOB.

Zl.

[narmataru]

Tu pourrais être un peu plus explicite s'il te plait
Les BLOB sont le stockage de tableau de byte dans un SGBD non ? Quel SGBD me propose-tu ? (ça reviens en fait à ce que je voulais faire avec Berkeleydb)
(et évidemment les transaction était aussi un des points fort pour lesquel j'avais choisi berkeleydb)

[fabszn]

Hello,

J'allais proposer la meme chose..

En fait, un blob tu peux stocker ce que tu veux dedans..
Tu pourrais créer un enregistrement par obj serializer.. avec des informations sur l'objet consultable independament de deserilization de l'objet.
En plus sur les recherches tu pourrais beneficier de la puissance d'un SGBD.

Il existe HSQLDB .. je ne sais si elle gere les blobs..

PS : actuellement je suis des cours au CNAM, je suis un UV sur les SGDB en ce moment , c'est de la que je tiens l'info concernant le blob..

[narmataru]

Oui merci pour votre proposition mais comme je l'ai mis dans mon premier message je souhaiterais éviter un SGBD classque pour faire celà. J'ai peur que la gestion du relationnel des SGBD viennent alourdir les recherches et diminuer les performance. Je n'ai pas besoin de relationnel à ce niveau.
J'utilise déjà cette techinque dans l'étape juste avant dans mon application. J'utilise une base HSQL qui contient 4 champs : 3 champs de recherche et un champ OBJECT (BLOB) ou je stocke l'objet sérialisé.

En fait la partie que je souhaite développer maintenant, récupére les objet à partir de la base HSQL pour les trier dans un certains ordre et lier certains objet entre eux. Ce que j'ai besoin en fait se serais un Iterator sur la liste des objets triés. Ainsi, un seul gros fichier contenant l'ensemble des objet sérialisés et ordonnés me conviendrais, mais j'ai peur que sur des fichier qui pourrais aller jusqu'a plusieurs GO ça perd en efficacité

[manube]

Salut,
Je ne pense pas trop me tromper en disant que pour les performances tu devrais utiliser un SGBD (il ont été créés pour ca).
Sinon j'avais une autre piste pour toi c'est de t'orienter vers les bases de données Objet (comme caché par ex) si tu n'as pas besoin de la partie relationnelle. Par contre, niveau licence je n'y connais rien dc je te souhaite bon courage.
+

[narmataru]

Bon je vais peut être me laisser tenter alors
Je suis preneur si quelqu'un peut me confirmer que HSQL permet de faire une requête du type "Select id,blob from data" sur un table data contenant plusieurs millions de données. Ainsi, un ResultSet devra être généré rapidemment (30 secondes étant déjà beaucoup). Alors il ne me restera qu'a faire :

Code :

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

1
2
3
4
while(resultset.hasNext(){
   MonObjet mo = (MonObjet)rs.getObject("Blob");
   traitement(mo);
}

Mon problème est bien que je dois itérer sur l'ensemble des données d'une table de façon efficace.

Personnellement je trouve qu'utiliser un SGBDR dans ce cas n'a pas d'intéret car jen'aurais qu'une seule table avec 2 colonne (id:autoincrément, blob). Mais si HSQL répond à ce problème, en mode processus et non client/serveur, je prend

[narmataru]

bon déjà ça commence mal
http://hsqldb.org/web/hsqlFAQ.html#BIGRESULTS

Selecting big results / Scanning big tables

One limitation of HSQLDB is that it currently does not support server side cursors. (This allows it to run without any writeable media). This means the result of a query must always fit in memory, otherwise an OutOfMemory error occurs. In the rare situation that a huge resultsets must be processed, then the following workaround can be used:

Limit the ResultSet using Statement.setMaxRows(1024), and select multiple 'smaller' blocks. If the table is for example 'CREATE TABLE Test(Id INT IDENTITY PRIMARY KEY, Name VARCHAR)' then the first block can be selected using 'SELECT * FROM Test'. The biggest ID should be recorded and the next block should be selected using 'SELECT * FROM Test WHERE Id>(biggest_id)' until no more records are returned. Don't forget to switch of the limit using setMaxRows(0).