109: (animated-1)
There is a new feature in Sql Server 2016 called "stretch database". This feature is amazing in a very perverse way: everything is wrong with it.

Starting with a name: it's not a database. This is a feature that you can apply on a table-by-table basis. The gist of the feature is that now you can take part of the data from a table residing in Sql Server 2016 instance (whether on-premise or on VM in the cloud) and move and store it in Sql Azure.

Technical limitations that preclude from using this feature are amazing. Here is the small subset:

Computed columns
Check constraints
Default constraints
Foreign key constraints that reference the table
Indexed views that reference the table

To be amazed even more, see the full list.

Okay, assume you have some [useless] table that has none of these "limitations". How much can you save by moving historical data to Azure? Here is the price list. The least expensive "performance level" will cost you $930/month. Ouch, but okay, let's estimate the size of data that can provide savings. With current hard drive prices, yearly cost of 1TB is around $10. $20, if we count mirroring. $930 * 12 / $20 = 560TB. So if you "stretch" more than 560TB into cloud, you may save something. (FYI, if you dedicate 1 Gbps link solely to the task of moving 560TB to the cloud, it will take 65 days).

Oops again though! The pricing page says "During preview, you can stretch up to 60TB of data with Stretch Database. Actual size limits will be determined as we get closer to general availability". However, the home page for the feature says "The size of the remote portion of a database with enabled for Stretch is limited only by the Azure SQL Database service tier". And the biggest tier, as we know from this page, is miserable 1TB for Premuim P11 tier. Moreover, the feature home page says that the price for the Azure part of the database is defined by the price of the corresponding Sql Azure tier ($7,000/month for P11, not $930 as described in the direct link to stretch database pricing).

I hope it is somewhat clearer now how insane is this "offering". That said, please don't misunderstand me. Sql Server by itself is an awesome platform. Azure by itself is an awesome platform. Combination of the two (Sql Azure or regular Sql Server running on Azure VM) can be even more awesome (as always, you need to carefully weight all pros and cons). But this feature? Nah. It's just some PM got carried away without proper check from someone with common sense.
109: (animated-1)
For the last 8 years I have been telling people: "CAP is misleading", "don't use CAP terms and definitions", "just forget about it, it's useless". Suddenly, today I stumble on relatively new article on the topic. I don't agree with author on all points he makes (like, why is that he thinks mvcc is not linearizable?), but most points are right on.

The CAP theorem is too simplistic and too widely misunderstood to be of much use for characterizing systems. Therefore I ask that we retire all references to the CAP theorem, stop talking about the CAP theorem, and put the poor thing to rest. Instead, we should use more precise terminology to reason about our trade-offs. (Yes, I realize the irony of writing a blog post about the very topic that I am asking people to stop writing about).

Many systems are neither consistent nor available under the CAP theorem’s definitions. However, I’ve never heard anyone call their system just “P”, presumably because it looks bad. But it’s not bad – it may be a perfectly reasonable design, it just doesn’t fit one of the two CP/AP buckets.

Even though most software doesn’t neatly fit one of those two buckets, people try to shoehorn software into one of the two buckets anyway, thereby inevitably changing the meaning of “consistency” or “availability” to whatever definition suits them. Unfortunately, if the meaning of the words is changed, the CAP theorem no longer applies, and thus the CP/AP distinction is rendered completely meaningless.

Whatever you do, please stop talking about CP and AP, because they just don’t make any sense.


https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

Profile

109: (Default)
109

March 2019

S M T W T F S
     12
3456789
101112131415 16
17181920212223
24252627282930
31      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags