Home/ Questions/Q 596703
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T16:12:01+00:00

I’ve been wondering about this for some time. In CouchDB we have some fairly

  • 0

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 this item and going through the tree structure created by the view. It seems a simple integer as an id would be much faster. If we used 64bit integers it would be a simple CMP followed by a JMP (assuming that the Erlang code was using JIT, but you get my point).

For strings, I assume we generate a hash off the ID or something, but at some point we have to do a character compare on all 33 characters…won’t that affect performance?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The short answer is, yes, of course it will affect performance, because the key length will directly impact the time it takes to walk down the tree.

    It also affects storage, as longer keys take more space, space takes time.

    However, the nuance you are missing is that while Couch CAN (and does) allocated new IDs for you, it is not required to. It will be more than happy to accept your own IDs rather than generate it’s own. So, if the key length bothers you, you are free to use shorter keys.

    However, given the “json” nature of couch, it’s pretty much a “text” based database. There’s isn’t a lot of binary data stored in a normal Couch instance (attachments not withstanding, but even those I think are stored in BASE64, I may be wrong).

    So, while, yes an 64-bit would be the most efficient, the simple fact is that Couch is designed to work for any key, and “any key” is most readily expressed in text.

    Finally, truth be told, the cost of the key compare is dwarfed by the disk I/O fetch times, and the JSON marshaling of data (especially on writes). Any real gain achieved by converting to such a system would likely have no “real world” impact on overall performance.

    If you want to really speed up the Couch key system, code the key routine to block the key in to 64Bit longs, and comapre those (like you said). 8 bytes of text is the same as a 64 bit “long int”. That would give you, in theory, an 8x performance boost on key compares. Whether erlang can create such code, I can’t say.

    • 0