1

i decided to use mongo db for product catalog : mongo db product catalog ecosystem

hi i want to use mongdo db for product catalog but i have question ? i have a website for selling second hand products in 100 categories and all of my fields is selective means if user want to sell vehicles he should choose brand like "bmw,toyota" not directive

so for saving all details in one document if after 2 years or 3 years toyota should be change to toyooota and my records go ver 20 million records i should update all toyota too toyootas yeah ? so it update command is expensive for that data ,

so another way its key value be in another collection like 1:bmw 2:toyota

so make a realtion between the documents and if one day we decide to change toyota to tooyoota we only change 1 record not entire collection ?

so what you prefer huge update on big data , or make a relation between product catalog details and another collection for key value
and then in details we say

{
  title:"a good vehicle" 
  details:{
  brand:"1" // means bmw, if we decide to change bmw name we should change   brand name in another collection

  }

}

and another way is

{
  title:"good vehicle",
   details:{
   brand:"bmw" // if one day we want to changes all bmw to bmwn for example, then we need a huge update
   }
}

notice:that values are selective by users they cant input directly their brand names like ebay ,

what u prefer for this design in mongodb?

Community
  • 1
  • 1
babak faghihian
  • 1,169
  • 2
  • 13
  • 24
  • Changing your question completely is not the best way to communicate. You might want to [read this](http://www.catb.org/esr/faqs/smart-questions.html). Then, please [read this](https://docs.mongodb.org/manual/core/data-modeling-introduction/). Rinse and repeat. Ask again, then. Voting to close as off topic since it is too broad nd too less real information is given to make a proper answer possible. – Markus W Mahlberg Nov 15 '15 at 09:32
  • @MarkusWMahlberg i change the question for better read and give more information to readers so the question changed not because make attention its because i twitted the link of my questions in mongodb communities so if you read the change the root of question not changed – babak faghihian Nov 15 '15 at 09:42
  • @MarkusWMahlberg so the question root about catalog product and the codes not changed , only change the way for asking better question please read the change concept – babak faghihian Nov 15 '15 at 09:48
  • Your question is answered in the first link I gave you. Nobody knows your application, it's procedures and flows better than you. Tech yourself hot to fish instead of asking for one. – Markus W Mahlberg Nov 15 '15 at 12:31
  • @MarkusWMahlberg and can u tell me where exactly speak about performance? – babak faghihian Nov 15 '15 at 12:42
  • Jesus, do you need it predigested? Use your brain! 2 queries = worse performance than 1 query. Conclusion: try to reduce number of queries. How to achieve that? By NOT using references. – Markus W Mahlberg Nov 15 '15 at 12:48
  • @MarkusWMahlberg first of all be calm and use your brain too, its Double-edged Sword in one hand we have better update and in another hand we have faster queries but the question is what is the way for having update in lower time and have good fetching time ,using DbRefs is better ? or Updating 20 million records without db ref is better ? – babak faghihian Nov 15 '15 at 12:57
  • @MarkusWMahlberg and if you think i am not thinking i should tell u whats this link jesus, – babak faghihian Nov 15 '15 at 12:58
  • @MarkusWMahlberg http://stackoverflow.com/questions/18415749/updating-large-number-of-records-in-a-collection http://stackoverflow.com/questions/9412341/mongodb-is-dbref-necessary – babak faghihian Nov 15 '15 at 12:59

1 Answers1

5

Babak, This is a common question and I'm sorry to say that it doesn't have a definite answer; just "it depends on your use case."

I would recommend reading Kristina Chodorow's MongoDB: The Definitive Guide. It's a little dated, but it's doc design section is pretty timeless.

Here's a short explanation of the general consensus:

  1. Is your use case primarily queries? If so, embed the fields that you query. It's going to take more space and make any updates painful, but multiplying the amount of work the DB has to do for the bulk of your workload will make every day painful.
  2. Is your use case primarily updates? If so, then embed references. That will make updates easier at the expense of queries.
  3. Is your use case somewhere in between? Then do a combination of the two.

Remember that MongoDB relies heavily on application logic (your programmers) to solve many problems that traditional RDBMSs solve (schema enforcement, data types, etc). You can solve many problems in the app itself. The simple example that you provide isn't something that seems likely to happen and also can be easily solved within the application w/o doing anything in the database. I recommend some serious thought about what you absolutely need your database to do everyday and using that to drive your doc design or decision to replatform. Remember, every day that you defer is going to make your problem more impactful and harder to solve.

jtobs
  • 131
  • 1
  • thank you , my details field maybe 15-20 update in year and my updates is very low , but the question is how much it take for records under 50 million records if they indexed ?if 4 million records of 50 million should change ,how much does it take ? – babak faghihian Nov 17 '15 at 07:34
  • 1
    I'm not sure that I understand your question, but I have a feeling that the answer is "it depends." It would depend on the size of your updates and the size & structure of your documents. Also, it will depend on the storage engine that you use. My recommendation would be to use MongoDB's benchrun test harness to write a simple app to insert 50 million docs that have a structure like you're thinking. Then run an update statement and see "how much it takes," you'll also need to account for the fact that the server will be doing other tasks while this is running – jtobs Nov 18 '15 at 18:40