4 ms·

Spanner's approach requires help from hardware and several full time employees maintaining and ensuring the uncertainty guarantees. This increases the cost of t

by abadid 8y ago

Spanner's approach requires help from hardware and several full time employees maintaining and ensuring the uncertainty guarantees. This increases the cost of the maintaining the system, which for Cloud Spanner is partially passed on to the end users. If you can build a system that doesn't require time synchronization, yet doesn't have any significant drawbacks relative to what Spanner provides, you'd be better off using this alternative system.

haberman 8y ago
> If you can build a system that doesn't require time synchronization, yet doesn't have any significant drawbacks relative to what Spanner provides, you'd be better off using this alternative system. But you describe exactly the drawbacks of giving up time synchronization: > The main downside of the first category is scalability. A server can process a fixed number of messages per second. If every transaction in the system participates in the same consensus protocol, the same set of servers vote on every transaction. Since voting requires communication, the number of votes per second is limited by the number of messages each server can handle. This limits the total amount of transactions per second that the system can handle. How is "worse scalability" not a significant drawback? This just sounds like an engineering tradeoff. I don't think engineering tradeoffs are the same as controversy. I get that your group's DB takes a different approach. But "blaming" Spanner for making a different trade-off doesn't come off well (I approached the article with an open mind).
- mrep 8y ago
  You beat me to it. Also, per > Calvin was able to achieve a throughput of over 500,000 transactions per second. For comparison, Amazon.com and NASDAQ likely process no more than 10,000 orders/trades per second even during peak workloads. Maybe if you are only considering the small scope of just the order transactions, but they are actually writing way more data to their databases such as logs, metrics, current state for things like shopping carts. In my experience, what teams have done is split their data off into their own siloed database to minimize scaling problems, but this becomes super painful when you want to join your data with others. If spanner can hold all of our data, scale, and handle joining across all of it, that sounds like a huge win.
ysleepy 8y ago
You clearly have an agenda here, the blog post contains little information while spreading FUD. Never heard of calvin and will now avoid it.
- atombender 8y ago
  Calvin is a research database, described in a paper and also provided as an open source project, but last I checked, it was pure research, not usable for real work. The "production version" of Calvin is arguably FaunaDB, which is a hosted SaaS product. Abadi is a very well known and, as far as I know, respected database researcher. No need to avoid his work.

by abadid 8y ago

haberman 8y ago

> If you can build a system that doesn't require time synchronization, yet doesn't have any significant drawbacks relative to what Spanner provides, you'd be better off using this alternative system. But you describe exactly the drawbacks of giving up time synchronization: > The main downside of the first category is scalability. A server can process a fixed number of messages per second. If every transaction in the system participates in the same consensus protocol, the same set of servers vote on every transaction. Since voting requires communication, the number of votes per second is limited by the number of messages each server can handle. This limits the total amount of transactions per second that the system can handle. How is "worse scalability" not a significant drawback? This just sounds like an engineering tradeoff. I don't think engineering tradeoffs are the same as controversy. I get that your group's DB takes a different approach. But "blaming" Spanner for making a different trade-off doesn't come off well (I approached the article with an open mind).

mrep 8y ago
You beat me to it. Also, per > Calvin was able to achieve a throughput of over 500,000 transactions per second. For comparison, Amazon.com and NASDAQ likely process no more than 10,000 orders/trades per second even during peak workloads. Maybe if you are only considering the small scope of just the order transactions, but they are actually writing way more data to their databases such as logs, metrics, current state for things like shopping carts. In my experience, what teams have done is split their data off into their own siloed database to minimize scaling problems, but this becomes super painful when you want to join your data with others. If spanner can hold all of our data, scale, and handle joining across all of it, that sounds like a huge win.

ysleepy 8y ago

You clearly have an agenda here, the blog post contains little information while spreading FUD. Never heard of calvin and will now avoid it.

atombender 8y ago
Calvin is a research database, described in a paper and also provided as an open source project, but last I checked, it was pure research, not usable for real work. The "production version" of Calvin is arguably FaunaDB, which is a hosted SaaS product. Abadi is a very well known and, as far as I know, respected database researcher. No need to avoid his work.