Sunday 19 April 2015

Persistence and Resilience in Hazelcast


Persistence

Hazelcast provides a solution loading and storing data externally, such as in a database. 


com.hazelcast.core.MapStore: Useful for reading and writing map entries from and to an external datasource. We need to implement our own MapStore, and configure it in hazelcast.xml. Then, hazelcast will call it at each map operation. 
The data can be persisted in either RDBMS or NoSQLs.

Hazelcast supports both write-through and write-behind for persistence in databases.

  • Write through operations increase latency since databases cause latency. Every time that a change is made in the map, a write through to your persistence mechanism happens. This is the default setting in map-store.
  •  
  • Write-behind: When a change happens, the change is synchronously written to the backup partition , but the change to the database is done asynchronously. You can enable write behind by configuring the write-delay-seconds to a positive value in the map-store configuration section. deleteAll and storeAll methods implemented in mapStore are used in write-behind mode.

Resilience:


1. Lose nodes
When a node dies, the ownership of any partitions that were owned by the now defunct node will be migrated to one of the backups so that no apparent data loss is experienced. 
Additionally in the background, Hazelcast will start to replicate the migrated partitions over to another node to cater for the fact that there are now fewer backups available than was configured. This will restore resilience back to as it was configured.

2. Add nodes
When we introduce a new node, Hazelcast reacts by assigning partitions from existing nodes to it. This will cause existing data to stream across to the new node taking on more and more partitions until it holds an overall fair share.

No comments:

Post a Comment