"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."
But you're..._adding_ support for memcached to that system. If this were a system already using memcached, it'd be...speaking memcached. If it were using a different, external caching system, you'd probably expect some measure of integration code, or at least testing it if, like Tyrant, it did speak the same protocol you were expecting. The only other case would be if you weren't using some external cache already, in which event you're going to be adding logic, regardless. - Marc On Wed, Jul 28, 2010 at 11:19 AM, Adam Lee <[email protected]> wrote: > 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 >
