lega

Вот есть сложный велосипед, если разберетесь. Доки нет.

Создание коллекций, документов, документов на основе документов, есть не только базовые типы (строки, числа и т.п.). а так же списки, таблицы, ссылки на документы других коллекций
Можно делать "логические" коллекции, т.е. если у вас есть 3 коллекции: пользователи, менеджеры, клиенты, то можно для одних документов сделать поле-ссылку на (пользователи + менеджеры) либо (менеджеры+клиенты) либо все (любые комбинации), т.е. при редактировании ссылки вываливается подбор из нескольких коллекций (либо открыть диалог выбора). Этой же фичей можно отфильтровать подбор (делается создание обработчика).
Так же есть (возможно сломана) возможность дропать картинки (прикреплять) к документам.
Есть фильтрованный поиск, например зафильтровать пользователей по отделу.
Есть наследование типов, например если вы хотите создавать документы на основе нескольких типов.
Есть авторизации и ACL по ролям. Можно подключить авторизацию через google, facebook, twitter, ВК. Подключить полнотекстовый поиск через sphinx.
Просмотр истории документов (видеть как и кем менялся документ).
Возможность менять представление документов.

Так же есть возможность брать куски и встраивать в свое веб-приложение, дополнять типы и менять темплейты полей. Можно делать плагины.
Часть функционала давно не используется, поэтому могло отвалится (нужно фиксить).

Не пытайтесь сделать хитроумные запросы (которые зачастую медленные), часто лучше сделать структуру документа где можно будет легко и быстро доставать данные.

Например для вашей задачи можно сделать так:

> db.qtest.insert({
	date: Date("2013-01-14"),
	name: "Roma",
	tags:['python', 'ruby', 'c'],
	counts: {python: 14, ruby:10, c:4 }
})

Поиск:

> db.qtest.find({tags: 'python'}, {date: 1, name:1, 'counts.python':1}).pretty()
{
	"_id" : ObjectId("55a28f4624db1e49cecbc89f"),
	"date" : "Sun Jul 12 2015 21:01:10 GMT+0500 (YEKT)",
	"name" : "Roma",
	"counts" : {
		"python" : 14
	}
}

Далее можете сделать индекс по тегам db.qtest.ensureIndex({tags: 1}), и этот запрос будет работать быстро когда коллекция будет большая.

Они размазываются по всем нодам по id

Зачем по id?

Сделайте уникальный индекс (шардинг) по username, тогда запрос будет к конкретному шарду в котором это имя (есть или должно быть). И при добавлении не нужно будет проверять, т.к. дубль имени не запишется (будет ошибка).

Можно попробовать sphinxsearch (или эластик), он ищет с сортировкой по релевантности, т.е. сверху будут наибольшие пересечения ключей, но он может сильно задуматься если там много пересечений.
Либо попробовать сделать обратный индекс с сортировпнными сайтами, за один проход вычислять пересечение по сайту, все сайты раскидать по нодам, результат скидывать в БД для сортировки.

Сколько в среднем ключей у сайта?

сколько времени еще может продолжаться этот кошмар?

Какая разница, уже пора бросить эту затею (и использовать sphinx или elasticsearch)

Mongodb шардинг, там атомарная транзакционность (+она производительней обычных транзакций), только "умершие локи" нужно будет вручную снимать (либо по таймауту).

Если VPS в разных датацентрах, то какие последствия?

Должно работать нормально, я в одном проекте сделал ноду на домашнем компе с динамическим ип (через OpenVPN) для бекапов, работало стабильно.

Можно сделать 2 простых запроса: find({ from:"email" }).count() и find({ to:"email" }).count()
А лучше, в "профиле email/пользователя" хранить счетчик входящих/исходящих.

Многое зависит от отчетов. Например для вашей задачи хранить сырые данные вообще не нужно.

Если отчеты ещё не определены или все же нужны сырые данные, то можно сделать партиционирование, например складывать все логи по одному игроку за один день в один документ в бинарном виде (time_delta, action) при этом зажать в gzip/zlib/...
В итоге из 500Гб может получится 5Гб, а скорость вырастет за счет легких индексов и меньшего кол-ва передаваемых данных/документов. - недавно делал подобное.

Так же можете сбросить userFlag в 0 для коллекции - сэкономите памяти, при этом монга не будет делать доп. резеривирования в каждом документе.

db.users.find({"age" : {"$gte" : 25, "$lte" : 35}}).sort({"username" : 1}).limit(100)
советуется брать следующий индекс {"username" : 1, "age" : 1}, вместо
{"age":1,"username":1}.

А должно быть наоборот.

Зачастую (но не всегда) порядок такой:
1) Фильтр на точные значения
2) Поля сортировки
3) Фильтр на "выборочные" значения (массивы).

В вашем случае ("age" : {"$gte" : 25, "$lte" : 35}) - это как бы точное значение (т.к. оно укладывается в "a < x < b"), далее идет сортировка ("username" : 1).
Т.е. получается монга "берет" пачку данных ...24,|25<=age<=35|,36... где в каждом из возрастов выбирает все значения по порядку т.к. они уже отсортированы.

Если индекс будет наоборот ({"username" : 1, "age" : 1}), то монга будет "входить" как бы в каждый username, брать из каждого вхождения диапазон 25<=age<=35, а потом сортировать все данные. - т.е. сортировка в начале тут лишняя.
Как то так.

Очень важно что-б сортировка "не ломалась" при проходе по индексу.

Вот полезная статья.