小编eeb*_*sen的帖子

我使用 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 概念。

到目前为止我想到的最好的选择

• 创建用于每个唯一时间戳的附加序列
• 不批量插入记录以强制每个记录的唯一时间戳
• 不缓存序列，尽管有一些讨论认为这不会解决 Exadata 下的问题

这是我的要求：我有一个 API，它允许用户提供一个序列作为标记并请求自那时以来的所有记录。例如，他们请求 1000 条标记为 7 的记录，他们将从我的表中获得 1000 条 ID 大于 1007 的记录。例如，假设返回的 1000 条记录的数字最大 ID 是 2045，因此我们返回 2045 作为标记 后来客户端请求 1000 条记录，标记为 2045，期望获得下一批 1000 条记录和一个新标记。

一种非常简单的方法，允许他们获取适合他们的任何大小的所有记录而不会丢失任何记录。但是，由于跨多个 Exadata 节点的序列缓存，在客户端请求 1000 条标记为 1007 的记录时，可能尚未创建 ID 为 2020 的记录。因此，当他们使用标记 2045 执行下一个请求时，他们将永远错过记录 2020。使用 ID 获取关联记录的时间戳可以解决这个问题，但是我必须确保始终将记录单独插入表中以保证唯一的时间戳。

假设：

• 不是在批量/批量插入中为单个记录获取单独时间戳的方法
• 即使在序列上使用 NOCACHE，多个节点也可能导致记录的插入是非时间顺序的（例如，序列值为 180 的记录可以使用大于序列值为 179 的记录的系统时间戳写入）

希望我只是没有找到正确的术语来搜索现有答案。我觉得这是一个多年来应该通过某些模式解决的问题。我认为 Twitter 已经解决了它......