couchdb - 长 ID 的性能

Question

我一直想知道这个问题有一段时间了。在 CouchDB 中，我们有一些相当的日志 ID……例如:

“000ab56cb24aef9b817ac98d55695c6a”

现在，如果我们正在搜索此项目并浏览由 View 创建的树结构。似乎一个简单的整数作为 id 会快得多。如果我们使用 64 位整数，它将是一个简单的 CMP，然后是一个 JMP(假设 Erlang 代码使用的是 JIT，但你明白我的意思)。

对于字符串，我假设我们生成了 ID 或其他东西的哈希值，但在某些时候我们必须对所有 33 个字符进行字符比较……这不会影响性能吗？

Answer 1

来自 CouchDB:权威指南:

I need to draw a picture of this at some point, but the reason is if you think of the idealized btree, when you use UUID’s you might be hitting any number of root nodes in that tree, so with the append only nature you have to write each of those nodes and everything above it in the tree. but if you use monotonically increasing id’s then you’re invalidating the same path down the right hand side of the tree thus minimizing the number of nodes that need to be rewritten. would be just the same for monotonically decreasing as well. and it should technically work if you’re updates can be guaranteed to hit one or two nodes in the inside of the tree, though that’s much harder to prove.

因此，顺序 ID 提供了性能优势，但是，您必须记住，当您拥有多个数据库时，这是不可维护的，因为 ID 会发生冲突。