长期以来,关系型数据库一直是各类公司在软件应用方面首选的通用解决方案。无论规模大小,它们几乎适用于所有场景。
如今,随着 NoSQL、内存数据库和数据湖等技术的日益普及,选择变得更加多样化。然而,在将内部部署数据库迁移到云端时,关系型数据库仍然是最直接的选择。
我们将深入探讨以下几种数据库,它们可以作为云迁移计划的一部分:
- Oracle 数据库
- Aurora 数据库
- Microsoft SQL Server
- MySQL 和 PostgreSQL
- MariaDB
本文将详细阐述这些数据库之间的差异与特点,包括它们的不足之处。 接着,通过一些典型的实际应用案例,让您更好地理解它们的应用场景。 最后,我将分享关于如何根据具体需求在不同数据库之间做出选择的建议。
AWS Oracle 数据库
资料来源:aws.amazon.com
Oracle 数据库无疑是过去几十年中使用最广泛的商业数据库。 当企业需要一个强大且高性能的数据库解决方案时,Oracle 数据库通常是首选。 这其中有很多充分的理由。
它有何不同
Oracle 是一个功能全面、强大的平台,可以满足各种不同的配置和需求。 长期以来,如果需要在本地硬件基础设施上实现最高水平的可靠性、可扩展性和可维护性,Oracle 数据库都是首选解决方案。
主要优势
选择像 Oracle 这样成熟的数据库系统,您将获得以下主要优势:
✅ 对备份和恢复操作提供强大的支持和丰富的选项。
✅ 具有广泛的可能性来调整系统内部数据库解决方案的性能,即使是在系统上线很久之后。 平台内的支持和维护活动设置简单,而且效果显著。
✅ 数据库解决方案的高度定制化。 Oracle 数据库支持大量可选择的功能,作为系统集成商,您可以灵活地构建一个包含平台所需功能的健壮系统(例如,触发器、分区、子分区、自动主键序列、视图、快照、数据约束、唯一键、组合键、外键、复合索引等)。 它几乎支持一切。
✅ 轻松管理数据库活动和流程。 配备专用的管理控制台和仪表板,以及许多由 Oracle 开发并提供给管理员的开箱即用工具。
✅ 支持多用户环境。 如果您需要同时支持数千个不同的活跃用户,那么 Oracle 数据库是理想选择。
主要缺点
Oracle 数据库在垂直扩展性能方面非常灵活。 但是,当您需要强大的水平扩展时,情况就不那么乐观了。 这意味着在集群数据库上升级到更强大的 CPU、更多内存和存储空间是很容易实现的。
然而,如果您的数据在短时间内显著增长(在云环境中这种情况很常见),性能瓶颈将变得更加明显,也更难解决。 将数据分布在多个集群中并期望它们动态扩展,将成为未来的主要需求。 在这种情况下,您可能会发现 Oracle 数据库的局限性开始显现,难以满足您未来的需求。
另一个潜在的缺点可能是成本。 Oracle 数据库虽然支持许多特性,但其中许多特性是有代价的。 当需要使用多个集群并且必须升级物理性能时,尤其如此。 这意味着仅仅通过软件调整数据模型已经不足以满足需求。 如果要获得更多管理工具和功能,您需要购买企业许可证,这会进一步增加已经很高的成本。
最后,Oracle 数据库不是原生的 AWS 数据库服务,这意味着您不能期望获得 AWS 的全面支持,而是需要依赖 Oracle 的支持。 这意味着您需要同时应对来自 Oracle 和 AWS 两个不同支持团队的问题,这可能会比较麻烦。
何时选择
如果您的现有内部部署解决方案已经在使用 Oracle 数据库,那么选择 Oracle 数据库的云版本是最自然的选择。 这也会使迁移到云解决方案的过程更加顺畅。
因此,选择 AWS Oracle 数据库的理由如下:
- 您希望在可预见的未来,云数据库能够支持与本地部署版本相同的流程和功能。
- 您不打算在短期内将数据库与太多 AWS 原生服务集成。
- 您不期望当前的数据量在短期内出现显著增长。
- 您需要对大量现有功能提供支持。也就是说,当切换到云时,不希望失去当前所具备的某些功能。
- 您的系统必须能够同时支持数百个活跃用户(甚至更多)。
使用示例
- 大型电信系统,用于处理计费、CRM 和中间件数据。
- 汽车数据库系统的定制数据库实现,与多个不同的定制或第三方供应商工具集成。
- 银行业的打包系统解决方案,其中 Oracle 数据库已经是供应商打包解决方案的固定部分,最终将额外的定制数据库组件集成到一个复杂的实现中。
AWS Aurora 数据库
资料来源:aws.amazon.com
在很多方面,Aurora 数据库与 Oracle 数据库形成了鲜明的对比,尽管它仍然属于关系型数据库的范畴。
它有何不同
Aurora 数据库是 AWS 中的原生数据库服务。 AWS 为其提供全面的支持和持续开发,并将其与 AWS 服务生态系统的其他部分深度集成。
Aurora 数据库在功能多样性方面还无法达到 Oracle 数据库的水平。 但它诞生于云端(与 Oracle 数据库不同)。 随着 AWS 对 Aurora 的进一步开发,未来的功能差距最终可能会比现在小得多。
在许多方面,Aurora 数据库已经领先于 Oracle 数据库,尤其是在与其他 AWS 云服务的集成方面。 而且,由于亚马逊在创建 Aurora 时考虑到了云生态系统,Aurora 数据库已经准备好接收海量的数据,并随着时间的推移而增加,因此水平扩展是一项强大的特性。
主要优势
我认为,Aurora 数据库的主要优势在于:
✅ 非常灵活的只读数据库副本实例的扩展性。 您可以在几秒钟内创建这些副本。 只读实例共享它们所源自的主数据库的相同数据库日志。 这意味着创建一个新的只读数据库不需要同步所有数据; 它可以通过共享现有的数据库日志自动完成。
✅ 具备应对大数据增长的能力,水平扩展是 Aurora 数据库的一大特色。 添加新集群和扩展不同可用性区域的可扩展性非常简单。 Aurora 在快速选择大量数据方面非常高效。
✅ 您可以选择使用 Aurora 数据库的 Server 或 Serverless 模式。 在 Serverless 模式下,某些功能可能不可用。 但是,选择 Serverless 模式可以获得很大的灵活性和成本优化。
✅ 自动备份和简单的时间点恢复。 另一个亮点是,Aurora 数据库可以轻松完成日常备份,并将整个数据库恢复到任何时间点。 在这里,您可以结合云环境的所有优势,例如始终可用的可用空间、快速的内部 AWS 操作以及旨在实现快速恢复时间和短停机时间的专用 Aurora 数据库功能。
✅ 支持 MySQL 或 PostgreSQL 数据库引擎,因此您可以选择适合您的数据库引擎。
主要缺点
- 尽管 Aurora 可以说是您在 AWS 中可以使用的功能最丰富的原生关系型数据库,但它在功能丰富性方面仍然落后于 Oracle 数据库。 这是可以理解的; Oracle 数据库有更多的时间来开发这些功能。 事实上,Aurora 数据库的每个版本都变得更加强大,功能也更加完善。
- 在本地部署环境中没有与 Aurora 数据库等效的产品。 也许可以认为,在 MySQL 或 PostgreSQL 数据库上构建的旧数据库非常匹配,从兼容性的角度来看,它们确实如此。 但它们并不是严格的等价物。 这意味着迁移不会那么简单。 您将需要自定义和实施迁移流程,以确保它们能够从本地传输数据并将其存储到 Aurora 数据库中,并且所有数据都采用正确的数据模型格式。
- 各种 AWS 限制,特别是那些硬性限制,在某些情况下可能会影响您选择此数据库作为迁移目标。 您很可能能够解决所有这些问题,但对于某些情况而言,您需要进行更认真的重构,与选择其他数据库目标相比,这最终会增加迁移的总成本。
何时选择
简而言之,选择 Aurora 数据库作为 AWS 平台上的首选关系型数据库绝不是一个错误的选择。尤其是在以下情况下:
- 您将围绕关系型数据库从头开始构建云系统。
- 您希望与尽可能多的不同 AWS 原生服务实现最高级别的兼容性和完整性。
- 您预计您的数据量将在短时间内显著增长。
- 您计划启动几个衍生出来的概念验证 (POC) 项目,并且希望在这些项目中使用关系型数据库的 Serverless 版本的所有优势。
使用示例
- 用于分析大量基础设施图像数据的 Serverless 平台。
- 利用机器学习模型来处理数据湖信息,并为您的业务生成商业预测。
- Netflix 使用 Aurora 数据库对其目录数据执行快速的并行查询。
AWS Microsoft SQL 数据库
资料来源:aws.amazon.com
该数据库在某些方面可以与 Oracle 数据库相媲美。 它也是在云时代到来之前很久就创建的,并且有很多当前的本地用户计划使用 MS SQL 数据库作为源数据库迁移到云端。
它有何不同
尽管有这些相似之处,但与 Oracle 数据库相比,MS SQL 数据库的使用量仍然较少。
至少从我个人的经验来看是这样的。 在过去的二十年里,我参与了多个 Oracle 项目,但只参与了少数涉及 MS SQL 数据库的案例。 坦率地说,我并不像处理 Oracle 数据库那样频繁地处理它。
不管怎样,我仍然意识到有很大一部分公司使用 MS SQL 数据库作为主数据库,它是所有数据的单一事实来源。
主要优势
MS SQL 数据库的主要优点:
✅ 与其他 Microsoft 服务和软件的良好集成,如果这是您认为对您的应用场景有价值的功能。
✅ 使用自定义代码扩展轻松定制,主要以 Javascript 代码模块的形式实现。 这在处理要通过数据库安排的更复杂的业务流程和作业时非常有用。
✅ 从管理的角度来看,非常简单(至少与 Oracle 数据库相比)。
✅ 它在 Azure 云生态系统中可能更有意义,因为它被认为是一个本地关系型数据库系统,与那里的其他云服务更兼容。
主要缺点
- 与 Oracle 数据库的情况类似,作为 AWS 云空间中的非原生数据库,所有支持和问题解决都必须通过单独的专用 MS SQL 支持团队来完成。
- 与 Oracle 数据库或 Aurora 数据库相比,功能支持的多样性通常较少。
- 不适合大量活跃用户。
- 水平可扩展性是一个比 Oracle 数据库更大的问题。
何时选择
如果您想将现有的本地 MS SQL 数据库迁移到云端,并尽可能减少干扰,那么 MS SQL 数据库是最理想的选择。 此外,如果您不希望在很大程度上与其他 AWS 云服务集成,它也是一个不错的选择。
然后,MS SQL 数据库将作为一个完全托管的数据库存在于 AWS 云中,与内部部署的替代方案相比,它具有无限的存储空间以及扩展的水平可扩展性和高可用性选项。
使用示例
- 作为定制集成各种数据库系统(甚至可以是不同类型,例如 Oracle 数据库)的中间平台。
- 各种规模较小的项目,其中数据库解决方案的成本是一个需要考虑的因素,而且预算更有限(并且不允许使用成熟的 Oracle 数据库解决方案)。
AWS MySQL 和 PostgreSQL 数据库
资料来源:aws.amazon.com
这些数据库都是开源的(尽管现在已被大型公司收购),这最终给它们带来了好处和坏处。
它们的功能也不像其他替代品那么丰富,尤其是在它们的原始形式下。 虽然您仍然可以在 AWS 基础设施中使用它们,但我怀疑这是否仍然具有太多实际意义。
它有何不同
当将本地数据库(无论是 MySQL 还是 PostgreSQL)迁移到 AWS 云时,您可以直接将 Aurora 与 MySQL 或 PostgreSQL 引擎一起用作目标,从而获得 Aurora 数据库提供的所有额外优势。
当然,与选择本地替代方案的情况相比,这意味着迁移阶段需要付出更多的努力,但这种额外的努力微乎其微。
它们的主要优势在于成本,并且它们最适合小型项目,在这些项目中,稳健性并不是真正的主题。
主要缺点
- 两者在支持的功能上都非常有限,您需要为可维护性和管理的有限选项做好准备。
- 不适合有很多活跃用户的大型项目。
- 不是高性能解决方案的最佳选择,而且持续的性能调整是一个强烈的需求。
何时选择
- 如果成本是主要考虑因素,并且预算非常有限。
- 如果项目规模很小。
- 如果数据量很小,并且没有显著增长的计划。
使用示例
- 基础设施成本应尽可能低的个人项目计划。
- 为了验证所提出的概念可行性的小型概念验证 (POC) 项目。
- 数据量较小的小型公司项目。
- 对于小型 SaaS 项目,不需要大量的数据库负载,只需要以关系数据模型方式存储数据即可。
AWS MariaDB
资料来源:aws.amazon.com
MariaDB 仍然是一个完全开源的数据库,由前 MySQL 开发人员创建(在 MySQL 被 Oracle 收购之后)。
在兼容性方面,任何 MySQL 数据库都可以在 MariaDB 中正常运行。
它有何不同
功能方面,与 MySQL 没有太大的区别,但开源特性是亮点。
从技术上讲,MariaDB 中有相当多有用的特性,但在 MySQL 中不可用。
主要缺点
与 MySQL 的情况非常相似。
何时选择
- 如果您绝对喜欢当前的 MariaDB 本地部署,并且出于任何原因不想迁移到 Aurora 数据库。
- 如果您希望在 AWS 云生态系统中使用数据库解决方案时保持真正的开源。
使用示例
与 MySQL 的情况非常相似。
最后的话
正如 Oracle 数据库在本地部署环境中是常见选择一样,Aurora 数据库似乎正在 AWS 云世界中占据一席之地。 至少从功能集来看,Aurora 是您在云端可以获得的最接近 Oracle 数据库的替代方案。
即便您不是主要利益相关者,了解到仍然有非常简单的选择可以将现有数据库迁移到 AWS 云中也是令人欣慰的。
更重要的是,通过此次迁移,您将自动获得之前最有可能缺少的功能。 其中,更优秀的存储可扩展性、高可用性和水平扩展性都是云环境的原生特性。