MongoDB_blog Ⅰ

Attribution: MongoDB: The Definitive Guide, Third Edition by Shannon Bradshaw, Eoin Brazil, and Kristina Chodorow (O’Reilly). Copyright 2020 Shannon Bradshaw and Eoin Brazil, 978-1-491-95446-1.

Before Getting Started

In this Blog we’ll introduce some of the basic concepts of MongoDB

Documents

At the heart of MongoDB is the document: an ordered set of keys with associated values.

The representation of a document varies by programming language, but most languages have a data structure that is a natural fit.

In JavaScript, for example, documents are represented as objects:

{"greeting" : "Hello, MongoDB!"}

This simple document contains a single key, "greeting", with a value of "Hello, MongoDB!".

In multiple key/value pairs:

{"greeting" : "Hello, MongoDB!", "views" : 7}

As we can see, values in documents can be one of several different data types (or even an entire embedded document—see “Embedded Documents”). In this example the value for "greeting" is a string, whereas the value for "views" is an integer.

The keys in a document are strings. Any UTF-8 character is allowed in a key, with a few notable exceptions:

Keys must not contain the character \0 (the null character). This character is used to signify the end of a key.

The . and $ characters have some special properties and should be used only in certain circumstances, as described in later chapters. They should be considered reserved, and drivers will complain if misused.

MongoDB is type-sensitive and case-sensitive. For example, these documents are distinct:

{"count" : 7}
{"count" : "7"}

as are these:

{"count" : 7}
{"Count" : 7}

And documents in MongoDB cannot contain duplicate keys. For example, the following is not a legal document:

{"greeting" : "Hello, world!", "greeting" : "Hello, MongoDB!"}

Collections

A collection is a group of documents. If a document is the MongoDB analog of a row in a relational database, then a collection can be thought of as the analog to a table.

Dynamic Schemas

The documents within a single collection can have any number of different “shapes”.

e.g. both of the following documents could be stored in a single collection:

{"greeting" : "Hello, MongoDB!", "views": 7}
{"signoff": "Good night, and good luck!"}

Note that the previous documents have different keys, different numbers of keys, and values of different types.

You may want to ask: “Why do we need separate collections at all?”

With no need for separate schemas for different kinds of documents, why should we use more than one collection? There are several good reasons:

Developers need to make sure that each query is only returning documents adhering to a particular schema or that the application code performing a query can handle documents of different shapes.

It’s much faster to get a list of collections than to extract a list of the types of documents in a collection.

For example, if we had a "type" field in each document that specified whether the document was a “skim,” “whole,” or “chunky monkey,” it would be much slower to find those three values in a single collection than to have three separate collections and query the correct collection.

Grouping documents of the same kind together in the same collection allows for data locality.

We begin to impose some structure on our documents when we create indexes. (This is especially true in the case of unique indexes.) These indexes are defined per collection. By putting only documents of a single type into the same collection, we can index our collections more efficiently.

Naming

A collection is identified by its name. Collection names can be any UTF-8 string, with a few restrictions:

The empty string ("") is not a valid collection name.

Collection names may not contain the character \0 (the null character), because this delineates the end of a collection name.

You should not create any collections with names that start with system., a prefix reserved for internal collections.

For example, the system.users collection contains the database’s users, and the system.namespaces collection contains information about all of the database’s collections.

User-created collections should not contain the reserved character $ in their names.

The various drivers available for the database do support using $ in collection names because some system-generated collections contain it, but you should not use $ in a name unless you are accessing one of these collections.

SUBCOLLECTIONS

One convention for organizing collections is to use namespaced subcollections separated by the . character.

For example, an application containing a blog might have a collection named blog.posts and a separate collection named blog.authors.

This is for organizational purposes only—there is no relationship between the blog collection (it doesn’t even have to exist) and its “children.”

Although subcollections do not have any special properties, they are useful and are incorporated into many MongoDB tools. For instance:

GridFS, a protocol for storing large files, uses subcollections to store file metadata separately from content chunks.

Most drivers provide some syntactic sugar for accessing a subcollection of a given collection.

Subcollections are a good way to organize data in MongoDB for many use cases.

Databases

In addition to grouping documents by collection, MongoDB groups collections into databases. A single instance of MongoDB can host several databases, each grouping together zero or more collections.

A good rule of thumb is to store all data for a single application in the same database. Separate databases are useful when storing data for several applications or users on the same MongoDB server.

Like collections, databases are identified by name. Database names can be any UTF-8 string, with the following restrictions:

The empty string (“”) is not a valid database name.

A database name cannot contain any of these characters: /, **, ., ", ***, <, >, :, |, ?, $, (a single space), or \0 (the null character). Basically, stick with alphanumeric ASCII.

Database names are case-insensitive.

Database names are limited to a maximum of 64 bytes.

There are also some reserved database names, which you can access but which have special semantics. These are as follows:

admin

The admin database plays a role in authentication and authorization. In addition, access to this database is required for some administrative operations.

local

This database stores data specific to a single server. In replica sets, local store data are used in the replication process. The local database itself is never replicated.

config

Sharded MongoDB clusters use the config database to store information about each shard.

By concatenating a database name with a collection in that database you can get a fully qualified collection name, which is called a namespace. Namespaces are limited to 120 bytes in length and, in practice, should be fewer than 100 bytes long.