Does field name length matter?

Given the option to ingest hundreds of millions of documents with either abbreviated field name or expanded, is there any size difference or recommendation from couchbase about this?

In my organization, we have a rule where all field names should be abbreviated to save space when there are large volumes of data being ingested. This comes from the assumption that 1 character = byte even for the field names

For example, rather than

"name": "Legacy Brewing Co.",
"address": "525 Canal Street",
"city": "Reading",
"state": "Pennsylvania",
"website": "",
"description": "Brewing Company"

The recommendation is to use :

"nm": "Legacy Brewing Co.",
"ad": "525 Canal Street",
"cit": "Reading",
"st": "Pennsylvania",
"web": "",
"desc": "Brewing Company"

Do you have any optimization in place so that when two documents have the same definition, we only use the space of 1?

No, there is no optimisation like that thanks to the schema-less nature of the storage; no two documents need have the same set of fields, or indeed any common fields at all.

The field names are largely arbitrary to the server, except where they conflict with reserved words (must be quoted in SQL++ statements), so there is no specific recommendation.

But yes, longer field names do contribute to overall collection size.

You of course can make use of compression to save space.


1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.