Database design 高可用性与数据库设计

长期以来，这是我心中的一个问题。 Facebook或拥有超过一亿用户的任何此类网站/应用程序如何维护其数据库

我相信不能把所有的东西都放在一个数据库中。 如果是这种情况，是否应该有多个数据库处理不同的部分？不同的部分，比如：一个状态数据库，一个照片数据库和一个用户数据库

数据库模式能否成为关系模式

5亿多用户，如果平均一个用户有10条文本更新，则会增加50亿行（至少），这应该是Facebook实际处理数据的10%。

---

我在某个地方读到Facebook有1800多个sql实例，其中有800多个是memcached。这些数据库实例是否应该相同？这些是如何设计的？

Facebook和其他拥有大型数据库的大公司采用

分区是将一个表分布在多个子表上，这些子表可能位于不同的数据库或服务器上，以提高读/写性能。SQL Server分区通常在表级别完成，当相关表组已分发时，数据库被视为已分区。表通常是水平分区或垂直分区

水平分区（也称为）提高了总体读/写性能

水平分区涉及将不同的行放入不同的表中。邮政编码小于50000的客户可能存储在CustomerEast中，而邮政编码大于或等于50000的客户则存储在CustomerWest中。这两个分区表分别是CustomerEast和CustomerWest，而可以在这两个分区表上创建一个具有联合的视图，以提供所有客户的完整视图

水平分区是一种数据库设计原则，其中数据库表的行是分开保存的，而不是按列进行拆分（用于规范化）。每个分区构成一个分片的一部分，分片可以位于单独的数据库服务器或物理位置

这种分区方法有许多优点。每个表中的行总数将减少。这会减少索引大小，这通常会提高搜索性能。一个数据库碎片可以放在单独的硬件上，多个碎片可以放在多台机器上。这使得数据库能够分布在大量机器上，这意味着数据库性能可以分布在多台机器上，从而大大提高了性能。此外，如果数据库碎片基于数据的某些真实分割（例如，欧洲客户与美国客户），则可以轻松自动地推断适当的碎片成员资格，并仅查询相关碎片

切分实际上远比这困难。虽然很长一段时间以来都是通过手工编码完成的（尤其是在行具有明显分组的情况下，如上面的示例所示），但这通常是不灵活的。人们希望自动支持分片，包括为其添加代码支持，以及识别要单独分片的候选对象

如果使用分布式计算在多台服务器之间分离负载（出于性能或可靠性原因），则分片方法也可能有用

与水平分区相比的碎片

水平分区按行分割一个或多个表，通常在模式和数据库服务器的单个实例中。它可以通过减少索引大小（从而减少搜索工作量）提供优势，前提是有某种明显、稳健、隐式的方法来确定将在哪个表中找到特定行，而无需首先搜索索引，例如“CustomerEast”和“CustomerWest”表的经典示例，他们的邮政编码已经指明了他们的位置

切分超越了这一点：它以相同的方式对有问题的表进行分区，但它可以跨模式的多个实例进行分区。明显的优势是，现在可以跨多个服务器（逻辑或物理）拆分大型分区表的搜索负载，而不仅仅是同一逻辑服务器上的多个索引

跨多个孤立实例拆分碎片需要的不仅仅是简单的水平分区。如果查询数据库需要查询两个实例，只是为了检索一个简单的维度表，那么所希望的效率增益将丢失。除了分区之外，切分还可以在服务器之间分割大型可分区表，同时将较小的表整体复制到这些表中

这也是分片与无共享体系结构相关的原因——一旦分片，每个分片都可以位于完全独立的逻辑模式实例/物理数据库服务器/数据中心/大陆中。不需要保留对其他分片中其他未分区表的共享访问（从分片之间）

这使得跨多个服务器的复制变得容易（简单的水平分区无法做到）。它还适用于应用程序的全球分布，否则数据中心之间的通信链路将成为瓶颈

显然，模式实例之间还需要某种通知和复制机制，以便未分区的表保持与应用程序要求的同步。在分片系统的体系结构中，这是一个复杂的选择：方法包括使这些有效的只读（更新很少且成批进行）、动态复制表（以减少分片的一些分发好处为代价）以及中间的许多选择

垂直分区改进了对数据的访问<