lega

На сервере где функция меняет xp, там и пусть уровень высчитывается и записывается а базу с тем же обновлением, для события - тут же проверяете изменился ли уровень и что-то делаете, например отправка сообщения клиенту.

Можете через mongoexport выгрузить в csv файл и открыть в excel/openoffice

1) Если кол-во искомых слов не большое, то можно сделать массив в документе и там хранить.
2) Использовать текстовый индекс
3) Если коллекция небольшая то можно $regex, но на больших коллекциях будет тормозить т.к. это полный перебор всех документов.

_id - это поле для уникального индекса, т.е. монга предотвращает появление дублей.
Значит вам нужно записать туда разные значения, сейчас вы пытаетесь записать туда дубль.
Если не трогать это поле, драйвер сам должен подставить туда уникальный ObjectId.

Имена детей уникальны у родителя.

Если нужна уникальность в пределах документа, используйте словарь (объект) вместо массива.

Судя по этой структуре, в базе либо будут дубли детей, либо у детей не будет детей и будет только один родитель, если на детей нужно будет ссылаться, то лучше их хранить отдельными документами.

Вы можете свой нумерованный идентификатор писать в _id. Но ObjectId работает быстрее*.
Так же можете делать дополнительное поле и индекс.

Не бьёт ли это по производительности?

Бьёт

> Качественный графический браузер для MongoDB под линукс

Google Chrome

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

PS: Зачем вам parent в комменте если он итак находится в каком-то коменте (уже имеет принадлежность)

оберните монго-драйвер во врапер который и будет разруливать что куда

replaceOne по сути тоже самое что и updateOne, только на updateOne стоит защита, чтоб не перетереть весь документ, т.е. обязательно должен быть $set или $addToSet или т.п. на replaceOne нет таких ограничений

Как правильно проверять чтобы одинаковых слагов не было?

Сделайте уникальный индекс на это поле и дублей не будет.

Не храните дубли да и все.

Я бы подумал о таком варианте (posts):

{
  votes: 15,
  vote: {
    user1: 1,
    user2: -1
  }
}

Одним запросом и пересчет и защита от повторного голосования, и выборка одним запросом.

1) Можно добавлять дублирующие ключи, можно проиндексировать все значения одним индексом (т.к. имя ключа одно), это список можно делать add/del
2) Проще обновлять значение (по прямому пути), дает уникальность по ключу - не будет дублирующих ключей по элементу.
У каждого подхода свои плюсы.
Ещё можно так же как и в mysql, но зачастую это неэффективно.