mysql - 适合大数据的数据库设计

Question

我为每个国家/地区准备了大量表格。我希望每个字段都有多个评论相关字段，以便用户可以在我的网站上发表评论。我可能会有更多字段，例如:创建评论的日期、评论者的 user_id。此外，我可能需要在未来添加其他字段。例如，company_support_comment/support_rating, company_professionalism_comment

假设我在一张表中有 100 万家公司，每家公司有 100 条评论。然后我会收到很多针对一个国家的评论 它很容易超过 20 亿。unsigned bigint 可以支持 18 446 744 073 709 551 615。所以我们可以在一个表中有那么多注释。 Unsigned int 将为我们提供 4.2+ 十亿。这在一张 table 上是不够的。然而想象一下查询一个有 40 亿条记录的表？这需要多长时间？我可能无法有效地检索评论，这会给数据库带来巨大的负载。鉴于在实践中可能无法完成一张 table 。多个表也可能不好。除非我们只使用 json 数据..

其实我现在也不确定。我的数据库设计需要一个合适的解决方案。我现在用的是mysql。

Answer 1

在我看来，你的问题方向错误。

从您的数据库设计开始。这意味着如果您担心它，请从 bigint 开始(因为如果您弄错了，从 int 转换为 bigint 会很痛苦)。构建良好的规范化模式。然后想办法让它变快。

在您的情况下，PostgreSQL 可能是比 MySQL 更好的选择，因为您的查询可能会针对二级索引。在使用 InnoDB 的 MySQL 上，这些比 PostgreSQL 更昂贵，因为使用 MySQL，您必须遍历主键索引来检索行。这意味着，有效地遍历两个 btree 索引以获取您要查找的行。可能不是世界末日，但如果性能是您最关心的问题，那可能是您不想支付的成本。虽然 MySQL 覆盖索引在某些情况下更有用，但我认为它们在这里对您没有帮助，因为您实际上对您可能没有直接索引的文本字段感兴趣。

在 PostgreSQL 中，您有一个 btree 索引，然后为您提供一系列页面/元组元组，然后允许您通过随机访问有效地查找数据。对于这么大的表，这将是一个胜利，我的经验是 PostgreSQL 可以在大表上执行得非常好(表的大小跨越，比如说，2-3TB 及其索引)。

但是，假设您坚持使用 MySQL，仔细注意索引可能会让您到达需要去的地方。请记住，您只是为一家公司提取 100 条评论，并且遍历一个索引具有 O(log n) 的复杂性，因此它并没有那么糟糕。最大的问题是为检索到的每一行遍历 pkey 索引，但即使这样也应该是可管理的。