Search results matching tags 'SQL Server 2008 R2', 'SQL Server 2008 and beyond', and 'SQL 11'http://sqlblog.com/search/SearchResults.aspx?o=DateDescending&tag=SQL+Server+2008+R2,SQL+Server+2008+and+beyond,SQL+11&orTags=0Search results matching tags 'SQL Server 2008 R2', 'SQL Server 2008 and beyond', and 'SQL 11'en-USCommunityServer 2.1 SP2 (Build: 61129.1)Blogging from the PASS Keynote : 2009-11-05http://sqlblog.com/blogs/aaron_bertrand/archive/2009/11/05/blogging-from-the-pass-keynote-2009-11-05.aspxThu, 05 Nov 2009 17:24:00 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:18568AaronBertrand<p>Bill Graziano took the stage and promised us the shortest keynote yet.&nbsp; He started by giving thanks to outgoing board members Greg Low, Pat Wright and Kevin Kline.&nbsp; Wayne Snyder took over and gave an emotional homage to Kevin, who gave 10 solid years to PASS.&nbsp; Very touching.&nbsp; Kevin left the stage to a standing ovation.</p><p>Introduced Brian Moran, Jeremiah Peschka and Thomas LaRock as the new Directors-at-Large, and Rushabh Mehta as the new President.&nbsp; Reaffirmed commitment to the community, and announced the PASS European Conference in Neuss, Germany, April 21-23, 2010.&nbsp; The North American summit is already scheduled for November 8-11, 2010, again in Seattle.&nbsp; (And if you <a href="http://www.sqlpass.org/summit/na2010" title="http://www.sqlpass.org/summit/na2010" target="_blank">register early enough</a>, you can get in for $995.)&nbsp; A lot of people who live in different time zones have expressed the desire to move the conference around, but I agree with Bill; having the conference this close to Microsoft provides enough benefit to offset the impact on travel.&nbsp; That's my opinion, of course. <br></p><p><br><b>Patrick Ortiz, Infrastructure Consulting Services, Dell</b> </p><p>Patrick came on and talked about the structure of Dell's operations involving Microsoft architecture (Exchange, SQL Server, SharePoint, etc.).&nbsp; Then he jumped into how they approach the combination of consolidation, disaster recovery, and configuration management.&nbsp; Apologies to Patrick, but there wasn't really anything exciting about his presentation; it seemed more that it should have been an elective session as opposed to a keynote for everyone in attendance.&nbsp; But I guess you get this privilege when you are such a big supporting vendor, and I do hope we collectively appreciate that.&nbsp; Okay, about halfway through, he did have one funny line about typical disaster recovery behavior, which seemed to wake up about 10% of the audience.&nbsp; But this didn't redeem the segment; sorry.<br></p><p><br><b>David DeWitt, Data and Storage Platform Division, Microsoft</b></p><p>David came on and made some funny comments about past incidents on stage, including the 192-core server that seemed like it was going to catch on fire when the fans kicked in.&nbsp; David runs the Jim Gray Systems Lab in Madison, WI.&nbsp; He is working on SQL Server Parallel Data Warehouse (or, as David would like to name it, SQL*).&nbsp; He promises to overwhelm us with technical details as opposed to making a marketing-ish presentation.</p><p>He compared how things have changed since 1980, including a 1,000X improvement in CPU cache, memory capacity, and CPU performance, and 10,000X increase in storage capacity.&nbsp; Whereas transfer times have only improved 65X, and seek times have only improved 10X.&nbsp; Seems funny that we are worried about getting 32-, 64-, 192-core machines when the disk performance simply can't scale to keep those CPUs busy.&nbsp; In fact when he measures transfer bandwidth per byte of storage, drives are actually 150X slower today compared to 1980, in relative terms.&nbsp; In 1980, the ratio of perf from Sequential : Random is 5 : 1.&nbsp; Today, it is 33 : 1.&nbsp; Meaning we have to focus on sequential reads and move the disk heads as little as possible.&nbsp; He also explained that as much as 50% of the time, the CPUs is sitting there, waiting for the memory to deliver something into its L2 caches.</p><p>David's idea about improving the storage bottleneck problem is to use column-wise storage instead of row-wise.&nbsp; Essentially, imagine storing all the values for each column, instead of each row, on common pages. The example showed how you could store ~2,000 values for a BalanceDue column (INT) on a single page, as opposed to the page being crowded by the other columns, and therefore being able to store far fewer rows on each page.&nbsp; (You still have to worry about the I/O for the other column values you want to retrieve; however a subset of columns will be faster in this model. SELECT * will never be faster, of course.&nbsp; But we usually don't want SELECT *, right?)&nbsp; This is a really interesting concept, and at its core it is quite simple, but implementation in existing architectures is far from trivial.</p><p>Since disk capacities have gotten 10,000X better, you can store redundant copies using different sort orders.&nbsp; Especially because with columnar storage, you can compress very well, leading to great reductions in storage requirements - leaving plenty of free space that will otherwise go to waste.&nbsp; By using run length encoding compression - in a certain sort order, you only need to store the offsets of contiguous rows that .&nbsp; Bit-vector encoding and dictionary encoding can be combined with run length encoding to achieve really fantastic compression rates; David's research yields improvements from 3X to 10X over row store.</p><p>Compression makes a lot of sense in this case because (remember) CPU is
1,000X faster than it used to be, and disk is only 65X.&nbsp; So any time we
can trade CPU cycles in exchange for less I/O, we should do it.&nbsp;
Basically we are striving to move the majority of the work to thecomponent(s) of the system that have improved the most over time (and continue to do so). </p><p>He explained the difference between early materialization and late materialization (where materialization is the process of turning the columns into rows) - queries with joins should use early materialization because they need to process against the whole table; queries without joins can use later materialization which again pushes the materialization work to CPU.<br></p><p>Updates are the big problem here... you have these very tightly packed columns, so you store deltas (which the queries must observe) and occasionally rebuild.&nbsp; Not suitable for OLTP or cases where reads occur against more than half of the columns of a table.</p><p>Microsoft is shipping VertiPaq, an in-memory column store, in SQL Server 2008 R2.&nbsp; So the hint is that there is definitely some work in this area underway for SQL11.<br></p><p>My mind is starting to hurt, but there are some very cool ideas here.<br></p><p>Note that throughout David's time on stage, Twitter was still abuzz with complaining about the Dell portion of the keynote.&nbsp; My favorite was from Steve Jones: <span class="status-body"><span class="entry-content">"<a href="http://twitter.com/way0utwest/status/5454983312" title="http://twitter.com/way0utwest/status/5454983312" target="_blank">@BrentO</a><a href="http://twitter.com/way0utwest/status/5454983312" title="http://twitter.com/way0utwest/status/5454983312" target="_blank"></a><a href="http://twitter.com/way0utwest/status/5454983312" title="http://twitter.com/way0utwest/status/5454983312" target="_blank"> Somebody tell the Dell guy PASS is in Orlando next year.</a>"</span></span></p><p>Wayne came on stage and announced that the keynote will be available on the DVDs.&nbsp; Just one more reason the $125 will be worth every penny. <br></p>