Metadata cache for mongodb

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Metadata cache for mongodb

bserdar
In a typical call, we submit three requests to MongoDB:
  - retrieve entityInfo
  - retrieve schema
  - the actual request

We can eliminate the metadata lookups for most calls. Metadata don't change often, and can be cached. We already decided that we don't want to deal with distributed caches, and we don't want to deal with undeterministic behavior resulting from stale caches as well. So, here's a compromise:

Setup:

We define two periods, a shorter period, say 10 seconds, that determines how often we should check if metadata changed or not; and a longer period, say 1 minute, that simply invalidates the cache.

We add a document with a field 'collectionVersion' into the metadata collection with a known fixed id.

Metadata lookups use a weak cache. Since it is a weak cache, it won't have an adverse effect on memory.

Operation:

 - Any metadata update increments collectionVersion
 - Every 10 seconds (the shorter period), we check collectionVersion. If it is not what it was the last time we checked it, we invalidate the cache
 - Every 1 minute (the longer period), we invalidate the cache

Under heavy load, this will eliminate the extra metadata calls for most requests. Any changes to metadata will be propagated to all nodes within 10 seconds. Any cache inconsistency such as a manual intervention will correct itself within a minute.

Thoughts?
Reply | Threaded
Open this post in threaded view
|

Re: Metadata cache for mongodb

jewzaam
Administrator
As long as the frequency is easily configured I don't see a problem.  I wonder about tying the short check to a request instead of polling but that defeats the purpose of this change, which is to increase response time.  Depending on how the cache is done, what is the risk to a request in progress if the cache becomes invalid?



On Tue, Sep 8, 2015 at 10:35 AM bserdar [via lightblue-dev] <[hidden email]> wrote:
In a typical call, we submit three requests to MongoDB:
  - retrieve entityInfo
  - retrieve schema
  - the actual request

We can eliminate the metadata lookups for most calls. Metadata don't change often, and can be cached. We already decided that we don't want to deal with distributed caches, and we don't want to deal with undeterministic behavior resulting from stale caches as well. So, here's a compromise:

Setup:

We define two periods, a shorter period, say 10 seconds, that determines how often we should check if metadata changed or not; and a longer period, say 1 minute, that simply invalidates the cache.

We add a document with a field 'collectionVersion' into the metadata collection with a known fixed id.

Metadata lookups use a weak cache. Since it is a weak cache, it won't have an adverse effect on memory.

Operation:

 - Any metadata update increments collectionVersion
 - Every 10 seconds (the shorter period), we check collectionVersion. If it is not what it was the last time we checked it, we invalidate the cache
 - Every 1 minute (the longer period), we invalidate the cache

Under heavy load, this will eliminate the extra metadata calls for most requests. Any changes to metadata will be propagated to all nodes within 10 seconds. Any cache inconsistency such as a manual intervention will correct itself within a minute.

Thoughts?



If you reply to this email, your message will be added to the discussion below:
http://dev.forum.lightblue.io/Metadata-cache-for-mongodb-tp386.html
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Metadata cache for mongodb

bserdar
 A request in progress will always see the metadata it retrieved when
it started, cached or not.

We can add configuration items to the metadata configuration.

On Tue, Sep 8, 2015 at 8:55 AM, jewzaam [via lightblue-dev]
<[hidden email]> wrote:

> As long as the frequency is easily configured I don't see a problem.  I
> wonder about tying the short check to a request instead of polling but that
> defeats the purpose of this change, which is to increase response time.
> Depending on how the cache is done, what is the risk to a request in
> progress if the cache becomes invalid?
>
>
>
> On Tue, Sep 8, 2015 at 10:35 AM bserdar [via lightblue-dev] <[hidden email]>
> wrote:
>>
>> In a typical call, we submit three requests to MongoDB:
>>   - retrieve entityInfo
>>   - retrieve schema
>>   - the actual request
>>
>> We can eliminate the metadata lookups for most calls. Metadata don't
>> change often, and can be cached. We already decided that we don't want to
>> deal with distributed caches, and we don't want to deal with undeterministic
>> behavior resulting from stale caches as well. So, here's a compromise:
>>
>> Setup:
>>
>> We define two periods, a shorter period, say 10 seconds, that determines
>> how often we should check if metadata changed or not; and a longer period,
>> say 1 minute, that simply invalidates the cache.
>>
>> We add a document with a field 'collectionVersion' into the metadata
>> collection with a known fixed id.
>>
>> Metadata lookups use a weak cache. Since it is a weak cache, it won't have
>> an adverse effect on memory.
>>
>> Operation:
>>
>>  - Any metadata update increments collectionVersion
>>  - Every 10 seconds (the shorter period), we check collectionVersion. If
>> it is not what it was the last time we checked it, we invalidate the cache
>>  - Every 1 minute (the longer period), we invalidate the cache
>>
>> Under heavy load, this will eliminate the extra metadata calls for most
>> requests. Any changes to metadata will be propagated to all nodes within 10
>> seconds. Any cache inconsistency such as a manual intervention will correct
>> itself within a minute.
>>
>> Thoughts?
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://dev.forum.lightblue.io/Metadata-cache-for-mongodb-tp386.html
>> To start a new topic under lightblue-dev, email [hidden email]
>> To unsubscribe from lightblue-dev, click here.
>> NAML
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/Metadata-cache-for-mongodb-tp386p387.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML