Mongodb：在 Web URL 上创建唯一索引是个好主意吗？

Question

我的文档如下：

{"url": "http://some-random-url.com/path/to/article"
"likes": 10
}

网址必须是唯一的。在url 上有一个唯一索引是个好主意吗？ URL 可能很长，从而导致更大的索引大小、更多的内存占用和更慢的整体性能。从 url 生成散列（我正在考虑使用murmur3）并在其上创建唯一索引是个好主意。我假设碰撞的可能性非常低，如下所述：https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed

有没有人认为这种方法有任何缺点？新文档将如下所示（在 u_hash 上具有唯一索引，而不是 url）：

{"url": "http://some-random-url.com/path/to/article"
"likes": 10
"u_hash": "<murmur3 hash of url>"
}

更新

我不会对url 进行正则表达式查询。将只进行完整的 URL 查找。我更关心这种查找的性能，因为我相信 mongodb 也会在内部使用它来维护唯一索引，因此也会影响写入性能（+ 更长的索引）。此外，我的理解是 mongobd 对于长文本索引的性能不佳，因为它不是为此目的而设计的。不过我可能错了，它只能取决于该索引是否适合 RAM。有什么指点吗？

Answer 1

我想扩展@AlexRyan 的答案。虽然他总体上是对的，但对于这个用例，有一些事情需要考虑。

首先，我们必须区分唯一索引和_id 字段。

当 URL 在您的用例中需要唯一时，必须有一个唯一索引。我们必须决定是使用 URL 本身还是它的散列值。散列本身对搜索没有帮助，因为保存在字段中的散列和将被 MongoDB 视为字符串。它可能是安全空间（URL 可能比它们的哈希值短），从而减少了索引所需的内存。但是，这样做会消除在索引中搜索部分 URL 的可能性，例如使用

db.collection.find({url:{$regex:/stackoverflow/}})

通过 url 上的唯一索引，此查询将使用索引，这将非常快。如果没有此类（唯一）索引，此查询将导致收集扫描速度相对较慢。

另外，在查询、更新或插入之前每次都创建散列并不会使这些操作更快。

这给我们留下了这样一个事实，即在其上创建哈希和和唯一索引可能会节省一些 RAM，但代价是对实际字段的查询速度要慢几个数量级。并且它引入了每次创建哈希和的需要。在 URL 和它的哈希值上都有一个索引根本没有意义。

现在问题是，以一种或另一种方式使用 URL 作为_id 是个好主意。由于 URL 通常本质上是不同的（它们应该返回相同的内容）并且喜欢与这种唯一性有关，所以我倾向于使用 URL 作为 id。因为无论如何您都需要_id 上的唯一索引，所以它在这里有两个用途：您拥有文档的 ID，确保 URL 的唯一性，并且 - 如果您使用 URL 的自然表示 - 它甚至是可查询的以一种有效的方式。

Answer 2

在 url 上使用唯一索引

db.interwebs.ensureIndex({ "url" : 1}, { "unique" : 1 })

而不是散列索引。 MongoDB 中的散列索引旨在用于散列分片键，而不是用于唯一约束。来自hashed index docs，

散列索引支持使用散列分片键对集合进行分片。使用散列分片键对集合进行分片可确保数据分布更均匀。

和

您不得创建具有散列索引字段的复合索引或在散列索引上指定唯一约束

如果url 需要唯一并且您将使用它来查找文档，那么绝对值得在url 上使用唯一索引。如果您想使用url 作为文档的主键，您可以将url 值存储在_id 字段中。此字段通常是驱动程序生成的 ObjectId，但它可以是您喜欢的任何值。在 MongoDB 集合中，_id 上始终存在唯一索引，因此您可以“免费”获得唯一索引。

Answer 3

我认为答案是“视情况而定”。

选择其中嵌入了没有现实世界意义的键可能会在将来为您省去痛苦。如果您决定需要更改它但您有很多引用它的外键，则尤其如此。

大多数数据库管理系统都为您提供了一种生成唯一 ID 的方法。 在 Oracle 中，您可能会使用序列。 在 MySQL 中，您可以在定义表本身时使用 AUTO_INCREMENT。

mongodb 为文档分配唯一 ID 的方式与关系数据库不同。他们为此使用 ObjectID。

ObjectID 的一个有趣之处在于它们是由驱动程序生成的。 由于用于生成它们的算法，即使您拥有大量应用程序和数据库服务器，它们也可以保证是唯一的。

您可以在此处了解有关它们的更多信息： http://docs.mongodb.org/manual/reference/object-id/

为了确保 ObjectId 的唯一性，我们进行了大量工程工作。 我默认使用它们，除非有很好的理由不这样做。 到目前为止，我还没有找到一个很好的理由不使用它们。