Structure of the memcached KEY

[Randy Wigginton]

Just FYI, in our application we use the full SQL query to generate a  
UUID.  We are far more concerned about false collisions than about  
the overhead, which is tiny (and once the sql is transformed on the  
client side, we save the result in a local hashtable, thus only  
having to generate the UUID once).

On Nov 3, 2006, at 4:57 AM, Daniel Beckham wrote:

> 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?
>