The title has got a question mark for a reason this time, since using ARM architecture could mean a lot of things, varying from super-low-power milliwatt range Arduinos to Raspberry Pis, ending with specialized supercomputing clusters. The common denominator here is still efficiency. ARM architecture is designed to be very efficient and to save money on TCO in the end, compared to traditional servers. From the reliability point-of-view, there is no problem at all. I know I could sleep peacefully even when running my pet project’s database on a Raspberry Pi (given there is a backup). But what about performance? Could Postgres-on-ARM be a viable option for more demanding projects where performance still matters a bit? The fuzzy answer - yes it can well be. First, allow me to introduce the M2DC project.
Table of Contents
During a recent conference, we came into contact with people working on an interesting hardware project called M2DCÂ - the Modular Microserver Data Centre.
In short, the project is a joint effort of many companies (supported by the European Union!). It is centered on building modular and scalable ARM-based general purpose server clusters that will reduce the TCO of servers by 50% in comparison to traditional approaches. Please read more about the project and participating companies here.
Now you may ask, "How does PostgreSQL come into play?" Well, PostgreSQL is one of the few RDBMS's that runs nicely on ARM architecture! And since the hardware specs looked intriguing (a cluster built on 4-core 2.2GHz Tegra modules), we were eager to see what it means in the real life.
After getting access to a demo system and testing the Postgres basics on it, we thought we’d document the process and the results in a nice PDF format for easier digestion. So if you'd like to actually get all the details and pictures of the hardware, as well as get a better idea of what we’re talking about and what was tested plus see the numerical results, please see the PDF below.
As for a conclusion – it's difficult as always, especially since the cluster is at its best when it comes to specialized applications (I compared it against a mainstream Amazon AWS instance). We had to leave out write tests due to slow disks. In the end, I was still surprised by the Bang-for-Buck (Performance-per-Watt) ratio. The ARM approach could pay off big-time monetarily, for example for data acquiring tasks that don’t require too many parallel database operations on a single cluster node.
But as I said, more info here:
In order to receive regular updates on important changes in PostgreSQL, subscribe to our newsletter, or follow us on Twitter, Facebook, or LinkedIn.
+43 (0) 2622 93022-0
office@cybertec.at
You need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Facebook. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from X. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More Information
It would be nice to see if you manage to run pgstrom on this setup indeed.
we did not try pgstrom. i think it would not work either because you don't have enough RAM to feed the GPUs with anything useful and storage sucks badly
Something like CitusDB would sing on a cluster of ARM processors tightly coupled with storage, e.g. Igneous, Seagate Kinetic or OpenIO.
no, it would not. storage on this box is WAYS to slow (it would need a dedicated SSD per node). in addition to that: we tried citus and figured that it is HIGHLY limited in what it can do. it can only handle fairly simple straight plans. any kind of windowing or so simply does not work. so, it would not sing. not enough RAM, not enough I/O and limited capabilities. those 100 ARM cores are not even the equivalent of a 32 core Intel box ... on top of that: think of management overhead of managing 24 nodes vs 1 server (things suchs a failover and so on). in short: no way you would be happy ...
The 'more info' PDF link leads to a 404 page.