Dieser Post wurde aus meiner alten WordPress-Installation importiert. Sollte es Darstellungsprobleme, falsche Links oder fehlende Bilder geben, bitte einfach hier einen Kommentar hinterlassen. Danke.
Sid Burn hat mich gestern auf MongoDB aufmerksam gemacht.
Ich bin seinem Rat gefolgt, und habe den interaktiven Online-Kursausprobiert. Wider erwarten handelte es sich glücklicherweise nicht um ein langweiliges Video, sondern wirklich um einen interaktiven Lehrer.
CouchDB scheint das dokumentenbasierte Prinzip exakt umgesetzt zu haben, während MongoDB sich näher an der Realität bewegt - und dabei sehr sehr stark an SQL erinnert.
Array vs. JOINPostgres kann mit Arrays als Daten einer Tabelle umgehen, allerdings nicht flexibel und nicht transparent.
MongoDB ist diesbezüglich flexibel: Jeder Wert kann ein einzelner Wert oder ein Array sein. Eigentlich ist das aber kein Verdient von MongoDB, sondern einer es Grundkonzeptes einer dokumentenorientierten Datenbank.
Postgres-Arrays sind bei der Suche nicht einfach, vor allem weil sie von DBIx::Class nicht sauber abstrahiert werden. MongoDB hat in diesem Punkt eindeutig die Nase vorn: Wird in einem Feld gesucht, ist es irrelevant ob der Wert ein Element eines Arrays ist, oder ob nur ein Wert vorhanden, aber zutreffend ist.
Postgres dagegen kann JOINen, ein Prinzip das in der nicht relationalen Welt von CouchDB undenkbar wäre, aber auch von MongoDB, die sich zwischen beiden Welten bewegt, nicht unterstützt wird.
An der Grenze
Einen großen Unterschied gibt es dennoch: MongoDB speichert maximal 4 MB pro Dokument - mehr geht nicht. Auch hier sind Anlagen möglich, die nicht dieser Grenze unterliegen und in der Praxis dürfte ein 4 MB Dokument eher selten sein, aber dennoch ist es eine Grenze, die in einigen Projekten zu Problemen führen könnte - insbesondere wenn stark verschachtelte Dokumente ins Spiel kommen.
Eine MongoDB-Collection (in etwa eine SQL-Tabelle) kann mit einem Größenlimit (in Bytes oder Dokumentenanzahl) belegt werden - alte Dokumente werden dann automatisch gelöscht, wenn die Collection voll ist. Das ist zum Beispiel für Log-Einträge sehr praktisch, es spart einen regelmäßigen DELETE FROM table WHERE COUNT>1000 ORDER BY id DESC (wobei ich noch nicht einmal sicher bin, dass dieser Befehl überhaupt funktionieren würde, aber ich denke der Sinn ist erkennbar).
MongoDB kennt dazu noch ein paar kleine praktische Spielereien auf die ich an dieser Stelle nicht weiter eingehen möchte.
Da sich beide so ähnlich sind - die freien Dokumente werden, wie im ersten Post gesagt, ohnehin wieder zu Perl-Objekten mit statischen Feldern - ist die Frage schwieriger denn je, ob Postgres oder MongoDB. CouchDB scheint dagegen bereits abgeschlagen zu sein, denn natürlich hält CPAN auch für MongoDB ein passendes Modul bereit.
2 Kommentare. Schreib was dazu-
Sid Burn
20.05.2011 17:36
Antworten
-
Sebastian
21.05.2011 14:36
Antworten
Mit MongoDB 1.8 wurde das Limit auf 16 MB angehoben. Ansonsten wurde mal erklärt das es keine technische Limitierung ist, sondern eine um den "Nutzer" etwas zu erziehen. Das man nicht alles in einem Dokumentet einbettet und auch die Collections nutzt und sinvoll aufteilt. Sonst verliert man eben die Geschwindigkeitsvorteile.
Die Begrenzung der Dokumente sehe ich auch noch etwas als kritisch an, denke aber das 16 MB ausreichend sind und man eher sein Datenbank Design überdenken sollte wenn einzelne Dokumente wirklich so groß werden.
Ich denke auch nicht, dass das 16MB-Limit zu Problemen führt, ausgenommen bei ganz speziellen Anwendungen. Eine Aufteilung würde allerdings wieder zu einer relationalen Datenbank führen - und dafür ist MongoDB ansich nicht gemacht.