-1

我开始考虑我的新项目，我发现了一些速度问题，所以我希望你能帮助我选择一种好的和优雅的编码方式。

每个用户在数据库中都有他访问过的“地方”的记录。每个地方都有“学校”——这个特定地方的许多学校。每个学校都有课。每个班级可能在不同的时间结束其“学习年”，因此如果日期 >= 学习年结束，则​​其数字应递增。

所以我们有这样一个数据库：

“地方”表：

place | user_id | 
----------------- 
1     |   4     |
2     |   4     |

4 号用户访问了 1 号和 2 号地点

“学校”表：

school | place |
----------------
5      |   2   |
6      |   2   |

Place 2 有两所学校 - id 5 和 6。

“类”表：

class | school | end_learning | class_number
---------------------------------------------
20    |   5    | 01.01.2013   |   2
21    |   5    | 03.01.2013   |   3
22    |   5    | 05.01.2013   |   4

学校 5 有 3 个班级，ID 为 20、21、22。如果日期大于 01.01.2013，则班级 20 的班级编号应递增为 3，结束学习日期更改为 01.01.2014。等等。

现在我们遇到了问题——如果有 1000 个地方，每个地方有 100 所学校，每个有 10 个班级，我们就有 1000000 条记录。很多。因为我所提供的只是一个简单的示例，所以我必须考虑在每次用户刷新页面时更新整个数据库，所以我担心它可能会滞后于这么多的记录。

我还可以将课程序列化为学校表中的一个字段：

school | place | classes
-------------------------------------------------------------------------
5      |   2   | serialized class 20, 21, 22 with end_learning field and class number
6      |   2   | other serialized classes from school 6

在那种情况下，我得到的记录减少了 10 倍，但每次我必须反序列化数据，检查日期，如果它比现在少，则更改它，序列化并保存到数据库。第二个问题是我必须从 db 中选择所有记录来操作它们，而不仅仅是所有需要更改的记录。

我也在考虑拥有两个数据库：一个包含在未来可能需要更改的记录，第二个可能需要在接下来的 24 小时（不久的将来）进行更改。每 24 小时将在接下来的 24 小时内结束学习的所有课程都移动到“近期”数据库，因此页面的每次刷新都适用于数千条记录，而不是数十万或数百万条记录。取而代之的是，它每天只对数百万条记录（更远的将来）创建一次“近期”表。

您如何看待所有这些数据库模式？也许你有更好的主意？

4

1 回答 1

2

我不太了解您概述的业务逻辑或数据模型 - 但我假设您已经考虑过了。

首先，像 MySQL 这样的 RDBMS 解决方案非常非常擅长管理大量记录，只要您使用的数据是关系型的。据我所知，您将搜索许多记录，但只更新一些记录（用户只能注册有限数量的课程）；我不认为这是一个大问题。

其次，在您可以证明它不满足您的性能需求之前，使用“标准”关系模型几乎总是比在开始时采用“异国情调”解决方案更好（我将您的序列化和分区解决方案归类为“异国情调“出于此答案的目的）。大量的时间和精力都花在了优化 SQL 的性能上；如果有一个简单的替代方案，它将成为标准解决方案的一部分。当然，有些点标准关系模型无法扩展（例如 Facebook 大小的流量），或者关系模型并不真正适合的业务领域（文档、图表）。但是，所有替代方案都像“标准” MySQL 一样具有优点和缺点。

第三，处理可能的性能问题的最佳方法是处理它们。在代码中。建立一个测试平台，根据关系模型创建一个模式，用测试数据填充它（例如使用DbMonster），给它一些负载（例如使用JMeter）并调整你的模式和查询以证明你的情况不适合标准溶液。如果你真的可以证明你不能很好地使用标准的关系数据库东西，那么只选择异国情调的东西。

于 2013-03-10T17:13:12.973 回答