Trying to understand the memcached client a little better. If there are multiple clients is the client library replicated across each client so that one client can cache data and another can know where to access that same data no matter which memcache server it is stored on? How is this replication of the client library managed... if not how is this functionality achieved? Thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right so my nomenclature is off. Let me see if I can re-word this...
Replacing 'client' with application... if there are multiple instances of the same application caching data to the distributed cache... how is each application's key/server dictionary updated so that each application instance knows where to retrieve cached data? Hopefully that makes more sense. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Memcache servers are dumb and the client does all the work. Basically on the client end the client hashes the key to figure out what server the data goes on. The formula kinda looks like this if you have, say, 3 servers:
"the key".GetHashCode() % 3 = the server to get/put the data at the given key.
If that particular server is down then there's a way to move onto another server, but that's the basics.
At no point do the memcache servers ever notify clients of anything.
Hope this is what you're looking for.
-Tim Gebhardt
tim@gebhardtcomputing.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see. Once a 'key' is created and the data is stored on a server determined by hashing the key if any api wants to get or set that data the same key is used and hashed identically to determine which server for accessing the data. Does the api not maintain a local dictionary of keys that have been used thus far to store data? If so, how do other instances of the api also maintain an identical collection of those keys to access the same data. I was under the impression that the 'Client Library' was this local dictionary... I hope this is making sense.
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>>>Does the api not maintain a local dictionary of keys that have been used thus far to store data?
No.
>>>I was under the impression that the 'Client Library' was this local dictionary.
Not sure where you got that impression. Memcache is a very "remote" dictionary :)!
The typical usage (again, there's a good example on the memcache homepage) is caching, say, a user object that's frequently retrieved from the database. In a webapp if you're already logged in you probably have an encrypted cookie given to the user, and in that cookie you store the user's username or user id. You can store that user information in memcache with a key that looks like:
"User: 49" or "User: emidd"
It's a deterministic key and easy to generate. It works great with caching the results of frequent SQL queries too (say perhaps the latest news posts on the homepage of a web application). Your key could be the entire SQL query (if it fits in the 255 character limit, otherwise you could just come up with your own key for that particular query):
"SELECT * FROM Posts ORDER BY Date LIMIT 20"
Or
"SQL Query: Latest 20 news posts"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Trying to understand the memcached client a little better. If there are multiple clients is the client library replicated across each client so that one client can cache data and another can know where to access that same data no matter which memcache server it is stored on? How is this replication of the client library managed... if not how is this functionality achieved? Thanks in advance.
emidd,
By the wording of your message it seems like it might be a good start for you to look at the official memcache site:
http://www.danga.com/memcached/
It explains how memcache works.
-Tim Gebhardt
tim@gebhardtcomputing.com
Right so my nomenclature is off. Let me see if I can re-word this...
Replacing 'client' with application... if there are multiple instances of the same application caching data to the distributed cache... how is each application's key/server dictionary updated so that each application instance knows where to retrieve cached data? Hopefully that makes more sense. Thanks.
Emidd,
Memcache servers are dumb and the client does all the work. Basically on the client end the client hashes the key to figure out what server the data goes on. The formula kinda looks like this if you have, say, 3 servers:
"the key".GetHashCode() % 3 = the server to get/put the data at the given key.
If that particular server is down then there's a way to move onto another server, but that's the basics.
At no point do the memcache servers ever notify clients of anything.
Hope this is what you're looking for.
-Tim Gebhardt
tim@gebhardtcomputing.com
I see. Once a 'key' is created and the data is stored on a server determined by hashing the key if any api wants to get or set that data the same key is used and hashed identically to determine which server for accessing the data. Does the api not maintain a local dictionary of keys that have been used thus far to store data? If so, how do other instances of the api also maintain an identical collection of those keys to access the same data. I was under the impression that the 'Client Library' was this local dictionary... I hope this is making sense.
Thanks.
>>>Does the api not maintain a local dictionary of keys that have been used thus far to store data?
No.
>>>I was under the impression that the 'Client Library' was this local dictionary.
Not sure where you got that impression. Memcache is a very "remote" dictionary :)!
The typical usage (again, there's a good example on the memcache homepage) is caching, say, a user object that's frequently retrieved from the database. In a webapp if you're already logged in you probably have an encrypted cookie given to the user, and in that cookie you store the user's username or user id. You can store that user information in memcache with a key that looks like:
"User: 49" or "User: emidd"
It's a deterministic key and easy to generate. It works great with caching the results of frequent SQL queries too (say perhaps the latest news posts on the homepage of a web application). Your key could be the entire SQL query (if it fits in the 255 character limit, otherwise you could just come up with your own key for that particular query):
"SELECT * FROM Posts ORDER BY Date LIMIT 20"
Or
"SQL Query: Latest 20 news posts"
Thanks a lot. That makes more sense.