0

mysql 数据库中的表中有两列。第一列包含指纹，而第二列包含具有该指纹的文档列表。它很像搜索引擎构建的倒排索引。表内记录的一个实例如下所示；

34 "doc1, doc2, doc45"

指纹的数量非常大（可达数万亿）。数据库中基本上有以下操作：插入/更新记录和根据指纹匹配检索记录。表定义python片段是：

self.cursor.execute("CREATE TABLE IF NOT EXISTS `fingerprint` (fp BIGINT, documents TEXT)")

插入/更新操作的片段是：

if self.cursor.execute("UPDATE `fingerprint` SET documents=CONCAT(documents,%s) WHERE fp=%s",(","+newDocId, thisFP))== 0L:
                self.cursor.execute("INSERT INTO `fingerprint` VALUES (%s, %s)", (thisFP,newDocId))

到目前为止，我观察到的唯一瓶颈是 mysql 中的查询时间。我的整个应用程序是基于网络的。所以时间是一个关键因素。我也想过使用 cassandra，但对它的了解较少。请建议我一个更好的方法来解决这个问题。

4

3 回答 3

2

获取高端数据库。甲骨文有一些优惠。SQL Server 也是。

数以万计的条目远远超出了普通数据库的范围。这是非常高端非常特别的东西，特别是如果你想要体面的性能。还要为其配备硬件——这意味着一个不错的中档服务器、用于缓存的 128+gb 内存，以及一个不错的 SAN 或通过 SAS 设置的足够好的 DAS。

请记住，万亿意味着：

  • 每个字节使用 1000gb。

如果指纹存储为 int64，则仅此数据就有 8000gb 磁盘空间。

或者您是否尝试从带有几张 2tb 光盘的小型廉价服务器上运行它？祝你好运。

于 2010-12-30T05:39:59.273 回答
1

该数据结构不太适合 SQL - SQL 中的“正确”设计是为每个指纹/文档对设置一行，但除非添加会占用太多空间的索引，否则查询速度会非常慢. 对于您正在尝试做的事情，SQL 增加了很多开销来支持您不需要的功能，同时不支持您确实需要的多值列。

Redis 集群可能非常适合 - 原子集操作应该非常适合您正在做的事情，并且通过正确的虚拟内存设置和一致的散列来在节点之间分配指纹，它应该能够处理数据量。然后命令将是

SADD fingerprint, docid

添加或更新记录，以及

SMEMBERS fingerprint

使用该指纹获取所有文档 ID。

SADD 是 O(1)。SMEMBERS 是 O(n)，但 n 是集合中的文档数量，而不是系统中文档/指纹的数量，因此在这种情况下也是 O(1)。

您当前使用的 SQL 插入是 O(n)，其中 n 是非常大的记录总数，因为记录存储为有序列表，必须在插入时重新排序，而不是哈希表，哈希表对于两者来说都是恒定时间并设置。

于 2010-12-31T01:38:06.053 回答
0

Greenplum 数据仓库，FOC，postgres 驱动，祝你好运...

于 2010-12-30T06:14:55.440 回答