Hardwarebedarf abschätzen

[OnDemand]

Hallöle,

versuche grad iiiirgendwie abzuschätzen wie man einen Server dimensionieren sollte. Gibts irgendne groß Richtung nach der man vorgehen kann? Die Server sind iwie eine Art VM in der Cloud, aber keine richtige VM, sind daher flexibel anpassbar. Mir gehts eigentlich hauptsächlich um Kerne + RAM damit da nix abschmiert.

Möchte einen SpringBoot Service installieren, der 10 CSV Dateien gleichzeitig verarbeitet, jede CSV ist 100-150MB groß, wird gelesen und in die Datenbank gesteckt. Wenn ich die Daten in eine List einlese ist die List 25 MB schwer (welche den RAM belasten?)

Außerdem liegt da eine Postgres Datenbank drauf, welche die CSV Daten aufnimmt.

 

[mihe7]

Gibts irgendne groß Richtung nach der man vorgehen kann?

Messen und Testen. Der Speicher hat nicht nur Einfluss darauf, ob die Kiste abschmiert sondern ggf. auch auf die Laufzeit, die wiederum vom GC abhängig ist. Da die Maschine sowieso nur die eine Aufgabe hat, sollte man m. E. mit dem Heap nicht geizen: Xms und Xmx gleichsetzen.

Du kannst natürlich abschätzen, wie viel Heap Du theoretisch mindestens brauchst. Das sagt aber nur aus, dass es darunter mit Sicherheit nicht geht - mehr aber auch nicht.

 

[Thallius]

Eigentlich sollte man Appllikationen und Datenbanken immer strikt trennen. Also nicht spring boot und db server auf einer Hardware.

 

[mrBrown]

Eigentlich sollte man Appllikationen und Datenbanken immer strikt trennen. Also nicht spring boot und db server auf einer Hardware.

Eigentlich sind solche pauschalen Aussagen Unsinn

 

[Thallius]

Eigentlich sind solche pauschalen Aussagen Unsinn

Solche gute faktisch belegte aussagen sind noch größerer unsinn

 

[mrBrown]

Solche gute faktisch belegte aussagen sind noch größerer unsinn

Ich bin einer von denen, die in diesem Fall Applikation und Datenbank auf dem gleichen Server betreiben würden, Gründe dafür findet man hier: https://www.java-forum.org/thema/microservices-strukturplanung.188630/

Falls du wirklich Argumente dagegen hast, sind sowohl ich als auch alle anderen beitragenden und ganz besonders @NicoDeluxe sicherlich daran interessiert Pauschal zu empfehlen, beides strikt zu trennen, ist halt immer am wenigsten hilfreich

 

[mihe7]

Eigentlich sollte man Appllikationen und Datenbanken immer strikt trennen. Also nicht spring boot und db server auf einer Hardware.

Das ist m. E. eine "best practice" aus den Zeiten, in denen die Anwendung für den Mehrbenutzerbetrieb um den mächtigen DB-Server herum gebaut wurde (der schon so viele Ressourcen frisst, dass sowieso nichts mehr übrig bleibt) - die klassische Client-/Server-Architektur, mit teils riesigen Datenmengen und Stored Procedures und Trigger, die sich um die Logik kümmern. Da empfiehlt es sich natürlich (irgendwann), das DBMS auf separater Hardware zu halten, Tablespaces bzw. Partitionen von Tabellen und Indizes auf separate Platten zu verteilen, um die vielen Anfragen möglichst schnell beantworten zu können.

Letztlich ist das eine Optimierungsmaßnahme -> premature optimization...

Im konkrete Fall wird die DB nur von einem kleinen Service verwendet, sozusagen in einer "Einzelplatzlösung", in der es in erster Linie auch noch darum geht, einfach "viele" Sätze in kurzer Zeit an eine Tabelle einzufügen. Da bringt eine eigene Maschine doch nichts, außer, dass der Netzwerkoverhead bezahlt werden muss. Die Anwendung ist so klein, dass sie der DB eh kaum Ressourcen klaut.

 

[Thallius]

es fängt schon damit an, dass ich viel einfacher die Hardware anpassen kann wenn ich nicht zwei Applikationen (und das sind in meinen Augen Programm und Datenbank) darauf laufen lasse.
weiterhin brauche ich für einen Applikation Server kein permanentes Backup. das Backup des DB Servers gestaltet sich entsprechend einfach.
Drittens bin ich wesentlich flexibler wenn sich später mal rausstellen sollte, dass die Daten aus der dB auch für andere programme interessant ist.
das wichtigste allerdings ist, dass es keinen einzigen Nachteil gibt wenn man die Hardware trennt. Im Prinzip ist das trennen der Hardware ein physikalischer docker, nur viel einfacher zu handhaben.

 

[LimDul]

es fängt schon damit an, dass ich viel einfacher die Hardware anpassen kann wenn ich nicht zwei Applikationen (und das sind in meinen Augen Programm und Datenbank) darauf laufen lasse.
weiterhin brauche ich für einen Applikation Server kein permanentes Backup. das Backup des DB Servers gestaltet sich entsprechend einfach.
Drittens bin ich wesentlich flexibler wenn sich später mal rausstellen sollte, dass die Daten aus der dB auch für andere programme interessant ist.
das wichtigste allerdings ist, dass es keinen einzigen Nachteil gibt wenn man die Hardware trennt. Im Prinzip ist das trennen der Hardware ein physikalischer docker, nur viel einfacher zu handhaben.

Nachteile:
- Netzwerkkommunikation ist langsamer als lokale Kommunikation
- Ich hab einen Service, der dann aus 2 Teilen besteht - Der Datenbank und dem Applikation Server. Wenn ich den komplett woanders hinschieben will, muss ich beide Teile korrekt verschieben.
- Ich hab zwei Systeme die ich monitoren muss und wo ich Resourcen bereitstellen muss

Ich stimme dir zu - in den meisten Fällen überwiegen die Vorteile, aber in dem Szenario um das es gerade geht eben nicht, denn:

- Das Netzwerk scheint langsam zu sein
- Ich brauche pro Service eine eigene DB, die auch explizit nur für den Service da ist, wo kein anderer draus lesen soll (Dafür ist die bewusst nicht gedacht)
- Backup ist in dem Szenario auch Nachrangig, weil man das System so konzipieren kann, dass ein DB Crash egal ist

Ich hab am Ende einen Docker Container den ich umherschieben kann, der in sich geschlossen ist und alles enthält, was er braucht.

 

[mrBrown]

[1] es fängt schon damit an, dass ich viel einfacher die Hardware anpassen kann wenn ich nicht zwei Applikationen (und das sind in meinen Augen Programm und Datenbank) darauf laufen lasse.

Was für Änderungen nimmst du an deiner Hardware vor, dass es eine Rolle spielt, wie viele Anwendungen laufen?

[2] weiterhin brauche ich für einen Applikation Server kein permanentes Backup. das Backup des DB Servers gestaltet sich entsprechend einfach.

Warum gestaltet sich das Backup schwieriger, wenn man mehrere Anwendungen laufen hat?

Entweder man sichert den ganzen Server, dann ist es egal, oder man sichert explizit nur die Datenbank, dann ist es egal. In diesem Fall ist das Backup allerdings sogar zweitrangig.

[3] Drittens bin ich wesentlich flexibler wenn sich später mal rausstellen sollte, dass die Daten aus der dB auch für andere programme interessant ist.

Dem hier geht die ganz bewusste Architektur-Entscheidung voraus, dass die Daten auf jeden Fall nur von einer einzigen Applikation genutzt werden.

das wichtigste allerdings ist, dass es keinen einzigen Nachteil gibt wenn man die Hardware trennt.

Doch. In diesem Fall war der DB-Server auf einem anderem Server, das war allerdings zu langsam. Beides auf einem Server ist eine Lösung dafür.

Im Prinzip ist das trennen der Hardware ein physikalischer docker, nur viel einfacher zu handhaben.

"Bare Metal" und Docker sind dabei überhaupt nicht vergleichbar, Docker (bzw das Tooling drum herum) löst schon noch mehr Probleme, und ist auch beim Einsatz mehrerer getrennter Server nützlich.



Wenn überhaupt sind die ganzen Punkte Argumente für vernünftigen Tool-Einsatz.
Hardware muss angepasst werden? Bekommen die Applikationen nicht viel mit, wenn man die in VMs/Containern laufen lässt.
Anwendung muss auf einen anderen Server umgezogen werden? Backup einspielen (was im Idealfall automatisch läuft) und Anwendung starten.
DB muss aus irgendeinem Grund doch zwingend auf einem anderem Server laufen? Backup einspielen und starten.
DB ist doch für etwas anderes interessant (ergo, die gesamte Architektur wird über den Haufen geworfen)? Dann greift der andere Service halt drauf zu.

 

[mihe7]

es fängt schon damit an, dass ich viel einfacher die Hardware anpassen kann wenn ich nicht zwei Applikationen (und das sind in meinen Augen Programm und Datenbank) darauf laufen lasse.

In der Cloud Hardware anpassen?

das wichtigste allerdings ist, dass es keinen einzigen Nachteil gibt wenn man die Hardware trennt.

Mehrkosten, schlechtere Ausnutzung und Kommunikation via Netzwerk würden mir jetzt mal pauschal einfallen.