Das Tabellenmodel muss nicht unbedingt ausschlaggebend sein, ein guter Grund um von einer klassischen Relationalen Datenbank weg zu gehen kann auch die Performance sein. Vor allem im WebAnwendungsbereich werden Features wie Transaktionen und aehnlich oft nicht gebraucht, oder nur in schwacher Form.
MongoDB kann z.B. Transaktionen auf einzelnen Objekten, nicht aber auf ganzen Collections, das reicht in vielen Faellen aber schon. Dafuer bekommt man dann eine insgesammt schneller reagierende Web Anwendung.
Es ist im NoSql Bereich auch durchaus ueblich mehr als eine Datenbank zu nutzen. Also zum ablegen von komplexen Dokumenten eine Documentendb wie Mongo oder Couche. Und zum verwalten von einfach strukturiertem Daten, wie z.B. Session informationen eine Key/Value Datenbank.
Aus letzterem Standpunkt macht eine Vereinigung der beiden hier natürlich Sinn!
Auch bei SQL DBs sind Transaktionen kein muss, sondern ein kann. Je nach DB gibt es sie sogar nicht einmal.
Zu NoSQL DBs im allgemeinen kann man nichts zur Geschwindigkeit sagen. Das hängt alleine vom Fall ab. Zumal man sich oft die höhere Geschwindigkeit durch komplexere Anwendungen erkauft. Nicht zu vergessen taugen auch SQL DBs oft als Key/Value Store, und sind dann nicht einmal langsamer.
Größer Key/Value Store solcher Art ist heute noch Facebook auf MySQL.
Ich gebe dir aber absolut recht das Mixen heute oft vorkommt, auch hier siehe Facebook, welche HBase für ihre Inbox einsetzen. Facebook hat zudem Cassandra entwickelt, welches sie aber wohl aktuell selbst nicht einsetzen, da dessen Transaktionsmodell (...) wohl nicht passt (leider habe ich den Link dazu nicht mehr zu Hand).
Zweifellos ist heute die Auswahl an Techniken Stark gestiegen. Keine schlechte Sache wie ich denke.
Beispiel einer größeren MongoDB Installation: ServerDensity. Dort speichern sie alle 5 Minuten alle Prozesse und Umgebungsinfos zu jedem überwachten Server. Sollen inzwischen nicht wenige Daten sein die sich so angesammelt haben. Allerdings: Sie haben gerade eine Downtime hinter sich, da ihr MongoDB Cluster mehrmals mit Exceptions zusammengebrochen ist.
Wo wir wieder beim Thema: Stabil und erprobt wäre. Meine MySQL Server laufen im Schnitt 1 Jahr ohne jeden Mux, dann ist meistens ein Restart wegen irgendeines Updates am Kernel oder MySQL notwendig.
Wie oben von mir geschrieben denke ich das NoSQL DBs einfach ein logischer Schritt hin zu mehr "passgenauen" Lösungen sind, weg von Standardlösungen die für jeden etwas bieten.
Vor nicht wenigen Jahren bestand die Basis einer normale Webanwendung aus: - einem Webserver - einer SQL Datenbank.
Heute haben wir eher solche Situationen: - Static-File Server (z.B. nginx) - Webserver/Application Server (eben Apache, oder whatever) - Message Queue (z.B. RabbitMQ) - SQL Datenbank - Cache-Server (meist Memcache) - oft noch eine NoSQL DB dazu wo passend
Dann manchmal noch spezielle Filelösungen, für die heute doch schnell zusammenkommenden Dateiberge durch Useruploads.
Ok. Also NoSQL heisst im prinzip alles von Key/Value-Store aka persistentes Memcache (vereinfacht gesagt) bis speziell für irgendwas. Aber ganz verste ich es dennoch nicht. Eine MySQL ist doch ohne Joins im Prinzip auch als einfacher key/value store zu nutzen, und nur so genutzt sicher auch nicht viel langsamer als ne NoSQL Lösung, oder doch .... egal, ich wrd mal gucken was ich dazu noch so für infos finde.
Das Tabellenmodel muss nicht unbedingt ausschlaggebend sein, ein guter Grund um von einer klassischen Relationalen Datenbank weg zu gehen kann auch die Performance sein. Vor allem im WebAnwendungsbereich werden Features wie
Transaktionen und aehnlich oft nicht gebraucht, oder nur in schwacher Form.
MongoDB kann z.B. Transaktionen auf einzelnen Objekten, nicht aber auf ganzen Collections, das reicht in vielen Faellen
aber schon. Dafuer bekommt man dann eine insgesammt schneller reagierende Web Anwendung.
Es ist im NoSql Bereich auch durchaus ueblich mehr als eine Datenbank zu nutzen. Also zum ablegen von komplexen Dokumenten eine Documentendb wie Mongo oder Couche. Und zum verwalten von einfach strukturiertem Daten, wie
z.B. Session informationen eine Key/Value Datenbank.
Aus letzterem Standpunkt macht eine Vereinigung der beiden hier natürlich Sinn!
Auch bei SQL DBs sind Transaktionen kein muss, sondern ein kann. Je nach DB gibt es sie sogar nicht einmal.
Zu NoSQL DBs im allgemeinen kann man nichts zur Geschwindigkeit sagen. Das hängt alleine vom Fall ab.
Zumal man sich oft die höhere Geschwindigkeit durch komplexere Anwendungen erkauft. Nicht zu vergessen taugen auch SQL DBs oft als Key/Value Store, und sind dann nicht einmal langsamer.
Größer Key/Value Store solcher Art ist heute noch Facebook auf MySQL.
Ich gebe dir aber absolut recht das Mixen heute oft vorkommt, auch hier siehe Facebook, welche HBase für ihre Inbox einsetzen. Facebook hat zudem Cassandra entwickelt, welches sie aber wohl aktuell selbst nicht einsetzen, da dessen Transaktionsmodell (...) wohl nicht passt (leider habe ich den Link dazu nicht mehr zu Hand).
Zweifellos ist heute die Auswahl an Techniken Stark gestiegen. Keine schlechte Sache wie ich denke.
Beispiel einer größeren MongoDB Installation: ServerDensity. Dort speichern sie alle 5 Minuten alle Prozesse und Umgebungsinfos zu jedem überwachten Server. Sollen inzwischen nicht wenige Daten sein die sich so angesammelt haben.
Allerdings: Sie haben gerade eine Downtime hinter sich, da ihr MongoDB Cluster mehrmals mit Exceptions zusammengebrochen ist.
Wo wir wieder beim Thema: Stabil und erprobt wäre. Meine MySQL Server laufen im Schnitt 1 Jahr ohne jeden Mux, dann ist meistens ein Restart wegen irgendeines Updates am Kernel oder MySQL notwendig.
Wie oben von mir geschrieben denke ich das NoSQL DBs einfach ein logischer Schritt hin zu mehr "passgenauen" Lösungen sind, weg von Standardlösungen die für jeden etwas bieten.
Vor nicht wenigen Jahren bestand die Basis einer normale Webanwendung aus:
- einem Webserver
- einer SQL Datenbank.
Heute haben wir eher solche Situationen:
- Static-File Server (z.B. nginx)
- Webserver/Application Server (eben Apache, oder whatever)
- Message Queue (z.B. RabbitMQ)
- SQL Datenbank
- Cache-Server (meist Memcache)
- oft noch eine NoSQL DB dazu wo passend
Dann manchmal noch spezielle Filelösungen, für die heute doch schnell zusammenkommenden Dateiberge durch Useruploads.
Ok. Also NoSQL heisst im prinzip alles von Key/Value-Store aka persistentes Memcache (vereinfacht gesagt) bis speziell für irgendwas.
Aber ganz verste ich es dennoch nicht. Eine MySQL ist doch ohne Joins im Prinzip auch als einfacher key/value store zu nutzen, und nur so genutzt sicher auch nicht viel langsamer als ne NoSQL Lösung, oder doch .... egal, ich wrd mal gucken was ich dazu noch so für infos finde.