Can see it in my old blog: http://kumarishan.wordpress.com/2012/02/18/scalability-solutions-hazelcast/
Key Features:
Use cases related to my projects:
Onyx - Distributed indexing
Use Case: In Onyx when a document comes to a host for indexing, it extracts each word and then sends them to their respective host. Every host is assigned a set of word from the universal set and it keeps indexes of only those keywords.
Using Distributed Topic
The basic idea is to use Hazelcast’s distribution and partioning logic to assign keywords to a host. So after extracting keywords from a document, Onyx will use Partition API to look for owner of the keyword. Once the owner is known it will publish the (keyword, document ID) pair to the topic which uniquely identifies the owner. The member subscribed to the topic will receive all the keywords assigned to it and add to its index file. Also every member has to listen on Migration events so that the index files can be updated based on new owners of the partition and keywords.
Detailed discussion: work in progress…
Caching solution:
Session store:
Hazelcast can be used to store session related data for backup in the event of failure, and load balancing. In case of Load Balancing when a request is routed to a host, it will be able to perform operations on the data even if the data reside on some other host. Transaction based on what kind of operation can be used here if multiple hosts are operating on the same data. But the catch is if load balancing always routes the request to a host where the data does not reside then the operations will always result in remote machine calls. One of the solution to avoid this, is to use data affinity and Near Cache techniques to cache and use source hashing as routing logic. This will ensure that the request keep coming to a particular host unless it fails and slowly the data will be cached due to Near Cache. Another method could be to use Partition API and route the request packets to the host that will have the session data. Here we will not need Near Cache technique but Data Affinity has to be used to have all the session data for a particular user at one place. With such an efficient system in place, JRuby based RoR can have inbuilt library for this.
Detailed discussion: work in progress…
Caching user data:
It can be used to support caching mechanism similar to memcached. This can be a more lucrative solution due to support for transaction, locking and near cache options.
Hash:
A wrapper over Hazelcast can be written to support more advanced features like routing requests to the specific host. Hazelcast can provide the basic feature of managing node arrival and removal, and auto re-partitioning of the key space. Basically all the functionality of DHT. And Hash can provide a service of lookup for a certain key to route so that operations can occur on the same machine as far as possible.
Detailed discussion: work in progress…
Will keep updating the post if more use case arrives..
Sources:
Design by Simon Fletcher. Powered by Tumblr.
© Copyright 2010
