Oceanbase数据库的缺点或劣势分析
OceanBase是蚂蚁金服完全自主研发的分布式关系数据库 目标是做一个通用型的分布式数据库。OceanBase的基本特点简单总结就是分布式、弹性扩展、高可用强一致。大部分分布式系统在面临跨节点请求时性能都会有些下降。产品本身会做优化 这个可以忽略。
OceanBase的缺点或劣势
首先，数据库虽然对MySQL绝大部分常用用法是兼容了，但是对Oracle还只是兼容了标准SQL和一些常用函数（包括窗口函数）。当然存储过程、游标、更多的分析函数内部也实现了，还需要一段时间检验。传统Oracle数据库上的那复杂的存储过程和package目前在OceanBase里运行还可能有性能问题。内部业务正在试用过程中。其次，OceanBase的外部用户很少，了解的人很少，相关资料仅限于OceanBase官网和OceanBase论坛，还有微信公众号和群。所以不大容易得到用户信任。这个会有个很长的过程。
第三就是对机器配置要求不低。如至少32C64G（更小也可以搭建集群，但使用不当容易有问题），生产环境建议256G等。生产环境这个配置不算什么，不过个人如果要安装搭一个测试环境，可能不大好搞到机器。OceanBase的资源瘦身我们也在做了，还需要点时间。
上面OceanBase的分布式事务在1.x版本里有个缺陷。当一个SQL读取或者修改多个分区并且这些分区跨节点的时候OceanBase 1.x是不支持的会提示“strong consistency across distributed node not supported”。这是因为还不支持全局一致性快照。这样的SQL隐含要求是如果访问的数据在多个节点这些数据必须是来自于同一个时间点之前含已提交的数据。要实现这个要求需要有一个全局的时钟。Google Spanner是通过硬件原子钟和API实现。实现这个的目前还有TiDB。DRDS和TDSQL只是在server节点将各个db节点返回的数据做聚合处理直接忽略了一致性要求。
OceanBase 2.x版本将会在内部用软件实现一个全局时钟解决全局一致性快照难题。所以硬件层面所有OceanBase机器的时间必须使用同一NTP源。彼此误差不能超过50ms。这点对IDC来说应该是基本要求。
所以这个全局一致性快照只能在数据库内核层面解决。如果是使用分布式数据库中间件的话做这个就不容易了。这点供拆分决策参考。
OceanBase SQL基本兼容MySQL语法部分兼容Oracle SQL语法。目前1.x版本对于函数、游标和存储过程之类都还不支持 2.x版本会逐步支持。
运维视角看OceanBase
OceanBase数据库是一个集群至少需要三台机器。机器数通常是奇数。这个集群不需要共享存储机器之间也不需要网络直连彼此是通过网络访问即可。为了降低跨节点之间的请求延时对性能的影响OceanBase机器也建议用万兆网卡。相应的交换机也要支持万兆。
跟商业数据库不一样的地方是OceanBase并不定义某台机器是主、某台机器是备。所以理论上每台机器都可以提供读写服务。但运维人员是否选择这样做是需要做一个综合考虑即在资源利用率和容灾目标方面做一个权衡。比如说如果每台机器都提供服务CPU和空间利用率都很高， 当有1或者2台主机故障时，剩余的机器可能没有足够的空间和CPU来接纳故障机器的数据和接管故障机器的对外服务，因为新机器CPU资源会紧张。决策的关键点是故障的概率究竟有多大和业务能承受数据库服务多大的损失。
当然，数据库也会更新，升级，力求更好，有些缺点可以弥补。
OceanBase的缺点或劣势
首先，数据库虽然对MySQL绝大部分常用用法是兼容了，但是对Oracle还只是兼容了标准SQL和一些常用函数（包括窗口函数）。当然存储过程、游标、更多的分析函数内部也实现了，还需要一段时间检验。传统Oracle数据库上的那复杂的存储过程和package目前在OceanBase里运行还可能有性能问题。内部业务正在试用过程中。其次，OceanBase的外部用户很少，了解的人很少，相关资料仅限于OceanBase官网和OceanBase论坛，还有微信公众号和群。所以不大容易得到用户信任。这个会有个很长的过程。
第三就是对机器配置要求不低。如至少32C64G（更小也可以搭建集群，但使用不当容易有问题），生产环境建议256G等。生产环境这个配置不算什么，不过个人如果要安装搭一个测试环境，可能不大好搞到机器。OceanBase的资源瘦身我们也在做了，还需要点时间。
上面OceanBase的分布式事务在1.x版本里有个缺陷。当一个SQL读取或者修改多个分区并且这些分区跨节点的时候OceanBase 1.x是不支持的会提示“strong consistency across distributed node not supported”。这是因为还不支持全局一致性快照。这样的SQL隐含要求是如果访问的数据在多个节点这些数据必须是来自于同一个时间点之前含已提交的数据。要实现这个要求需要有一个全局的时钟。Google Spanner是通过硬件原子钟和API实现。实现这个的目前还有TiDB。DRDS和TDSQL只是在server节点将各个db节点返回的数据做聚合处理直接忽略了一致性要求。
OceanBase 2.x版本将会在内部用软件实现一个全局时钟解决全局一致性快照难题。所以硬件层面所有OceanBase机器的时间必须使用同一NTP源。彼此误差不能超过50ms。这点对IDC来说应该是基本要求。
所以这个全局一致性快照只能在数据库内核层面解决。如果是使用分布式数据库中间件的话做这个就不容易了。这点供拆分决策参考。
OceanBase SQL基本兼容MySQL语法部分兼容Oracle SQL语法。目前1.x版本对于函数、游标和存储过程之类都还不支持 2.x版本会逐步支持。
运维视角看OceanBase
OceanBase数据库是一个集群至少需要三台机器。机器数通常是奇数。这个集群不需要共享存储机器之间也不需要网络直连彼此是通过网络访问即可。为了降低跨节点之间的请求延时对性能的影响OceanBase机器也建议用万兆网卡。相应的交换机也要支持万兆。
跟商业数据库不一样的地方是OceanBase并不定义某台机器是主、某台机器是备。所以理论上每台机器都可以提供读写服务。但运维人员是否选择这样做是需要做一个综合考虑即在资源利用率和容灾目标方面做一个权衡。比如说如果每台机器都提供服务CPU和空间利用率都很高， 当有1或者2台主机故障时，剩余的机器可能没有足够的空间和CPU来接纳故障机器的数据和接管故障机器的对外服务，因为新机器CPU资源会紧张。决策的关键点是故障的概率究竟有多大和业务能承受数据库服务多大的损失。
当然，数据库也会更新，升级，力求更好，有些缺点可以弥补。
无相关信息
*您觉得此文有阅读和收藏价值吗？电脑上网的请在键盘上按Ctrl+D加入收藏~；手机上网可加入书签~
