分布式数据库版本迭代快，对用户来说是真的好吗？
分布式数据库处于发展期，还未达到成熟期，使用过程中遇到的各类问题较多，需要及时修复，但是现在普片数据库厂商版本迭代太快，对厂商来说可以更好及时修复问题，进行功能优化。但是没有考虑到用户的实际情况，如果升级频繁可能对原有系统带来风险和问题，现在市场上OB、TDSQL、TIDB等等分布式数据库都有这个问题，而且维护人员还需要重新进行一次熟悉和安全检测。用户如果自己选择时间进行升级，跨多版本进行升级，跨度太大，这样对各个版本前后兼容问题会带来很大风险，而且有的还必须让厂商来做，这里边还会涉及行内配合费用，厂商的人天也很贵的，对用户来说是升级也不是，不升级也不是的困境。
针对眼下分布式数据库版本的迭代频率，大家如何考虑？对大家来说真的好吗？大家在分布式数据库版本迭代上是如何处理的，如何应对版本频繁升级？希望大家在投票后可以谈谈自己企业的应对经验！
投票选项【单选】
-
分布式数据库版本迭代快：是好事，可以及时修复问题和优化！0%
-
分布式数据库版本迭代快：不好，频繁升级带来兼容风险、运维压力等等！0%
各方声音(3)
分布式数据库上面往往放了多个业务的数据库，如果升级需要停机，那对于升级窗口很少的用户来说是个大问题。期待厂商能做到对用户无感知。
收起一个产品的生命周期包括初创期、建设期、稳定期、消亡期。在前两个周期存在频繁迭代是正常的，稳定期应当固定的、较长周期的迭代。
数据库是应用系统的重中之重，频繁迭代必然带来风险。我们需要反思2点：
1、从数据用户侧产品选型：是否考虑了产品发展周期？是否很好地平衡“为满足业务需求不得不采用某个产品”和“该产品频繁迭代带来的问题”？在系统变更、数据完整等方面做了哪些设计来应对风险和运维压力？
2、从产品研发侧迭代策略：当前产品所处阶段和快速迭代是否匹配？新功能、新Bugfix是否解决了用户的痛点（是否价值大）？
作为系统架构师，需要做好权衡和应对。
收起
版本迭代升级需要大量的回归性测试工作，会引起业务停机时间变长及增加相关人员工作内容及协调难度。整体的运维成本其实是挺高的，应定期评估软件bug影响程度，对于重大的bug要及时升级 ，对于有其他变通做法的bug 不做升级，让应用开发商尽可能修改。每年做一次升级评估，定期升级 ，保持数据库版本在行业主流版本的范围内。
收起