6年半以前，我回到中國，重新加入我近19年前離開的公司：Sybase中國，負責在中國地區推動列式數據庫產品Sybase IQ。從去年開始角色有些轉換，從列式數據庫轉而關注SAP的數據庫戰略，同時關注在“極端OLTP”場景下的數據庫技術發展方向。現在似乎是一個回顧一下列式數據庫這個技術過去近10年來的發展過程，並展望一下未來的發展方向的時候了。
2006年前后，一般企業的數據規模大約在100GB級別，個別大企業開始嘗試挖掘TB級數據中的價值，也開始體會TB級數據管理及分析的挑戰了。列式數據庫在幾乎低調、甚至沉寂了近10年之后開始被一些前瞻性客戶關注了。
歸根溯源，列式數據庫可以追溯到1994年，Sybase公司收購了一家名為ExpressWay Technologies的公司，其主要產品是幫助傳統數據庫做報表加速的工具，原理就是把行式數據庫的數據以列式的方式存儲下來。這個技術在1996年被正式推出為產品Sybase IQ，並延續到了現在。我們來看看為什么這樣一個從行式到列式的轉變可以提高報表的速度吧：
首先，行式數據庫顧名思義，存儲格式是按照‘行’的方式把一行各個字段的數據存在一起，一行一行連續存儲的。這樣的話，對把一條數據的信息寫到數據庫中；或者對一條數據中的某些字段進行修改；或者刪除整條數據一類的OLTP操作來說既直觀也高效。但是，在行式數據庫上做一些報表、分析的時候，大家又發現這種存儲格式使用效率不高，因為大部分統計分析場景，例如：統計各省份的銷售額和利潤同比變化；按照部門統計業績完成情況等等，都是在其中某些字段上的操作，行式數據庫不分情況一律按照頁面讀取數據的方式，在只分析銷售額和利潤的時候，把每一份合同的其他信息，如客戶名稱，簽約時間，客戶經理等等也統統都讀了進來，浪費了大量寶貴的I/O。
數據庫界給出的第一個改進辦法就是“索引”，就像字典前面的目錄一樣，做到快速定位。但是隨着分析場景變得越來越復雜、變化越來越多，DBA 們發現索引通常只能為一部分查詢、分析起到幫助的作用，如果想為一個企業級的BI系統中所有的查詢、分析場景做優化，無論是從組合的角度，還是從開銷的角 度，都幾乎是不可能的，因為大量的索引所帶來的存儲空間的浪費以及為維護這些索引所帶來的時間的浪費都會以指數級別增長。
而列式數據庫的思路原理並不復雜，把行式數據全部拆開，按照列的方式重新組合存儲，一列的所有行的數據存放在一起；按照列內數據的特征值（通常像時間、部門代碼、銷售地區等維度字段的特征值並不多，幾個到幾百個很常見）進行高效編碼，並且在實際存儲中以編碼形式存儲，這樣就帶來了大比例的壓縮。
帶來的好處是：原來只分析銷售額的查詢就只訪問銷售額字段，即使是所有歷史時期的數據，也不存在讀多余的無關數據的問題。
真正的列式數據庫具有的創新性在於所有字段都是索引的，甚至可以認為索引和數據是統一的，這樣一來，企業數據分析中最困難的隨機查詢，反而變成了列式數據庫的長項，經常出現在這些復雜、多表關聯、歷史數據分析的場景中比傳統的行式數據庫快成百上千倍的情況。
列式數據庫在數據倉庫、數據集市、企業商務智能 （BI）等領域已經發揮了越來越多的作用，在全球數以千計的企業中支撐着大量的大數據分析場景的應用，最大的可公開的數據倉庫壓縮后的數據量達幾百TB， 約合傳統行式數據庫內幾PB的總量。各家數據庫廠商都已經以不同的形式在接受列式存儲技術，推出不同風格、不同類型的列式存儲的產品，例如最新的微軟 SQL Server 2012中的Columnstore Index就是一個很好的例子，可選擇地定義個別列式存儲的索引。
未來會怎樣呢？這里說一點個人的觀點：
- 一項技術從產生到興盛需要一段時間，列式數據庫目前應該仍處於高速發展期，在未來的1-3年間應該還會出現更多的用戶接受列式數據庫對分析類場景的優勢，更大量地采用
- 更多的ISV會重點投入開發基於列式數據庫的分析類應用，充分享受列式數據庫的優勢
- 列式數據庫的宗旨在於豐富而高效的索引，會有更多的索引出現，為不同的分析場景提供高效的服務，例如：全文檢索、圖像分析等等。
- 更長期的范疇：技術產品通常會有分久必合，合久必分的情況，在另一個高度上把行式數據庫和列式數據庫以某種智能的方式組合在一起也是一種可以預見，並且已經見到類似SAP HANA這樣的嘗試已經顯露出一些初期的勢頭
讓我們積極加入到列式數據庫技術的學習、研究、使用及發展的浪潮中，在數據庫這個既傳統而又不斷出新的領域中捕獲各自的機會，貢獻各自的才智吧