Performance of Long IDs

后端 未结 2 1080
醉酒成梦
醉酒成梦 2021-01-13 05:19

I\'ve been wondering about this for some time. In CouchDB we have some fairly log IDs...eg:

\"000ab56cb24aef9b817ac98d55695c6a\"

Now if we\'re searching for

2条回答
  •  太阳男子
    2021-01-13 06:00

    From the CouchDB: The definitive guide book:

    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.

    So sequential IDs offer a performance benefit, however, you must remember this isn't maintainable when you have more than one database, as the IDs will collide.

提交回复
热议问题