一个大型数据库还是几个较小的数据库？

Question

在阅读了很多关于它和类似的问题之后，我仍然不清楚以下案例。

我在一个 mysql 数据库中有这样的模式，我根据结果类型存储超过 10 项运动的比赛概率（用于在不同页面上显示每种运动的赔率的应用程序，但我永远不会混合体育在同一页）：

设计一：单一数据库

SPORT
id
name

TEAM
id
sportId
name
birth

MATCHES
id
sportId
teamId_1
teamId_2
result
date

PROBABILITIES
id
matchId
type
percentage

（表概率很长，几乎有十亿行，并且会随着时间的推移而增长）

所有必要的字段都被正确索引。 然后要查看与id = 1的足球运动没有结果的比赛的所有概率，我将进行以下查询：

SELECT s.name, t1.name as nameTeam1, t2.name as nameTeam2, t1.birth as birthTeam1, t2.birth as birthTeam2, m.date, p.type, p.percentage
FROM matches m
INNER JOIN team t1 ON t1.id = m.teamId_1
INNER JOIN team t2 ON t2.id = m.teamId_2
INNER JOIN sport s ON s.id = m.sportId
INNER JOIN probabilities p ON p.matchId = m.id
WHERE result IS NULL
AND s.id = 1

这个数据库设计很棒，因为它让我可以像 Prisma 一样舒适地使用 ORM。 但对我的团队来说，最重要的是速度和性能。

知道了这一点，这样做是个好主意还是将表分成几个数据库更好？

设计 2：每项运动一个数据库

数据库足球

TEAM
id
sportId
name
birth

MATCHES
id
teamId_1
teamId_2
date

PROBABILITIES
id
matchId
type
percentage

数据库篮球

TEAM
id
sportId
name
birth

MATCHES
id
teamId_1
teamId_2
date

PROBABILITIES
id
matchId
type
percentage

probabilities表要小得多，在某些运动中只有数千行。

因此，例如，如果我只需要获取足球概率，我会进行如下查询：

SELECT t1.name as nameTeam1, t2.name as nameTeam2, t1.birth as birthTeam1, t2.birth as birthTeam2, m.date, p.type, p.percentage
FROM football.matches m
INNER JOIN football.team t1 ON t1.id = m.teamId_1
INNER JOIN football.team t2 ON t2.id = m.teamId_2
INNER JOIN football.probabilities p ON p.matchId = m.id
WHERE result IS NULL

或者当我们只查询数据库中最近的行时，是否有其他方法可以提高数据库的速度和性能，例如对probabilities表进行分区？

Answer 1

如果您为每项运动创建一个数据库，则您将应用程序锁定在该决定中。 如果您将它们全部放在一起，则可以在以后根据需要将它们分开。 我怀疑它会是。

但对我的团队来说，最重要的是速度和性能。

在这个早期阶段，最重要的事情是让某些东西正常工作，这样您就可以使用它并发现它实际需要做什么。 然后根据您的学习调整架构..

您的主要性能问题不会来自您是否拥有一个或多个数据库，而是更多的索引、错误查询和模式设计等问题。

为此...

• 保持架构简单
• 保持架构灵活
• 考虑一个数据仓库

首先，这意味着一个数据库。 如果不需要，不要添加维护多个模式副本的复杂性。

其次，使用模式迁移并将模式的细节保留在应用程序代码之外。 ORM 是一个好的开始，但也使用存储库模式、装饰器模式、服务模式等来防止表的详细信息泄漏到代码中。 然后，当不可避免地需要更改您的架构时，您无需重写所有使用它的代码。

您的问题可以通过索引和分区（可能是分区概率）来解决，但在不知道您的查询的情况下，我不能说什么。 例如，您可能希望按匹配的年龄进行分区，因为新匹配比旧匹配更有趣。 很难说。 幸运的是，稍后可以添加分区。

表的 rest 应该相对较小，按团队分区不太可能有帮助。 糟糕的分区选择甚至会减慢速度。

最后，可能最好的性能是将统计表分离到针对大数据和统计优化的数据仓库中。 在那里进行统计并让应用程序查询它们。 这将必须具有低延迟和保持小优势的运行时模式与主要报告预先计算的统计查询的统计数据库分开。

---

关于您的架构的一些注释。

从比赛中删除“运动”。 这是多余的。 从团队中获取。 添加约束以确保两支球队都在进行相同的运动。

不要命名列date 。 首先，它是一个关键字。 第二，什么日期？ 如果有另一个与比赛相关的日期怎么办？ 三、比赛时间呢？ 使其具体： scheduled_at 。 使用时间戳类型。

Result应该是它自己的表。 你会想要存储很多关于比赛结果的信息。

Answer 2

在 MySQL 中，“DATABASE”是一个非常轻量级的东西。 它与 MySQL 几乎没有区别，并询问您是否有一个或两个 db。 或 20。

您可能需要一些语法来处理 JOIN：

一分贝：

USE db;
SELECT a.x, b.y
    FROM a
    JOIN b ON ...;

两个数据库：

USE db;
SELECT a.x, b.y
    FROM db1.a AS a
    JOIN db2.b AS b  ON ...;

这两者的表现是一样的。

底线：做你觉得好的事情，开发者。