首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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

这是学习笔记的第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,冲突机制的异常处理就是设计的重心和难点了。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190827A0059900?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券