主页 / dba / 问题 / 7924
Accepted
KM.
Asked: 2011-11-16 13:16:53 +0800 CST

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

  • 772

我们有一种情况，我们可以 (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 上运行，我们正在运行 MySQL 5.x。

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

mysql database-design

4 个回答

  1. Best Answer

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

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

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

    我采用这种方法而不是单一的大型数据库方法的原因是，将要创建的潜在数据库的绝对大小...... 1000 个数据库中的每一个都有 200 个表，并且每个数据库中的许多单独的表数据库包含数亿行数据！

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

    这就是我会做的！希望它对您的决策有所帮助... :)

    • 15

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

    另请参阅 Microsoft 关于多租户数据架构的这篇出色的白皮书

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

    • 11

  3. 设置 B 更易于管理

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

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

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

    从操作系统的角度来看，它处理 i 节点（或 Windows 的 FAT 表）的能力，包括每个文件夹的最大文件数：

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

    如果您必须使用ALTER TABLE或其他一些 DDL 来调整表结构：

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

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

    • 在设置 A 下，将每个表的符号链接移动到单独的磁盘只会加剧“文件夹中的 inode 数量”问题。.frm由于重复访问文件，磁盘 I/O 和整体表访问变得更加复杂并增加了整体服务器负载。
    • 在设置 B 下，只需将整个数据库文件夹移动到单独的数据装载中。磁盘 I/O 可以按需分配。
    • CAVEAT :对于 InnoDB 非常不鼓励

    打个比方，你更喜欢哪个？

    • 一间卧室，一间浴室和一间厨房的巨大公寓（SetupA）
    • 多套公寓，每套都有自己的卧室、浴室和厨房 (SetupB)

    在公寓中修理散热器时：

    • 使用设置 A，每个租户都可能会感到不便，并且必须参与其中，因为您必须在每个人面前与受影响的租户交谈，就像每个人的事一样
    • 使用设置 B，除了听到一些敲打墙壁或管道的声音外，租户可以继续他们的私人生活
    • 这个列表及其隐喻可以继续下去

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

    • 9

  4. 我也有一个 SaaS 产品并使用与 Dave Rix 提到的相同的设置。

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

    我再提几点建议：

    • 您应该有一个负载平衡的数据库“控制器”（master-master），它存储数据库位置（ip）、数据库名称和客户名称。这个控制器是您的应用程序知道每个客户数据库在哪里的地方。

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

    • 您的应用程序可以随心所欲地增长。如果它是一个 Web SaaS，您可以创建一个负载平衡的 Web 服务器群，指向每个数据库，就像客户登录一样。

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

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

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

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

      例如，5 个主服务器 + 1 个从服务器，5 个数据库在不同的端口上运行——只要有足够的 RAM 就可以了。

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

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

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

    • 您必须有一个数据库映像，您可以在其中导出并用于新帐户。

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

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

    好吧，这就是我在公司中所做的所有事情，该产品有大约 5k 个数据库，每个数据库大约有 600 个表。

    • 3

相关问题