Database Reference
In-Depth Information
Opting for Performance vs. Features
Performance is important, but MongoDB also provides a large feature set. We've already discussed some of the
features MongoDB doesn't implement, and you might be somewhat skeptical of the claim that MongoDB achieves
its impressive performance partly by judiciously excising certain features common to other databases. However,
there are analogous database systems available that are extremely fast, but also extremely limited, such as those that
implement a key/value store.
A perfect example is
memcached
. This application was written to provide high-speed data caching, and it is
mind-numbingly fast. When used to cache website content, it can speed up an application many times over.
This application is used by extremely large websites, such as Facebook and LiveJournal.
The catch is that this application has two significant shortcomings. First, it is a memory-only database. If the
power goes out, then all the data is lost. Second, you can't actually search for data using memcached; you can only
request specific keys.
These might sound like serious limitations; however, you must remember the problems that memcached is
designed to solve. First and foremost, memcached is a data cache. That is, it's not supposed to be a permanent
data store, but only to provide a caching layer for your existing database. When you build a dynamic web page,
you generally request very specific data (such as the current top ten articles). This means you can specifically ask
memcached for that data—there is no need to perform a search. If the cache is out-of-date or empty, you would query
your database as normal, build up the data, and then store it in memcached for future use.
Once you accept these limitations, you can see how memcached offers superb performance by implementing
a very limited feature set. This performance, by the way, is unmatched by that of a traditional database. That said,
memcached certainly can't replace an RDBMS. The important thing to keep in mind is that it's not supposed to.
Compared to memcached, MongoDB is itself feature-rich. To be useful, MongoDB must offer a strong set of
features, such as the ability to search for specific documents. It must also be able to store those documents on disk,
so that they can survive a reboot. Fortunately, MongoDB provides enough features to be a strong contender for most
web applications and many other types of applications as well.
Like memcached, MongoDB is not a one-size-fits-all database. As is usually the case in computing, tradeoffs
must be made to achieve the intended goals of the application.
Running the Database Anywhere
MongoDB is written in C++, which makes it relatively easy to port and/or run the application practically anywhere.
Currently, binaries can be downloaded from the MongoDB website for Linux, Mac OS, Windows, and Solaris. There
are also various official versions available for Fedora and CentOS, among other platforms. You can even download the
source code and build your own MongoDB, although it is recommended that you use the provided binaries wherever
possible. All the binaries are available in both 32-bit and 64-bit versions.
■
the 32-bit version of MongodB is limited to databases of 2gB or less. this is because MongodB uses
memory-mapped files internally to achieve high performance. anything larger than 2gB on a 32-bit system would require
some fancy footwork that wouldn't be fast and would also complicate the application's code. the official stance on this
limitation is that 64-bit environments are easily available; therefore, increasing code complexity is not a good tradeoff.
the 64-bit version for all intents and purposes has no such restriction.
Caution
MongoDB's modest requirements allow it to run on high-powered servers or virtual machines, and even to power
cloud-based applications. By keeping things simple and focusing on speed and efficiency, MongoDB provides solid
performance wherever you choose to deploy it.
