传统关系型数据库，如Oracle、DB2、MySQL、SQLSERVER等，其中数据是按照行数据为基本逻辑存储的存储单元，一行中的数据以连续存储的形式存在于存储介质中。我们知道今天的数据处理大致可以分为两类，OLTP（联机事务处理）和OLAP（联机分析处理）。OLTP是传统关系型数据库的主要应用，用于进行一些基本的、日常的事务处理，如数据库记录的增、删、改、查等；而OLAP是分布式数据库的主要应用。性能要求不高，但处理的数据量大，通常应用于复杂的动态报表系统。OLTP和OLAP的主要区别为什么OLTP和OLAP在数据库应用类别方面存在显着差异？其实这是数据库存储方式不同造成的。基于行的存储和基于列的存储传统的关系型数据库，如Oracle、DB2、MySQL、SQLSERVER等，使用的是基于行的存储（Row-based）。在基于行的存储数据库中，数据是以行数据的形式存储在一个逻辑存储单元中，一行中的数据以连续的存储形式存在于存储介质中。列式存储是相对于行式存储而言的。Hbase、HPVertica和EMCGreenplum等新兴的分布式数据库都使用基于列的存储。在基于列存储的数据库中，数据按照列为基本逻辑存储单元进行存储，列中的数据以连续存储的形式存在于存储介质中。行存储的适用场景包括：1.适用于随机增删改查操作；2、需要连续选择所有属性的查询操作；3.需要频繁插入或更新的操作，并且操作的大小大于相关索引和行的大小。在实践中，我们会发现基于行的数据库在读取数据时有一个先天的“缺陷”。例如，即使选择的查询目标只涉及几个属性，因为这些目标数据都埋藏在每一行数据单元中，但行单元往往非常大，应用程序必须读取每条完整的行记录，这大大降低了阅读效率。对此，行数据库给出的优化方案是加“索引”。在OLTP类型的应用中，可以通过索引机制或者表分区来简化查询操作步骤，提高查询效率。但是，对于具有海量数据背景的OLAP应用（如分布式数据库、数据仓库等），基于行的数据库就有些“力不从心”了。为基于行的数据库建立索引和物化视图需要花费大量的时间和资源，所以得不偿失。不能从根本上解决查询性能和维护成本问题，不适合数据仓库等应用场景。因此，后来出现了列式存储。数据库。对于数据仓库和分布式数据库，大多数情况下它会汇总各种数据源的数据，然后进行分析和反馈。它的大部分操作都是围绕同一列属性的数据进行的，列式数据库只需要返回与列属性相关的值。在大查询场景下，列式数据库可以高效的将内存中每一列的值进行组装，最终形成关系记录集，因此可以显着降低IO消耗。并减少查询响应时间，非常适合数据仓库和分布式应用。列式存储引擎的适用场景包括：1、在查询过程中，各列的操作可以并发执行（SMP），在内存中聚合完整的记录集，可以减少查询响应时间；2、在数据列中高效查找数据，无需维护索引（任何列都可以作为索引）。查询过程中，尽量减少不相关的IO，避免全表扫描；3、由于每一列都是独立存储的，数据类型已知，所以可以针对列的数据类型，数据的大小等因素动态选择压缩算法，提高物理存储的利用率；如果某行某列没有数据，则该列的值不需要存储在列存中，这样会比行存更节省空间。当然，和行数据库一样，列存储也有不适用的场景。主要包括：需要频繁更新数据的事务场景表中列属性少的小型数据库场景不适合涉及删除和更新的实时操作随着列式数据库的发展，传统的行型数据库增加了列-基于存储的支持，形成一个具有两种存储方式的数据库系统。例如，随着Oracle12c中内存组件的引入，Oracle数据库拥有了双模式的数据存储方式，可以支持混合类型的应用。当然，列式数据库也支持行式存储，比如HPVertica。总之，没有完美的数据库，一切都要根据实际的数据存储和分析需求！
