Hallo *
Auch wenn der Thread schon etwas älter ist, habe ich mich gerade mal in diesem Forum registriert, um meinen Senf dazuzugeben. Vielleicht hilft es ja etwas oder führt zu neuen Diskussionen.
- Auch für Leute, die über Suchmaschinen hierherfinden.
Auf die Ursprungsfrage bin ich aufmersakm geworden, weil ich seit fast 10 Jahren in einem Datenbankbereich tätig bin, der mittlerweile als "NoSQL" tituliert wird. Meines Erachtens eine blödsinnige Bezeichnung - aber egal. Daher fange ich mit Deiner "NoSQL"-Frage als erstes an, bevor ich zu Deinen ersten Fragen komme:
Die "NoSQL"-Datenbanken aus diesem Bereich würde ich nicht zwingend als Alternative zu SQL sehen. Es ist schlichtweg nicht möglich, dass man mal eben von SQL auf NoSQL wechselt oder andersherum. (Allerdings funktioniert teilweise ein Wechsel zwischen verschiedenen SQL- und NoSQL-Produkten auch nicht ohne weiteres - aber das ist hier nicht das Thema). Von daher beschreibt NoSQL nur einen anderen oder auch ergänzenden Weg zu den vorhandenen Lösungen.
Aus persönlicher Erfahrung kann ich berichten, dass ich bei einem neuen Projekt - also quasi auf "grüner Wiese" - immer zuerst die Möglichkeiten der verschiedenen NoSQL-Lösungen evaluieren würde.- OK, jetzt könnt Ihr schreiben, ich sei befangen, weil ich ja bei einem Hersteller einer solchen arbeite - aber nimmt nicht jeder automatisch das Werkzeug, mit dem er sich am besten auskennt? Zudem habe ich vor meiner "NoSQL"-Zeit nur mit SQL-Systemen gearbeitet und stoße auch bei laufenden Projekten immer wieder darauf, weil wir Schnittstellen anbieten müssen. Von daher kenne ich viele Stärken und Schwächen beider Seiten.
Ob sich jetzt ein NoSQL- oder SQL-Produkt bei genau Dir anbietet, kann also nicht pauschal beantwortet werden. Das kommt darauf an, was genau Du vorhast und wie Deine "use cases" Deiner endgültigen Entwicklung aussehen. Wenn Du Dich weder gut in SQL noch in NoSQL auskennt, glaube ich aber, dass Du vermutlich mit dokument- oder objektorientierten NoSQL-Systemen schneller Erfolg haben wirst und von der Performance her auch noch viel Lusft nach oben hast.
Um konnkret auf Deine dritte Frage einzugehen (Ab wann lohnt es sich überhaupt?): Wie gesagt, so wie andere pauschal zu SQL greifen, greife ich mittlerweile zu NoSQL. Da ich selbst bei kleinen Ideen nicht weiß, wie es sich in der Zukunft verhalten wird, bin ich da einfach flexibler. Zumal ich ja an direkter Quelle sitze und ich ich mich schlichtweg nicht irgendwann mit dem ganzen Index-Müll auseinandersetzen möchte.
Das Thema "Index" ist übrigens ein Hauptgrund, warum "NoSQL" so im Kommen ist. Die einfache Verteilung der Datenbanken in kleine "Häppchen" verursacht eben auch nur kleine Indizes. Ich bin in den letzen Projekten immer wieder darüber gestolpert, dass selbst gestandene Datenbank-Admins nicht wissen, wie konkret ein Index arbeitet und was da optimiert wird - es gibt ja schließlich Software die das macht (z.B. Oracle Optimizer o.ä.). Daher kann ich nur empfehlen, sich da nochmal genauer einzulesen - oder ein paar einfach Youtube-Videos anzuschauen.
Und damit hast Du auch noch einen zweiten Grund für Deine dritte Frage: Die einfache Verteilung der Datenbank. Mal eben ein Cluster-System aufzubauen ist bei vielen NoSQL-Produkten eine Sache von ein paar Minuten.
Zu Deiner vierten Fragen (Haben große Anbieter von vornherein auf NoSQL gesetzt?): Ich denke nicht. Es gibt ja nicht nur Facebook. (wobei mich der NoSQL-Einsatz in der Timeline schon verwundert). Google hat viele Ansätze geliefert, nachdem sie viele Jahre Erfahrung gesammelt haben. Amazon liefert eine Lösung. Oracle hat von "SleepyCat" vor einigen Jahren die BerkeleyDB aufgekauft, SAP kommt seit 2011 mit Hana um die Ecke ... und so weiter. Es liegt schlichtweg daran, dass die Datenmengen und vernetzten Strukturen immens wachsen und irgendwie ausgewertet werden müssen. Dabei werden häufig die "NoSQL"-Lösungen mit allem möglichen vermischt. "Hana" von SAP ist zum Beispiel eine "in-Memory"-Lösung, in der SAP die SQL-Strukturen kopiert, um sie schneller abfragen zu können. Nur leider hilft das nicht immer. Ich weiß es aus einem Projekt, dass dort 3TB (ja - "terabyte"!!!) an Arbeitsspeicher benötigt werden. Die Abfragen dauern dann aber trotzdem 5 min. im Durchschnittund ein entsprechender Server kosten dann auch mal etwas sechstelliges.
Wie man sieht, kann man zwar klein anfangen, bekommt dann aber irgendwann - vielleicht - Probleme. Von daher: ob Du mit SQL oder NoSQL starten sollst, kann nicht pauschal beantwortet werden. Ich warne nur davor pauschal irgendetwas abzulehnen.
Für Deine ersten beiden Fragen können Dir vielleicht verschiedene Automatismen helfen. Es gibt Programme die quasi als "Batch" laufen und den von Dir "aufgezeichneten" Weg in vielen Threads durchlaufen. So simulierst Du dann die Last von 100 Userabfragen pro Sekunde. Allerdings verhalten sich die verschiedenen Lösungen manchmal unterschiedlich. Von daher kann es sinnvoll sein, wenn man sich selbst ein entsprechendes Script schreibt.
Die größte Latenz wird aber vermutlich allein durch die Internetleitung und den Webserver entstehen (wenn es denn ein "Internetprojekt" wird). Daher wird an dieser Stelle häufig die Last auf verschiedene Webserver verteilt (z.B. load balacing des Apache oder IIS).
So - vielleicht konnte ich Deine Fragen etwas beantworten und Dir helfen - aber vielleicht hast Du Dich ja auch schon für eine Lösung entschiedene.
Viele GRüße
