Primary Exploration of MongoDB-basic concepts and data types

I. Basic Concepts 1. Document: MongoDB is a Document-based NoSQL database. A document is the basic unit of data in MongoDB and is very similar to rows in relational databases (more complex than rows ). A document consists of multiple key pairs that have the following features: a. The key pairs in the document are ordered (usually the order of the key keys in the document is not important ). B. In the document

I. Basic Concepts 1. Document: MongoDB is a Document-based NoSQL database. A document is the basic unit of data in MongoDB and is very similar to rows in relational databases (more complex than rows ). A document consists of multiple key pairs which have the following features: a. The key/pair in the document is ordered (generally, the order of the key keys in the document is not important ). B. In the document

I. Basic Concepts

1. Document: MongoDB is a Document-based NoSQL database. A document is the basic unit of data in MongoDB. It is very similar to a row in a relational database (more complex than a row ).

A document consists of multiple key-value pairs that have the following features:

A. Key/value pairs in the document are ordered (generally, the order of the key/value pairs in the document is not important ).

B. The values in the document can not only be strings in double quotes, but also several other data types (or even the entire embedded document ).

C. The document key is a string. Except for a few of the following, keys can use any UTF-8 character.

I. The key cannot contain \ 0 (null). This character is used to indicate the end of the key.

II. vertices (.) and $ have special meanings and can only be used in specific environments.

III. The key starting with the underscore "_" is the reserved key.

D. Key/value are case sensitive and case sensitive.

E. The keys cannot be repeated.

2. Set: a set of documents, similar to tables in a relational database. MongoDB collections have the following features:

A. No mode. Set mode-free means that documents in a set can be varied, but it is best to divide the set into multiple sets based on data features or business needs.

B. name. The set is identified by the name. The collection name can be any UTF-8 string that meets the following conditions:

I. The set name cannot be a null string.

II. The set name cannot contain \ 0 characters (null). This character indicates the end of the Set Name.

III. The set cannot start with "system.", which is the prefix reserved for the system set. For example, system. users stores the user information of the database, and system. namespaces stores the information of all database sets.

IV. The collection name created by the user cannot contain reserved characters $.

Sub-set: a convention for organizing a set is to use the "." character to separate sub-sets divided by namespace. For example, an application with the blog function may contain two sets: blog. posts and blog. authors. This makes it clear that posts and authors are part of a blog application. It doesn't matter whether a specific blog set exists, that is, the blog set has nothing to do with its child set. We recommend that you use child sets to organize data in MongoDB.

3. Database: a database consists of multiple sets. A MongoDB instance can carry multiple databases, which can be considered completely independent of each other. Each database has independent permission control. Even on a disk, they store different files. The database name can be any UTF-8 string that meets the following conditions:

A. cannot be a null string ("").

B. It cannot contain ''(Space),. (point), $,/, \, and \ 0 (null character ).

C. It should be in lower case.

D. A maximum of 64 bytes.

The database name will eventually become a file in the file system, so it will be limited by the above conditions. Some database names are retained and can be accessed directly. For example, if the admin has all permissions, the user in the database automatically inherits the permissions of all databases. The local database is used to store any set of local servers. This database will never be copied. The config database is used to save information about shards. This database is used when Mongo uses shard settings.

Namespace: database name + set name. The length cannot exceed 121 bytes. In actual use, it should be less than 100 bytes.

4. MongoDB Shell: The MongoDB shell is a built-in JavaScript shell that can interact with the MongoDB instance from the command line. It can be used to perform management operations and check running instances. MongoDB shell can be used as a JavaScript interpreter or a MongoDB client.

4.1 run shell. Start mongodbmongod, open another command window, and run cmd.exe. If the following interface appears, the operation is successful.

Note: When it is enabled, shell connects to the test database of the MongoDB server by default, and assigns the connection value to the global variable db. This variable is the main entry point for accessing MongoDB through shell. (Basic shell operations will be introduced later ).

Ii. Data Types

MongoDB supports multiple data types as values in the document. MongoDB documentation is expanded from JSON, which is similar to JavaScript objects. MongoDB adds other data types based on the Basic JSON key/value pairs.

1. Basic Data Types

A. null indicates a null value or a field that does not exist, for example, {"x": null }.

B. Boolean, which contains 'true' and 'false' values, for example, {"x": true }.

C and 32-bit integers cannot be used in Mongo Shell, because JavaScript only supports 64-bit floating point numbers, so 32 is automatically converted to integers.

D and 64-bit integers are not supported in Mongo Shell. shell uses a special embedded document to display 64-bit integers.

E, 64-bit floating point number, and shell digits are of this type. {"X": 3.14} and {"x": 3} are both floating point numbers.

F, String, UTF-8 string can be represented as string type data.

G, symbol, shell does not support this type, shell will convert the symbol type in the database to a string.

H. Object id. the Object id is the unique ID of 12 bytes of the document, for example, {"x": ObjectId ()}.

I. Date: the number of milliseconds since the standard epoch, not the time zone, for example, {"x": new Date ()}

J. Regular Expression. The document can contain regular expressions. The regular Syntax of JS is: {"x":/foobar/I}

K. Code. The document can contain JavaScript code.

L. binary data can be composed of any byte string, which cannot be used in shell.

M, maximum value, BSON is the document storage protocol used by MongoDB, it contains a special type, indicating the maximum possible. Shell does not have this type.

N. Minimum value. A special type included in BSON indicates the possible minimum value. Shell does not have this type.

O, undefined, {"x": undefined }.

P, array, the value set or list can be expressed as an array. For example, {"x": ["a", "B", "c"]}.

Q. embedded documents. documents can be embedded into documents. For example, {"x": {"foo": "bar "}}.

Note: The number in MongoDB is double precision by default. If you modify the integer in the document, it will go through the process of converting to a floating point even if its value remains intact, therefore, try not to overwrite the entire document in shell.

2. _ id and ObjectId. The document stored in MongoDB must have a _ id key. The value of this key can be of any type. The default value is the ObjectId object. Each document in a collection has a unique _ id value, which is the unique identifier of each document in the set.

ObjectId:ObjectId is the default type of _ id. Different machines can use the globally unique method to generate it conveniently. ObjectId uses a 12-byte storage space. Each byte has two hexadecimal numbers and is a 24-Bit String. The generation method is as follows:

I. The first four bytes are the timestamp starting from the standard epoch, in seconds. After combining with the next five bytes, the uniqueness is provided in seconds.

II. The next three bytes are the unique identifier of the host, usually the hash value of the host name. This ensures that different hosts generate different objectids to avoid conflicts.

III. The next two bytes are from the process identifier (PID) that generates the ObjectId. Ensure that the ObjectId generated by multiple concurrent processes on the same machine is unique.

IV. The first nine bytes ensure that the ObjectId generated by different processes on different machines is unique in the same second, and the last three bytes are automatically added counters, it is used to ensure that the ObjectId generated by the same process in the same second is also different. Each process can have a maximum of 256 ^ 3 (16 777 216) ObjectId in a second.

Automatic _ id generation: To enhance the scalability of the MongoDB database, the _ id generation is generally completed by the client driver. This can reduce the cost of the MongoDB server, in line with the MongoDB Design Philosophy: to transfer from the server side to the driver to do things, try to transfer. Because it is much easier to expand the application layer than to expand the database layer. Handing over the transaction to the client reduces the burden of database expansion. At the same time, you can use the rich APIs provided by the driver.