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

Spanner vs. Calvin: distributed consistency at scale

fauna.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Spanner vs. Calvin: distributed consistency at scale

#41

Post by arielweisberg »

abadid wrote: post #18
jhugg wrote: post #15

Earlier quoted context omitted.

> But VoltDB's command logging feature came directly from Calvin. VoltDev here. Huh? We added this feature in 2011 and read the Calvin paper sometime later IIRC.

"The case for determinism in database systems" paper (which described the technology that became Calvin) was written in VLDB 2010. At least one VoltDB developer told me that command logging came from a talk we gave about this paper to your team.

I think they happened independently, but it's long enough ago that I might not recall if I or Ning had inspiration from somewhere.

If you heard it from Ning or myself then it's probably what happened.

Re: Spanner vs. Calvin: distributed consistency at scale

#42

Post by jhugg »

abadid wrote: post #18
jhugg wrote: post #15

Earlier quoted context omitted.

> But VoltDB's command logging feature came directly from Calvin. VoltDev here. Huh? We added this feature in 2011 and read the Calvin paper sometime later IIRC.

"The case for determinism in database systems" paper (which described the technology that became Calvin) was written in VLDB 2010. At least one VoltDB developer told me that command logging came from a talk we gave about this paper to your team.

I think that logical logging was an obvious choice given VoltDB architecture. It's totally possible there was a talk that was involved for somebody though.

That said, we <3 determinism at VoltDB and rely on it to achieve what we achieve.

Re: Spanner vs. Calvin: distributed consistency at scale

#43

Post by jhugg »

zenithm wrote: post #12
abadid wrote: post #5

Earlier quoted context omitted.

I said in my post: "influenced the design of several modern “NewSQL” systems" --- I'm not aware of other production implementations of Calvin. But VoltDB's command logging feature came directly from Calvin. So basically I had in mind FaunaDB and VoltDB when I wrote that sentence. Neither is an exact version of Calvin, but FaunaDB is closer to Calvin than VoltDB. Obviously, the Calvin paper has been cited many hundred…

How does Volt's transaction resolution mechanism compare? It sounds like that would be a third model yet.

We have a whitepaper here: https://www.voltdb.com/wp-content/uploads/2017/03/lv-technic...

My brief summary comparison. VoltDB is a bit less general in some key ways. It tends to have the same performance no matter how much contention there is, which is rare. It's also getting pretty mature, with lots of integrations and hard corners sanded off.

It also typically has much lower latency than these systems, both theoretically and practically.

Re: Spanner vs. Calvin: distributed consistency at scale

#45

Post by venkasub »

jchrisa wrote: post #27

Abadi has an interesting paper here about why so many NoSQL databases are missing transactions. http://dbmsmusings.blogspot.com/2015/10/why-mongodb-cassandr... The fairness, isolation, and throughput (FIT) tradeoffs seem more interesting to me than CAP.

Efficiency? Not sure how one measures fairness.

Re: Spanner vs. Calvin: distributed consistency at scale

#46

Post by abadid »

arielweisberg wrote: post #41
abadid wrote: post #18

Earlier quoted context omitted.

"The case for determinism in database systems" paper (which described the technology that became Calvin) was written in VLDB 2010. At least one VoltDB developer told me that command logging came from a talk we gave about this paper to your team.

I think they happened independently, but it's long enough ago that I might not recall if I or Ning had inspiration from somewhere. If you heard it from Ning or myself then it's probably what happened.

Yes Ariel, it was you who told me this! But I agree with jhugg that it was an obvious choice based on the VoltDB architecture.

Re: Spanner vs. Calvin: distributed consistency at scale

#47

Post by hendzen »

vgt wrote: post #28
fdsfsafasfdas wrote: post #26

Earlier quoted context omitted.

> This makes it difficult to open source without open sourcing a bunch of hardware. That's simply not true; there are many consumer-grade GPS clocks out there well within the bounds that spanner operates (iirc skew bounded at +- 5ms). Not only that, but you can bet that if spanner were open-sourced, you'd see additional pressure to lower the cost of that hardware. Not that the answer is any more nefarious: They don't…

A critical design feature of Spanner is owning the packets end-to-end (as in, between data centers and across oceans). This lets Google minimize the "A" in "CAP", and would be quite difficult to replicate outside of a network like Google's SDN. Spanner is the software, plus the network, plus the hardware. (work on Google Cloud)

+ The army of SREs monitoring it...

Re: Spanner vs. Calvin: distributed consistency at scale

#48

Post by z3t4 »

I think it's often a better strategy to do sharding or micro-services and if possible keep the service so small that it's state can fit in a single machine. If you can have data boundaries, like for example one customer do not need to access the data of another customer, then you can separate customers's data and place them in different databases.

Re: Spanner vs. Calvin: distributed consistency at scale

#49

Post by elvinyung »

z3t4 wrote: post #48

I think it's often a better strategy to do sharding or micro-services and if possible keep the service so small that it's state can fit in a single machine. If you can have data boundaries, like for example one customer do not need to access the data of another customer, then you can separate customers's data and place them in different databases.

The state can never fit on just a single machine, unless you're perfectly confident that single machine will never fail :)

Distributed consistency as discussed in this blog post is not really about scaling write throughput (which is the problem solved by horizontal/vertical partitioning), but rather about keeping replicas in sync with each other, seeing the same state. The usual suspects, MySQL and Postgres, don't really have any sort of replication that's totally synchronous (although they're getting there[1, 2]).

As for scaling writes, I agree that chopping up your Postgres database is the safest choice for now, but it's generally true that this is hacky, and kind of a pain to architect your application around it. Solutions like Spanner and FaunaDB aim to free the application developer from this burden, without having to give up the large feature set of relational databases by using a NoSQL database.

[1] https://dev.mysql.com/doc/refman/5.7/en/group-replication.ht...

[2] http://paquier.xyz/postgresql-2/postgres-10-quorum-sync/

Re: Spanner vs. Calvin: distributed consistency at scale

#50

Post by jhugg »

abadid wrote: post #46
arielweisberg wrote: post #41

Earlier quoted context omitted.

I think they happened independently, but it's long enough ago that I might not recall if I or Ning had inspiration from somewhere. If you heard it from Ning or myself then it's probably what happened.

Yes Ariel, it was you who told me this! But I agree with jhugg that it was an obvious choice based on the VoltDB architecture.

lol
Post reply on HN