Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: v2.4
Fetching contributors…

Cannot retrieve contributors at this time

220 lines (162 sloc) 8.697 kb
=========================
FAQ: MongoDB Fundamentals
=========================
.. default-domain:: mongodb
This document addresses basic high level questions about MongoDB and
its use.
If you don't find the answer you're looking for, check
the :doc:`complete list of FAQs </faq>` or post your question to the
`MongoDB User Mailing List <https://groups.google.com/forum/?fromgroups#!forum/mongodb-user>`_.
What kind of database is MongoDB?
---------------------------------
MongoDB is a :term:`document`\-oriented DBMS. Think of MySQL but with
:term:`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.
Operationally, MongoDB features master-slave replication with automated
failover and built-in horizontal scaling via automated range-based
partitioning.
.. note::
MongoDB uses :term:`BSON`, a binary object format similar
to, but more expressive than :term:`JSON`.
Do MongoDB databases have tables?
---------------------------------
Instead of tables, a MongoDB database stores its data in
:term:`collections <collection>`, which are the rough equivalent of RDBMS
tables. A collection holds one or more :term:`documents
<document>`, 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.
.. see:: :doc:`/reference/sql-comparison`
.. _faq-schema-free:
Do MongoDB databases have schemas?
----------------------------------
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.
.. see:: :doc:`/reference/sql-comparison`
What languages can I use to work with MongoDB?
----------------------------------------------
MongoDB :term:`client drivers <driver>` exist for
all of the most popular programming languages, and many
other ones. See the :ecosystem:`latest list of
drivers </drivers>`
for details.
.. seealso:: :doc:`/applications/drivers`.
Does MongoDB support SQL?
-------------------------
No.
However, MongoDB does support a rich, ad-hoc query language
of its own.
.. seealso:: :doc:`/reference/operator`
What are typical uses for MongoDB?
----------------------------------
MongoDB has a general-purpose design, making it appropriate for a large
number of use cases. Examples include content management
systems, mobile applications, gaming, e-commerce, analytics,
archiving, and logging.
Do not use MongoDB for systems that require SQL,
joins, and multi-object transactions.
Does MongoDB support ACID transactions?
---------------------------------------
MongoDB does not support multi-document transactions.
However, MongoDB does provide atomic operations on a single
document. Often these document-level atomic operations are sufficient
to solve problems that would require ACID transactions in a relational
database.
For example, in MongoDB, you can embed related data in nested arrays or
nested documents within a single document and update the entire
document in a single atomic operation. Relational databases might
represent the same kind of data with multiple tables and rows, which
would require transaction support to update the data atomically.
Does MongoDB require a lot of RAM?
----------------------------------
Not necessarily. It's certainly possible to run MongoDB
on a machine with a small amount of free RAM.
MongoDB automatically uses all free memory on the machine as its
cache. System resource monitors show that MongoDB uses a lot of
memory, but its usage is dynamic. If another process suddenly needs
half the server's RAM, MongoDB will yield cached memory to the other process.
Technically, the operating system's virtual memory subsystem manages
MongoDB's memory. This means that MongoDB will use as much free memory
as it can, swapping to disk as needed. Deployments with enough memory
to fit the application's working data set in RAM will achieve the best
performance.
.. seealso:: :doc:`/faq/diagnostics` for answers to additional
questions about MongoDB and Memory use.
How do I configure the cache size?
----------------------------------
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.
.. _faq-database-and-caching:
Does MongoDB require a separate caching layer for application-level caching?
----------------------------------------------------------------------------
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.
Does MongoDB handle caching?
----------------------------
Yes. MongoDB keeps all of the most recently used data in RAM. If you
have created indexes for your queries and your working data set fits
in RAM, MongoDB serves all queries from memory.
MongoDB does not implement a query cache: MongoDB serves all queries
directly from the indexes and/or data files.
Are writes written to disk immediately, or lazily?
--------------------------------------------------
Writes are physically written to the :doc:`journal </core/journaling>`
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 :setting:`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 :setting:`syncdelay`.
What language is MongoDB written in?
------------------------------------
MongoDB is implemented in C++. :term:`Drivers <driver>` and client libraries
are typically written in their respective languages, although some
drivers use C extensions for better performance.
.. _faq-32-bit-limitations:
What are the limitations of 32-bit versions of MongoDB?
-------------------------------------------------------
MongoDB uses :ref:`memory-mapped files <faq-storage-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.
If you're running a 64-bit build of MongoDB, there's virtually no
limit to storage size. For production deployments, 64-bit builds and
operating systems are strongly recommended.
.. seealso:: "`Blog Post: 32-bit Limitations <http://blog.mongodb.org/post/137788967/32-bit-limitations>`_"
.. note::
32-bit builds disable :term:`journaling <journal>` by default
because journaling further limits the maximum amount of data that
the database can store.
Jump to Line
Something went wrong with that request. Please try again.