Simple Comparisons on some In-Memory Data Grids

 

Fetures	Feature Description	GemFire7	Coherence3.7	Infinispan5	Gigaspaces7	Notes
1. topologies	peer-peer; client-server	High	High	High	High
2. cross-site /   WAN replication	datacenter-datacenter; region-region	High	Low	Med	High	Coherence support by incubator "Push replication"; Infinispan basic support in V5.2
3. read-most scalability	via replication	High	High	High	High
4. write-most scalability	via partitioning and replication between primary and backups	High	High	Med	High
5. high availability / HA	via replication and persistence  into disk (DB)	High	High	High	High
6. asychronous     replication	useful for slow changing data and WAN replication	High	Med	High	High	Coherence support by incubator "Push replication";
7. partition rehashing	consistent hashing to reduce data relocation	High	High	High	High	all seem to use consistent hashing-like algorithms
8. dynamic clustering	adds or loses nodes	High	High	High	Med
9. updating among     partition backups	master-backup: less deadlock prone and IO master-master/update anywhere: more dealock prone and IO	High	High	Low	High	Infinispan only has master-master that incurs deadlock for slow network and large caches
10. cache loader and       writer	2 application interfaces: loades data from DB and saves data into Cache. With cache loader and writer, applications only need to interace with Cache!	High	High	Med	High	Infinispan writers only support JPA, not JDBC or Hibernate!
11. read-through and      read-ahead	populates cache with DB in batch mode	Med	High	Med	High	no prefetch/batch support from Gemfire and infinispan
12. write-through and      write-behind	persists cache into wherever they were loaded.write-behind persists data asynchronously	High	High	Med	High
13. event notification	Cache also works as a messaging and parallel processing bus like JMS/MDB	Med	Med	Med	High
14. continous querying	register contents-based interests with Cache and receive updates continously.	High	High	Low	High
15. cache querying	SQL like query: not only searches  based on key matching	High	High	Low	High
16. locking and tx	JTA (global tx) and ACID properties	High	High	Med	High
17. off-heap	puts cache data off Java heap so that GC pause time is reduce!	Low	High	Low	Low
18. key affinity /      colocation	colocates related cache objects on the same partition to reduce IO	High	High	High	High
19. customized      partitioning	puts cache into specific cluster node to bypass cache hashing algorithm	High	Low	Med	Low
20. synchronous      requests like RFQ	synchronou requests should go through the same partition routing as asynchrous messages.	Low	Low	Low	High
21. API	Map,Restful and appropriate interfaces	Med	Med	Med	High
22. language bindings	Java, C++ etc	Med	Med	Med	High
23. map-reduce /      scatter-gather	submits aggregation tasks to run across multiple or all cluster nodes	High	High	High	High
24. monitoring	monitor the health of clusters	High	Med	Med	High
25. J2EE (JMS,Web,      Remoting)	how much J2EE? to support?	Low	Low	Low	High
26. migration effort	how to migrate to a different cache production in a J2EE app. server	High	High	High	Low	GigaSpaces is an app. server

Technical Evalutions for a Real Time Searching System Part 1 -- Overview

I recently conducted a technical evaluations for a real time search system (RTSS hereafter). It primarily focuses on mature open source frameworks. Many technologies involved are quite new and very interesting.
I present my ideas in a 4-part series:

• Part 1 -- Overview
• Part 2 -- Solutions Based on SQL and NoSQL DB (H2 and MongoDB)
• Part 3 -- Solutions Based on Index Search Engines (Lucene Solar and Sphinx);
• Part 4 -- Solutions Based on XML DB (MarkLogic and Berkeley DB XML)

1 Main Business Requirements for RTSS

• Supports auto-complete and spell checkers on customized list of names;
• Supports advanced searching and browsing on many combinations of attributes;
• Support ranking / relevance;
• Supports different types of clients (Java/C/C#) by being service-oriented;
• Supports huge user based by being reliable and scalable;

 2 Architecture Layers

The RTSS can be divided into 3 logic layers. From front-end to back-end, they are as follows:

• The UI layer that includes web applications hosted on Jetty/Tomcat/JBoss, and non-web applications such as Java Swing and c/C++;
• The service or business layer that provides results to the UI layer for auto-complete and spell-checker and all kinds of search requests either in a language neutral format such as XML, Fast Infoset, JSON or such descriptive binary protocol as Google Protocol Buffers;
• The DAO layer that provides the service layer with search results. Data stores (SQL, NoSQL, index search engines and XML DB) will also be discussed along with DAO.

The 3 layers may be hosted on different servers for flexibility and scalability. However, they are usually combined together if possible for better performance. Data stores are usually on a separate server. However, in-memory DB can be embedded into the service layer.
In the following discussion, the lines or words in bold blue are viable options for final selection.

Master-Local -- the most common topology in IMDG

IMDG (In-Memory-Data-Grid) functions like an in-memory database to the front end users. In order to be scalable, IMDG has to provide partitioned topology besides the replicated one.

If we bundle an application locally with a data partition together and the application only processes its local data, we form what the GigaSpaces calls a PU(Processing Unit).
Because PU doesn't need to communicate with others, we can achieve linear scalability by deploying multiple PUs.

However such a tightly couple application rarely exists practically.
On one hand IMDG basically partitions data evenly without caring about too much of your application. After all IMDG, as the delegate of a system of record (the database), should be able to server all applications.
On the other hand your application should implement your specific business logic and you may have different applications for different business requirements.

So your universal data and your specific business requirements are just conflicting with each other.
To solve this dilemma, a Master-Local topology is often employed where the master cache (or Data-only Processing Unit or EDG in GigaSpaces) itself can be either replicated, partitioned or both; the local cache (or embedded space in GigaSpaces), caches data from, and synchronizes any update with, the master on demand. The communication between local and master is usually a single network hop and extreme low latency can be achieved using switches.
Here is a diagram from GigaSpaces where the master is replicated:

If your local cache is read-only, the performance is the best.
Oracle Coherent also calls the above topology as Near Cache.

Going back to GigaSpaces' "XAP Order Management Tutorial" in its XAP 7.0.0 "Quick Start Guide" section. As its comment mentions, the AccountData comes from IMDG which is simulated by AccountDataLoader in the example. In practice it should come from an EDG which connects to the local embedded space in the order runtime processing unit.