Я когда-то делал это для приложений, предназначенных для поисковых систем. Он использовал цепочку LRU, которая также была адресуемой (через хеш-таблицу) по идентификатору файла и адресу памяти IIRC. При каждом доступе элементы hot перемещались в начало цепочки LRU. Когда память переполнилась (mmap может потерпеть неудачу ...), хвост LRU-цепочки был отключен.
Подводный камень этой схемы в том, что программа может быть заблокирована на страницах с ошибками. И поскольку он был однопоточным, он был действительно заблокирован. Изменение многопоточной архитектуры потребует защиты хеш-структур и структур LRU с помощью замков и семафоров.
После этого я понял, что выполняю двойную буферизацию: сама ОС имеет идеальный механизм дискового буфера LRU, который, вероятно, умнее моего. Просто открывайте () или mmap () каждый отдельный файл по каждому запросу, только один системный вызов, и (учитывая недавнюю активность) так же быстро, или даже быстрее, чем слой буферизации.
по отношению к СУБД: использование СУБД - это чистый дизайн, но у вас есть минимальные издержки на 3 системных вызова только для того, чтобы получить первый блок данных. И он, безусловно, ( всегда ) будет блокироваться. Но он вполне пригоден для многопоточного проектирования и избавляет вас от боли блокировок и управления буфером.