Totgeburt ganz sicher nicht! Es steckt eine Firma dahinter die auch kommerziellen Support bietet:
http://www.10gen.com/products/mongodb
Warum eine Alternative?
SQL-DBs gibt es viele. Ich selbst habe Erfahrungen mit MS SQL, Postgres und MySQL. Ich bin, bedingt durch die Rahmenbedingungen hier, immer wieder an das Problem das mir SQL-Tabellen zu statisch sind gestoßen. Dafür habe ich es hier mit Produkten zu tun deren Eigenschaften/Attribute sich über die Jahre deutlich verändern. Dafür gibt es bekannte Kompensationsmittel im DB-Entwurf oder man speichert/liest eben XML-Repräsentanzen. Das geht alles, macht aber wenig glücklich.
Nun gibt es NoSQL (sprich: Not only SQL) Datenbanken und da deren Hype immer mehr zu nimmt, beschloß ich mir die mal anzusehen. Wenn man das Feld der Anbieter filtert stellt man fest das es sehr große und robuste Lösungen gibt wie Hadop, die aber nur für Google oder die NSA wirklich nützlich sind. Es gibt reine Datensammler wie CouchDB, die tolle Eigenschaften haben aber bei individuellen Abfragen einfach umständlich sind. Und es gibt eben mongodb. Die kommen mit den Eigenschaften einer NoSQL DB daher, bringen all deren Vorteile mit und doch verhält sich mongodb sehr ähnlich zu einer relationalen SQL DB. Daher meine Gehversuche damit und meine Begeisterung hält an.
Ein paar Fakten:
- mongodb kennt einzelne Datenbanken, wie show databases und use db bei mysql, gibt es die pendants auch hier.
- mongodb kennt ein Pendant zu Tabellen, sie heißen collections und werden wie Tabellen verwendet (CouchDb kennt keine solche Struktur, alle Daten landen direkt in der DB)
- Collections sind Namensräume, keine Strukturen wie in SQL! In db.kunden kann ich alles über Kunden speichern, die Struktur der einzelnen Dokumente ist völlig egal! in db.aufträge würde man dann deren Aufträge ablegen etc.
- In den Collections werden Dokumente gespeichert. Das sind jede Art von JSON-Objekten. Somit lassen sich u.A. jede Art von Javascript-Objekten direkt in Collections speichern, aber nat. auch Objekte anderer Sprachen wie PHP,Python oder Ruby
- Die mongodb-shell ist ein vollwertiger Javascript-Interpreter und erlaubt das verwalten der DB mittels Javascript
- fragt man ein Attribut ab das nicht in allen Dokumenten enthalten ist, so wird es für diese Dokumente als NULL angenommen.
- Dokumente enthalten all die Datentypen die Javascript auch kennt, inklusive Date und nat auch inklusive Javascript-Code selbst.
- Natürlich dürfen Dokumente (Objekte in der Anwendung) wieder Dokumente (also Unterobjekte9 enthalten und selbstredend kann man bei Abfragen auch darin suchen. Gleiches gilt für Arrays von Objekten ...
- Auch bei Abfragen kann in dem was in SQL die WHERE-Clause ist statt Abfragebedingungen nativer Javascript-Code genutzt werden.
- Jedes Dokument darf bis zu 16MB groß sein, die Zahl der Dokumente je Collection ist nur durch den Speicherplatz begrenzt, bis zu 64 Indizes je Collection sind machbar
- Master/Slave Kopplungen gehören zum Prinzip von mongodb, ein Write-Master und mind ein Read-Slave sollten zu einer produktiven Umgebung gehören
Alles in Allem ist dieser Ansatz wesentlich mächtiger als der klassischer SQL-DBs und das direkte 1:1 persistieren von Objekten und der programmiermäßige Umgang mit der DB selbst, läßt aus Programmierersicht die DB viel näher an die Anwendung heranwachsen. Tatsächlich reduziert mongodb die Leistung des Servers auf das reine verwalten der Daten selbst. Selbst der Primärindex ( eine Mischung aus timestamp, hash aus dem rechnernamen des schreibenden Rechners und einem Counter je einträge pro Millisekunde) generiert der Treiber oder der Programmierer, nicht jedoch der Db-Server.
Das gibt ein ganz neues Gefühl und ganz neue Freiheiten beim Umgang mit DBs, das mich derzeit einfach nur begeistert ( ich denke das kann man herauslesen ). Daher meine Eingangsfrage, denn wo Licht ist, ist nicht selten auch Schatten - nur sehe ich den noch nicht. Für mich hat dieser Ansatz das Potential die klassischen SQL-DBs abzulösen. Die haben ganz sicher ihre Vorteile, aber eben nicht überall. Hätte ich schon vor 15 Jahren die Wahl gehabt, ich hätte mich recht sicher für MongoDB entschieden statt dem MS SQL Server damals.
