Live data from Hacker News

Anna: A Fast, Scalable, Flexibly Consistent Key-Value Store

databeta.wordpress.com

61–70 of 77 posts

Re: Anna: A Fast, Scalable, Flexibly Consistent Key-Value Store

#61
post #26

Rant: Why so much focus on Key Value stores? That's the easy part of the problem. I would like to know more about the interesting ones: secondary indexes, range scans, performance on mixed workloads, robustness, operational complexity.

CockroachDB is implemented on top of a key / value store. I don’t know too much about the internals, but a kv store with lots of degrees of consistency seems like a good primitive to build more complex data stores on top. For instance, indexes could live as immediately consistent sharded keys, while data stays eventually consistent (or user configurable).

Re: Anna: A Fast, Scalable, Flexibly Consistent Key-Value Store

#62
post #5

I feel like between Redis, S3, Cloud Storage, RocksDB, Cassandra, etc...this area strikes me as one that has been solved as well as we could reasonably expect it to be. What the world of data needs more of is continued development into novel indexing strategies/implementations. ElasticSearch, Postgres's GIN index on JSONB, MapReduce, graph databases. I don't need another key value store...

Cassandra is JVM GC issues Redis is in-memory only Cloud Storage - Not sure, how we can use it outside of cloud vendors RocksDB - Facebook just outsourced the engine to the community, where is the service which adds replication, clustering and network interface on top of it? I am sure, they use one internally, why is it not being open-sourced? There is also badger but most of these only offer low-level operation. Sor…

Cassandra has a host of other trade offs besides java (tombstones and data garbage collection come to mind).

Re: Anna: A Fast, Scalable, Flexibly Consistent Key-Value Store

#64

Claims in the blog post (orders of magnitude faster than the current state of the art systems, universal linear universal scalability from threads to many nodes, dimissing Dean's rule of redesign after x10 scale) seem overblown to me. What have they really built: a purely in-memory KV store that doesn't support synchronous secondary writes for durability. So, any comparisons with ACID KV stores, either disk based (Ca…

Can you point me to where Scylla claims to be ACID or linearizable? As far as I know there is no Paxos implementation yet, not that Cassandra's LWT implementation is anything to write home about.

Re: Anna: A Fast, Scalable, Flexibly Consistent Key-Value Store

#66
post #5

I feel like between Redis, S3, Cloud Storage, RocksDB, Cassandra, etc...this area strikes me as one that has been solved as well as we could reasonably expect it to be. What the world of data needs more of is continued development into novel indexing strategies/implementations. ElasticSearch, Postgres's GIN index on JSONB, MapReduce, graph databases. I don't need another key value store...

All the options you mention have varying features that give it advantages and disadvantages in various scenarios. What works well in on, won't in others, etc. That said, I was mostly interested on how this compares to etcd, since the use case seems pretty similar. How does Anna scale out (differing data centers) compared to it being a bad idea with etcd for example.

I've just finished reading the paper. One difference is that Anna offers a weaker form of consistency than etcd. Etcd offers sequential consistency, and Anna offers casual consistency. I believe that this could eliminate many etcd use cases, since ordering for non-casual events many be different depending on the node you access.

I'm not sure I fully understand etcd's durability guarantees. When an operation is completed, does that mean that the data is durable on a single machine, and then becomes durable on other machines at a later point? If so, it seems like Anna could offer the same durability guarantees.

I think Anna's architecture could be more of a competitor to Cassandra, or DynamoDB as long as you only need casual consistency. The performance implications do seem pretty interesting.

Re: Anna: A Fast, Scalable, Flexibly Consistent Key-Value Store

#67
post #36

Earlier quoted context omitted.

> Why so much focus on Key Value stores? That's the easy part of the problem. There aren't enough good/fast/reliable ones

Does Redis not count?

Redis is an impressive piece of engineering, but it performs best as an in-memory kv-store on a single core. Its distributed capabilities target a different problem than other distributed kv-stores attempt to solve. Redis Cluster focuses on reasonable functionality for an in-memory store. However, Redis Cluster is neither highly available, nor consistent. There are multiple modes that can cause catastrophic data loss, so Redis Cluster works best in situations where losing data isn't a big deal. For it's intended use case, nothing else comes close to offering the same functionality, performance, reliability, and ease of use.

Re: Anna: A Fast, Scalable, Flexibly Consistent Key-Value Store

#68

Earlier quoted context omitted.

Cassandra is JVM GC issues Redis is in-memory only Cloud Storage - Not sure, how we can use it outside of cloud vendors RocksDB - Facebook just outsourced the engine to the community, where is the service which adds replication, clustering and network interface on top of it? I am sure, they use one internally, why is it not being open-sourced? There is also badger but most of these only offer low-level operation. Sor…

Cassandra has a host of other trade offs besides java (tombstones and data garbage collection come to mind).

Rocks Storage engine in Cassandra which claims to reduce the GC stalls

https://engineering.instagram.com/open-sourcing-a-10x-reduct...

Re: Anna: A Fast, Scalable, Flexibly Consistent Key-Value Store

#69

So reading through this announcement, it seems the key to ANNA's speed is: local cache (in the form of the actor's mailbox) + background gossip The usual restrictions (and increases in latency) still apply when you want to make sure that something's actually written (quoruming) after you've written it, from what I can tell. Can someone explain to me why this is a step forward for the field -- I haven't yet read all t…

I don't think that's correct. The real key to its performance seems to be the usage of distributed lattices as data structures, and the ability to perform compile-time checks that guarantee the data will be eventually consistent, both of which allow code to be completely lock-free. This comes from the CALM paper cited in the article - lots of reading to do!

I thought so before too, but after reading the paper again, I came to the same conclusion as the parent. The usage of distributed lattices is key, but it only works because it allows them to reduce messaging cost and gossip at background intervals. As far as I can tell, this means that you can receive a successfully written response, have that machine die , and all data within the last multicast period is lost. Therefore, it isn't suitable as a datastore, and the benchmarks are mostly worthless with the exception of Redis.
Post reply on HN