代码之家  ›  专栏  ›  技术社区  ›  andyuk

在CouchDB中创建文档ID的最佳实践是什么?[关闭]

  •  26
  • andyuk  · 技术社区  · 16 年前

    我们都知道,对于关系数据库,使用数字标识作为主键是最佳实践。

    在couchdb中,生成的默认ID是 UUID . 最好还是使用默认的,或者使用一个用户将在应用程序中使用的容易记忆的标识符?

    例如,如果您在couchdb中设计stackoverflow.com数据库,您会使用这个问题吗? slug (例如,在CouchDB中创建文档ID时的最佳实践是什么)或每个文档的UUID?

    6 回复  |  直到 9 年前
        1
  •  18
  •   andyuk    16 年前

    我不是CouchDB专家,但在做了一些研究之后,我发现了这一点。

    简单的答案是,除非你有充分的理由不使用UUID。

    答案越长,取决于:

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

    更改成本低,可能更改ID

    这方面的一个例子可能是一个具有非规范化设计的博客,比如 jchris' blog ( sofa code available on git hub )

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

    更改ID和永不更改的ID的成本很高

    这方面的一个例子是任何使用自动增量ID的高度规范化的DB设计。stackoverflow.com是一个很好的例子,它的自动递增的问题ID可以在每个URL中看到。更改ID的成本非常高,因为每个外键都需要更新。

    ID将有多少引用或“外键”(关系数据库语言)?

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

    ID更改的可能性有多大?

    如果您不想使用UUID,您可能已经知道要使用什么ID了。

    如果它可能改变,那么改变ID的成本应该很低。如果不是,请选择其他ID。

    你想要使用一个容易记住的ID的动机是什么?

    不要说表演。

    Benchmarks show “couchdb_s view key lookup几乎(但不是完全)和直接文档查找一样快”。这意味着必须搜索才能找到一个记录并不重要。不要因为可以直接查找文档而选择友好ID。

    你会做很多批量插入吗?

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

    看看这个 post 关于大容量插入。达米安·卡茨评论说:

    “如果你想拥有最快的 可能的插入时间,你应该给出 ID的升序值,因此 uuid并以1递增,这样 它总是插入相同的 放在索引中,并被缓存 一旦你遇到朋友 大于RAM的文件。为了更容易 做同样的事情的方法,只是 按顺序编号文件,但 用衬垫固定长度,这样 正确排序,“0000001” 例如,不是“1”。

        2
  •  4
  •   TimoSolo Horshack    9 年前

    从关系数据库的角度来看,我花了一段时间才找到couchdb。但事实与接受的答案是相反的;

    与使用默认UUID不同,生成智能ID可以极大地帮助您检索和排序数据。

    假设你有一个数据库电影。所有文档都可以在url/movies下找到,但具体在哪里?

    如果您将带有“jabberwocky(”“id”:“jabberwocky”)的文档存储到您的电影数据库中,它将在url/movies/jabberwocky下可用。因此,如果您向/movies/jabberwocky发送一个GET请求,您将返回构成文档的JSON(“_id”:“jabberwocky”)。

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

    性能提示:如果你只是使用随机生成的文档ID,那么你不仅错失了一个获得免费索引的机会,你还需要承担构建一个永远不会使用的索引的开销。所以使用和滥用你的医生ID!

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

        3
  •  2
  •   Peter O. Manuel Pinto    14 年前

    我知道这是一个答案很长的问题,但对于那些发现这个问题的人来说,还有另一个重要的考虑。当一个文档被删除时,你只知道它的ID。键入( type:foo )或者暗示(duck-typing)不起作用。因此您无法订阅的更改 doc.deleted===true && doc.type==foo ,因为删除后, doc.type===undefined .一个 _id 特别是当客户端代码需要无状态(因此不能缓存 圣婴 S型)。

        4
  •  0
  •   mikeal    16 年前

    使用标识符 很多 在couchdb内部,任何额外的散列成本都会降低一堆内部的速度,所以最好还是使用所提供的uuid。

        5
  •  0
  •   Mike    10 年前

    您可以使用默认的couchdb id(uuid),正如在 documentation 使用默认UUID的主要原因如下:

    • UUID是一种随机数,具有很低的碰撞概率,每个人都可以在数百万年内每分钟生成数千个UUID,而不必创建重复的UUID。这是确保两个独立的人不能用相同的ID创建两个不同的文档的一个很好的方法。
    • CouchDB复制允许您与其他人共享文档,并且使用UUID确保所有文档都可以工作。

    现在,另一方面,如果您依赖服务器(couchdb)来生成uuid,并且由于第一个post请求被弹出而最终发出两个post请求,那么您可能会生成两个文档,并且永远不会发现第一个文档,因为只有第二个文档会被报告,因此,最好生成您自己的uuid以确保U_秷秷永远不会出现重复的文档,但除非您特别需要,否则我绝对会使用UUID。 documenta .

        6
  •  -1
  •   max    16 年前

    数据库中的主键不应该有任何“意义”,除非可能对序列进行编码。您可能想更改slug,但不想更改主键。

    有一个很好的理由可以使用以时间戳开始的东西来在您的键中具有固有的顺序。我经常使用“%f@%s”%(time(),hostname())获得有序的唯一密钥。(只有当time()实现从未两次返回相同的值时,这才有效。)

    对于其他的东西(例如图像),我想避免重复的地方,我经常使用sha(数据)作为键。