clickhouse
特点
1 列式存储
分析型 聚合性能好
压缩比高 因为同一列的数据类型一样
同样数据占空间小 磁盘和缓存使用率高
2 DBMS
管理能力好 支持标准的SQL 开窗函数不支持
3 多样化引擎
最常见
4 高吞吐写
顺序写入 到临时分区中 在后台进行异步合并
5 并发查询
利用多线程 并发查询多个分区
问题 单条利用多个线程 不适合多条sql并发执行 qps不高 低频高复杂度大数据量的查询
6 更适合单表操作 ，多表join性能一般
数据类型 (使用时大小写敏感)
Long Int64 UInt64 带U的没有负值
Integer Int32 UInt32 带U的没有负值
decimal Decimal32(s) Decimal64(s) Decimal128(s) |Decimal(7,2) Decimal(16,2) Decimal(36,2) 汇率 日利率
varchar String
date Date DateTime DateTime64
表引擎
TinyLog 小文件
Memory 内存
MergeTree (最重要)
支持分区 （单机 按目录物理分区） 缩小数据范围 where 加入分区条件
primary key 只是一个一级索引 不是唯一主键 (where 中进行筛选用的)
order by 必填项 影响你的存储顺序 primarykey必须是order by的前缀
二级索引 （实验性） where 条件中使用
TTL 数据的时效性
遇到达到失效时间 不是立即生效 随着MergeTree 后台合并来进行时效 建议使用天级及以上 失效周期的字段建议使用分区字段
查询执行计划
clickhouse-client --send_logs_level=trace <<< 'select * from test1.t_order_mt where total_amount > toDecimal32(900., 2)'
手动触发合并操作
optimize table xxxx final
- ReplacingMergeTree
去重 以order by 字段 为准 维度列 ， ReplacingMergeTree(版本列)，版本列最大的保留 ， 版本列相同留最新的
- SummingMergeTree
汇总统计 以order by 字段 为准 维度列 , SummingMergeTree(聚合列)， 除了维度列和聚合列， 留最老的
共同问题： 1. 范围有限 分区内字段聚合和去重
2. 时效有延迟 必须触发分区合并 才进行聚合和去重
3. 手动触发 optimize table xxxx final
副本
ReplacatedMergeTree(zk_path,rep_name)
ReplacatedReplacingMergeTree(zk_path,rep_name,版本列)
ReplacatedSummingMergeTree(zk_path,rep_name,聚合列)
基于zk ，利用zk观察里面的日志，来获得别的副本的最新数据
配置： metrika.xml 配置zookeeper的地址就行了
两个互为副本的表
zk_path 必须一致 /clickhouse/tables/{shard}/table_name
rep_name 必须不一致
集群
本地表 存储真正数据
分布式表 代理工作 不存储数据
metrika.xml 配置一个集群
internal_replication true 自己管理副本 集群不管 得用复制的本地表 官方推荐 false交给集群管理 普通表就可以
distribute 表 分发读请求 到所有的shard中 ，如果shard有多副本 选error_count最小 如果error_count相同 默认随机 也可以改成顺序
distribute 表 分发写请求 根据分区键 取模 发到不同的shard中
写入到
sparkstreaming 写入clickhouse 使用 写入通用jdbc方法 地址不同 driver不同而已