当前设计:
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 cpu 3.7GB谷歌CloudSQL)在user_notes表中大约1亿行之后变得非常慢,而且我们还可以创建将近40亿个表。
我们可以增加实例,这肯定会提高性能,但我们没有预算。我还没有进行性能测试。但我觉得最好还是问问专家
另外,如果我有预算的话,那么最好的方法是什么呢?
更新
慢查询(1分23秒)
SELECT * FROM user_tables WHERE user_id=2 AND DATE(created_at) >= '2017-01-01' AND DATE(created_at) < '2017-02-01'注意:
WHERE user_id=XXX发布于 2018-07-27 07:57:26
1.你目前的设计比建议的设计要好得多
2.我的建议如果你有预算的话,那就把MySQL服务器放大
3.我不认为为了这个目的,技术变革是明智的欺骗
发布于 2018-07-27 09:18:54
你有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'
},
...
]
}然后,根据每个用户的注释数量(可能很多),您必须知道文档大小的限制(上次我听到的是16 of )。所以,也许你目前的设计可能不会那么糟糕。
但是,如果您最终选择了这条路线,那么MySQL现在也有一个类似于MongoDB的文档存储库供品,但是,我不确定Google是否支持它(我不这么认为)。因此,最终,也许你不需要“转向其他技术”。
免责声明:我在MySQL工作(但我不是模式设计专家)
https://stackoverflow.com/questions/51553202
复制相似问题