0

Sometime, we have many fields and large data set in DB (i am using mongoDB). One thing come in my mind regarding to save some bytes in DB by keeping shorten name in DB. Like

year : yr

Month : mn

isSameCity : isSmCt

So, Is this approach good or bad. Or, that depends on case base.

Please mentor me on this.

Vikas Gupta
  • 35
  • 5
  • 1
    It's very trivial in terms of performance. Attribute names should be descriptive to someone who knows nothing about the database, so I'd go with the full name. – n1c9 Jan 09 '18 at 05:21

3 Answers3

4

One common performance optimization strategy with MongoDB is to use short field names in documents.

That is, instead of creating a document that looks like this...

{first_name: "Jon", last_name: "Hyman"}

Use shorter field names so that the document might look like...

{fn: "Jon", ln: "Hyman"}

Since MongoDB doesn't have a concept of columns or predefined schemas, this structure is advantageous because field names are duplicated on every document in the database. If you have one million documents that each have a "first_name" field on them, you're storing that string a million times. This leads to more space per document, which ultimately impacts how many documents can fit in memory and, at large scale, may slightly impact performance, as MongoDB has to map documents into the memory as it reads them.

Referred from objectrocket

Community
  • 1
  • 1
Irshad Khan
  • 5,670
  • 2
  • 44
  • 39
1

Long named attributes (or, "AbnormallyLongNameAttributes") can be avoided while designing the data model. In my previous organisation we tested keeping short named attributes strategy, such as, organisation defined 4-5 letter encoded strings, eg:

  1. First Name = FSTNM,
  2. Last Name = LSTNM,
  3. Monthly Profit Loss Percentage = MTPCT,
  4. Year on Year Sales Projection = YOYSP, and so on..)

While we observed an improvement in query performance, largely due to the reduction in size of data being transferred over the network, or (since we used JAVA with MongoDB) the reduction in length of "keys" in MongoDB document/Java Map heap space, the overall improvement in performance was less than 15%.

In my personal opinion, this was a micro-optimzation that came at an additional cost (huge headache) of maintaining/designing an additional system of managing Data Attribute Dictionary for each of the data models. This system was required to have an organisation wide transparency while debugging the application/answering to client queries.

If you find yourself in a position where upto 20% increase in the performance with this strategy is lucrative to you, may be it is time to scale up your MongoDB servers/choose some other data modelling/querying strategy, or else to choose a different database altogether.

Akshay
  • 41
  • 3
0

To quote Donald Knuth:

Premature optimization is the root of all evil (or at least most of it) in programming.

Build your application however seems most sensible, maintainable and logical. Then, if you have performance or storage issues, deal with those that have the greatest impact until either performance is satisfactory or the law of diminishing returns means there's no point in optimising further.

If you are uncertain of the impact of particular design decisions (like long property names), create a prototype to test various hypotheses (like "will shorter property names save much space"). Don't expect the outcome of testing to be conclusive, however it may teach you things you didn't expect to learn.

Referred from: Is shortening MongoDB property names worthwhile?

Akshay Kolhapure
  • 9
  • 2