Datenbank testen | nosql?

Hallo,

ich arbeite z.Z. an einem Projekt bei dem (vereinfacht ausgedrückt) sich Benutzer auf einer Website registrieren/einloggen können und anschließend Gruppen erstellen können. Dazu kommen dann Funktionen wie:

- jede Gruppe enthält eine eigene Chronik/Gästebuch
- Ersteller und Mitglieder einer Gruppe können andere Personen einladen

Ich habe mich schon ein wenig mit MySql beschäftig aber in Hinsicht auf Themen wie Performance/Optimierung absolut keine Ahnung.Hierzu hätte ich ein paar Fragen.

1. Wie kann ich mein Projekt auf Performance/Beständigkeit testen, z.B. "Wie viele Anfagen/Sekunden werden beantwortet?
In der späteren Praxis werden/sollen natürlich mehrer Nutzer diesen Dienst
gleichzeitig Zugriff haben mit möglichst kleinen Latenzen.

2. Wie testen erfahrerne/große Entwickler ihre Datenbanken auf diese Kriterien?


Unter anderem ich bin auf das Thema NoSql (Not only Sql) gestoßen und laut Entwickler, heißt es das dies eine sehr gute Alternative zu Sql darstellen soll (Performance, Skalierbarkeit, etc.). Doch stimmt dies?

3. Ab wann "lohnt" sich ein NoSql System bzw. wird überhaupt eins benötigt?

4. Haben Social Networks, wie z.B. Facebook, von Anfang an auf NoSql gesetzt?

Vielen Dank im vorraus!

Mit freundlichen Grüßen

 

Also ich habe noch nie ein NoSQL System benutzt und kann dir auch zu Testroutinen nicht viel sagen. Einen Performance Test wirst du selbst programieren und simulieren müssen, um vernünftige Aussagen treffen zu können.

NoSQL ist sinnvoll, wenn es um Objektorientierte Daten geht. Wenn z.B. zu einem User (Objekt) viele verschiendene Informationen geladen werden sollen. Hier kommen bei SQL die Informationen aus speziellen Tabellen für Nachrichten, Bilder, Profil-Einstellungen, Kommentare etc. Bei NoSQL können diese Informationen nach meinem Verständniss zusammen abgelegt werden und dann schneller aufgerufen werden.

Ob das die Megaperformance für dein Projekt gibt will und kann ich nicht sagen. Selbst Social Networks wie Facebook setzen glaube ich derzeit nur auf MySQL, es geht also auch mit SQL. http://mashable.com/2011/12/15/facebook-timeline-mysql/

 

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

 

Hi Tom,

erstmal vielen Dank für deine ausführliche Antwort, ich denke ich hab die NoSQL - SQL Geschichte anfangs aus einem falschen Winkel betrachtet.


"Da ich selbst bei kleinen Ideen nicht weiß, wie es sich in der Zukunft verhalten wird, bin ich da einfach flexibler."
Diese Aussage beschreibt genau meinen Standpunkt! Ich weiß weder wie das Projekt bei der Masse ankommt, noch wie es sich entwickeln wird.
Daher ist flexilibität praktisch ein MUSS. Ich möchte nich das alle 2 Wochen zB neu an den ganzen Scripten gearbeitet werden muss.

"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."
Ich habe bereit einige Erfahrung in MySQL gesammelt, der Einstieg viel mir kein bisschen schwer und das dazu lernen bereitet ebenfalls keinerlei Probleme.
Bei den NoSQL Themen sieht das schon ganz anders aus.
Es geht über verschieden Typen (GraphDB, DocumentDB, etc.) und das ganze dann noch mal über verschiedenen Anbietern. Die Dokumentationen die ich gefunden habe waren dann doch sehr spärlich verfasst. Somit fällt mir der Einstieg recht schwer bzw. weiß ich nicht mal wo ich am besten anfangen soll.

"weil ich seit fast 10 Jahren in einem Datenbankbereich tätig bin, der mittlerweile als "NoSQL" tituliert wird"
Oder suche ich zwanghaft nach "NoSQL" informationen obwohl es bereits als "normal" angesehen wird?

"Ich warne nur davor pauschal irgendetwas abzulehnen."
Dies ist ein weiterer Grund warum es sich meiner Meinung nach Lohnt sich mit dem Thema zu befassen. Ich möchte auf jeden Fall einen Blick auf den "Plan B" haben.


Dann nochmal kurz meine Meinung zu den 2 anderen Themen.

"Zu Deiner vierten Fragen (Haben große Anbieter von vornherein auf NoSQL gesetzt?): Ich denke nicht. "
An sich bin ich deiner Meinung, aber heute sieht schon wieder alles anders aus. Gefällt heute Person A eine Seite, so kennt am nächsten Tag bereits Person XY diese. Damit will ich sagen das heutzutage die Dinge ungemein schneller kursieren (via Facebook, Twitter, ...) und da mein Projekt ebenfalls von den User abhängt die dort sind ist das richtige angehen an die Sache das A und O.

"Von daher kann es sinnvoll sein, wenn man sich selbst ein entsprechendes Script schreibt."
Ich vermute mal dieser Punkt rückt erst in den Vordergrund wenn es Richtung Release geht? Momentan läuft alles per XAMPP auf meinem System und schließlich hängt die Abfrage/Sekunde-Rate nicht nur von der Datenbankmodellierung ab.


Ich würde mich freuen wenn du/ihr ein paar Tipps/Links für mich hättest, mit denen ich den richtigen Einstieg/Weg in die Materie finde.
Euch allen noch einen schönen Tag. =)

Mit freundlichen Grüßen

 

Hi

Versteh mich nicht falsch - Du bist natürlich auch bei SQL bis zu einer gewissen Größe flexibel. Ich sehe nur immer wieder, dass die Möglichkeiten von SQL überschätzt werden und dass es für bestimmte Dinge nicht das optimale Werkzeug ist. Dazu kommt, dass viele Leute einfach aneinander vorbeireden, wenn Sie über SQL-Probleme sprechen. Selbst hier im Forum habe ich einen kleinen Thread gefunden, bei dem ich der Meinung bin, dass die Beteiligten aneinander vorbeireden (link). - vielleicht wurde er deswegen auch nicht weitergeführt. Aber ich finde, es zeigt ganz gut, dass es bei relationalen Systeme nicht ausreicht nur SQL "zu sprechen", sondern dass es erforderlich ist, auch das dahinter zu kennen.

Auch bei NoSQL kann man viele Dinge kompliziert lösen, obwohl es sicherlich einfacherere Wege gibt. Die Frage ist aber eben, wie schnell kann man ein Produktivsystem wirklich so ändern, dass es den geänderten Anforderungen wieder gerecht wird? Und da glaube ich eben, dass ich bei großen und vernetzten Datenbeständen besser bei NoSQL aufgehoben bin. (meine persönliche Meinung) Das Problem hierbei ist eben, dass es keine einheitliche Abfragesprache wie SQL gibt. (Wobei sich das "einheitlich" mittlerweile auch nur noch auf "Ansi SQL" bezieht. Ein einfacher Wechsel von einem zu einem anderen SQL-System ist nicht immer einfach möglich.)

Um Deine Frage bzgl. eines Tips zu beantworten, versuche ich hier mal einen kleinen Abriss und ein vage Empfehlung auf Basis der von Dir gegebeben Informationen:

Den größten Überblick über die angebotenen NoSQL-Lösungen findest Du unter nosql-database.org - allerdings sind dort nicht alle Lösungen aufgeführt. Ein paar kleine (aber trotzdem gute Lösungen) sind nicht darunter, soweit ich weiß. Allerdings ist das nur eine Auflistung der Lösungen. Die Seite bietet noch keine Hilfestellung zum Umgang mit den Lösungen.

Dann ist auch heise.de immer ganz gut. Da kann man sich zu den News im NoSQL-Bereich informieren.

Ein guter, wenn auch oberflächlicher Artikel, ist ebenfalls unter heise.de zu finden. Im Jahr 2010 gab es auch eine Artikelserie, in der verschiedene Produkte vorgestellt und die Möglichkeiten erläutert wurden. Hier kann man aber sagen, dass die "größeren" Produkte ohnehin die eigene API auf der eigenen Webseite ausführlich beschreiben.

Und da ist dann auch schon das Stichwort "API". Bei NoSQL wirst Du nicht drumherum kommen, Dich in die API des gewählten Produktes einzuarbeiten. Allerdings ist das relativ überschaubar und einfach, weil man nicht viele Funktionen braucht.

Insgesamt lassen sich grob mehrere (aktuelle) Bereiche an Datenbanken unterscheiden (ich lasse mal hierarchische Lösungen u.ä. weg):

• relational (also SQL: Oracle, MySQL, MS SQL, Postrgres,...)
• key/value-stores (ein Datensatz besteht aus einem eindeutigen Schlüssel und einem Wert - siehe z.B.: Redis)
• document stores (unter einer eindeutigen ID wird die Dokumentstruktur, z.B. JSON, gespeichert - siehe MongoDB oder Couchbase)
• graph db (ähnlich wie document sores, nur um die Erweiterung, dass der Graph an einem Objekt als Metadaten gespeichert wird - siehe z.B. neo4j)
• Objektdatenbanken ("Objekt" wie in "objektorientiert". Die Objekte aus z.B. Java oder C# werden direkt, ohne objektrelationale mapping gespeichert - siehe objectivity, versant und db4o)
• big tables (nicht zu verwechseln mit einer relationalen Tabelle. Hier besteht ein Datensatz aus einem dynamischen Konstrukt beliebiger Felder innerhalb eine bestimmten Kontextes. Ein anderer Datensatz kann mehr oder weniger Felder haben.
• Volltext Index (reiner Index für die Suche in Volltexten - siehe z.B. Lucene)

Auf Basis Deines grob skizzierten Projektes würde ich vermutlich zu einem "document store" greifen. Vielleicht auch zu einem "big table". MongoDB und couchbase sind recht schnell installiert und in Betrieb zu nehmen. Und die API ist auch ganz dokumentiert. Vielleicht kannst Du da ja schon etwas ausprobieren. Ich hatte Anfang letzten Jahres mal einen Auftrag für einen Software-Prototypen auf CouchDB/Couchbase. Da gefielen mir die Abfragemöglichkeiten nicht so gut. Aber wer's mag ;-)

Ich könnte auch unsere Lösung empfehlen ;-) aber ich will hier keine Werbung machen. Zudem sind wir kommerziell.

Ansonsten gibt es mittlerweile auch schon ein paar bücher zu dem Thema NoSQl und CouchDB, MongoDB im speziellen. Die sind sicherlich auch ganz sinnvoll, um einen Überblick über die Möglichkeiten zu erhalten und einen ersten Ansatz zu finden.

Viele Grüße