认识达内从这里开始

对于大多数软件编程开发行业来说，能够掌握不同的编程技术对于程序员还是非常重要的，能够满足更多的编程需求，而本文我们就通过案例分析来简单了解一下，数据库架构技术选型分享。

1.成熟度。

一款数据库成熟度怎么样可以从历史版本发布情况来简单分析，如果频繁的大版本发布及小版本修复各种致命bug、缺陷等，显然不能被一般外部用户接受。以MySQL为例，2005年MySQL5.0发布到今天MySQL8.0成熟经历了17年，其中MySQL8.0从2016年发布到今天一个版本的稳定打磨就经历了7年!数据库注定是要十年磨一剑的。

2.标杆应用。

在业内是否被大规模验证过了，或者有标志性的成功案例。很多国产数据库目前整体还是闭塞的虽然号称在金融、电信、银行、保险等领域上线了，但实际情况怎么样完全不得而知，尤其互联网公司崇尚的是开源这一类的数据库很难被接受。

3.技术底蕴&靠山

所谓大厂出品必属精品，随便一个什么公司搞一个数据库是很难被接受的。大家普遍认可业内顶尖的一流公司做背书的产品，甚至在深入了解一下开发这款数据库的团队靠谱吗?毕竟数据库的复杂度堪比操作系统，要求非常高，甚至团队规模怎么样，不要指望百十人的团队能写出靠谱的数据库(KPI产品例外)。当然中间件方案的分布式例外，毕竟核心是做Proxy，复杂度远不在一个数量级上。

4.生态。

生态主要看技术、人才、文档、服务这四方面。

技术方面，业务接入的改造是否低成本，或者说是否能复用成熟的生态(比如TiDB和OceanBase都是完整支持MySQL协议的)，是否足够开放让社区或者相关从业人员尽可能参与进来?比如TiDB这方面做的就很好。周边生态工具是否齐全，比如业务研发高频使用的IDE工具，DBA更加关心的一些技术接口或者现成的实用运维工具等。

人才方面，市场是否有足够数量的从业人员如DBA。

文档方面，此前国产数据库整体上文档完整性比较弱，现在好很多了，不过整体文档水平跟MySQL这样的开文档比还有差距，很明显的感受是：告诉你怎么用，很少告诉你为什么或者原理性的东西比较少，可能是写文档的同学不是内核研发。

服务方面，国产数据库的诞生有现实的需求，但整体相比传统商业数据库成熟度还不够，因此需要更好的售后服务及支撑体系才能弥补整体的不足。分布式数据库未来上云是个大方向，毕竟对绝大部公司而言是很难有人力跟能力去驾驭一个复杂的、成熟度有待打磨的产品。

5.ROI

主要看引入分布式要解决什么问题，如果是成本，很不幸小范围引入分布式数据库可能成本会更高!毕竟相比单机数据库，分布式数据库普遍对硬件成本要求非常高，比如TiDB和OceanBase都有很高的硬件要求(OceanBase4.0小型化后改观很多)。如果是性能优化那更不幸，通常benchmark可能跑不过单机数据库!分布式数据库的整体收益只能在达到一定规模后才能发挥出成本、性能优势。因此，如果只是某个单一场景引入分布式来解决可能不是太好的选择。据说携程是做了大规模MySQ/Oracle升级OceanBase，相信他们应该有相关的数据可供参考。

关于ROI可以简单的比喻：分布式是卡车，拉的多跑的慢，单机数据库是轿车拉的少跑的快，因此要有个平衡。后引用一句话:“过早的优化是万恶之源”。

6.兼容性验证

虽然很多数据库都号称兼容MySQL等协议，但还是要以自己的实际验证结果为准(99.99%的兼容跟的兼容对结果的影响是巨大的)。起码你要有SQL流量回放能力来验证执行计划跟执行效率的差异吧。此外，对于能否平滑迁移，成熟的产品往往有一套完整的解决方案，要考虑上线后你真的能驾驭它吗。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。