一个大数据库与几个小数据库

我们有一种情况，我们可以（A）使用表前缀在一个MySQL数据库中部署应用程序实例，或者（B）对应用程序的每个实例使用不同的MySQL数据库，例如，

设置“ A”：

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

最终结果是具有许多表的大型数据库。

设置“ B”：

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

最终结果是许多数据库带有某些表。

在所有条件都相同的情况下（例如，数据量，应用程序实例数等），采用这两种方法的利弊是什么？什么会对数据库性能和维护造成不利影响？该应用程序基于PHP 5，可在Apache 2.x上运行，而我们正在运行MySQL5.x。

非常感谢您的时间和想法！

我运行了一个系统，其中最好的部分是一千个数据库，分布在多个服务器上。它们都是相同的结构，并且与每台计算机上的模板数据库同步。

这使我能够将数据库从一个数据库迁移到另一个数据库，如果一个数据库过度地过载，并且随着客户端组合的变化，我可以在不同的服务器上创建新的数据库以在服务器之间实现负载平衡。这是我从系统中获得的最大优势，因为我有多个大块锡，可以在单独的服务器上同时执行多个复杂的查询。

这样做的好处是，您可以按照自己的速度将服务器添加到配置中，因为每台服务器开始超载，将另一台服务器添加到混合中，将一些数据库迁移到新服务器上，最终得到不错的结果负载均衡的服务器集。在需要时向系统增加规模的一种非常好用且简单的方法！

我之所以采用这种方法，而不是使用单个大型数据库方法，是因为将要创建的潜在数据库的庞大规模... 1000个数据库中的每个数据库都有200个表，并且每个数据库中都有许多单独的表数据库包含数亿行数据！

一个数据库配置将需要某些表（其中约8个）具有数十亿行的数据，并且总数据库大小将超过10Tb。我们能够拥有多台具有5Tb RAID 10存储的服务器，每个服务器上都有许多数据库。

那就是我会做的！希望它有助于您的决策... :)

您正在构建的应用程序是SaaS应用程序吗？如果是这样，我建议您考虑第三种方法-拥有一个数据库，所有应用程序实例具有相同的结构，但有所不同-在所有表中添加一个userid / applicationid列。这将大大降低您的应用程序开发/维护成本。以我的经验，这是存储多租户数据的最佳方法之一。

也看到这个 Microsoft关于多租户数据体系结构的白皮书

它还强调了您提到的方法的优缺点。

设置B更易于管理

每个都tablen位于不同的文件夹中。如果您不想测试操作系统限制，那将是非常有益的。

例如，我的雇主为汽车经销商的CRM系统托管MySQL。客户有800家经销店。每个经销商数据库都有160个表。那是128,000张桌子。

• 在设置A下，所有128,000个表都将位于一个数据库下。
• 在设置B下，每组160张表位于/ var / lib / mysql下的子文件夹中。

从操作系统及其处理索引节点（或Windows的FAT表）的能力的角度来看，这包括每个文件夹具有最大数量的文件：

• 在设置A下，您可能会担心一个文件夹下有128,000个文件。您的操作系统可以在一个文件夹中支持那么多文件吗？
• 在设置B下，无需担心。

如果必须使用ALTER TABLE或其他DDL 来对表结构进行tweek操作：

• 在设置A下，您必须使用PHP（或专用的MySQL脚本）针对特定的表名和相应的查询编写所需的DDL脚本，然后再访问它并进行更改
• 在设置B下，连接到正确的数据库，然后每次访问相同的命名表。访问范例始终是干净的：
  • 特定数据库
  • 下的特定文件夹 /var/lib/mysql
  • 特定的TableName。

如果要将不同的数据库放在不同的磁盘上：

• 在设置A下，每个移到单独磁盘的表的符号链接只会加剧“文件夹中的索引节点数”问题。磁盘I / O和整体表访问使问题更加复杂，并增加了整体服务器负载，因为.frm重复访问文件，。
• 在设置B下，只需将整个数据库文件夹移动到单独的数据装载中即可。磁盘I / O可以按需分配。
• CAVEAT：强烈建议不要使用InnoDB

隐喻地说，您希望拥有哪一个？

• 一间带一间卧室，一间浴室和一个厨房的巨型公寓（SetupA）
• 多个公寓，每个公寓都有自己的卧室，浴室和厨房（SetupB）

在公寓中安装散热器时：

• 使用设置A，每个租户都会感到不便，必须参与其中，因为您必须在每个人面前与受影响的租户进行交谈，就像每个人的工作一样
• 使用设置B，除了可以听到墙壁或管道上的撞击声之外，租户还可以继续自己的私生活
• 这个清单及其隐喻可以持续不断

IHMO尽管预算可能是设计/基础架构决策的驱动力，但我很容易赞成为每个客户分配单独的数据库。

我也有SaaS产品，并使用与Dave Rix相同的设置。

每个客户都有自己的数据库

我还会提出一些建议：

• 您应该具有负载均衡的数据库“控制器”（主-主），该数据库存储数据库位置（ip），数据库名称和客户名称。该控制器是您的应用程序知道每个客户数据库所在位置的地方。

• 您的应用程序可以在任何您想要的地方-您可以拥有全球许多数据中心的数据库。

• 您的应用程序可以根据需要增长。如果是Web SaaS，则可以创建负载平衡的Web服务器场，以指向每个数据库的时间作为客户登录的时间。

• 您可以为某些客户创建自定义的VIEW /数据库-而不会影响其他客户。如果您尝试提供自定义作为业务的一部分，那很重要。

• 您可以设置两个Web场+数据库场：一个用于“ EDGE”版本，另一个用于“ STABLE”版本。然后，在向所有客户申请之前，您需要有一小部分客户愿意测试并确认一切都按预期进行（换句话说，质量保证[QA]）。

• 您应该每天至少对每个数据库执行一次自动备份作业。

• 您应该有另一台服务器进行复制。如果您负担不起相同数量的“主”和“从”主机服务器，则同一台主机可以复制许多数据库（对于同一主机上的每台服务器使用不同的端口）。

  例如，5个主服务器+ 1个从属服务器，其中5个数据库在不同的端口上运行-仅具有足够的RAM即可完成此任务。

• 您应该使用“迁移”工具随时将一个数据库移动到另一台服务器。

• 您应该将VIP客户迁移到更安全/可用的数据库服务器，以保护您的收入。请记住，很多时候20％的客户代表您收入的80％。照顾特殊的顾客。

• 您应该有一个备份删除“垃圾”收集器，以进行“最后备份”并在客户离开公司时删除数据库。

• 您必须具有用于导出和用于新帐户的数据库映像。

• 您必须具有数据库修补工具才能将新修补程序应用于现有帐户。

• 使用Subversion或git等版本控制工具保留所有SQL补丁的版本，并创建自己的编号。xxx-4.3.0.sql-有时修补出错，并且您必须知道如何恢复/完成修补任务。

好吧，这是我在公司中所做的所有工作，该产品具有约5000个数据库，每个数据库约有600个表。