MongoDB Advanced-Correlation query

"Suzhou needs to work to add me QQ, the introduction of fee-splitting" MongoDB advanced

1. Database commands

A. How the command works

Drop command to delete a collection in the shell and Execute Db.refactor.drop (). Actually, this function actually runs the drop command,

You can use RunCommand to achieve the same effect:

Db.runcommand ({"Drop": "Refactor"})

{"Nindexeswas": 1, "MSG": "Indexes dropped for collection", "ns": "Test.refactor", "OK The response to the ": 1} command is a document that contains information about whether the command was executed successfully, and possibly some other command output." Response document for the command

There is a "OK" key. The OK key has a value of 1 for success, 0 for execution failure, and a "errmsg" key when it is 0 o'clock.

Its value indicates why the command failed.

The commands in MongoDB are actually implemented as a special type of query that is executed against the $cmd collection. RunCommand

Just accept the command document and execute the equivalent query, so the drop call is actually like this:

Db. $cmd. FindOne ({"Drop": "Refactor"})

When the MongoDB server gets a request to query the $cmd collection, it starts a set of special logic to handle, rather than handing it over to the normal query code.

Almost all MongoDB drivers provide a runcommand-like Help method to execute commands, and if necessary, you can use a

Simple query to run the command.

Access to some commands requires administrator privileges and must be run in the admin database.

b) to get an up-to-date list of all commands, you can run Db.listcommands () in the shell,

You can also use Http://localhost:28017/_commands

2. Fixed set

MongoDB not only supports common collections, but also supports fixed sets, which are created in advance and fixed in size.

Fixed sets like a circular queue, if there is not enough space, the earliest documents are deleted, providing space for the new document.

Fixed sets automatically retire the oldest document when a new document is inserted.

Fixed collections cannot delete documents (except auto-obsolete documents), and updates (size increases) will cause the document to move.

The documents in the pinned collection are stored in the order in which they were inserted without maintaining a deleted document free space list.

Fixed collections do not have indexes by default, even on "_id".

A. Properties and usage of fixed collections

Inserts to a fixed set are fast, and when you do insert, you don't need to allocate extra space, and the server doesn't have to find a free list to place the document.

Insert the document directly at the end of the collection, and overwrite the old one if necessary. By default, the index is not updated.

Queries that are output to a fixed set in order of insertion are fast enough that the document itself is stored in the order in which it is inserted, according to this

Sequential queries are traversed, and the order in which the results are returned is the order of the documents on disk. By default, locating a fixed collection is

Results are returned in the order in which they were inserted.

Fixed sets can automatically retire the oldest data when new data is inserted. Insert Fast, follow the Insert Order query also quickly, automatically obsolete, these several

Properties combine to make a fixed set particularly suitable for applications such as logs. In fact, the purpose of designing a fixed collection in MongoDB

is used to store the internal replication log oplog. Fixed collections There is also a use to cache a small number of documents, in general, fixed collections

Use the scene with any that you want to automatically retire the expiration attribute.

B. Creating a fixed collection

The fixed collection must be created before it is displayed.

Such as:

Db.createcollection ("refactorcapped", {"capped": true,size:100000,max:100})

The above command creates a fixed set of refactorcapped, with a size of 100000 bytes and a maximum of 100 documents.

When you specify an upper limit for the number of documents, you must specify both the size. The elimination mechanism will only work based on the number of documents when the capacity is not yet full.

If the capacity is full, the elimination mechanism will be based on capacity to work.

You can convert a normal collection to a fixed set, such as converting a collection of blogs into a fixed set of 10000 bytes

Db.runcommand ({converttocapped: "blog", size:10000})

C. Natural sorting

The ordering of fixed collections is called natural sorting. The natural sort is the order of the documents on disk.

Because the documents of a fixed collection are always stored in the order in which they are inserted, this is the natural order. By default,

When you query a pinned collection, you return the document in the order in which it was inserted. You can also use natural sorting to query in reverse-insert order

Such as

Db.blog.find (). Sort ({"$natural":-1})

3.GridFS

Gridfs is a mechanism for storing binary files in MongoDB, using Gridfs to save files:

Gridfs can directly take advantage of the established replication or fragmentation mechanism, which is easy to recover and extend for file storage

Gridfs can avoid some problems with the file system that is used to store user uploads, such as Gridfs there is no problem in placing a large number of files in the same directory.

Gridfs does not produce disk fragmentation because MongoDB allocates data file space in 2GB.

A. Using Gridfs

The simplest way to use Gridfs is to use mongofiles.mongofiles to upload, download, list, find, and delete files in Gridfs.

You can get help with Mongofiles--help

Such as:

b) Internal principle

Gridfs is a lightweight file storage specification built on ordinary MongoDB documents. The MONGODB server actually requests the GRIDFS and the normal

Requests, all related work is done by the client driver or the tool.

The basic idea of Gridfs is that large files can be partitioned into chunks, each stored as a single document, so that large files can be stored. Because MongoDB

Support for storing binary data in documents minimizes the storage overhead of blocks. In addition to storing the file itself quickly, there is a separate document to

Stores the chunked information and the metadata of the file.

Gridfs blocks have a separate collection, and by default, blocks will use the Fs.chunks collection, which can be overwritten if needed. The structure of the document within this block is simple

{

"_id": ObjectId ("...."),

"N": 0,

"Data": Binddata ("..."),

"files_id": ObjectId ("....")

}

Like other MongoDB documents, blocks have their own unique "_id". The files_id key is the "_id" of the file document that contains this block metadata.

N represents the block number, which is the sequential number of the block in the source file, which contains the binary data that makes up the file block.

The metadata for the file is placed in another collection, which is fs.files by default. Each of these documents represents a file in Gridfs that is associated with a file.

Custom metadata can also exist. In addition to user-defined keys, the GRIDFS specification defines some keys

_id

The unique ID of the file, stored as the value of the FILES_ID key in the block

Length

Total number of bytes of file content

Chunksize

The size of each block, in bytes, is 256k by default and can be adjusted if necessary.

Uploaddate

Timestamp when the file was deposited in Gridfs

Md5

MD5 inspection of the contents of the file and, generated by the server by the FILEMD5 command, used to calculate the md5 of the upload block and

It also means that the user can verify the value of the MD5 key to ensure that the file is uploaded correctly.

Db.fs.files.find ()

4. Server-side scripting

JavaScript scripts can be executed on the server side via the Db.eval function, or the JavaScript script can be saved in the database and

Called in a different database command.

A. Db.eval

Use the Db.eval function to execute JavaScript scripts on the MongoDB server side. This function first passes the given JavaScript string to the

MongoDB server, executes on the server, and then returns the result.

Db.eval can be used to simulate multi-document transactions: Db.eval locks The database, executes JavaScript, and then unlocks. Although there is no built-in rollback mechanism,

However, this ensures that a sequence of operations takes place in a specified sequence of orders.

There are two ways to send code that encapsulates a function or is not encapsulated, such as:

Db.eval ("return ' refactor ';") Db.eval ("function () {return ' refactor ';}")

A function must be encapsulated only when parameters are passed. The parameter is passed in the second argument of the Db.eval, and is written in the form of an array.

Such as:

Db.eval ("function (name) {return ' Hello, ' +name;} ', [' Refactor '])

If the expression of db.eval is complicated, debugging is to write the debug information into the log of the database.

Such as:

Db.eval ("Print (' Hello Refactor ')")

So we can find Hello refactor in the log.

B. Storing JavaScript

Each MongoDB database has a special collection: System.js, which is used to store JavaScript variables. These variables can be in any MongoDB

Called in the JavaScript context, including the "$where" clause, the Db.eval call, and the MapReduce job. Insert to make the variable exist in System.js

Such as:

Db.system.js.insert ({"_id": "X", "Value": 1}) Db.system.js.insert ({"_id": "Y", "Value": 2}) Db.system.js.insert ({"_id" : "Z", "Value": 3})

The above example defines x, Y, z in the global scope, sums it: Db.eval ("return x+y+z;")

System.js can store JavaScript code, which makes it easy to customize some scripts, such as writing a log function with JavaScript and storing it in

In System.js:

Db.system.js.insert ({"_id": "Log", "Value": function (msg,level) {var levels=["DEBUG", "WARN", " 　　　　　　　　　　ERROR "," Patal "]; 　　　　　　　　　　level=level?level:0; 　　　　　　　　　　var now= new Date (); 　　　　　　　　Print (now + "" + levels[level]+msg); } 　　} )

Call:

Db.eval ("Log (' Refactor Bolg test ', 1)")

The disadvantage of using stored JavaScript is that the code is detached from the regular source control and will confuse the JavaScript that the client sends.

The best way to store JavaScript is to use a JavaScript function somewhere in the program, so if it's updated,

Just update this function without having to change it. If the JavaScript code is long and cumbersome to use, you can also use storage JavaScript,

In this way, the village will save a lot of king spread time.

C. Security

The implementation of JavaScript code should consider MongoDB security.

Such as:

>func= "function () {print (' Hello, ' +username+ '! ');}"

If username is user-defined, you can use such a string "');d b.dropdatabase ();p rint ('",

The code becomes like this:

>func= "function () {print (' Hello, ');d b.dropdatabase ();p rint ('! ');}"

To avoid this, scope is scoped.

Most drivers provide a special type of code that is passed to the database because the code can actually be seen as a string and a

A combination of scopes. A scope is a document that holds the variable name and value mappings. When the JavaScript function executes, this mapping is

Forms the local scope of the function.

5. Database References

Dbref is like a URL that uniquely identifies a reference to a document. It automatically loads documents just like URLs in a Web site automatically load Web pages via links.

What is A.dbref?

Dbref is an inline document, dbref some of the required keys, such as:

{"$ref": CollectionName, "$id": Id_value}

Dbref points to a collection, and a id_value is used to determine the unique document within the collection based on "_id". These two messages allow Dbref to

Uniquely identifies any document within the MongoDB database. If you want to reference a document from another database, there is an optional key "$db" in Dbref

{"$ref": CollectionName, "$id": Id_value, "$db":d atabase}//Note the order of the keys cannot be changed.

B. Examples

Two collections users (user), notes (notes),

Users can create notes that can refer to users or other notes.

Db.users.insert ({"_id": "Refactor", "DisplayName": "Dis_refactor"}) Db.users.insert ({"_id": "Refactor2", " DisplayName ":" Dis_refactor2 "})

Db.notes.insert ({"_id": 2, "author": "Refactor", "text": "Refactor in MongoDB"}) Db.notes.insert ({"_id": "Author": " Refactor22 "," text ":" ... Dbref likes URL "," References ": [{" $ref ":" Users "," $id ":" Refactor "}, {" $ref ":" Notes "," $id ": 2}]})

var note=db.notes.findone ({"_id": 22}); 　　Note.references.forEach (function (ref) {Printjson (db[ref. $ref].findone ({"_id": Ref. $id})); });

C. When to use Dbref

This reference to other documents in MongoDB is not the only way to Dbref.

The above example uses a different kind of reference: each Note's author key only stores the "_id" key of the author document, and there is no need to use dbref because it has

Know that each author is a document within the Users collection. This reference in GRIDFS's block document "FILES_ID" is simply a reference to the document "_id".

Do you choose Dbref or store "_id" when you save the reference?

Saving "_id" is more compact and lightweight for developers. But Dbref can reference any collection (or even any database) of documents, developers

There is no need to know and remember which collections the referenced documents are in. Drivers and some tools provide additional functionality to dbref, such as automatic referencing.

In summary, it is best to use dbref when storing references to documents of different collections. Otherwise it is better to store "_id" as a reference, which is simpler and easier to manipulate.

MongoDB Advanced-Correlation query