HSQLDB et gros texte

[sandytarit]

Bonsoir

Quel "type" sql (varchar,blob..)serait adapter pour stocker du texte assez long dans un champ de base de donnée HSQLDB ?

merci pour vos réponses

[grabriel]

Salut,

J'ai regardé dans la doc et ils ne parlent pas de blob???

http://hsqldb.org/doc/guide/ch09.html#datatypes-section

par contre y'a LONGVARCHAR j'ai aussi lu dans la mailing qu'une personnes avait des problèmes avec le stockage de ses champs varchar trop long... un out of memory, lorsqu'elle appelait le contenu de sa table (il utilisait des tables text). Ce post vaux pas grand chose puisque je t'apporte aucune info pertinente mais vu que personne n'a répondu!!!!
J'utilise HSQLDB et j'aurai aussi à faire face à ton problème pour stocker de gros texte donc ta solution m'intéresse, si tu en trouve une.

[sandytarit]

Je crois déjà que je vais plutôt utilisé H2
http://www.h2database.com/html/frame.html

Je l'ai testé elle fonctionne exactement pareil que hsqdb mais est beaucoup plus performante en terme de temps d'accès et si on veut stocker la base en mémoire elle uitlise beaucoup moins de mémoire lors d'insertion de champ que hsqldb et il existe un type blob

[grabriel]

Rahhhh !!!

C'est un peu trop tard pour moi de changer de base donc je pense que je vais continuer sur hsqldb mais peut etre qu'un jour si je n'ai pas le choix je suivrai ta voie en penchant pour H2....

[epsilon68]

j'avais bien demarré mon projet avec HSQLDB, c'etait vraiment bien ...
jusqu'a un out of memory avec une requete
update matable set monchamps = null

la table avait 40000 enregistrements...

je suis passé a H2 a grand coups de sueur ...
mais un resultat niquel, plus d'exception...

quant a la rapidité, je ne peux pas vraiment dire si l'un ou l'autre est mieux,
je peux simplement dire que l'un marche et pas l'autre

[grabriel]

Merci pour l'info je pense que je vais me préparer à une éventuelle migration, j'attends de rencontrer des problèmes. Je suis abonné à la mailing de hsqldb et j'ai pas vu de messages avec des problèmes de mémoire donc Wait and see!!!

Je me prépare comme même!!

[epsilon68]

ca m'a vraiment surpris ce "out of memory" !!!
la table avait ~40'000 enregistrements mais beaucoup de champs.
personne n'a eu le meme probleme ?

et du coup je suis avec H2 et ca marche
mais bon je vais aussi regarder derby ... on sait jamais :-/

[epsilon68]

aie aie aie
derby ca fait faire beaucoup beaucoup de changements :-((
et ca a l'air tellement ... rigide :-(

bof !

quelqu'un a de l'experience avec derby ?
derby vs H2 ?

[grabriel]

Salut,

Tu peux donner plus de détails sur ton utilisation pour ton problème :

ca m'a vraiment surpris ce "out of memory" !!!
la table avait ~40'000 enregistrements mais beaucoup de champs.
personne n'a eu le meme probleme ?

1 Ta base est en mémoire, en standalone dans des fichiers, en serveur, etc..?
2 Le programme qui utilise ta base (langage, OS (je ne sais pas si ca change grand chose) etc...)?
3 ton signe astrologique?
4 la version de ton HSQLDB (si ca se trouve c'est une erreur qui à été corrigé avec la dernière release)?

Bref du détail, si ca ne me sert pas, ca servira à quelqu'un d'autres... c'est peut-être un problème qui peut être corrigé par l'équipe de développement.

Je ne sais pas ce que tu as dans ta base mais est-ce que tu as dépassé les 8 GB?

a more powerful engine that supports data up to 8GB (source HSQLDB.org)

Je sais que c'est théorique et avec des tests labos mais je pense que 6Gb doit etre plus proche pour des cas plus générique.

J'aurai à gérer + de 40'000 enregistrements et je voudrais savoir si je vais être confronté au même problème.

MERCI pour tes infos.

[epsilon68]

... avec plaisir !!!

1. c'est une appli standalone qui utilise la db avec un fichier.
(pas de serveur quoi)
2. Java / Windows XP
3 Cancer
4 la derniere (1.8.0.7)

c'est une appli qui scanne des fichiers / folders
dans mon cas 44312 fichiers 5142 repertoires.

cela plantait apres le scan si je faisais update TT_FILE set F = null;

CREATE CACHED TABLE TT_FOLDER (
A VARCHAR(512) PRIMARY KEY,
B VARCHAR(512),
C VARCHAR(512) NULL,
D VARCHAR(512) NOT NULL,
E BIGINT NULL,
F BOOLEAN NULL,
G INTEGER NULL,
H VARCHAR(1000) NULL,
I BOOLEAN NULL,
J BOOLEAN NULL,
K BOOLEAN NULL,
L BOOLEAN NULL,
M BOOLEAN NULL,
FOREIGN KEY (B) REFERENCES TT_FOLDER(A) on delete cascade
);


CREATE CACHED TABLE TT_FILE (
A VARCHAR(512) PRIMARY KEY,
B VARCHAR(512),
C VARCHAR(512) NOT NULL,
D VARCHAR(512) NOT NULL,
E VARCHAR(50) NULL,
F VARCHAR(50) NULL,
G DATETIME NULL,
H BIGINT NULL,
I BIGINT NULL,
J VARCHAR(50) NULL,
K VARCHAR(50) NULL,
L BOOLEAN NULL,
M BOOLEAN NULL,
N BOOLEAN NULL,
O BIGINT NULL,
P BIGINT NULL,
Q varchar(512) NULL,
R varchar(512) NULL,
S DATETIME NULL,
T BOOLEAN NULL,
U varchar(512) NULL,
V varchar(512) NULL,
W varchar(512) NULL,
X varchar(2000) NULL,
Y varchar(2000) NULL,
Z BOOLEAN NULL,
AA INTEGER NULL,
AB BOOLEAN NULL,
AC BOOLEAN NULL,
AD BOOLEAN NULL,
AE BOOLEAN NULL,
AF BOOLEAN NULL,
AG BOOLEAN NULL,
AH BOOLEAN NULL,
AI BOOLEAN NULL,
FOREIGN KEY (B) REFERENCES TT_FOLDER(A)
);

[grabriel]

Merci pour ces précisions.

c'est une appli standalone qui utilise la db avec un fichier

Moi j'ai la meme utilisation par contre pour les tables :

Code :

CREATE CACHED TABLE ...

Moi j'utilise

Code :

1
2
CREATE TEXT TABLE TOTO...;
SET TABLE TOTO SOURCE "Data/toto;encoding=UTF-8;fs=\t";

Avec le 'set table xxx source "le fichier dans lequel seront stockés mes infos; l'encodage de mon fichier; et le séparateur de champ;"'.

Je crois que par défaut d'après les vagues souvenirs qu'il me reste de la seule lecture de la doc, que CREATE TABLE == CREATE CACHED TABLE et que par défaut les tables sont en mémoire.

Si t'as toute ta table en mémoire et qui fait 40'000 lignes et plein de colonnes c'est peut etre normal que t'ai un out-of memory (je supose, je fais juste le mec qui sais ).

Mais bon ca ne m'empêchera pas de faire des tests avec plus d'enregistrements pour voir la soliditée de la base.

[epsilon68]

justement CACHED veut dire que la table reste sur le disk et une partie seulement est en memoire.

si tu ne mets pas CACHED, la table est en memoire et elle se sauvegarde avec des insert dans le fichier script.

toi tu mappes un fichier CSV, mais je redoute beaucoup qu'elle devra tenir en memoire ... je n'en suis pas persuadé, c'est juste mon petit doigt

je continue de regarder du coté de Derby au cas ou ...
j'avance sur la pointe des pieds maintenant ...
en tous les cas le gros point positif de H2 c'est qu'elle est relativement souvent mis a jour, de nouvelles versions arrivent tout le temps... par contre Derby .. je n'en dirais pas autant....

[grabriel]

Pour info :

HSQLDB is one of the fastest database engines (see the graph at hsqldb.org).
but if it isn't fast enough try http://www.h2database.com/. which was created by the original author HSQL.

Source : HSQLdb user discussions

Moralitée H2 est plus rapide... au moins c'est ni le site officiel de H2, ni un commercial qui l'annonce donc confiance +1.

[epsilon68]

je suis 100% avec H2 maintenant.
super rapide, tres puissant, tres fiable, n'a jamais planté, genial quoi !

[epsilon68]

apres quelques recherches, ca pourrait etre mon probleme:

The number of rows also depends on the size of a row. Obviously, if you have very large xxxchar or xxxbinary values in your rows, only a small handful of rows may be possible. Also, the engine typically requires many times the size of the actual column values when processing SQL character sequences (e.g. parse and logging deal with things in string form and thus may do several intermediate conversions that may require many large intermediate buffers and strings).

Another factor is whether you are using CACHED or MEMORY tables. With MEMORY tables, all rows are in MEMORY, so you need more of it. With CACHED tables, the full data is on the file system and only a portion of it is in a memory cache. The max row count of the cache is fixed at startup and can be set quite low (about 1K rows). However, even then you can get OOME, as for instance if you try to cache 1K large rows, say 1MB each, as this would represent 1GB (more actually, do to certain in-memory representation overheads and index structure info).

Finally, HSQLDB does not yet support a disk-based scratch space for query processing, so even if your tables are all CACHED, queries with large results can cause OOME, since the result of each query is currently formed 100% in-memory. Although it's not being actively worked on at the moment, there are plans to eventually provide a disk-based scratch space to allow performing queries whose results (and intermediate operations, such as sorting and grouping) consume more than the available memory.