Also eine VM (um das Thema nochmals aufzugreifen) hat bei einem Kunden zum kompletten Zusammenbruch der
DB geführt, einfach weil tierisch viele Daten übers Netz in die
DB geblasen werden und die VM-Umsetzung des Netzwerks nun einmal Overhead kostet.
Bei der prognostizierten Performance von knapp 2 Operationen pro Sekunde wird dieses Limit jedoch aller Vorausicht nach nicht erreicht werden.
Ich würde grundsätzlich einem
DB-Server so viel CPU-Power und
RAM wie irgend möglich spendieren, natürlich in Abwägung der zu erwartenden Arbeiten. So eine
DB ist ein Numbercruncher, nur eben nicht mit FP, sondern mit Integerwerten (Das Aggregieren von FP-Feldern mal ausgenommen, aber das fällt nicht ins Gewicht).
Mit handelsüblicher Mittelklasseserverhardware fährt man i.A. sehr gut. Wir merken bei Neukunden sehr schnell, das es mit einer
DB-Anwendung nicht getan ist, und dann ist es praktisch, beim
DB-Server nicht gespart zu haben.