标签的高效数据结构？

Question

想象一下，您希望尽可能高效地（二进制）将stackoverflow帖子（包括其标签）序列化和反序列化，以及在执行标记查找时的性能。这种情况是否有良好的数据结构？

Stackoverflow有大约28532个不同的标签，您可以创建一个包含所有标签的表并为它们分配一个整数。此外，您可以按频率对它们进行排序，以便最常见的标签具有最低的数字。仍然存储它们就像一个字母“1 32 45”的字符串似乎从搜索和存储的角度来看有点无用

另一个想法是将标记保存为变量bitarray，从查找和序列化的角度来看这很有吸引力。由于最常见的标签是首先你可能会将标签装入少量内存。

问题当然是不常见的标签会产生巨大的比特。对于0的大跨度，是否有“压缩”比特阵列的标准？或者应该完全使用其他结构？

修改

我不是在寻找数据库解决方案或解决方案，我需要将整个表保留在内存中，而是用于过滤单个项目的结构

Answer 1

不要破坏你的问题，但28k记录确实不是那么多。您是否可能过早优化？ 我首先坚持在数据库表上使用'常规'索引。他们使用的harhing启发式算法通常非常有效，并且不容易被击败（或者如果你能及时真的值得努力并获得足够大的收益吗？）。

另外，根据您实际执行标记查询的位置，用户是否真的注意到您针对优化的200ms时间增益？

首先测量然后优化： - ）

修改

如果没有DB，我可能会有一个主表，其中包含所有标记和ID（如果可能，将其保存在内存中）。保留一份常规的ID分类列表以及每篇帖子。

不确定基于通用性的存储空间有多大帮助。您可以进行常规二进制搜索的排序列表可以证明足够快;衡量： - ）

在这里，你需要为每个标签查询迭代所有帖子。

如果这最终会变慢，您可以为每个标签存储一个帖子标识符的口袋。这个数据结构可能会变得有点大，可能需要一个文件来搜索和阅读。

对于较小的表，您可以根据散列值（带有重复项）构建一个表。通过这种方式，您可以使用它快速找到较小的候选帖子列表，这些帖子需要进一步检查以确定它们是否匹配。

Answer 2

您需要第二个包含2个字段的表：tag_id question_id

就是这样。然后你在tag_id，question_id和question_id，tag_id上创建索引 - 这将覆盖索引，所以你的所有查询都会非常快。

Answer 3

我觉得你过多地抽象了你的问题;你没有多说你想如何访问数据结构，这是非常重要的。

话虽如此，我建议计算每个标签的出现次数，然后使用Huffman coding提出可用于标签的最短编码。这并不完全是完美的，但我会坚持下去，直到你证明这是不合适的。然后，您可以将代码与每个问题相关联。

Answer 4

如果要在特定标记内有效查找问题，则需要某种索引。也许，所有Tag对象都可以有一个引用数组（引用，指针，nummeric-id等）到所有用这个特定标记标记的问题。这样，您只需要找到标记对象，并且您有一个指向该标记的所有问题的数组。