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.
>
