In-Memory Computing Blogs and Events

IMCPlanet.org presents in-memory computing blogs and events from around the world. Read the latest in-memory computing news here. Submit your RSS feed or post your upcoming events and help the in-memory computing community stay up to date on the latest developments.

Sep
17
2014
Posted by Distributed Thoughts on Wednesday 17 September 2014, 21:37

Generally, persistent disk-oriented systems will require the additional 3rd phase in commit protocol in order to ensure data consistency in case of failures. In my previous blog I covered why the 2-Phase-Commit protocol (without 3rd phase) is sufficient to handle failures for distributed in-memory caches. The explanation was based on the open source GridGain architecture, however it can be applied to any in-memory distributed system.In this blog we will cover a case when an in-memory cache serves as a layer on top of a persistent database. In this case the database serves as a primary system of records, and distributed in-memory cache is added for performance and scalability reasons to accelerate reads and (sometimes) writes to the data. Cache must be kept consistent with database which means that a cache transaction must merge with the database…

Sep
17
2014
Posted by Distributed Thoughts on Wednesday 17 September 2014, 21:36

In my previous blogs I have talked at length about 2-Phase-Commit transaction protocol for in memory caches, and how in-memory caches can handle failures a lot more efficiently than disk-based databases. In this blog I want to cover yet another very important optimization that can be utilized for in-memory caches, specifically for cases where data is partitioned across the network.In-memory caches, and specifically in-memory data grids, such as GridGain or Oracle Coherence, often employ a technique called data partitioning, where every key in the…

Sep
17
2014
Posted by Distributed Thoughts on Wednesday 17 September 2014, 21:36

If you prefer a video demo with coding examples, skip to the screencast at the bottom of this blog.Distributed In-Memory Caching generally allows you to replicate or partition your data in memory across your cluster. Memory provides a much faster access to the data, and by utilizing multiple cluster nodes the performance and scalability of the application increases significantly.Majority of the products that do distributed caching call themselves In-Memory Data Grids. On top of simply providing hash-table-like access to your data, a data grid product should provide some combination of the following features:

  • Clustering
  • Distributed Messaging
  • Distributed Event Notifications
  • Distributed ACID Transactions
  • Distributed Locks
Sep
17
2014
Posted by Distributed Thoughts on Wednesday 17 September 2014, 21:33

Since the G1 (garbage-first) garbage collector has been released, there were expectations that it would finally perform better for larger heap sizes (>16GB). Unfortunately those expectations were not met. While G1 garbage collector is meant to remove larger GC pauses, the sporadic and unpredictable behavior of G1 collector on larger heaps renders it generally unusable for any system sensitive to performance SLAs.At GridGain, having worked on a distributed caching (data grid) product for many years, we constantly benchmark with various Garbage Collectors to find the optimal configuration for larger heap sizes. From conducting numerous tests, we have concluded that unless you are utilizing some off-heap technology (e.g. GridGain OffHeap), no Garbage Collector provided with JDK will render any…

Sep
17
2014
Posted by Distributed Thoughts on Wednesday 17 September 2014, 21:31

2-Phase-Commit is probably one of the oldest consensus protocols and is known for its deficiencies when it comes to handling failures, as it may indefinitely block the servers waiting in prepare state. To mitigate this, a 3-Phase-Commit protocol was introduced which adds better fault tolerance at the expense of extra network round-trip message and higher latencies. I would like to extend these traditional quorum concepts into distributed in-memory caching, as it is particularly relevant to what we do at GridGain. GridGain too has 2-phase-commit transactions, but unlike disk-based persistent systems, GridGain does not need to add a 3rd phase to the commit protocol in order to preserve data consistency during failures. 

We want to avoid the 3-Phase-Commit protocol because it adds an additional network round-trip and has a negative impact on latencies and performance.

In GridGain, the data is partitioned in…

Jul
03
2014
Posted by Distributed Thoughts on Thursday 3 July 2014, 19:40

For those who are not familiar with GridGain, it is an open source distributed data grid product mainly focusing on distributed in-memory caching,  distributed computations, and streaming. It generally addresses all sorts of performance and scalability challenges for business applications by bringing and caching data in memory and allowing to compute on it.With release 6.1.9, GridGain significantly simplified its installation and deployment. GridGain now allows for:

  1. One Click Installation:The product simply has to be downloaded and unzipped. After that it is ready to be used.
  2. One Jar Dependency:GridGain now has only one mandatory dependency - gridgain-6.1.9.jar. All other jars are optional.

Essentially, you still have support for the same set of features, like Spring configuration, or…

May
20
2014
Posted by Distributed Thoughts on Tuesday 20 May 2014, 13:46

If you don't like to read and prefer video demos, you can skip directly to the Screencast at the bottom of this post.What do Clustering frameworks really do? More often than not clustering frameworks will provide capability to auto-discover servers on the network, share resources, and schedule tasks. Some will also add distributed messaging and distributed event notification capabilities.While there are some well known clustering frameworks, like Zookeeper or Mesos, they usually provide very rudimentary clustering capabilities. However, often on top of basic clustering, you also need to perform MapReduce computations, distribute closures, or distribute data. For cases like these, Compute Grids (a.k.a. High Performance Computing Grids) or Data Grids become…

May
14
2014
Posted by Distributed Thoughts on Wednesday 14 May 2014, 12:23

I am pleased to announce that GridGain 6.1.0 has been released today. This is the first main upgrade since GridGain 6.0.0 was released in February and contains some cool new functionality and performance improvements:

Support for JDK8

With GridGain 6.1.0 you can execute JDK8 closures and functions in distributed fashion on the grid:try (Grid grid = GridGain.start()) { grid.compute().broadcast((GridRunnable)() -> System.out.println("Hello World")).get();}

Geospatial Indexes

GridGain allows to easily query in-memory data in SQL using in-memory indexes. Now you can extend SQL to geospatial queries. For example, query below will find all points on the map within a certain square region:Polygon square = factory.createPolygon(new Coordinate[] { new Coordinate(0, 0), new Coordinate(…

Apr
17
2014
Posted by Distributed Thoughts on Thursday 17 April 2014, 15:07

Having spoken with many customers evaluating our product I am noticing that a majority of folks evaluating in-memory computing, whether it be data grid, map reduce, or streaming, do not know how to appropriately perform benchmarking. The right approach to distributed in-memory benchmarking is very different than benchmarking disk-based products, like databases, and generally requires experience and understanding of the delicate details of how network and garbage collections behave under load. With that in mind, GridGain will soon be releasing a benchmarking framework to help easily overcome all these challenges, but until then here is a list of things to watch out for.…

Mar
26
2014
Posted by Distributed Thoughts on Wednesday 26 March 2014, 10:09

Before diving deeper into what it means to easily cluster an application, let's start from defining what  a cluster really is. Wikipedia has a pretty good explanation of clustering here, which is a high level definition that covers fault tolerance, load balancing, scheduling, etc. However, the real magic behind clustering is in making these complex distributed operations seem easy.From development standpoint ability to cluster an application in most cases can be reduced to being able to easily perform the following functions:

  1. Get list of all currently alive cluster nodes
  2. Ability to create sub-groups of nodes within cluster at will
  3. Exchange messages between any nodes…
Mar
18
2014
Posted by Distributed Thoughts on Tuesday 18 March 2014, 10:48

Yesterday GridGain released it's 6.0 version under the Apache 2.0 open source license. Our CTO, Nikita Ivanov, wrote about the new GridGain features and licensing in his blog here, so I will not repeat them. Instead, I will briefly describe our vision behind In-Memory Computing and why we made the move to open source.Why is In-Memory Computing important? The simple answer is that there is no other way to process today’s enormous data volumes. In order to get answers from 100’s of terabytes of data in milliseconds you absolutely must have an In-Memory solution in your architecture. This is…

Mar
11
2014
Posted by Distributed Thoughts on Tuesday 11 March 2014, 12:53

As you may already know, GridGain went open source last week. Going open source was a lot more involved than simply opening up our code. We put significant amount of thought into simplifying our APIs and making our development process as community friendly as possible.As an example, take a look at how in GridGain you can take any local operation and distribute it across the cluster. Let's take GridCache interface. In addition to distributed methods, like get(...) or put(...), many APIs on this interface are local. For example, method size() will return number of entries locally cached, or method containsValue…

Mar
03
2014
Posted by Distributed Thoughts on Monday 3 March 2014, 18:57

Data loading usually has to do with initializing cache data on startup. However, quite often caches need to be loaded or reloaded periodically and not only on startup. In cases when you need to load lots of data, either at startup or at any point after, using standard cache put(...) or putAll(...) operations is generally inefficient, especially when transactional boundaries are not important. This is especially true when data has to be partitioned across the network, so you don't know in advance on which node the data will end up.For fast loading of large amounts of data GridGain provides a cool mechanism called data-loader (implemented via GridDataLoader). The data loader will properly batch keys together and collocate those batches with nodes on which the data will be cached. By controlling the size of the batch and the size of internal transactions it is possible to achieve very fast data loading rates.The code below shows an example of how it can be done:// Get the data loader…

Mar
03
2014
Posted by Distributed Thoughts on Monday 3 March 2014, 18:57

Clustering and failing-over web sessions is certainly not a new topic, but time proves that this topic never gets old either.  No e-commerce site wants to loose any customers in case of a server crash. The old approach of sticky sessions does not seem to do the trick anymore, as it often causes uneven load distribution across cluster with certain servers being overloaded while others being almost idle.Web session clustering provides freedom of load balancing user sessions to any app server without losing intermediate user session data. Why? Because underneath it takes advantage of in-memory distributed caching technology which ensures that user sessions are available in memory regardless of which server is hit. With this approach fault tolerance comes automatically - if a server crashes, simply go to another server and your session will still be available. All of this happens transparently to user who simply continues to browse and add items to the shopping cart as if nothing…