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

时间:2013-12-01 09:22:58

标签: .net-4.5 memory-mapped-files

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

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

FilStream提供Lock API,但MemoryMappedFile不提供锁定,因此我将不得不使用一些进程间锁定。

我的要求是,

  1. 我希望文件只能通过单个进程打开
  2. 单个进程将有多个线程访问相同的MMF但可能是不同的视图
  3. 我想轻松读取/写入4B到64KB的块,但是使用完全锁定,将使用互斥锁
  4. 我将写4KB到64KB固定大小的整页,我想在我的处理结束时执行Flush。但我希望这种写操作非常耐用。
  5. 从MSDN上的文档中,我看到MemoryMappedFile是创建数据库系统的最佳候选者,但是我已经看到了一些开源的nosql c#数据库,我还没有看到他们中的任何一个使用它,所以它让人怀疑是什么是瓶颈。另一个原因可能是MMF在.NET很晚才推出,而这些数据库没有MMF选项。

1 个答案:

答案 0 :(得分:2)

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

使用MMF进行阅读无法改善。您希望针对公共访问模式进行优化,快速访问模式,因为查询会按顺序访问数据。它得到了文件系统缓存的良好支持,它可以预先读取磁盘上相同柱面上的数据,因为实际上它是免费的。 MMF可能会因您访问视图时触发的页面错误导致的千针刺死中国酷刑死亡。重复访问数据时不是问题,但这是dbase引擎不做的一件事。

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