Используя NIO, мне нужно заботиться о R / W на границах блоков?

Question

Справочная информация

Много работы было уделено оптимизации проектирования базы данных, особенно в области наиболее оптимальных способов чтения и записи данных с дисков (как шпиндельных, так и SSD).

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

Вопрос

Допустим, я работаю в среде с относительно небольшим объемом памяти и хочу использовать небольшой файл с отображением памяти объемом 32 МБ для чтения и записи содержимого огромного файла объемом 500 ГБ.

Если бы я использовал механизмы NIO Java, в частности MappedByteBuffer (механизм отображения файлов в памяти Java), мне нужно было бы позаботиться о выполнении операций чтения и записи на границах блоков (например, 4 КБ) в памяти перед сопряжениемданные, которые мне нужны, или я могу просто выполнить R / W операции в любом месте, где я хочу, и разрешить операционную систему, логику подкачки виртуальной машины, файловую системуи встроенное ПО хранения выполняет оптимизацию операций и отбраковку дополнительных данных блока, которые мне не нужны по мере необходимости?

дополнительная информация

Причина вопроса заключается вв дизайне базы данных я вижу этот навязчивый акцент на оптимизации блоков до такой степени, что, кажется, не существует мира, в котором вы когда-либо просто читали бы и записывали данные без концепции блока.

Что меня смущает, так это то, что файловая система - это та, которая обеспечивает выполнение блоковых операций, зачем моему приложению более высокого уровня беспокоиться об этом?Если я хочу получить 17 631 байт со смещением 71, я не могу просто взять их и прочитать их, или мне действительно быстрее понять, что операция чтения начинается в блоке 0 и пересекает границы блоков 0, 1и 2 ... прочитать все эти 3 блока во внутренний байт [], а затем отбросить 17 631 байт, которые я хотел в первую очередь?

Если литература по проектированию БД не была настолько религиознойэта идея блока, вопрос никогда бы не пришёл мне в голову, но, поскольку это так, мне интересно, если я упускаю здесь критическую деталь файловых систем WRT и оптимального ввода-вывода блочного устройства.

Спасибо зачтение.

Answer 1

4KB блоки важны, потому что обычно это гранулярность MMU и, следовательно, менеджера виртуальной памяти ОС. Когда элементы часто используются вместе, важно спроектировать макет базы данных так, чтобы эти элементы оказались на одной странице. Таким образом, ошибка страницы будет отображаться во всех элементах страницы.

Answer 2

Я думаю, что одна из причин, по которым базы данных осведомлены о размере блока (который может не совпадать с размером блока fs, но, конечно, должен выравниваться), заключается не только в выполнении операций ввода-вывода с выравниванием блоков, но иуправлять тем, как данные на диске кэшируются в памяти, а не просто полагаться на кэширование ОС.Некоторые базы данных фактически полностью обходят кеш файловой системы ОС.Наличие базы данных для управления кешем иногда позволяет лучше понять, как используется этот кеш, что ОС может не обеспечить.

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

Большинство баз данных, с которыми я знаком, имеютконцепция блочного кэша / буфера, где живет некоторая часть рабочего набора базы данных.Управление кешем, полностью состоящим из произвольных экстентов, потенциально может быть немного сложнее в управлении.Кроме того, многие базы данных на самом деле упорядочивают свои хранимые данные в виде последовательности блоков, поэтому шаблон ввода-вывода вытекает из этого.Конечно, это может быть просто наследие баз данных, изначально написанных для платформ, которые не имели богатых возможностей кеширования ОС ...

Попытка завершить этот набег с каким-то ответом на ваш вопрос ... мойбыло бы ощущение, что чтение из произвольных экстентов в отображаемом файле и разрешение ОС справляться с дополнительным провалом должно быть в порядке.С точки зрения производительности, вероятно, более важно попытаться и позволить ОС выполнять опережающее чтение: например, с помощью вызовов «advise», чтобы ОС могла начать чтение следующего экстента с диска, пока вы обрабатываете текущий.И, конечно, способ посоветовать ОС разархивировать экстенты, с которыми вы закончили.