Почему не может DMBSes полагаться на пул буферов ОС?
Статья Stonebraker (Поддержка операционной системы управления базой данных) объясняет, что, "издержки для выборки блока от менеджера по пулу буферов обычно включают издержки системного вызова и перемещения от ядра к ядру". Забудьте о стратегии буферной замены и т.д. Единственная точка, которую я подвергаю сомнению, является заключенным в кавычки.
Мое понимание - то, что, когда DBMS хочет читать, блок x он дает общую инструкцию по чтению. Не должно быть никакого различия от того из любого другого приложения, запрашивающего чтение.
Я не ищу универсальные ответы (я получил их и прочитал газеты). Я ищу подробный ответ описанной проблемы. Посмотрите, что файл читает из JAVA-приложения, вызывают системный вызов?
4 ответа
Читаем из вашего другого вопроса и работаем дальше:
Когда СУБД должна доставить страницу с диска, это будет включать по крайней мере один системный вызов. В этот момент большинство СУБД помещают страницу в свой собственный буфер. (Они также оказываются в буфере ОС, но это неважно).
Итак, у нас есть один системный вызов. Однако мы можем избежать дальнейших системных вызовов. Это возможно потому, что СУБД кэширует страницы в своем собственном пространстве памяти. Первое, что сделает СУБД, когда решит, что ей нужна страница, - это проверит, есть ли она в ее кэше. Если есть, то она извлекает ее оттуда, не вызывая системного вызова.
СУБД может свободно уничтожать страницы в своем кэше любым способом, наиболее выгодным для ее потребностей в вводе-выводе. Срок действия кэша ОС истекает более общим образом, поскольку у ОС есть и другие заботы. Одним из примеров этого является то, что СУБД обычно использует большое количество памяти для кэширования страниц, поскольку знает, что дисковый ввод-вывод - одна из самых дорогих вещей, которые она может сделать. ОС не будет этого делать, так как ей нужно сбалансировать стоимость дискового ввода-вывода с наличием памяти для других приложений.
Дисковый ввод-вывод операционной системы должен быть универсальным для работы в различных ситуациях. СУБД иногда может значительно повысить производительность, используя менее общий код, оптимизированный для ее собственных нужд.
СУБД выполняет собственное кэширование, поэтому не хочет работать через кэширование операционной системы. Он «владеет» патчем на диске, поэтому ему не нужно беспокоиться о совместном использовании с другими процессами.
Обновление Ссылка на статью в помощь.
Во-первых, статье почти тридцать лет, и в ней говорится о давно устаревшем оборудовании. Тем не менее, читать его довольно интересно.
Во-первых, следует понимать, что ввод-вывод диска - это многоуровневый процесс. Это было в 1981 году, а сейчас тем более. В самой нижней точке драйвер устройства выдает аппаратным средствам инструкции физического чтения / записи. Выше может быть код ядра o / s, затем код пользовательского пространства o / s, затем приложение. Между fread () программы на языке C и перемещением головок дисков существует по крайней мере три или четыре уровня, а может быть и больше. СУБД может стремиться к повышению производительности, может стремиться обойти некоторые уровни и взаимодействовать напрямую с ядром или даже ниже.
Я вспоминаю, как несколько лет назад устанавливал Oracle на сервер Sun. У него была возможность выделить диск как «необработанный» раздел, где Oracle будет форматировать диск по-своему, а затем напрямую обращаться к драйверу устройства. Операционная система вообще не имела доступа к диску.
Это в основном проблема производительности. DBMS предъявляет очень специфические и необычные требования к вводу-выводу.
ОС может иметь любое количество процессов, выполняющих ввод-вывод и заполняющих ее буферы сортированными кэшированными данными, которые это производит.
И, конечно же, существует проблема размера и того, что кэшируется (dbms может лучше формировать кеш для своих нужд, чем более общее кэширование буфера устройства).
Кроме того, существует проблема, заключающаяся в том, что общий «блок» на самом деле может составлять значительно большую нагрузку на ввод-вывод (это зависит от разделения и т.п.), чем то, что в идеале хотелось бы нести dbms; его собственный кеш может быть настроен для лучшей работы с расположением данных на диске и, таким образом, для минимизации операций ввода-вывода.
Еще одна проблема - это индексы и аналогичные средства для ускорения запросов, которые, конечно, работают лучше, если кэш действительно знает , что они означают в первую очередь.
Реальная проблема заключается в том, что кэш файлового буфера не находится в файловой системе, используемой СУБД; он находится в ядре и используется всеми файловыми системами, находящимися в системе. Любая память, считываемая из ядра, должна быть скопирована в пользовательское пространство: это переход от ядра к ядру, о котором вы читали.
Помимо этого, существуют и другие причины, по которым вы не можете полагаться на системный буферный пул:
- Часто СУБД действительно хорошо представляют свои будущие шаблоны доступа и не могут передать эти шаблоны ядру. Это может привести к снижению производительности.
- Буферный кеш обычно хранится в диапазоне памяти ядра фиксированного размера, поэтому он не может увеличиваться или уменьшаться. Это также означает, что кэш намного меньше, чем основная память, поэтому при использовании буферного кеша СУБД не сможет воспользоваться преимуществами системных ресурсов.