几个数据库方向的发展思路

这是学习笔记的第2082篇文章

最近在做一些规划和调整，也结合了行业里的一些情况，把这些信息整理了下，算是一个粗略的思路和参考。

技术选型

首先技术选型方面，也是需要与时俱进，至少目前的选型应该是在5.7的新版本，MGR推出有些年了，方案的成熟度和稳定性已经有了较大的提升，我们内部已经对运维系统和任务系统做了跨机房的双活方案，已经运行了半年，下半年准备引入一些业务场景。

而8.0版本目前对于很多应用来说，变动比较大，原本的客户端，驱动模式都有兼容问题，新版本的功能方面个人更加看好克隆插件。

同时对于数据库方向，除了InnoDB在其他方向上也需要做到取舍，比如TokuDB，在Percona这些年一直是最小化运营，而在8月开始已经要正式退出了。所以一方面把InnoDB这块做做好做深，另一方面选型时也要考虑在一个较长的周期内没有其他的风险，在这方面MyRocks就是一个很不错的补充。

在OLAP方向选型，Infobright引擎有着性能的优势，但是在功能支持上还是存在欠缺，在这方面可以考虑ClickHouse来作为后备补充。

在NewSQL方向上的选型，CockroachDB近期也变更了协议，这块对于开源社区的使用来说还是有一些变动的因素，个人更推崇TiDB.

不可忽略回收站功能

AliSQL最近推出了新的功能，可以参考：

而我们最近在运维中也出现了一些运维故障，这些故障的表面现象都是不合理的删除和清理操作导致不可逆。而深层次的原因之一就是权限的管理较为松散，在这方面Oracle的回收站是一个很好的功能，AliSQL的设计思路也很精巧，对很多细节的处理做了补充，我们在设计数据生命周期管理的时候，也融入了回收站的功能，也是尽可能希望把drop操作通过一种可逆的方式进行统筹管理。drop操作本身是合理的，但是可控可逆的drop操作应该是值得提倡的。

高可用

在高可用管理方面，在行业内也存在大量的解决方案，而从MySQL的发展来看，目前最简洁的方案应该是基于MGR的方案，MGR可以结合Consul,VIP等方案实现一套较为完整的高可用解决方案。

另外Orchestrator方案也不容小视，最近也在做一些补充测试，从我调研的测试情况来看，对于拓扑图的生成算是一个亮点但不核心的功能，我觉得相比MHA来说，Orchestrator的方案更加友好，同时能够提供更全面的定制化功能，基于go语言的开发使得后期的改进也会更加容易接入。

分布式ID

最近在设计分布式方案的时候，其中分布式ID就是重中之重。目前调研了滴滴的tinyid和美团的leaf,目前来看，美团的leaf功能较为完善，支持segment和snowflake模式，而且通过ab测试的时候，单机的性能还是不错的，如果接入集群的方式，能够让整个ID服务的吞吐率有较大的提升。

而对于ID方案的设计，需要进一步考虑结合场景来进行细化和补充，能够让ID服务更加稳定可靠，是需要进一步提升和着手的地方。

机房多活

最近测试了Otter的方案，对于跨机房的数据多活的支持还是不错的，从使用的方式上，其实和OGG还是很相似的，Otter的方案是典型的技术视角来设计的，OGG是作为较为成熟的产品视角来做的。

双向复制中的难点就是数据延迟和数据冲突机制的检测处理，在这方面，自己也着手在看行业内的一些好的方案，比如基于binlog的方案，基于TiDB的方案是一种思路，基于MySQL Ripple的开源方案也是一个很好的补充。

如果考虑更多是数据冲突机制的处理策略，那么势必对于分布式ID，冲突机制的异常处理就是设计的重心和难点了。