DataSets & NoSQL like MongoDB/CouchDB
verwendetes Datenbanksystem: CouchDB oder MongoDB
Hallo zusammen,
ich habe eine kleinere Frage, auf die ich im GOOGLE keine vernünftige Antwort fand.
Ist es möglich die vorhandene Datenlogik, die als DataSet im Projekt existiert und derzeit für eine SQL DB verwendet wird, auf eine NoSQL DB anzuwenden und zu verwenden.
Dass da bestimmte Anpassungen wie Treiber oder DataTableRow benötigt werden, ist mir klar. Würde aber die vorhandene Logik aber weiter funktionieren?
NoSQL ist keine herkömmliche relationale Datenbank. Es ist eher eine Art Baum (eben Json), statt nur eine Tabelle.
Ich hab das mit DataSets noch nie getestet, aber den klassischen, stark regulären Weg schlagen diese Datenbanken nicht ein - sind eben auch sehr viel dynamischer und benötigen diesbezüglich auch viel mehr Disziplin seiten des Entwicklers; daher bezweifel ich eine Unterstützung von DataSets der Datenbanken diesbezüglich sehr.
Aus diesem Grund gibt es für die MongoDB auch eine komplett eigene Library, um diese und ihre Funktionen im gedachten Ursprung auch nutzen zu können.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Also würde es bedeuten, dass ich parallel eine ähnliche Data Logik aufbauen müsste, die aber mit der NoSQL DB arbeitet und im Menu dem User die Möglichkeit biete zu switchen.
Danke für die schnelle Antwort. Noch eine letzte für diesen Tag. Im Internet bin ich auf einen sehr interessanten Beitrag gestoßen, wo behauptet wird, dass eine NoSQL DB wie die MongoDB 100 mal schneller arbeiten kann bei komplexeren Abfragen, sowie Schreibaufgaben, als die SQL DB.
Gibt es da Erfahrungen, die es bestätigen könnten?
Hier ist der Link : MongoDB vs. SQL DB
Ja das stimmt soweit.
Dazu sei aber gleich gesagt: wem die Konsistenz der Daten wichtiger ist als die Performance, der ist mit einer relationalen DB besser bedient.
Sowas macht sich erst bei einigen Tausend / hunderttausend Zugriffe pro Sekunde dann wirklich bemerkbar. Eine normale Seite, wie Focus, Spiegel, die vielleicht 3-4 Millionen Zugriffe am Tag haben - die werden sicherlich kein NoSQL nutzen und auch gar nicht brauchen.
Facebook / Google hat aber Milliarden von Anfragen jeden Tag. Meine sogar, dass Facebook WebServer-Anfragen im mittleren 2-stelligen Milliardenbereich beantwortet. ((Ob die Zahl wirklich stimmt - keine Ahnung. Kann ich mir aber bei 300 Mio aktiven Leuten pro Tag gut vorstellen. Dass einiges Cached wird - keine Frage.)
Prozentual gesehen ist die performance beachtlich; im Einzefall gesehen aber marginal: ob ein großer DB Zugriff einer Website nun 45ms oder 2ms benötigt; das merkt der Anwender nicht, da andere Instanzen (Verbindungsaufbau, Übertragung des HTML Codes) mehr Zeit verschlingen. Hier sind also Optimierungen an anderer Stelle besser.
Bei Webseiten sagt man sowieso alls unter 130ms merkt ein Anwender nicht mehr.
Diese Datenbanktechnik hat andere Vorteile; aber eben auch Nachteile. Man muss wissen, was man will.
Im Prinzip nutzen alle hochverfügbaren Seiten (Amazon, Facebook, Google..) mittlerweile NoSQL Datenbanken, da diese eben deutlich performanter sind. Dafür hast Du unter umständen Inkonsistenzen, auf die man eben reagieren muss. Aber dafür gibts normalerweise von der Engine aus dann auch Trigger.
Der große Performancevorteil bei NoSQL ist eben, dass langsame Joins nicht oder nur sehr selten wirklich ausgeführt werden. Das ist wahrscheinlich der größte Push.
Im Studium wurd das Anhand eines Ticketverkaufes für die WM erklärt:
Die Seiten werden um eine gewisse Uhrzeit freigeschalten. Schlagartig wird also Performance abgefragt; die Performance ist ungemein wichtig in diesem Moment. Nebenprodukt sind aber Inkonsistenzen durch interne und externe Laststeuerung, keine wirklichen Schemas...
Dieses nimmt man aber in Kauf, da man diesbezüglich sehr einfach reagieren kann und die spätere Buchung storniert.
Weitere Vorteil dieser Datenbanken ist eben das flexible Schema.
Die ersten, die das genutzt haben in großem Ausmaße war damals Amazon. Mit Facebook, die ja gar nicht wissen, was sie in 3 Jahren für Features haben, und die sehr schnelle Entwicklungszyklen haben, hat die NoSQL-DB dann den durchbruch geschafft.
Wenn Du Deine Datenbank korrekt gekapselt hast, sollte das eigentlich egal sein, welche DB Deine Anwendung nutzt. Die Entities definierst Du sowieso Zentral. Was davon also von der DB Schicht an das Entity und damit an die Anwendung kommt - im optimalen Fall alles absolut sauber getrennt.
Im Prinzip geht eine Klassendefinition eher in Richtung relationale Datenbanken; Spalten = Properties etc...
Aber nutzt Du eben eine neue Spalte auf dynamischen Wege in einer NoSQL Datenbank, so bildest Du diese eben mit einem optimalen Property ab.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
@morbus85:
DataSet und Co eher nicht.
Schon mal Simple.Data Angeschaut?