Thanks for all your feedback. Dan, your third option looks good ( cost of memory/oql need to consider). But this should solves popular redisĀ use cases "Top k/ multiple leaderboards use cases, where subset of users/entity involves". In general, Redis brings beautiful user apis which is very handful to end user. They don't need to think about distributed nature of stores. Geode brings strong consistency, high availability(in few seconds secondary copy is available), wan-replication, Async queue and many more enterprise features.
Thus providing those apis on top of Geode should generate good value. Thanks Again.Hitesh. From: Dan Smith <dsm...@pivotal.io> To: dev@geode.apache.org Sent: Wednesday, February 15, 2017 3:12 PM Subject: Re: GeodeRedisAdapter improvments/feedback Deltas would help. If the regions are persistent, the whole new value does get written to disk though. I suppose a third option would be to store all collections in the same region, but store each element of the collection as a separate entry. For example for HSET rkey rfield rvalue would create an entry with a geode key of (rkey, rfield) in a REDIS_MAPS region. We could index the based on rkey. That might make operations on the entire collection more expensive though; those operations would all require using OQL queries. -Dan On Wed, Feb 15, 2017 at 2:35 PM, Galen M O'Sullivan <gosulli...@pivotal.io> wrote: > On Wed, Feb 15, 2017 at 1:34 PM, Real Wes <thereal...@outlook.com> wrote: > > Does delta propagation make worrying about frequently updated fat > collections moot? > > As long as we don't have collections on the order of the available RAM on a > single server (in which case we'd want to distribute it across multiple > servers), and pending testing, I think it does. Good idea, I didn't even > know we could do this. >