将 RDBMS 恐龙迁移到云端

大型关系数据库如何影响云迁移
关系系统历史上至少有两层——关系数据库和应用程序或访问层。在他们更复杂的设计中，他们有多个应用程序服务器层、管理 FTP 访问的服务器、ETL/ELT、Web 服务器、中间件和相应的数据库，这些数据库要么提供给主关系系统，要么从主关系系统提供。某些平台（例如 Oracle）是围绕模式构建的，这导致历史上更大的数据库更难以迁移，除非作为一个整体。 

关系恐龙的二分法
关系数据库恐龙的自然生命是成长，并且使用基于模式设计的 RDBMS 与较小的租户架构相比，每个数据库都可以拥有 TB 甚至 PB 级的数据。根据数据与其他系统的互连性，数据库大小可以产生自己的引力，将系统拉近源头以提供最佳用户体验。在云中，企业云覆盖的巨大空间放大了这种拉力。 

数据引力会将应用程序、连接的数据资产和资源拉到最大的数据体中，通常是拥有关键业务数据的遗留关系数据库。 

随着越来越多的数据在应用程序和数据库之间传输到更大的关系系统（通过 ETL/ELT 处理或数据库链接），所有涉及的系统都需要与更大的关系主体紧密连接以消除延迟。这本质上就是数据引力。 

RDBMS 数据引力

图 2

在为云构建 RDBMS 时，必须考虑数据引力。不仅对于基础架构的选择，甚至对于服务，云解决方案都必须了解应用程序和数据库连接以部署它们以获得最佳性能。设计从最大的系统开始，然后辐射到最小的组件/服务，确保最具影响力的系统得到架构设计成功所需的关注。 

全有或全无到云端
当客户迁移到云端时，他们可能已经尝试了一些迁移的系统，然后决定认真地将所有内容迁移到云端。考虑到这一点，我们的目标是不在本地留下任何东西，这需要了解陈旧的关系系统以及将它们迁移到云端的要求。 

trickle-to-the-cloud 策略最显着的弱点之一是，以前的较小的云迁移项目可能已经将各种工作负载转移到多个云中，如果系统之间存在数据交互，这将导致围绕多云发现云依赖。网络成为我们最后的瓶颈，没有人发现如何克服它。使用对等网络和加速网络关闭数据中心位置可能有助于消除一些延迟，但如图 3 所示，在开发出新的网络技术之前，这一挑战将继续存在。多云解决方案可以在云提供商之间提供一些数据优势，但它们永远不会像单一云解决方案那样运行。 

云提供商之间的网络延迟差异可能因地区和地理位置而异

图 3：云提供商之间的网络延迟差异可能因地区和地理位置而异 

克服跨云延迟问题的第一个目标是确定每天、每周等在环境之间移动需要哪些数据。第二个目标应该是围绕开发人员如何在本地执行工作并针对云开发对其进行优化，尽可能消除多余的部分。始终选择简化在通过网络拉取或推送数据时可能创建的任何额外 IO。 

所有跨云数据处理都应该经过全面测试，以确保它能够满足业务需求，并且即使随着时间的推移潜在的数据增长也是可以接受的。 

基础架构即服务与平台或软件即服务
在调查云迁移后，平台即服务 (PaaS) 和软件即服务 (SaaS) 被反复推销为所有本地技术的有吸引力的选择。用户很高兴听到他们可以减少在支持基础设施和平台上的花费，但他们忘记了他们想要迁移到云的关系环境中已经建立了多少技术债务。 

为什么非常大的 RDBMS 经常受限于 IaaS？
一旦 PaaS 和 SaaS 需要用户放弃许多定制和功能变得明显，用户就会重新考虑基础架构即服务 (IaaS)。这是多种因素共同作用的结果，但大多数挑战都围绕着多年来系统内置的复杂性以及 SaaS/PaaS 产品缺乏功能。在决定云中可用的选项与迁移到云中的数据资产时，请遵循以下简单的指导原则： 

软件即服务：
您正在从事一个新建（新）项目 
数据库层不需要定制代码 
系统具备应用驱动开发，数据存储要求简单 
您正在使用较小的用户群和简单的恢复点目标 (RPO)/恢复时间目标 (RTO) 
平台即服务： 
您正在从事一个新建项目 
vCPU、内存和 IO 的资源使用很容易适应 PaaS 的限制 
管理基础架构的 IT 资源很少，或者希望取消此要求  
数据库层实现的高级功能或自定义选项较少
基础设施即服务：
您正在使用大型 TB-PB 关系系统
您需要与本地应用程序相同或相似的架构
您对资源有独特的需求——IO、vCPU 和/或内存
您的工作负载非常苛刻，具有复杂的 RPO/RTO 和开发需求
如果需要使用 IaaS，重要的是要认识到云供应商可以为大量工作负载提供解决方案，而关系工作负载是独一无二的，需要正确的 IaaS 解决方案才能满足要求。 

如何构建 RDBMS 迁移策略
迁移具有挑战性，做好准备是成功的最佳行动方案。具有多层系统的关系数据库，无论您使用的是陈旧的客户端/服务器架构还是大型机解决方案，都需要进行规划以确保成功。尽管每个项目都是独一无二的，但某些方面是通用的，如果满足计划的一部分，将有助于保证成功迁移。通用列表通常包括： 

数据库大小和复杂性
数据负载和连接的生态系统
应用程序、作业、Web 和其他服务器
网络延迟
RDBMS 中必须确定哪些重要指标？
大多数关系工作负载都是资源密集型的——换句话说，它们比其他工作负载对基础设施的要求更高。但是，尽管我们可能会关注 CPU 和内存，但关系型工作负载（尤其是 Oracle 等）可能需要高 IO 存储解决方案。 

大多数 IO 存储和基准测试将重点关注请求 (IOP)；但是，请求大小可能会有所不同，从而使这些值因营销利益而受到损害。根据我的经验，建议减少对 IOP 的关注，并确保所选择的解决方案（包括虚拟机和存储 IO 限制）可以处理每秒兆字节（吞吐量）。 

创建 RDBMS 复杂性的层次
随着云中服务、高可用性和备份的变化，所有关于存储和解决方案的决策都必须关注 RPO 和 RTO。还应考虑可能与 RPO/RTO 不同的任何所需的客户正常运行时间 SLA，因为可以将服务捆绑到选择作为架构一部分的存储解决方案中。 

确保所有架构决策都基于应如何为推荐实践设计云架构，而不仅仅是复制客户已构建到其本地架构中的内容。这是云中常见的错误，会造成漏洞和冗余。 

一个好的起点是提升和转移关系数据库工作负载，这将消除现有本地硬件中内置的任何基础设施债务。如果不考虑这个硬件，所有的注意力都放在关系工作负载上，那么可以根据它的需要设计一个新的架构。