分布式数据库处于发展期,还未达到成熟期,使用过程中遇到的各类问题较多,需要及时修复,但是现在普片数据库厂商版本迭代太快,对厂商来说可以更好及时修复问题,进行功能优化。但是没有考虑到用户的实际情况,如果升级频繁可能对原有系统带来风险和问题,现在市场上OB、TDSQL、TIDB等等分布式数据库都有这个问题,而且维护人员还需要重新进行一次熟悉和安全检测。用户如果自己选择时间进行升级,跨多版本进行升级,跨度太大,这样对各个版本前后兼容问题会带来很大风险,而且有的还必须让厂商来做,这里边还会涉及行内配合费用,厂商的人天也很贵的,对用户来说是升级也不是,不升级也不是的困境。
针对眼下分布式数据库版本的迭代频率,大家如何考虑?对大家来说真的好吗?大家在分布式数据库版本迭代上是如何处理的,如何应对版本频繁升级?希望大家在投票后可以谈谈自己企业的应对经验!
一个产品的生命周期包括初创期、建设期、稳定期、消亡期。在前两个周期存在频繁迭代是正常的,稳定期应当固定的、较长周期的迭代。
数据库是应用系统的重中之重,频繁迭代必然带来风险。我们需要反思2点:
1、从数据用户侧产品选型:是否考虑了产品发展周期?是否很好地平衡“为满足业务需求不得不采用某个产品”和“该产品频繁迭代带来的问题”?在系统变更、数据完整等方面做了哪些设计来应对风险和运维压力?
2、从产品研发侧迭代策略:当前产品所处阶段和快速迭代是否匹配?新功能、新Bugfix是否解决了用户的痛点(是否价值大)?
作为系统架构师,需要做好权衡和应对。
收起好不好是相对的,不是绝对的,对于数据库厂商来讲为了快速变现,所以将一个基本能用的数据库上线;但是数据库到各个项目之后,各个项目的特性问题会直接暴露数据库的问题,这样就需要数据库厂商一直修改bug,导致 频繁升级 ,所以 频繁升级 对于数据库厂商为好事,它在完善;
但是各个客户这边用了一版数据库之后,如果出问题了,肯定不能等 升级的,一般都通过特殊处理绕过去问题的形式解决,时间久了就都不记得当时做的特殊处理了 ,这样再 升级数据库会出现很多的问题 ;
还有数据库最重要的就是稳定性, 一次升级就会存在诸多潜在问题,更别说 频繁升级 了,
我们的解决策略是:只做大版本升级,减少升级次数。
厂商经常会做一些打补丁、优化的操作,大部分都是小版本更新,那么除非对业务或应用影响大的情况会单独升级,否则我们会把所有小版本更新集中到一个包里,一次性做个较大版本的升级,以减少次数。
现在分布式数据库更新的版本多又快,主要还是因为问题相对比较多,解决一些已知bug,但是为了解决bug频繁进行升级和迭代,这样会带来很大的变更风险和工作量,这样带来的收益反而降低,如果不是极大影响数据库,不建议频繁升级,十次事故九次变,减少变更,等版本稳定可以统一升级到一个稳定版本。
收起现在国产数据库还处于成长阶段,快速迭代是应对需求的正反馈。
以前总是抱怨国外产品不理会客户需求,现在国产数据库对需求的反馈很积极,充分说明了国产的必要性。
当然,国产数据库的版本管理比较混乱,没有清晰的产品路线图,客户需求管理不规范,需要加倍努力。