Large caches ...

[Thomas -lists]

I would usually do this in the application.
You try to retrieve a key from the cache, if its not there retrieve it
from the database and put this into the cache.
Every next call would get the key from the cache then.
Thats my basic understanding on how a cache works.
You don't need to care about loading the cache before using it and you
have no problems if the cache fails.


thomas



Hans-Juergen Schoenig wrote:

> I know that it is not a database. Basically I fully understand what
> you mean. We have a real database which does the real storage.
> The problem is: If we lose a node we cannot reload the entire cache as
> it is too large and the system will be down for quite a while.
> If I know which server got lost - is there a way to repopulate only
> the data which is on this certain server?
> This would dramatically reduce the time needed to recover. In the
> meantime the missing data could be provided by the database
> (serving 1 out of 10 records from the database should work).
>
>    Best regards,
>
>       Hans
>
>
> Brad Fitzpatrick wrote:
>
>> You know that memcached isn't a database, right?  It's a CACHE.  If a
>> machine dies, you get some cache misses, which you then have to
>> repopulate
>> from your REAL DATABASE.
>>
>> - Brad
>>
>>
>> On Sat, 2 Jul 2005, Hans-Juergen Schoenig wrote:
>>
>>  
>>
>>> We are planning to develop an application on top of a very large in
>>> memory database. Basically the size of the application will be around
>>> 100 - 400 gb (in memory). We will need a quite large server farm to
>>> achieve that. The problem now is: What happens if a server fucks up?
>>> What can we do to make this work 24x7? Rebuilding the cache from
>>> scratch
>>> is not an option as it is too large :(.
>>>
>>> How did other folks solve that?
>>>
>>>    Best regards,
>>>
>>>       Hans
>>>
>>>
>>>   
>>
>