- 人阅读
- 2021-04-20 10:18:00
- 相关关键词
科技云报道原创。
面对互联网业务的不断深化以及业务量的爆发式增长，传统数据库架构迎来了前所未有的挑战和变革。在传统数据库领域，Oracle一直占据了很大的市场份额，很多企业的业务系统基于此实现OLTP交易场景。近年来，随着分布式技术的发展，分布式数据库逐渐占据了OLTP领域较大的市场，尤其在互联网领域，MYSQL、PG等分布式数据库的应用非常广泛。在中国，软件国产化、自主可控战略的提出，“去Oracle”逐渐被提上日程，非互联网企业也开始考虑数据库转型。其中，分布式数据库即是一个重要转型方向。然而，分布式数据库应该如何在企业中正确地落地，一直是业界讨论的焦点，首当其冲的问题就是：分布式数据库是否能替换Oracle？在回答这个问题之前，先来看看分布式数据库的发展历程和特点。20世纪80年代，伴随着关系数据库理论的诞生，IBM和Oracle两家公司开始提供商业化的数据库产品，服务于各类大型企业。初期的数据库都是单机软件，跑在专有的硬件之上，比如IBM的大机、小型机，如果业务量或者数据量增加，只能进行垂直扩展，即采用增加CPU、存储的方式。这套体系的优点是非常稳定，缺点是开放性不够，与通用x86服务器体系之上的开发环境兼容性差，另外当业务量增长过快时，其扩展能力有限，而且这套系统的造价非常昂贵。2000年以后，随着互联网在线业务的发展，业务系统访问的并发度呈指数级上升，海量数据计算和分析需求越来越普遍，传统单机系统在业务支撑、成本、开放性等方面均面临巨大挑战，数据库垂直扩展的模式也无法维系。以支付业务为例，随着在线购物、在线缴费方式的普及，支付业务系统的并发量迅速增长，尤其是在“双十一”“618”“春节抢红包”等场景下，每秒有上百万笔支付交易。互联网企业开始探索新的水平扩展的方案，最常见的就是应用系统通过分库分表进行解决。但是，这种解决方案的应用系统需要做大量改造，需要感知数据存储位置，增加了运维的复杂性，并因此出现了中间件的方式，如Mycat等。这种方式虽实现了数据对应用的透明，但未解决数据库运维的痛点。随着大数据技术的发展，以Hadoop、Greenplum为代表的非结构化大规模数据处理技术崛起。这些技术主要采用Shared-nothing架构，在分析领域率先实现了分布式的扩展，分析的主要任务是数据的查询，其应对的挑战主要是海量数据的存储、计算，对于事务的要求较低。2010年后，谷歌Spanner、Tidb采用Paxos或Raft等一致性协议来解决中间件方案的单点瓶颈问题，这为事务数据库的分布式化提供了新的理论依据。之后，分布式数据库发展迎来了热潮，各类分布式数据库百花齐放。相比于传统的单机或主备模式的集中式数据库，分布式数据库是传统数据库技术与计算机网络的有机结合，在平滑扩展、高性能、高可靠、高可用、低成本等方面具有优势，特别是当数据量上升到一定程度，在性能方面可突破集中式数据库的瓶颈。回顾过去10年，分布式数据库经历了从行业质疑、小规模试水、到如今在金融、互联网等行业的探索和应用，有一些甚至在生产系统中得到大量应用，可以说分布式数据库的春天已经到来。那么，分布式数据库足以替代Oracle这样的传统数据库了吗？传统关系型数据库在核心交易等领域深耕了40多年，到目前为止，大部分纯交易场景不论从数据量还是商业模式都没有本质的变化，其业务的扩展空间的确十分有限。在企业数字化转型的过程中，数据量随着业务发展快速膨胀，为数据库带来全新的市场机遇。而分布式数据库的设计初衷，正是为了解决全新的数字化业务问题。在Oracle所无法满足的场景中，分布式数据库成为了理想的落地方案。但值得注意的是，在替代Oracle的问题上，并没有一刀切的答案。分布式数据库的诞生，首先是为了解决传统数据库不擅长的场景，在关系型数据库做到极致的领域同样需要很长的时间才能完善，并不是为了单纯替换某个原有系统。如果只是为了使用及推广新技术，而进行固有架构的替换，将会面临极大的技术风险与挑战。可以看到，目前国内绝大部分的分布式数据库的产品试用，都是在一些非核心系统的应用。例如：在金融机构，分布式数据库常用于渠道类业务如：网联、第三方支付对接等，在生产环境中验证产品功能和稳定性，并没有实现真正的替代。相比较于DB2、Oracle等商业数据库和MySQL 等开源数据库，分布式数据库产品在生态圈、技术手册、技术支持等多个方面，还是稍逊一等，仍然有大量可提升的空间。由于尚无统一的业界标准，也没有哪一款分布式数据库产品，是这个领域不可争议的第一名，就如同Oracle一样。对于分布式数据库而言，想要替代Oracle，更大难点在于如何从Oracle迁移出来。很多企业原本都是传统数据库一体化解决方案，其设计与运维经验不一定完全适合分布式数据库。从Oracle迁移至分布式数据库就会遇到各种障碍，例如：不同数据库之间的异构数据如何做到无损迁移？迁移过程中如何保障系统稳定性？如何设置异构数据库并行过渡期？Oracle数据库往往和应用耦合度较高，迁移过程还会涉及到应用迁移和改造，如何评估改造量和改造难度？兼容性如何保障？数据库迁移完成后如何成功建转运？传统运维方案中的网络、存储、监控告警、备份恢复等等应该如何规划？除此之外，尽管分布式数据库比原来各业务系统独立使用数据库更加易于运维，但是刚引入分布式数据库，难免碰到运维技术和人力跟不上的阶段。从全球数据量发展的方向来看，其爆发性增长，主要集中在基于数字化创新的多样化业务场景。因此，单纯替代传统Oracle占据核心优势的固有领域，并非是分布式数据库未来的增长方向。分布式数据库的最佳落地与使用方式，是从海量数据业务到核心的逐步迭代过程。先从存在海量数据弹性扩展的新兴业务需求入手，随着业务革新不断的深入，逐渐渗透进传统业务及应用中。企业在选择分布式数据库落地场景时，也应该选择适当的应用场景，以真正发挥其优势能力，并持续打磨技术团队的运维能力，并逐步推向核心。 来源：科技云报道
免责声明：此文内容为第三方自媒体作者发布的观察或评论性文章，所有文字和图片版权归作者所有，且仅代表作者个人观点，与
无关。文章仅供读者参考，并请自行核实相关内容。投诉邮箱：editor@fromgeek.com。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
