Übverall dort, wo das eher starre Tabellenmodel "üblicher" Datenbanken nicht mehr passt.
Man kann NoSQL DBs auch als Ansatz sehen, weg vom allgemeinen, hin zum speziellen zu kommen. Lange wurden im großen und ganzen nur SQL DBs verwendet. Das hatte gute Gründe, waren und sind sie doch gut getestet, und ihre Nutzung ist wohl bekannt. Aber das Modell hat auch Nachteile, vor allem bei der Skalierung (das trifft nur ab er ganz ganz wenige wirklich, weit weniger als viele glauben).
Viele NoSQL DBs wählen andere Grundansätze, sind z.B. Dokumenten-DBs, verzichten auf Spalten, Verteilen ihre Abfragen-Verarbeitungen in einen Cluster, akzeptieren hohe Latenzwerte bei der Replikation usw. Je nachdem was dem Anwendenden Vorteile bringt.
Da jeder andere Anforderungen hat, gibt es auch mehr als eine NoSQL DB. Und sie alle unterschieden sich deutlich. Manche sind nur einfache Key/Value Stores ohne jede Logik, um persistenz erweiterte Memcache Versionen werden oft als einfachste NoSQL DB genutzt. Andere nutzen komplexe Systeme wie kopien von Googles BigTable.
Übverall dort, wo das eher starre Tabellenmodel "üblicher" Datenbanken nicht mehr passt.
Man kann NoSQL DBs auch als Ansatz sehen, weg vom allgemeinen, hin zum speziellen zu kommen. Lange wurden im großen und ganzen nur SQL DBs verwendet. Das hatte gute Gründe, waren und sind sie doch gut getestet, und ihre Nutzung ist wohl bekannt. Aber das Modell hat auch Nachteile, vor allem bei der Skalierung (das trifft nur ab er ganz ganz wenige wirklich, weit weniger als viele glauben).
Viele NoSQL DBs wählen andere Grundansätze, sind z.B. Dokumenten-DBs, verzichten auf Spalten, Verteilen ihre Abfragen-Verarbeitungen in einen Cluster, akzeptieren hohe Latenzwerte bei der Replikation usw. Je nachdem was dem Anwendenden Vorteile bringt.
Da jeder andere Anforderungen hat, gibt es auch mehr als eine NoSQL DB. Und sie alle unterschieden sich deutlich. Manche sind nur einfache Key/Value Stores ohne jede Logik, um persistenz erweiterte Memcache Versionen werden oft als einfachste NoSQL DB genutzt. Andere nutzen komplexe Systeme wie kopien von Googles BigTable.
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.
Man hört ja jetz immer öfter von "NoSQL" Datenbanken.
Aber wo liegt deren Anwendungsgebiet eigentlich?
Übverall dort, wo das eher starre Tabellenmodel "üblicher" Datenbanken nicht mehr passt.
Man kann NoSQL DBs auch als Ansatz sehen, weg vom allgemeinen, hin zum speziellen zu kommen.
Lange wurden im großen und ganzen nur SQL DBs verwendet. Das hatte gute Gründe, waren und sind sie doch gut getestet, und ihre Nutzung ist wohl bekannt.
Aber das Modell hat auch Nachteile, vor allem bei der Skalierung (das trifft nur ab er ganz ganz wenige wirklich, weit weniger als viele glauben).
Viele NoSQL DBs wählen andere Grundansätze, sind z.B. Dokumenten-DBs, verzichten auf Spalten, Verteilen ihre Abfragen-Verarbeitungen in einen Cluster, akzeptieren hohe Latenzwerte bei der Replikation usw.
Je nachdem was dem Anwendenden Vorteile bringt.
Da jeder andere Anforderungen hat, gibt es auch mehr als eine NoSQL DB. Und sie alle unterschieden sich deutlich. Manche sind nur einfache Key/Value Stores ohne jede Logik, um persistenz erweiterte Memcache Versionen werden oft als einfachste NoSQL DB genutzt. Andere nutzen komplexe Systeme wie kopien von Googles BigTable.
Was immer einen zufrieden macht
Übverall dort, wo das eher starre Tabellenmodel "üblicher" Datenbanken nicht mehr passt.
Man kann NoSQL DBs auch als Ansatz sehen, weg vom allgemeinen, hin zum speziellen zu kommen.
Lange wurden im großen und ganzen nur SQL DBs verwendet. Das hatte gute Gründe, waren und sind sie doch gut getestet, und ihre Nutzung ist wohl bekannt.
Aber das Modell hat auch Nachteile, vor allem bei der Skalierung (das trifft nur ab er ganz ganz wenige wirklich, weit weniger als viele glauben).
Viele NoSQL DBs wählen andere Grundansätze, sind z.B. Dokumenten-DBs, verzichten auf Spalten, Verteilen ihre Abfragen-Verarbeitungen in einen Cluster, akzeptieren hohe Latenzwerte bei der Replikation usw.
Je nachdem was dem Anwendenden Vorteile bringt.
Da jeder andere Anforderungen hat, gibt es auch mehr als eine NoSQL DB. Und sie alle unterschieden sich deutlich. Manche sind nur einfache Key/Value Stores ohne jede Logik, um persistenz erweiterte Memcache Versionen werden oft als einfachste NoSQL DB genutzt. Andere nutzen komplexe Systeme wie kopien von Googles BigTable.
Was immer einen zufrieden macht
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.