java内存映射缓存,java – 用于数据库实现的内存映射的MappedByteBuffer或直接ByteBuffer？...

这看起来像一个长期的问题，因为所有的上下文。下面的小说里有两个问题。感谢您抽出时间阅读并提供帮助。

情况

我正在开展可扩展的数据存储实现，可以支持在32位或64位系统上处理数据文件，从几KB到TB或更大的数据文件。

数据存储区使用写入时复制设计;始终将新的或修改的数据附加到数据文件的末尾，而不要对现有数据进行就地编辑。

系统可以托管1个或多个数据库;每个由磁盘上的文件表示。

实施细节并不重要;唯一重要的细节是，我需要不断地追加到文件，并将其从KB扩展到MB到GB到TB，同时随机跳过文件以进行读取操作来回答客户端请求。

首先，思考

乍一看，我知道我想使用内存映射文件，所以我可以把有效地管理内存状态的数据的负担推到主机操作系统上，而不是我的代码。

那么所有我的代码都需要担心的是在写入时序列化追加到文件的操作，并允许任意数量的同时读取器在文件中寻求回答请求。

设计

因为单个数据文件可以超过MappedByteBuffer的2GB限制，我希望我的设计必须包含一个抽象层，该层采用写入偏移并将其转换为特定2GB段内的偏移量。

到现在为止还挺好…

问题

这是我开始挂断的地方，认为使用不同的设计(如下所述)可能是更好的方法。

从这里读到20个左右的“内存映射”相关问题，似乎mmap调用在分配时想要连续运行的内存是很敏感的。所以，例如，在32位主机操作系统上，如果我试图mmap一个2GB的文件，由于内存碎片，我的机会很小，映射将成功，而我应该使用像一系列的128MB映射来拉一个整体档案。

当我想到这个设计，甚至说使用1024MB的mmap大小，一个DBMS托管了一些由1TB文件表示的巨大的数据库，我现在有内存中的数千个内存映射区域和我自己在Windows 7上的测试为了在多GB文件中创建几百mmaps，我没有遇到异常，我实际上每次尝试分配太多时，JVM都会出现故障，在某种情况下，我的Windows 7机器中的视频剪切并重新初始化与我从未见过的操作系统错误弹出窗口。

不管“你永远不会处理大的文件”或“这是一个有创意的例子”的论点，我可以用这些类型的副作用对这些代码进行编码，这使我的内部警报变得高度警惕，被认为是替代性的(下文)。

BESIDES的问题，我对内存映射文件的理解是，每次文件生成时，我都必须重新创建映射，所以在这个文件的附加情况下，只有在设计中，它才逐渐增长。

我可以在一定程度上通过以大块(每次8MB的速度)增长文件来克服这个问题，并且每8MB重新创建一次映射，但是不断重新创建这些映射的需要让我非常紧张，特别是没有明确的unmap feature supported in Java。

问题#1/2

鉴于我的所有发现，到目前为止，我将把内存映射文件视为主要的重读解决方案或只读解决方案的一个很好的解决方案，但不需要重写映射。

但是随后，我围绕着我周围的景观，像MongoDB这样的解决方案，它涵盖了所有的内存映射文件，我觉得我在这里缺少一些核心组件(我知道它一次分配到2GB的范围内，所以我想象他们正在使用这种逻辑解决重新映射的成本，并有助于维持顺序运行在磁盘上)。

在这一点上，我不知道Java是否缺少一个unmap操作的问题，使得这个操作更加危险，不适合我的使用，或者我的理解不正确，有人可以指向我。

替代设计

如果我对mmap的理解是正确的，那么上面提到的内存映射的另一种设计如下：

将a direct ByteBuffer定义为合理的可配置大小(大致为2,4,8,16,32,64,128KB)，使其易于与任何主机平台兼容(不需要担心DBMS本身造成颠簸的情况)，并使用原始FileChannel，一次执行文件1 buffer-capacity-chunk的specific-offset reads，完全代替内存映射文件。

缺点是现在我的代码不得不担心像“从文件中读取足够的文件以加载完整的记录”。

另一个缺点是，我不会使用操作系统的虚拟内存逻辑，让它自动为我保留更多的“热”数据在内存中;相反，我只是希望操作系统使用的文件缓存逻辑足够大，为我做一些有用的事情。

问题2的2

我希望能够确认我对这一切的理解。

例如，也许文件缓存太棒了，在这两种情况下(内存映射或直接读取)，主机操作系统将尽可能保持尽可能多的热数据，大文件的性能差异可以忽略不计。

或者也许我对内存映射文件(连续内存)的敏感要求的理解是不正确的，我可以忽略所有这些。