Physical Data Modeling - Data Modeling for MongoDB - page 161

Note that because Type 1 is requested for both Department and Calendar , our data model
does not need to change and remains with the same structure as our prior step:
STEP 3: INDEX AND SHARD
The primary and alternate keys from our logical data model are converted into unique in-
dexes on the physical. We can also add additional indexes for performance, called sec-
ondary or non-unique indexes. For example, if there is a continuous need to see custom-
erLastName and customerFirstName , we can add indexes to these fields to reduce the
amount of time it takes to retrieve.
Partitioning (called “sharding” in MongoDB) is when a document is split up into two or
more parts. Vertical partitioning is when fields are split up and horizontal is when docu-
ments are split up. Frequently, both horizontal and vertical are used together. That is, when
splitting documents apart, in many cases we learn that certain fields only belong with cer-
tain documents.
Both vertical and horizontal partitioning are common techniques when building analytics
systems. A collection might contain a large number of fields and perhaps only a subset are
volatile and change often, so this subset can be vertically partitioned into a separate collec-
tion. Or we might have ten years of orders in a table, so to improve query performance we
horizontally partition by year so that when queries are run within a given year, the perform-
ance will be much faster.
For Relational
For our relational physical data model, these attributes are queried frequently and therefore
need non-unique indexes: customerFirstName and customerLastName (we added a
composite index [6] on both of these attributes), customerTypeCode , accountTypeCode ,
branchCode , and accountName :