POC SQL 2014

Notas del editor

• #2: In this session we will take a closer look at the unique design points of Microsoft SQL Server’s in-memory solution and the significant impact it can have on your business.
• #3: This is the track agenda slide, meant to orient your audience on where they are in the day. This session is the first session in the Data Platform track, and should be delivered before “Drive Business Faster with SQL Server 2014 In-Memory Technologies” and “New Hybrid Cloud Scenarios with SQL Server 2014.” Please edit this slide to align with your event’s agenda.
• #4: Before we get into the details of in-memory, lets talk about why so many people in today’s business world are interested in this technology. One of the key goals businesses are trying to achieve today is getting to a state—or getting closer to a state—where the business can be driven in real-time, powered by real-time insights. The barriers here are speed and throughput. With data volumes getting larger and larger how do you gain insights quickly across your transactional business, your historical data, third party data (relational or non-relational), so you can make better and faster business decisions. This is the heart of the problem that in-memory technology helps to solve. With Microsoft SQL Server 2014 in-memory technologies built-in across all database workloads, we’ll show how we can drive significantly faster transactions, faster queries and faster insights. It also increases throughput in terms of number of users. The key thing to remember in this presentation is that all of the in-memory capabilities we will share are built into SQL Server 2014, meaning a single sku, not options and add-ons.
• #5: Now lets take a closer look at how we can impact your business with our in-memory technology. We are the only provider to date that can speed transactions as well as queries and insights with in-memory technology optimized for each workload: OLTP, data warehousing, and analytics. With our new in-memory OLTP engine in SQL Server 2014, we have customers that have seen up to 30x faster transaction processing. I am not talking about query speed, but actual transaction write speed, up to 30x faster. I know many of you might be thinking, well Oracle and other database vendors are talking 100x. What they are talking about is query speed, not transactional speed. We are the only vendor that delivers an in-memory engine designed for OLTP transaction performance increase. There’s also built-in In-Memory columnstore for data warehousing workloads to speed queries. We were already benchmarking over 100x performance gains with many customers in the SQL Server 2012 release of the in-memory columnstore. With SQL Server 2014, the in-memory columnstore gets even better, we will talk about that in just a few minutes. Again, we can also increase query speed by over 100x. Finally we offer business users the ability to analyze data and data models much faster with built-in in-memory capabilities for Excel through PowerPivot, and Analysis Services. The benefit is that you can analyze billions of rows of data per second in Excel. Meaning a business user can analyze data of nearly any size with the tools they are most familiar with. This is what we mean when we say “driving real-time business with real-time insights.” We can significantly speed your transaction business tied to your revenue stream. We can massively speed the process to analyze both real-time transaction data, along with historical and third party data from IT or business users. This is why we are already seeing in-memory technologies transforming the way businesses run.
• #6: Lets start off by taking a look at how in-memory technologies have evolved in SQL Server. This may be a surprise to many of you, but our in-memory journey actually started way back in SQL Server 2008 R2, when our engineering team made a key design decision to build in-memory technology into the core data platform, rather than acquire and stitch in an in-memory solution to run in parallel to the core database. Around this timeframe, both Oracle and IBM went down the acquire-and-stitch route: Oracle acquired TimesTen in-memory database and IBM acquired Natiza. The challenge with the acquire-and-stitch solution is that in-memory impacts to the overall database, which in the past were designed to run on disk. So the challenge we often hear from customers using TimesTen or Natiza is that using in-memory breaks other core DB2 and Oracle database functionality. For example, we have heard from many customers that RAC break when you use TimesTen. Not only is there a functional compatibility issue, the customer is also forced to learn a new set of APIs because it is a completely different database. This is not the design approach we took. We believe our customers want to utilize other key capabilities that SQL Server and the broader Microsoft Data Platform have to offer in conjunction with in-memory. They don’t want to use a different tool set for in-memory database than they do for disk database, they still wan to use T-SQL and SQL Server management when enabling in-memory. This is the unique design approach we took back when we first started improving analytics by building in-memory into PowerPivot for billions for rows of data analysis in Excel. Then in SQL Server 2012, we expanded our in-memory footprint with the same built-in approach by adding in-memory to Analysis Services so IT could build data models much faster, and introduced an in-memory column store that could improve query speeds by 100x. With SQL Server 2014, we are covering the final workload by introducing an in-memory OLTP solution—or in-memory rowstore—to significantly speed transactional performance. We also enhanced the in-memory columnstore with faster performance and significantly higher data compression so memory utilization can be optimized. Now, here’s one point to note if you listened to the keynote at Oracle openworld. Larry announced a new in-memory columnstore that would be built-in to the core database. So as you can see Oracle is following our footsteps and realizing the stitch strategy doesn’t work when it comes to something as critical to the overall database as in-memory. And he also mentioned that it will be an optio—we all know what that means. And their new solution is in an early beta. SQL Server 2014 is our third release of in-memory solutions across the data platform, and in a single sku, no options or add ons.
• #7: Lets start off by taking a look at how in-memory technologies have evolved in SQL Server. This may be a surprise to many of you, but our in-memory journey actually started way back in SQL Server 2008 R2, when our engineering team made a key design decision to build in-memory technology into the core data platform, rather than acquire and stitch in an in-memory solution to run in parallel to the core database. Around this timeframe, both Oracle and IBM went down the acquire-and-stitch route: Oracle acquired TimesTen in-memory database and IBM acquired Natiza. The challenge with the acquire-and-stitch solution is that in-memory impacts to the overall database, which in the past were designed to run on disk. So the challenge we often hear from customers using TimesTen or Natiza is that using in-memory breaks other core DB2 and Oracle database functionality. For example, we have heard from many customers that RAC break when you use TimesTen. Not only is there a functional compatibility issue, the customer is also forced to learn a new set of APIs because it is a completely different database. This is not the design approach we took. We believe our customers want to utilize other key capabilities that SQL Server and the broader Microsoft Data Platform have to offer in conjunction with in-memory. They don’t want to use a different tool set for in-memory database than they do for disk database, they still wan to use T-SQL and SQL Server management when enabling in-memory. This is the unique design approach we took back when we first started improving analytics by building in-memory into PowerPivot for billions for rows of data analysis in Excel. Then in SQL Server 2012, we expanded our in-memory footprint with the same built-in approach by adding in-memory to Analysis Services so IT could build data models much faster, and introduced an in-memory column store that could improve query speeds by 100x. With SQL Server 2014, we are covering the final workload by introducing an in-memory OLTP solution—or in-memory rowstore—to significantly speed transactional performance. We also enhanced the in-memory columnstore with faster performance and significantly higher data compression so memory utilization can be optimized. Now, here’s one point to note if you listened to the keynote at Oracle openworld. Larry announced a new in-memory columnstore that would be built-in to the core database. So as you can see Oracle is following our footsteps and realizing the stitch strategy doesn’t work when it comes to something as critical to the overall database as in-memory. And he also mentioned that it will be an optio—we all know what that means. And their new solution is in an early beta. SQL Server 2014 is our third release of in-memory solutions across the data platform, and in a single sku, no options or add ons.
• #8: This is the track agenda slide, meant to orient your audience on where they are in the day. This session is the first session in the Data Platform track, and should be delivered before “Drive Business Faster with SQL Server 2014 In-Memory Technologies” and “New Hybrid Cloud Scenarios with SQL Server 2014.” Please edit this slide to align with your event’s agenda.
• #9: Before we jump into Microsoft’s in-memory engineering design points, lets take a look at a couple of key trends that have impacted our design. One, of course, is the significant drop in-memory pricing that makes in-memory databases feasible for customers. The second is around CPU performance flattening out, meaning that just throwing more compute at a problem may not resolve performance bottlenecks. Our design approach took into account how to better utilize existing CPU capacity, as we often hear from customers that typical CPU utilization is below the 50% mark—often due to contention.
• #10: Lets start off by taking a look at how in-memory technologies have evolved in SQL Server. This may be a surprise to many of you, but our in-memory journey actually started way back in SQL Server 2008 R2, when our engineering team made a key design decision to build in-memory technology into the core data platform, rather than acquire and stitch in an in-memory solution to run in parallel to the core database. Around this timeframe, both Oracle and IBM went down the acquire-and-stitch route: Oracle acquired TimesTen in-memory database and IBM acquired Natiza. The challenge with the acquire-and-stitch solution is that in-memory impacts to the overall database, which in the past were designed to run on disk. So the challenge we often hear from customers using TimesTen or Natiza is that using in-memory breaks other core DB2 and Oracle database functionality. For example, we have heard from many customers that RAC break when you use TimesTen. Not only is there a functional compatibility issue, the customer is also forced to learn a new set of APIs because it is a completely different database. This is not the design approach we took. We believe our customers want to utilize other key capabilities that SQL Server and the broader Microsoft Data Platform have to offer in conjunction with in-memory. They don’t want to use a different tool set for in-memory database than they do for disk database, they still wan to use T-SQL and SQL Server management when enabling in-memory. This is the unique design approach we took back when we first started improving analytics by building in-memory into PowerPivot for billions for rows of data analysis in Excel. Then in SQL Server 2012, we expanded our in-memory footprint with the same built-in approach by adding in-memory to Analysis Services so IT could build data models much faster, and introduced an in-memory column store that could improve query speeds by 100x. With SQL Server 2014, we are covering the final workload by introducing an in-memory OLTP solution—or in-memory rowstore—to significantly speed transactional performance. We also enhanced the in-memory columnstore with faster performance and significantly higher data compression so memory utilization can be optimized. Now, here’s one point to note if you listened to the keynote at Oracle openworld. Larry announced a new in-memory columnstore that would be built-in to the core database. So as you can see Oracle is following our footsteps and realizing the stitch strategy doesn’t work when it comes to something as critical to the overall database as in-memory. And he also mentioned that it will be an optio—we all know what that means. And their new solution is in an early beta. SQL Server 2014 is our third release of in-memory solutions across the data platform, and in a single sku, no options or add ons.
• #11: Lets take a look at the first design point our engineering team took back during the release of SQL Server 2008 R2, which was to build-in in-memory technology and make it pervasive throughout the platform—from analytics, to data warehousing to OLTP. One of the main benefits of building in-memory into the platform is that you as the customer don’t have to learn new development tools or new APIs and you can take advantage of all of the other rich features and capabilities in SQL Server along with in-memory. You can even take advantage of other data platform services on-premises or in the cloud with Microsoft Azure along with in-memory performance. This is not the case when you look at competitive technologies that have chosen to acquire-and-stitch together a solution like TimesTen from Oracle or Natiza from IBM. The stitched solutions often break core database functionality for both DB2 and Oracle as the core databases were designed to run on disk. For example, RAC does not work with TimesTen and you have to learn a whole new set of APIs and tools to use TimesTen. Ferranti computer systems—we’ll take a closer look them later in the session—designs software for utility companies. They are helping to transform the utility industry and revolutionize the way electricity is consumed and sold by improving the way utilities leverage data. They not only need the help of in-memory technology to quickly process large amounts of relational data, but they also need a solution for tackling non-relational data. Because SQL Server 2014 offered the built-in approach for in-memory, they were able to utilize in-memory OLTP as well as our Microsoft Azure HDInsight service to tackle big data. They are now able to write more than 200 million rows in 15 minutes. The last point I will make on “built-in” is that because we have designed in-memory into the platform, it’s not only pervasive throughout the platform across all workloads, it is also built-in to a single enterprise sku, so you don’t have to pay more or purchase additional sku’s to gain all of the in-memory capabilities.
• #12: This is the track agenda slide, meant to orient your audience on where they are in the day. This session is the first session in the Data Platform track, and should be delivered before “Drive Business Faster with SQL Server 2014 In-Memory Technologies” and “New Hybrid Cloud Scenarios with SQL Server 2014.” Please edit this slide to align with your event’s agenda.
• #13: Now lets take a closer look at our unique in-memory design points—from our engineers deciding to make in-memory pervasive by building it in to the data platform to how we have made it easy to implement in-memory into your applications.
• #14: Lets take a look at the first design point our engineering team took back during the release of SQL Server 2008 R2, which was to build-in in-memory technology and make it pervasive throughout the platform—from analytics, to data warehousing to OLTP. One of the main benefits of building in-memory into the platform is that you as the customer don’t have to learn new development tools or new APIs and you can take advantage of all of the other rich features and capabilities in SQL Server along with in-memory. You can even take advantage of other data platform services on-premises or in the cloud with Microsoft Azure along with in-memory performance. This is not the case when you look at competitive technologies that have chosen to acquire-and-stitch together a solution like TimesTen from Oracle or Natiza from IBM. The stitched solutions often break core database functionality for both DB2 and Oracle as the core databases were designed to run on disk. For example, RAC does not work with TimesTen and you have to learn a whole new set of APIs and tools to use TimesTen. Ferranti computer systems—we’ll take a closer look them later in the session—designs software for utility companies. They are helping to transform the utility industry and revolutionize the way electricity is consumed and sold by improving the way utilities leverage data. They not only need the help of in-memory technology to quickly process large amounts of relational data, but they also need a solution for tackling non-relational data. Because SQL Server 2014 offered the built-in approach for in-memory, they were able to utilize in-memory OLTP as well as our Microsoft Azure HDInsight service to tackle big data. They are now able to write more than 200 million rows in 15 minutes. The last point I will make on “built-in” is that because we have designed in-memory into the platform, it’s not only pervasive throughout the platform across all workloads, it is also built-in to a single enterprise sku, so you don’t have to pay more or purchase additional sku’s to gain all of the in-memory capabilities.
• #15: Lets take a look at the first design point our engineering team took back during the release of SQL Server 2008 R2, which was to build-in in-memory technology and make it pervasive throughout the platform—from analytics, to data warehousing to OLTP. One of the main benefits of building in-memory into the platform is that you as the customer don’t have to learn new development tools or new APIs and you can take advantage of all of the other rich features and capabilities in SQL Server along with in-memory. You can even take advantage of other data platform services on-premises or in the cloud with Microsoft Azure along with in-memory performance. This is not the case when you look at competitive technologies that have chosen to acquire-and-stitch together a solution like TimesTen from Oracle or Natiza from IBM. The stitched solutions often break core database functionality for both DB2 and Oracle as the core databases were designed to run on disk. For example, RAC does not work with TimesTen and you have to learn a whole new set of APIs and tools to use TimesTen. Ferranti computer systems—we’ll take a closer look them later in the session—designs software for utility companies. They are helping to transform the utility industry and revolutionize the way electricity is consumed and sold by improving the way utilities leverage data. They not only need the help of in-memory technology to quickly process large amounts of relational data, but they also need a solution for tackling non-relational data. Because SQL Server 2014 offered the built-in approach for in-memory, they were able to utilize in-memory OLTP as well as our Microsoft Azure HDInsight service to tackle big data. They are now able to write more than 200 million rows in 15 minutes. The last point I will make on “built-in” is that because we have designed in-memory into the platform, it’s not only pervasive throughout the platform across all workloads, it is also built-in to a single enterprise sku, so you don’t have to pay more or purchase additional sku’s to gain all of the in-memory capabilities.
• #16: Lets take a look at the first design point our engineering team took back during the release of SQL Server 2008 R2, which was to build-in in-memory technology and make it pervasive throughout the platform—from analytics, to data warehousing to OLTP. One of the main benefits of building in-memory into the platform is that you as the customer don’t have to learn new development tools or new APIs and you can take advantage of all of the other rich features and capabilities in SQL Server along with in-memory. You can even take advantage of other data platform services on-premises or in the cloud with Microsoft Azure along with in-memory performance. This is not the case when you look at competitive technologies that have chosen to acquire-and-stitch together a solution like TimesTen from Oracle or Natiza from IBM. The stitched solutions often break core database functionality for both DB2 and Oracle as the core databases were designed to run on disk. For example, RAC does not work with TimesTen and you have to learn a whole new set of APIs and tools to use TimesTen. Ferranti computer systems—we’ll take a closer look them later in the session—designs software for utility companies. They are helping to transform the utility industry and revolutionize the way electricity is consumed and sold by improving the way utilities leverage data. They not only need the help of in-memory technology to quickly process large amounts of relational data, but they also need a solution for tackling non-relational data. Because SQL Server 2014 offered the built-in approach for in-memory, they were able to utilize in-memory OLTP as well as our Microsoft Azure HDInsight service to tackle big data. They are now able to write more than 200 million rows in 15 minutes. The last point I will make on “built-in” is that because we have designed in-memory into the platform, it’s not only pervasive throughout the platform across all workloads, it is also built-in to a single enterprise sku, so you don’t have to pay more or purchase additional sku’s to gain all of the in-memory capabilities.
• #17: Lets take a look at the first design point our engineering team took back during the release of SQL Server 2008 R2, which was to build-in in-memory technology and make it pervasive throughout the platform—from analytics, to data warehousing to OLTP. One of the main benefits of building in-memory into the platform is that you as the customer don’t have to learn new development tools or new APIs and you can take advantage of all of the other rich features and capabilities in SQL Server along with in-memory. You can even take advantage of other data platform services on-premises or in the cloud with Microsoft Azure along with in-memory performance. This is not the case when you look at competitive technologies that have chosen to acquire-and-stitch together a solution like TimesTen from Oracle or Natiza from IBM. The stitched solutions often break core database functionality for both DB2 and Oracle as the core databases were designed to run on disk. For example, RAC does not work with TimesTen and you have to learn a whole new set of APIs and tools to use TimesTen. Ferranti computer systems—we’ll take a closer look them later in the session—designs software for utility companies. They are helping to transform the utility industry and revolutionize the way electricity is consumed and sold by improving the way utilities leverage data. They not only need the help of in-memory technology to quickly process large amounts of relational data, but they also need a solution for tackling non-relational data. Because SQL Server 2014 offered the built-in approach for in-memory, they were able to utilize in-memory OLTP as well as our Microsoft Azure HDInsight service to tackle big data. They are now able to write more than 200 million rows in 15 minutes. The last point I will make on “built-in” is that because we have designed in-memory into the platform, it’s not only pervasive throughout the platform across all workloads, it is also built-in to a single enterprise sku, so you don’t have to pay more or purchase additional sku’s to gain all of the in-memory capabilities.
• #18: Lets take a look at the first design point our engineering team took back during the release of SQL Server 2008 R2, which was to build-in in-memory technology and make it pervasive throughout the platform—from analytics, to data warehousing to OLTP. One of the main benefits of building in-memory into the platform is that you as the customer don’t have to learn new development tools or new APIs and you can take advantage of all of the other rich features and capabilities in SQL Server along with in-memory. You can even take advantage of other data platform services on-premises or in the cloud with Microsoft Azure along with in-memory performance. This is not the case when you look at competitive technologies that have chosen to acquire-and-stitch together a solution like TimesTen from Oracle or Natiza from IBM. The stitched solutions often break core database functionality for both DB2 and Oracle as the core databases were designed to run on disk. For example, RAC does not work with TimesTen and you have to learn a whole new set of APIs and tools to use TimesTen. Ferranti computer systems—we’ll take a closer look them later in the session—designs software for utility companies. They are helping to transform the utility industry and revolutionize the way electricity is consumed and sold by improving the way utilities leverage data. They not only need the help of in-memory technology to quickly process large amounts of relational data, but they also need a solution for tackling non-relational data. Because SQL Server 2014 offered the built-in approach for in-memory, they were able to utilize in-memory OLTP as well as our Microsoft Azure HDInsight service to tackle big data. They are now able to write more than 200 million rows in 15 minutes. The last point I will make on “built-in” is that because we have designed in-memory into the platform, it’s not only pervasive throughout the platform across all workloads, it is also built-in to a single enterprise sku, so you don’t have to pay more or purchase additional sku’s to gain all of the in-memory capabilities.
• #19: Lets take a look at the first design point our engineering team took back during the release of SQL Server 2008 R2, which was to build-in in-memory technology and make it pervasive throughout the platform—from analytics, to data warehousing to OLTP. One of the main benefits of building in-memory into the platform is that you as the customer don’t have to learn new development tools or new APIs and you can take advantage of all of the other rich features and capabilities in SQL Server along with in-memory. You can even take advantage of other data platform services on-premises or in the cloud with Microsoft Azure along with in-memory performance. This is not the case when you look at competitive technologies that have chosen to acquire-and-stitch together a solution like TimesTen from Oracle or Natiza from IBM. The stitched solutions often break core database functionality for both DB2 and Oracle as the core databases were designed to run on disk. For example, RAC does not work with TimesTen and you have to learn a whole new set of APIs and tools to use TimesTen. Ferranti computer systems—we’ll take a closer look them later in the session—designs software for utility companies. They are helping to transform the utility industry and revolutionize the way electricity is consumed and sold by improving the way utilities leverage data. They not only need the help of in-memory technology to quickly process large amounts of relational data, but they also need a solution for tackling non-relational data. Because SQL Server 2014 offered the built-in approach for in-memory, they were able to utilize in-memory OLTP as well as our Microsoft Azure HDInsight service to tackle big data. They are now able to write more than 200 million rows in 15 minutes. The last point I will make on “built-in” is that because we have designed in-memory into the platform, it’s not only pervasive throughout the platform across all workloads, it is also built-in to a single enterprise sku, so you don’t have to pay more or purchase additional sku’s to gain all of the in-memory capabilities.
• #20: So Ferranti is just on example. But imagine what you could do with you business if you could determine customer purchasing trends in real-time—not at the end of the day, week or month—but as they happened. And if you could tie that to social sentiment data in real-time and combine it with historical data or current events or even mobile data. How could you transform your business? Speed and throughput of data are at the heart of this puzzle and in-memory technology will revolutionize databases, much like virtualization revolutionized physical compute. Imagine a new level of customer personalization by acting on a world of data in real-time