3 ms·
> for workloads that are processing multi-gigabytes rather than terabyte+ scale, a big-memory server may well provide better performance per dollar than a clust
by kijin 14y ago
> for workloads that are processing multi-gigabytes rather than terabyte+ scale, a big-memory server may well provide better performance per dollar than a cluster.
Does the "performance per dollar" take into account the devastating damage that a single, very powerful server would cause if it ever went down?
With 1 server that can process terabytes of data, you're either processing terabytes of data or zero bytes of data. Redundancy would be difficult to achieve, not only because the hardware is expensive, but also because your software was designed to work best on a single server.
With 1000 servers that can process gigabytes of data each, you're always processing terabytes of data even if a few servers go down from time to time. Redundancy is already built in.
If you put all your hard drives in RAID 10, you need twice the hard drives as your storage needs. If you put them all in RAID 5/6 instead, you only fewer hard drives but you'll get a similar level of overall reliability. With hard drives, of course, there would be a significant difference in performance. With CPU cores, on the other hand, the difference would be smaller.
- jacques_chester 14y agoI think you're conflating throughput with availability. They are distinct non-functional requirements and they should be considered and architected for distinctly.
- kijin 14y agoThroughput is different from availability, and I'm not conflating them. But they are not completely unrelated, either. All I'm saying is that it might turn out to be more expensive to design high-availability architectures using a small number of high-throughput servers than it is to design one using a large number of low-throughput servers. Sometimes this doesn't matter because you only need to crunch data a few times a week. Other times, you need 99.99% uptime.