这就是768台服务器。对一些人来说，这看起来是很多台计算机。但对于那些管理基础架构的应用程序来说，拥有数百万客户，每秒执行数百万个查询，这很正常。这种规模的产品通常需要成千上万台服务器协同工作。最难以扩展的基础设施组件几乎总是数据库。单个数据库服务器无法处理如此高的需求，因此我们必须通过数据库分片将查询和数据分散到许多服务器上。数据库分片是扩展Postgres或MySQL数据库以处理超过几个TB数据的最佳方式。让我们看看如何从一个小的单节点数据库，扩展到一个包含几个TB数据的四个分片，最后扩展到一个跨768台服务器分片并存储一个PB数据的数据库。成长的烦恼 为了理解为什么分片是扩展关系数据库的必要部分，我们必须了解较少可扩展方法的瓶颈。首先考虑一个简单的应用程序架构。你使用过的大多数应用程序都是这样运作的，或者至少在其存在初期是这样的。运行于客户端设备上的软件通过互联网连接到应用服务器。该应用服务器位于数据中心，处理身份验证、页面加载以及应用程序行为的所有服务器端逻辑。所有持久化数据，例如用户帐户、帖子、设置和消息都会存储在数据库服务器中并从中检索（其中“数据库服务器”通常是Postgres或MySQL，尽管本文关注的是Postgres）。即使是较大的数据库服务器（数十个CPU核心，数百GB的RAM），瓶颈很快就会出现。通常，由于查询量大，会出现CPU限制，或者由于读取和写入量大，会出现I/O限制（IOPS）。这一点由普遍可扩展性法则很好地总结：简而言之，USL指出，资源争用导致可扩展性随着资源增加而以小于线性的速度增长，并且在某一点上，不一致性会导致性能下降。这对于Postgres以及任何试图在更大服务器上跨多个线程或进程扩展的软件系统都是适用的。解决此问题的一种方式，至少在短期内，是利用只读副本。在这种配置中，你保持原始服务器作为主服务器，并添加额外的副本。如上所示，主服务器向每个副本发送持续的数据更新消息，以确保它们与主服务器的数据变化保持同步。写入操作（INSERT、UPDATE、DELETE）只能到达主服务器。如果允许向任何服务器写入数据，我们可能会遇到冲突的数据。解决这个问题需要复杂且缓慢的一致性算法，这是可能的，但在大多数情况下并不理想以获得最佳性能。然而，应用服务器可以将读取（SELECT）查询发送到副本。由于大多数应用程序的读取量远远大于写入量，因此这提供了更多的可扩展性。（即使查询流量不需要，副本对于高可用性和数据持久性也是必要的。）通过添加副本，数据库可以扩展以处理更多流量。这方面的一个极端例子是OpenAI在单个主服务器上使用50个副本。事实证明，垂直扩展服务器（增加CPU / RAM）和添加副本只能解决到一定程度。有几个瓶颈无法通过这种方式解决：1）写入限制在一台服务器上。随着写入量的增加，任何数量的只读副本都无法缓解该问题。在Postgres确认一个已提交的写入之前，它必须在其预写日志（WAL）中记录变化，并将该日志刷新到持久存储中。WAL是所有连接共享的资源，这本质上是你整个数据库中的单一写入瓶颈，即使你有数十个副本。2）副本不增加数据容量。副本是主服务器数据的完整副本，包括所有索引。添加副本给我们提供了更多的读取位置，但不分散数据。3）备份。备份是数据持久性以及RPO / RTO保证的重要部分。由于节点与存储之间通信的带宽限制，备份一个大型单体数据库到对象存储可能需要几个小时甚至几天。对于依赖于频繁且验证备份的许多组织来说，这是不可接受的。处理此问题的最有效方法是分片。分片，带有“d”。分片通过在许多不同的主服务器之间分配数据和查询来解决这三个瓶颈。对于数据而言，它是有用的，因为单一节点的存储限制和写入吞吐量有限。对于查询而言，它是有用的，因为网络互连和CPU只能同时处理一定数量的查询。分片在超过几个TB数据的所有规模上都是有效的。例如，对于2TB的数据，我们可能会选择一个具有四个分片的设置，每个分片存储500GB…