0

g我正在开发一个具有以下结构的 Web 应用程序：我们有“客户”，每个客户都有自己的“用户”。每个客户（以及他的用户和其他数据）都与其他客户完全分离，并且他们之间没有共享数据。
此外，每个“客户”都有不同的子网站，所有来自那里的查询（无论是他还是他的用户）都将始终引用一个 customer.id

数据库按以下方式构建：

CREATE TABLE `customer` ( 
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT 
) ENGINE=InnoDB; 

CREATE TABLE `user` ( 
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
  `customerID` int(11) unsigned 
) ENGINE=InnoDB; 

CREATE TABLE `blogPost` ( 
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
  `userID` int(11) unsigned 
) ENGINE=InnoDB;

我有很多表，比如“blogPost”，它们通过用户连接到客户。

一个常见的查询是这样的：

SELECT *  
FROM `blogPost` bp 
INNER JOIN `user` u 
ON bp.userID=u.id 
WHERE u.customerID = 324

值得注意的是，这些连接很昂贵而且真的没有必要——因为当我们进入一个子网站时，我们只对连接到特定客户的数据感兴趣

所以问题是如何改进数据库？我对这个主题阅读得越多，我就越困惑——NDB
（MySQL 集群）存储引擎是要走的路吗？
是否最好为每个客户创建许多不同的数据库？也许添加一个冗余customerID字段blogPost？还有什么想法？MongoDB？！

4

2 回答 2

0

所以问题是如何改进数据库？

是的，连接很昂贵。特别是如果（正如您的 create table 语句所暗示的那样）您没有索引。如果确实如此，那么您必须添加索引，至少在主键和外键上。（我还注意到，根据您的设计，您不会为博客文章存储任何内容？真的吗？

一个常见的查询是......

真的吗？如果您的查询没有实现任何类型的过滤，那么您的应用程序就会出现问题。如果过滤被实现为分页并且数据很少被删除/更新，那么每个外键序列号将比全局自动增量 ID 更有效。

是否最好创建许多不同的数据库

绝对不。

当然，如果您的物理设备将 I/O 分布在不同的磁盘上会提高 I/O 性能（假设您的 DBMS 配置正确并且您的热数据集太大而无法放入内存）在这种情况下您应该考虑在不同的磁盘上交错索引和数据文件和/或使用 MySQL 内置的跨文件系统分片支持。

也许在 blogPost 中添加一个多余的 customerID 字段

也许。

集群对于可用性和性能来说是一个非常好的想法 - 但它会带来设置和保持运行所需的技能和时间方面的开销。你现在当然不应该看 NDB - 在你用尽了调整单个实例的范围之后，看看同步和异步复制。

首先添加索引，然后调整您的 DBMS 配置，然后尝试将 customerID 添加到博客文章中，然后查看文件是如何在您的存储中分布的（这看起来像是 SSD 的一个很好的用例）。

于 2013-03-21T09:11:55.727 回答
0

首先让我们清理 NDB 引擎，MySQL Cluster / NDB 不是这里的方法，它不仅没有提供任何有助于你的情况的东西，它实际上使它更复杂。您不仅需要大量资源和至少 3 个数据库服务器来运行 NDB，诸如 JOINS 之类的东西在 NDB 中仍然不是很好——只是不要去那里。

连接表没有任何问题，RDBMS 旨在有效地做到这一点。如果您要加入外键索引，这将既快速又高效。您在这里尝试做的是绝大多数网络数据库每天处理的事情，并且其中大多数将信息连接在一起。

您可以为每个客户使用一个数据库，但请相信我，这将大大增加您的数据库管理工作，如果您出于业务原因等原因确实不必走这条路，请不要这样做。当架构更改发生并且客户 x 有性能问题但客户 y 没有时，这是一场噩梦 - 你最终会给自己带来很多工作

于 2013-03-21T08:54:23.597 回答