生成词汇提升的唯一ID
我想生成用于CouchDB的ID。 我希望这些ID可以按时间上升，这样我就可以在没有保留单独的时间戳字段的情况下对id进行sorting。 我知道CouchDB会用这个属性来生成id，但是我不希望查询数据库的性能受到影响，我宁愿在我的服务器上运行一个algorithm。 除了结果不是按照词汇升序外，我会去执行rfc 4112。 有没有什么好的理由我不应该这样做：
(Date.now()) + 'x' + Math.round(Math.random() *1E18) （我正在使用nodejs）。 使用非标准的uuid，还是依靠随机函数构build的javascript，是否有任何费用？
当谈到uuids时，你有一些select。
第一select是如果你想_id生成的客户端（节点，浏览器等），或沙发。 这听起来像你想在客户端生成自己的uuid。 没事儿。 只需将你的函数的结果粘贴到你保存到couchdb的文档的_id字段中即可。 沙发只是使用它。
你可以让沙发创buildID。 如果您没有为自己select一个，Couchdb只会生成一个_id。 Couchdb默认使用“顺序”uuid生成algorithm。 你可以通过被子和configuration改变他人的algorithm。 有一个名为“uuids”的部分，带有“algorithm”键。 你可以在这里看到这些algorithm的来源：
https://github.com/apache/couchdb/blob/master/src/couchdb/couch_uuids.erl
有关他们的描述在这里：
http://wiki.apache.org/couchdb/HttpGetUuids?highlight=%28utc%5C_random%29
正如你可以看到的utc_random函数是非常类似于你的build议。 但是，如果你想自己的，如果你倾向于你可以在服务器端添加algorithm，并重新编译沙发。
你的问题的第二部分是关于select不同algorithm的性能。 我要从用户列表post引用Dave Cottlehuber：
当doc ID不断增加时，CouchDB将具有最佳的插入时间，因为这样可以最大程度地减less对树的重写。 这也将有助于您的观点build立时间出于同样的原因，也尽可能减less浪费的文件空间，虽然这也将在压缩期间恢复。
所以你的algorithm和utc_random都应该没问题，因为他们的doc id不断增加，直到看似有用的时间方向。
我build议坚持使用CouchDB为您生成的UUID，但是您可以将服务器configuration为使用utc_random，它将在时间戳前添加一个可以按照您的loggingsorting的时间戳。