Источник контента:27 октября 2018 г. Го Юаньвэй, сопредседатель китайского сообщества MongoDB, выступил с речью «Введение в механизм хранения WiredTiger» на «Конференции китайского сообщества MongoDB 2018 в Гуанчжоу». IT big coffee сообщил, что как эксклюзивный видео-партнер, он был выпущен с разрешения организатора и спикера.
Количество слов для чтения:2969 | 8 минут чтения
Резюме
Темой этого обмена является механизм хранения WiredTiger, который в основном состоит из четырех частей. Во-первых, он представляет архитектуру подключаемого модуля хранилища MongoDB, затем дела WiredTiger. Третья часть представляет механизм Checkpoint. Наконец, через случай, анализ Функции распределения и сжатия кэша WiredTiger.
Подключаемая архитектура механизма хранения
Нижний уровень этой схемы — это нижний уровень механизма хранения, а посередине находится механизм хранения в памяти. Над этими механизмами хранения находится документная модель данных MongoDB, поэтому независимо от того, какой механизм хранения используется, он прозрачен для разработчиков приложений верхнего уровня. Верхний уровень — это различные приложения, поддерживаемые базой данных MongoDB. Вы можете увидеть общую архитектуру, которая на самом деле чем-то похожа на Mysql, обе из которых являются подключаемыми архитектурами механизма хранения.
Особенности транзакций и уровни изоляции моментальных снимков
Транзакции в реляционных базах данных изолированы, а MongoDb также поддерживает транзакции и соответствует стандартным функциям транзакций ACID. Обычно у вещей есть уровни изоляции, такие как фиксация записи, нефиксация чтения, моментальный снимок и т. д. MongoDB по умолчанию использует уровень изоляции моментального снимка.Когда что-либо запускается, он сначала делает снимок всех операций записи в памяти, кроме незавершенных транзакций, а затем записывает сообщение о состоянии для этих незавершенных транзакций записи.
Для транзакции операции записи перед записью необходимо решить, конфликтует ли операция с другими незавершенными транзакциями.Если есть конфликт, выполнение завершится ошибкой, и транзакция будет повторно отправлена через определенный период времени.Ключ здесь заключается в том, чтобы иметь возможность судить об операции записи, конфликтует ли операция с другими транзакциями.
MVCC реализует обнаружение конфликтов и параллелизм вещей
Внедрение механизма контроля многоверсионности позволяет выявлять конфликты, фактически реализовано путем записи номера версии записи, которая оперируется в начале каждой вещи, этот метод существует и в других базах данных.
Например, у нас есть две транзакции записи, AB. Транзакция A сначала считывает данные строки, которые нужно изменить, из таблицы, значение запаса равно 100, а номер версии записи строки равен 1. Транзакция B также считывает те же данные строки, которые нужно изменить, значение чтения равно 100, а номер версии записи строки равен 1. Транзакция A обязуется изменить значение инвентаризации, а номер версии записи строки увеличивается на 1, что больше, чем номер версии 1, прочитанный в начале, поэтому транзакция A может быть отправлена. Однако, когда транзакция B фиксируется, обнаруживается, что номер версии записи строки в это время уже равен 2, что приводит к конфликту, поэтому транзакция B не может быть зафиксирована. Затем транзакция B попытается выполнить повторную отправку, добавив 1 к номеру прочитанной версии, чтобы больше не было конфликтов и отправка прошла нормально. С помощью этого многоверсионного механизма управления параллелизмом можно предотвратить изменение транзакцией B неправильных данных.
Типовой процесс выполнения операционной транзакции
Прежде чем транзакция записи начнет выполняться, делается снимок всех выполняющихся незафиксированных транзакций. Затем сохранить действие этой операции записи в массив Operation_array, из которого действие можно извлечь и откатить, а затем измененные данные записываются в виде журнала и записываются в область кэша журнала. Когда транзакция операции записи фиксируется, данные в буфере журнала сначала сбрасываются на диск и записываются в файл журнала.Когда база данных неожиданно выходит из строя и восстанавливается, файл необходимо прочитать, и действия в файле повторяются.
Изменение данных, вызванное операцией записи, сначала записывается в кеш механизма хранения WiredTiger. Данные в кеше организованы в структуру b-дерева. Конечный узел b-дерева — это страница, которая фактически хранит данные. изменяется, страница становится не «грязной». страница» (в памяти); механизм хранения записывает данные в «грязной странице» на физический диск для сохранения по умолчанию каждые 60 с.
Типичный процесс операции записи после введения механизма контрольных точек
После введения чекпойнта соответственно изменится и весь процесс, в основном места, обведенные на рисунке. Контрольная точка будет генерироваться в двух местах: во-первых, когда диск сбрасывается каждые 60 секунд по умолчанию, и грязные данные в памяти сбрасываются на диск, и они будут генерироваться в соответствующем файле данных. Другая возможность - когда функция журнала журнала включена, когда файл журнала достигает 2 ГБ, также возникает контрольная точка.
У контрольной точки есть две важные функции: одна из них заключается в том, что при восстановлении базы данных нам нужно восстанавливать только с последней временной точки контрольной точки, что эффективно сокращает время восстановления базы данных. С другой стороны, после завершения контрольной точки можно считать, что данные в памяти до момента контрольной точки были безопасно и полностью записаны на диск, поэтому объем памяти, занимаемый «грязными страницами» памяти можно освободить для экономии места в памяти.
Использование памяти WiredTiger
Использование памяти WiredTiger разделено на две части: одна — внутренняя память, а другая — кеш файловой системы. Значение внутренней памяти по умолчанию имеет расчетную формулу { 50% от (RAM-1GB) или 256MB }, память индекса и коллекции загружаются во внутреннюю память, индекс сжимается и помещается во внутреннюю память, коллекция не сжимается. wiredTiger будет автоматически использовать всю остальную свободную память через кеш файловой системы, а данные в кеше файловой системы согласуются с форматом данных на диске, что может эффективно сократить дисковый ввод-вывод.
Внутренняя структура внутреннего кэша
Данные в памяти хранятся в виде структуры btree.Перед тем, как какие-либо данные будут записаны, они будут считаны во внутренний кэш. Как показано на рисунке выше, первой операцией является вызов диспетчера блоков, и диспетчер блоков считывает данные с диска в память. Когда данные будут изменены на втором этапе, новая страница будет перераспределена, и изменение будет выполнено на этой основе.После завершения изменения исходная страница станет «грязной страницей», а затем « грязная страница" будет изменена через внутренний механизм wiredTiger. "Перепрошить на диск через менеджер блоков.
Несколько структур данных, связанные с внутренним кешем
Первая — это исходная страница, на которой собраны все данные в виде списка. Если есть действие модификации, будет сохранена другая измененная страница, а на измененной странице будут сохранены два связанных списка. Заголовок связанного списка сохраняется. При вставке связанного списка и изменении связанного списка они соответствуют двум структуры данных, так что wiredTiger будет Каждая операция модификации и вставки не записывается непосредственно на диск. Когда операции модификации или операции вставки накапливаются в определенной степени, эти операции будут регулироваться в памяти, сортироваться, а затем записываться на диск в одно и то же время.
Случай: проблема с пулом соединений для разработки приложений
Наконец, мы рассмотрим проблемы с пулами соединений, которые более важны для разработчиков приложений. В то время многие из наших приложений использовали MongoDB, и все приложения создавали Mongo Client. Эти приложения часто добавлялись, удалялись, изменялись и проверялись. Однако, поскольку наши интеграторы конфигурации серверов могут быть не очень хорошо знакомы с развертыванием сегментированных кластеров, поэтому На некоторые параметры также не обращают внимания, из-за чего возникает проблема с большим количеством таймаутов соединения.
Позже мы проанализировали это и нашли конкретные причины. Для MongoDB его подключение разделено на две части, одна это слово подключения драйвера, а другая на сервере.Есть параметр, который определяет максимальное количество одновременных подключений, которые может поддерживать сервер. Если пул подключений драйвера намного больше, чем количество одновременных подключений, которые может поддерживать сервер, даже если клиентская программа не имеет проблем с подключением, сервер будет иметь ошибку отказа в соединении. Чтобы решить эту проблему, мы можем изменить размер пула соединений по умолчанию на уровне клиента и сервера соответственно.
Выше содержание сегодняшнего обмена, спасибо всем!
Редактор: IT big coffee сказал, пожалуйста, указывайте авторские права и источник при перепечатке