Database Reference
In-Depth Information
WHY SO MUCH APPLICATION CODE?
If you're coming from a relational database, particularly if you have a background as a DBA, you
may be accustomed to pushing as much logic as possible into the database. Although this approach
may be desirable in some circumstances, it's really not feasible with MongoDB due to limited pro-
gramming capabilities within the server (compared to many relational database systems). Moving
more of the workload to the application servers, as MongoDB often requires, actually carries with
it an important benefit: application servers are typically
much
easier to scale than database servers.
Even with MongoDB's straightforward sharding, it's hard to compete with the scale-up sequence
for an app server:
1. Bring up an app server
2. Add it to the load balancer
Of course, there are some cases where data locality and indexes can make doing some operations
on the MongoDB server more efficient. A good rule of thumb is to consider whether there's a sig-
nificant performance advantage to keeping a calculation on the MongoDB server, and if not, move
it to the application layer.
Sharding
If the system needs to scale beyond a single MongoDB node, we'll want to use a sharded
cluster. Sharding in this use case is fairly straightforward, since all our items are always re-
trieved by
_id
. To shard the
character
and
location
collections, the commands would be
the following:
>>>
>>>
db
.
command
(
'shardcollection'
,
'dbname.character'
, {
...
...
'key'
: {
'_id'
:
1
} })
{ "collectionsharded" : "dbname.character", "ok" : 1 }
>>>
>>>
db
.
command
(
'shardcollection'
,
'dbname.location'
, {
...
...
'key'
: {
'_id'
:
1
} })
{ "collectionsharded" : "dbname.location", "ok" : 1 }
