基于列存储的数据库的优点¶
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这样的操作实在是笨拙。