Live data from Hacker News

120K distributed consistent writes per second with Calvin

fauna.com

11–20 of 73 posts

Re: 120K distributed consistent writes per second with Calvin

#11
post #10

This seems cool, and I sincerely wish them nothing but success. That said, I had a major sense of déjà vu while reading this post -- I worked at FoundationDB prior to the Apple acquisition, when we published a blog post with a very similar feel: http://web.archive.org/web/20150325003241/http://blog.founda... I'm not trying to make a comparison between a system I used to work on and one that I frankly know little to n…

Bah! I was so dissappointed when I heard about the Apple acquisition of FoundationDB. Will any of the technology behind it ever see the light of day?

Re: 120K distributed consistent writes per second with Calvin

#12
post #10

This seems cool, and I sincerely wish them nothing but success. That said, I had a major sense of déjà vu while reading this post -- I worked at FoundationDB prior to the Apple acquisition, when we published a blog post with a very similar feel: http://web.archive.org/web/20150325003241/http://blog.founda... I'm not trying to make a comparison between a system I used to work on and one that I frankly know little to n…

Bah! I was so dissappointed when I heard about the Apple acquisition of FoundationDB. Will any of the technology behind it ever see the light of day?

Unfortunately I'm the last person to ask. While I did start at FoundationDB pretty early (second employee), I ceased to be involved at the point of the acquisition, and beyond that I've only heard a few rumors from former coworkers.

As a business it was always an ambitious effort, and I'm not sure what could or should have been done differently. But since then I've used a number of other systems and thought to myself "boy, I wish I had FDB right now."

Re: 120K distributed consistent writes per second with Calvin

#13
post #8
post #7

"Calvin's primary trade-off is that it doesn't support session transactions, so it's not well suited for SQL. Instead, transactions must be submitted atomically. Session transactions in SQL were designed for analytics, specifically human beings sitting at a workstation. They are pure overhead in a high-throughput operational context." Is this specifically for distributed SQL only? I think there are some scalable SQL…

Calvin is a generalized consistency protocol, that we use in FaunaDB to support relational semantics (but not SQL) in our database. Multi-query transactions can be useful, but the FaunaDB query language is functional, rather than declarative like SQL, so composing queries that can do everything you want is usually easier than SQL.

How would you perform the classic "transfer money from one account to another" operation?

Would you create a single operation that reads one record, checks that it's enough, then adds the amount to another record?

Or maybe you'd first read both accounts, then issue a conditional write operation that makes sure the data hasn't changed before doing the write?

Re: 120K distributed consistent writes per second with Calvin

#14
post #10

This seems cool, and I sincerely wish them nothing but success. That said, I had a major sense of déjà vu while reading this post -- I worked at FoundationDB prior to the Apple acquisition, when we published a blog post with a very similar feel: http://web.archive.org/web/20150325003241/http://blog.founda... I'm not trying to make a comparison between a system I used to work on and one that I frankly know little to n…

Totally off topic - why does O2 UK block this without adult verification?

On mobile so cannot read article

Re: 120K distributed consistent writes per second with Calvin

#15
post #2

This is a new one to me...the referenced paper is here: http://cs.yale.edu/homes/thomson/publications/calvin-sigmod1... How does this algorithm compare to whatever Google Spanner does?

That's a good and complicated question. They both are fully ACID-compliant systems. The biggest difference as a developer is that Calvin never blocks reads, contested or not. You get causally consistent single-replica reads with no coordination. This makes the read performance equivalent to something like Cassandra at CONSISTENCY.ONE, without giving up the cross-partition write linearization of something like Spanner…

Can Calvin scale beyond the OP claim?

I've personally seen a Cassandra ring go to more than 2M ops/sec.

Re: 120K distributed consistent writes per second with Calvin

#16
post #12

Earlier quoted context omitted.

Bah! I was so dissappointed when I heard about the Apple acquisition of FoundationDB. Will any of the technology behind it ever see the light of day?

Unfortunately I'm the last person to ask. While I did start at FoundationDB pretty early (second employee), I ceased to be involved at the point of the acquisition, and beyond that I've only heard a few rumors from former coworkers. As a business it was always an ambitious effort, and I'm not sure what could or should have been done differently. But since then I've used a number of other systems and thought to myself…

Do you know what Apple is using it for, and at what scale?

Re: 120K distributed consistent writes per second with Calvin

#17
post #15

Earlier quoted context omitted.

That's a good and complicated question. They both are fully ACID-compliant systems. The biggest difference as a developer is that Calvin never blocks reads, contested or not. You get causally consistent single-replica reads with no coordination. This makes the read performance equivalent to something like Cassandra at CONSISTENCY.ONE, without giving up the cross-partition write linearization of something like Spanner…

Can Calvin scale beyond the OP claim? I've personally seen a Cassandra ring go to more than 2M ops/sec.

Yes. This isn't near the top end, more like what happens when we run benchmarks on a reasonable web infrastructure class cluster. This is still only 5 machines in each datacenter.

Re: 120K distributed consistent writes per second with Calvin

#19
post #12

Earlier quoted context omitted.

Bah! I was so dissappointed when I heard about the Apple acquisition of FoundationDB. Will any of the technology behind it ever see the light of day?

Unfortunately I'm the last person to ask. While I did start at FoundationDB pretty early (second employee), I ceased to be involved at the point of the acquisition, and beyond that I've only heard a few rumors from former coworkers. As a business it was always an ambitious effort, and I'm not sure what could or should have been done differently. But since then I've used a number of other systems and thought to myself…

Another former-FoundationDB guy here (hi Ian!), and I actually think the business case for Apple open sourcing is very strong. I'm a fan of the layered architecture we chose, but building efficient and powerful layers on top of the core key-value store is a serious engineering effort in its own right. By encouraging an open-source layer ecosystem (and operational and deployment tools), Apple could leverage its investment in the core technology more effectively.

Whether Apple's leadership agrees with me is another question. :)

Re: 120K distributed consistent writes per second with Calvin

#20
post #10

This seems cool, and I sincerely wish them nothing but success. That said, I had a major sense of déjà vu while reading this post -- I worked at FoundationDB prior to the Apple acquisition, when we published a blog post with a very similar feel: http://web.archive.org/web/20150325003241/http://blog.founda... I'm not trying to make a comparison between a system I used to work on and one that I frankly know little to n…

That's one of my favorite benchmarks!

You're right that distributed consistency is a beginning, not an end. We are painfully aware of all the startups that have died or are dying on this beach.

It's great to be scalable and consistent, but you have to be more than an operationally-better replacement for legacy SQL. That's one reason we built our own query language that plays to modern application development patterns (serverless, functional, change feeds, etc.) instead of the typical slow, never-quite-there, distributed SQL planner.

Post reply on HN