每个客户端拆分 mysql 数据库答案

【问题标题】：Splitting mysql database per client每个客户端拆分 mysql 数据库
【发布时间】：2011-03-31 14:20:08
【问题描述】：

我正在开发一个相对较小的数据库。它总共有 67 个表，有超过一百万条记录。它大约为 254 MB。与它一起工作的应用程序已经运行了大约 5 年，使用量每年翻一番。今年我们预计将增加三倍，这将使一个赛季的数据库规模几乎翻倍。我的问题是，将数据库拆分为多个数据库是不是一个坏主意。假设我们有 300 个客户端，它将创建 300 个单独的数据库，其中包含 67 个表，但只包含与该客户端相关的数据。除了可以在不同服务器上执行的内部统计数据之外，没有太多理由将数据放在一起。我们在其生命周期内不应超过 10,000 个客户。

当我们需要对“主数据库”架构进行更改时，我看到此设置存在的问题，它需要在所有“从属数据库”中复制更改

添加新客户端时，复制也是一个挑战。

代码级别的应用程序几乎是为这种类型的设置设置的。

我有什么遗漏吗？这是一个可怕的想法吗？

数据库是仓促（不是我）创建的，没有考虑未来，现在是我的责任。

就规范化、字段类型审计、sql 优化、索引和服务器调优而言，还有很多工作要做。任何反馈将不胜感激。

【问题讨论】：

标签： mysql database database-design relational-database mysql-management

【解决方案1】：

“规范化、字段类型审计、sql 优化、索引和服务器调优”让您忙得不可开交

没有充分的理由将其拆分为 300 个数据库。还有很多很好的理由不这样做，你已经阐明了。只要CustomerId通过数据库明确区分Customer数据就可以了。

所以做你必须做的事，不要给自己更多完全不必要的工作。

当数据库规模大、速度差时，转移到真正的 SQL 平台。

【讨论】：

【解决方案2】：

目前您拥有四分之一的数据。你设想它今年翻一番（半场演出）。是1997年吗？不，现在是 2010 年，人们在手机上拥有千兆字节的数据。

所以问题是，您要解决什么问题？它不能是存储，因为那是微不足道的数据量。如果它的性能，那么我认为拆分成多个数据库可能会使事情变得更糟，除非你设想每个数据库都有一个服务器。从安全角度来看，有一种观点认为需要单独的数据库，但有不同的方法可以解决这些问题。

您当前的环境有问题吗？或者至少有趋势表明您在十二个月内可能会遇到问题？如果没有，那就坐稳。如果是，请清楚地制定它们，然后弄清楚 300 个数据库将如何解决这些问题，以及它们是否值得不可避免的悲伤。然后重新校准该悲伤以考虑 10000 名用户并再次提出问题。

可能有一些问题的最佳答案是“一万个数据库”，但不是很多。

“我们最大的客户增加了大约12000 每年的记录。 "

换句话说，大约每十个工作分钟记录一条记录（假设一天八小时）。这似乎不是一个大的写入负载。

“这个想法是而不是客户去通过所有数据，它只是访问他们的数据。”

但这不是很多数据，当然也没有什么是体面的索引策略无法解决的问题。

我仍然不明白您是否现在遇到了真正的问题，或者您只是在考虑将来某个时候可能会出现问题的事情。

【讨论】：

问题在于性能。我们最大的客户每年增加大约 12000 条记录。而我们的平均客户每年大约有 1000 条记录。这个想法是客户端浏览所有数据，它只是访问他们的数据。正如您所说的那样，这会如何使性能变得更糟。
如果您发现记录数量相对较少（是的，12k 是 SMALL）的性能问题，您应该考虑重构查询以提高效率。

【解决方案3】：

我的问题是如何访问数据库？每个客户端是否安装一个应用程序？如果是这样，那么将数据库分开可以在升级应用程序时为您赢得一些时间（因为您只需要在更新应用程序时更新数据库）。如果它们被一个应用程序安装访问，请将它们放在一起。

但还有其他考虑因素。您提到今天的大小是 100 万行 @ 256 MB。这应该很容易在商品服务器的范围内。因此，如果您预计最坏情况下每年会增长 5 倍，那么您说的是今年 500 万行，接下来是 25 个，第三个是 125 个，第四个是 625 个，第五个是 31.25 亿行。即使是 30 亿行（取决于查询的确切用法和类型）对于 MySQL 来说也不是那么难处理（仍然在商品服务器的上限范围内）......

另外，如果您开始遇到问题，您总是可以在 client 键上 partition 每个（或只是主要表）...它由 MySQL 自动为您管理，所以您没有自己管理它们的维护噩梦......

【讨论】：

它是一个网络应用程序。然后将对测试客户端进行更改，然后进行部署。
对，但是 Web 应用程序只有一个实例，对吗？这意味着只有一个网站可以访问所有数据（而不是为每个客户创建不同的网站）...

【解决方案4】：

修改当前架构以接纳多个客户端，如果在到达第 n 个客户端时性能受到影响（并且 SELECT 优化没有帮助），您可以添加新服务器。在我们的例子中，我们将数据按“站点”划分，因此一个用户无法访问不在其站点上的数据。

【讨论】：

【解决方案5】：

让我们看看 SAP ERP。它可能拥有数千个客户和数十亿个记录器。它是可靠的电力系统。并且其中的所有表（系统表除外）都有一个指定客户端的“MANDT”字段。 Offcource SAP 通常与 ORACLE 一起使用，但在您的情况下，由于数据量很小，它还不够。
因此，根据 SAP 的成功历史和关于 MySQL 作为良好 DBMS 的好意意见，我可以得出结论，您不应该在客户端之间溜走 DB。这不会产生太多

【讨论】：