5 ms·

It would be nice to know why I would use this instead of something tried and tested like Redis, but the sparse description doesn't really help.

by fein 8y ago

staticassertion 8y ago
Redis is like 0 for 3 from a CAP perspective as far as I understand it. Fine for a cache, but if you want a KV store you can rely on for some properties, it does not seem viable. So redis is 'tried and true' but may not meet your constraints. https://www.quora.com/What-is-Redis-in-the-context-of-the-CAP-Theorem https://www.quora.com/What-is-Redis-in-the-context-of-the-CA... I haven't read the Faster paper yet (planning to) so I don't know that it provides better guarantees. But I personally would like a simple-as-redis KV store that provides better guarantees. edit: Ah, yeah, Faster doesn't seem to even really be directly comparable to Redis - seems more like rocksdb, and not a distributed system.
kodablah 8y ago
On the surface, I'd guess the statically linked vs separate daemon differences apply (both have obvious pros and cons depending upon requirements and deployment scenarios). Also, MS research is just that, a research wing and many of their libs go stale/unsupported after written.
makmanalp 8y ago
You wouldn't - first and foremost, this is probably most useful as a storage layer for some more higher-level data store. Second, think of software artifacts from papers as a proof of concept, or a prototype. It's intended more to demonstrate some architectural innovation, and less to serve customer needs. Their ideas revolve around supporting a high level of concurrent access and removing the locking overhead that would normally stem from this, and an interesting way to handle spilling over to disk in larger-than-memory scenarios. This might evolve into a customer-oriented product eventually. Or perhaps get retrofitted into the guts of something like MS SQL server.

It would be nice to know why I would use this instead of something tried and tested like Redis, but the sparse description doesn't really help.

by fein 8y ago

It would be nice to know why I would use this instead of something tried and tested like Redis, but the sparse description doesn't really help.

staticassertion 8y ago

Redis is like 0 for 3 from a CAP perspective as far as I understand it. Fine for a cache, but if you want a KV store you can rely on for some properties, it does not seem viable. So redis is 'tried and true' but may not meet your constraints. https://www.quora.com/What-is-Redis-in-the-context-of-the-CAP-Theorem https://www.quora.com/What-is-Redis-in-the-context-of-the-CA... I haven't read the Faster paper yet (planning to) so I don't know that it provides better guarantees. But I personally would like a simple-as-redis KV store that provides better guarantees. edit: Ah, yeah, Faster doesn't seem to even really be directly comparable to Redis - seems more like rocksdb, and not a distributed system.

kodablah 8y ago

On the surface, I'd guess the statically linked vs separate daemon differences apply (both have obvious pros and cons depending upon requirements and deployment scenarios). Also, MS research is just that, a research wing and many of their libs go stale/unsupported after written.

makmanalp 8y ago

You wouldn't - first and foremost, this is probably most useful as a storage layer for some more higher-level data store. Second, think of software artifacts from papers as a proof of concept, or a prototype. It's intended more to demonstrate some architectural innovation, and less to serve customer needs. Their ideas revolve around supporting a high level of concurrent access and removing the locking overhead that would normally stem from this, and an interesting way to handle spilling over to disk in larger-than-memory scenarios. This might evolve into a customer-oriented product eventually. Or perhaps get retrofitted into the guts of something like MS SQL server.