Home · Servers for big data workloads
Workload guide
Servers for big data workloads
Big data platforms are storage systems that compute: the node design balances processor throughput against local drive capacity, and the wrong balance strands one or the other. This guide works through the balance from our server and storage range.
Balance is the whole design
A data node that out-computes its disks idles expensive cores; a node that out-stores its processors turns scans into overnight jobs. The practical design starts from the working set: how much data is hot, how it is distributed, and what a full scan must cost in time. From there the node splits into a compute shape (2U dual-socket, moderate local capacity) and a capacity shape (storage-dense, drives first).
Our storage range enters the same design from the other side: a SAN or hybrid flash array centralises the hot tier while nodes keep bulk local capacity. Estates that outgrow node-local storage usually land on that hybrid shape.
Drives decide the capacity tier
The drive pages carry the two anchor lines — 4 TB SATA enterprise drives for bulk capacity and 12 TB SAS drives for dense pools. In a data estate the drive decision is a fleet decision, repeated hundreds of times; getting the interface and form factor right once, in writing, is worth more than any per-drive saving.
What to send
- Total data volume and its growth rate.
- The hot working set — the share scanned daily.
- Whether the platform is node-local (Hadoop-style) or shared-storage based.
The scan test: sizing by the query that hurts
Big data estates should be sized against their worst regular query, not their average load. The full-table scan, the end-of-month aggregation, the reindex that runs while the business sleeps — those are the workloads that decide whether the platform feels fast or broken, and they are storage-and-memory events more than processor events. State the painful query in the inquiry, with its data volume and its deadline; node balance follows from it more honestly than from any generic ratio.
Growth compounds the point. Data platforms rarely shrink, and the node design chosen today becomes the template every expansion copies. A balance that wastes twenty percent of its processors wastes them at fleet scale within two years — the sizing pass is the cheapest performance the platform will ever buy.
A note on refresh cycles
Data platforms refresh in layers, not in events: drives first, because capacity demand is relentless; nodes second, as processor generations justify themselves; the layout — local against shared — last, because it is the hardest to change. A purchase that knows its layer refreshes cheaply. Drives bought to the fleet's standard interface and form factor slot into the next node generation as readily as this one, which is why the drive decision deserves its reputation as the platform decision in disguise.
The short version
Balance the node against the working set, buy drives as a fleet decision, and let the hot tier's size choose between local storage and an array. State the data volume, the growth rate and the painful query in the inquiry, and the configuration that comes back will already embody the balance this guide describes — which is the difference between a platform and a pile of parts.
Questions buyers ask
Should big data nodes have GPUs?
Only where the pipeline has a GPU stage — some ETL and most ML feature work. Otherwise the budget belongs in drives and memory.
Can storage and nodes be quoted together?
Yes — nodes, arrays and drives for one platform are quoted as one configuration.
Price a configuration like this
Send the model name, your target configuration and the delivery destination. We reply with a configuration-matched quote and the checks to run before shipment.