Понять систему MongoDB

Ответ 1

Примечание: это было написано еще в 2013 году, когда MongoDB был еще довольно молод, у него не было функций, которые он имеет сегодня, хотя этот ответ по-прежнему остается верным для mmap, он не относится к другим технологиям хранения, которые теперь реализует MongoDB, такие как WiredTiger или Percona.

Хорошее место, чтобы начать точно понимать, что такое индекс: http://docs.mongodb.org/manual/core/indexes/

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

Как мы можем быть уверены, что данные, которые мы запрашиваем, будут получены из памяти или нет?

Один из способов - посмотреть на поле yields в любом запросе explain(). Это скажет вам, сколько раз считыватель выдал свою блокировку, потому что данные не были в ОЗУ.

Еще один более глубокий способ - взглянуть на такие программы, как mongostat и другие подобные программы. Эти программы сообщат вам о том, какие сбои страниц (когда данные должны быть выгружены в ОЗУ с диска) происходят на вашем mongod.

Я понимаю, что MongoDB использует свободную память для кэширования данных о памяти, которая свободна в данный момент, но может ли кто-нибудь объяснить дальнейшее глобальное поведение?

Это на самом деле неверно. Проще сказать, что MongoDB делает это, но на самом деле это не так. Это на самом деле ОС и ее собственные алгоритмы подкачки, обычно LRU, которые делают это для MongoDB. MongoDB выполняет кеширование планов индексов в течение определенного периода времени, так что ему не нужно постоянно продолжать проверку и тестирование индексов.

В каком случае может быть лучше использовать переменную на нашем сервере узлов, которая хранит данные, чем доверять кеш-системе MongoDB?

Не уверен, как вы ожидаете, что это сработает... Я имею в виду, что эти два делают совершенно разные вещи, и если вы собираетесь читать ваши данные из MongoDB в ваше приложение при запуске в эту переменную, то я определенно не рекомендую это.

Кроме того, алгоритмы ОС для управления памятью чрезвычайно развиты и быстры, так что все в порядке.

Как вы в целом советуете использовать MongoDB для огромного трафика?

Хм, это такой огромный вопрос. На самом деле, я бы порекомендовал вам Google немного в этой теме, но, как указано в документации, вам нужно убедиться, что ваш рабочий набор вписывается в ОЗУ на один.

Вот хорошая отправная точка: Что означает "рабочий набор"? в оперативную память для MongoDB?

Ответ 2

MongoDB пытается сохранить целые коллекции в памяти: он отображает карту на каждую страницу коллекции. Для того чтобы все было в памяти, как страницы данных, так и индексы, которые ссылаются на них, должны храниться в памяти.

Если MongoDB возвращает запись, вы можете быть уверены, что она теперь в памяти (независимо от того, было ли это до вашего запроса или нет).

MongoDB не хранит "кеш" записей так же, как, скажем, веб-браузер. Когда вы совершаете изменения, обновляются как память, так и диск.

Монго отлично подходит для соответствующих случаев использования. Это очень высокая производительность, если у вас достаточно памяти сервера для кэширования всего и быстро уменьшается за этот момент. Многие, многие веб-сайты большого объема используют MongoDB: хорошо, что память настолько дешевая, теперь.

Ответ 3

Таким образом, в идеальном случае было бы три узла MongoDB, в основном 2 в Prod и 1 в DR. Нужна ясность в следующих сценариях: - (для сценариев без разделения) 1. Если для транзакции обновления, если один узел обновляется, то, если моя следующая транзакция чтения перейдет к другому узлу, он не получит обновленные значения, верно? 2. Если я настроил ядро базы данных в памяти на одной реплике и не настроил на других, что произойдет с описанным выше сценарием? Как в одной записи на одном узле (в памяти включен один) и читать на других узлах?