在couchdb中创建文档ID时的最佳做法是什么？

Question

我们都知道，对于关系数据库，最好使用数字ID作为主键。

在couchdb中，生成的默认ID为UUID。最好坚持使用默认值，还是使用用户在应用程序中使用的易记忆标识符？

例如，如果您在couchdb中设计stackoverflow.com数据库，您会使用问题slug（例如，什么是最佳实践，何时创建文档-ids-in-couchdb ）或每个文件的UUID？

Answer 1

我不是沙发专家，但在做了一点研究之后，这就是我发现的。

简单的答案是，使用UUID，除非你有充分的理由不这样做。

答案越长，取决于：

更改ID V的成本ID更改的可能性

更改成本低且可能更改ID

此示例可能是具有非规范化设计的博客，例如jchris' blog（sofa code available on git hub）。

每当其他网站链接到博客帖子时，这是对id的另一个引用，因此更改ID的成本会增加。

更改ID的成本和永不改变的ID

此示例是任何使用自动增量ID进行高度规范化的数据库设计。 Stackoverflow.com是一个很好的例子，它可以在每个URL中看到自动递增的问题ID。由于每个外键都需要更新，因此更改ID的成本非常高。

ID会有多少引用或“外键”（关系数据库语言）？

任何“外键”都会大大增加更改ID的成本。必须更新其他文档是一个缓慢的操作，绝对应该避免。

ID更改的可能性有多大？

如果您不想使用UUID，您可能已经知道要使用的ID。

如果可能发生变化，更改ID的成本应该很低。如果不是，请选择其他ID。

您想要使用容易记忆的ID的动机是什么？

不要说表现。

Benchmarks show“CouchDB的视图键查找几乎，但不完全，与直接文档查找一样快”。这意味着必须进行搜索才能找到记录并不是什么大问题。不要选择友好的ID只是因为你可以直接查找文档。

您会进行多次批量插入吗？

如果是这样，最好使用增量UUID以获得更好的性能。

有关批量插入的信息，请参阅此post。 Damien Katz评论并说：

  

“如果你想拥有最快的   可能的插入时间，你应该给   _id的升序值，所以得到一个   UUID并以此方式将其递增1   它总是插入相同的   放在索引中，并作为缓存   一旦你处理，友好   大于RAM的文件。为了更容易   只是为了做同样的事情   顺序编号文件，但   用填充物固定长度   他们排序正确，“0000001”   例如，而不是“1”。“

Answer 2

从关系数据库的角度来看，我花了一段时间来弄清楚couchdb。但事实与接受答案相反;

生成智能ID可以极大地帮助您检索和排序数据，而不是使用默认的uuid。

  

假设您有数据库电影。所有文件都可以在URL /电影下的某个地方找到，但究竟在哪里？

     

如果您将带有_id Jabberwocky（{＆＃34; _id＆＃34;：＆＃34; Jabberwocky＆＃34;}）的文档存储到电影数据库中，它将在URL / movies / Jabberwocky下提供。因此，如果您向/ movies / Jabberwocky发送GET请求，您将获得构成文档的JSON（{＆＃34; _id＆＃34;：＆＃34; Jabberwocky＆＃34;}）。

http://guide.couchdb.org/draft/documents.html

  

效果提示：如果您只是使用随机生成的文档ID，那么您不仅错过了获得免费索引的机会 - 您还会产生开销建立一个你永远不会使用的索引。因此，请使用和滥用您的文档ID！

https://pouchdb.com/2014/05/01/secondary-indexes-have-landed-in-pouchdb.html

Answer 3

我意识到这是一个长期回答的问题，但对于那些发现问题的人来说，还有另一个重要的考虑因素。删除文档时，您所知道的就是ID。键入，无论是显式（type:foo）还是暗示（鸭子打字）都不起作用。因此，您无法订阅doc.deleted===true && doc.type==foo的更改，因为删除后doc.type===undefined。您可以在事后解码的_id值很有用，特别是如果您的客户端代码需要无状态（因此不能按类型缓存_id列表）。

Answer 4

_id在CouchDB内部使用很多，任何额外的散列成本都会减慢一堆内部因素，所以最好坚持使用提供的UUID。

Answer 5

您可以使用默认的CouchDB ID（UUID），正如documentation中所述，使用默认UUID的主要原因如下：

• UUID是具有如此低冲突概率的随机数，每个人可以在数百万年内每分钟生成数千个UUID而无需创建副本。这是确保两个独立人员无法创建两个不同文档的好方法相同的身份证。
• CouchDB复制允许您与他人共享文档，并使用UUID确保一切正常。

现在，另一方面，如果您依赖服务器（CouchDB）来生成UUID，并且您最终发出两个POST请求，因为第一个POST请求遭到轰炸，您可能会生成两个文档但从未发现有关第一个是因为只会报告第二个，所以，最好生成自己的UUID以确保你永远不会得到重复的文件，但我肯定会使用UUID，除非你具体否则需要。 documenta

Answer 6

数据库中的主键除了编码序列外，不应该有任何“含义”。您可能想要更改SLUG而不是主键。

使用以时间戳开头的内容可能会有一个很好的论据，即在密钥中使用固有的顺序。我经常使用“％f @％s”％（time（），hostname（））来获取有序的唯一键。 （仅当你的time（）实现永远不会返回相同的值两次时才有效。）

对于其他东西（例如图像），我想避免重复，我经常使用sha（数据）作为密钥。