source2003

Индексы в MongoDB, представляю собой, в целом, то же самое, что и индексы в другой базе данных. Вместо перебора большой коллекции целиком, мы перебираем индекс, который гораздо проще запихать в память и работать с ним. Помимо прочего, индексы в отличии от самих данных, более нормализованы для поиска/сравнения значений.

Тут про индексы PostgreSQL, но аналогичным же образом, индексы работают во всех БД, с которыми приходилось работать мне.

После того, как поймете общее назначение индексов, можно будет легко найти интересующую Вас информацию по конкретному типу индексов в конкретной БД.

что происходит, когда мы их объявляем

Происходит чтение коллекции и построения индекса. Обычно, в физическом виде, это файл (или несколько файлов) на жестком диске.

Можно ли объявлять много индексов в коллекции?

Можно, но чем больше индексов - тем больше данные будут занимать на диске.

В идеале, под индекс попадают те данные, с которыми Вы работаете непосредственно, например, "логин" пользователя в таблице/коллекции пользователей, т.к. именно по нему происходит поиск. Все остальные данные, за пределами индекса, например, имя_пользователя, пароль, его телефон и т.д. - просто прилагаются "до кучи", в виде не индексированных данных, т.к. по ним либо не осуществляется поиск, либо, осуществляется довольно редко.

Желательно к этому полю добавить индекс.

collection.find({
  'date': {
    $gte: new Date(Date.now() - 5000) // 5000ms = 5 секунд
  }
});

Если это поле типа Integer, а не Date, то в new Date оборачивать не надо.

db.collection.find({}).count() должно быть равно db.collection.distinct({"ID"}).length

В nginx примерно так:

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://SERVER_IP:8080;
    }
}

server {
    listen 80;
    server_name example.net;
    location / {
        proxy_pass http://SERVER_IP:1337;
    }
}

*если в демагогию*
NoSQL подходит для хранения, где логику взаимосвязей между объектами задаёт программист выше уровнем, SQL же напротив, обязывает описать логику хранения на уровне БД.
Тот и другой подход имеют право на жизнь и могут быть производительней один другого в зависимости от ситуации.
Модная тенденция перехода во многих аспектах разработки на NoSQL исходит из того, что большинство фреймворков (да и отрасль разработки в целом) созрела для перехода на эту парадигму.

*если в практику*
NoSQL - это чаще всего хранение типа ключ:значение, т.е. вы можете очень быстро записывать и читать парные значения, можете их быстро реплицировать, распределять, можете масштабировать эту конструкцию, всё что вам нужно в таком подходе, дак это поверх, выше уровнем абстракций описать логику связей между этими записями \ таблицами.
В таком хранении у вас, на уровне БД, не будет возможности сказать, что поле A в таблице Аа должно быть заполнено значением из таблицы Бб и поля Б, вам придётся писать код, который сам определит эту логику.
Само собой, вам придётся и писать логику всех запросов к данным, все джойны и так далее (хотя некоторые фреймворки облегчают или нивелирую это).

По-умолчанию, данные сессии хранятся в файлах и явно читаются в оперативную память во время выполнения скрипта. Место хранения можно изменить, реализовав собственный SessionHandler, но нужно понимать, что "в оперативной памяти" - понятие растяжимое и разделяемой памяти у php нет.
Почитайте документацию, там всё подробно описано.