Vergleich und Evaluation zwischen modernen und traditionellen Datenbankkonzepten unter den Gesichtspunkten Skalierung, Abfragemglichkeit und Konsistenz

Zehntausende Web-Services verwenden relationale Datenbanken, um Daten zu
speichern und auszulesen. Im Vergleich zu modernen Konzepten knnen relationale Datenbanken als wichtigster Stellvertreter fr "traditionelle Technologien'' bezeichnet werden. Wenn man als Entwickler zu Seiten wie Google.com, Facebook.com, Amazon.com, Digg.com, Ebay.com, Yahoo.com, Twitter.com oder Dawanda.com surft, wird meist angenommen, dass eine verteilte relationale Datenbank verwendet wird. Die Annahme ist zu 50% richtig, jedoch ist die Datenhaltung meist nicht relational. Diese Grounternehmen verwalten mehrere hundert Gigabytes, bis hin zu 100.000 Gigabyte an Daten, und mussten in den letzten sechs Jahren Lsungen finden, um erfolgreich diese riesigen Datenmengen zu beherrschen. Google erfand vor ca. sieben Jahren ein Verfahren, um Datenmengen im Petabytebereich zu beherrschen. Facebook entwickelte selbst eine Datenbanktechnologie, um die Posteingnge von Benutzern verfgbar zu machen, Twitter.com adaptiert diese Technologie fr andere Zwecke. Amazon.com entwickelte "Dynamo'', um Hochverfgbarkeit fr deren weltgrte E-Commerce Plattform zu schaffen. Diese und andere Eigenentwicklungen entstanden aus der Notwendigkeit heraus, riesige Datenmengen bzw. Datenbanken hoch verfgbar, konsistent und skalierbar zu machen.

Seit den letzten drei Jahren sind alternative "Open-Source-Implementierungen'' dieser Entwicklungen entstanden. Die Verffentlichung der Konzepte und Technologien fhrten zu einer ganzen Bewegung namens "NoSQL''. Sind diese Konzepte vorteilhafter, um eine bessere und fr Entwickler einfachere Skalierung, Abfragemglichkeit und Datenkonsistenz in einem hochverfgbaren Datenbanksystem, zu gewhrleisten? Wie werden komplexe Abfragen in modernen und traditionellen verteilten Systemen gemacht und wie werden diese ausgefhrt? Speziell stellt sich die Frage, ob das MapReduce Verfahren ein vollstndiger Ersatz fr SQL ist. Fr welche Einsatzzwecke sind beide besonders gut geeignet