Trade-offs all around in SQL Server Data Services (SSDS)
David Robinson talks about concurrency here. Roger comments about David's take on concurrency here. In SSDS, we make several important trade-offs:
a. We give up some latency because of quorum based commits in favor of aggregate throughput. Theoretically this approach lets you hyper partition the data to get extreme throughput if that is what the app needs. We have to remember SSDS is a big train or a bus and not a finely tuned Ferrari. I believe that is what David was referring to in his article.
b. Trade-off single system image and backward compatibility of existing SQL Server applications for lights out operations, high scale and availability. I know this raises a lot of eyebrows. But giving up backward compatibility allowed us lots of freedom in choosing a data model and optimize for a completely different cost point.
It is important we understand these nuances when dealing with a large scale distributed data service.
