geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <ukohlme...@pivotal.io>
Subject Re: GeodeRedisAdapter improvments/feedback
Date Wed, 15 Feb 2017 23:18:43 GMT
I think we are now straddling into the territory where any distributed 
storage gains would be negated by the memory we require to make the 
queries/lookup/operation fast.

In addition to the added memory pressure, we still face network latency 
for every operation.


On 2/15/17 15:12, Dan Smith wrote:
> 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 <gosullivan@pivotal.io>
> wrote:
>
>> On Wed, Feb 15, 2017 at 1:34 PM, Real Wes <TheRealWes@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.
>>


Mime
View raw message