Facebook Twitter Gplus LinkedIn YouTube E-mail RSS
Home Application Architecture Local Cache, Local View or Embedded Space? – GigaSpaces Data Access – How and Why

Local Cache, Local View or Embedded Space? – GigaSpaces Data Access – How and Why

GigaSpaces includes several runtime options and API to access the IMDG. These includes:
- Local Cache
- Local View (available only for GigaSpace)
- Embedded Space
- Remote space
Where the API to access your data could be GigaSpace API or GigaMap API (JMS API and JDBC API are also available).

This post will compare the Local Cache , Local View and the Embedded Space runtime modes and explain how data is read from GigaSpaces In-memory-Data-Grid. We will discuss also the impact on the application VM behavior when data is constructed.

Here is a basic comparison of the GigaSpace vs. GigaMap when accessing the data stored within the IMDG:
GigaSpace API embedded space or local cache/view runtime mode (read operation) – the client is getting with a shallow copy of a matching object and not a deep copy. A shallow copy means that complex fields are not copied – the client proxy manipulates the object fields references and not the object itself. The proxy materializes the object within its client side runtime and populates it with its data. This behavior generates very small amount of garbage collection activity when object goes out of scope.
GigaMap API embedded space or local cache runtime mode (get operation) – the client is getting a reference to the value object. No object creation performed when accessing the data. This behavior does not generate any garbage collection activity when object goes out of scope.

In terms of the underlying implementation – when comparing the GigaMap and GigaSpace , these are very different:
GigaSpace API has been designed to deal with template based and SQL based queries , data notifications and more. Its root is the JavaSpace specification. It allows you to index object fields data and query these or fetch the object based on its ID.
GigaMap API is a distributed table implementation on top of the space. The GigaMap API allows the client to access the space using the typical hash table (key,value) semantics. It has been designed to deal with fetching objects based on a Key. The key (unique value) is used to generate the space object UID and the value stored as part of a space object field (called Envelop). A single Map mapped into a single logical Space (could be comprised from multiple physical spaces when running as partitioned clustered space) – i.e. one Map per Space.

The GigaSpace API local cache/view implemented using a regular space. The GigaMap API in embedded mode implemented using a space. The GigaMap API local cache is NOT implemented using a space but via Concurrent Hash Table.

The local cache runtime mode allows the client application to run a cache that is used for repeated read operations. Every read operation is executed first against the local cache. If the desired object is found, the application will have very good response time. If the desired object is not found in the local cache, it is read from the master remote space. In case a matching object found at the master space, it is loaded into the client local cache and handed back the client application.

Performance Comparison

See below Embedded Space GigaMap get API vs. GigaSpace read API comparison:

Emb bench

As we can see the GigaMap and GigaSpace perform the same and scale the same.

See below local cache GigaMap API get API vs. GigaSpace read API comparison:

local cache bench

– The GigaSpace API read operation in local cache mode performance is similar to GigaSpace API embedded space mode performance.
– The GigaMap API get operation running a local cache introduce very fast response time due-to its special local cache implementation that is in fact faster and more scalable than the regular Java hash table.

Conclusions

- GigaSpace read and GigaMap get operations with embedded space runtime mode scales very well and perform the same. You could have 600,000 read operation per sec with 4 concurrent threads. Very impressive!

- GigaMap get operation with local cache runtime mode is faster than GigaSpace read operation when running a local cache. If you need very fast access to your data based on ID – the GigaMap local cache should be considered. You could have 4 million get operations per second with the GigaMap running a local cache.

We will introduce in future versions a new local cache for the GigaSpace API. This local cache will be faster than the current local cache and will be targeted for read operations based on ID.

Note: GigaSpace SQL based Queries are slower than template based queries due-to the parsing activity. Caching the SQLQuery and re-use it (set the class name and the where clause to different values each time) will improve the performance.

Tests conducted using XAP 6.6.1 , JDK 1.6 , Solaris 10 OS , Sun Fire X4600.

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
1 Comment  comments 
  • http://www.shopnflpatriotsjerseys.com/index.php?main_page=replica&simt=13&player=Fred_Taylor_Jerseys Tom Brady Jersey

    Thanks , I have just been searching for information approximately this subject for a while and yours is the best I have came upon till now. But, what about the conclusion? Are you sure in regards to the supply?|What i don’t realize is if truth be told how you’re no longer really a lot more well-liked than you may be right now. You are very intelligent.

© GigaSpaces on Application Scalability | Open Source PaaS and More