简介
确定您需要哪种数据库基础设施来满足应用程序的性能、可靠性和扩展需求可能是一项艰巨的任务。您为数据库拓扑所做的选择会影响您的整个应用程序堆栈如何响应不同类型的使用情况，以及它可以应对哪些故障场景。因此，了解您的选择并做出符合您目标的明智决策非常重要。
从处理所有基础设施需求的单个数据库到更复杂的系统，有很多不同的方法。与此同时，也有许多权衡需要考虑。
在本指南中，我们将介绍一些最常见的关系数据库基础设施模式，以及它们如何与不同的使用模式对齐。我们将了解每种配置提供的优势以及您需要考虑的一些缺点。我们还将讨论不同决策对您的整体运营复杂性的影响。完成阅读后，您应该能够更好地判断哪些设计最适合您当前的需求，以及您可能希望随着需求变化而尝试哪些选项。
垂直扩展
扩展数据库系统最简单的方法是垂直扩展。垂直扩展，也称为向上扩展，意味着增加管理数据库的服务器的容量。通过增加处理能力、内存分配或存储容量，您可以提高数据库系统可以处理的性能和容量，而不会增加系统整体的复杂性。
作为一般规则，向上扩展数据库是一个很好的第一步，因为它可以在不影响基础设施拓扑的情况下提高数据库的功能。向上扩展通常也相当简单，因为可以将容量更大的机器配置为复制追随者，直到它同步，然后可以触发故障转移使其成为新的主服务器。
然而，向上扩展也有其局限性，因为可以合理分配给一台机器的资源量是有限的。如果没有配置复制追随者在出现问题时接管，它也代表了单点故障。这些问题可以通过其他一些扩展选项来解决。
命令查询职责分离 (CQRS) 和只读副本
扩展数据库基础设施的另一种主要方法是水平扩展。水平扩展意味着您不是增加单个服务器的容量，而是增加专用于满足特定需求的服务器数量。因此，您通过向基础设施添加额外的机器来增加容量。
命令查询职责分离 (CQRS) 是一个术语，用于描述添加逻辑以分离修改数据的查询（写入查询）和不修改数据的查询（读取查询）。这使您可以将这些不同类别的请求路由到不同的主机，以帮助分配负载。
利用此设计的最基本基础设施是一个主服务器，它可以接受读取和写入查询，以及一个或多个跟随主服务器的副本服务器，这些副本服务器可以接受读取查询。此设计适用于读取密集型应用程序使用模式，因为读取操作可以由任何数据库服务器处理。
此外，该系统还为您的架构提供了一些冗余，因为如果任何服务器宕机，系统仍将运行。如果追随者宕机，则可以将读取请求路由到其他服务器。如果主服务器宕机，则可以将其中一个副本追随者提升为接受写入查询。
多主复制
虽然使用 CQRS 和只读副本可以帮助您处理更多的读取请求，但它不会显着影响基础设施的写入性能。为了提高架构可以处理的写入次数，您需要考虑是否可以采用多主复制设计。
多主复制是一种复制形式，其中多个服务器可以接受写入请求。有些系统配置为任何服务器都可以处理写入请求，而另一些系统则设计为一组核心主服务器处理写入，而更多的只读追随者。无论实现方式如何，多主复制都会增加负责写入查询的服务器数量。
虽然这种设计乍听起来很理想，但仍存在一些重大挑战，阻止其成为广泛采用的模式。虽然多个服务器可以处理写入请求，但它们仍然必须协调以在其服务器之间复制更改并解决数据更改中的冲突。这可能导致在协商冲突时响应时间过长，或者可能导致数据不一致。
每个系统都选择自己的方法来应对这些挑战。这是CAP 定理的演示——一个描述分布式系统中一致性、可用性和分区容错之间相互作用的声明——在行动。一些系统提供较弱的一致性保证以保持可用性，而另一些数据库则拒绝接受更改，如果它们的对等方无法在写入时协调事务。在各种实现之间进行选择时，选择最适合您需求的方法是一个重要因素。
读取查询缓存
虽然使用只读副本是一种增加可以响应读取请求的可用数据库的方法，但它并不能提高复杂读取操作的基本查询性能。服务器仍然需要每次发出请求时执行读取操作，即使结果与之前的查找相同。
为了减少响应时间，可以引入读取查询缓存层。在数据库客户端和数据库本身之间添加缓存可以显着减少常用请求的查询时间。应用程序可以从缓存请求读取结果，并在可用时几乎立即收到结果。对于在缓存中找不到结果的情况，将从数据库本身获取结果并添加到缓存中以供下次使用。
以这种方式配置缓存对于数据不太可能在每次发出请求时都发生更改的场景非常有效。它对于咨询多个表并包含复杂连接操作的昂贵读取查询特别有用。这些结果可以执行一次，然后保存以供将来查询。
在数据变化速度更快的情况下，读取缓存可能几乎没有帮助。根据配置的行为，缓存在这些情况下有返回陈旧数据的风险，并且应实施周到的缓存失效策略，以便在数据更改时从缓存中清除陈旧数据。
数据分片
到目前为止，我们讨论的设计都是根据数据库组件是否响应写入请求来对数据库组件进行分段。然而，另一种划分职责的方法是将实际数据集分成多个部分。
分片是将逻辑数据集分解为更小的子集，以将其管理分配给不同的机器的过程。每个数据库服务器仅处理一部分数据，并引入路由机制，该机制了解哪些机器负责哪些数据。
通常，分片在一次操作整个数据集是不必要或不常见的场景中执行。数据集根据每个记录的特定键值进行分段，该键称为分片键。例如，您可以根据客户的位置手动分片数据。您还可以使用哈希算法自动分片，以确定哪些节点应处理哪些键。这可以帮助您的系统避免在分片键空间分布不均匀的情况下出现不平衡分布。
分片为数据系统引入了相当多的复杂性，并且不适用于所有场景。与多个分片交互的操作将遭受显着的性能损失，因为它们会从每个成员检索结果。这可能会发生在聚合查询中，或者在预先不知道特定分片键的情况下。此外，分片分配不均匀也可能导致效率低下和瓶颈，需要通过重新平衡整个数据集的分布来解决。
去中心化功能数据管理
在许多情况下，与其将数据集的值拆分为多个段，不如为不同的功能目的使用不同的数据库更有意义。例如，如果您有帐户服务和产品服务，则拥有与每个关注点相对应的专用数据库可以帮助您独立扩展不同的组件。
功能数据管理允许您分解数据库基础设施，并根据其客户端的需求管理每个部分。可以使用最有意义的策略来扩展每个功能部分。它允许您设计数据库模式并将其部署到最符合特定用例模式的位置，而不是要求它为整个组织服务。
对于许多组织来说，此策略具有重要的优势，这些优势超出了实际系统的属性。去中心化数据管理可以允许较小的团队拥有自己的数据，而无需与其他各方协调更改。它与面向微服务的应用程序架构提倡的关注点分离非常吻合。
无服务器数据库
对于许多人来说，您必须评估的不同权衡以及您可能需要管理的用于正确扩展的基础设施量可能会让人不知所措。卸载这种复杂性的一种选择是利用数据库服务，这些服务可以为您管理基础设施和扩展。
无服务器数据库是一类服务，它将数据存储与数据处理分离，以便轻松扩展资源以响应需求变化。
数据存储层负责维护系统管理的实际数据。在此层的前面，部署了可扩展数据库处理单元层，以处理针对数据集的实际查询处理。任何给定时间处于活动状态的单元数量直接与当前使用情况相关联，因此随着需求高峰分配更多资源，如果情况平静下来，处理单元将返回待机状态。
查询通过路由代理转发到数据库处理器，路由代理知道如何将请求转发到活动节点以及何时请求其他资源。
无服务器数据库具有与实现自动缩放功能的传统数据库服务相同的许多属性。两者都可以根据需求分配容量。但是，无服务器数据库允许您将存储成本与处理成本分开，并且可以在不需要时将处理量缩减为零。此外，与传统产品提供的自动缩放相比，无服务器解决方案往往能够更快地扩展以满足需求。
虽然无服务器数据库可能适合某些情况，但它们并非万能药。在数据库处理器已缩减为零的情况下，由于冷启动，再次处理可能会出现延迟。此外，无服务器数据库堆栈中各种组件之间连接的 churn 可能会导致额外的延迟。
从运营的角度来看，无服务器数据库平台也可能很困难。部署和数据库更改可能更难以推理和监控。由于数据库系统的动态状态，本地开发环境也可能与生产环境显着不同。最后，与任何其他云服务一样，使用无服务器数据库可能会使您面临供应商锁定的风险。在围绕无服务器平台进行设计时，记住这些权衡非常重要。
结论
随着您的应用程序需求变得越来越重要，有很多方法可以设计、部署和管理您的数据库基础设施。每种解决方案都有其优势和局限性，在尝试为您的环境找到合适的解决方案时，了解这些优势和局限性非常重要。
了解数据库基础设施如何影响数据的可用性、性能和完整性，可以让您避免代价高昂的错误和无法提供所需保证的实施。如果上述设计之一不能满足您的要求，您可以组合不同方法的一些元素以获得额外的优势。
如果您想了解更多关于上述通用模式的信息，以下是一些您可能想要查看的其他资源
常见问题解答
数据库可扩展性是扩展或收缩系统资源容量以支持应用程序不断变化的使用情况的能力。
既有垂直扩展，也有水平扩展。垂直扩展是指向上扩展单个服务器或集群。水平扩展是指将额外的节点引入系统以分担增加的使用量带来的负载。
命令查询职责分离 (CQRS) 是一个术语，用于描述添加逻辑以分离修改数据的查询（写入查询）和不修改数据的查询（读取查询）。
这使您可以将这些不同类别的请求路由到不同的主机，以帮助分配负载。
CQRS 是使用微服务时常用的设计模式。数据库读写操作的分离避免了复杂的查询和连接。它符合微服务应用程序架构中寻求的原则。
使用 CQRS 设计模式，您可以分离关注点和数据库职责，而单个数据库将在单体架构中承担这些职责。
分片是将逻辑数据集分解为更小的子集，以将其管理分配给不同的机器的过程。
每个数据库服务器仅处理一部分数据，并引入路由机制，该机制了解哪些机器负责哪些数据。
分片和分区都将大型数据集分离为更小的子集。两者之间的区别在于，分片通常意味着跨多个服务器分离数据，而分区则不然。分区通常发生在单个数据库上。