1. Every document has a special key, "_id", that is unique across the document's collection.
2. Key/value pairs in documents are ordered.
{"foo" : 3, "greeting" : "Hello, world!"}
{"greeting" : "Hello, world!", "foo" : 3}
这两条document不相同.
3. The keys in a document are strings. Any UTF-8 character is allowed in a key, with a
few notable exceptions:
3.1 Keys must not contain the character \0 (the null character). This character is used
to signify the end of a key.
3.2 The . and $ characters have some special properties and should be used only in
certain circumstances, as described in later chapters. In general, they should be
considered reserved, and drivers will complain if they are used inappropriately.
3.3 Keys starting with _ should be considered reserved; although this is not strictly
enforced.
3.4 MongoDB is type-sensitive and case-sensitive. For example, these documents are
distinct:
{"foo" : 3}
{"foo" : "3"}
As are as these:
{"foo" : 3}
{"Foo" : 3}
4. A final important thing to note is that documents in MongoDB cannot contain duplicate
keys. For example, the following is not a legal document:
{"greeting" : "Hello, world!", "greeting" : "Hello, MongoDB!"}
5. Collections are schema-free. This means that the documents within a single collection
can have any number of different “shapes.”
For example, both of the following documents could be stored in a single collection:
{"greeting" : "Hello, world!"}
{"foo" : 5}
6. Note that the previous documents not only have different types for their values (string
versus integer) but also have entirely different keys. Because any document can be put
into any collection, the question often arises: “Why do we need separate collections at
all?” It’s a good question—with no need for separate schemas for different kinds of
documents, why should we use more than one collection? There are several good
reasons:
6.1 Keeping different kinds of documents in the same collection can be a nightmare
for developers and admins. Developers need to make sure that each query is only
returning documents of a certain kind or that the application code performing a
query can handle documents of different shapes. If we’re querying for blog posts,
it’s a hassle to weed out documents containing author data.
6.2 It is much faster to get a list of collections than to extract a list of the types in a
collection. For example, if we had a type key in the collection that said whether
each document was a “skim,” “whole,” or “chunky monkey” document, it would
be much slower to find those three values in a single collection than to have three
separate collections and query for their names (see “Subcollections”
on page 8).
6.3 Grouping documents of the same kind together in the same collection allows for
data locality. Getting several blog posts from a collection containing only posts will
likely require fewer disk seeks than getting the same posts from a collection con-
taining posts and author data.
6.4 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.
As you can see, there are sound reasons for creating a schema and for grouping related
types of documents together. MongoDB just relaxes this requirement and allows de-
velopers more flexibility.
7. Naming
A collection is identified by its name. Collection names can be any UTF-8 string, with
a few restrictions:
7.1 The empty string ("") is not a valid collection name.
7.2 Collection names may not contain the character \0 (the null character) because
this delineates the end of a collection name.
7.3 You should not create any collections that start with system., a prefix reserved for
system 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.
7.4 User-created collections should not contain the reserved character $ in the name.
The various drivers available for the database do support using $ in collection
names because some system-generated collections contain it. You should not use
$ in a name unless you are accessing one of these collections.
8. Subcollections
One convention for organizing collections is to use namespaced subcollections sepa-
rated 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 incor-
porated into many MongoDB tools:
8.1 GridFS, a protocol for storing large files, uses subcollections to store file metadata
separately from content chunks
8.2 The MongoDB web console organizes the data in its DBTOP section by
subcollection
8.3 Most drivers provide some syntactic sugar for accessing a subcollection of a given
collection. For example, in the database shell, db.blog will give you the blog col-
lection, and db.blog.posts will give you the blog.posts collection.
Subcollections are a great way to organize data in MongoDB, and their use is highly
recommended.
有点类似PostgreSQL中，表继承的概念.
9. Databases
In addition to grouping documents by collection, MongoDB groups collections into
databases. A single instance of MongoDB can host several databases, each of which can
be thought of as completely independent. A database has its own permissions, and each
database is stored in separate files on disk. 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 application 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:
9.1 The empty string ("") is not a valid database name.
9.2 A database name cannot contain any of these characters: ' ' (a single space), ., $, /,
\, or \0 (the null character).
9.3 Database names should be all lowercase.
9.4 Database names are limited to a maximum of 64 bytes.
One thing to remember about database names is that they will actually end up as files
on your filesystem. This explains why many of the previous restrictions exist in the first
place.
9.5 There are also several reserved database names, which you can access directly but have
special semantics. These are as follows:
admin
This is the “root” database, in terms of authentication. If a user is added to the
admin database, the user automatically inherits permissions for all databases.
There are also certain server-wide commands that can be run only from the ad-
min database, such as listing all of the databases or shutting down the server.
local
This database will never be replicated and can be used to store any collections that
should be local to a single server .
config
When Mongo is being used in a sharded setup , the config database
is used internally to store information about the shards.
By prepending a collection’s name with its containing database, you can get a fully
qualified collection name called a namespace. For instance, if you are using the
blog.posts collection in the cms database, the namespace of that collection would be
cms.blog.posts. Namespaces are limited to 121 bytes in length and, in practice, should
be less than 100 bytes long.