1

想象一下，您必须从 1 到 10 询问世界上每个人的幸福感。每个人都会做出回应。有多达 80 亿人，因此您必须使用 bigint 作为密钥（假设我们已经在另一个数据库中拥有身份，我们只需要密钥），而您实际上拥有近 80 亿条唯一记录。然后，对于每条记录，您必须存储一个从 1 到 10 的值——在大多数将映射到字节数据类型的数据库中（这只是一个假设，我们也可以在 0 到 255 的范围内测量幸福感）。

80 亿人 *（8 字节密钥 + 1 字节值）= 64 Gb 密钥值 + 8 Gb 值 = 72 Gb 总大小。

是否可以在任何主流数据库（例如 SQL Server 或 MySql）中大幅减少相同任务的存储大小？

我不打算进行这样的民意调查并且没有那么多用户，大键是其他几个 int 键的笛卡尔积的结果，从长远来看，我可以拥有数十亿条记录，每个记录都有简单的数值较小ID的组合。

4

2 回答 2

1

您无需存储密钥即可使用密钥。您只需要一个包含响应的数组。所以 80 亿人提供了 80 亿字节。所以这是 8 GB。

如果您只想说 16 个可能的答案，您可以将两个答案打包在一个字节中，这样您就可以减少到 4 GB。

如果您真的希望它又小又快，那么平面文件可能同样好，如果不是更好的话。这取决于您的使用类型。

但是如果你真的想要它在一个表中，但仍然保持它很小，你需要去掉每条记录上的键。例如，您可以通过在记录之间共享密钥来做到这一点，例如：

Key      n0 n1 n2 n3 n4 n5 n6 n7 n8 n9
00000000  7  1  2 13  7  8  9 11  2  9
00000010  3  7  8  9 11  2  6  7  9 12

答案00000000-00000009被记录在案00000000，答案00000010-00000019被记录在案00000010

于 2013-05-05T19:58:03.337 回答
0

如果密钥分布稀疏，您将不得不明确地将响应与密钥配对。您可以通过将此轮询存储在另一个已经有键列的表中来保存它，从而节省工作量。

如果键是连续的，那么 Ebbe 的方法效果最好。如果您必须使用表结构，您可以将此数据拆分为例如 1024 个分片，并在进行键查找时将键的前 10 位隐含在表的标识中。

您还可以从密钥的尾部节省一些存储空间。例如，我们不想存储密钥的最后 10 位。然后将密钥截断 10 位并在其中存储一个 blob，这将是一个包含 1024 个响应的平面数组。

您可以通过为每个答案创建 10 个表并根据投票答案在每个表中插入键来保存投票数据（1 个字节值）（这不能与上述某些内容结合使用，而且如果您的投票也不会扩展答案范围大）。

于 2013-05-05T20:07:53.413 回答