Structure of the memcached KEY

[Daniel Beckham]

The protocol documentation explains this. Look for the "Keys" section a 
few paragraphs down:

http://cvs.danga.com/browse.cgi/wcmtools/memcached/doc/protocol.txt?rev=HEAD&content-type=text/plain

To answer your second question, hashing the SQL query is the first thing 
that I would think to do.  You are correct in saying that hashing adds 
overhead to the entire operation, but it is going to be insignificant 
for many operations.  Except for very high load situations or extremely 
time sensitive situations, hashing is going to be your best all around 
choice.

But, that question can easily be answered yourself by writing a quick 
benchmark script to to test it.  Perform a large number of 
query/memcached store operations using a hash of the SQL query and then 
try it just using a sequential value for the key.

One additional thought.  For a memcached application like a website, 
it's normal that your database operation results in the creation of some 
common object that is used in a web page.  Instead of caching a raw 
query that still needs to be turned into something useful, why not go 
ahead and turn it into that useful object and then store that?  Usually 
that can be more easily identified by some unique column in the table, 
like a post ID, etc.  By doing this you would actually save many more 
CPU cycles and resources than you would figuring out how to no hash a 
SQL query.

-Daniel

Luc Levesque wrote:
> What are the restrictions / limits on the format of the key used to 
> get / set strings into memcached?
>  
> I simply used the SQL query for the key ( which contained quotes, 
> spaces and all that stuff ) and it barfed. I now run a SHA1 hash on 
> the query string and use that but this is adding overhead.
>  
> Ideas?