Database rows and columns of memory storage Detailed

 See also: https://blog.csdn.net/Xingxinxinxin/article/details/80939277

Unfinished be modified .......................

 A data processing type

• Online transaction processing OLTP (on-line transaction processing)
• Online analytical processing OLAP (On-Line Analytical Processing)

the difference:

• OLTP is the main application of traditional relational databases, to perform some of the basic, routine transactions, such as database records add, delete, change, etc.
• OLAP is the main application of distributed database, its real-time ask for much, but the large amount of data processing, usually applied to complex and dynamic reporting system.

 

II. Row and column storage Storage

• Row-based storage storesatable in a sequence of rows.
• Column-based storage storesatable in a sequence of columns.

Traditional relational databases, such as Oracle, DB2, MySQL, SQL SERVER, etc. using row storage method (Row-based), in the database based on the line memory, the data is stored on the basis of logical storage unit in accordance with line data, data line is present in the form of continuously stored in a storage medium.

Storage column (Column-based) with respect to the line for the storage, emerging Hbase, HP Vertica, EMC Greenplum a distributed database storage columns are used. In column-based database storage, the data is stored in accordance with the logical units of storage as the base, in the presence of a data continuously stored in the form of a storage medium.

Can be clearly seen from the figure, the data row of a table storage are put together, but the storage columns are saved separately. So they have these advantages and disadvantages of the following comparison:

1. In contrast to the data write

1) th row is stored in the write once. If this is written based on the operating system's file system that can guarantee success or failure of the writing process, the integrity of data can thus be determined.

2）列存储由于需要把一行记录拆分成单列保存，写入次数明显比行存储多（意味着磁头调度次数多，而磁头调度是需要时间的，一般在1ms~10ms)，再加上磁头需要在盘片上移动和定位花费的时间，实际时间消耗会更大。所以，行存储在写入上占有很大的优势。

3）还有数据修改,这实际也是一次写入过程。不同的是，数据修改是对磁盘上的记录做删除标记。行存储是在指定位置写入一次，列存储是将磁盘定位到多个列上分别写入，这个过程仍是行存储的列数倍。所以，数据修改也是以行存储占优。

2.在数据读取上的对比

1）数据读取时，行存储通常将一行数据完全读出，如果只需要其中几列数据的情况，就会存在冗余列，出于缩短处理时间的考量，消除冗余列的过程通常是在内存中进行的。

2）列存储每次读取的数据是集合的一段或者全部，不存在冗余性问题。

3） 两种存储的数据分布。由于列存储的每一列数据类型是同质的，不存在二义性问题。比如说某列数据类型为整型(int)，那么它的数据集合一定是整型数据。这种情况使数据解析变得十分容易。相比之下，行存储则要复杂得多，因为在一行记录中保存了多种类型的数据，数据解析需要在多种数据类型之间频繁转换，这个操作很消耗CPU，增加了解析的时间。所以，列存储的解析过程更有利于分析大数据。

4）从数据的压缩以及更性能的读取来对比

 

 

 

3.优缺点

1）行存储的写入是一次性完成，消耗的时间比列存储少，并且能够保证数据的完整性，缺点是数据读取过程中会产生冗余数据，如果只有少量数据，此影响可以忽略;数量大可能会影响到数据的处理效率。

2）列存储在写入效率、保证数据完整性上都不如行存储，它的优势是在读取过程，不会产生冗余数据，这对数据完整性要求不高的大数据处理领域，比如互联网，犹为重要。

两种存储格式各自的特性都决定了它们的使用场景。

 

列存储的适用场景
1）一般来说，一个OLAP类型的查询可能需要访问几百万甚至几十亿个数据行，且该查询往往只关心少数几个数据列。例如，查询今年销量最高的前20个商品，这个查询只关心三个数据列：时间（date）、商品（item）以及销售量（sales amount）。商品的其他数据列，例如商品URL、商品描述、商品所属店铺，等等，对这个查询都是没有意义的。

 

而列式数据库只需要读取存储着“时间、商品、销量”的数据列，而行式数据库需要读取所有的数据列。因此，列式数据库大大地提高了OLAP大数据量查询的效率

 

 

2）很多列式数据库还支持列族（column group，Bigtable系统中称为locality group），即将多个经常一起访问的数据列的各个值存放在一起。如果读取的数据列属于相同的列族，列式数据库可以从相同的地方一次性读取多个数据列的值，避免了多个数据列的合并。列族是一种行列混合存储模式，这种模式能够同时满足OLTP和OLAP的查询需求。

 

最后总结如下
传统行式数据库的特性如下：

①数据是按行存储的。

②没有索引的查询使用大量I/O。比如一般的数据库表都会建立索引，通过索引加快查询效率。

③建立索引和物化视图需要花费大量的时间和资源。

④面对查询需求，数据库必须被大量膨胀才能满足需求。

 

列式数据库的特性如下：

①数据按列存储，即每一列单独存放。

②数据即索引。

③只访问查询涉及的列，可以大量降低系统I/O。

④每一列由一个线程来处理，即查询的并发处理性能高。

⑤数据类型一致，数据特征相似，可以高效压缩。比如有增量压缩、前缀压缩算法都是基于列存储的类型定制的，所以可以大幅度提高压缩比，有利于存储和网络输出数据带宽的消耗。

 

行式存储的适用场景包括：

1、适合随机的增删改查操作;

2、需要在行中选取所有属性的查询操作;

3、需要频繁插入或更新的操作，其操作与索引和行的大小更为相关。

实操中我们会发现，行式数据库在读取数据的时候，会存在一个固有的“缺陷”。比如，所选择查询的目标即使只涉及少数几项属性，但由于这些目标数据埋藏在各行数据单元中，而行单元往往又特别大，应用程序必须读取每一条完整的行记录，从而使得读取效率大大降低，对此，行式数据库给出的优化方案是加“索引”。

在OLTP类型的应用中，通过索引机制或给表分区等手段，可以简化查询操作步骤，并提升查询效率

但针对海量数据背景的OLAP应用(例如分布式数据库、数据仓库等等)，行式存储的数据库就有些“力不从心”了，行式数据库建立索引和物化视图，需要花费大量时间和资源，因此还是得不偿失，无法从根本上解决查询性能和维护成本等问题，也不适用于数据仓库等应用场景，所以后来出现了基于列式存储的数据库

对于数据仓库和分布式数据库来说，大部分情况下它会从各个数据源汇总数据，然后进行分析和反馈，其操作大多是围绕同一列属性的数据进行的，而当查询某属性的数据记录时，列式数据库只需返回与列属性相关的值，在大数据量查询场景中，列式数据库可在内存中高效组装各列的值，最终形成关系记录集，因此可以显著减少IO消耗，并降低查询响应时间，非常适合数据仓库和分布式的应用

列式存储引擎的适用场景包括：

1、查询过程中，可针对各列的运算并发执行(SMP)，***在内存中聚合完整记录集，***可能降低查询响应时间;

2、可在数据列中高效查找数据，无需维护索引(任何列都能作为索引)，查询过程中能够尽量减少无关IO，避免全表扫描;

3、因为各列独立存储，且数据类型已知，可以针对该列的数据类型、数据量大小等因素动态选择压缩算法，以提高物理存储利用率;如果某一行的某一列没有数据，那在列存储时，就可以不存储该列的值，这将比行式存储更节省空间。

 

当然，跟行数据库一样，列式存储也有不太适用的场景，主要包括：

1. 数据需要频繁更新的交易场景
2. 表中列属性较少的小量数据库场景
3. 不适合做含有删除和更新的实时操作

随着列式数据库的发展，传统的行式数据库加入了列式存储的支持，形成具有两种存储方式的数据库系统。例如，随着Oracle 12c推出了in memory组件，使得Oracle数据库具有了双模式数据存放方式，从而能够实现对混合类型应用的支持，当然列式数据库也有对行式存储的支持比如HP Vertica。总之，没有***的数据库，一切都要以实际的数据存储和分析需求为准!

写入：
行存储的写入是一次完成，数据的完整性因此可以确定。
列存储需要把一行记录拆分成单列保存，写入次数明显比行存储多。
行存储在写入上占有很大的优势

数据修改：
行存储是在指定位置写入一次，列存储是将磁盘定位到多个列上分别写入。
行存储在数据修改也是占优的

数据读取：
行存储通常将一行数据完全读出，如果只需要其中几列数据，就会存在冗余列
列存储每次读取的数据是集合中的一段或者全部。
由于列储存的数据是同质的，这种情况使数据解析变得容易。行存储则复杂的多，因为在一行记录中保存了多种类型的数据，数据解析需要在多种数据类型之间频繁转换，这个操作很消耗cpu
所以列存储的解析过程中更有利于分析大数据

显而易见，两种存储格式都有各自的优缺点：行存储的写入是一次性完成，消耗的时间比列存储少，并且能够保证数据的完整性，缺点是数据读取过程中会产生冗余数据，如果只有少量数据，此影响可以忽略；数量大可能会影响到数据的处理效率。列存储在写入效率、保证数据完整性上都不如行存储，它的优势是在读取过程，不会产生冗余数据，这对数据完整性要求不高的大数据处理领域，比如互联网，犹为重要。

什么时候应该使用行式存储？什么时候应该使用列式存储呢？
如果你大部分时间都是关注整张表的内容，而不是单独某几列，并且所关注的内容是不需要通过任何聚集运算的，那么推荐使用行式存储。原因是重构每一行数据（即解压缩过程）对于HANA来说，是一个不小的负担。
列式存储的话，比如你比较关注的都是某几列的内容，或者有频繁聚集需要的，通过聚集之后进行数据分析的表。