OLTP、OLAP列数据库、列族数据库的区别

一句话区别

  • OLTP:基于行存储的关系数据库,写入速度极快,用于数据记录修改场景,MySQL、Oracle
  • OLAP:基于列存储,查询速度极快,用于海量数据分析,Clickhouse、Vertica、 Amazon Redshift、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 LucidDB、 SAP HANA、 Google Dremel
  • 列族:使用k-v + 时间戳存储,用于大表大数据存储,分布式存储,带版本时序操作等场景,HBase、Cassandra、BigTable(google)

区别

1.在数据写入上的对比

1)行存储的写入是一次完成。如果这种写入建立在操作系统的文件系统上,可以保证写入过程的成功或者失败,数据的完整性因此可以确定。

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

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

2.在数据读取上的对比

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

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

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

OLAP-OLTP 的查询性能对比

以OLAP ClickHouse为例,可以看出在1亿条数据情况下,MySQL和Hive比ClickHouse慢289倍和831倍

https://clickhouse.tech/benchmark/dbms/#[%22100000000%22,[%22ClickHouse%22,%22Vertica%22,%22Hive%22,%22MySQL%22,%22MemSQL%22,%22Greenplum%22],[%221%22,%222%22]]

ClickHouse有个在线的domo,可以试试查询它1亿行的表(hits_100m_obfuscated)复杂查询的速度,挺惊人。

https://play.clickhouse.tech/?file=welcome

存储方式

行式数据库OLTP

在传统的行式数据库系统中,数据按如下顺序存储:

rowwatchIDJavaEnabletitleGoodEventEventTime
#0 89354350662 1 投资者关系 1 2016-05-18 05:19:20
#1 90329509958 0 联系我们 1 2016-05-18 08:10:20
#2 89953706054 1 任务 1 2016-05-18 07:38:00
#N

处于同一行中的数据总是被物理的存储在一起。mysql innodb数据还和索引放在一起。

列式数据库OLAP

在列式数据库系统中,数据按如下的顺序存储:

row:#0#1#2#N
watchID: 89354350662 90329509958 89953706054
JavaEnable: 1 0 1
title: 投资者关系 联系我们 任务
GoodEvent: 1 1 1
EventTime: 2016-05-18 05:19:20 2016-05-18 08:10:20 2016-05-18 07:38:00

该示例中只展示了数据在列式数据库中数据的排列方式。

实际上列式数据库还应该有一个内部索引,左边是行数据库,右边是列数据库

将Customes Name列及Material列做逻辑化索引标识,查询时分别匹配Materia=Refrigerator及Customes Name=Miller的数据,然后做交叉匹配。

 

列族数据库的存储模型

核心是k-v 加 时间戳存储。

 场景

行式存储的适用场景:

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

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

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

列式存储的适用场景:

  一般来说,一个OLAP类型的查询可能需要访问几百万甚至几十亿个数据行,且该查询往往只关心少数几个数据列。例如,查询今年销量最高的前20个商品,这个查询只关心三个数据列:时间(date)、商品(item)以及销售量(sales amount)

列族存储的适用场景:

列族是一种K-V方式的行列混合存储模式,这种模式能够同时满足OLTP和OLAP的查询需求。

但写效率不如行式,读效率不如列式

OLAP-ClickHouse应用场景分析

新近极热门的ClickHouse大有干掉ES、Hodoop生态链如Hive、HBase的趋势的可能。

使用ClickHouse作为OLAP服务的常见的应用场景包括:监控系统、ABtest、用户行为分析、BI报表,特征分析等。

hadoop VS OLAP ClickHouse

  • Hadoop 体系是一种离线系统,一般很难支持即席查询。ClickHouse 可以支持即席查询。
  • Hadoop 体系一般不支持实时更新,都采用批量更新和写入。ClickHouse 支持实时数据更新。
  • Hadoop 体系一般采用行记录存储,数据查询需要扫描所有列,当表很宽时会扫描很多用不到的列。ClickHouse 是列式存储,查询只需要加载相关的列。

目前大量使用 ClickHouse 的互联网公司:

1. 今日头条内部用 ClickHouse 来做用户行为分析,内部一共几千个 ClickHouse 节点,单集群最大 1200 节点,总数据量几十 PB,日增原始数据 300TB 左右。

2. 腾讯内部用 ClickHouse 做游戏数据分析,并且为之建立了一整套监控运维体系。

3. 携程内部从 18 年 7 月份开始接入试用,目前 80% 的业务都跑在 ClickHouse 上。每天数据增量十多亿,近百万次查询请求。

4. 快手内部也在使用 ClickHouse,存储总量大约 10PB, 每天新增 200TB, 90% 查询小于 3S。

5. 在国外,Yandex 内部有数百节点用于做用户点击行为分析,CloudFlare、Spotify 等头部公司也在使用。

ClickHouse 高性能的背后

建议读这篇:

https://blog.csdn.net/u013256816/article/details/108413872

https://zhuanlan.zhihu.com/p/103781296

 

posted @ 2020-10-15 18:10  昕友软件开发  阅读(1023)  评论(0编辑  收藏  举报
欢迎访问我的开源项目:xyIM企业即时通讯