MemoryMappedFile 是创建数据库系统的更好选择吗？

Question

我正在尝试创建 NoSQL 类型的数据库来存储 blob。每个 blob 将具有固定大小，例如 4KB 到 64KB。每个 blob 都将被完全重写，所以假设我有 1GB 到 1TB 的文件，在 FileStream 中我可以执行 Seek 和 write 等操作。但是我对 Locking 持怀疑态度。

MemoryMappedFile 对于 View 只有 4KB 到 64KB 的大文件会表现更好吗？或者我应该使用带锁定的 FileStream。

FilStream 提供 Lock API，但是 MemoryMappedFile 不提供锁定，所以我将不得不使用一些进程间锁定。

我的要求是，

1. 我希望文件只能由单个进程打开
2. 单个进程将有多个线程访问同一个 MMF，但可能有不同的视图
3. 我想轻松读/写 4B 到 64KB 的块，但要使用完全锁定，将使用互斥锁
4. 我会将 4KB 的整个页面写入 64KB 的固定大小，并且我只想在处理结束时执行刷新。但我希望这个写操作非常持久。

从 MSDN 上的文档中，我认为 MemoryMappedFile 是创建数据库系统的最佳候选者，但是我看到了一些开源 nosql c# 数据库，但我还没有看到它们中的任何一个使用它，所以它让人怀疑什么是瓶颈。另一个原因可能是 MMF 在 .NET 中引入的时间很晚，而那些数据库没有 MMF 选项。

Answer 1

不，不太可能从 MMF 中获得用于 dbase 引擎的里程数。对于初学者来说，操作系统已经提供了文件数据的内存映射视图。您可以从文件系统缓存中免费获得它。

使用 MMF 阅读无法改善这一点。您希望针对常见的访问模式进行优化，这些模式应该快速，因为查询按顺序访问数据。文件系统缓存很好地支持它，它会提前读取以从磁盘上的同一个柱面中获取数据，因为您实际上是免费获得的。访问视图时触发的页面错误会导致 MMF 因一千针刺而死于中国酷刑。当您重复访问数据时这不是问题，但这是 dbase 引擎不做的一件事。

MMF 非常适合写入，您只需写入内存，操作系统就会懒惰地更新文件。但这是您永远不想在 dbase 引擎中使用的一个功能，您希望确保在提交事务时在磁盘上更新文件数据。您可以强制刷新，但这很粗糙，整个视图都会被刷新，而不仅仅是应该提交的数据。