doris和clickhouse,clickhouse使用场景

本文目录

• 1.clickhouse使用场景
• 2.clickhouse数据存储结构
• 3.doris是什么意思
• 4.clickhouse之replication配置及使用

clickhouse使用场景

1，查询强烈要求带上分区键过滤和主键过滤，如 where day = today() and itime = now()。

2，建表的时候，选择合适的分区键和排序键是优化的关键。

3，如果不允许重复主键(且不要求去重时效性)，建议使用表类型：ReplicatedReplacingMergeTree 建表语句可参考 https://clickhouse.yandex/docs/en/operations/table_engines/replacingmergetree/ ,注意只能保证单节点的数据不重复，无法保证集群的。

4，如果要对某一列过滤，且该列非partition key和orderby key, 且该列过滤前后数据量差异较大，建议使用prewhere clause过滤。参考： https://clickhouse.yandex/docs/en/query_language/select/#prewhere-clause 。

5，日期和时间使用Date, DateTime类型，不要用String类型。

6，建表时，强烈建议低基数(基数小于10000)且类型为String的列，使用 LowCardinality 特性，例如国家(country)，操作系统(os)皆可用LowCardinality。查询效益提高可以40~50%，具体参考 https://altinity.com/blog/2019/3/27/low-cardinality 。

7，为了使复杂查询尽量本地完成，提前减小数据量和网络传输，加快查询速度，创建分布式表时，尽量按照主键hash分shard。例如欲加快select count(distinct uid) from table_all group by country, os的查询速度. 创建分布式表table_all时，shard key为cityHash64(country, os)，hash函数参考 https://clickhouse.tech/docs/en/sql-reference/functions/hash-functions/ 。

8，计算不同维度组合的指标值时，用with rollup或with cube替代union all子句。

9，建表时，请遵守命名规范：分布式表名 = 本地表名 + 后缀"_all"。 select请直接操作分布式表。

10，官方已经指出Nullable类型几乎总是会拖累性能，因为存储Nullable列时需要创建一个额外的文件来存储NULL的标记，并且Nullable列无法被索引。因此除非极特殊情况，应直接使用字段默认值表示空，或者自行指定一个在业务中无意义的值（例如用-1表示没有商品ID）

11，稀疏索引不同于mysql的B+树，不存在最左的原则，所以在ck查询的时候，where条件中，基数较大的列（即区分度较高的列）在前，基数较小的列（区分度较低的列）在后。

12，多表Join时要满足小表在右的原则，右表关联时被加载到内存中与左表进行比较

13，多维分析, 查询列不宜过多, 过滤条件带上分区筛选 (select dim1, dim2, agg1(xxx), agg2(xxx) from table where xxxx group by dim1, dim2 )

14，禁止SELECT *, 不能拉取原始数据!!!! (clickhouse不是数据仓库, 纯粹是拉原始表数据的查询应该禁止,如 select a, b, c, f, e, country from xxx )

分区键和排序键理论上不能修改，在建表建库的时候尽量考虑清楚 。

0，事实表必须分区，分区粒度根据业务特点决定，不宜过粗或过细。我们当前都是按天分区，按小时、周、月分区也比较常见（系统表中的query_log、trace_log表默认就是按月分区的）。

1，分区键能过滤大量数据，分区键建议使用toYYYYMMDD()按天分区，如果数据量很少，100w左右，建议使用toYYYYMM()按月分区，过多的分区会占用大量的资源，会对集群的稳定性造成很大的影响。

2，分区键必须使用date和datetime字段，避免string类型的分区键

3，每个sql必须要用分区键，否则会导致大量的数据被读取，到了集群的内存限制直接拒绝

4，排序键也是一个非常重要的过滤条件，考虑到ck是OLAP 库，排序键默认也是ck的主键，loap库建议分区键要使用基数比较少的字段，比如country就比timestramp要好。

5，不要使用过长的分区键，主键 。

6，CK的索引非MySQL的B树索引，而是类似Kafka log风格的稀疏索引，故不用考虑最左原则，但是建议基数较大的列（即区分度较高的列）在前，基数较小的列（区分度较低的列）在后。另外，基数特别大的列（如订单ID等）不建议直接用作索引。

分区数过多会导致一些致命的集群问题。 不建议分区数粒度过细，不建议分区数过多 ，经验来看，10亿数据建议1-10个分区差不多了，当然需要参考你的硬件资源如何。

1，select 查询性能降低，分区数过多会导致打开大量文件句柄，影响集群。

2，分区数过多会导致集群重启变慢，zk压力变大，insert变慢等问题。

https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/custom-partitioning-key/

clickhouse数据存储结构

本文基于ClickHouse 20.8.5.45版本编写，操作系统使用的是CentOS 7.5，主要介绍MergeTree表引擎的存储结构以及索引过程。

刚刚创建的表只在数据目录下生成了一个名为 test_merge_tree 文件夹(具体路径为data/default/test_merge_tree)，并没有任何数据，接下来往该表里面插入一条数据，看看会生成哪些文件。

在test_merge_tree目录下使用tree命令可以看到刚刚的那条命令生成了一个名为 200002_1_1_0 的文件夹。

在介绍这些文件之前先介绍一下200002_1_1_0这个目录的命名规则

当分区发生合并时，新的分区目录名称命名规则将会在接下来介绍，这里不做详述。

在介绍这部分之前，需要先将min_compress_block_size配置改小，以方便分析mrk2和bin文件，其默认值为65535。

修改方法为在 users.xml 文件的 profiles 里面增加以下配置

修改完后重启clickhouse-server服务，然后再用以下命令查看是否修改成功

刚刚已经插入了一条数据，但是那一条数据不具有代表性，所以这次决定多插入几条数据再来分析。

上面这条命令产生了个新的分区目录 200002_2_2_0 ，此目录下的文件前面已经讲过，现在重点分析以下几个文件的存储格式

MergeTree表会按照主键字段生成primary.idx，用于加快表查询。前面创建表时使用的是(Id, Name)两个字段作为主键，所以每隔index_granularity行数据就会取(Id, Name)的值作为索引值，由于index_granularity被设置为2，所以每隔两行数据就会生成一个索引。也就是说会使用(3,'Lisa'), (6,'Meimei'), (31,'vincent')作为索引值。

这里我只介绍第一个索引(3,'Lisa')的存储格式，剩下的可以自己去梳理。Id是UInt64类型的，所以使用8字节来存储。从上图可以看出前8个字节为0x03，以小端模式来存储，接下来我们可以看到其它文件都是以小端模式来存储。Name是String类型，属于变长字段，所以会先使用1个字节来描述String的长度，由于Lisa的长度是4，所以第9个字节为0x04，再接下来就是Lisa的ASCII码。

mrk2文件格式比较固定，primary.idx文件中的每个索引在此文件中都有一个对应的Mark，Mark的格式如下图所示：

通过primary.idx中的索引寻找mrk2文件中对应的Mark非常简单，如果要寻找第n(从0开始)个index，则对应的Mark在mrk2文件中的偏移为n*24，从这个偏移处开始读取24 Bytes即可得到相应的Mark。

bin文件由若干个Block组成，由上图可知Id.bin文件中包含两个Block。每个Block主要由头部的Checksum以及若干个Granule组成，Block的格式如下图所示：

每个Block都会包含若干个Granule，具体有多少个Granule是由参数min_compress_block_size控制，每次Block中写完一个Granule的数据时，它会检查当前Block Size是否大于等于min_compress_block_size，如果满足则会把当前Block进行压缩然后写到磁盘中，不满足会继续等待下一个Granule。结合上面的INSERT语句，当插入第一个Granule(3, 4)时，数据的的size为16，由于16 <24所以会等第二个Granule，当插入第二个Granule(6, 12)后数据的size为32，由于32 > 24所以会把(3, 4, 6, 12)压缩放到第一个Block里面。最后面的那个31由于是最后一条数据，就放到第二个Block里面。

partition.dat文件里面存放的是分区表达式的值，该分区表达式生成的值为200002，UInt32类型，转换成16进制就是0x00030d42。

minmax文件里面存放的是该分区里分区字段的最小最大值。分区字段Birthday的类型为Date，其底层由UInt16实现，存的是从1970年1月1号到现在所经过的天数。通过上面的INSERT语句我们可以知道Birthday的最小值为2000-02-03，最大值为2000-02-08。这两个时间转换成天数分别为10990和10995，再转换成16进制就是0x2aee和0x2af3。

属于同一个分区的不同目录，ClickHouse会在分区目录创建后的一段时间自动进行合并，合并之后会生成一个全新的目录，以前老的分区目录不会立马删除，而是在合并后过一段时间再删除。新的分区目录名称遵循以下规则：

所以上面的两个分区目录200002_1_1_0和200002_2_2_0在过一段时间后最终会变成一个新的分区目录200002_1_2_1。由此可见如果你频繁插入数据会产生很多分区目录，在合并的时候会占用很多资源。所以最好一次插入很多条数据，尽量降低插入的频率。

通过上面的介绍相信大家已经对ClickHouse的索引结构有所了解，接下来用一张图简要描述Id字段的索引过程。

其它列的索引过程类似，这里就不一一赘述了，有兴趣的朋友可以自己去研究。

本文通过一个简单的例子来分析ClickHouse的存储结构，整个逻辑力求简洁明了，希望通过本文能够让喜欢ClickHouse的朋友对它的索引有个清晰的认识。

doris是什么意思

一，女生叫doris的意思

女生叫doris的意思是通常代表那种头发是短发类型的。而且相貌或者身材有一点像北欧国家女性的特征，通常取这样名字的女生，会给人一种比较像精灵一样的感觉。这个英文名翻译成汉语的话就是桃瑞斯或者桃丽丝，这个英文名本来是希腊神话里面的人物，他分别是水仙女和海仙女，本来的意思有小礼物的意思。

二，给自己取英文名的方法

给自己取英文名的方法有好多，以下是常见的几种方法，如果实在不知道取什么英文名的话，可以参考圣经上面的一些名字，或者是参考希腊罗马神话里面的一些名字，还有一些文学名著里面的名字也是非常合适的。除此之外也可以按照自己的个人特征，或者是身份或者是职业，来给自己取相应的英文名。可以在取英文名的时候，让英文名和中文名的发音差不多，或者是局部保持差不多就可以，也可以运用意译的方式来翻译一个英文名。

在此之上的内容给大家大致的介绍了女生叫doris的意思，与此同时也与大家简略的介绍了给自己取英文名的方法。

clickhouse之replication配置及使用

Clickhouse支持cluster，支持shard及replication。这里介绍replication。

replication只适用于MergeTree引擎类型table，作用于单个表。而不是整个server。一台server上面可以同时存在replicated表和非replicated表。

1.在多台节点上安装clickhouse-server

2.分别在每台server上面配置zookeeper，默认配置文件位置/etc/clickhouse-server/config.xml，示例如下：

3.在配置文件中配置宏（macro），这里的参数在建表的时候会被引用到。

shard是分片标识，replication模式采用一个分片，不同server分片相同

replica是副本标识，不同副本该值不能相同，可以配置为本机的hostname

4.分别在不同的server上面执行建表语句

这里有几点说明：

-其中{shard}和{replica}的值会被宏中所配置的值代替

-table engins必须使用MergeTree族，并且加上Replicated前缀，如：ReplicatedReplacingMergeTree

-第一个参数'/clickhouse/tables/{shard}/flow'是表在zookeeper上的路径，第二个参数即副本名称

在不同的server建好表以后，就可以往表中写入数据了，可以使用insert方式向replicated表中写入数据，也可以通过clickhouse-client的文件导入方式写入。只需要往其中一台server的replicated表中写数即可，clickhouse会自动将数据同步到其他server上面，同步数据和写入数据的过程是异步的。

-clickhouse的cluster环境中，每台server的地位是等价的，即不存在master-slave之说，是multi-master模式

-各replicated表的宿主server上要在hosts里配置其他replicated表宿主server的ip和hostname的映射

-上面描述的是在不同的server上建立全新的replicated模式的表， 如果在某台server上已经存在一张replicated表，并且表中已经有数据，这时在另外的server上执行完replicated建表语句后，已有数据会自动同步到其他server上面

-如果zookeeper挂掉，replicated表会切换成read-only模式，不再进行数据同步，系统会周期性的尝试与zk重新建立连接

-如果在向一张replicated表insert数据的时候zookeeper挂掉，这时候会抛一个异常，等到与zk重新建立连接以后，系统（其他replicated表所在server）会检查本地文件与预期文件（保存在zk上）的差别，如果是轻微的差别，直接同步覆盖，如果发现有数据块损坏或者识别不了，则将这些数据文件移动到“detached”子目录，然后重新根据zk所记录的文件信息进行副本的同步

-drop掉某一台server上的replicated表，不会对其他server上面的replicated表造成影响

以上就是关于doris和clickhouse,clickhouse使用场景的全部内容，以及doris的相关内容,希望能够帮到您。