如果数据跑得足够快，ddl 就追不上我

2

1

9

Clickhouse安装部署

官方网站下载对应的安装包，clickhouse 仅支持 ubuntn ，不过也提供了 centos 6、7的安装包，其他类操作系统自行参考官网。

下载地址：

http://repo.red-soft.biz/repos/clickhouse/stable/

RPM安装方式: 按照顺序依次安装即可。存在系统包冲突可以更新相关的依赖。

集群配置：参考官方说明

自从体验了一把 CH 导入数据，写入和查询速度真的是杠杠滴～

－

Clickhouse表引擎

执行官方Sample SQL 创建本地表（MergeTree）、分布式表(Distributed), 测试插入数据，可以在其他节点上进行查询。

MergeTree主要特性:

1.按照主键存储数据；

2.一个mergeTree类型的表必须拥有一个Date类型的字段，值得注意的是不能为 DateTime 类型。

3.并且在设置主键的时候，需要将Date类型字段与主键进行绑定。

Distributed：

1.如果一个表是分布式表，那么这个表并不存储实际数据，而是将该表的查询转化为多台服务器的查询.

2.Distributed相当于是多个本地表的逻辑视图.

Distributed表引擎要素

1.集群名称：metrika.xml中clickhouse_remote_servers下面包含的机器

2.数据库名称：clickhouse实例中的数据库名称

3.表名称：确认那些表是采取分布式表引擎

1.如果向其中分布式表的一台实例进行 insert into, 那么数据会先落盘到当前服务器，然后数据异步进行分发到其他的服务器上所在的 clickhouse 实例。

2.如果数据写入的过程中，其中的一个节点出现down掉的情况，那么会有数据丢失的情况（单纯的dt表没有副本），没有同步成功的xxx.bin文件会保留，但是当节点恢复正常的时候，数据会重新同步到重启的clickhouse上。

－

数据插入的三种方式

Values:

insert into db.table (date, datetime, domian, uri, http_code) values ('2018-03-18', '2018-03-19 10:44:57', 'sina.com.cn', '/sports', 200), ('2018-03-18', '2018-03-19 10:44:57', 'sina.com.cn', '/finance', 403)

JSONEachRow:

insert into db.table format JSONEachRow {"date":"2018-03-18", "datetime": "2018-03-19 10:44:57", "domain":"sina.com.cn", "uri": "/sports", "http_code":200}{"date":"2018-03-18", "datetime": "2018-03-19 10:44:57", "domain":"sina.com.cn", "uri": "/finance", "http_code":403}

TapSeparated:

insert into db.table (date, datetime, domian, uri, http_code) FORMAT TabSeparated

总结: values性能中等; JSONEachRow性能较差,操作不方便，容易产生信息报错; TabSeparated性能较好,不会产生插入报错,但是字段需要进行严格把控。

－

数据以什么方式写入比较好

数据写入的方式有多种，影响因素也非常多，有磁盘阵列方式、磁盘类型、数据量，机器数量，语句，采取的表引擎等等，还与写入的方式相关; 具体测试参考官方以及第三方的测试方法

－

Clickhouse 为什么那么快

Question: OLAP 类型的数据库非常多，例如 Hbase（更关注实时查询）、Hive（更加关注数据处理）, 在牺牲 transaction 的前提下数据在写入的条件下如何做优化 ?

A1: 顺序读写比随机读写效率高已经是一个常识， Hbase 就是采取 LSM 这种思路（什么是LSM 可以参见我之前 Hbase的那篇笔记摘抄）来做存储层面的优化，同时加入了 mergeTree 和 log 进行批量写，加大了吞吐量。那么 CH 是如何做的呢？

A2: 值得注意的是 clickhouse 的 mergeTree 与

Habse LSM 的那个 tree不一样, 准确来说是变种，

因为 CH没有使用memtable 和 log, 不写内存表，

不写log, 直接落地磁盘，异步 merge, 分块写。

A3: 具体一点就是 CH 的 mergeTree，稍微具体一点就是 CH 在查询数据的时候，使用primary.idx 去定位到数据的位置，然后查询 column.mrk 去计算偏移量，由于使用的是稀疏索引，会有额外不需要的数据也被读取到（index_granularity参数控制?），压缩的数据块还需要 decompress，因此 CH 不适合高负载的单点查询。之所以采取稀疏索引就是为了支持万亿级的列在单机上能够不占大量内存。当大量的数据写入的时候，数据会按照 primary key order 形成新的 part, 为了保证块不那么多，后台会定期进行合并 (这个好多数据库都有 merge）

emmmm...整理得不够细,一是踩坑还不够多,二是核心还不理解,具体细节也无法公开,只能算是开篇，上述有结合自己翻译理解和参考文档可能存在错误，慎读23333.

参考：

https://clickhouse.yandex/docs/zh/development/architecture/

https://blog.csdn.net/u013676711/article/details/78862243

etc.