谈谈个人对分布式数据库选型的理解吧。我觉得使用分布式数据库的根本原因就两点。
一是高可用,数据分片后不容易出现全局故障,即便有单点故障,顶多影响部分数据和业务。另一个是性能扩展,因为单点性能容量有限,面对互联网交易,手机交易的大并发访问,单点数据库可能会遇到性能问题。
然而对于金融行业来说,为了这两点选择的分布式数据库,还得具备单数据库的基本功能,例如pitr,分布式事务,读写一致性等。而这些基本功能,众多分布式数据库基本都是通过设置全局事务号来搞定的。如果是基于客户端的分布式数据库,其实是做不到这一点的。所以基于客户端的分布式数据库只能应用在有限的场景下,需要应用开发支持才行。而也正因为如此,基于客户端的分布式性能是最好的,基本没有损耗。
客户端模式局限多不适合,那么就要考虑这些国产的分布式数据库产品了,我想把这些归为中间件式的分布式数据库。例如华为高斯,阿里ob,antdb,巨杉,tidb等等。这些数据库功能最齐全,支持强一致性的话都设置了全局控制组件,例如gtm,全局事务管理器,然后一大堆的数据节点,加上提供链接的协调节点。几乎所有这些分布式产品都是这么干的。也有些另类的例如基于分布式一致性协议,但是性能和整体功能兼容性都会差很多。
我们测了很多分布式数据库产品,结果在这里暂时不能透露,只说说我们测试会关注的点。一是高可用,关注每个组件故障回复时间,尤其是全局影响时间。还有就是单点事务性能和分布式的跨节点事务性能,读写强一致性。这个方面数据库差异特别大,因为有全局组件的原因,分布式数据库处理能力最终上限也会出现在这里,不可能无限扩展的,这与我们需要的性能扩展是相悖的,有些产品甚至还不如单机性能好。最后是混合型场景htap。因为任谁也不能保证自家的应用就是oltp没点复杂查询什么的,因此复杂查询的支持也需要验证。我想大家在测试的时候把这几点测到,基本上就有答案了。
分布式数据库属于新产品,尤其是集群类型的,虽然测好了单点故障,但是全局故障会不会有问题谁也说不好。因此pitr必须得有,额外保护也得考虑。建议将数据想办法同步一份到集群外面来,以防万一。
最后说说迁移。几乎所有的分布式数据库在做产品的时候都会考虑兼容性,但是事实上都做不到百分百的兼容。因此工作量还是有的,既然选择了,就不用太考虑工作量。平时也是做好对数据库告警功能或者特色功能使用的控制,尽量只使用数据库的基本功能,不要写一堆存储过程什么的,减少对数据库产品的依赖性。