From 4d621f5b58d3e687a00eeeb78612cce2e2628bf3 Mon Sep 17 00:00:00 2001 From: zeekling Date: Sun, 3 Jan 2021 20:00:06 +0800 Subject: [PATCH] =?UTF-8?q?=E6=B7=BB=E5=8A=A0clickHouse=E7=AE=80=E4=BB=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 407a733..c7bb1e2 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,31 @@ -# clickHouseTest +## clickHouse 简介 -clickHouse 练习。 \ No newline at end of file +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去处理分析请求。