Database 对于具有固定列数的可搜索位矩阵，什么是好的表示形式？

原始数据可以描述为固定数量的列（大约几千列）和较大数量的行（大约数十亿行）。每一个细胞都是一个比特。所需的查询类似于查找设置了位12329123020的所有行。差不多

for (i=0;i< max_ents;i++) 
    if (entry[i].data & mask == mask) 
        add_result(i);

for（i=0；i

在典型情况下，在任何特定行中设置的位不多（例如5%），但这并不能保证，存在一定程度的可变性

在更高的层次上，数据描述条目的按位指纹，数据本身是一种搜索索引，因此需要最大的速度。什么算法适合这种搜索？目前，我正在考虑为每一列分别设置单独的稀疏（压缩/压缩）位向量。不过，我怀疑它是否最佳。

这看起来类似于“文本搜索”，尤其是交叉反向索引。让我看一下最简单的算法

首先，您应该在设置每个位的位置创建数字的排序列表。例如，对于数字表：

第1行->10110

第2行->00111

第3行->11110

第4行->00011

第5行->01010

第6行->10101

您可以创建反向索引：

位0在->2、4、6中设置

位1设置在->1、2、3、4、5中

位2在->1、2、3、6中设置

等等

现在，对于一个查询（比如比特0、1和2），您只需要使用类似合并排序的算法合并这些已排序的列表，。要做到这一点，您可以首先合并列表0，1，给您{2，4}，然后将其与列表2合并，给您{2}

可以进行几种优化，包括但不限于压缩这些列表，因为连续项之间的差异通常很小，可以进行更有效的合并等

但是，为了节省更多的麻烦，为什么不重用其他人已经完成的工作呢。。。您可以随时使用任何开源文本搜索引擎（我建议）来执行此任务（应该可以在不到一天的编码时间内完成），并且它应该包含一些人们在很长时间内构建的优化；）。（提示：在文本搜索术语中，您应该将每一行视为“doc”，将每一位视为“token”）

编辑（根据问题作者的要求添加一些算法）：

a） 压缩：您可以做的最有效的事情之一是压缩帖子列表（对应于每个位置的排序列表）。大多数算法通常采用连续项之间的差异，然后根据某种编码（，）对其进行压缩。这将压缩倒排列表，以便它要么消耗更少的文件空间（从而减少文件I/O），要么使用更少的内存对同一组数字进行编码。在您的情况下，我可以估计每个帖子列表将包含~5%*1e9=5e7个元素。如果它们均匀分布在0-1e9之间，则间隙应该在20左右，因此我们假设编码每个间隙平均需要约8b（这是一个很大的高估），总计为500MB。因此，对于1000个列表，您需要500GB的空间，这肯定需要一个磁盘空间。这反过来意味着您应该尽可能使用好的压缩算法，因为更好的压缩意味着更少的文件I/O，您将受到I/O的限制

b） 交集顺序：您应该始终从最小的列表开始交集列表，因为这样可以保证创建最小大小的中间列表，这意味着通过下面所示的技术，以后比较会更少

c） 合并算法：由于您的索引几乎肯定会溢出到磁盘，因此在算法级别上您可能做不了多少事情。但是使用的一些想法是使用基于二进制搜索的过程来合并两个列表，而不是简单的线性合并过程，以防其中一个列表比另一个列表小得多（这将导致

O（N*log（M））

复杂性，而不是

O（N+M）

其中

M>>N

）。但对于基于文件的索引，这几乎从来都不是一个好主意，因为二进制搜索会进行许多随机访问，这会完全破坏磁盘延迟，而线性合并过程是严格按顺序进行的

d） ：这是另一个伟大的数据结构，用于存储排序后的帖子列表，也可以支持前面提到的高效“二进制搜索”。这里的关键思想是，跳过列表的上层可以保存在内存中，这可以大大加快交集算法的最后阶段，当您可以简单地搜索内存中的上层以获得磁盘偏移量，然后从那里进行磁盘访问时。有一点是，二进制搜索+基于skiplist的合并比线性合并更有效，并且可以通过实验找到

---

e） 缓存：无需思考。如果某些术语经常出现，请将它们缓存在内存中，以便将来更有效地获取它们。请注意，缓存也可以是一个更快的基于闪存的磁盘，它可以为您提供更好的吞吐量，并且可能会缓存大量更频繁的术语（32GB内存只能保存这些列表中的约64个，而256GB闪存可以保存约512个）。

您的搜索有常见模式吗？如果某些列的查询频率高于其他列，那么将它们编入索引

BINARY（1）

或

BINARY（2）

列可能是有意义的，而将其余列保留在

BINARY（300）

列中（或其他任何形式）。数据有一种模式，查询有一种模式，但无法提前确定。查询模式可以在统计上建立。数据模式可能有点困难。您可以说，在典型的情况下，不需要太多（例如5%）位ar