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…
120K distributed consistent writes per second with Calvin
11–20 of 73 posts
Re: 120K distributed consistent writes per second with Calvin
#12This 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?
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"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.
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
#14This 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…
On mobile so cannot read article
Re: 120K distributed consistent writes per second with Calvin
#15This 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…
I've personally seen a Cassandra ring go to more than 2M ops/sec.
Re: 120K distributed consistent writes per second with Calvin
#16Earlier 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…
Re: 120K distributed consistent writes per second with Calvin
#17Earlier 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.
Re: 120K distributed consistent writes per second with Calvin
#18Re: 120K distributed consistent writes per second with Calvin
#19Earlier 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…
Whether Apple's leadership agrees with me is another question. :)
Re: 120K distributed consistent writes per second with Calvin
#20This 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…
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.