数据库种类越来越多WHY VS CLICKHOUE 是MYSQL的救命稻草?
数据库的种类越来越多不知道大家近有没有这样的体会，时序性的数据库，列式数据库，OLAP类型的数据库等等， 数据库从概念上慢慢已经超越了之前的一些思维模式的限定。
产生这样的原因有几点（纯属个人臆想）
1 业务的场景的丰富，业务场景的丰富来自于需求，需求的多变导致使用数据库的场景的多种多样。
2 程序人员的“懒”， 这里没有贬低的意思，而是一种数据库发展的方向，我们都知道，随着业务的复杂性和数据量的变化，以及处理的特定性，需要处理数据的方式方法如果都依赖于程序员来完成，那就比较恐怖了。
1 程序员大部分属于逻辑代码的编写者，实际上一大群的程序员都属于需要懂得业务逻辑的，“码砖”， 他们根本就不懂如何来设计表，或者怎么使用对的数据库，思维模式停留在怎么把数据塞进去和怎么读出来的这个水平。
2 程序员的精力应该花在哪里，实际上程序员中只有少部分人在进行架构的分析和相关程序架构的设计，大部分的程序员的精力都在于怎么尽快的将业务逻辑实现这个工作。
一句话，业务为先, 大部分单位是不会有时间给程序员培养的时间，在说白一点，钱就是命，先把程序上线，不管有多烂，后面等受不了了在修补，重构，重构，重构，没完没了的重构。
3 系统有一部分运行出现故障的原因在于数据库的性能因素造成的，使用了不称手的“数据库” 导致业务的性能在后期数据量大了，出现各种各样的问题。
这些就是现在新型数据库层出不穷的原因之一， 通过数据库特定的方式将业务程序难搞的地方，让数据库本身的特性来解决，这是新型数据库层出不穷的支持的动力。
的程序人员，可能会理解，如果你要处理一个问题，有10个考虑，8个注意，7个小心，那你编写的这个程序要考虑的地方太多，终究的有“失策”的地方。 数据库本身也是，如果单体的数据库的功能越多，后面需要解决的问题就越多，而产生的问题的可能性就越多，并且也很难进行 scale up scale in scale out ， 这也是在大型数据存储中，ORALCE 必然是一个淘汰产品结局。
用另一句话来解释就是，以结构化的思维将单个复杂的问题化为多个简单的问题。所以复杂的数据库化繁为简处理的问题多种多样，就造就了多种类型的数据库产品。
我们回到题目的另一个问题， MYSQL VS CLICKHOUSE， 这是什么意思
，取长补多合作的关系。
MYSQL 本身在聚合和多表联合运算上的缺陷需要找一个志同道合的“同学”，来一起狼狈为奸。
方案1 通过目前CLICKHOUSE 新版本中的直接支持的作为MYSQL从库的方法，将clickhouse 伪装成一个 mysql的从节点，通过准实时同步数据（异步）的方式将数据同步到clickhouse。通过这样的方式来解决mysql 本身OLAP的无能，以及应用程序需要进行 大表count(*) 操作， group by , order by 等操作以及多表的join 符合查询操作。
这里有几个注意的点
1 建议使用 MaterializeMYSQL 的数据库引擎在CLICKHOUSE 作为主要的工作引擎。
2 如果此设计和业务强相连，则建议通过某些监控方式来监控节点之间的同步状态，以及数据同步的状态。
使用MaterializeMYSQL的主要的原因是通过内部的数据解析和回写的方式隐去了第三方的插件的所造成的数据传输的损耗（时间）。通过将MYSQL的binlog event 转换成BLOCK，存入CLICKHOUSE 的数据存储底层。版本为V20.9.1 及以上的版本。
同时clickhouse也支持断点续传的于MYSQL 本身的从节点的主从的方式没有什么太大的区别。（不是原理，只是看上去类似）
这里其实存在一个商机，如果这样的方案中的一个问题是当主从切换后，clickhouse 应该如何与新主进行挂接，可以不关心新的MYSQL的节点的BINLOG 和 POS ，因为我们可以通过CLICKHOUSE 支持GTID 的方式来保证与新的主节点可以继续进行同步数据，但如何切换自动进行连接的修改，这是一个可以切入的地方， 可以通过两者进行一个产品，作为一个方案，来支持大批使用MYSQL的单位，让他们继续安心的使用MYSQL 而不是更换为其他的数据库。
方案2
这个方案有点大了，就是直接使用CLICKHOUSE的集群模式，将所有的MYSQL的数据库都同步到CLICKHOUSE 的集群中。
通过clickhouse 本身的集群，将数据汇聚到 clickhouse，将分析和一些MYSQL 本身难以实现的语句在这里实现，并且成为公司基于MYSQL的大数据分析的平台进行整合。
所以一个产品和人是一样的，不思进取是要被淘汰掉的， MYSQL 本身b+tree的存储方式可以说成也MYSQL 败也MYSQL 。
相关文章