18. februar 2008 - 14:03Der er
14 kommentarer og 1 løsning
Bedste valg af database
Hejsa,
Jeg skal lave et program hvor jeg skal bruge en mindre database. Programmet skal skrives i Java, og man skal kunne connecte til databasen via JDBC. Jeg skal kunne installere programmet uden at skulle til at installere en eller anden database-server. Der er snak om en mindre database, som aller aller mex bliver 100 mb :)
Jeg har kigget lidt på Apache Derby, som ligger godt. I må meget gerne komme med argumenter om evt. performance osv.
Denne database er meget brugt, gratis, open source. Det er let at få hjælp, der er bred support, den er kendt af mange og derer masser af tilgængelige vejledninger. Du render ikke måd begrændsninger af nogen slags, den kan let konverteres til andre formater og let bringes til atspille samme med andre systemer fordi næsten alle laver deres systemer så MYSql kan bruges. Den kan næsten betragtes som standard
Det hedder en embedded database, når der ikke skal køre en separat database server. Det er det du vil ikke ?
En oplagt mulighed er HSQLDB. Rigtigt mange Java produkter shipper med den som default database. Det er også den som OpenOffice bruger.
Hvis du bruger Java 1.6, så kommer den med Derby under navnet "Java DB".
H2 og Hypersonic er henholdsvis en nyere udgave og en ældre database lavet af manden bag HSQLDB.
De fleste embedded database har nogle mangler som database betragtet, men alle de nævnte er dog brugbare.
Jeg jar testet performance på Derby og HSQLDB. Derby performer ikke super men acceptabelt - lige under flere meget kendte ikke-Java databaser. HSQLDB performer nærmest uhyggeligt godt i de små tests jeg har lavet. Jeg har dog en mistanke om at HSQLDB vil tabe pusten ved større datamængder (jeg har kun testet op til 100 MB).
FireBird JDBC (JayBird) kan også bruges i embedded mode. Man skal dog være påmærksom på at at den løsning kræver native libs, hvilket ikke altid passer sammen med en Java løsning.
Jo, det er helt klart en embedded database som jeg har brug for. Jeg var inde på hjemmesiden for Derby, hvor man kunne downloade en performance beskrivelse, som hele tiden gik på at hvis datamængden var for stor til at have i hukommelsen, så performede meget bedre end MySql.. Nu har jeg ikke sat mig videre ind i det endnu, for jeg synes det lyder lidt underligt.. Jeg har lige læst beskrivelsen af HSQLDB, som jo faktisk tegner helt fantastisk :) De skriver op til 8 gb, som skulle være mere end rigeligt, for det program jeg skal lave.. Det vigtigste er i hvert fald bare at den er embedded - altså så man ikke skal installere alt muligt på computeren i forbindelse med installation af mit program..
Lad os sige, at man valgte Microsoft Access.. Ville man så være nødt til at have Office pakken installeret på maskinen (eller access), eller er det nok bare at have access databasen og så en jdbc driver til den? For hvis ikke man skulle installere noget, så kunne access jo lige så godt være en embedded database :)
Et sidste spørgsmål, som alle da gerne må svare på..
Hvis du skulle bruge en embedded database til forholdsvis små datamængder (max 300mb), hvilken database ville du så bruge af HSQLDB og derby (og hvorfor)?
Tak for hjælpen arne. Jeg har et supplerende spørgsmål, som nok fortjener et point fra sig selv.. Det handler om sql.. Du kan lige svare, så får du point
Kritikken fra det IBM forum skyder dog lidt ved siden af.
#Atomic - transactions can be partially committed in hsqldb, "partially committed" is #not a term I thought I would ever see associated with a database. Certainly not in #the four database systems I worked on, or the five database companies I've spent the #last fifteen years at.
Termen "partially committed" findes ikke i min kopi af HSQLDB docs.
#Isolation - hsqldb only supports dirty read, thus transactions always see uncommitted #values from other transactions.
Den korrekte term at at HSQLDB kun supporterer transaction isolation level read uncommitted.
Det er klart dokumenteret i docs:
>>HSQLDB supports transactions at the READ_UNCOMMITTED level, also known as level 0 transaction isolation.
HSQLDB understøtter transaktioner men med et meget dårligt transaction isolation level.
Det er en meget god grund til ikke at bruge HSQLDB til en stor multi-user app.
Men lige netop for embedded database er det ikke et stort problem. Ofte er der slet ikke behov for transaction isolation, men ellers kan man emulere det ved at bruge synchronized i applikationen.
#The claimed transaction rates seen in various postings about hsqldb clearly indicate #that the log is not being forced to disk at commit time. Looking briefly at the #hsqldb documentation it seems the writes are forced to disk every 60 seconds by #default, you can lose a lot of transactions in 60 seconds!
Min kopi af HSQLDB docs:
>>SET WRITE_DELAY {{TRUE | FALSE} | <seconds> | <milliseconds> MILLIS >> >>The default is TRUE and indicates that the changes to the database that have been >>logged are synched to the file system once every 20 seconds. FALSE indicates there >>is no delay and at each commit a file synch operation is performed. Numeric values >>from 0 can also be specified for the synch delay. >> >>The purpose of this command is to control the amount of data loss in case of a total >>system crash. A delay of 1 second means at most the data written to disk during the >>last second before the crash is lost. All data written prior to this has been synced >>and should be recoverable >> >>This setting should be specified on the basis of the reliability of the hardware >>used for running the database engine, the type of disk system used, the possibility >>of power failure etc. Also the nature of the data stored should be considered. >> >>In general, when the system is very reliable, the setting can be left to the >>default. If it is not very reliable, or the data is critical a setting of 1 or 2 >>seconds would suffice. Only in the worst case scenario or with the most critical >>data should a setting of 0 or FALSE be specified as this will slow the engine down >>to the speed at which the file synch operation can be performed by the disk >>subsystem.
Man må sætte det som man nu føler sig mest tryg ved.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.