【免费】ClickHouse中文API文档_clickhouse官方文档查看资源-CSDN文库

clickhouse

需积分: 0 147 浏览量 2023-02-03 10:28:49 上传评论 1 收藏 8.16MB PDF 举报

资源推荐

资源详情

资源评论

什么是ClickHouse？

ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

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

Row WatchID JavaEnable Title GoodEvent EventTime

#0 89354350662 1 Investor Relations 1 2016-05-18 05:19:20

#1 90329509958 0 Contact us 1 2016-05-18 08:10:20

#2 89953706054 1 Mission 1 2016-05-18 07:38:00

#N … … … … …

处于同一行中的数据总是被物理的存储在一起。

常见的行式数据库系统有：MySQL、Postgres和MS SQL Server。

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

Row: #0 #1 #2 #N

WatchID: 89354350662 90329509958 89953706054 …

JavaEnable: 1 0 1 …

Title: Investor Relations Contact us Mission …

GoodEvent: 1 1 1 …

EventTime: 2016-05-18 05:19:20 2016-05-18 08:10:20 2016-05-18 07:38:00 …

这些示例只显示了数据的排列顺序。来自不同列的值被单独存储，来自同一列的数据被存储在一起。

常见的列式数据库有： 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去处理分析请求。

列式数据库更适合OLAP场景的原因

列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍)，下面详细解释了原因(通过图片更有利于直观理解)：

行式行式

列式列式
看到差别了么？下面将详细介绍为什么会发生这种情况。
输入/输出  
1.  针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消
耗。
2.  由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
3.  由于I/O的降低，这将帮助更多的数据被系统缓存。
例如，查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以
以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。
这实际上是当前实现的速度。
CPU  
由于执行一个查询需要处理大量的行，因此在整个向量上执行所有操作将比在每一行上执行所有操作更加高效。同时这将有助于实现一个几乎没有调用成本的查询引擎。如果你不
这样做，使用任何一个机械硬盘，查询引擎都不可避免的停止CPU进行等待。所以，在数据按列存储并且按列执行是很有意义的。
有两种方法可以做到这一点：
1.  向量引擎：所有的操作都是为向量而不是为单个值编写的。这意味着多个操作之间的不再需要频繁的调用，并且调用的成本基本可以忽略不计。操作代码包含一个优化的内
部循环。
2.  代码生成：生成一段代码，包含查询中的所有操作。
这是不应该在一个通用数据库中实现的，因为这在运行简单查询时是没有意义的。但是也有例外，例如，MemSQL使用代码生成来减少处理SQL查询的延迟(只是为了比较，分析
型数据库通常需要优化的是吞吐而不是延迟)。
请注意，为了提高CPU效率，查询语言必须是声明型的(SQL或MDX)， 或者至少一个向量(J，K)。 查询应该只包含隐式循环，允许进行优化。
来源文章
ClickHouse的特性  
真正的列式数据库管理系统  
在一个真正的列式数据库管理系统中，除了数据本身外不应该存在其他额外的数据。这意味着为了避免在值旁边存储它们的长度«number»，你必须支持固定长度数值类型。例
如，10亿个UInt8类型的数据在未压缩的情况下大约消耗1GB左右的空间，如果不是这样的话，这将对CPU的使用产生强烈影响。即使是在未压缩的情况下，紧凑的存储数据也是
非常重要的，因为解压缩的速度主要取决于未压缩数据的大小。
这是非常值得注意的，因为在一些其他系统中也可以将不同的列分别进行存储，但由于对其他场景进行的优化，使其无法有效的处理分析查询。例如：
HBase，BigTable，Cassandra，HyperTable。在这些系统中，你可以得到每秒数十万的吞吐能力，但是无法得到每秒几亿行的吞吐能力。
需要说明的是，ClickHouse不单单是一个数据库， 它是一个数据库管理系统。因为它允许在运行时创建表和数据库、加载数据和运行查询，而无需重新配置或重启服务。
数据压缩  
在一些列式数据库管理系统中(例如：InfiniDB CE 和 MonetDB) 并没有使用数据压缩。但是, 若想达到比较优异的性能，数据压缩确实起到了至关重要的作用。
除了在磁盘空间和CPU消耗之间进行不同权衡的高效通用压缩编解码器之外，ClickHouse还提供针对特定类型数据的专用编解码器，这使得ClickHouse能够与更小的数据库(如
时间序列数据库)竞争并超越它们。
数据的磁盘存储  
许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。
ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果可以使用SSD和内存，它也会合理的利用这些资源。
多核心并行处理  
ClickHouse会使用服务器上一切可用的资源，从而以最自然的方式并行处理大型查询。

多服务器分布式处理  
上面提到的列式数据库管理系统中，几乎没有一个支持分布式的查询处理。
在ClickHouse中，数据可以保存在不同的shard上，每一个shard都由一组用于容错的replica组成，查询可以并行地在所有shard上进行处理。这些对用户来说是透明的
支持SQL  
ClickHouse支持一种基于SQL的声明式查询语言，它在许多情况下与ANSI SQL标准相同。
支持的查询GROUP BY, ORDER BY, FROM, JOIN, IN以及非相关子查询。
相关(依赖性)子查询和窗口函数暂不受支持，但将来会被实现。
向量引擎  
为了高效的使用CPU，数据不仅仅按列存储，同时还按向量(列的一部分)进行处理，这样可以更加高效地使用CPU。
实时的数据更新  
ClickHouse支持在表中定义主键。为了使查询能够快速在主键中进行范围查找，数据总是以增量的方式有序的存储在MergeTree中。因此，数据可以持续不断地高效的写入到表
中，并且写入的过程中不会存在任何加锁的行为。
索引  
按照主键对数据进行排序，这将帮助ClickHouse在几十毫秒以内完成对数据特定值或范围的查找。
适合在线查询  
在线查询意味着在没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到用户的页面中。
支持近似计算  
ClickHouse提供各种各样在允许牺牲数据精度的情况下对查询进行加速的方法：
1.  用于近似计算的各类聚合函数，如：distinct values, medians, quantiles
2.  基于数据的部分样本进行近似查询。这时，仅会从磁盘检索少部分比例的数据。
3.  不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合。这在数据聚合条件满足某些分布条件下，在提供相当准确的聚合结果的同时降低了计算资源的使用。
Adaptive Join Algorithm  
ClickHouse支持自定义JOIN多个表，它更倾向于散列连接算法，如果有多个大表，则使用合并-连接算法
支持数据复制和数据完整性  
ClickHouse使用异步的多主复制技术。当数据被写入任何一个可用副本后，系统会在后台将数据分发给其他副本，以保证系统在不同副本上保持相同的数据。在大多数情况下
ClickHouse能在故障后自动恢复，在一些少数的复杂情况下需要手动恢复。
更多信息，参见 数据复制。
角色的访问控制  
ClickHouse使用SQL查询实现用户帐户管理，并允许角色的访问控制，类似于ANSI SQL标准和流行的关系数据库管理系统。
限制  
1.  没有完整的事务支持。
2.  缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据，但这符合 GDPR。
3.  稀疏索引使得ClickHouse不适合通过其键检索单行的点查询。
来源文章
性能  
根据Yandex的内部测试结果，ClickHouse表现出了比同类可比较产品更优的性能。你可以在 这里 查看具体的测试结果。
许多其他的测试也证实这一点。你可以使用互联网搜索到它们，或者你也可以从 我们收集的部分相关连接 中查看。
单个大查询的吞吐量  
吞吐量可以使用每秒处理的行数或每秒处理的字节数来衡量。如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度
进行处理（对于简单的查询，速度可以达到30GB／s）。如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以
400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，如果你是在提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。
对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。
处理短查询的延迟时间  
如果一个查询使用主键并且没有太多行(几十万)进行处理，并且没有查询太多的列，那么在数据被page cache缓存的情况下，它的延迟应该小于50毫秒(在最佳的情况下应该小于
10毫秒)。 否则，延迟取决于数据的查找次数。如果你当前使用的是HDD，在数据没有加载的情况下，查询所需要的延迟可以通过以下公式计算得知： 查找时间（10 ms） * 查
询的列的数量 * 查询的数据块的数量。
处理大量短查询的吞吐量  
在相同的情况下，ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。因此我们建议每秒最多查询
100次。
数据的写入性能  
我们建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。
如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行
写入，这将带来线性的性能提升。
来源文章

ClickHouse历史  
ClickHouse最初是为 YandexMetrica 世界第二大Web分析平台 而开发的。多年来一直作为该系统的核心组件被该系统持续使用着。目前为止，该系统在ClickHouse中有超过
13万亿条记录，并且每天超过200多亿个事件被处理。它允许直接从原始数据中动态查询并生成报告。本文简要介绍了ClickHouse在其早期发展阶段的目标。
Yandex.Metrica基于用户定义的字段，对实时访问、连接会话，生成实时的统计报表。这种需求往往需要复杂聚合方式，比如对访问用户进行去重。构建报表的数据，是实时接
收存储的新数据。
截至2014年4月，Yandex.Metrica每天跟踪大约120亿个事件（用户的点击和浏览）。为了可以创建自定义的报表，我们必须存储全部这些事件。同时，这些查询可能需要在几
百毫秒内扫描数百万行的数据，或在几秒内扫描数亿行的数据。
Yandex.Metrica以及其他Yandex服务的使用案例  
在Yandex.Metrica中，ClickHouse被用于多个场景中。
它的主要任务是使用原始数据在线的提供各种数据报告。它使用374台服务器的集群，存储了20.3万亿行的数据。在去除重复与副本数据的情况下，压缩后的数据达到了2PB。未
压缩前（TSV格式）它大概有17PB。
ClickHouse还被使用在：
存储来自Yandex.Metrica的会话重放数据。
处理中间数据
与Analytics一起构建全球报表。
为调试Yandex.Metrica引擎运行查询
分析来自API和用户界面的日志数据
ClickHouse在其他Yandex服务中至少有12个安装：search verticals, Market, Direct, business analytics, mobile development, AdFox, personal services等。
聚合与非聚合数据  
有一种流行的观点认为，想要有效的计算统计数据，必须要聚合数据，因为聚合将降低数据量。
但是数据聚合是一个有诸多限制的解决方案，例如：
你必须提前知道用户定义的报表的字段列表
用户无法自定义报表
当聚合条件过多时，可能不会减少数据，聚合是无用的。
存在大量报表时，有太多的聚合变化（组合爆炸）
当聚合条件有非常大的基数时（如：url），数据量没有太大减少（少于两倍）
聚合的数据量可能会增长而不是收缩
用户不会查看我们为他生成的所有报告，大部分计算将是无用的
各种聚合可能违背了数据的逻辑完整性
如果我们直接使用非聚合数据而不进行任何聚合时，我们的计算量可能是减少的。
然而，相对于聚合中很大一部分工作被离线完成，在线计算需要尽快的完成计算，因为用户在等待结果。
Yandex.Metrica 有一个专门用于聚合数据的系统，称为Metrage，它可以用作大部分报表。
从2009年开始，Yandex.Metrica还为非聚合数据使用专门的OLAP数据库，称为OLAPServer，它以前用于报表构建系统。
OLAPServer可以很好的工作在非聚合数据上，但是它有诸多限制，导致无法根据需要将其用于所有报表中。如，缺少对数据类型的支持（只支持数据），无法实时增量的更新数
据（只能通过每天重写数据完成）。OLAPServer不是一个数据库管理系统，它只是一个数据库。
为了消除OLAPServer的这些局限性，解决所有报表使用非聚合数据的问题，我们开发了ClickHouse数据库管理系统。
来源文章
ClickHouse用户  
公司简介公司简介 行业行业 用例用例 群集大小群集大小 (Un)压缩数据大小压缩数据大小  (of
single replica)
参考资料参考资料
2gis 地图 监测 — — 俄文，2019年7月
Aloha 浏览器 移动应用程
序
浏览器后
端
— — 俄文幻灯片，2019年5月
阿玛迪斯 旅行 分析 — — 新闻稿,四月2018
Appsflyer 移动分析 主要产品 — — 俄文，2019年7月
ArenaData 数据平台 主要产品 — — 俄文幻灯片，十二月2019
Badoo 约会 时间序列 — — 俄文幻灯片，十二月2019
Benocs 网络遥测和
分析
主要产品 — — 英文幻灯片，2017年10月
免责声明
如下使用ClickHouse的公司和他们的成功案例来源于公开资源，因此和实际情况可能有所出入。如果您分享您公司使用ClickHouse的故事，我们将不胜感激 将其添加到列将其添加到列
表表，但请确保你这样做不会有任何保密协议的问题。也欢迎提供来自其他公司的出版物的更新。
*

彭博社 金融、媒体 监测 102个服务器 — 幻灯片，2018年5月
Bloxy 区块链 分析 — — 俄文幻灯片，八月2018
Dataliance/UltraPower 电信 分析 — — 中文幻灯片，2018年1月
CARTO 商业智能 地理分析 — — 地理空间处理与ClickHouse
CERN 研究 实验 — — 新闻稿,四月2012
思科 网络 流量分析 — — 闪电对话，十月2019
城堡证券 金融 — — — 贡献，2019年3月
Citymobil 出租车 分析 — — 俄文博客文章，三月2020
内容广场 网站分析 主要产品 — — 法文博客文章，十一月2018
Cloudflare CDN 流量分析 36服务器 — 博客文章,五月2017, 博客文章,三月
2018
Corunet 分析 主要产品 — — 英文幻灯片，2019年4月
CraiditX 氪信 金融AI 分析 — — 英文幻灯片，2019年11月
Criteo/Storetail 零售 主要产品 — — 英文幻灯片，十月2018
德意志银行 金融 商业智能
分析
— — 英文幻灯片，十月2019
Diva-e 数字咨询 主要产品 — — 英文幻灯片，2019年9月
Exness 交易 指标，日
志记录
— — 俄语交谈，2019年5月
精灵 广告网络 主要产品 — — 日文博客，2017年7月
虎牙 视频流 分析 — — 中文幻灯片，2018年10月
Idealista 房地产 分析 — — 英文博客文章,四月2019
Infovista 网络 分析 — — 英文幻灯片，十月2019
InnoGames 游戏 指标，日
志记录
— — 俄文幻灯片，2019年9月
Integros 视频服务平
台
分析 — — 俄文幻灯片，2019年5月
科迪亚克数据 云 主要产品 — — 虏茅驴麓卤戮碌禄路戮鲁拢
Kontur 软件开发 指标 — — 俄语交谈，2018年11月
LifeStreet 广告网络 主要产品 75台服务器（3个副本) 5.27PiB 俄文博客文章，2017年2月
Mail.ru 云解决方案 云服务 主要产品 — — 运行ClickHouse实例，俄语
MessageBird 电信 统计 — — 英文幻灯片，2018年11月
MGID 广告网络 网络分析 — — 我们在实施分析DBMS ClickHouse
的经验，俄文
OneAPM 监测和数据
分析
主要产品 — — 中文幻灯片，2018年10月
Pragma Innovation 遥测和大数
据分析
主要产品 — — 英文幻灯片，十月2018
青云 云服务 主要产品 — — 中文幻灯片，2018年10月
Qrator DDoS保护 主要产品 — — 博客文章,三月2019
公司简介公司简介 行业行业 用例用例 群集大小群集大小 (Un)压缩数据大小压缩数据大小  (of
single replica)
参考资料参考资料