Fast key-value stores: An idea whose time has come and gone

Re:Fast key-value stores: An idea whose time has come and gone by saulrh on Monday June 24, 2019 @11:44AM (#20264689)

> In a KV system you would have something like key and value as bytes fields.

Isn't that kind of custom interchange format what they're complaining about when they say that remote stores just push the complexity to the client?

[ Parent | on HN ]

Re:Fast key-value stores: An idea whose time has come and gone by hinkley on Monday June 24, 2019 @11:54AM (#20264824)

In the kv stores I’ve used the client and the server are mostly the same process, or started out that way.

I don’t know many sane people who want to use the kv store as a system of record, and even the people who expect it to be exhaustive (all possible keys) make me doubt their sanity for that and other reasons.

So far, everyone has a bit of code that looks for a key and, if it is missing, performs the work necessary to build the payload. The code that creates the payload is never more than a couple function calls away from the retrieval code.

[ Parent | on HN ]

Re:Fast key-value stores: An idea whose time has come and gone by shereadsthenews on Monday June 24, 2019 @11:48AM (#20264742)

I don't know but how does complaining that it takes a microsecond to encode 256 random numbers lead to the conclusion that remote KV caches are unworkable? That's just a non sequitur.

[ Parent | on HN ]