# hsqldb: performance, große tabellen und so



## Roar (17. Okt 2005)

hi,
bin grad dabei hsqldb bisschen zu vergewaltigen.
angeblich soll das ding ja daten von bis zu 8gb größe bearbeiten können.
hab einfach mal versuch 100000 zeilen in die db einzuschleusen, was auch recht hm... passabel.. in 2,5sek ging (ohne batch): "INSERT INTO test3 (id, field2, field3) VALUES (123, 456, \'hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo \')"

beim nächsten start fliegt er mir nur leider bei DriverManager.getConnection("jdbc:hsqldb:file:tests/test4", "sa", ""); raus wegen DriverManager.getConnection("jdbc:hsqldb:file:tests/test4", "sa", "");
hab jetz keinen bock der vm mehr ram zu geben, da tabellen ja auch noch doppelt so groß und größer werden können, ewig kann ich ja nich mehr speicher applien.

ginge das ohne weiteres wenn ich hsql als server starten würde? eher nich oder?  ???:L   

danke,
gruß


----------



## Bleiglanz (17. Okt 2005)

Problem könnte der bei HSQL verzögerte Commit sein

setz mal zwischendurch immer wieder mal ein commit() ab...


----------



## Roar (17. Okt 2005)

Bleiglanz hat gesagt.:
			
		

> Problem könnte der bei HSQL verzögerte Commit sein
> 
> setz mal zwischendurch immer wieder mal ein commit() ab...



hmja, mach ich. das is ja nich das problem. das problem ist, dass er mir beim erneuten starten der datenbank abschmiert weils ihm zuviele daten sind :S kann aber doch nich sein bei "nur" 100000 zeilen?


----------



## Bleiglanz (17. Okt 2005)

\'hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo hallo \')"

ist schon ein bissl lang, der String

wie gross ist denn die Datei auf deinem Rechner (die ganze DB liegt ja da irgendwo rum als ASCII-File..)?

wie genau fliegt er denn raus? d.h. was für eine Ex kommt denn beim nächsten hochfahren??


----------



## Roar (17. Okt 2005)

die datei wär normalerweise 26mb groß, hab sie aber mit 
stmt.execute("SET SCRIPTFORMAT COMPRESSED");
auf 270kb komprimiert gekriegt.
so schmeirt er ab:
java.lang.OutOfMemoryError: Java heap space
Exception in thread "main" java.sql.SQLException: out of memory
	at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
	at org.hsqldb.jdbc.jdbcStatement.fetchResult(Unknown Source)
	at org.hsqldb.jdbc.jdbcStatement.execute(Unknown Source)
seltsamerweise hier erst beim nächsten insert. hatte in der anderen test datenbank wohl noch 2 oder mehr tabellen mit 100000 zeilen, denn dort hängt er sich auch mit ner  java.sql.SQLException: General error: java.lang.OutOfMemoryError: Java heap space schon bei getContnection() auf


----------



## Bleiglanz (17. Okt 2005)

> Does HSQLDB store all data in memory. Doesn't memory run out as a result?
> 
> Only if you want to. By default, CREATE TABLE results in a memory table, as this is the best type for smaller tables. For larger tables, use CREATE CACHED TABLE and adjust the hsqldb.cache_scale to suite your memory use requirements (as little as 8MB or so). See the Deployment Issues section of the Guide. There is no simple rule and no imposition on the part of HSQLDB as maximum flexibility is allowed using only a couple of settings. A popular use of HSQLDB is for OLAP, ETL, and data mining applications where huge Java memory allocations are used to hold millions of rows of data in memory.


----------



## Roar (17. Okt 2005)

hmm jor cool, dange, nu schmierts beim zweiten mal zwar nicht mehr beim starten ab, aber 1. dauert das inserten und selecten länger als beim ersten mal. und 2. wenn ich beim zweiten starten nochmal ein select durchführe fliegt wieder ne java.sql.SQLException: out of memory, dann sind dann aber auch schon 200000 zeilen drin... :-/


----------



## Bleiglanz (17. Okt 2005)

irgendwas gibts da auch noch beim SELECT von wegen LIMIT und so, damit er die ganze Tabelle nicht gleich in den Speicher holt 

dass das Inserten länger dauert ist schon klar, er muss ja dann und wann "rausschreiben" auf die Platte...


----------



## Roar (17. Okt 2005)

hm jap, ein LIMIT 30 in den select und das geht zackig . und 100.000 zeilen werd ich wohl auch nich auf einmal einfügen 
dafür hab ich jetz (im vergleich) ziemlich große .data dateien :-/
naja passt schon, danke


----------



## Hsqldb (1. Dez 2005)

Hallo,

hätt da auch nochmal ne Frage und zwar was bedeutet bitte das hier:
stmt.execute("SET SCRIPTFORMAT COMPRESSED"); 

Danke


----------



## AlArenal (1. Dez 2005)

Wenn du weiterhin deine DB komprimiert benutzt, ist doch klar, dass du OutOfMemory-Exceptions bekommst, denn beim Start muss er das Ding doch beim Start entpacken und irgendwie im Speicher vorhalten um Daten auszulesen und zu ändern.  (sage das ohne Gewähr, weil ich nicht genau weiß wie tricky die das implementiert haben)

Wenn du ganz normal das Ding nicht mit ner RAM DB sondern cached laufen lässt, fackelt da auch nichts ab.


----------

