Suche "richtiges" Framework/Library

[GuestMan]

Hallo Profis, (;-))

also, um es kurz zu machen ich habe folgendes Szenario: Applikation (die mit Java laufen soll) die viele Daten darstellen soll und durchsuchen soll. D.h. ungefähr könnte man es sich als eine Bücherverwaltung vorstellen. Der Umfang wird so bis ca. 10.000 Objekte gehen. Der Speicheraufwand pro Objekt ist nicht so groß, aber bei 10.000 Elementen auch nicht zu vernachlässigen!

Nun, muss es ja durchsuchbar sein und wenigstens halbwegs performant funktionieren. Also bin ich folgende Schritte durchgegangen:

1. Schritt: DATENBANK ist das Zauberwort. Die verwaltet sehr performant die Daten und ist längst nicht auf 10.000 beschränkt. Doch leider sprengt es den Rahmen der Applikation. Weder direkter Zugriff auf MySql noch über eine Schnittstelle (PHP etc.) ist möglich, da es eine "Applikation auf dem Stick" seien soll.

2. Schritt: JAVADB. Ist einer Datenbank sehr ähnlich, funktioniert leider nicht so toll. D.h. die Create-Scripts sind nicht richtig kompatibel mit den normalen MySQL scripts ... wäre ja nicht so schlimm. Aber: es wird ja immer ein DB-Ordner angelegt. Und auf dem Stick geht das nicht so toll, weil die Applikation so funktionieren soll, dass man EINE Jar hat und EINE "DB-Datei".

3. Schritt: XML. Dies schien für mich der perfekte Ausweg, da ich mit XML eine Struktur reinbringen könnte und das Ganze in eine Datei schreiben könnte (Video-Dateien sind ja auch jenseits der 1 MB und können trotzdem ausgelesen werden). Doch leider eignet sich JDOM nicht für so große Dateien wie angestrebt. Doch kann ich ja nur JDOM benutzen, weil es ja auch die XML-Struktur modifizieren kann. Und das können die anderen XML-Frameworks in Java nicht (nach meinem Wissen). Außerdem: wie bekomme ich eine performante Suchfunktion hin?

Und nun bitte ich Euch Euren Senf dazu zu geben. Obwohl die XML-Lösung unangenehm ist (Performance, Größe/Auslesen) gefällt mir diese Lösung am besten. Leider habe ich hiervon am wenigsten Ahnung wie ich es umsetzen kann (Performante Suche???/auslesen großer XML dateien?).

Ich hoffe Ihr könnt mir ein Paar Tipps geben!
Gruß,
Max

P.S.: Auf Textdateien will ich vorerst noch nicht zurückgreifen ;-)

 

[homer65]

Es gibt auch noch andere minimalistische Datenbank Systeme. Vielleicht ist da was passendes für dich dabei.

 

[Gast2]

Ich würde eine Objekt Datenabnk mit DB4O benutzen. Das Datenbank file kannst du doch einmal initial anlegen und in das jar bundlen.

Ist mit Sicherheit um Welten schneller als XML.

Aber andererseits - 10k Objekte im Speicher zu haben und effizient durchsuchen sollte eigentlich kein Problem darstellen. Müsstest dir nur Gedanken machen über die Datenstruktur, Indexierung etc. Das würde dir eine Datenbank abnehmen.

 

[GuestMan]

Danke schon mal für die schnellen Antworten!

Ich habe unterdessen diese Seite gefunden: Open Source Database Engines in Java und mir mal einige solcher Datenbanken angeschaut. Leider benutzen alle dieses umständliche JDBC und die beiden die in Frage kämen sind schlecht dokumentiert, kostenpflichtig oder machen umständliche Sachen mit Dateien & Co.

Also habe ich mir nochmals einige Gedanken gemacht: eigentlich würde es ja genügen, wenn ich eine Klasse Buch schreibe und da alles rein packe, was das Buch an Attributen hat (=eben objektorientiert). Nun wenn man diese Objekte nun Serialisiert und in eine Datei speichert, dann habe ich doch praktisch schon meine eigene Datenbank. Nun wenn da nicht noch die Performanceprobleme bei der Suche wären.

Inzwischen habe ich mir mal "DB4O" angesehen. Ich kann bestimmen, wohin gespeichert wird. Ich kann Objekte speichern (so wie ich es oben beschrieben habe). Man kann Objekte durchsuchen und noch einige andere Features nutzen, die ich garnicht benötige. Auf den ersten Blick ist die Doku sehr gut! Scheint auf meinen Fall zu passen, oder? (Lizenz: GPL)

Kennt sich denn jemand mit der Performance aus (fassy)? Ist das kompatibel mit 10.000+ Elementen/Einträgen? Muss an der Heapgroße der VM rumgeschraubt werden?

Vielen Dank,
Max

P.S.: Die vorgeschlagene Lösung hört sich wesentlich sauberer an als XML/Text-Dateien!

 

[GuestMan]

Leider hatte ich etwas vergessen und musste in einem neuen "Post" antworten:

Ich muss ja dann die "db4o-7.12.145.14409-core-java5.jar" in mein Projekt einbinden (die weiteren Features benötige ich ja nicht). Mit 1,3 MB nicht gerade ein Leichtgewicht - aber man kann ja sowieso nichts daran ändern ...

Was ich noch fragen wollte: diese Datei ist nach folgendem Listing nur für JDK5&6:

db4o-7.12-core-java1.1.jar
will run with most Java JDKs that supply JDK 1.1.x functionality such as reflection and Exception handling. That includes many IBM J9 configurations, Symbian and Savaje.

db4o-7.12-core-java1.2.jar
is built for all Java JDKs between 1.2 and 1.4.

db4o-7.12-core-java5.jar
is built for Java JDK 5 and JDK 6

Wie schlimm ist das? Gibt es noch viele Leute, die Java 1-1.4 nutzen? Ist diese Datei auch mit Java 7 kompatibel (soll im Herbst kommen)?

 

[GuestMan]

Ich habe mal einen Performance-Test konstruiert. Er findet mit simplen URLs statt:

TEST 1 (DB-FILE: 27,6 MB)
=================================================
* 110009 links read in 645990311 ns (0.6459903 s)
* Database created in 1650542085 ns (1.650542 s)
* 110009 objects created in 13534677412 ns (13.534677 s)
* 110009 objects found in db in 7736510265 ns (7.7365103 s)
* Search: 9 objects found in db in 12934354466 ns (12.934355 s)

TEST 2 (DB-FILE: 31,4 MB)
=================================================
* 20000 links read in 153616345 ns (0.15361635 s)
* Database created in 1168834773 ns (1.1688348 s)
* 20000 objects created in 4921763934 ns (4.921764 s)
* 130009 objects found in db in 8859466247 ns (8.859467 s)
* Search: 11 objects found in db in 15016964030 ns (15.016964 s)

Die Suchzeit ist ja vertretbar ... Aber ob es sich auch mit "großen" Objekten (die Link-Objekte hatten alle nur ein Attribut; für mein Szenario reicht das leider nicht aus ...) verhält ...

 

[slawaweis]

also, um es kurz zu machen ich habe folgendes Szenario: Applikation (die mit Java laufen soll) die viele Daten darstellen soll und durchsuchen soll. D.h. ungefähr könnte man es sich als eine Bücherverwaltung vorstellen. Der Umfang wird so bis ca. 10.000 Objekte gehen. Der Speicheraufwand pro Objekt ist nicht so groß, aber bei 10.000 Elementen auch nicht zu vernachlässigen!

ich habe mir erst Gestern einen Algorithmus geschrieben, der geschätzte 300.000 Dateien auf der Festplatte anhand deren Metadaten (Dateiname, Länge) verarbeitete. Dabei wurden die 300.000 File-Objekte auf einmal im Speicher gehalten. Ich hatte keine Speicherprobleme damit und der Algorithmus brauchte nur 61 Sekunden für den finalen Durchlauf.

So können solche Sachen ruhig mit puren Java verarbeiten werden. Ich würde die XML-Lösung bevorzugen, außer es werden echte Datenbankfunktionen benötigt, wie JOINs über ganze Tabellen. Wenn man die XML-Datei auch noch in eine ZIP-Datei packt, reduziert das die Zugriffe auf die Festplatte, was besondern bei einem Speicherstick beschleunigend wirkt. Wenn man mit Speichersticks arbeitet, sollte man besonders aufpassen, dass die Datenbank alle Daten auf einmal lädt und im RAM verarbeitet, sonst hat man unnötige Flaschenhälse im System.

Slawa

 

[Wildcard]

Wie wäre es mit JCR? Zum Beispiel die Jackrabbit Implementierung:
Welcome to Apache Jackrabbit
Durchsuchen sollte sehr flott sein da Lucene im Hintergrund einen Index erstellt. Queries funktionieren wahlweise über XPath oder SQL und das Deployment Modell ist sehr flexibel und transparent für die Applikation (Filesystem, In-Memory, Remote,...)

 

[Empire Phoenix]

nur so am rande, man könnte auch einfach einen portablen mysql server zupacken, der per script gestartet wird, und danach das java programm, das auf lokalhost connected.

 

[Wildcard]

nur so am rande, man könnte auch einfach einen portablen mysql server zupacken, der per script gestartet wird, und danach das java programm, das auf lokalhost connected.

Wäre eine H2 nicht die geschicktere Variante?

 

[GuestMan]

@Portabler MySql-Server
Ist keine 100% pure Java Lösung! Außerdem: mehr Dateien, größere Dateigröße und ein viel Größeres Feld für Fehler. Man müsste ja dann für Mac, Linux und Windows MySql-Server dazupacken ...

Ich werde mich wohl für eine "Java Object Database" entscheiden - wenn auch zähneknirschend. Folgende habe ich mir ausgesucht (Rangordnung):

1. "neodatis-odb-1.9.24.679" (http://www.neodatis.org/): Geringe Dateigröße (Jar ist nur ~700 KB groß), alle notwendigen Funktionen*, OpenSource (GPL/LGPL).
2. "JODB_Mini_Bin_3.0.0_rc3" (http://www.java-objects-database.com/): Sehr geringe Dateigröße (300 KB), alle notwendigen Funktionen aber keine Dokumentation, Projekt inaktiv?, (LGPL/GPL).
3. "db4o-7.12-java" (http://db4o.com/): Große Jar-Datei, viele Funktionen, bei (evtl.) komerzieller Verwendung Erwerbung nötig.

@slawaweis
Da liegt auch mein Problem: ich möchte z.B. die "Datenbankdatei" in einem ZIP verpacken mit einer Config für den aktuellen Benutzer. Aber man kann bei allen drei Lösungen nur einen String angeben als Dateipfad, von dem die Datenbankdatei gelesen werden soll (man könnte natürlich die Datenbankdatei vorher extrahieren). Gerade bei meinem Favoriten oben wäre das der krönende Abschluss.

Und dies ist der Grund, warum ich überlege, ob ich die Verwaltung nicht mit XML-Dateien selber mache. Aber auf der anderen Seite muss ich oben nur die Datei angeben und kann dan munter auslesen und updaten und suchen ...

Aber vielleicht hat ja jemand von Euch noch ne Idee, wie ich neodatis bei bringe einen Dateistream anzunehmen. ;-)

Gruß,
Max

 

[kay73]

Wieso nicht HSQLDB? Bei uns in allen Unit-Test Standard.

 

[Wildcard]

@kay73
Derby, HSQL und H2 sind alle drei sinnvoll für diesen Anwendungsfall. HSQL und H2 sind feature-reicher als Derby und H2 ist der gedankliche Nachfolger von HSQL, daher würde ich wenn es eine pure java DB sein soll zu H2 tendieren (wie gesagt, die anderen funktionieren natürlich auch).

@GuestMan
Eine Object Database finde ich eine sehr ungewöhnliche Wahl. Was bringt dich zu dieser Entscheidung?
Meine Meinung:
Auf den trendy No-SQL Zug aufspringen da du damit die Vorteile einer DB mit einfacher API verbinden kannst. Für die konkreten Requirements halte ich wie gesagte Apache Jackrabbit für die beste und einfachste Wahl.

Wenn es traditioneller sein soll, dann eine der genannten DB Lösungen

 

[GuestMan]

Also bis gestern kannte ich keine Object Databases. Und mir hat die Idee die hinter einer solchen Datenbank steht sehr gut gefallen, denn es minimiert für mich den Programmieraufwand (ich kann einfach Objekte reinpacken/ändern/auslesen/filtern und muss kein SQL-Statement schreiben) und erhält die logische OOP-Struktur (ich arbeite direkt mit Objekten und muss nicht noch die SQL rückgaben auslesen und dann in ein Objekt packen).

Doch diese Lösung - mittels ODB - ist meiner Meinung nach nur sinnvoll einsetzbar in "lokalen Applikationen" und wenn man nicht auf eine tabellenartige Struktur (ERM) angewiesen ist (d.h. auch keine JOINS etc. benötigt). Und da ich ja nur Objekte reinpacken will und die durchsuchen möchte finde ich, dass es eigentlich sehr gut passt (warum sollte ich noch viel Aufwand um ein Tabellenmodell betreiben und dann noch mit SQL-Statements rumhantieren?). Außerdem: man muss ja mal mit allem möglichem gearbeitet haben ;-)

Gruß,
Max

 

[tuxedo]

Mein Vorschlag:

H2 in Kombination mit EclipseLink.

Vorteile:
* Die DB passt in eine File, der Java-Kram dann in die JAR. Ergo: 2 Files
* Die DB liefert die die ganzen Vorteile von SQL
* Dank EclipseLink musst du dich aber nicht mit SQL rumärgern, sondern kannst mit Objekten arbeiten
* Du kannst die DB und die Daten auch extern mit Tools öffnen und lesen da H2 ja JDBC kompatibel ist
* Ist alles komplett in plain java ...

- Alex