clickhouse特性以及适用场景
适用场景
大量数据写入和查询，但是修改比较少。对事务不敏感。偶尔数据丢失不敏感。
很多物联网类的应用场景都是如此。
- 统计城市的气温，一个城市一千个监测点，一分钟统计一次，一千个城市每分钟产生一百万数据，一天就是十四亿条数据。
- 统计物流车辆位置信息
- 统计用户网络行为
这些都有着明显的特点，数据量大，大量重复的数据，数据不会修改，对事务不敏感，并发低。这与传统的应用场景区别很大。大部分互联网场景是，并发高，事务级别高，大量的更新，但是每次查询关联的数据少。
为了解决新的问题，出现了一种新的数据库：时序数据库。数据是按照时间维度不断增加的，数据量大，对大量的数据进行统计计算。
特性
clickhouse就是这样一种数据库，官方介绍是用于联机分析(OLAP)的列式数据库管理系统(DBMS)
- 绝大多数是读请求
- 数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。
- 已添加到数据库的数据不能修改。
- 对于读取，从数据库中提取相当多的行，但只提取列的一小部分。
- 宽表，即每个表包含着大量的列
- 查询相对较少(通常每台服务器每秒查询数百次或更少)
- 对于简单查询，允许延迟大约50毫秒
- 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)
- 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
- 事务不是必须的
- 对数据一致性要求低
- 每个查询有一个大表。除了他以外，其他的都很小。
- 查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中
clickhouse也是列式数据库，数据是按照每个字段一列列的存储的。常见的数据库是按照每一行数据一行行存储的，这个与我们正常思维一致，也可以实现比较好的表之间的关联。
列式存储的好处就是，对于一列的数据，可以进行很好的压缩。因为同一列的数据都是同一种类型，尤其是那些用来表示状态的字段，大部分都是0 1 2等数字，clickhouse就可以对齐压缩。其次在查询时也不必搜索所有的字段只需要遍历需要的字段，性能更高。弱化了事务、修改和表之间的关联能力，大大提高了性能。
经过简单测试7GB大小，4千万条数据，不管是count(*)，还是根据某些字段聚合统计排序都可以在秒内完成，并且存入数据库后只占用300M左右的空间。
发现的一个问题是数据库长时间没用，或者某些语句第一次查询，可能数据需要预热，用时在5s左右。
