Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

databeta.wordpress.com

Post reply on HN
Print view View original

71–77 of 77 posts

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

#71

Post by hardwaresofton »

doorbumper wrote: post #69
ricardobeat wrote: post #16

Earlier quoted context omitted.

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. There…

Super duper late, but I still haven't had time to read any of the papers (there are like 4 if I really want to get anywhere close to understanding their spin on gossip + the lattice thing) -- glad the discussion is still interesting though.

I'm starting to think that the quorum strategy is something like a theoretical lower bound -- at least until someone brilliant figures out a way past it (or technology shifts in some gigantic way or something).

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

#72

Post by leventov »

evanweaver wrote: post #64
leventov wrote: post #45

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.

Anna paper itself says that Cassandra and Scylla are Linearizable per-key. Yes, obviously Scylla is not ACID, sorry for my loose usage of this term. I was referring to durability, i. e. "D" from ACID.

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

#73

Post by Capaverde »

doorbumper wrote: post #70
Capaverde wrote: post #63

Why this fad with naming apps as persons? Found this: http://fortune.com/2014/12/22/startup-names-human/

Anna is a hummingbird. Known for its fastest relative speed.

Why this fad with naming birds as persons?

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

#74

Post by jaricftw »

doorbumper wrote: post #66
tracker1 wrote: post #44

Earlier quoted context omitted.

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 comple…

etcd does not provide key partitioning/sharding, it achieves linearizable consistency using replica state machine via Raft. Anna provides weaker consistency guarantee (causal or read committed), but has partitioning/sharding.

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

#75

Post by hyc_symas »

SanFranManDan wrote: post #20
ralusek wrote: 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...

I agree. However, I stumbled into the world of KV stores (like RocksDB, LMDB, LevelDB, etc..) last year, and what is most surprising is that they all stop in the same place. I understand that they should do one thing and one thing well, but it is still disappointing when you have to implement things like replication, sharding, and indexing yourself. There really aren't even that many DBMS that are KV (like redis) out…

BerkeleyDB has a replication engine. IMO that's too much of a kitchen-sink approach. Judging by how many of those KV stores utterly fail to store data reliably, that's already a hard enough problem to solve. Focusing on the local storage is a clearly delineated realm of responsibility. Distribution obviously belongs to a higher logical layer.

Indexing requires knowledge of a higher level data model. (Again, BerkeleyDB has built in support for secondary indexing, but last time I checked it was a quite braindead and slow implementation. Faster to build your own indices instead, using the other facilities provided.)

With that said, while a KV store has no logical data model to apply to index generation, it can at least provide primitives for you to construct your own indices. BerkeleyDB and LMDB do this.

Distribution with transaction support may require help from the storage engine (offering something resembling multi-phase commit). BerkeleyDB provides this already; LMDB will probably provide this in 1.0.

An argument could be made that the storage engine should be able to handle replication/distribution even without understanding the higher level/application data model. BerkeleyDB does this with page-level replication. IME this results in gratuitously verbose replication traffic, as every high level operation plus all of its dependent index updates etc. are replicated as low level disk/page offset operations. IMO it makes more sense to leave this to a higher layer because you can just replicate logical operations, and save a huge amount of network overhead.

As for the possible higher layers - antoncohen's response below gives a few examples. There are plenty of higher level DBMSs implemented on top of LMDB, providing replication, sharding, etc.

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

#76

Post by hyc_symas »

digikata wrote: post #33
SanFranManDan wrote: post #20

Earlier quoted context omitted.

I agree. However, I stumbled into the world of KV stores (like RocksDB, LMDB, LevelDB, etc..) last year, and what is most surprising is that they all stop in the same place. I understand that they should do one thing and one thing well, but it is still disappointing when you have to implement things like replication, sharding, and indexing yourself. There really aren't even that many DBMS that are KV (like redis) out…

I think we're just getting to the point where it may become more common to separate the simpler problem of a single node, non-distributed 'store' with some kv interface below, and then build more complex distributed algorithms in a layer or two above. You can see some of the larger monolithic codebases that had to start by having their own code all the way up and down the stack, but now are starting to experiment wit…

"Just getting to the point" ? OpenLDAP has been architected this way for ~20 years. I think the same could be said for MySQL, as well as SQLServer (built on top of ESENT/JET). Large monolithic data stores are an obvious anti-pattern, reflects short-sighted design process.

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

#77

Post by digikata »

hyc_symas wrote: post #76
digikata wrote: post #33

Earlier quoted context omitted.

I think we're just getting to the point where it may become more common to separate the simpler problem of a single node, non-distributed 'store' with some kv interface below, and then build more complex distributed algorithms in a layer or two above. You can see some of the larger monolithic codebases that had to start by having their own code all the way up and down the stack, but now are starting to experiment wit…

"Just getting to the point" ? OpenLDAP has been architected this way for ~20 years. I think the same could be said for MySQL, as well as SQLServer (built on top of ESENT/JET). Large monolithic data stores are an obvious anti-pattern, reflects short-sighted design process.

Ha, you have a good point. I think my comment was directed more to "distributed cloud store" applications, much more so than databases. That begs the question - then what capabilities have those apps been focusing on that they didn't get from existing databases (or thought that they didn't get from existing databases)...
Post reply on HN