Gain an in-depth understanding of the Shell and documentation of MangoDB

1. MongoDB shell

MangoDB is actually a database shell. It is generally assumed that it runs on the same machine as mongod and that mongod is bound to the default port.

If this is not the case, you can specify these parameters at startup to connect the shell to another server:

 
 

  
  
mongo 192.168.10.10:10000 
 
 

In this way, mongod running on 192.168.10.10 and port 10000 will be connected.

Shell connects to the test database by default. To use another database, add the slash and database name after the server address:

Mongo 192.168.10.10: 10000/refactor

This will connect to the refactor database on 192.168.10.10: 10000.

You can also use the -- nodb option to start the shell, instead of connecting to any database, just try javascript

Mongo -- nodb

Db is by no means the only database. You can connect to any number of databases from the shell, which is convenient for multiple server environments. Call connect (),

And assign the result to the variable. For example, in the partition environment, you may want to use mongos to represent the mongos server and want to have a connection to each slice.

Follow these steps:

Mongos = connect ("127.0.0.1: 10000 ")

Shard0 = connect ("127.0.0.1: 10001 ")

Shard1 = connect ("127.0.0.1: 10002 ")

In this way, mongos, shard0, and shard1 can be used as db variables.

Shell Tool

For managing multiple databases, multiple database variables are more useful than simple databases, for example, in sharding,

To maintain a single variable that only requires Server Configuration:

Config = db. getSisterDB ("config ")

Config. shards. find ()

2. BSON

The document of MongoDB is an abstract concept. Its specific presentation form depends on the driver and programming language used.

Because the communication in MongoDB relies heavily on documents, a file expression that all drivers, tools, and processes can share is required.

This expression is called Binary JSON (BSON)

BSON is a lightweight binary format that represents all the documents in MongoDB as their own strings. The database can understand BSON and has files on disk.

This format is also used.

When the driver needs to insert a document or use the document as a query condition, the driver converts the document to BSON and then sends it to the server. Similarly, it returns the document to the client.

It is also a string in BSON format. The driver needs to decode the data, program the local file representation, and finally return it to the client.

There are three main reasons for using BSON:

A. Efficiency

BSON is designed to more effectively represent data and provide better space for the moment. In the worst case, BSON is slightly less efficient than JSON. In the best case (

For example, to store binary data or most of the data), BSON is much more efficient than JSON.

B. Traverse rows

Sometimes BSON sacrifices space efficiency in exchange for easier traversal formats. For example, add the length before the string, instead of using a terminator at the end.

This is useful for embedded documents of MongoDB.

C. Performance

BSON encoding and decoding are fast. It represents the type in a C-style representation and is fast in most programming languages.

2. MongoDB transmission protocol

Based on the TCP/IP protocol, the driver simply encapsulates the MongoDB transmission protocol for interaction with MongoDB.

The MongoDB transmission protocol is basically a simple encapsulation of BSON data. For example, a message is inserted with 20 bytes of header data (including

Inform the server of the Code for executing the write operation, the message length, the set name to be inserted, and the list of BSON documents to be inserted)

3. Data Files

In the data directory of MongoDB, each database has several independent files. Each data has a. ns file and several data files.

Therefore, the database refactor is stored in files such as refactor. ns, refactor.0, and refactor.1.

The size of each new data file ending with a number will be doubled until the maximum value is 2 GB. This is to prevent small databases from wasting too much disk space,

At the same time, it allows large databases to use contiguous disk space.

Apsaradb for MongoDB pre-allocates data files to ensure performance (you can use -- norealloc to disable this function). Pre-allocates data files in the background.

This means that the MongoDB Server Always keeps an extra empty data file in each database to avoid

Blocking caused by file allocation.

4. namespaces and data domains

In a data file, each database is organized according to the namespace. Data of one type is stored separately from other types.

Your own namespace, and the index is also. the metadata of the namespace is stored in the. ns file of the database.

Data in each namespace is divided into several groups and placed in a region of the data file. This region becomes a data domain.

:

Database foo has three data files, of which 3rd are pre-allocated Empty files. The first two data files are divided into several data fields and belong to several different namespaces.

Each namespace can have several different data domains and does not need to be contiguous on the disk. It is similar to the data file of the database.

The data domain size is also increased. This is to balance the control that is wasted in the namespace and try to make the data of a namespace continuously.

There is also a special namespace $ freelist in the figure, which stores the data domains that are no longer in use (such as the data domains generated by deleting a set or index ).

When a namespace is allocated with a new data field, the system first looks for the idle list to see if there is any suitable data field available.

5. Inner-slave ing storage engine

The default storage engine of MongoDB is the memory ing engine. When the server is started, all data files are mapped to the memory, and then the Operating System

Writes buffered data to the disk and transfers the data to the Memory Page.

Such empathy has several important characteristics:

A) The MongoDB memory management code is very refined because most of the work is handed over to the operating system.

B) the virtual SIZE OF THE MongoDB server process is usually very large and exceeds the size of the entire dataset,

Because the operating system will process the data stored in the memory.

C) MongoDB cannot control the order in which data is written to the disk, so it cannot use pre-write logs to provide standalone persistence.

D) A 32-bit MongoDB server has a limit. Each mongod can process up to 2 GB of data, because all data must be accessed using a 32-bit address.

Edit recommendations]

1. MongoDB 2.0 official version released
2. View the Compact Command one by one in the new functions of MongoDB 2.0
3. Comprehensive Evaluation of mainstream NoSQL databases-MongoDB
4. How to use MySQL to learn MongoDB
5. MongoDB setup and simple operations in Windows