clickhousebook
clickhousebook copied to clipboard
ClickHouse原理解析与应用实践
作者你好,我在你写的纸质书上看到介绍,MergeTree在每个partition下面的,每一列数据用下面三个文件来存储: [Column].bin [Column].mrk [Column].mrk2 但我下载clickhouse来研究,在数据目录的partition下面并没有看到针对每个字段建立单独的文件来存储,而是一个通用的: data.bin data.mrk3 来存储,请问这是为什么呢? 我测试的clickhouse是当前docker上面的latest版本。 
书中这样介绍: 如果存在交集,且MarkRange步长**大于**8(end-start),则将此区间进一步拆分成8个子区间(由merge_tree_coarse_index_granularity指定,默认值为8),并重复此规则,继续做递归交集判断。 但是根据 图6-12,正确的描述应该是 如果存在交集,且MarkRange步长**大于或者等于**8(end-start),则将此区间进一步拆分成8个子区间(由merge_tree_coarse_index_granularity指定,默认值为8),并重复此规则,继续做递归交集判断。
勘误以及建议
**1.建议**(P184-185):针对ALL以及ANY相关join,给出的测试数据表存在问题,join_tab1与join_tab2通过id关联不存在2表中可以找到多条匹配数据,故无法区分all以及any怎么返回匹配的全部/第一条数据,建议调整join_tab2的数据 **2.错误**(P189):9.5.3中join_tab1join_tab2、join_tab3关联结果出现a.name = ClickHouse b.rate=105的数据,该数据在测试数据表join_tab2中不存在 **3.错误**(P232):10.4.2第三段文字中// 1分片,2副本...是使用的10.2.3的多副本示例,但是在P214 10.2.3的示例为1分片,1副本...还望确认下 **4.争议**:在P230处案例为2分片 0副本的sharding_sample集群,对应的每个shard配置中只有一个replica,同样N分片N副本的案例为1分片1副本,每个shard内部两个replica,而在官网的Distributed介绍案例[Getting Started -> Tutorial]中和书中含义不同,案例为3分片,每分片1副本的集群perftest_1shards_3replicas中每个shard下只有一个replica,故到底一个shard下一个replica是表示1分片一副本还是书中的1分片0副本??? https://imgtu.com/i/5sglRg https://imgtu.com/i/5sg8Mj
P110中,`图6-18`中举例说明了.mrk中的文件内容,其中压缩文件中的偏移量示例中为`0和12016`。 在后续P112中,说明了`12016=12000+8+8`,其中8为头信息压缩后的大小。 不过我在此有个疑问,**第二个8指的是什么大小**。 书中提及定位方式可参考`图6-19`,不过`图6-19`似乎含义是,`12016=12000+8+8`的第二个8似乎是第二个压缩块的头信息? 但这样的话,第一个偏移量`0`又没有包含第一个数据块的头信息。 > 即如果`12016=12000+8+8`中第二个8的含义是第二个压缩块的头信息,那么`图6-18`中偏移量示例应该为`8和12016`? 后来我参考官方示例,导入了同样的文件,可以看到书中示例数据均为真实数据。 执行下述语句 ```shell od -l -j 0 -N 480 --width=24 JavaEnable.mrk2 ``` 并且发现了下面数据:`0,12016,26693`。 再执行 ```shell clickhouse-compressor --stat < ./JavaEnable.bin ``` 可以得到所有数据块压缩后的大小,其中前三个为`12000,14661,4936`。 经过简单计算,可得:`26693=12016+14661+8+8`。似乎也有一个8的多余。(毕竟截止第三个数据块开始只有3个,但实际计算中包含了4个8。) 同时对`clickhouse-compressor...
ASOF SQL示例: SELECT a.id, a.name, b.rate, a.time, b.time FROM join_tb1 AS a ASOF INNER JOIN join_tb2 AS b ON a.id = b.id AND a.time = b.time 该SQL 执行失败:(SQL工具 DBeaver) SQL...
尊敬的作者: 您好! 读了《ClickHouse原理解析与应用实践》这本书后,对ClickHouse有了进一步的认识,非常感谢! 在阅读过程中我发现了一个错误,向您反馈下,根据184页的原数据表,我们可以发现第186页的INNER JOIN的结果是错的,多了下面rate=105那一行结果,P188,P189的表格中也有类似的错误。  P184部分截图  P186部分截图
书中截图字段  官网截图 
我看到文章中有讲ReplacingMergeTree怎么进行Merge操作,和Distributed表用的MergeTree引擎怎么进行写操作的复制,但好像没有讲该表是如何进行合并操作呢?也是由接收的主副本进行分发?
99页
原文:而数据文件也会依照index_granularity的间隔粒度生成压缩数据块。 压缩数据块不是得严格按照64k-1m划分吗