共计 15555 个字符，预计需要花费 39 分钟才能阅读完成。
clickhouse 简介
ClickHouse 是一个开源的，面向列的 MPP 架构数据分析数据库（大规模并行处理），由俄罗斯 Yandex 为 OLAP 和大数据用例创立。
ClickHouse 全称是 Click Stream,Data Warehouse，简称 ClickHouse 就是基于页面的点击事件流，面向数据仓库进行 OLAP 剖析。
ClickHouse 对实时查询处理的反对使其实用于须要亚秒级剖析后果的应用程序。
ClickHouse 的查询语言是 SQL 的一种方言，它反对弱小的申明性查问性能，同时为最终用户提供相熟度和较小的学习曲线。
ck 的劣势和有余
劣势：
查问速度十分快，每台服务器每秒解决上亿或上百亿行的数据。
能够充分利用硬件多线程实现单个查问的分支解决性能超过每秒 2tb
数据存储通过压缩，可能缩小 io
存储引擎弱小
性能好：
一亿性能比照：
十亿性能比照
容错与高牢靠：
反对分布式集群
反对多主机异步复制，可跨多数据中心部署
所有节点都相等避免出现单点故障
单个节点或整个数据中心停机工夫不影响零碎读写可用性
包含许多企业健全性能和针对认为谬误的故障安全机制
有余：
不反对事务(这其实也是大部分 OLAP 数据库的毛病)
不善于依据主键按行粒度查问(然而反对这种操作)，它是按列存储，按列查问，故并不很适宜按行查问的场景。
不善于按行删除数据(然而反对这种操作)，按行删除数据性能较低
ClickHouse 的个性
定位是剖析性数据库，即 OLAP，不是严格的关系型
OLAP(关系型的联机剖析解决 ’ 基于大批量数据聚合统计分析，侧重于查问 ’，和它一起比拟的还有 OLTP 联机事务处理 ’ 基于事务的数据处理剖析，侧重于事务 ’，咱们常见的 ERP,CRM 零碎就属于 OLTP)
残缺的 DBMS(关系数据库)
具备 database、table、row、DDL、DML、用户、权限管制、数据备份、数据恢复、分布式治理的性能、反对大规模并行运算、每个节点存储对应分区数据
列式存储数据库
雷同的列的数据存在一起，查问的时候只查须要的列，其余的列不关注，不做 io，防止全表扫描，有更好的压缩比。
在线实时查问
不须要任何数据预处理
反对批量更新
领有欠缺的 SQl 反对和函数
反对高可用
不依赖 Hadoop 简单生态(像 ES 一样，开箱即用)
ClickHouse 利用场景
ck 比拟实用于广告流量，web 流量，app 浏览，金融，电子商务，信息安全，电信网络游戏和物联网等畛域
非常适合大数据分析的场景，能够用于电信数据的存储和统计，用户行为的数据记录和剖析，信息安全日志剖析，商业智能与广告网络价值的数据挖掘，以及网络游戏和物联网的数据分析和解决。
ClickHouse 作为一款高性能 OLAP 数据库，但并不适宜事务性场景
clickhouse 的数据拜访流程
server
ck 服务器实现了多个不同的接口：
1. 用与内部客户端的 http 接口
2. 用于数据传输拷贝的接口
3. 用于本机的 ClickHouse 客户端接口，也作为在分布式查问执行中跨服务器通信的 TCP 接口
Parser 分析器
负责创立 AST 对象（形象语法树）
将一条 SQL 解析成 AST 语法树的模式，不同的 SQL 有不同的 Parser 分析器来解析
Intercepter 解释器
负责解释 AST 对象，创立查问的执行通道
IStorage 存储接口
负责依据 AST 语句的要求返回指定列的原始数据
定义了 DDL、read、write 办法，负责数据定义查问和写入
Block
ClickHouse 外部的数据操作均是通过操作 Block 对象实现的。
Block 对象蕴含了数据对象（Column）、数据类型（DataType）、列名组成的三元组，Block 对象进一步形象和封装了该三元组，使得通过 Block 对象能够实现一系列的数据操作
Column 和 Field
Column 提供了数据的读取能力
Column 和 Field 是 ck 最根底的映射单元
ck 按列存储数据，每列数据由一个 Column 对象示意，Field 示意 Column 的一个单值 (也就是单列中的一行数据)
DataType
数据类型由 DataType 负责，提供了序列化和反序列化，从 Column 和 Field 获取数据
Function
ck 提供两类函数（一般函数和聚合函数）
一般函数由 IFunction 接口定义
聚合函数有状态，由 IAggregateFunction 定义，以 COUNT 聚合函数为例，其 AggregateFunctionCount 的状态应用整型 UInt64 记录。状态反对序列化和反序列化，在分布式节点间能够进行传输，实现增量计算。
装置单点 clickhouse
反对的平台：x86_64、AArch64、Power9
# 官网预构建的二进制文件通常为 x86_64 编译并利用 SSE 4.2 指令集，须要进行检测
grep -q sse4_2 /proc/cpuinfo && echo "SSE 4.2 supported" || echo "SSE 4.2 not supported"
#来自 DEB 包的装置形式：sudo apt-get install -y apt-transport-https ca-certificates dirmngr
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 8919F6BD2B48D754
echo "deb https://packages.clickhouse.com/deb stable main" | sudo tee \
/etc/apt/sources.list.d/clickhouse.list
sudo apt-get update
sudo apt-get install -y clickhouse-server clickhouse-client
#启动 clickhouse-server 默认端口 9000
sudo service clickhouse-server start
#启动 clickhouse-client 链接 server
clickhouse-client # or "clickhouse-client --password" if you've set up a password.
#能够用以下形式装置对应版本
sudo apt-get install clickhouse-server=21.8.5.7 clickhouse-client=21.8.5.7 clickhouse-common-static=21.8.5.7
# arm 零碎须要应用 wget 获取对应版本包
wget --progress=bar:force:noscroll "https://builds.dev.altinity.cloud/apt-repo/pool/main/clickhouse-client_21.8.5.7.dev_all.deb" -P /tmp/clickhouse_debs
wget --progress=bar:force:noscroll "https://builds.dev.altinity.cloud/apt-repo/pool/main/clickhouse-common-static_21.8.5.7.dev_arm64.deb" -P /tmp/clickhouse_debs
wget --progress=bar:force:noscroll "https://builds.dev.altinity.cloud/apt-repo/pool/main/clickhouse-server_21.8.5.7.dev_all.deb" -P /tmp/clickhouse_debs 部署中可能用到的一些额定配置
文件句柄数量配置：/etc/security/limits.d/clickhouse.conf
在 linux 下每一个 tcp 连贯都要占一个文件描述符，如果达到下限，就会呈现谬误：“Socket/File:Can’t open so many files”。
如果配置太小可能会影响性能。
定时工作配置：/etc/corn.d/clickhouse-server
与 MySQL 相似，启动 clickhouse 程序会启动一个服务过程，默认端口 9000，一台主机上可启动多实例，须要应用不同端口。
服务启动后会默认创立 system 与 default 两个数据库。
ck 的常见命令
# 根本和 mysql 差不多
SHOW databases;
SHOW tables;
USE [database];
DESC [table];
SELECT * from [database].[table];
SHOW CREATE insert_select_testtable;
CREATE TABLE insert_select_testtable
(
`a` Int8,
`b` String,
`c` Int8
)
ENGINE = MergeTree()
ORDER BY a ;
INSERT INTO insert_select_testtable (*) VALUES (1, 'a', 1) ;
ck 的外围目录
服务端配置文件目录: /etc/clickhouse-server
数据目录(默认目录): /var/lib/clickhouse
ck 的表数据存于 /var/lib/clickhouse/data/[database]/[table]目录下
表的元数据目录：/var/lib/clickhouse-server/metadata
日志目录：/var/log/clickhouse-server
有 clickhouse-server.err.log 和 clickhouse-server.log 文件
可执行文件目录：/user/bin
clickhouse 主程序的可执行文件
clickhouse-client 客户端可执行文件
clickhouse-server 服务端可执行文件
clickhouse-compressor 内置的解压缩工具
CK 的索引
默认提供两种索引，稠密索引和跳数索引，
依据索引所笼罩的行数产生索引标记来记录数据的区间信息
稠密索引
按主键或者排序键进行排序后保留，默认粒度 8192 行。稠密索引只须要应用大量的索引标记就能够记录大量数据的区间地位信息，这样索引文件足够小，常驻内存取用更快
跳数索引
由数据的聚合产生（Max/min 等）数据通过距离力度构建索引后，跳数索引会依据索引粒度对数据进行汇总（跳跃）。
跳数索引的粒度其实相当于对已构建的索引的合并。
ck 的数据类型
不同版本的 clickhouse 的数据类型有所区别，具体能够应用以下命令查问：
select * from system.data_type_families;
# 数据类型的官网名称 是否辨别大小写 别名 别名和官名用哪个都行
┌─name────────────────────────────┬─case_insensitive─┬─alias_to────┐
│ BLOB │ 1 │ String │
└─────────────────────────────────┴──────────────────┴─────────────┘
比拟根底的数据类型
这里列举了一些和其余的数据库没有太大区别的数据类型。
UInt8, UInt16, UInt32, UInt64, UInt128, UInt256, Int8, Int16, Int32, Int64, Int128, Int256
uuid
Datetime64,Date32
Float32, Float64
Decimal(P, S), Decimal32(S), Decimal64(S), Decimal128(S), Decimal256(S)
string
留神 ck 并没有提供 bool 数据类型，能够应用 uint8 取值限度为 0 或者 1
FixedString(N)
存储固定长度（按字节数计）字符串
如果字符串蕴含的字节数少于字符串，则用空字节补充字符串 N。
Too large value for FixedString(N)如果字符串蕴含多于 N 字节，则引发异样。
查问数据时，ClickHouse 不会删除字符串开端的空字节。如果应用 WHERE 子句，则须要手动增加空字节以匹配该 FixedString 值
比方：当 FixedString(2)的数据 k 值为 a，应用 where k = ‘a’ 无奈查到该叙述，须要应用 where k =’a\0’
FixedString(N)的长度是个常量。仅由空字符组成的字符串，函数 length 返回值为 N, 而函数 empty 的返回值为 1，即有长度的空字符串
LowCardinality(data_type)
把其它数据类型转变为字典编码类型。
它适宜长度和定义域都可变，但总体基数不是特地大的列
低基数是一种润饰类型，即用法为 LowCardinality(type)。其中 type 示意的原始类型能够是 String、FixedString、Date、DateTime，以及除了 Decimal 之外的所有数值类型。一般来说 string 比拟罕用。
它应用字典地位进行过滤、分组、减速某些函数（例如 length()）.
应用 LowCarditality 数据类型的效率依赖于数据的多样性。如果一个字典蕴含少于 10000 个不同的值，那么 ClickHouse 能够进行更高效的数据存储和解决。反之如果字典多于 10000，效率会体现的更差。
当应用字符类型的时候，能够思考应用 LowCardinality 代替 enum。LowCardinality 通常更加灵便和高效。
CREATE TABLE lc_t
(
`id` UInt16,
`strings` LowCardinality(String)
)
ENGINE = MergeTree()
ORDER BY idarray(T)
在同一数组内能够蕴含多种数据类型，然而数据类型必须要兼容; 定义表的时候数组须要明确指定元素类型.
数组的最大大小限度为一百万个元素。
如果 ClickHouse 无奈确定数据类型，则会生成异样。当尝试同时创立蕴含字符串和数字的数组时会产生这种状况。
举例：
CREATE TABLE t_arr (`arr` Array(Array(Array(UInt32)))) ENGINE = MergeTree ORDER BY tuple();
INSERT INTO t_arr VALUES ([[[12, 13, 0, 1],[12]]]);
SELECT arr.size0, arr.size1, arr.size2 FROM t_arr;
#后果：┌─arr.size0─┬─arr.size1─┬─arr.size2─┐
│ 1 │ [2] │ [[4,1]] │
└───────────┴───────────┴───────────┘
Enum
由命名值组成的枚举类型。
命名值必须申明为 ’string’ = integer 对。ClickHouse 仅存储数字，但反对通过名称对值进行操作。
ClickHouse 主动抉择 Enum 插入数据的类型。反对应用 Enum8 或 Enum16 类型来确定存储的大小。
# 创立一个带有一个枚举 Enum8('hello' = 1, 'world' = 2) 类型的列：CREATE TABLE t_enum
(x Enum8('hello' = 1, 'world' = 2)
)
ENGINE = TinyLog
#这个 `x` 列只能存储类型定义中列出的值：`'hello'` 或 `'world'`。如果尝试保留任何其余值，ClickHouse 抛出异样。Tuple
组类型由 1～n 个元素组成，每个元素之间容许设置不同的数据类型，且彼此之间不要求兼容。元组反对类型推断，其推断根据以最小存储代价为准则。
SELECT tuple(1,'a') AS x, toTypeName(x)
┌─x───────┬─toTypeName(tuple(1, 'a'))─┐
│ (1,'a') │ Tuple(UInt8, String) │
└─────────┴───────────────────────────┘
SELECT tuple(1, NULL) AS x, toTypeName(x)
┌─x────────┬─toTypeName(tuple(1, NULL))──────┐
│ (1,NULL) │ Tuple(UInt8, Nullable(Nothing)) │
└──────────┴─────────────────────────────────┘
CREATE TABLE named_tuples (`a` Tuple(s String, i Int64)) ENGINE = Memory;
INSERT INTO named_tuples VALUES (('y', 10)), (('x',-10));
#应用名称查找元素
SELECT a.s FROM named_tuples;
┌─a.s─┐
│ y │
│ x │
└─────┘
#应用索引查找元素
SELECT a.2 FROM named_tuples;
┌─tupleElement(a, 2)─┐
│ 10 │
│ -10 │
└────────────────────┘Nested(name1 Type1, Name2 Type2, …)
嵌套数据结构相似于嵌套表。一张数据表，能够定义任意多个嵌套类型字段，但每个字段的嵌套层级只反对一级，即嵌套表内不能持续应用嵌套类型。
CREATE TABLE dept (
name String,
people Nested(
id UInt8,
name String
)
) ENGINE = Memory;
INSERT INTO dept VALUES ('研发部',[001,002,003],['小李','小张','小刘']);
INSERT INTO dept VALUES ('测试部',[001,002],['小李','小张']);
SELECT name, dept.id, dept.name FROM nested_test;
┌─name──┬──people.id────┬─people.name──────────┐
│ 研发部 │ [001,002,003] │ ['小李','小张','小刘'] │
└───────┴───────────────┴──────────────────────┘
┌─name──┬─people.id─┬─people.name────┐
│ 测试部 │ [001,002] │ ['小李','小张'] │
└───────┴───────────┴────────────────┘
INSERT INTO dept VALUES ('研发部',003,'小刘');
# 报错：DB::Exception: Type mismatch in IN or VALUES section. Expected: Array(UInt8). Got: UInt64
INSERT INTO dept VALUES ('研发部',[001,002],['小李','小张','小刘']);
# DB::Exception: Elements 'people.id' and 'people.name' of Nested data structure 'people' (Array columns) have different array sizes..
AggregateFunction
AggregateFunction 是 clickhouse 提供的一种非凡的数据类型，它可能以二进制的模式存储中间状态后果。
其应用办法也非常非凡，对于 AggregateFunction 类型的列字段，数据的写入和查问都与寻常不同。在写入数据时，须要调用 State 函数。而在查问数据时，则须要调用相应的 Merge 函数。
-- 建表语句 这里 uniq 和 sum 是指定的聚合函数，而 uniqState、uniqMerge 是函数对应的 State 和 Merge 函数
CREATE TABLE t
(
id String,
code AggregateFunction(uniq,String),
value AggregateFunction(sum,UInt32),
) ENGINE = ...
-- 写入测试数据;
INSERT INTO TABLE t SELECT 'A000', uniqState('code1'), sumState(toUInt32(100));
INSERT INTO TABLE t SELECT 'A000', uniqState('code1'), sumState(toUInt32(100));
INSERT INTO TABLE t SELECT 'A001', uniqState('code1'), sumState(toUInt32(100));
INSERT INTO TABLE t SELECT 'A001', uniqState('code2'), sumState(toUInt32(50));
-- 查问数据
SELECT id,uniqMerge(code),sumMerge(value) FROM t GROUP BY id;
┌─id────┬─uniqMerge(code)─┬─sumMerge(value)─┐
│ A001 │ 2 │ 150 │
│ A000 │ 1 │ 200 │
└───────┴─────────────────┴─────────────────┘Nullable(typename)
容许将示意“缺失值”的非凡标记 (NULL) 与容许的正常值一起存储 TypeName。例如，Nullable(Int8)类型列能够存储 Int8 类型值，而没有值的即将存储 NULL.
对于 a TypeName，您不能应用复合数据类型 [Array] 和[Tuple]。复合数据类型能够蕴含 Nullable 类型值，例如 Array(Nullable(Int8)).
留神：为了存储空值会额定占用存储空间，会对性能有影响。
CREATE TABLE t_null(x Int8, y Nullable(Int8)) ENGINE TinyLog
INSERT INTO t_null VALUES (1, NULL), (2, 3)
SELECT x + y FROM t_null
┌─plus(x, y)─┐
│ ᴺᵁᴸᴸ │
│ 5 │
└────────────┘
# 如果对应的是 null 返回 1 否则返回 0
SELECT y.null FROM t_null;
┌─n.null─┐
│ 1 │
│ 0 │
└────────┘Domain
域名类型分为 IPv4 和 IPv6 两类，实质上它们是对整型和字符串的进一步封装
IPv4 应用 UInt32 存储，相比 String 更加紧凑，占用的空间更小，查问性能更快
CREATE TABLE IP4_TEST (
url String,
ip IPv4
) ENGINE = Memory;
INSERT INTO IP4_TEST VALUES ('www.baidu.com','192.0.0.0');
SELECT url,ip,toTypeName(ip) FROM IP4_TEST;
#谬误的 ip 无奈写入
INSERT INTO IP4_TEST VALUES ('www.baidu.com','192.0.0');
# DB::Exception: Invalid IPv4 value.IPv6 类型是基于 FixedString(16)封装的，它的应用办法与 IPv4 一样。
数据库引擎
延时引擎 Lazy
最近一次拜访距离 expiration_time_in_seconds` 秒，将数据存到内存里，只能用于 *Log 表。
它是为存储许多小的 *Log 表而优化的，对于这些表，两次拜访之间的工夫距离很长。
CREATE DATABASE testlazy ENGINE = Lazy(expiration_time_in_seconds);Atomic
默认引擎
它反对非阻塞的 [DROP TABLE] 和[RENAME TABLE]查问和原子的 [EXCHANGE TABLES t1 AND t2] 查问。
数据库 Atomic 中的所有表都有惟一的 UUID，并将数据存储在目录 /clickhouse_path/store/xxx/xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/，其中 xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy 是该表的 UUID。
RENAME TABLES 是在不更改 UUID 和挪动表数据的状况下执行的。这些查问不会期待应用表的查问实现，而是会立刻执行。
在 DROP TABLE 时，不删除任何数据，数据库 Atomic 只是通过将元数据挪动到 /clickhouse_path/metadata_dropped/ 将表标记为已删除，并告诉后盾线程。最终表数据删除前的提早由 [database_atomic_delay_before_drop_table_sec] 设置指定。
能够应用 SYNC 修饰符指定同步模式。应用 [database_atomic_wait_for_drop_and_detach_synchronously] 设置执行此操作，DROP 期待运行 SELECT, INSERT 和其余应用表实现的查问。表在不应用时将被理论删除。
MySQL
MySQL 引擎用于将近程的 MySQL 服务器中的表映射到 ClickHouse 中，并容许对表进行 INSERT 和 SELECT 查问，以不便在 ClickHouse 与 MySQL 之间进行数据交换
MySQL 数据库引擎会将对其的查问转换为 MySQL 语法并发送到 MySQL 服务器中，因而能够执行诸如 SHOW TABLES 或 SHOW CREATE TABLE 之类的操作。
然而不能应用 RENAME，CREATE TABLE，ALTER
CREATE DATABASE [IF NOT EXISTS] db_name [ON CLUSTER cluster]
ENGINE = MySQL('host:port', ['database' | database], 'user', 'password')表引擎
表引擎有以下作用
1. 数据如何存储，放在哪儿
2. 反对哪些查问，如何反对
3. 对并发拜访的反对，是否多线程申请形式执行语句
4. 所反对的查问品种
5. 是否反对索引
6. 主备复制的反对
CK 提供了近 30 种表引擎，分为四类：log、MergeTree、Special、Integration
Log（日志）
用于做小表的数据分析（100 万行左右）。
TinyLog、StripeLog、Log
独特特点
数据存储在磁盘上。
写入时将数据追加在文件开端。
不反对渐变操作。
不反对索引（这意味着 SELECT 在范畴查问时效率不高。）
非原子地写入数据（如果某些事件毁坏了写操作，例如服务器的异样敞开，表内数据不残缺）
差别：
Log 和 StripeLog 引擎都反对：
并发拜访数据的锁。（INSERT 申请执行过程中表会被锁定，并且其余的读写数据的申请都会期待直到锁定被解除。如果没有写数据的申请，任意数量的读申请都能够并发执行。）
并行读取数据。（在读取数据时，ClickHouse 应用多线程。每个线程解决不同的数据块。）
TinyLog：
对并发拜访没有限度（没有锁）
如果同时从表中读取并在不同的查问中写入，则读取操作将抛出异样 如果同时写入多个查问中的表，则数据将被毁坏。
Log：
Log «标记» 的小文件与列文件存在一起。
这些标记写在每个数据块上，并且蕴含偏移量，这些偏移量批示从哪里开始读取文件以便跳过指定的行数。这使得能够在多个线程中读取表数据。
对于并发数据拜访，能够同时执行读取操作，而写入操作则阻塞读取和其它写入。
Log 引擎实用于长期数据，write-once 表以及测试或演示目标。
MergeTree（合并树）
该类型引擎用于做大数据量剖析，是 ClickHouse 官网次要举荐的引擎类型，反对简直所有的 ClickHouse 外围性能。
罕用的存储引擎：
MergeTree：
该引擎中数据按列存储，每个列数据以二进制模式独自压缩，性能最好
ReplacingMergeTree：
基于 MergeTree 复制引擎，在分布式高可用汇总联合 zk 做正本复制
Distributed：
分布式引擎，此类表不存储数据，相当于视图性能，写入数据到分布式表中，会把申请分不到集群的各个分片中；在查问的时候做聚合查问再返回
Special
为特定的场景定制，例如：内存、缓存和文件
Integration
用于对其余内部数据库表的集成
比方将内部数据导入或者间接读取其余的数据源
ClickHouse 集群
ClickHouse 集群解决的是高可用与负载平衡的问题，一个集群能够用多个节点组成，当某集群节点呈现故障后不影响整个集群的失常应用
什么是分区
在 clickhouse 中对于一张表做分区，则是对数据的纵向切分，数据以目录的模式存在，在写入时创立，雷同分区的数据最终合并到同一个分区目录，不同分区的数据不会被合并到一起。
分区不能解决各个节点的数据分布问题，只能够升高数据文件的搜寻范畴。
CK 分布式集群
该分布式集群有两个分布式节点，每个分布式节点上有一个本地表，都有一个分布式表（Distributed），读取数据的时候分布式表会在两个本地表（也能够说是分片）中都读取数据汇总后返回给用户，收到的读写工作时，分布式表将工作散发到各个本地表。
原理如下图：
本地表
寄存用户理论的数据，一个本地表等同于一份数据分片
分布式表
是一个逻辑概念，不存储任何数据，是本地表的拜访代理，相似于 MySQL 中的视图，作用相似于分库中间件
多个节点上有多个本地表，集群中有一个分布式表，数据存入的时候 会由分布式表将数据随机扩散到多个分片中，这时如果有一个节点坏掉，集群中数据会失落一部分（即坏掉的分片的数据没了）
应用 on cluster 语句在集群的某台机器上执行以下代码，即可在每台机器上创立本地表和分布式表，其中⼀张本地表对应着⼀个数据分⽚，分布式表通常以本地表加“_all”命名。它与本地表造成⼀对多的映射关系，之后能够通过分布式表代理操作多张本地表。
这里有个要留神的点，就是分布式表的表构造尽量和本地表的构造统一。如果不统一，在建表时不会报错，但在查问或者插入时可能会抛出异样。在集群中应用，咱们要加上 on cluster <cluster_name> 的 ddl，这样咱们的建表语句在某一台 clickhouse 实例上执行一次即可散发到集群中所有实例上执行。
先在每一个分片上创立本地表：
-- 应用 ReplicatedMergeTree 引擎创立本地表 test_log
create table test_log on cluster ck_cluster
(
totalDate Date,
unikey String
)
engine = ReplicatedMergeTree('/clickhouse/test/tables/{shard}/test_log', '{replica}')
PARTITION BY totalDate
ORDER BY unikey
SETTINGS index_granularity = 8192;分布式表引擎的创立模板：
ENGINE = Distributed(cluster, database, table, [sharding_key])参数形容：
cluster：集群名称，在对分布式表执⾏读写的过程中，它会使⽤集群的配置信息来找到相应的 host 节点。database，table：数据库和本地表名称，用于将分布式表映射到本地表上。sharding_key: 分⽚键，分布式表会依照这个规定，将数据散发到各个本地表中。
-- 创立分布式表 test_log_all，数据在读写时会依据 rand()随机函数的取值，决定数据写⼊哪个分⽚，也能够用 hash 取值。create table test_log_all on cluster ck_cluster
(
totalDate Date,
unikey String
)
engine = Distributed('ck_cluster', 'test', 'test_log', rand());CK 的正本复制
对每个分片复制了一份正本，放在其余的节点上，即做了数据备份，当某节点坏掉，会从其余节点的正本读取数据。
ClickHouse 只容许一个实例持有一个分片，所以在生产环境中，个别采纳两个甚至多个对等的集群相互复制和热备（依附 ReplicatedMergeTree 引擎族实现复制表），当某集群上的某节点挂掉后，能够由其余集群上持有对应分片的节点顶上，实现高可用。
CK 的正本复制不可避免升高了性能，假如说一个 2 核的机器，原本创立一个 ck 实例，这个 ck 实例能够用 2 核的 cpu 计算能力，然而当减少正本时，每个正本只能应用 1 个 cpu 的计算能力了。
然而其实对于大多数应用 ClickHouse 的场景来说，ck 都是被用于数据分析应用，在这样的场景下数据都是从其余的生产库中周期抽取，进行大数据分析的，所以数据其实是被容许失落的。
然而如果数据失落后，须要从新将所有的数据同步过去，可能会付出较大的代价，所以个别会创立一个副原本应用，保障集群的可用性。
分布式集群的读写规定
数据写入：
如果间接写入的是 A1/B1/C1，那么对应的复本表会写同样的数据
如果写入的是分布式表，则依据规定随机平分写入或者独自写入到某个分片中，正本进行复制
数据读取：
会从 A /B/ C 同时读取数据，A 中的数据随机从 A1 或者 A2 读取，读取到所有数据后合并到一起返回后果，如果 A1 挂了会从 A2 读，不影响集群读取
常见的 CK 分布式计划
计划 1：纯分片
该计划在不同节点上创立分片，应用 Distributed+MergeTree 构造。
长处：
架构简略
并行查问分布式表，查问速度十分快
毛病：
如果某个分片节点损坏，会失落数据且无奈复原，查问会报错，整个集群会瘫掉
实用场景：
不常常做剖析，然而有数据分析需要，集群不须要继续运行提供服务，然而数据量较大（数据少能够间接用单点），采纳该形式进步查问剖析的效率，满足需要。
计划 2：分片 + 正本复制
该计划在不同节点上创立分片，并对每个分片做正本复制，应用 Distributed+MergeTree 构造，正本复制由 Distributed 管制
**
长处：**
数据安全有保障，不存在某一数据节点故障后无奈查问，集群瘫掉的问题
并行查问分布式表，速度快
毛病：
某个节点存储损坏后，节点再次上线或者用其余的新节点上线，都会被视为空节点，损坏前该损坏节点所存储的数据无奈复原，只能保障新数据的，当另外一个分片坏掉时（低概率事件），仍然会面临集群数据失落集群瘫痪的问题
复制和分片数据散发均为 Distributed 组件管制，Distributed 呈现问题，集群就会出问题。
**
实用场景：**
这种架构实用于有新数据周期性写入，只对新数据做剖析不对老数据分析的场景（老数据会舍弃）
计划 3：分片 + 正本复制 + 高可用
该计划在不同节点上创立分片，并对每个分片做正本复制，应用 ReplicatedMergeTree+Distributed+Zookeeper 构造。
本地表应用 ReplicatedMergeTree 形式创立
Zookeeper 是一个分布式服务框架，次要用于解决分布式应用中遇到的一些数据管理问题，例：对立命名服务，状态同步服务、集群治理，分布式应用配置项的治理。
长处：
共享同一个 Zookeeper 门路的表，互相同步数据，数据安全有保障，不存在节点故障，新节点上线 Zookeeper 会把损坏前的数据同步。
并行查问分布式表，速度快
毛病：
如果一次几百万写入，容易导致 Zookeeper 集群压力过大出现异常（能够采纳写入本地表，读取分布式表的计划，可保障每秒几百个 insert 操作）
相比非复制表，insert 的提早略大，须要期待 Zookeeper 集群驱动复制。
老本较高
实用场景：
适宜数据量大，安全性要求高的生产环境，是最优的分布式高可用集群计划
生产环境计划总结
应用计划 3
正本数量至多为两个，即两份数据
通过外围负载平衡散发形式 写表写本地表，读表读分布式表，表治理对立入口
默认并发 100 左右
批量写入不倡议小批量，小批量写入会造成过多的数据合并，性能会降落
倡议不要在一台主机内应用多实例，ck 应用时很容易跑满 cpu
倡议 zk 5 节点，不和 ck 在同一主机
节点配置：CPU48 核、内存 128G\192G、磁盘 SSD RAID5/10、数据量 1TB/40 亿左右
对于【云原生小课堂】
【云原生小课堂】是由灵雀云、Kube-OVN 社区、云原生技术社区联结开设的公益性技术分享类专题，将以丰盛详实的精品内容和灵活多样的出现模式，继续为您分享云原生前沿技术，带您理解更多云原生实际干货。
在数字化转型的背景下，云原生曾经成为企业翻新倒退的外围驱动力。作为国内最早将 Kubernetes 产品化的厂商之一，灵雀云从出世便携带“云原生基因”，致力于通过革命性的技术帮忙企业实现数字化转型，咱们期待着云原生给这个世界带来更多扭转。
关注咱们，学习更多云原生常识，一起让扭转产生。
