mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-22 07:31:57 +00:00
Merge pull request #17360 from qianmoQ/fix-docs
Fixed a problem with the translation of introduction
This commit is contained in:
alexey-milovidov
GitHub
commit
f4c2c42b5a
2
.gitignore
vendored
2
.gitignore
vendored
@ -124,3 +124,5 @@ website/package-lock.json
|
||||
|
||||
# Toolchains
|
||||
/cmake/toolchain/*
|
||||
|
||||
*.iml
|
||||
|
||||
@ -4,53 +4,50 @@ ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)
|
||||
|
||||
在传统的行式数据库系统中，数据按如下顺序存储：
|
||||
|
||||
| row | watchID | JavaEnable | title | GoodEvent | EventTime |
|
||||
|-----|-------------|------------|------------|-----------|---------------------|
|
||||
| #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 | … | … | … | … | … |
|
||||
| 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。
|
||||
{: .灰色 }
|
||||
常见的行式数据库系统有：`MySQL`、`Postgres`和`MS SQL Server`。
|
||||
|
||||
在列式数据库系统中，数据按如下的顺序存储：
|
||||
|
||||
| row: | #0 | #1 | #2 | #N |
|
||||
| Row: | #0 | #1 | #2 | #N |
|
||||
|-------------|---------------------|---------------------|---------------------|-----|
|
||||
| watchID: | 89354350662 | 90329509958 | 89953706054 | … |
|
||||
| WatchID: | 89354350662 | 90329509958 | 89953706054 | … |
|
||||
| JavaEnable: | 1 | 0 | 1 | … |
|
||||
| title: | 投资者关系 | 联系我们 | 任务 | … |
|
||||
| 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 | … |
|
||||
| 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场景的关键特征 {#olapchang-jing-de-guan-jian-te-zheng}
|
||||
|
||||
- 大多数是读请求
|
||||
- 数据总是以相当大的批(\> 1000 rows)进行写入
|
||||
- 不修改已添加的数据
|
||||
- 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
|
||||
- 绝大多数是读请求
|
||||
- 数据以相当大的批次(\> 1000行)更新，而不是单行更新;或者根本没有更新。
|
||||
- 已添加到数据库的数据不能修改。
|
||||
- 对于读取，从数据库中提取相当多的行，但只提取列的一小部分。
|
||||
- 宽表，即每个表包含着大量的列
|
||||
- 较少的查询(通常每台服务器每秒数百个查询或更少)
|
||||
- 查询相对较少(通常每台服务器每秒查询数百次或更少)
|
||||
- 对于简单查询，允许延迟大约50毫秒
|
||||
- 列中的数据相对较小： 数字和短字符串(例如，每个URL 60个字节)
|
||||
- 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
|
||||
- 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
|
||||
- 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
|
||||
- 事务不是必须的
|
||||
- 对数据一致性要求低
|
||||
- 每一个查询除了一个大表外都很小
|
||||
- 查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中
|
||||
- 每个查询有一个大表。除了他意以外，其他的都很小。
|
||||
- 查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中
|
||||
|
||||
很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
toc_priority: 8
|
||||
toc_title: "\u91C7\u7528\u8005"
|
||||
toc_priority: 5
|
||||
toc_title: "ClickHouse用户"
|
||||
---
|
||||
|
||||
# ClickHouse用户 {#clickhouse-adopters}
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
toc_priority: 2
|
||||
toc_title: ClickHouse的特性
|
||||
---
|
||||
|
||||
# ClickHouse的特性 {#clickhouse-de-te-xing}
|
||||
|
||||
## 真正的列式数据库管理系统 {#zhen-zheng-de-lie-shi-shu-ju-ku-guan-li-xi-tong}
|
||||
@ -12,9 +17,13 @@
|
||||
|
||||
在一些列式数据库管理系统中(例如：InfiniDB CE 和 MonetDB) 并没有使用数据压缩。但是, 若想达到比较优异的性能，数据压缩确实起到了至关重要的作用。
|
||||
|
||||
除了在磁盘空间和CPU消耗之间进行不同权衡的高效通用压缩编解码器之外，ClickHouse还提供针对特定类型数据的[专用编解码器](../sql-reference/statements/create/table.md#create-query-specialized-codecs)，这使得ClickHouse能够与更小的数据库(如时间序列数据库)竞争并超越它们。
|
||||
|
||||
## 数据的磁盘存储 {#shu-ju-de-ci-pan-cun-chu}
|
||||
|
||||
许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果有可以使用SSD和内存，它也会合理的利用这些资源。
|
||||
许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。
|
||||
|
||||
ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果可以使用SSD和内存，它也会合理的利用这些资源。
|
||||
|
||||
## 多核心并行处理 {#duo-he-xin-bing-xing-chu-li}
|
||||
|
||||
@ -27,9 +36,11 @@ ClickHouse会使用服务器上一切可用的资源，从而以最自然的方
|
||||
|
||||
## 支持SQL {#zhi-chi-sql}
|
||||
|
||||
ClickHouse支持基于SQL的声明式查询语言，该语言大部分情况下是与SQL标准兼容的。
|
||||
支持的查询包括 GROUP BY，ORDER BY，IN，JOIN以及非相关子查询。
|
||||
不支持窗口函数和相关子查询。
|
||||
ClickHouse支持一种[基于SQL的声明式查询语言](../sql-reference/index.md)，它在许多情况下与[ANSI SQL标准](../sql-reference/ansi.md)相同。
|
||||
|
||||
支持的查询[GROUP BY](../sql-reference/statements/select/group-by.md), [ORDER BY](../sql-reference/statements/select/order-by.md), [FROM](../sql-reference/statements/select/from.md), [JOIN](../sql-reference/statements/select/join.md), [IN](../sql-reference/operators/in.md)以及非相关子查询。
|
||||
|
||||
相关(依赖性)子查询和窗口函数暂不受支持，但将来会被实现。
|
||||
|
||||
## 向量引擎 {#xiang-liang-yin-qing}
|
||||
|
||||
@ -55,12 +66,20 @@ ClickHouse提供各种各样在允许牺牲数据精度的情况下对查询进
|
||||
2. 基于数据的部分样本进行近似查询。这时，仅会从磁盘检索少部分比例的数据。
|
||||
3. 不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合。这在数据聚合条件满足某些分布条件下，在提供相当准确的聚合结果的同时降低了计算资源的使用。
|
||||
|
||||
## Adaptive Join Algorithm {#adaptive-join-algorithm}
|
||||
|
||||
ClickHouse支持自定义[JOIN](../sql-reference/statements/select/join.md)多个表，它更倾向于散列连接算法，如果有多个大表，则使用合并-连接算法
|
||||
|
||||
## 支持数据复制和数据完整性 {#zhi-chi-shu-ju-fu-zhi-he-shu-ju-wan-zheng-xing}
|
||||
|
||||
ClickHouse使用异步的多主复制技术。当数据被写入任何一个可用副本后，系统会在后台将数据分发给其他副本，以保证系统在不同副本上保持相同的数据。在大多数情况下ClickHouse能在故障后自动恢复，在一些少数的复杂情况下需要手动恢复。
|
||||
|
||||
更多信息，参见 [数据复制](../engines/table-engines/mergetree-family/replication.md)。
|
||||
|
||||
## 角色的访问控制 {#role-based-access-control}
|
||||
|
||||
ClickHouse使用SQL查询实现用户帐户管理，并允许[角色的访问控制](../operations/access-rights.md)，类似于ANSI SQL标准和流行的关系数据库管理系统。
|
||||
|
||||
# 限制 {#clickhouseke-xian-zhi}
|
||||
|
||||
1. 没有完整的事务支持。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
toc_priority: 4
|
||||
toc_title: ClickHouse历史
|
||||
---
|
||||
|
||||
# ClickHouse历史 {#clickhouseli-shi}
|
||||
|
||||
ClickHouse最初是为 [YandexMetrica](https://metrica.yandex.com/) [世界第二大Web分析平台](http://w3techs.com/technologies/overview/traffic_analysis/all) 而开发的。多年来一直作为该系统的核心组件被该系统持续使用着。目前为止，该系统在ClickHouse中有超过13万亿条记录，并且每天超过200多亿个事件被处理。它允许直接从原始数据中动态查询并生成报告。本文简要介绍了ClickHouse在其早期发展阶段的目标。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
toc_priority: 3
|
||||
toc_title: ClickHouse性能
|
||||
---
|
||||
|
||||
# 性能 {#performance}
|
||||
|
||||
根据Yandex的内部测试结果，ClickHouse表现出了比同类可比较产品更优的性能。你可以在 [这里](https://clickhouse.tech/benchmark/dbms/) 查看具体的测试结果。
|
||||
|
||||
Loading…
Reference in New Issue
Block a user