微軟官方給出的內存數(shù)據(jù)庫定義是非常準確的：在內存數(shù)據(jù)庫系統(tǒng)中，包括數(shù)據(jù)庫引擎和盡可能多的數(shù)據(jù)都將直接存儲在RAM中。當然，這對于提高交易處理速度是非常有幫助的，但需要有兩個前提：1、數(shù)據(jù)庫和引擎都要盡可能的小;2、系統(tǒng)中的RAM要盡可能的大。以便數(shù)據(jù)庫、引擎與RAM相互適應。
隨著內存硬件的成本在不斷下降，越來越多的服務器都不斷增加內存配置，因此上述的兩個條件中，后者在實現(xiàn)起來顯然要比前者更加容易。而對于SQL Server來說則更是如此。
除了內存設備的成本降低之外，CPU的處理速度以及并行化也在不斷加深。因此，目前主流的數(shù)據(jù)庫產(chǎn)品都在這些方面上做文章，為了提升CPU的利用率，它們會盡可能地將數(shù)據(jù)庫操作更加向CPU靠攏。
在此之前，SAP、Oracle都在做此類嘗試，并取得了不錯的反饋。所以SQL Server也在積極地對這一技術進行深入研發(fā)。在微軟TechNet博客上面的一篇文章中，作者David Campbell探討了內存數(shù)據(jù)庫技術的發(fā)展趨勢，并指出數(shù)據(jù)存儲模式將由傳統(tǒng)的行式逐漸轉化為列式存儲。
這也就引出我之前所提到的一個問題：要想真正利用好內存處理技術，我們之前的SQL Server安裝是否需要進行升級或者改造?這很有可能，但是也是要視情況而定，以下是在使用內存數(shù)據(jù)庫時我們所需要注意的三個問題：
1、內存數(shù)據(jù)庫解決方案需要我們對現(xiàn)有數(shù)據(jù)庫進行部分改造
基于列式存儲的內存數(shù)據(jù)庫在進行設置的時候依然需要進行一定的變更。在微軟發(fā)布的一個案例中分享了SQL Server 2012中現(xiàn)有的一些內存功能，其中就提到當需要進行數(shù)據(jù)庫變更的時候，更改元數(shù)據(jù)值就可以了。所以根據(jù)你的設置，可能所需的工作會很少，但并不代表沒有。
2、數(shù)據(jù)庫越大，性能提升越多，但費用也越高
那些面向分析和數(shù)據(jù)倉庫的工作負載是適合內存數(shù)據(jù)庫的(假設所有處理都在內存中進行)，你將能看到大限度的性能提升。列式結構的內存數(shù)據(jù)庫并不是針對交易型負載進行的優(yōu)化，也就是傳統(tǒng)的CRUD(create, read, update, delete)操作。也許未來內存技術將逐漸擴展到交易系統(tǒng)領域，但這不是一朝一夕的事。
3、因此，我們并不需要把所有東西都轉移到內存數(shù)據(jù)庫上
我們可以先從那些處理器密集型的工作負載入手，如數(shù)據(jù)分析。數(shù)據(jù)分析系統(tǒng)在內存數(shù)據(jù)庫的清單中應該出在高的優(yōu)先級之上。即使你還沒有特別計劃要遷移到其他版本的SQL Server，記住這一點也會幫助你更好地在未來完成SQL Server系統(tǒng)的遷移。
事實上，微軟在Excel的PowerPivot插件上就已經(jīng)使用到了列式存儲技術。Campbell介紹說：“在SQL Server 2012中，我們還添加了xVelocity內存分析引擎，它是作為SQL Server分析服務(SSAS)的一部分來交付給用戶。”從長遠角度來看，xVelocity組件將逐漸獨立出來，也許在下一版本的SQL Server內存數(shù)據(jù)庫中，我們就能看到它成為一個高度垂直化的解決方案，專門應對數(shù)據(jù)倉庫或者數(shù)據(jù)分析等工作負載。
