我使用 Berkeley DB (BDB) 作为 JMS 队列的持久存储。当我使用队列中的条目时，底层 BDB 文件不会立即收缩，但最终会收缩。我遇到了 BDB 文件在文件系统上占用大量空间而检索性能下降的问题。
我的条目大小变化很大，但在持久队列中有 400,000 条大约 32kb 的消息并不少见。
我想了解 BDB 如何管理文件，以便我可以限制文件大小/检索性能的条目数。或者，我可以排除 BDB 作为我的持久存储机制。
我可能正在搜索错误的术语，但没有在Oracle 文档或The Berkeley DB Book中找到我要查找的内容。如果 BDB 不希望我弄乱它的内部结构，我不会感到惊讶，但如果（至少）没有关于它如何处理其内部结构的概述，我会感到惊讶。
Oracle 11gR2 Exadata
我需要唯一标识何时及时创建记录。序列缓存意味着我不能使用基于序列的 ID，而批量插入意味着在一个批次中插入的所有记录都将具有相同的时间戳值（即使使用 TIMESTAMP(9)）。类似于 Twitter 的since_id 概念。
到目前为止我想到的最好的选择
这是我的要求：我有一个 API，它允许用户提供一个序列作为标记并请求从那时起的所有记录。例如，他们请求标记为 7 的 1000 条记录，他们将从我的表中获取 1000 条 ID 大于 1007 的记录。例如，假设返回的 1000 条记录中数字最大的 ID 是 2045，因此我们返回 2045 为标记 后来，客户请求 1000 条记录，标记为 2045，期望获得下一批 1000 和新标记。
非常简单的方法可以让他们以适合他们的任何大小获取所有记录而不会丢失任何记录。但是，由于跨多个 Exadata 节点的序列缓存，在客户端请求标记为 1007 的 1000 条记录时，可能尚未创建 ID 为 2020 的记录。因此，当他们使用 2045 标记进行下一个请求时，他们将永远错过 2020 年的记录。使用 ID 获取关联记录的时间戳可以解决这个问题，但是我必须确保始终将记录单独插入表中以保证唯一的时间戳。
假设：
希望我只是没有找到正确的术语来搜索现有答案。我觉得这是一个多年来应该通过一些模式来解决的问题。我认为Twitter已经解决了它......