数百万行的数据库设计

Posted 2023-04-18

【中文标题】数百万行的数据库设计

【英文标题】：database design for millions of rows

【发布时间】：2014-11-14 09:00:42

【问题描述】：

我有一个包含用户和按钮的应用程序，每个都有唯一的 ID。我创建了一个 user_tbl 和 button_tbl。

当按钮或用户不多的时候一切都很好，但是当有数亿用户和按钮时呢？用户和按钮将分布在许多表中...... 所以我发现我必须创建多个表并将它们命名为tbl_0，tbl_1等，然后生成用户ID，当以0开头的ID将存储在user_tbl_0中，以1开头的ID将存储在user_tbl_1等等在。按钮也是如此。

现在，查询是根据按钮或用户执行的，即有时我需要查询分配给某个 BUTTON 的所有 USERS，有时需要查询分配给某个 USER 的所有 BUTTONS。 我创建了一个 user_buttons_tbl，其中每一行都包含分配给用户的用户 ID 和按钮 ID。再说一次，当只有一个这样的表时，没有问题，但在某些时候我将不得不创建额外的表并根据用户 ID 将它们命名为 user_buttons_tbl_0、user_buttons_tbl_1 等等。

问题： 只有当我查询某个用户的所有按钮时，这才对我有帮助。在这种情况下，我可以根据用户 ID 从相应的表（0、1、...）中查询，但是当我需要查询所有用户的某个 BUTTON 时，我需要查询所有这些用户表，因为这个按钮可能让用户的 ID 以 0、1、2 等开头。

可能的解决方案： 创建 button_users_tbl_0、button_users_tbl_1 等（就像 user_buttons_tbl），其中按钮 ID 而不是用户 ID 将是决定在哪个表中存储记录的关键（tbl_0、tbl_1、...）。当我需要向所有用户查询某个按钮时，这可以为我服务。

这意味着当我为用户分配一个按钮时，我需要根据用户 ID 将记录插入到适当的 user_buttons_tbl 中，并根据按钮 ID 将记录插入到适当的 button_users_tbl 中，因此它的存储空间是 2 倍相同的数据。

我的问题：

如果我有除 USERS 和 BUTTONS 之外的其他数据类型怎么办？像 LINKS 一样，每个链接都分配给某个按钮并且每个链接都有一个链接 ID？这使事情变得更加复杂，并且可能需要额外的“重复”表。

也许我应该在表格上添加表格，甚至不使用 0、1、2 等命名它们，并且每次都查询它们......这听起来是一种不好的做法，但我不知道。 ..也许这就是它的完成方式。是吗？

什么是正确的做法？对于具有此类数据交叉的大数据，什么被认为是良好的数据库设计实践？还有其他解决方案吗？

非常感谢您的回答，并在此先感谢您。

【参考方案1】：

性能优化的一般规则是：

不要过早优化 在开始之前测量。

如果您使用的是 SQL 数据库，则应从构建适当规范化的数据库架构开始，并仅在实际开始遇到性能问题时才开始对其进行性能调整。这样，您实际上就知道瓶颈在哪里。如果您一开始就根据您认为的瓶颈来设计架构，而事实证明是不同的，那么您将度过一段糟糕的时光。无论如何，数亿行对于设计良好的 SQL 数据库来说不一定是问题。

如果您一开始就不需要关系数据库的强大功能，您可以查看 NoSql 解决方案，例如 Cassandra、CouchDB 或许多其他解决方案之一。它们在性能和可扩展性方面享有盛誉，但它们需要更多的努力来管理您的数据。

【讨论】：

谢谢瑞克。我明白你在说什么，这听起来很合乎逻辑。但是，我希望至少为 ID 格式做好准备，因此无论我遇到什么瓶颈，ID 基础设施都将支持轻松的可扩展性。使用 AI 选项是否正确，或者生成像 XYZ12345678 这样的智能 ID 以便以后为我提供更大的灵活性？

智能 ID 为您提供更少的灵活性，而不是更多。 64 位整数有 18,446,744,073,709,551,615 个不同的值。您无需扩展到大于 64 位 ID 号。