Механика ведения журнала MongoDB: для чего нужен приватный просмотр?

Я прохожу онлайн-курс MongoDB. Я только что посмотрел видео "Влияние журналирования на резидентную память", в котором описывается, как работает MongoDB. с данными в памяти и как они сохраняются на диск. Я также прочитал эти статьи о ведении журнала MongoDB:

  1. Механика ведения журнала;
  2. Как работает ведение журнала MongoDB.

Кажется, я не могу понять обоснование концепции частного просмотра.

диаграмма журнала

Насколько я понимаю, когда в качестве механизма хранения используется MMAPv1 и включено журналирование, с данными в MongoDB происходят следующие вещи:

  1. Когда MongoDB запускается, существующие файлы данных отображаются в виртуальную память с помощью отображения памяти (см. mmap). . Эта область виртуальной памяти называется общее представление.
  2. Затем общее представление переназначается в другую часть виртуальной памяти, называемую личным представлением. Логически (не физически) похоже, что все данные дублируются между двумя представлениями.
  3. При операции записи изменения применяются к частному представлению.
  4. Изменения также сохраняются (инкрементально) в файл журнала.
  5. После подтверждения сохранения изменений в журнале они также применяются к общему представлению.

В какой-то момент после этого общее представление будет сброшено в файлы данных на диске (это называется синхронизацией).

В какой-то момент общий вид также будет переназначен на частный вид.

Вопрос

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


person Dmytro Shevchenko    schedule 25.10.2015    source источник
comment
В качестве подсказки: приватное представление является приватным для подключения, iirc. Таким образом, когда вы вносите изменения, вы видите их немедленно, но они становятся доступными для других подключений только после того, как они сохранятся на диске, что обеспечивает согласованность.   -  person Markus W Mahlberg    schedule 25.10.2015
comment
@MarkusWMahlberg У вас есть ссылки, подтверждающие это? Заранее спасибо!   -  person Dmytro Shevchenko    schedule 26.10.2015
comment
Как вести журнал операций записи записей: private view хранит данные для использования с операциями чтения. Приватное представление — это первое место, где MongoDB применяет новые операции записи. После фиксации журнала MongoDB копирует изменения, сделанные в частном представлении, в общее представление, где они затем доступны для загрузки в файлы данных базы данных. Затем MongoDB применяет операции записи журнала к общему представлению. ... Насчет подключения-привата, я на самом деле не уверен, но, кажется, это было сказано в М202.   -  person Markus W Mahlberg    schedule 26.10.2015


Ответы (2)


Короче говоря, когда вы запускаете операцию записи, mongod сначала публикует операцию записи для частного просмотра. Частный вид - это файл с отображением памяти, через 200 мс он копирует данные в журнал, который является дочерним каталогом ваших данных / БД.

И после фиксации журнала он копирует данные в общее представление, которое сбрасывается в данные / БД через 60 секунд.

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

Частный вид и общий вид занимают выделенное место в ОЗУ. (файл с отображением памяти). Чтобы узнать больше о файле отображения памяти. Скажем, например, если ваш файл имеет размер 2000 байт на диске, он сопоставит его с адресом памяти 10-10010, поэтому вы можете прочитать файл непосредственно из адреса памяти. Любое изменение в файле из адреса памяти будет сброшено обратно в файл на вашем диске.

person VIJ    schedule 17.09.2017

Вот цитата из ответа, который Уильям Кросс предоставил на форумах Университета MongoDB.

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

Если это произойдет, и сервер выйдет из строя, то все, что у вас есть, это поврежденные данные; нет возможности откатить его назад. Имейте в виду, что с MMAPv1 большая часть работы механизма хранения перекладывается на ОС. MMAPv1 был создан, чтобы избежать мелкозернистого контроля над данными, идущими на диск, который нам здесь понадобится, чтобы поток был таким, каким мы хотим. Таким образом, чтобы этого не произошло, общедоступное представление данных остается неизменным до тех пор, пока на диске не будет завершена запись журнала упреждающей записи, и только после этого общедоступное представление обновляется. У нас есть приватное представление данных, поэтому они могут существовать в совершенно отдельном месте и сбрасываться на диск до того, как мы коснемся общедоступного представления и рискуем частично зафиксировать его на диске. Тем временем мы получили запись, поэтому у нас также есть приватное представление для ответа на запросы на чтение.

Что касается того, как именно это написано, я знаю, что мы записываем байты и начинаем с первого изменения, так что это смещение + байты. Это делает вещи относительно минимальными.

person Community    schedule 09.11.2015