Distributed persistent cache store

[Erik Vanherck <Er...@inventivegroup.com>]

Hi All,

I gather that the current CacheStore is designed to be implemented by using some kind of centralised storage backend. However I need to store data for longer periods of time and a database is poorly suited for it (mainly small blobs) because pure write throughput matters, Hadoop HDFS massive overkill and too much latency (already tried that), and shared filesystems … well they present their own set of challenges and weird behaviour, safety and visibility guarantees (even something like glusterfs). 

So I thought about doing it easy, just store it in large sequential files on local disks for each node. This would work fine apart from having a need to ensure some kind of reliability by replicating the data since nodes may be lost.

I see that there are events broadcast for a PUT and REMOVE on a cache, so potentially I could hook into that and do some custom logic by using some hash and then sharding, but if there are better solutions or reasons why this would not work, I would love any suggestions.

Cheers,
Erik

Re: Distributed persistent cache store

[vkulichenko <va...@gmail.com>]

Hi Erik,

Generally, cache store is designed to be shared across all nodes. Dumping
data to local FS can lead to different data consistency issues and
definitely not an easy task.

If you want to persist your data, but avoid large latencies of DB, you can
use write-behind caching [1].

BTW, GridGain has functionality similar to what you describe in their
enterprise edition [1], but it's actually used mostly for recovery after
full cluster restart, but not for persistence.

[1]
https://apacheignite.readme.io/docs/persistent-store#write-behind-caching
[2] https://gridgain.readme.io/docs/local-recoverable-store

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Distributed-persistent-cache-store-tp2275p2285.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.