That seems an odd case to me, to be honest. One of the key benefits of memcached is its ultra-low latency, which is negated somewhat by using a much heavier protocol. Also, writing a simple client library for the text protocol is seriously achievable in an afternoon.
Anyway, there's nothing to say that you can't change your "hashing" strategy to work with HTTP/URIs. Just hash the URI or use characters from it to select a server, for example... As long as all clients agree, it doesn't matter how you shard the data. Again, I'd say you should take a look at TokyoTyrant for a fast, simple key-value store that speaks both memcached and HTTP. On Wed, Jul 28, 2010 at 2:11 PM, Les Mikesell <[email protected]> wrote: > There's no argument that embedding a locally-configured memcache client > library for the appropriate language into your program would be more > efficient, but consider the case where you have many programs in many > languages sharing the cache data and some of them have inherent http > capability and aren't used enough to care about that last 10% efficiency > when it means rewriting a bunch of code with new libraries to get it. > However, I still think the http interface would have to be a separate > standalone piece, sitting over a stock client that knows about the local > distributed servers or you'd need a special client library anyway. > > -Les > > > > On 7/28/2010 12:53 PM, Adam Lee wrote: > >> memcached's protocol is, as has been pointed out, already language >> agnostic and much more efficient than trying to do HTTP. If you're >> saying RESTful in the "not necessarily HTTP" sense, though, then I'd say >> that memcached's text protocol is basically already as RESTful as you're >> going to get- think of commands as verbs ('get,' 'set,' 'add,' 'delete,' >> etc...) and the key as a URI and you're basically in an analogous >> situation that I think basically meets the criteria as much as you can >> (hard to have a stateless cache)... >> http://en.wikipedia.org/wiki/Representational_State_Transfer#Constraints >> >> If you want a key-value datastore with an HTTP interface, though, might >> I recommend Tokyo Tyrant? It speaks memcached and its own binary >> protocol as well: http://1978th.net/tokyotyrant/spex.html#protocol >> >> On Wed, Jul 28, 2010 at 12:03 PM, Les Mikesell <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 7/28/2010 10:16 AM, jsm wrote: >> >> Gavin, >> You are right about the overhead and also saw that API's exist for >> most of the languages as well. >> I thought REST API would make memcached language agnostic. >> I would like to hear from the community if the REST API should be >> pursued or not? >> >> >> I'm not quite sure how a rest api could deal with the distributed >> servers without a special client anyway. But, it might be handy to >> have a web service that mapped a rest api as directly as possible to >> memcache operations where the http side would use traditional load >> balance/fail over methods and handle the http 1.1 connection >> caching. I'm sure there would be places where this could be used by >> components that have/want data in a cache shared by more efficient >> clients. >> >> -- >> Les Mikesell >> [email protected] <mailto:[email protected]> >> >> >> >> >> -- >> awl >> > > -- awl
