为什么使用专用数据库？
为了了解专用数据库的重要性，我们来探讨一下应用程序架构在过去几十年里发生的变化。然后，我们来看看数据库在现代应用程序开发中的作用。
点击以下选项卡，了解云原生数据库更适合当今应用程序的一些原因。
-
应用程序架构的发展历程
-
微服务世界中的数据库
-
应用程序架构的发展历程
-
近几十年来，应用程序架构发生了显著的变化。最初，公司使用本地大型机来处理他们的关键应用程序。这些大型机兼具应用程序的各个方面 — 计算和存储 — 并连续运行数年而不中断。
后来，使用客户端-服务器 (C/S) 架构将应用程序分为了多个部分。服务器将响应来自各个客户端的请求，从而实现了更多的分布式系统。客户端和服务器可以位于同一台计算机上，但在需要时，分别位于不同的计算机可以实现更具可扩展性的系统。客户端和服务器可以分开，以免争用资源。
随着互联网的兴起，三层架构日益流行。应用程序被按功能划分为多个组件：表现层作为用户界面；应用层负责业务逻辑和处理；数据层提供长期持久的存储。这一进步再次提升了应用程序的可扩展性，因为每个层都可以独立扩展。
从大型机到客户端-服务器，再从客户端-服务器到三层架构，这些转变都属于横向拆分，即应用程序的不同技术部分在不同的层进行处理，然而纵向拆分实现了下一个转变。近年来，微服务的概念已经兴起。利用微服务，可以根据功能将应用程序分为不同的服务。例如可以将库存数据处理和订单历史数据处理分成两个独立的服务，分别负责各自的领域，而不是由一个应用程序同时处理这两个方面。这种拆分不仅独立扩展了这两种服务，而且提高了开发团队之间的敏捷性。
-
微服务世界中的数据库
-
了解了应用程序架构的发展历程后，我们来看看数据库是如何随之发展的。
起初，大多数数据库都使用分层数据模型。数据以树的形式进行存储，父记录连接到子记录。每个子记录只能连接到单个父记录，这限制了对更复杂概念（如多对多关系）进行建模的能力。分层数据库通常部署在本地数据中心，并用于内部系统。
后来，关系数据库风靡全球。在关系数据库中，对 Schema 进行严格的约束，并对记录进行规范化以避免数据重复。Schema 约束有助于解决数据完整性问题，规范化有助于节省存储成本，因为存储是数据中心中最昂贵的资源。SQL 查询语言的采用使开发人员能够根据需要重新组合规范化数据。在关系数据库流行期间，远程数据中心越来越多地用于托管应用程序。
在 21 世纪初，有两次重大转变改变了数据库格局。第一次重大转变是，可以访问互联网的全球业务呈上升趋势。随着全球应用程序的发展，数据库的性能被推到了极限。由于存储成本急剧下降，而关系数据库难以满足性能需求，NoSQL 数据库在数据库领域中悄然兴起。这类数据库去掉了关系数据库的某些功能，如 Schema 约束、事务支持和 SQL 查询语言，性能优于关系数据库。
与此同时，越来越多的公司将其应用程序迁移到云。企业们更偏向于云的弹性伸缩模型，因为他们可以根据实际客户需求来进行扩容和缩容，而不是根据前几个季度的数据预估。随着应用程序开发转向微服务，开发人员不需要选择一个可以处理所有任务的多功能数据库。每个开发团队都可以选择适合自己应用程序的数据库。因此，专用数据库的使用越来越普遍。设计应用程序时，可以选择最适合处理任务的数据库。
在应用程序架构中，选择数据库是最重要的决策之一。所选择的数据库类型将影响可以处理的访问模式、应用程序的性能以及您的团队将负责的运维任务。应该考虑许多因素，包括应用程序工作负载、数据形态、性能要求和运维负担。
-
应用程序工作负载
-
数据形态
-
性能要求
-
运维负担
-
应用程序工作负载
-
选择专用数据库时应考虑的第一个因素是应用程序工作负载。工作负载描述了应用程序存储的数据类型和数据访问模式。
工作负载分为三大类：
- 事务型：也称为在线事务处理 (OLTP)，指的是需要执行大量并发操作的应用程序使用场景，其中每个操作读取或写入少量数据行。这适用于大多数面向用户的应用程序，包括电子商务、手机游戏和社交网络。
- 分析型：也称为在线分析处理 (OLAP)，指的是汇总大量数据的使用场景。分析型数据存储中的并发查询通常要少得多，但每个查询需要处理的数据行要多得多。分析型访问模式通常用于内部应用程序，例如报告。
- 缓存型：在缓存型工作负载中，可以计算频繁访问的数据并将其存储在单独的数据库中，以缩短响应时间。这不仅可以减少事务数据库的负载，还可以缩短对终端用户的响应时间。这类数据库很少是数据的主要来源，而是缓存作为辅助来源，存储事务型工作负载的派生数据。
了解您的工作负载类型将有助于更轻松地选择适合使用场景的数据库
-
数据形态
-
第二个需要考虑的因素是数据的形态。在考虑数据形态时，请了解将要建模的实体类型以及实体之间的关系。您将如何访问数据？实体多久更新一次？
以下列出了一些常见数据模型，以及应用于的使用场景：
- 关系：关系数据库已为大多数开发人员所熟知。在关系数据库中，可以将数据规范化为单独的表，并在查询时将相关实体组合在一起。适用于有多个相关实体但具有不同更新模式的使用场景。严格的模式验证和规范化的数据模型有助于确保整个应用程序的数据完整性。
- 键值或宽列：键值或宽列数据存储专为扩展而打造。数据分布到多个存储节点中，并且可以随着数据的增加添加更多存储节点。这种分区模式可实现几乎无限的可扩展性，而不会降低性能。
- 文档：文档数据模型使用称为文档的大型记录将频繁访问的异构数据位组合在一起。可以将数据放在一个文档中，以加快访问速度，而不将这些数据分布在多个表中。
- 图形：图形数据模型突出强调数据之间的关系。利用图形数据库，可以遍历对象之间的关系，查找数据之间隐藏的联系。图形数据库通常用于社交网络或欺诈检测服务。
了解对数据的访问模式，有助于选择适用于应用程序的专用数据库。
-
性能要求
-
选择专用数据库时需要考虑的另一个重要因素是应用程序的性能要求。这不仅指的是数据访问速度和记录大小，还指的是在终端用户中您的服务的使用场景。
如果您的服务为等待响应的用户处理关键工作负载，那么速度至关重要。您可能希望使用内存缓存来帮助减少对用户的延迟。
另一方面，如果您的服务用于执行内部分析或后台数据处理，那么速度可能是一个不太重要的因素。您可能更关心您的服务是否能够处理传入系统的数据量。
此外，还应该考虑数据的地域要求。一些数据库，例如 Amazon DynamoDB 和 Amazon Aurora，可以让您轻松地在全球范围内复制数据。这意味着您的数据离用户更近，响应时间更短。
-
运维负担
-
选择专用数据库时应该考虑的最后一个因素是数据库的运维负担。针对数据库进行开发只完成了一半任务，还需要确保为实例故障做好准备，配置备份，并制定升级计划。
使用 AWS 专用数据库时，会为您承担大部分运维负担。AWS 数据库可以在主实例发生故障的情况下自动升级副本实例。备份和还原由系统完全托管，您也无需关注软件升级。通过使用 AWS 的全托管数据库，您可以专注于为用户开发功能和创新。
在本课程的其余模块中，您将完成五个不同 AWS 专用数据库的实操教程。本课程将使用餐厅点评应用程序为例。您将构建一款用户可以评价餐厅并查看餐厅评价排行的应用程序。在这些实操教程中，您将使用专用数据库处理主存储、缓存、欺诈检测等任务。