Überlegungen zum Thema Serverhardware

[Tywin]

Hallo,

ich versuche gerade aufgrund der Application + Datenbank auf die Hardware zu schließen. Die Application ist Java und eigentlich nur als Mini zu betrachten. Die Arbeit verrichtet die Datenbank.
Die Datenbank besteht aus einer Tabelle mit 8 Spalten mit index - ein Eintrag kommt nach meinen Rechnungen (Datentypengröße addiert) auf 60 byte. Ich habe vor extra großen Speicher anzuschaffen (16 GB DDR2) damit die Datenbank auch ganz im Speicher gehalten werden kann.

Spekuliere ich nun mit 50 neuen Einträgen in der Sekunde und rechne das dann auf ein paar Jahre hoch so muss ich feststellen, dass die DB bald deutlich zu groß wird für den Speicher.

- Sind diese überlegungen richtig?

Desweitern weiß ich nicht wie groß ich meine Festplatte anlegen soll. Diese dient in dem Fall ja nur als Backupspeicher, weil sowohl application wie auch db im ram gehalten sind. Also nehme ich die spekulierte Größe der DB in 10 Jahren und gib noch etwas drauf? (- keine besonderen anderen application werden auf der platte sein)

- Stimmt diese Überlegung?

Wenn ich nun als Internetanbindung 10 Mbit/second annehme, dann reicht das für die geschilderten Dinge locker aus, wenn ich pro db-connection (max 120/sec) maximal 800kbit sende und empfange.


Wie ihr vielleicht seht, fehlen mir die nötigen Anhaltspunkte und ich hab überhaupt keine Ahnung ob diese Überlegungen richtig sind.... daher bitte ich euch um Feedback. - Danke

 

[Projekt2501]

Hi,

hab deine Rechnung nachvollzogen und komme bei der Größe auf ähnliche Ergebnisse.

MySQL AB :: MySQL 5.1 Referenzhandbuch :: 14.3 Die MERGE-Speicher-Engine

Das könnte dir ein paar Ansätze liefern.

Hoffe ich konnte wenigstens etwas helfen.

Grüße
Projekt2501

 

[amnesie]

Spekuliere ich nun mit 50 neuen Einträgen in der Sekunde und rechne das dann auf ein paar Jahre hoch so muss ich feststellen, dass die DB bald deutlich zu groß wird für den Speicher.

- Sind diese überlegungen richtig?

Die Speichermenge habe ich jetzt nicht nachgerechnet, ich frage mich allerdings nur, warum du alles im Speicher halten willst. Wie sieht dein Zugriffsmuster auf die Daten aus? Kannst du vernünftige Indizes erstellen oder gar partitionieren?

Desweitern weiß ich nicht wie groß ich meine Festplatte anlegen soll. Diese dient in dem Fall ja nur als Backupspeicher, weil sowohl application wie auch db im ram gehalten sind. Also nehme ich die spekulierte Größe der DB in 10 Jahren und gib noch etwas drauf? (- keine besonderen anderen application werden auf der platte sein)

- Stimmt diese Überlegung?

Die Hardware wird keine 10 Jahre lang so existieren, also rechne nur mal 3-4 Jahre im Vorraus. Wenn du ein Volume Manager benutzt, spielt die Partitionsgrösse keine Rolle. Ausserdem kannst du später mal noch Festplatten nachlegen.

Wenn ich nun als Internetanbindung 10 Mbit/second annehme, dann reicht das für die geschilderten Dinge locker aus, wenn ich pro db-connection (max 120/sec) maximal 800kbit sende und empfange.

Ist deine Anbindung eine kritische Grösse?

Wie ihr vielleicht seht, fehlen mir die nötigen Anhaltspunkte und ich hab überhaupt keine Ahnung ob diese Überlegungen richtig sind.... daher bitte ich euch um Feedback. - Danke

Was für eine Anwendung? Was für ein Zugriffsmuster? Irgendwelche sonstige kritischen Grössen (50 garantierte inserts pro Sekunde über Jahre hinweg? Garantierte Antwortzeiten für bestimmte Abfragen?)

Lös dich von der Vorstellung, daß deine Daten komplett in den Speicher passen müssen, es wird ziemlich sicher nicht funktionieren (viel Speicher hilft trotzdem viel); ausserdem rechne nicht mit 10 Jahren Laufzeit, insbesondere weil die Hardware nicht so lange mitmachen wird.

 

[Tywin]

Super, danke beide Antworten waren sehr hilfreich!

Warum ich alles im Speicher halten möchte? Ich dachte das gibt enormen performance schub und alle optimierten DB würden so gehandhabt werden. wenn ich nur wenig ram habe muss der ja immer auf die platte swappen or?

Ob die Anbindung eine kritische Größe ist? Nun ich muss ehrlich gestehen ich verstehe deine Frage hier nicht. Ich muss lediglich wissen, welche connection ich brauche, damit das teil läuft.

Die Anwendung selber prüft lediglich mithilfe der Datenbank Objekte mit einigen Abfragen. Durchschnittlich 50 Anfragen / Sekunden ist auch über Jahre hinweg zu erwarten - ja.
Garantierte Antwortzeiten für bestimmte Abfragen? Nein es soll aber nicht zu größeren Verzögerungen kommen.

Und bezüglich "Viel speicher hilft trotzdem" - kann man hier auch hineininterpretieren, dass je mehr speicher, desto mehr darf die cpu nachlassen? ich hab z.b. überhaupt keine ahnung was ich für so nen server für cpu brauche.

Danke nochmals für die Antworten!

 

[Projekt2501]

Ich hätte einen Vorschlag für dich.

Schreib dir ein Script, dass die Anfragen ohne Rücksicht auf Verluste in die DB hämmert mit deinem normalen Rechner.

Müll die also mit Dummydaten mal so richtig schön voll.

Teste die Performance mit einer Datenbank, die komplett in den Speicher passen könnte (will sagen gut reinpaßt).

Dann geh hin und Müll das Ding weiter zu bis es die 2-3 Fache größe des RAMs hat und teste wieder die Performance. Wenn du ne schnelle Platte dran hast könnte dir das vielleicht schon reichen.

Und ja, mehr RAM ist immer ein sehr guter Weg.

Denke mal so bekommst du ein "Feeling" dafür wie sich eine Datenbank verhalten könnte.

Greets
Projekt2501

 

[amnesie]

Ich schliesse mich meinem Vorredner an: Führe mal einen Test durch und schau, wie sich deine Anwendung in ein paar definierten Szenarien, die du als wahrscheinlich hälst, verhält. Daraus kannst du dann hochrechnen, was für Hardware du brauchst.

Bezüglich RAM: Die Datenbank nutzt den verfügbaren Speicher selbstständig aus, und sie weiss im Normalfall auch recht gut, welche Daten sie im RAM halten muss und bei welchen es nicht lohnt. Viel Speicher ist gut, CPU kann bei bestimmten Aktionen auch kritisch sein.