翻译|布加迪规划|云照RDBMS往往是企业所有数据中最关键的，不会自然消失，但也可以作为全面上云的一个落脚点。云吞噬软件，遗留系统是否消失了？当然不是。当今的许多顶级企业要么已经迁移到云，要么正在迁移过程中。作为IT组织的一部分，企业通常拥有一个或多个支持业务核心的大型关系数据库管理系统(RDBMS)。这些庞大的旧单体数据库，往往是公司最关键的数据，自然不会丢弃。相反，它们可以作为完全迁移到云的定位点。无论云战略如何，这些单体数据库对整个生态系统都是必不可少的，应该成为迁移战略的一部分，以确保成功迁移到云。云迁移示例当团队尝试分离连接到大型关系数据库的应用程序或小型系统时，会出现一个常见的错误，如图1所示。为了成功，关系数据库和所有连接的资源（无论是应用程序、辅助数据库、Web服务器等）.)必须整体迁移。此外，这种成功需要一种策略来迁移大量关系数据、多台服务器、已安装的软件、作业和网络配置，这些都是数据生态系统的一部分。网络是最后一个瓶颈，也将是需要克服的最大挑战之一。1.数据引力：大型关系数据库的影响过去，关系系统至少有两层：关系数据库层和应用程序或访问层。在更复杂的设计中，它们有多层应用服务器来管理FTP访问、ETL/ELT、Web服务器、中间件以及与主要关系系统紧密链接的相应数据库。某些平台（例如Oracle）是围绕模式构建的，这会导致更大的数据库：除非作为一个整体来处理，否则更难迁移。首先，关系数据库不断增长，RDBMS是基于模式而不是更小的租户架构设计的，每个数据库可能包含TB甚至PB级的数据。根据数据与其他系统的互连性，数据库的大小会产生自己的“引力”，将系统拉近数据源，以提供最佳的用户体验。在云中，这种拉力被企业云的广泛影响所放大。数据引力将应用程序、连接的数据资产和资源拉到最大的数据量，这通常是具有业务关键数据的遗留关系数据库。随着越来越多的数据在应用程序和数据库之间传输到更大的关系系统（通过ETL/ELT处理或数据库链接），所有涉及的系统都需要紧密连接到更大的关系系统以消除延迟。这实际上是数据引力。在为云构建RDBMS时，必须考虑数据引力。不仅对于基础设施，甚至对于服务，云解决方案都必须了解应用程序和数据库连接，以便部署它们以获得最佳性能。设计从最大的系统开始，然后辐射到最小的组件/服务，确保最具影响力的系统得到成功构建所需的关注。2.全部上云，或者什么都不上云当客户迁移到云端时，他们可能已经尝试了多个迁移的系统，然后才决定将所有内容都迁移到云端。考虑到这一点，我们的目标是不在本地留下任何东西，这需要了解遗留关系系统以及将它们迁移到云端的要求。这种逐步迁移到云策略的最大缺点之一是，以前较小的云迁移项目可能会将各种工作负载转移到多个云中，如果系统之间存在数据交互，这可能会导致需要发现。多云依赖。网络成为最后的瓶颈，没有人想出如何克服它。使用点对点和加速网络，靠近数据中心可能有助于消除一些延迟，但如图3所示，除非开发出新的网络技术，否则这一挑战将继续存在。多云解决方案可以跨云提供商提供一些数据优势，但它们永远不会像单一云解决方案那样发挥作用。云提供商之间的网络延迟差异可能因地区和地理位置而异克服跨云延迟问题的首要目标是确定每天和每周需要在环境之间移动哪些数据。第二个目标应该是开发人员如何在本地执行工作并以尽可能少的冗余为云开发优化它。始终选择简化，这可能会在通过网络拉取或推送数据时导致额外的IO。所有跨云的数据处理都应该经过彻底的测试，确保能够满足业务需求，即使数据可能会逐渐增加，也是可以接受的。3.选择：PaaS还是IaaS？在研究了云迁移之后，平台即服务(PaaS)和软件即服务(SaaS)是诱人的选择，供应商将其作为所有内部部署技术进行了大量营销。用户很高兴听到他们可以减少在支持基础设施和平台上的花费，但忘记了他们想要迁移到云的关系环境中积累了多少技术债务。(1)为什么非常大的RDBMS往往局限于IaaS？一旦PaaS和SaaS要求用户放弃大量定制和功能变得明显，用户就会重新考虑基础架构即服务(IaaS)。这是由多种因素造成的，但大多数挑战都围绕着多年来系统内置的复杂性以及SaaS/PaaS产品中功能的缺乏。在决定哪些选项在云中可用以及将数据资产迁移到云时，应遵循这些简单的准则：SaaS：新项目数据库层不需要自定义代码系统应用程序驱动的开发，简单的数据存储要求小用户群和简单的恢复点Objective(RPO)/RecoveryTimeObjective(RTO)PaaS：新项目vCPU、内存和IO的资源使用很容易适应PaaS管理基础设施的约束，IT资源很少，或者想摆脱这个需要数据库层实现较少高级功能或自定义选项IaaS：您使用从TB到PB的大型关系系统您需要与本地应用程序相同或相似的架构您对资源有独特的需求-IO、vCPU和/或内存您有非常苛刻的要求具有复杂RPO/RTO和开发要求的苛刻工作负载如果您需要使用IaaS，重要的是要意识到c大声供应商可以为大量工作负载提供解决方案，而关系工作负载是独一无二的，需要合适的IaaS解决方案来满足要求。(2)RDBMS迁移策略如何扩展？迁移充满挑战，做好准备是成功的最佳途径。无论您使用过时的客户端/服务器架构还是大型机解决方案，具有多层系统的关系数据库都需要进行规划以确保成功。虽然每个项目都是独一无二的，但某些方面是共同的，如果将其作为计划的一部分加以解决，将有助于确保成功迁移。常见列表通常包括以下内容：数据库大小和复杂性数据负载和连接的生态系统应用程序、作业、Web和其他服务器网络延迟(3)RDBMS中必须确定哪些重要指标？大多数关系型工作负载都是资源密集型的——换句话说，它们对基础设施的要求高于其他工作负载。但是，虽然我们可能专注于CPU和内存，但关系型工作负载，尤其是像Oracle这样的工作负载，可能需要高IO存储解决方案。大多数IO存储和基准测试都关注请求(IOP)，但是，请求大小会有所不同，从而使这些值变得水汪汪的。根据我的经验，建议减少对IOP的关注，并确保围绕VM和存储IO约束选择的解决方案可以每秒处理兆字节（吞吐量）。(4)创建多层RDBMS的复杂性由于云中服务、高可用性和备份的变化，所有围绕存储的决策和解决方案都必须关注RPO和RTO。还应考虑可能不同于RPO/RTO的任何客户正常运行时间SLA，因为服务可能会捆绑到作为体系结构的一部分选择的存储解决方案中。确保所有架构决策都基于应如何为推荐实践设计云架构，而不仅仅是复制客户已经融入其本地架构的内容。这是云中的一个常见错误，会造成漏洞和冗余。转换关系数据库工作负载将是一个很好的起点，可以消除现有本地硬件中固有的基础设施债务。如果将此硬件排除在外，并且所有重点都放在关系工作负载上，则可以根据需要设计新的架构。4.重要保证：架构框架由于大多数数据生态系统不仅需要主数据库和连接系统的迁移，还需要非生产副本的复制，因此构建一个可以简化、自动化和部署的框架非常重要DevOps实践。在没有框架的情况下每次都做所有的环环相扣的操作，既费时又容易出错。构建云迁移框架首先要记录将关系系统从端到端部署到云所需的内容。初始阶段可能类似于图4中所示的一般示例，然后可以对其进行扩展以完成迁移项目计划。扩建完成后，使用工具和脚本尽可能地实现自动化，同时确保足够的灵活性以便将来在众多系统和体系结构中重用。云迁移的高级框架示例确保脚本语言和工具可以像云迁移一样扩展，验证它们可以管理基础设施、关系系统和数据。随着问题的出现和解决，记录它们以确保它们不会在未来再次发生，从而作为云迁移策略的一部分持续提高效率。5.结论大型关系数据库通常是许多云迁移项目的重点。一旦迁移到云端，可能会提出多个项目来实现这些遗留系统的现代化并消除这些遗留系统，但它们的核心通常会成为新应用程序策略的基础，数据驻留在与本地相同的关系系统中。由于资源有限、投资回报率低或工作量大，改造通常会消除更改系统的紧迫性。随着企业继续迁移到云，将大规模RDBMS作为这些数据中心和数据资产的一部分迁移的推荐实践将是必不可少的，因为这些关系系统仍将发挥作用。原文链接：https://dzone.com/articles/migrate-rdbms-dinosaurs-to-the-cloud
