Wer kann mir eine Datenbank empfehlen

[Tensor]

Hi und Hallo,
da ich selbst sehr wenig Erfahrung mit Datenbanken habe, nun aber vor dem Problem stehe, immer grössere Datenmengen sicher speichern zu müssen, würde ich mich über eine Expertenempfehlung wirklich freuen.

Die Aufgabe ist im Grunde recht simpel:

• ein webclient liefert Daten an den Server, dieser speichert und liefert auf Anfrage wieder aus.
  
• die Daten sind baumartig strukturiert, auf der untersten Ebene gibt es eine Hashtable in diese können beliebig weitere Hastables oder Arrays eingetragen sein. Jedes Array oder jede Hashtable kann weitere Hashtables oder Arrays enthalten. Die Schachteltiefe ist nicht begrenzt und am Ende sind die "Blätter" des Datenbaumes stets integer, float, String oder boolean.
  
• Zugriffe auf die Daten erfolgen über Pfade. Will etwa ein webclient seine registry laden lautet der Befehl an den server: "load("root;customer;5;webapps;4;dummyuser;system;registry"); woraufhin der Server die entsprechende Hashtable serialisiert und sendet. Und umgekehrt will der webclient einen Eintrag in der Registry aktualisieren lautet der Befehl an den Server etwa: save("root;dummycustomer;....;registry;app_1;default;23", serializedObject);

Wenn jemand glaubt das richtige Datenbanksystem für diese Aufgabe zu kennen würde ich mich wirklich über einen Tipp sehr freuen.

Danke im Voraus
Gernodt

 

[Sekundentakt]

Hi,

ohne das ich mich näher damit beschäftigt hätte, aber dein dritter Punkt klingt nach einem Fall, wo XML-Datenbanken ganz nützlich sein könnten. Schau Dir konkret mal Berkeley DB an (das ist die einzige XML-Datenbank, die ich kenne - wird von Oracle als Open Source zur Verfügung gestellt) und beließ Dich zusätzlich noch über die Skalierbarkeit - ich glaube aber, die sollte kein Problem darstellen.

Hast Du keine Möglichkeit das Ganze zu normalisieren, sodass RDBMS nicht gänzlich ausscheiden?

Gruß

 

[Gast2]

Ja, bei der Struktur wirst du mit relationalen DBs keine Freude haben. Da bleiben eigentlich dann nur Alternativen wie Berkeley, xindice, db4o, versant und ähnliches mit all ihren Vor- wie Nachteilen.

 

[gman]

Hi,

nachdem die relationalen DBs nach einhelliger Meinung schon ausgeschieden sind, guck dir
vielleicht mal deren aktuell heiß gehandelten "Nachfolger" an.

Stichworte: NoSQL, insbesondere GraphDB (wenn ich ehrlich bin hab ich deinen Anwendungs
fall nicht so ganz verstanden aber letzteres klingt ähnlich abgefahren wie deine
Aufgabenbeschreibung )

 

[Tensor]

Erst mal Danke für Euere Antworten,

• RDBMS scheidet tatsächlich aus - obwohl sich die Datenstruktur tatsächlich abbilden liesse, nur die Sache wird derart verzwickt, und meine Fähigkeiten sind hier viel zu beschränkt
• db4o interessiert mich, Datenbank und Struktur passen wohl ganz gut zusammen. Ich sehe nur ein grosses Problem: Datenbanken speichern viele kleinere Objekte, hier gibts nur ein einziges und das ist wahrhaft gigantisch.

Meine Frage also an diejenigen mit db4o Erfahrung: kann db4o ein einzges Objekt verwalten, das im Prinzip mehrere hundert GB gross werden kann und dann aus mehreren milliarden Subobjekten besteht???

Alternativ sehe ich die Möglichkeit einer doppelt verlinkten Liste. Jedes Objekt kennt seinen parent, die childs, seinen Typ und den Datenwert - falls es Daten trägt. Zugriffe erfolgen, indem man sich von Objekt zu Objekt hangelt. Aber auch da die Frage: könnte man mit db4o so etwas erledigen??

LG

 

[Gast2]

Meine Frage also an diejenigen mit db4o Erfahrung: kann db4o ein einzges Objekt verwalten, das im Prinzip mehrere hundert GB gross werden kann und dann aus mehreren milliarden Subobjekten besteht???

Alternativ sehe ich die Möglichkeit einer doppelt verlinkten Liste. Jedes Objekt kennt seinen parent, die childs, seinen Typ und den Datenwert - falls es Daten trägt. Zugriffe erfolgen, indem man sich von Objekt zu Objekt hangelt. Aber auch da die Frage: könnte man mit db4o so etwas erledigen??

LG

Anfürsich verwalten schon. Aber es macht keinen sinn da du nicht weiter drin suchen kannst. Dein zweiter Vorschlag wäre da schon besser. Du queriest ja in db40 nach einem Objekt. Wenn du das dann rausbekommst und dich über die parent und childs weiter navigieren kannst ist das möglich.

Ich würd dann aber auch die Objekte "weich" verlinken über eine ID und nicht mit einer linkedList die refernzen auf Objekte hällt.

Also Sprich in dem Object Ids der parent und childs halten und mir die childs dann aus db40 per query rausholen.

 

[homer65]

Sowas läßt sich sehr wohl mit relationalen Datenbanken realisieren.
Mit anderen Datenbanksystemen kenne ich mich leider nicht aus.
Anmerken möchte ich jedoch, das es, wenn die Datenmenge größerer wird, keinen Sinn machte alles als ein Objekt abspeichern, das man nur als ganzes lesen und verändern kann. Wichtig ist, das auslesen und verändern von Teilbereichen ohne großen Aufwand geht.

 

[mvitz]

Anfürsich verwalten schon. Aber es macht keinen sinn da du nicht weiter drin suchen kannst. Dein zweiter Vorschlag wäre da schon besser. Du queriest ja in db40 nach einem Objekt. Wenn du das dann rausbekommst und dich über die parent und childs weiter navigieren kannst ist das möglich.

Ich würd dann aber auch die Objekte "weich" verlinken über eine ID und nicht mit einer linkedList die refernzen auf Objekte hällt.

Also Sprich in dem Object Ids der parent und childs halten und mir die childs dann aus db40 per query rausholen.

Das widerspricht dann aber dem Konzept einer Objektorientierten Datenbank, hier sollen ja auch solche Objekte direkt mit gespeichert werden. Idealerweise haben diese Objekte eben auch eine eindeutige Eigenschaft, über die man diese dann zusätzlich laden/suchen/finden kann. So kann man sich direkt ein Root-Element holen und dann machen was man möchte, oder über die Datenbank direkt ein Kind-Element nach einem bestimmten Kriterium finden.

 

[Gast2]

So kann man sich direkt ein Root-Element holen und dann machen was man möchte, oder über die Datenbank direkt ein Kind-Element nach einem bestimmten Kriterium finden.

Klar geht das - du musst halt nur die Fetchtiefe wissen/angeben in wie weit du Referenzen auflöst...

 

[Sekundentakt]

Sowas läßt sich sehr wohl mit relationalen Datenbanken realisieren.
Mit anderen Datenbanksystemen kenne ich mich leider nicht aus.
Anmerken möchte ich jedoch, das es, wenn die Datenmenge größerer wird, keinen Sinn machte alles als ein Objekt abspeichern, das man nur als ganzes lesen und verändern kann. Wichtig ist, das auslesen und verändern von Teilbereichen ohne großen Aufwand geht.

Das sehe ich genau so.
Könntest Du vielleicht mehr zu Deinem eigentlichen Use-case sagen?
Objekte mit mehreren Gigabyte an notwendigem Speicher - das klingt irgendwie so, als ob man hier noch optimieren könnte.

Fragen, die mir aufkamen, waren: Was befindet sich in den Objekten, dass sie so groß werden können? Eingelesene Dateien? Oder was bläht die so auf?

Die nächste Frage ist: Wonach suchst Du in der Datenbank? Oder anders: Was wären typische Anfrageformen? Suchst Du immer nur ein Objekt X oder suchst Du alle Objekte, mit der EigenschaftY - hier könnte man ggf. noch etwas mehr in Erfahrung bringen.

db4o interessiert mich, Datenbank und Struktur passen wohl ganz gut zusammen. Ich sehe nur ein grosses Problem: Datenbanken speichern viele kleinere Objekte, hier gibts nur ein einziges und das ist wahrhaft gigantisch.

Das klingt irgendwie so, als ob Du die Datenbank als zentrale Speicherstelle verwenden möchtest, um möglichst einfach wieder an die Objekte heranzukommen.
Bei Daten wie z.B. Anschriften, Adressen etc. macht sowas Sinn, aber z.B. Dateien (Bilder, Videos, PDFs,...) werden nur per Referenz in der DB gehalten (z.B. Speicherort/Parameter für Programm, dass den Speicherort kennt oder anhand der Parameter auflösen kann).
Grund hierfür ist, dass ein "normales" Filesystem eher mit solchen Daten umgehen kann als eine Datenbank.

Das sind nur ein paar Gedanken hierzu.

Fakt ist aber, dass Du - falls möglich - mehr über Dein Vorhaben erläutern solltest, damit wir Dir hier konstruktiv weiterhelfen können.

Beste Grüße

 

[Tensor]

Wie schon eingangs erwähnt sind die Daten im Prinzip nicht tabellen- sondern baumartig.
Der Hintergrund ist der: einerseits habe ich ein System - programmiert in AS3 - das eine Art Betriebssystem innerhalb des Browsers etabliert ... mit allem was man von einem
System halt so erwarten kann - inclusive eines eigenen Interpreters. Andererseits die zugehörige serverseitige Software - JAVA - um die Clients zu kontrollieren und mit Daten zu versorgen bzw. von den Clients versorgt zu werden.

Es ist also nicht immer vorhersehbar welche Datenstrukturen in welchem Zusammenhang anfallen oder künftig anfallen könnten. Das Ganze ähnelt eher der Filestruktur eines Betriebssystems.
Der Datenbaum besteht aus Hashtables und Arrays, die beliebig geschachtelt sind und Zugriffe erfolgen über Pfade.

Die Daten selbst sind stets Strings, ints, floats oder booleans (z.B. sind Bilddaten in der Tat nicht direkt in der Struktur enthalten sondern nur der Verweis).
Die typischen Datenbankanfragen wie: gib mir alle Benutzer, deren Postleitzahl mit "3" beginnt und deren Vorname "Hans" ist, gibt es nicht.

Tatsächlich lauten die Anfragen etwa: gib mir das, was unter dem Pfad: "root;system;filesystem;desktop;folder_1" abgespeichert ist - was immer das auch sein mag.
Andererseits lauten Kommandos an den Server etwa: lösche "root;system;filesystem;desktop;folder_1;7". Was das Arrayelement "7" im folder_1 entfernen soll -
und dabei natürlich alle nachfolgenden Arrayelemente oberhalb von 7 umnumerieren muss.
In Hashtables können neue keys angelegt und hierunter neue Kombinationen von Hashtables und Array abgelegt werden.
Hashtablekeys können gelöscht, neue Arrayelemente angefügt oder an beliebiger Stelle eingefügt werden etc. etc.

Lauter Aufgaben, die nicht typisch für eine Datenbank - sondern eher für ein Filesystem - sind.???:L

 

[ice-breaker]

Tensor, irgendwie ist der Großteil deines Postings fachlich einfach komplett falsch.

Datenbanken als auch Betriebssysteme - du meinst wohl Dateisysteme - setzen auf Bäume: B-Bäume, (B+)-Bäume und weitere.

Und natürlich gibt es diese Kriterien-Anfragen, diese werden auf Bäumen ausgeführt, die Index-Daten. Wurden dort passende Datensätze gefunden, werde diese aus einer großen Datei von der Festplatte geladen anhand des Offsets, den der Index angegeben hat.

Also mit Hashtables und Arrays wird da rein gar nichts gemacht, es seidenn man würde in einer Datenbank einen Hash-Index anlegen, aber das ist eine andere Geschichte.

 

[Sekundentakt]

Dinge die mir hier auf Anhieb einfallen, sind Nested Sets.
Schau Dir dazu mal den Artikel auf phpperformance.de an:Nested Sets
Nimm Dir dafür aber Zeit, sonst verstehst Du die Theorie dahinter nicht.
Falls Du dich fragst, wie das SQL-Statement dort stimmen kann, besorg Dir am besten Zettel und Stift und rechne nach - als ich das damals tat, hat's auch Klick gemacht ;-).

Nested Sets sind hervorragend dazu geeignet, baumartige Strukturen in nur wenigen Spalten abzubilden.
Lediglich das verändern der Struktur (z.B. den ersten Ast von X auf einmal zum ersten Ast von Y zu machen etc.) ist etwas aufwändiger. Hier müsstest Du dich etwas näher belesen.

Btw.: Willst Du auf ein echtes Dateisystem zugreifen und brauchst dafür die entsprechenden Pfade?
Soweit ich weiß, gibt es auch virtuelle Dateisysteme. Vielleicht helfen die Dir ja auch weiter.

 

[Gelöschtes Mitglied 5909]

Auch wenn ich das noch nicht benutzt habe, denke ich dass dir Welcome to Apache Jackrabbit helfen könnte.

Ist übrigens eine JSR implementierung

Schau da mal nach: First Hops

import javax.jcr.Repository;
import javax.jcr.Session;
import javax.jcr.SimpleCredentials;
import javax.jcr.Node;
import org.apache.jackrabbit.core.TransientRepository;

/**
 * Second hop example. Stores, retrieves, and removes example content.
 */
public class SecondHop {

    /**
     * The main entry point of the example application.
     *
     * @param args command line arguments (ignored)
     * @throws Exception if an error occurs
     */
    public static void main(String[] args) throws Exception {
        Repository repository = new TransientRepository();
        Session session = repository.login(
                new SimpleCredentials("username", "password".toCharArray()));
        try {
            Node root = session.getRootNode();

            // Store content
            Node hello = root.addNode("hello");
            Node world = hello.addNode("world");
            world.setProperty("message", "Hello, World!");
            session.save();

            // Retrieve content
            Node node = root.getNode("hello/world");
            System.out.println(node.getPath());
            System.out.println(node.getProperty("message").getString());

            // Remove content
            root.getNode("hello").remove();
            session.save();
        } finally {
            session.logout();
        }
    }

}