The 2016 release of SQL Server promises an amazing benefit to organizations of all sizes with its Stretch Database offering. Stretch Database allows companies to use on-premises instances of SQL Server to “stretch” their data into the Microsoft Azure SQL Database. It gives the user control of what’s extended into the cloud, whether stretching an entire database, selecting tables or just choosing a subset of data within a specific table.
Why adopt Stretch Database? Here are five simple reasons.
Projects in the financial services sector commonly specify the need for seven years of data retention. Actual usage suggests that having one year’s worth of readily accessible data will satisfy more than 90 percent of all the questions the analysts were asking. Imagine if you could remove 6/7 of the data in your storage area network (SAN). Next year’s budget won’t require adding additional storage, as you’d be able to more effectively use your current resources to solve today’s problems without the burden of carrying yesterday’s data debt.
Introduction to Cloud Adoption
Many organizations are nervous about using cloud resources. Look at Stretch Database as a low-risk opportunity for testing externally hosted data. All of your existing infrastructure remains intact and, if you decide this set of data wasn’t a good fit for the cloud, you migrate it back down – no harm, no foul.
Azure SQL Database allows users to pay for performance, so if an “S0” level is sufficient for day-to-day needs, then companies pay only for that tier. If, at year end, you realize you’re going to need more performance to address processing needs, it’s a literal click of the button to get greater performance out of your stretched database. The beautiful part of this is when you’re done processing, you step back down to your normal processing tier.
The Stretch Database is a form of partitioning, but, unlike SQL Server’s table partitioning, there’s no need to restructure tables to make it work. In the financial services example, if six years’ worth of data is in Azure storage and one year is stored locally, a query asking for all the transactions in the past 30 days immediately eliminates 85 percent of the data from being searched. If that data were only stored on-premises, then you would need to have created and maintained a suitable index to get that level of performance.
Easily the best part of adopting Stretch Database is the work you don’t have to do. The changes to the database are transparent to the users. Your data is either stretched or it’s not. There are no code changes required to calling applications, extract, transform and load (ETL), data visualization or your backup strategy. All the tools you’re using now will continue to work without the need to write, test, and implement specific code for data stretched into the cloud.
The 2016 release of SQL Server is another great step toward hybrid data solutions. One that optimizes your local investment while leveraging the Azure platform for its stability, security and scalability. Interested in learning more? Check out the video below from Steven Cardella for a demonstration on how to configure SQL Server 2016 Stretch Database.