Stabbing at mongo in the dark

I picked up MongoDB the other day. I think I got what I wanted from the exercise. What were the surprises, though?

1. In the javascript shell, you need the right arrangement of current database and collection before you see anything interesting. When you’re doing db.record_baskets and seeing nothing, even though you know there’s a record_baskets collection, for me that was because I was in the wrong database. Doing “use mydb” sorted things out.
2. When you save a record, it’s only if you explicitly say what to replace that you get a replacement operation. Otherwise you just add another record, and then when you search by whatever your condition is you’ll get two records. It took me a while to work this one out because my records were big-ol arrays, so it wasn’t entirely obvious that there was two of them.
3. There’s some crazy magic around index construction. Like, totally crazy. I did a search for {i: 1234}. It took 237 seconds. I did an ensureIndex for {i: 1}. It took half a second. Then repeating the search took no time at all. How come the linear scan took so long, but index construction so little? I have two theories. The first is that there’s some heuristical thing that mongo uses to decide when to make indexes, and it made an index in the process of issuing the first query, so ensureIndex didn’t actually have to do anything. The second is that the data storage format is such that all of the i-values were stored in an arrangement that was already usable as an index, so it was able to recognize that, mark it as an index, and use it as such without actually doing much rearranging.

Also, the modifier operations are really neat and I want to do something that uses them to the fullest extent.

So, that was fun.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s