Database server

[Eggybert]

Voor mijn website draait er nu een synology DS920+ met 20gb geheugen en SSD catch samen met 3 (langzame) hardeschijven in hybride raid. Op de synology draait er nog veel meer dan alleen de website (Home assistant, mail server, synology drive, kalender,backups etc) En hij trekt dit nog redelijk goed.

Maar voor het verwerken van weer voorspellingen loop ik tegen het schrijf limiet van het systeem aan.
Elke uur is de server bezig ruim 3 miljoen datapunten te updaten in een postgris database. (duurt nu 8 minuten)
En data uit de deze database halen duurt nu +/- 2 sec per zoek opdracht.
Op zich redelijk werkbaar maar voor de toekomst misschien kijken naar iets krachtiger.

Die 3M datapunten is al behoorlijk geoptimaliseerd. (was 9+M datapunten)

Wat wil je doen met je nieuwe systeem?
Hij zal voornamelijk als database server functioneren naast de synology voor nu met de nodige docker containers.
De voorspellingen verwerken heeft meer cores toegevoegde waarde. Alle scripts die draaien zijn al multicore.

Wat mag het systeem gaan kosten?
+/- 1500 euro.

Wat denk je allemaal nodig te hebben?
Zat zelf te kijken naar de Ugreen nas dp480t als optie en deze uit te breiden met 64gb geheugen en 4x 2Tb SSD.
Of toch zelfbouw?

Heb je nog bepaalde eisen/wensen?
Beetje zuinig is altijd fijn. Hij zal 24/7 draaien.

Wat verwacht je van ons?[i]
Kwa prijs/prestatie lijkt de Ugreen nas een redelijke optie. Of zou een eigenbouw heel veel geld of extra prestatie schelen?
Kan een beetje overweg met linux maar om nou te zeggen dat ik een server zou kunnen optuigen weet ik niet. (google en chatgpt kunnen hier natuurlijk goed bij helpen)
De synology is hier wel heel makkelijk in moet ik zeggen.

Graag zou ik wat feedback ontvangen van mensen met ervaring met database servers over welke richting in te slaan.

[sOid]

Kun je toelichten waarom je geen gebruik wil maken van een VPS of cloud computing? Dat lijkt mij een logischer keuze voor de usecase.

[martyw]

Welk programma gebruik je om weersvoorspellingen te verwerken? Als ik het zo lees is het niet CPU bound, je NAS heeft een trage Intel Celeron J4125, het is de disk snelheid die je beperkt. Zoek dus inderdaad een oplossing die van SSD storage gebruik maakt. Hoe groot is die Postgres database? 3 Miljoen datapunten klinkt niet heel extreem...

[Eggybert]

sOid schreef op vrijdag 27 juni 2025 @ 11:31:
Kun je toelichten waarom je geen gebruik wil maken van een VPS of cloud computing? Dat lijkt mij een logischer keuze voor de usecase.

Omdat ik daar ook nog niet echt ervaring mee heb De rede is vooral omdat het nog thuis lukt.
De website gebruikt veel verschillende technieken, dit is ook zo gegroeid in de jaren.
Vooral de data verwerken bestaat uit een aantal verschillende scripts. (python en php)
Het is nu vooral het opslaan wat de bottleneck is.

martyw schreef op vrijdag 27 juni 2025 @ 11:36:
Welk programma gebruik je om weersvoorspellingen te verwerken? Als ik het zo lees is het niet CPU bound, je NAS heeft een trage Intel Celeron J4125, het is de disk snelheid die je beperkt. Zoek dus inderdaad een oplossing die van SSD storage gebruik maakt. Hoe groot is die Postgres database? 3 Miljoen datapunten klinkt niet heel extreem...

De KNMI notificaties komt binnen via mqtt (python script) en worden dan via andere python script verwerkt in data voor de database en verschillende afbeeldingen voor de site. Alle python script draaien samen in een docker container.

De postgris database groeit met 30K punten per uur. Maar er moeten ook 3M bestaande punten worden geüpdatet.

[DukeBox]

Ooit draaide ik alle DPC stats op een synology met een Intel Atom (DS1812+), dat waren per uur zo'n 60M+ update records in een MySQL database. Dat allemaal zonder SSD(cache), 4 HDD's in RAID10 en totaal 4GB RAM, dat was nooit een probleem ook al was de CPU 100% belast. Meestal ligt het eerder aan je database model en type table.

[Dekar]

Zelfbouw is veel sneller dan die trage off the shelf NAS apparaten. Wat vind je van zoiets?

Intel 10-core CPU (wel minder geschikt voor Plex/Jellyfin vanwege F versie)
Moederbord met plek voor 2 m.2 SSDs en 8 sata schijven
Behuizing waar tot 8 HDDs in past
Stille koeler
64GB RAM
Gold voeding
4TB SSD met Cache

#	Categorie	Product	Prijs	Subtotaal
1	Processors	Intel Core i5-14400F (SRN3R) Tray	€ 129,03	€ 129,03
1	Moederborden	Biostar B760MX2-E Pro D4	€ 111,84	€ 111,84
1	Behuizingen	Fractal Design Node 804	€ 101,99	€ 101,99
1	Processorkoeling	Arctic Freezer 36	€ 29,19	€ 29,19
1	Geheugen intern	Crucial Pro CP2K32G4DFRA32A	€ 108,99	€ 108,99
1	Voedingen	be quiet! Pure Power 11 400W	€ 59,38	€ 59,38
1	SSD's	Samsung 990 Pro (zonder heatsink) 4TB	€ 284,60	€ 284,60
			Totaal	€ 825,02

Kan evt goedkoper door i3 te nemen, moederbord met iets minder sata aansluitingen en goedkopere behuizing.

[The Eagle]

Data verwerken, zeker als het om vele datapunten gaat, doe je niet op een database backend. Dat wordt hoe dan ook een bottleneck.
Zou eerder voor iets file based achtigs kiezen, en dan delta format met spark er bovenop ofzo.

Sowieso, als ophalen 2 sec duurt qua query, kijk dan eens naar je explain plan, identificeer waar de bottleneck zit en doe daar iets aan. Zou eens beginnen met wat indexen te zetten

Dat het zo gegroeid is uit hobby maakt nog niet dat het nog steeds de juiste richting is om in te gaan

[Eggybert]

Dekar schreef op vrijdag 27 juni 2025 @ 14:29:
Zelfbouw is veel sneller dan die trage off the shelf NAS apparaten. Wat vind je van zoiets?

Intel 10-core CPU (wel minder geschikt voor Plex/Jellyfin vanwege F versie)
Moederbord met plek voor 2 m.2 SSDs en 8 sata schijven
Behuizing waar tot 8 HDDs in past
Stille koeler
64GB RAM
Gold voeding
4TB SSD met Cache

Kan evt goedkoper door i3 te nemen, moederbord met iets minder sata aansluitingen en goedkopere behuizing.

Bedankt voor de optie.

The Eagle schreef op vrijdag 27 juni 2025 @ 14:48:
Data verwerken, zeker als het om vele datapunten gaat, doe je niet op een database backend. Dat wordt hoe dan ook een bottleneck.
Zou eerder voor iets file based achtigs kiezen, en dan delta format met spark er bovenop ofzo.

Sowieso, als ophalen 2 sec duurt qua query, kijk dan eens naar je explain plan, identificeer waar de bottleneck zit en doe daar iets aan. Zou eens beginnen met wat indexen te zetten

Dat het zo gegroeid is uit hobby maakt nog niet dat het nog steeds de juiste richting is om in te gaan

Ik ga juist voor een database om spatial queries te kunnen doen op basis van locatie en tijd. (dit zijn de 2 indexen in de database)
En hiervan de regels op te vragen. de spatial queries doe ik al in een loopup table zodat hij dit niet in de grote main table hoeft te doen.

Zou ik de data uit de orginele grib file halen duurt dit +/- 15 seconden.

explain plan kende ik nog niet en ga ik zeker naar kijken.

[ Voor 21% gewijzigd door Eggybert op 27-06-2025 15:07 ]

[The Eagle]

Spatial is idd een vak apart - maar dat zei je er niet bij

DB- en querytuning tuning discrimineert niet op datatype, dus die kant zou ik eerst in gaan. Spatial kan wat zwaarder zijn, maar het is helemaal afhankelijk van wat je exact opvraagt en wanneer / hoe vaak of een index goed of slecht kan doen, ook irt het bijwerken er van. Immers, als je een insert op je tabel doet moet je ook de evt indexen updaten en ook dat kost een beetje tijd

Je noemt btw postgris; ik neem aan dat je bedoelt dat je PostgreSQL icm een PostGIS plugin gebruikt? Of alleen de DB zelf?

[Eggybert]

The Eagle schreef op vrijdag 27 juni 2025 @ 15:22:
Spatial is idd een vak apart - maar dat zei je er niet bij

DB- en querytuning tuning discrimineert niet op datatype, dus die kant zou ik eerst in gaan. Spatial kan wat zwaarder zijn, maar het is helemaal afhankelijk van wat je exact opvraagt en wanneer / hoe vaak of een index goed of slecht kan doen, ook irt het bijwerken er van. Immers, als je een insert op je tabel doet moet je ook de evt indexen updaten en ook dat kost een beetje tijd

Je noemt btw postgris; ik neem aan dat je bedoelt dat je PostgreSQL icm een PostGIS plugin gebruikt? Of alleen de DB zelf?

Het is inderdaat een PostgreSQL met Postgis plugin

Explain heeft me het beste geholpen.
Data ophalen duurt nu maar 73ms en in de database schrijven is nu terug naar iets onder 4 minuten
Dit is voor nu prima werkbaar. Dank je wel

[The Eagle]

Met 1 zin 1500 euro besparen. Gotta love my job

Protip: alles, maar dan ook alles wat je aan keys gebruikt om dingen te lezen, een index op zetten. Je DBMS regelt dan de rest
Geldt ook voor batch jobs waarbij je op basis van iets bestaands moet selecteren uiteraard - das ook lezen

[ Voor 28% gewijzigd door The Eagle op 29-06-2025 20:05 ]

[FrankHe]

De grap is dat zo'n quad core Celeron met een sloot RAM nog best prima prestaties laat zien. Vergelijkbaar met of sneller dan menig dikke server van 20 jaar geleden. Het OS en de database maken over het algemeen slim gebruik van al dat beschikbare geheugen. Lezen kan flink verbeteren met de juiste indexen. Bij schrijfacties is het inderdaad een kwestie van zaken in batches verwerken en de indexen naderhand bijwerken. Zelfs met SATA HDD's kun je nog hele acceptabele hoeveelheden data verstouwen.

Een XEON CPU met quad channel geheugen en NVMe SSD is natuurlijk fijn om te hebben maar in veel gevallen helemaal niet nodig.