概要

应用程序正在变得越来越好，它拥有更多的功能、更多的活跃用户，并且每天都会收集更多的数据。但数据库现在导致应用程序的其余部分变慢。数据库分片可能是问题的答案，但许多人不知道它是什么，最重要的是何时使用它。在本文中我们将讨论什么是数据库分片、它的工作原理以及使用它的最佳方法。

在我们讨论这个问题之前，有必要了解为什么我们对数据存储进行分片，以及在开始分片之前可以选择的各种选项。

当表达到特定大小时，人们通常会觉得分片是解决所有扩展问题的神奇解决方案。然而拥有包含数十亿行的表，并且没有看到令人信服的理由进行分片，因为使用模式非常适合单个表，并且没有看到任何强有力的理由（除了管理如此大的表之外）对表进行分片。

什么是数据库分片？

简单来说分片是一种跨多台机器分布数据的方法。当没有一台机器可以处理预期的工作负载时，分片变得特别方便。

分片是水平扩展的一个例子，而垂直扩展是一个越来越大的机器来支持新工作负载的例子。

工程师经常会陷入以最复杂的方式做事的过程中，但是随着应用程序的发展变得更加容易，早期保持事情简单会使以后的事情变得具有挑战性。因此，如果问题通过获得具有更多资源的计算机而消失，这就是正确的答案。

现在我们已经讨论了潜在的服务器架构，让我们谈谈数据布局。

还可以通过多种方式对数据进行分区，并将特定表移动到其数据库，这与在微服务架构中看到的非常相似，其中应用程序的特定方面拥有其数据库服务器。应用程序知道在哪里寻找每个。或者可以跨多个数据库节点存储同一个表的行，这带来了诸如分片键之类的想法；稍后会详细介绍。

Cassandra 等更现代的数据库将其从应用程序逻辑中抽象出来，并在数据库级别进行维护。

分片之前有哪些选择？

与任何分布式架构一样，数据库分片也需要花钱。设置分片、保持每个分片上的数据最新以及确保请求发送到正确的分片既耗时又复杂。在开始分片之前可能想看看这些其他选项之一是否适合。

选项 1：什么也不做。

曾多次被问到在没有任何明显的瓶颈或限制因素（例如耗尽可以支持工作负载的硬件）的情况下，分片是否是一个好主意。如果没有损坏，就不要修理它。

选项 2：垂直缩放

之前我们已经回避了这一点，只是让机器拥有更多资源，添加额外的 RAM，为计算繁重的工作负载添加更多的 CPU 核心，并添加额外的存储。这些都是不需要重新设计应用程序和数据库架构的选项。其他最终限制，例如带宽（网络或系统内部），也可能迫使进行分片。

WAL WAL（预写日志）是磁盘上只能添加的额外结构。在将更改写入数据库之前，首先将它们写入日志，该日志必须位于持久存储上。它用于从崩溃和丢失的事务中恢复。此日志还用于支持某些数据库（例如 PostgreSQL 和 MySQL）中的复制。

选项 3：复制

如果对数据所做的大部分操作都是读取数据，那么复制可以提高数据的可用性并加快读取数据的速度。这可以避免数据库分片的一些复杂性。通过制作更多数据库副本可以提高读取性能。当然假设已经补充了缓存，这可以通过负载平衡或根据查询所在的位置路由查询来完成。但复制使得写入密集型工作负载更难处理，因为每次写入都必须复制到每个节点。这可能会根据数据存储而有所不同，其中一些数据存储是异步执行的，而其他数据存储可能会延迟初始写入以确保其被复制。

选项 4：专业数据库

性能不佳是由于数据库需要针对其所服务的工作负载进行更好的设计而导致的。例如将搜索数据存储在关系数据存储中可能没有什么意义。将类似的东西转移到 Elasticsearch 会更有效。将 blob 移动到像 S3 这样的对象存储比将它们存储在关系存储中可能是一个巨大的胜利。外包此功能可能比尝试对整个数据库进行分片更有意义。

如果应用程序数据库管理大量数据、需要大量读取和写入和/或需要始终可用，则分片数据库可能是最佳选择。让我们看一下分片的优点和缺点。