Question

当前设计：

Table: users
------------------------------
| id | email                 |
------------------------------  
| 1  | abc@xyz.com           |
| 2  | def@mno.com           |
| 3  | fun@ton.com           |


Table: user_notes
-----------------------------------------------------
| id | user_id  | content     | created_at          |
-----------------------------------------------------
| 1  |    1     | loreum ipsu | 2017-01-01 10:00:00 |
| 2  |    1     | loreum ipsu | 2017-01-02 11:00:00 |
| 3  |    2     | loreum ipsu | 2017-01-03 12:00:00 |

拟议设计：

Table: users
------------------------------
| id | email                 |
------------------------------  
| 1  | abc@xyz.com           |
| 2  | def@mno.com           |
| 3  | fun@ton.com           |

Table: user_1_notes
------------------------------------------
| id | content     | created_at          |
------------------------------------------
| 1  | loreum ipsu | 2017-01-01 10:00:00 |
| 2  | loreum ipsu | 2017-01-02 11:00:00 |

Table: user_2_notes
------------------------------------------
| id | content     | created_at          |
|-----------------------------------------
| 1  | loreum ipsu | 2017-01-01 10:00:00 |

我之所以提出这种设计，是因为我发现我们的MySQL服务器（1 user_notes表中的大约1亿行之后，CPU 3.7GB的Google CloudSQL速度）变得非常慢，而且我们可以创建近40亿个表。

我们可以提高实例的性能，这肯定会提高性能，但是我们没有预算。我尚未进行性能测试。但是我认为最好咨询专家社区

关于上述设计的优点和缺点。

另外，如果我有预算，请指导我，那么实现相同的最佳方法是什么

只是加强MySQL服务器
或其他...

已更新

慢速查询（1分23秒）

SELECT * FROM user_tables WHERE user_id=2 AND DATE(created_at) >= '2017-01-01' AND DATE(created_at) < '2017-02-01'

注意：

我对user_notes表的所有查询将始终像WHERE user_id=XXX
我不必同时查询2个或更多用户

Answer 1

1。您当前的设计要比拟议的设计好得多

2。我的建议是，如果您有预算，那么只需增加MySQL服务器

3。我不认为为此目的而进行技术变革是明智的决定

Answer 2

您有user_id的索引吗？也许你可以从那里开始。

建议的设计可能不是一个好主意，无论您使用MySQL，MongoDB还是其他解决方案。

例如，在MongoDB上，您应尽可能嵌入文档，这意味着您可能会选择以下更好的方法：

Collection: users
{
  id: 1,
  email: abc@xyz.com,
  notes: [
    {
      content: 'loreum ipsu',
      created_at: '2017-01-01 10:00:00'
    },
    ...
  ]
}

然后，根据每个用户有（可能很多）笔记的数量，您必须知道文档大小的限制（16MB，我上次听到）。因此，也许您当前的设计可能还不错。

如果您最终还是走了那条路线，MySQL现在也有一个类似于MongoDB的文档存储offering，但是，我不确定Google Cloud是否支持它（我认为不是）。因此，最终，也许您不需要“转向其他技术”。

免责声明：我在MySQL工作（但我不是架构设计专家）

我们应该将数据拆分成MySQL中即时创建的表还是与其他DBMS一起使用？

2 个答案: