Database Reference
In-Depth Information
ever used have been relational. But not all databases support dynamic queries. For
instance, key-value stores are queryable on one axis only: the value's key. Like many
other systems, key-value stores sacrifice rich query power in exchange for a simple
scalability model. One of MongoDB's design goals is to preserve most of the query
power that's been so fundamental to the relational database world.
To see how MongoDB's query language works, let's take a simple example involv-
ing posts and comments. Suppose you want to find all posts tagged with the term
poli-
tics
having greater than 10 votes. A
SQL
query would look like this:
SELECT * FROM posts
INNER JOIN posts_tags ON posts.id = posts_tags.post_id
INNER JOIN tags ON posts_tags.tag_id == tags.id
WHERE tags.text = 'politics' AND posts.vote_count > 10;
The equivalent query in MongoDB is specified using a document as a matcher. The
special
$gt
key indicates the greater-than condition.
db.posts.find({'tags': 'politics', 'vote_count': {'$gt': 10}});
Note that the two queries assume a different data model. The
SQL
query relies on a
strictly normalized model, where posts and tags are stored in distinct tables, whereas
the MongoDB query assumes that tags are stored within each post document. But
both queries demonstrate an ability to query on arbitrary combinations of attributes,
which is the essence of ad hoc queryability.
As mentioned earlier, some databases don't support ad hoc queries because the
data model is too simple. For example, you can query a key-value store by primary key
only. The values pointed to by those keys are opaque as far as the queries are con-
cerned. The only way to query by a secondary attribute, such as this example's vote
count, is to write custom code to manually build entries where the primary key indi-
cates a given vote count and the value stores a list of the primary keys of the docu-
ments containing said vote count. If you took this approach with a key-value store,
you'd be guilty of implementing a hack, and although it might work for smaller data
sets, stuffing multiple indexes into what's physically a single index isn't a good idea.
What's more, the hash-based index in a key-value store won't support range queries,
which would probably be necessary for querying on an item like a vote count.
If you're coming from a relational database system where ad hoc queries are the
norm, then it's sufficient to note that MongoDB features a similar level of queryability.
If you've been evaluating a variety of database technologies, you'll want to keep in
mind that not all of these technologies support ad hoc queries and that if you do need
them, MongoDB could be a good choice. But ad hoc queries alone aren't enough.
Once your data set grows to a certain size, indexes become necessary for query effi-
ciency. Proper indexes will increase query and sort speeds by orders of magnitude;
consequently, any system that supports ad hoc queries should also support secondary
indexes.
