Jau, die schöne weite Welt lädt in letzter Zeit immer mehr ein 'neue' Erfindungen auszutesten und zu implementieren. Ich persönlich spiel im Moment mit dem Gedanken CouchDB und Cassandra ein bisschen anzutesten und herauszufordern und würd gern wissen ob hier jemand schon Erfahrung gesammelt hat.
Cheers, alen
Original von Kampfhoernchen
Objektorientierte DBs haben einen entscheidenden Nachteil: Sie sind LANGSAM.
Quellen?
Dass sie langsamer sind, wenn man nicht die Datenstruktur entlang geht (sprich die direkten Verweise), sondern nach Dingen wirklich sucht, kann ich nachvollziehen. Aber pauschal?
http://www.db4o.com/about/productinformation/benchmarks/
Demnach: Je komplexer die Datenstruktur desto besser sind objektorientierte Lösungen... und BGs können schon sehr schnell sehr komplex werden :-)
Original von Kampfhoernchen
Objektorientierte DBs haben einen entscheidenden Nachteil: Sie sind LANGSAM. Und mit mehr Daten werden sie expotenziell langsamer. Andere Systeme hab ich noch nicht ausprobiert, bin auch aber auch Erfahrungsberichte gespannt.
CouchDB ist doch dokument-orientiert und nicht oo, oder?
Zur Geschwindigkeit kann ich auch noch nichts sagen..
Alleine die Tatsache, wie eine Datenbank (bzw. der Planer) ein Objekt-Query ausführen kann, sollte einem realistisch klar werden lassen, das schon aus logischen Gründen komplexe Datensätze - zu denen Objekte automatisch auch dazugehören - per Definition langsamer sind. Hey, man hat schon vor Jahren die geile Idee mit Objekten gehabt.. und sie in der Realität verworfen, weil relationale Datenbanken - und auch in Verbindung mir OR-Wrappern/-Managern - in Punkten Geschwindigkeit/Performanz/Durchsatz/Speicher (Skalierbarkeit) nicht zu schlagen sind.
Selbst einfache XML-Fragmente lassen sich nicht ohne weiteres abfragen und umformen, obwohl Datenbanken seit Jahren entsprechende Typen (bspw. XMLTYPE) verstehen und auch Techniken mit XPath (neuerdings auch XQuery) zur Verfügung stehen. Aber einen Index auf Spalten mit XML-Dokumenten aufzusetzen, zu pflegen (DML) und effektiv zu verwenden, sind Techniken, die erst im kommen sind. Dabei muss man relativ schnell die Semantik der Daten beachten, etwa um die Erstellung von komplexen Indizes, im Vergleich zu einem einfachen Spaltenindex bei relationalen Systemen.
Derzeit sehe ich noch keinen großen Vorteil objektorientierter DBMS in den meisten Anwendungen - und auch Browsergames haben selten derartig komplexe Daten (wir reden ja nicht über Assoziationen, also Relationen). Ausnahmen gibt es, und dort nur zu Lasten der Performance. Wahrscheinlich in diesen Ausnahmen auch nicht so wichtig, weil man wohl auf Semantik setzt.
Man sollte vielleicht, bevor man die Keule gegen objektorientierte Datenbanken auspackt, nochmal den Ausgangspost lesen und feststellen, dass es hier gar nicht um objektorientierte Datenbanken geht. CouchDB ist dokumentenorientiert und Cassandra ein Key/Value-Store. Man könnte vielleicht auch noch BerkeleyDB mit aufnehmen.
Produkive Erfahrungen habe ich mit den Systemen aber auch nicht. Hatte mal mit BerkeleyDB rumgespielt und fand es performancetechnisch durchaus eine interessante Option. Der Nachteil an solchen Systemen ist für mich, dass sie oft dazu tendieren eine Blackbox für die Anwendungsdaten zu wenden, d.h. man kann nur sinnvoll über die Anwendung selbst darauf zugreifen. Eine relationale (SQL) Datenbank kann man problemlos auswerten ohne dafür aufwändig neuen Code zu schreiben. Gerade bei einem Browserspiel wo die Spieler häufig Probleme mit ihren Spielständen melden ist es unschätzbar wertvoll, wenn man einfach mit ein paar SQL-Queries Auswertungen und Recherchen fahren kann.
In der Tat - aber die Gründe für die zu Grunde liegende Frage der Datensemantik ist davon unberührt. Und auch meine Ausführungen bzgl. effizienter Algorithmen für Indizes und DML-Statements.
Original von knalli
in Punkten Geschwindigkeit/Performanz/Durchsatz/Speicher (Skalierbarkeit) nicht zu schlagen sind.
Ein Wunder, dass man nicht mehr in Assembler programmiert...
Performance ist nicht alles & deshalb denke ich, dass die alternativen DB-Systeme durchaus ihre Berechtigung haben.
Original von knalli
weil relationale Datenbanken - und auch in Verbindung mir OR-Wrappern/-Managern - ... nicht zu schlagen sind.
Hast du dazu Benchmarks?
Ich kenne nur http://www.polepos.org/. Dort schneidet Hibernate/MySQL selbst bei einer flachen Datenstruktur schlechter ab als die OO-DB (während nur MySql natürlich die OO-DB schlägt).
Ich lasse mich aber gerne auch überzeugen (mit entsprechenden Quellen natürlich)!
(sry, dass ich gerade wieder die OOs ins Spiel bringe...aber da wir gerade am Überlegen sind OO-Db einzusetzen, ist das ein interessantes Thema für mich)
Eigene Benchmarks nicht, aber die Kenntnis über das Wissen, welches sich in der Datenbankwelt in den letzten Jahren/-zehnten dazu angesammelt hat.
Selbstverständlich ist ein OR-Wrapper langsam, wenn man a) ihn einfach laufen lässt und/oder er b) schlecht designed wurde. Die zusätzliche Schicht ist per Definition (zusätzlicher Layer) ein Overhead, und die Aufgabe des Entwicklers kann nur sein, diesen entsprechend zu minimieren. Welches durch eine geeignete Konfiguration und begrenzt durch die Möglichkeiten des ORM zu tun ist. Datenbanken sind halt kein Thema, die einfach "out-of-the-box" funktionieren (doch, funktionieren schon, nur selten efffizient genug).
Es gibt Objekttypen in Systemen wie Oracle schon seit Jahren, nur eingesetzt werden sie selten. Nur, weil alle Entwickler keine Lust haben? Wohl eher nicht (Praxis).
Bezgl. Performance/Indizes: Beispiel, welches ich auf der BTW09 in Münster mitgenommen habe: XML-Fragmente in einer Logtabelle. Das ist natürlich ideal, weil man so die Log-Ergebnisse der verschiedenen Anwendungen in eine Tabelle ablegen kann (Gesamtgröße im 9stelligen Bereich). Problem 1: Wie filtert man effizient? Die Abfragetechnik ist schnell gewählt (XPath/XQuery), aber für das DBMS bedeutet dies ein Angucken jeden Datensatzes. Ein regulärer Index kann nicht verwendet werden, da a) keine Spalte wie in einer Relation verwendet werden und b) jeder Datensatz auch anders aussehen kann (gleiche Struktur der XML-Dokumente ist nicht erforderlich). Die Quintessenz ist also, dass man jeden Index selber (bspw. über einen XPath, count(accounts/account/name)) selber definieren muss. Das zu lösende (bzw. vorgestellte) Problem ist aber die Tatsache, das der Index (der auch komplizierter sein kann) auch nach einem DML-Statement konsistent sein muss. Und es ist ja klar, das ein komplettes Neuberechnen aller Indizes über alle Dokumente (Millionen) nicht in Frage kommt. Bei normalen relationalen Systemen ist ein solcher Index u.U. durch mathematische Funktionen zu errechnen (count und Existenzen/Null ist total easy, bei Durchschnitten wird es natürlich schwieriger).
Wenn man sich der Problematik erst mal klar wird, dann wird vllt auch verständlich, das rein objekteorientierte/basierte Datenbanksysteme nicht genauso funktionieren können wie eben die relationalen.
Den Einwand mit ORM habe ich deswegen gebracht, weil es für mich kein Grund ist, nur wegen einer OO-Anwendung auch eine "OO"-Datenbank zu verwenden. Entsprechende Zwischenschichten lösen das Problem idR wesentlich besser, zumal man auch deutlich flexibler in der Datenbanksystemwahl ist. Ich muss gestehen, ich weiß nicht um den Umstand von Objekten in MySQL oder Postgres, aber es funktioniert sicher komplett anders als in Oracle oder gar DB2. Bei einem ORM - wie etwa der Quasi-Standard Hibernate - ist das erstmal völlig egal, erst bei der Performance-Optimierung kann das eine Rolle spielen.