As any fast growing technology In-Memory Computing has attracted a lot of interest and writing in the last couple of years. It’s bound to happen that some of the information gets stale pretty quickly - while other is simply not very accurate to being with. And thus myths are starting to grow and take hold.
I want to talk about some of the misconceptions that we are hearing almost on a daily basis here at GridGain and provide necessary clarification (at least from our our point of view). Being one of the oldest company working in in-memory computing space for the last 7 years we’ve heard and seen all of it by now - and earned a certain amount of perspective on what in-memory computing is and, most importantly, what it isn’t.
Let’s start at... the beginning. What is the in-memory computing? Kirill Sheynkman from RTP Ventures gave the following crisp definition which I like very much:
“In-Memory Computing is based on a memory-first principle utilizing high-performance, integrated, distributed main memory systems to compute and transact on large-scale data sets in real-time - orders of magnitude faster than traditional disk-based systems.”
The most important part of this definition is “memory-first principle”. Let me explain...
Memory-first principle (or architecture) refers to a fundamental set of algorithmic optimizations one can take advantage of when data is stored mainly in Random Access Memory (RAM) vs. in block-level devices like HDD or SSD.
RAM has dramatically different characteristics than block-level devices including disks, SSDs or Flash-on-PCI-E arrays. Not only RAM is ~1000x times faster as a physical medium, it completely eliminates the traditional overhead of block-level devices including marshaling, paging, buffering, memory-mapping, possible networking, OS I/O, and I/O controller.
Let’s look at example: say you need to read a single record in your program.
In in-memory context your code will be compiled to interact with memory controller and read it directly from local RAM in the exact format you need (i.e. your object representation in particular programming language) - in most cases that will result in a simple pointer arithmetic. If you use proper vectorized execution technique - you’ll often read it from L2 cache of your CPUs. All in all - we are talking about nanoseconds and this performance is guaranteed for all cases.
If you read the same record form block-level device - you are in for a very different ride... Your code will have to deal with OS I/O, buffered read, I/O controller, seek time of the device, and de-marshaling back the byte stream that you get from it to an object representation that you actually need. In worst case scenario - we’re talking dozen milliseconds. Note that SSDs and Flash-on-PCI-E only improves portion of the overhead related to seek time of the device (and only marginally).
Taking advantage of these differences and optimizing your software accordingly - is what memory-first principle is all about.
Now, let’s get to the myths.
This is one of the most enduring myths of in-memory computing. Today - it’s simply not true. Five or ten years ago, however, it was indeed true. Look at the historical chart of USD/MB storage pricing to see why:
The interesting trend is that price of RAM is dropping 30% every 12 months or so and is solidly on the same trajectory as price of HDD which is for all practical reasons is almost zero (enterprises care more today about heat, energy, space than a raw price of the device).
The price of 1TB RAM cluster today is anywhere between $20K and $40K - and that includes all the CPUs, over petabyte of disk based storage, networking, etc. CIsco UCS, for example, offers very competitive white-label blades in $30K range for 1TB RAM setup: http://buildprice.cisco.com/catalog/ucs/blade-server Smart shoppers on eBay can easily beat even the $20K price barrier (as we did at GridGain for our own recent testing/CI cluster).
In a few years from now the same 1TB TAM cluster setup will be available for $10K-15K - which makes it all but commodity at that level.
And don’t forget about Memory Channel Storage (MCS) that aims to revolutionize storage by providing the Flash-in-DIMM form factor - I’ve blogged about it few weeks ago.
This myths is based on a deep rooted misunderstanding about in-memory computing. Blame us as well as other in-memory computing vendors as we evidently did a pretty poor job on this subject.
The fact of the matter is - almost all in-memory computing middleware (apart from very simplistic ones) offer one or multiple strategies for in-memory backups, durable storage backups, disk-based swap space overflow, etc.
More sophisticated vendors provide a comprehensive tiered storage approach where users can decide what portion of the overall data set is stored in RAM, local disk swap space or RDBMS/HDFS - where each tier can store progressively more data but with progressively longer latencies.
Yet another source of confusion is the difference between operational datasets and historical datasets. In-memory computing is not aimed at replacing enterprise data warehouse (EDW), backup or offline storage services - like Hadoop, for example. In-memory computing is aiming at improving operational datasets that require mixed OLTP and OLAP processing and in most cases are less than 10TB in size. In other words - in-memory computing doesn’t suffer from all-or-nothing syndrome and never requires you to keep all data in memory.
If you consider the totally of the data stored by any one enterprise - the disk still has a clear place as a medium for offline, backup or traditional EDW use cases - and thus the durability is there where it always has been.
The variations of this myth include the following:
Mounting RAM disk is a very poor way of utilizing memory from every technical angle (see above).
As far as SSDs - for some uses cases - the marginal performance gain that you can extract from flash storage over spinning disk could be enough. In fact - if you are absolutely certain that the marginal improvements is all you ever need for a particular application - the flash storage is the best bet today.
However, for a rapidly growing number of use cases - speed matters. And it matters more and for more businesses every day. In-memory computing is not about marginal 2-3x improvement - it is about giving you 10-100x improvements enabling new businesses and services that simply weren’t feasible before.
There’s one story that I’ve been telling for quite some time now and it shows a very telling example of how in-memory computing relates to speed...
Around 6 years ago GridGain had a financial customer who had a small application (~1500 LOC in Java) that took 30 seconds to prepare a chart and a table with some historical statistical results for a given basket of stocks (all stored in Oracle RDBMS). They wanted to put it online on their website. Naturally, users won’t wait for half a minute after they pressed the button - so, the task was to make it around 5-6 seconds. Now - how do you make something 5 times faster?
We initially looked at every possible angle: faster disks (even SSD which were very expensive then), RAID systems, faster CPU, rewriting everything in C/C++, running on different OS, Oracle RAC - or any combination of thereof. But nothing would make an application run 5x faster - not even close... Only when we brought the the dataset in memory and parallelized the processing over 5 machines using in-memory MapReduce - we were able to get results in less than 4 seconds!
The morale of the story is that you don’t have to have NASA-size problem to utilize in-memory computing. In fact, every day thousands of businesses solving performance problem that look initially trivial but in the end could only be solved with in-memory computing speed.
Speed also matters in the raw sense as well. Look at this diagram from Stanford about relative performance of disks, flash and RAM:
As DRAM closes its pricing gap with flash such dramatic difference in raw performance will become more and more pronounced and tangible for business of all sizes.
This is one of those mis-conceptions that you hear mostly from analysts. Most analysts look at SAP HANA, Oracle Exalytics or something like QlikView - and they conclude that this is all that in-memory computing is all about, i.e. database or in-memory caching for faster analytics.
There’s a logic behind it, of course, but I think this is rather a bit shortsighted view.
First of all, in-memory computing is not a product - it is a technology. The technology is used to built products. In fact - nobody sells just “in-memory computing” but rather products that are built with in-memory computing.
I also think that in-memory databases are important use case... for today. They solve a specific use case that everyone readily understands, i.e. faster system of records. It’s sort of a low hanging fruit of in-memory computing and it gets in-memory computing popularized.
I do, however, think that the long term growth for in-memory computing will come from streaming use cases. Let me explain.
Streaming processing is typically characterized by a massive rate at which events are coming into a system. Number of potential customers we’ve talked to indicated to us that they need to process a sustained stream of up to 100,000 events per second with out a single event loss. For a typical 30 seconds sliding processing window we are dealing with 3,000,000 events shifting by 100,000 every second which have to be individually indexed, continuously processed in real-time and eventually stored.
This downpour will choke any disk I/O (spinning or flash). The only feasible way to sustain this load and corresponding business processing is to use in-memory computing technology. There’s simply no other storage technology today that support that level of requirements.
So we strongly believe that in-memory computing will reign supreme in streaming processing.
I want to talk about some of the misconceptions that we are hearing almost on a daily basis here at GridGain and provide necessary clarification (at least from our our point of view). Being one of the oldest company working in in-memory computing space for the last 7 years we’ve heard and seen all of it by now - and earned a certain amount of perspective on what in-memory computing is and, most importantly, what it isn’t.
In-Memory Computing
Let’s start at... the beginning. What is the in-memory computing? Kirill Sheynkman from RTP Ventures gave the following crisp definition which I like very much:
“In-Memory Computing is based on a memory-first principle utilizing high-performance, integrated, distributed main memory systems to compute and transact on large-scale data sets in real-time - orders of magnitude faster than traditional disk-based systems.”
The most important part of this definition is “memory-first principle”. Let me explain...
Memory-First Principle
Memory-first principle (or architecture) refers to a fundamental set of algorithmic optimizations one can take advantage of when data is stored mainly in Random Access Memory (RAM) vs. in block-level devices like HDD or SSD.
RAM has dramatically different characteristics than block-level devices including disks, SSDs or Flash-on-PCI-E arrays. Not only RAM is ~1000x times faster as a physical medium, it completely eliminates the traditional overhead of block-level devices including marshaling, paging, buffering, memory-mapping, possible networking, OS I/O, and I/O controller.
Let’s look at example: say you need to read a single record in your program.
In in-memory context your code will be compiled to interact with memory controller and read it directly from local RAM in the exact format you need (i.e. your object representation in particular programming language) - in most cases that will result in a simple pointer arithmetic. If you use proper vectorized execution technique - you’ll often read it from L2 cache of your CPUs. All in all - we are talking about nanoseconds and this performance is guaranteed for all cases.
If you read the same record form block-level device - you are in for a very different ride... Your code will have to deal with OS I/O, buffered read, I/O controller, seek time of the device, and de-marshaling back the byte stream that you get from it to an object representation that you actually need. In worst case scenario - we’re talking dozen milliseconds. Note that SSDs and Flash-on-PCI-E only improves portion of the overhead related to seek time of the device (and only marginally).
Taking advantage of these differences and optimizing your software accordingly - is what memory-first principle is all about.
Now, let’s get to the myths.
Myth #1: It’s Too Expensive
This is one of the most enduring myths of in-memory computing. Today - it’s simply not true. Five or ten years ago, however, it was indeed true. Look at the historical chart of USD/MB storage pricing to see why:
The interesting trend is that price of RAM is dropping 30% every 12 months or so and is solidly on the same trajectory as price of HDD which is for all practical reasons is almost zero (enterprises care more today about heat, energy, space than a raw price of the device).
The price of 1TB RAM cluster today is anywhere between $20K and $40K - and that includes all the CPUs, over petabyte of disk based storage, networking, etc. CIsco UCS, for example, offers very competitive white-label blades in $30K range for 1TB RAM setup: http://buildprice.cisco.com/catalog/ucs/blade-server Smart shoppers on eBay can easily beat even the $20K price barrier (as we did at GridGain for our own recent testing/CI cluster).
In a few years from now the same 1TB TAM cluster setup will be available for $10K-15K - which makes it all but commodity at that level.
And don’t forget about Memory Channel Storage (MCS) that aims to revolutionize storage by providing the Flash-in-DIMM form factor - I’ve blogged about it few weeks ago.
Myth #2: It’s Not Durable
This myths is based on a deep rooted misunderstanding about in-memory computing. Blame us as well as other in-memory computing vendors as we evidently did a pretty poor job on this subject.
The fact of the matter is - almost all in-memory computing middleware (apart from very simplistic ones) offer one or multiple strategies for in-memory backups, durable storage backups, disk-based swap space overflow, etc.
More sophisticated vendors provide a comprehensive tiered storage approach where users can decide what portion of the overall data set is stored in RAM, local disk swap space or RDBMS/HDFS - where each tier can store progressively more data but with progressively longer latencies.
Yet another source of confusion is the difference between operational datasets and historical datasets. In-memory computing is not aimed at replacing enterprise data warehouse (EDW), backup or offline storage services - like Hadoop, for example. In-memory computing is aiming at improving operational datasets that require mixed OLTP and OLAP processing and in most cases are less than 10TB in size. In other words - in-memory computing doesn’t suffer from all-or-nothing syndrome and never requires you to keep all data in memory.
If you consider the totally of the data stored by any one enterprise - the disk still has a clear place as a medium for offline, backup or traditional EDW use cases - and thus the durability is there where it always has been.
Myth #3: Flash Is Fast Enough
The variations of this myth include the following:
- Our business doesn’t need this super-fast processing (likely shortsighted)
- We can mount RAM disk and effectively get in-memory processing (wrong)
- We can replace HDDs with SSDs to get the performance (depends)
Mounting RAM disk is a very poor way of utilizing memory from every technical angle (see above).
As far as SSDs - for some uses cases - the marginal performance gain that you can extract from flash storage over spinning disk could be enough. In fact - if you are absolutely certain that the marginal improvements is all you ever need for a particular application - the flash storage is the best bet today.
However, for a rapidly growing number of use cases - speed matters. And it matters more and for more businesses every day. In-memory computing is not about marginal 2-3x improvement - it is about giving you 10-100x improvements enabling new businesses and services that simply weren’t feasible before.
There’s one story that I’ve been telling for quite some time now and it shows a very telling example of how in-memory computing relates to speed...
Around 6 years ago GridGain had a financial customer who had a small application (~1500 LOC in Java) that took 30 seconds to prepare a chart and a table with some historical statistical results for a given basket of stocks (all stored in Oracle RDBMS). They wanted to put it online on their website. Naturally, users won’t wait for half a minute after they pressed the button - so, the task was to make it around 5-6 seconds. Now - how do you make something 5 times faster?
We initially looked at every possible angle: faster disks (even SSD which were very expensive then), RAID systems, faster CPU, rewriting everything in C/C++, running on different OS, Oracle RAC - or any combination of thereof. But nothing would make an application run 5x faster - not even close... Only when we brought the the dataset in memory and parallelized the processing over 5 machines using in-memory MapReduce - we were able to get results in less than 4 seconds!
The morale of the story is that you don’t have to have NASA-size problem to utilize in-memory computing. In fact, every day thousands of businesses solving performance problem that look initially trivial but in the end could only be solved with in-memory computing speed.
Speed also matters in the raw sense as well. Look at this diagram from Stanford about relative performance of disks, flash and RAM:
As DRAM closes its pricing gap with flash such dramatic difference in raw performance will become more and more pronounced and tangible for business of all sizes.
Myth #4: It’s About In-Memory Databases
This is one of those mis-conceptions that you hear mostly from analysts. Most analysts look at SAP HANA, Oracle Exalytics or something like QlikView - and they conclude that this is all that in-memory computing is all about, i.e. database or in-memory caching for faster analytics.
There’s a logic behind it, of course, but I think this is rather a bit shortsighted view.
First of all, in-memory computing is not a product - it is a technology. The technology is used to built products. In fact - nobody sells just “in-memory computing” but rather products that are built with in-memory computing.
I also think that in-memory databases are important use case... for today. They solve a specific use case that everyone readily understands, i.e. faster system of records. It’s sort of a low hanging fruit of in-memory computing and it gets in-memory computing popularized.
I do, however, think that the long term growth for in-memory computing will come from streaming use cases. Let me explain.
Streaming processing is typically characterized by a massive rate at which events are coming into a system. Number of potential customers we’ve talked to indicated to us that they need to process a sustained stream of up to 100,000 events per second with out a single event loss. For a typical 30 seconds sliding processing window we are dealing with 3,000,000 events shifting by 100,000 every second which have to be individually indexed, continuously processed in real-time and eventually stored.
This downpour will choke any disk I/O (spinning or flash). The only feasible way to sustain this load and corresponding business processing is to use in-memory computing technology. There’s simply no other storage technology today that support that level of requirements.
So we strongly believe that in-memory computing will reign supreme in streaming processing.