CODEWITHSUNDEEP
mongodb
user4951
user4951

Reputation: 33090

How to properly store data we want to index in mongodb

I have businesses collection.

The business are reviewed by users.

Each user can only review a business once. Future reviews will simply replace the former one.

This is how we store it

 "Reviews" : {
    "gusyanto" : {
      "day" : "December 21, 2012, 8:08 am",
      "review" : "Tes review"
    },
    "sapi" : {
      "day" : "December 21, 2012, 8:18 am",
      "review" : "makanan ini sangat enak"
    }
  }

Alternatively we can also use this

 "Reviews" : [{
      "userid" : "gusyanto",
      "day" : "December 21, 2012, 8:08 am",
      "review" : "Tes review"
    },
    {
      "userid" : "sapi",
      "day" : "December 21, 2012, 8:18 am",
      "review" : "makanan ini sangat enak"}
    ]
  }

So basically we want can store it as a dictionary where the key is the userid or we can store it as an array where userID is the field key. So the key in the second approach is static namely userID.

We want to index the entries. For example, a user may want to know what businesses he has reviewed.

Which approach I should use?

Upvotes: 0

Views: 92

Answers (2)

vivek
vivek

Reputation: 5219

Well I'd do it like this:

                          reviews (collection)
                                  |
                                  |
                    ______________|______________
                   |                             |
                 Doc 1                        Doc 2
  {"user_id": "USer1",                      {"user_id": "USer2",
   "review" : "Tes review",                  "review" : "makanan ini sangat enak",
   "date"   : "December 21, 2012, 8:08 am",  "date"   : "December 21, 2012, 8:08 am",
   "business": "Business1"                   "business": "Business2"
  }                                         }

And then you could build an index as follow:

  db.reviews.ensure_index([("user_id", ASCENDING), ("date", ASCENDING)])
  db.reviews.ensure_index([("business", ASCENDING), ("date", ASCENDING)])

Now you can perform queries(in log(n) time) such as:

  1. Get all reviews for by User1 sorted by date.
  2. Get reviews for a business sorted by date.

Update:

Assuming you instead chose to do something like this:

                          Businesses (collection)
                                  |
                                  |
                    ______________|______________
                   |                             |
             BusinessDoc 1                    BusinessDoc 2
  {"business": "business1",                      {"user_id": "business",
   "review" : {..business1 reviews here..},     "review" : {..business2 reviews here..},
  }                                         }

I will suggest you against putting all the reviews for a business, say "B1" in a single doc, which is what will happen if you have a "Businesses" collection.

Why not a 'Business' collection:

  1. It'll make your queries and indexes complicated, and
  2. If there are just too many reviews for a very popular 'BusinessX', it'll hit the 16MB limit.

Upvotes: 2

Sammaye
Sammaye

Reputation: 43884

I am going to take your docs as they are, an example; however, I would like to mention that storing date in string format might hurt your index and querying abilities.

The problem with making an index on the Reviews field here is that review content field you have.

I can easily image that being too big for a single index field, in which case an exception will be thrown and it will not be indexed ( http://docs.mongodb.org/manual/reference/limits/#Index%20Size and http://docs.mongodb.org/manual/core/indexes/#indexes-on-sub-documents ). This is probably one of the biggest problems with full text fields in MongoDB.

So with that in mind I already would not advise forming an index on the field itself.

But, as to which index is best is extremely subjective to your querying.

If you were only querying by one field or the other, i.e. day or userid then I would make two separate indexes, however if you are combining your fields in your queries I would most likely go for a compound edition of the index.

Upvotes: 1

Related Questions