Я не думаю, что ваш предложенный дизайн является звуком. Сбой операционной системы (например, сбой питания и т. Д.) Может привести к частичной синхронизации области mmap с диском (возможно, страницы записаны в другом порядке, чем вы их записали и т. Д.), Что означает, что ваши структуры данных получат поврежден произвольным образом.
Если вам нужно, чтобы изменения в вашей базе данных были долговечными и атомарными (возможно, согласованность и целостность тоже не повредили бы, верно?), Тогда я настоятельно рекомендовал бы использовать существующую систему баз данных, которая поддерживает ACID, или соответствующее подмножество. Может быть, sqlite или Berkeley DB сделают свое дело.
Вы можете сделать это сами, в принципе, но не так, как вы описали - вам нужно создать какой-нибудь файл журнала, который был бы обновлен так, чтобы его можно было прочитать атомарно, и иметь возможность «воспроизвести» события из некоторого известного снимка и т. д., что технически сложно.
Помните, что:
- Сбой ОС может привести к частичному завершению записи, инициированной msync () или аналогичной, на прочный диск
- mmap не гарантирует никогда не записывать данные в другое время, то есть, если вы некоторое время не вызывали msync ()
- Страницы не обязательно записываются в том же порядке, в котором вы изменили страницы в памяти - например, Вы можете записать в [0], а затем в [4096] и иметь [4096] долговечный, но [0] не после сбоя.
- Даже сброс отдельной страницы не обязательно является атомарным.
Я понимаю, что использование библиотеки (например, bdb или sqlite) для каждой операции чтения или записи в вашей структуре данных является навязчивым изменением, но если вам нужна такая устойчивость, я думаю, что это необходимо.