基于列存儲的數據庫的優點¶
a)對于聚集操作，比如求sum，明顯基于列存儲的要比基于行存儲的快；
b)對于update操作，不須接觸其他列值；
c)基于行存儲的數據庫在查詢每行記錄的多個列值更高效的條件是，row-size比較小，這樣一次磁盤讀取就可以獲取整行；
d)基于行存儲的數據庫在insert一行的時候相對更高效，畢竟可一次寫入一個連續空間，即一次single disk seek；

從實際情況上來看，基于行存儲的數據庫更適合OLTP（聯機事務處理系統），基于列存儲的數據庫更適合OLAP（聯機分析處理系統），比如數據倉庫。除此之外，同一列必定是同一類型大小，基于列存儲的數據庫更容易使用高效的存儲方式，與之相對，基于行存儲的數據庫則只能采用隨機方式處理列值了。

Vertica 數據庫的設計特點¶
a)它是基于列的存儲結構，提高了連續的record處理的性能，但是在一般事務中增加了對單獨record進行update和delete的開銷；
b)“單獨”更新（out-of-place updates）和混合存儲結構，提高了查詢、插入的性能，但增加了update和delete的開銷；
c)壓縮，減少存儲開銷和IO帶寬開銷；
d)完全無共享架構，降低對共享資源的系統競爭；

Vertica數據庫運行在基于Linux的網格服務器上，目前應用于Amazon Elastic Compute Cloud的數據庫管理系統。

The Vertica Analytic Databas¶
a)重申三大特點：壓縮、基于列、表分解；
b)混合數據存儲模式，當insert時候，按照寫優先分配原則，實現insert與query的高并發操作；
c)自動化數據庫結構設計工具，多節點集群系統，所有的數據都會保存在不止一個節點上，即所謂的k-safety，這樣可防止單點故障造成的損失；
d)高性能，支持ACID，輕量級事務和并發控制更加適合load和query操作。Vertica的故障恢復模型是基于多節點拷貝，而不是傳統的基于日志；
e)靈活部署；
f)監視和管理工具和API；

對于一個node上的vertica數據庫，數據存儲分為兩個部分，一個是讀優存儲（read-optimized store，ROS），另一個是寫優存儲（write-optimized store，WOS），每次更新和插入的數據臨時放在WOS部分，SQL查詢會訪問ROS部分，并且ROS存放已經經過壓縮和排序的數據，這樣就做到了讀寫并發兩不誤，通過tuple mover進程定期將WOS的數據壓縮排序后拷貝到ROS區域。

對于多個node，一個表的schema首先會按列拆分為多個映射，將每個列排序保存在不同磁盤上。

Vertica數據庫設計本身就適合基于列的查詢，雖然一些基于行的數據庫經過預處理和內部關系視圖等操作也可以優化常見查詢的速度，但仍和vertica能應付更多不同查詢的高性能無法相比，尤其是vertica的的列主動壓縮（aggressive compression）。主動壓縮，簡單的說就是將一個列不同的值的一維存儲轉換為二維元組（tuple），格式為<個數，列值>，這樣的話，即使是date類型的百萬條數據，一年最多也只有365個數對，好處不言而喻，節省空間、提高查詢速度、方便聚集函數操作。另外，對應浮點數和時間這樣的連續數值，也采用了某些處理方式實現了一些排序和壓縮（具體沒看懂）。

在讀優存儲（ROS）區域，除了排序壓縮外，還有些別的優化處理。比如數據是致密填充（dense packed）的，即占用的磁盤分頁內沒有空閑，不用考慮后來insert的數據放哪的問題，因為那是tuple mover做的事情。另一個優化是，vertica會提前取出一大塊數據用以減少多次磁盤掃描。 Vertica對于各節點上冗余存儲的列數據可采用不同排序順序存儲，這樣不但利用多拷貝實現了故障恢復，還利用多種排序順序提高了查詢速度，對于每一個給定的sql操作，vertica都會選擇一個最合適的排序順序。

DB designer 根據數據樣本和查詢樣本將邏輯schema映射為多個物理schema，說白了就是將一個行映射拆分為多個行映射，同時保證每個查詢的from部分都只來自一個映射。 k-safety，簡單的說就是，對于數據庫中的每一列，都會在k+1個節點上存儲，這樣即使k個節點壞掉了也沒事。

Vertica開發，支持標準SQL語句，支持JDBC和ODBC，支持perl和python編程，支持PostgreSQL等數據庫的應用代碼向其平滑移植。但是vertica對于update這樣的操作實在是笨拙。