MySQL体系结构优化- MySQL群集

Question

gI正在开发一个具有以下结构的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群集)存储引擎是可行的吗？

创建多个不同的数据库-每个客户一个数据库-是否更可取？也许可以在blogPost中添加一个冗余的customerID字段？还有其他想法吗？MongoDB ?！

Answer 1

首先，让我们清理一下NDB引擎，MySQL集群/ NDB不适合这里，它不仅没有提供任何对您的情况有帮助的东西，而且实际上使它变得更加复杂。你不仅需要大量的资源和至少3台数据库服务器来运行NDB，像JOINS这样的东西在NDB中仍然不是很好--就是不要去那里。

连接表没有错，RDBMS的设计就是为了有效地做这件事。如果您是在外键上连接索引，那么这将是既快速又有效的。您在这里尝试做的是绝大多数web数据库每天处理的内容，并且它们中的大多数将信息连接在一起。

您可以为每个客户使用一个DB，但相信我，这将极大地增加您的数据库管理工作，如果您真的不需要因为业务原因而走这条路，请不要这样做。当模式发生更改时，当客户x有性能问题而客户y没有问题时，这将是一场噩梦--您最终会给自己带来很多工作

Answer 2

所以问题是我怎样才能改进数据库？

是的，Join是昂贵的。尤其是在没有索引的情况下(如create table语句所暗示的)。如果确实是这样，那么您必须添加索引，至少在主键和外键上是这样。(我还注意到，根据您的设计，您不会为博客帖子存储任何内容？真的？

常见的查询应该是这样的：

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

创建许多不同的数据库是否更可取

绝对不是。

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

可能会向blogPost添加冗余的customerID字段

也许吧。

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

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