Background Index Creation in MongoDB

Lecture Notes

As of MongoDB 2.6, background index creation will occur on secondaries as well as
the primary when a background index is created on the primary of a replica set.

Text Indexes in MongoDB

Lecture Notes

In this lesson, Dwight uses ensureIndex.
This command has been deprecated in favor of createIndex.

Geospatial Indexes in MongoDB.

Lecture Notes

In this lesson, Dwight uses ensureIndex. This command has been deprecated in favor of createIndex

TTL Indexes in MongoDB.

Sparse Indexes in MongoDB

Lecture Notes

In this video, Dwight uses the ensureIndex command, which is now deprecated. You would now use createIndex.

Quiz

Quiz: Sparse Indexes

If an index is unique AND sparse, can 2 documents which do
not include the field that is indexed exist in the same collection?
Yes

No


Ans.

Yes

Unique Indexes in MongoDB

Lecture Notes
In this video, Dwight uses the ensureIndex command, which is now deprecated. You would now use createIndex.

Quiz

Quiz: Unique Indexes

If an index is created with the options document, { unique : true } can 2 documents which do not include the field that is indexed exist in the same collection?
Yes

No
Ans.

NO

Index Notes in mongoDB

Lecture Notes
In this video, Dwight mentions that the index is used automatically if it is present. This is no longer always true if you are sorting using a sparse index, but remains true otherwise. He also uses the ensureIndex command, which is deprecated as of MongoDB 3.0 in favor of createIndex
Quiz: Index Notes
A MongoDB index can have keys of different types (i.e., ints, dates, string)
1.True
2.False


Ans.
True
Advance on Index Notes in MongoDB

Collection Scans in MongoDB

createIndex(), getIndexes() & dropIndex() functions in mongoDB

Lecture Notes
As of mongodb 3.0, ensureIndex() is deprecated, though it will still work; you should use createIndex() instead. If you use ensureIndex with mongodb 3.0, it will point to createIndex.
Quiz: createIndex(), getIndexes() & dropIndex()
What will happen if an index is created on a field that does not exist in any of the documents in the collection?
1.MongoDB will throw an error and not create the index.
2.MongoDB will create the index but give a warning.
3.MongoDB will not create the index and not throw an error.
4.MongoDB will ask if you're sure first.
5.MongoDB will create the index without any warning.


Ans.


5.MongoDB will create the index without any warning.

Storage Engine: WiredTiger in mongoDB

Quiz: Storage Engine: WiredTiger
In MongoDB 3.0, the WiredTiger storage engine brings which of the following to MongoDB? Check all that apply.
1.Document-level concurrency control
2.Compression
3.Replication


Ans.

1.Document-level concurrency control

2.Compression

Answer

The only incorrect answer is replication, which has been, and remains, available for MongoDB for all supported releases of the server.

MMAPv1: Documents and Data Files in mongoDB

Lecture Notes
At approximately 7:40, I say that document moves might leave 'holes in your document...' I meant holes in your data files.

Quiz: MMAPv1: Documents and Data Files

Relative to no padding, Power of Two Sized Allocations in MMAPv1 provides which of the following benefits? Check all that apply.
1.Document movement need no longer result in updates to your indexes.
2.Record spaces are likely to get re-used.
3.Documents will not have to move as soon as they grow in size.
4.Documents that grow at a constant rate will move less often as time goes on.

Ans.


2.Record spaces are likely to get re-used.
3.Documents will not have to move as soon as they grow in size.
4.Documents that grow at a constant rate will move less often as time goes on.

Answer
The following answers are correct:
Documents will not have to move as soon as they grow in size. - This is because you have some space to grow before you reach your record size.
Record spaces are likely to get re-used. - Without standardized sizes, the likelihood that your new document will want the same size of record space as an old document might be slim, especially if your documents have different sizes (which they will if they're all growing). With standard sizes, all documents are likely to find record spaces that fit them.
Documents that grow at a constant rate will move less often as time goes on. - This makes sense, if you think about it. If your documents start out at an average size of 20 bytes, and grow at a rate of 1 byte per day, your first move will happen in 12 days (since the smallest record size is 32 bytes). Your second move will take 32 days, and your third will take 64. Each successive move will take longer and longer.
The incorrect answer is:
Document movement need no longer result in updates to your indexes. - this is not true for MMAPv1.

MMAPv1: Documents and Data Files in mongoDB

Storage Engine: MMAPv1 in mongoDB

Quiz: Storage Engine: MMAPv1

To understand MMAPv1, it is important to know that it:
1.Maps data files directly into virtual memory.
2.Maps data coming through the socket directly onto disk.
3.Maps JSON directly to BSON.
4.Maps compressed data files directly into BSON.
5.Maps data files directly into physical memory.

Ans.
5.Maps data files directly into virtual memory.

Chapter- 3 Storage Engine: Introduction

The storage engine directly determines which of the following? Check all that apply.
1.The wire protocol for the drivers
2.Format of indexes
3.Architecture of a cluster
4.The data file format

Ans.
2.Format of indexes
4.The data file format
The storage engine handles the interface between the database and the hardware, and by hardware, we mean specifically memory and disk, and any representations of the data (or metadata) that is located there, which is to say the data and indexes.
The data file format - The data files' format is determined by the storage engine, so this choice is correct. Different storage engines can implement different types of compression, and different ways of storing the BSON for mongoDB.
Architecture of a cluster - We picked false here, but you might argue with this choice. The architecture of the cluster is determined by interactions between servers, which communicate over the wire. Since the storage engine doesn't affect the wire protocol, the server architecture could be exactly the same, which is why we went with false. Even so, one might argue that a good choice of storage engine should result in a smaller cluster to handle the same workload. If your gut was to go with true for this reason, that's a defensible choice.
The wire protocol for the drivers - False. The wire protocol determines how servers communicate with each other, or with the applications. This is clearly outside of the storage engine.
Format of indexes - True. It may not be obvious when you first think about it, but indexes are controlled by the storage engine. For instance, MongoDB uses Btrees. With MongoDB 3.0, WiredTiger will be using B+ trees, with other formats expected to come in later releases.