MongoDB Hashed Shard Keys Selection

Updating to the latest version of mongodb available for ubuntu fixed the issue. This time, running db.bar.ensureIndex({"_id": "hashed"}, {"background": 1}), gave me:

Inserted 1 record(s) in 97564ms

and when I ran sh.shardCollection("foo.bar", {"_id": "hashed"}), I got:

{
  "collectionsharded": "foo.bar",
  "ok": 1
}

Here's the bash script that I used to update the servers:

#!/bin/bash

# for installing the latest and greatest version of MongoDB on Ubuntu Servers
if [[ "$UID" != 0 ]]; then # if not root, then exit non-zero
  printf "$(basename $0): err: %s\n" "must be root"
  exit 1
fi

apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10 # import the MonboDB public GPG key
echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/mongodb.list # create `/etc/apt/sources.list.d/mongodb.list` containing the ubuntu repo for mongodb.  
apt-get update # refresh the apt repos

for each in mongodb-clients mongodb-dev mongodb-server mongodb; do # remove the old version of mongodb
  apt-get remove "$each"
done

apt-get install mongodb-10gen # install mongodb from the newly added repo

In the future, ask to have the question migrated here instead of double posting.

From the MongoDB Documentation,

To calculate how much RAM you need, you must calculate your working set size, or the portion of your data that clients use most often. This depends on your access patterns, what indexes you have, and the size of your documents. Because MongoDB uses a thread per connection model, each database connection also will need up to 1MB of RAM, whether active or idle.

If the query is not completely covered by an index then the entire document is loaded into RAM by MongoDB. This is the same regardless of the type of query.

As for whether or not you should split your collection, that's really a design decision that requires a lot more background to understand and weigh in on. You'll need to perform tests to see if the gains from it based on the query patterns are worth it compared to the loss of atomicity (a business driven decision potentially).

I probably wouldn't recommend this approach though and would assess what your true SLA's are and whether or not you're using the right amount of hardware (RAM) for the desired results. Your real question here is "Do I have enough RAM to satisfy my query performance requirements when it comes to cached data?" If the answer is no, figure out what design works best with your constraints.