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

KM.*_*KM. 15 mysql database-design

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

设置“A”:

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen
Run Code Online (Sandbox Code Playgroud)

最终结果是一个包含许多表的大数据库。

设置“B”:

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen
Run Code Online (Sandbox Code Playgroud)

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

所有条件都相同(例如,数据量、应用程序实例数量等),使用这两种方法的优缺点是什么?什么会对数据库性能和维护有害?该应用程序基于 PHP 5,在 Apache 2.x 上运行,我们运行的是 MySQL 5.x。

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

Dav*_*Rix 14

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

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

这样做的好处是,您可以按照自己的速度将服务器添加到配置中,因为每个服务器开始过载,添加另一个服务器,将一些 dbs 迁移到新服务器并最终得到一个很好的负载平衡的一组服务器。一种在需要时为系统添加规模的非常好的和简单的方法!

我采用这种方法而不是单一的庞大数据库方法的原因是,本来可以创建的潜在数据库的庞大规模...... 1000 个数据库中的每一个都有 200 个表,并且每个数据库中的许多单独的表数据库包含数亿行数据!

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

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


Dha*_*DK' 11

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

另请参阅Microsoft 撰写的有关多租户数据架构的出色白皮书

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


Rol*_*DBA 9

设置 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 可以按需分配。
  • 警告:非常不鼓励 InnoDB

打个比方,你更喜欢哪个?

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

在公寓中安装散热器时:

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

IHMO 虽然预算可能是设计/基础设施决策的驱动力,但我很容易支持每个客户单独的数据库。