添加clickHouse简介
This commit is contained in:
parent
4e64ee150d
commit
4d621f5b58
32
README.md
32
README.md
|
@ -1,3 +1,31 @@
|
|||
# clickHouseTest
|
||||
## clickHouse 简介
|
||||
|
||||
clickHouse 练习。
|
||||
ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。
|
||||
|
||||
常见的列式数据库有: Vertica、 Paraccel (Actian Matrix,Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、
|
||||
MonetDB (VectorWise, Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。
|
||||
|
||||
不同的数据存储方式适用不同的业务场景,数据访问的场景包括:进行了何种查询、多久查询一次以及各类查询的比例;每种类型的查
|
||||
询(行、列和字节)读取多少数据;读取数据和更新之间的关系;使用的数据集大小以及如何使用本地的数据集;是否使用事务,以及它们
|
||||
是如何进行隔离的;数据的复制机制与数据的完整性要求;每种类型的查询要求的延迟与吞吐量等等。
|
||||
|
||||
系统负载越高,依据使用场景进行定制化就越重要,并且定制将会变的越精细。没有一个系统能够同时适用所有不同的业务场景。如果
|
||||
系统适用于广泛的场景,在负载高的情况下,要兼顾所有的场景,那么将不得不做出选择。是要平衡还是要效率?
|
||||
|
||||
OLAP场景的关键特征
|
||||
- 绝大多数是读请求
|
||||
- 数据以相当大的批次(> 1000行)更新,而不是单行更新;或者根本没有更新。
|
||||
- 已添加到数据库的数据不能修改。
|
||||
- 对于读取,从数据库中提取相当多的行,但只提取列的一小部分。
|
||||
- 宽表,即每个表包含着大量的列
|
||||
- 查询相对较少(通常每台服务器每秒查询数百次或更少)
|
||||
- 对于简单查询,允许延迟大约50毫秒
|
||||
- 列中的数据相对较小:数字和短字符串(例如,每个URL 60个字节)
|
||||
- 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
|
||||
- 事务不是必须的
|
||||
- 对数据一致性要求低
|
||||
- 每个查询有一个大表。除了他以外,其他的都很小。
|
||||
- 查询结果明显小于源数据。换句话说,数据经过过滤或聚合,因此结果适合于单个服务器的RAM中
|
||||
|
||||
很容易可以看出,OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同, 因此想要使用OLTP或Key-Value数据库去高效的处理
|
||||
分析查询场景,并不是非常完美的适用方案。例如,使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。
|
||||
|
|
Loading…
Reference in New Issue