Frequently Asked Questions:
This document addresses basic high level questions about MongoDB and it’s use.
If you don’t find the answer you’re looking for, check the complete list of FAQs or post your question to the MongoDB User Mailing List.
MongoDB is a document-oriented DBMS. Think of MySQL but with JSON-like objects comprising the data model, rather than RDBMS tables. Significantly, MongoDB supports neither joins nor transactions. However, it features secondary indexes, an expressive query language, atomic writes on a per-document level, and fully-consistent reads.
操作上、MongoDBは、自動範囲ベース自動フェイルオーバーと水平スケーリングを内蔵する、マスタースレーブ・レプリケーションを特徴とします。
Instead of tables, a MongoDB database stores its data in collections, which are the rough equivalent of RDBMS tables. A collection holds one or more documents, which corresponds to a record or a row in a relational database table, and each document has one or more fields, which corresponds to a column in a relational database table.
Collections have important differences from RDBMS tables. Documents in a single collection may have a unique combination and set of fields. Documents need not have identical fields. You can add a field to some documents in a collection without adding that field to all documents in the collection.
MongoDB uses dynamic schemas. You can create collections without defining the structure, i.e. the fields or the types of their values, of the documents in the collection. You can change the structure of documents simply by adding new fields or deleting existing ones. Documents in a collection need not have an identical set of fields.
In practice, it is common for the documents in a collection to have a largely homogeneous structure; however, this is not a requirement. MongoDB’s flexible schemas mean that schema migration and augmentation are very easy in practice, and you will rarely, if ever, need to write scripts that perform “alter table” type operations, which simplifies and facilitates iterative software development with MongoDB.
MongoDB client drivers exist for all of the most popular programming languages, and many other ones. See the latest list of drivers for details.
See also
No.
However, MongoDB does support a rich, ad-hoc query language of its own.
MongoDBは、一般用デザインを備え、使用例として適当なものが数多くあります。例をあげると、コンテンツ管理システム、モービル・アプ、ゲーム、電子商取引、分析、アーカイブ、ロギングが含まれます。
SQL、結合、マルチオブジェクトトランザクションを必要とするシステムには MongoDB を使用しないでください。
MongoDB does not provide ACID transactions.
However, MongoDB does provide some basic transactional capabilities. Atomic operations are possible within the scope of a single document: that is, we can debit a and credit b as a transaction if they are fields within the same document. Because documents can be rich, some documents contain thousands of fields, with support for testing fields in sub-documents.
また MongoDB では書き込みを永続的(durable)にすることが可能です (ACIDの‘D’ ). 永続書き込みをするときは 64-ビットのものにはデフォールトで備わっているジャーナリングを起動する必要があります。また書き込みには、以下の書き込み関連事項を出す必要があります{j: true}これでジャーナルがディスクで同期化されるまで、まちがいなく書き込みがブロックされることになります。
Users have built successful e-commerce systems using MongoDB, but applications requiring multi-object commits with rollback generally aren’t feasible.
必ずしも必要としません。小量のRAMを持つ機器で MongoDB を実行することもできます。
MongoDB はキャッシュとして、機器に備わっているフリーメモリーを自動的に使用します。 システムリソースのモニターは、 MongoDBが大量のメモリを使うことを示していますが、使用状況はダイナミックです。 他のプロセスが突然サーバーの半分のRAMを必要とする場合は、 MongoDB は他のプロセスにキャッシュメモリを譲ります。
理論的には、オペレーティングシステムのバーチュアルメモリサブシステムが MongoDBのメモリを管理します。ということは、 MongoDB は必要があればディスクにスワップしてできるだけ多くフリーメモリを使うということです。 RAMに設定されるアプリケーションの稼動データに十分なメモリを備えた展開がベストパフォーマンスを成し遂げます。
See also
FAQ: MongoDB Diagnostics for answers to additional questions about MongoDB and Memory use.
MongoDB has no configurable cache. MongoDB uses all free memory on the system automatically by way of memory-mapped files. Operating systems use the same approach with their file system caches.
No. In MongoDB, a document’s representation in the database is similar to its representation in application memory. This means the database already stores the usable form of data, making the data usable in both the persistent store and in the application cache. This eliminates the need for a separate caching layer in the application.
This differs from relational databases, where caching data is more expensive. Relational databases must transform data into object representations that applications can read and must store the transformed data in a separate cache: if these transformation from data to application objects require joins, this process increases the overhead related to using the database which increases the importance of the caching layer.
はい、MongoDBは最近使用されたデータをすべてRAMに保存します。クエリのインデックスを作成した場合、作業用データセットがRAMに収まる容量なら、MongoDBはすべてのクエリにメモリから応答します。
MongoDB はクエリキャッシュを実行しません： MongoDB は全クエリディレクトリをインデックス、および/またはデータファイルから対応します。
Writes are physically written to the journal within 100 milliseconds, by default. At that point, the write is “durable” in the sense that after a pull-plug-from-wall event, the data will still be recoverable after a hard restart. See journalCommitInterval for more information on the journal commit window.
While the journal commit is nearly instant, MongoDB writes to the data files lazily. MongoDB may wait to write data to the data files for as much as one minute by default. This does not affect durability, as the journal has enough information to ensure crash recovery. To change the interval for writing to the data files, see syncdelay.
MongoDB is implemented in C++. Drivers and client libraries are typically written in their respective languages, although some drivers use C extensions for better performance.
MongoDB uses memory-mapped files. When running a 32-bit build of MongoDB, the total storage size for the server, including data and indexes, is 2 gigabytes. For this reason, do not deploy MongoDB to production on 32-bit machines.
64ビットビルドのMongoDBを実行する場合、実質的にストレージサイズの制限はありません。運用環境では64ビットのビルドおよびオペレーティングシステムを強くお勧めします。
See also
Note
32-bit builds disable journaling by default because journaling further limits the maximum amount of data that the database can store.