Why MCS Means Rapid In-Memory Computing Adoption

What does the relatively new acronym MCS have to do with the accelerated adoption of in-memory computing? I’d say everything.

MCS stands for Memory Channel Storage and it essentially allows you to put NAND flash storage into a DIMM form factor and enable it to interface with a CPU via a standard memory controller. Put another way, MCS provides a drop-in replacement for DDR3 RDIMMs with 10x the memory capacity and a 10x reduction in price.

Historically, one of the major inhibitors behind in-memory computing adoption was the high cost of DRAM relative to disks and flash storage. While advantages such as 100x performance, lower power consumption and higher reliability were clearly known for years, the price delta was and is still relatively high:

Storage ~ Performance ~ Price
1TB MCS 20-200x TBD ~$5,000
1TB DDR3 RDIMM (32 DIMMs) 1000-10,000x $20,000
1TB PCI-E 10-100x $5,000
1TB SSD 10-100x $1,000
1TB HDD 1x $100

While spinning HDDs are essentially cost-free for enterprise consumption, and flash storage is enjoying mass adoption, DRAM storage still lags behind simply due to higher cost.

MCS-based storage is about to change this once and for all as it aims to bring the price of flash-based DRAM to the same level as today’s SSD and PCI-E flash storage.

MCI vs. PCI-E Flash

If prices are relatively similar between MCS and PCI-E storage, what makes MCS so much more important? The answer is direct memory access vs. block-based device.

All of the PCI-E flash storage today (FusionIO, Violin, basic SSDs, etc.) are recognized by the OS as block devices, i.e. essentially fast hard drives. Applications access these devices via typical file interface involving all typical marshaling, buffering, OS context switching, networking and IO overhead.

MCS provides an option to view its flash storage simply as main system memory, eliminating all the OS/IO/network overhead, while working directly via a highly optimized memory controller – the same controller that handles massive CPU-DDR3 data exchange – and enabling software like GridGain’s to access the flash storage as normal memory. This is a game changer and potentially a final frontier in the storage placement technology. In fact, you can’t place application data any closer to the CPU than the main memory and that is precisely what MCI enables us to do on terabyte and petabyte scale.

Moreover, MCS provides direct improvements over PCI-E storage. Diablo Technology, the pioneer behind MCS technology, claims that MCS is more performant (lower latencies and higher bandwidth) than typical PCI-E and SATA SSDs while providing ever elusive constant latency that is unachievable with standard PCE-E or SSD technologies.

Plug-n-Play

Another important characteristic of MCS storage is the plug-n-play fashion in which it can be used – no custom hardware, no custom software required. Imagine, for example, an array of 100 micro-servers (ARM-based servers in micro form factor), each with 256GB of MCI-based system memory, drawing less than 10 watts of power, costing less than $1000 each.

You now have a cluster with 25TB in-memory storage, 200 cores of processing power, running standard Linux, drawing around 1000 watts for about the same cost as a fully loaded Tesla Model S. Put GridGain’s In-Memory Computing Stack on it and you have an eco-friendly, cost effective, powerful real-time big data cluster ready for any task.

Welcome to the future.

Debunking DRAM vs. Flash Controversy vis-a-vis In-Memory Processing

Debunking DRAM vs. Flash Controversy vis-a-vis In-Memory Processing

Wikibon produced an interesting material (looks like paid by Aerospike, NoSQL database recently emerged by resurrecting failed CitrusLeaf and acquihiring AlchemyDB, which product, of course, was recommended in the end) that compares NoSQL databases based on storing data in flash-based SSD vs. storing data in DRAM.

There are number of factual problems with that paper and I want to point them out.

Note that Wikibon doesn’t mention GridGain in this study (we are not a NoSQL datastore per-se after all) so I don’t have any bone in this game other than annoyance with biased and factually incorrect writing.

“Minimal” Performance Advantage of DRAM vs SSD

The paper starts with a simple statement “The minimal performance disadvantage of flash, relative to main memory…”. Minimal? I’ve seen number of studies where performance difference between SSDs and DRAM range form 100 to 10,000 times. For example, this University of California, Berkeley study claims that SSD bring almost no advantage to the Facebook Hadoop cluster and DRAM pre-caching is the way forward.

Let me provide even shorter explanation. Assuming we are dealing with Java – SSD devices are visible to Java application as typical block devices, and therefore accessed as such. It means that a typical object read from such device involves the same steps as reading this object from a file: hardware I/O subsystem, OS I/O subsystem, OS buffering, Java I/O subsystem & buffering, Java deserialization and induced GC. And… if you read the same object from DRAM – it involves few bytecode instructions – and that’s it.

Native C/C++ apps (like MongoDB) can take a slightly quicker route with memory mapped files (or various other IPC methods) – but the performance increase will not be significant (for obvious reason of needing to read/swap the entire pages vs. single object access pattern in DRAM).

Yet another recent technical explanation of the disadvantages of SSD storage can be found here (talking about Oracle’s “in-memory” strategy).

MongoDB, Cassandra, CouchDB DRAM-based?

Amid all the confusion on this topic it’s no wonder the author got it wrong. Neither MongoDB, Cassandra or CouchDB are in-memory systems. They are disk-based systems with support for memory caching. There’s nothing wrong with that and nothing new – every database developed in the last 25 years naturally provides in-memory caching to augment it’s main disk storage.

The fundamental difference here is that in-memory data systems like GridGain, SAP HAHA, GigaSpaces, GemFire, SqlFire, MemSQL, VoltDB, etc. use DRAM (memory) as the main storage medium and use disk for optional durability and overflow. This focus on RAM-based storage allows to completely re-optimized all main algorithms used in these systems.

For example, ACID implementation in GridGain that provides support for full-featured distributed ACID transactions beats every NoSQL database (EC-based) out there in read and even write performance: there are no single key limitations, no consistency trade offs to make, no application-side MVCC, no user-based conflict resolutions or other crutches – it just works the same way as it works in Oracle or DB2 – but faster.

2TB Cluster for $1.2M 🙂

If there was on piece in the original paper that was completely made up to fit the predefined narrative it was a price comparison. If the author thinks that 2TB RAM cluster costs $1.2M today – I have not one but two Golden Gate bridges to sell just for him…

Let’s see. A typical Dell/HP/IBM/Cisco blade with 256GB of DRAM will cost below $20K if you just buy on the list prices (Cisco seems to offer the best prices starting at around $15K for 256GB blades). That brings the total cost of 2TB cluster well below $200K (with all network and power equipment included and 100s TBs of disk storage).

Is this more expensive that SSD only cluster? Yes, by 2.5-3x times more expensive. But you are getting dramatic performance increase with the right software that more than justifies that price increase.

Conclusion

2-3x times price difference is nonetheless important and it provides our customers a very clear choice. If price is an issue and high performance is not – there are disk-based systems of wide varieties. If high performance and sub-second response on processing TBs of data is required – the hardware will be proportionally more expensive.

However, with 1GB of DRAM costing less than 10 USD and DRAM prices dropping 30% every 18 months – the era of disks (flash or spinning) is clearly coming to its logical end. It’s normal… it’s a progress and we all need to learn how to adapt.

Has anyone seen tape drives lately?