【问题标题】:one database per client or all clients in one database. which one should I use for a online application?每个客户端一个数据库或一个数据库中的所有客户端。我应该使用哪一个进行在线申请?
【发布时间】:2012-02-01 00:56:47
【问题描述】:

所以我有这个应用程序,它有多个模块,从项目管理到会计模块。 问题是我应该每个客户(公司)拥有一个数据库还是一个包含所有内容的数据库?

1) 哪个性能更好?
2) 管理多个数据库将变得更加困难,或者这些数据库是否易于管理。
3) 我们将为所有用户提供相同的应用程序,这意味着无论数据库数量如何,都将使用相同的模式。
4) 一些客户将有很多这样的数据(例如,会计师可能在一个表中每年添加多达 200 万行),而另一些客户将使用更少的数据。

你觉得我应该用什么?

【问题讨论】:

标签: mysql database-design multi-tenant


【解决方案1】:

1) 拥有独立的数据库可以更轻松地在多个主机上分配负载,它在许多方面都起到了提升作用;磁盘、内存、锁定、cpu、备份时间等。如果您真的想在 mysql 中放入数百万行,那么使用单独的数据库(不仅是模式)甚至单独的实例肯定是一个好主意,这样资源消耗的客户就不会将停机时间强加给资源消耗较少的客户。

2) 在 N 是数据库数量的情况下,管理起来会困难 N 倍.如果您必须致电托管公司的客户支持,甚至您当地的脾气暴躁的 dba,而不是每次需要更新架构或创建新数据库时都从控制台运行一个简洁的脚本,这本质上也更难管理。

一些数据库和持久性框架支持多租户,Oracle 支持,并且在 Hibernate 4 中开始出现支持。

尽管许多论据指向不同数据库的方向, 通常也可以只使用一个数据库。

【讨论】:

  • 1) 是的,我们已经有一些用户使用旧应用程序,他们每年创建大约 200 万行(尤其是会计师)。 2)这个问题是如何确保在我运行脚本时所有数据库都已更新?
  • @redmoon7777 好吧,这完全取决于您,就像您在一个多租户数据库中保证数据分离一样。
  • 你是对的。我一直在四处寻找几天我仍然找不到“正确”的答案。现在我倾向于使用多个数据库。
  • @redmoon7777 只要你不依赖别人来管理数据库,至少这样不会错。但这可能有点矫枉过正,您的里程可能会有所不同......
【解决方案2】:

理论上,多个数据库的性能会更好。也就是说,如果您可以将它们放在单独的磁盘控制器上。但实际上它们很可能都在同一个磁盘上,因此可能不会有性能提升。此外,额外的磁盘更适合用作 RAID 阵列的额外成员,而不是作为可以卸载数据的额外独立逻辑磁盘。

从维护的角度来看,多个数据库将是一场噩梦。对数据库的每次 ALTERation 都需要进行 N 次,其中 N 是客户端的数量。当然,您永远不会手动执行此操作,因此您将始终必须以编程方式执行此操作,并且很快您就会开始体会到,如果您只需在管理控制台上单击几下即可执行相同的 ALTERations,而不是每次都必须为您编写代码。

【讨论】:

  • 你是对的,但是数据库管理是使用多个数据库的唯一问题吗?
  • 好吧,如果您打算执行任何跨数据库查询,拥有多个数据库并不是很方便,但我认为如果确实必须这样做,可以这样做,所以这不是一个炫耀。
  • true,这会影响脚本一次在所有客户端上收集数据。
  • 对,但这可能是您最不关心的问题。
  • 通常您想要以编程方式管理更改(sql 脚本),即使只有一个模式。版本控制是一个原因,更好的控制是另一个原因。
【解决方案3】:

如果您不使用单独的数据库,那么安全性将是一个真正的负担,不管有什么其他问题。您必须对编码非常谨慎,以确保一家公司不会看到(或修改或删除)其他公司的数据。

【讨论】:

  • 只要数据库位于一组脚本之后并且不直接暴露给客户端,确保数据安全并不是那么难。
  • 除了信任代码之外,我更希望有一些其他机制来强制访问数据,尤其是在使用熟练程度可疑的雇佣编码人员时。
  • redmoon7777,我没有关于这两种方法的相对性能的数据。我只是说这一考虑可能胜过其他任何考虑。
  • 我同意,所以您认为(添加)安全性胜过多个数据库维护?
  • 是的,正如 MikeNakis 所指出的,您可以对数据库进行脚本修改。如果编程错误危及您客户的数据,没有什么能拯救您。
猜你喜欢
  • 2017-05-03
  • 2023-03-09
  • 2011-02-17
  • 1970-01-01
  • 1970-01-01
  • 2015-05-09
  • 2011-09-08
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多