java - 保存 RPC 请求内容的最佳实践

Question

我们有一个 SOA 应用程序，它提供数百个 RPC 服务。对于其中一些 rpc 服务，我们希望将传入的请求内容持久保存到数据库中。正如你所看到的，不同服务的结构和请求参数是不同的，我们无法设计一个标准的结构表来包含整个请求体。

Oracle 11 是我们唯一可以使用的持久存储，我们不能使用 nosql/分布式缓存产品。我们曾经考虑过使用json和clob字段来实现这个需求，但是由于性能原因，我们的DBA建议使用clob不是一个好主意。

我想知道是否有人有类似的情况，是否有最佳实践？

Answer 1

我们有一些应用程序可以在面向消息传递的中间件中持久保存消息(据我记得，每月大约有 3000 万条消息，需要大约 1 TB 表空间来管理此消息，并删除超过 42 天的旧消息[如果他们使用分区和截断来管理空间会容易得多])。它只是将消息插入到 CLOB 中，并在适当的数据类型和大小的列中记录其他相关的消息元数据 [我认为它们用于表消息元数据表和消息有效负载表；他们查询消息元数据表以获取有关其服务如何使用的基本指标]。从我给客户的笔记中:

LOB 存储基础知识: 1. LOB段大于LOB段的字节总和 消息 2. 每个LOB可以内联或外联存储。内联意味着最多 3964 字节的 LOB 与该行的其余数据存储在表的同一 block (段)中。大于 3964 字节的 LOB 将离线存储在 LOB 段中。外联 LOB 完全存储在 LOB 段中，只有 lob 定位器与行的其余部分一起存储在 block 中。

block 大小决定数据如何离线存储；这是每个 LOB 的 LOB 段空间分配单元，无论大小如何。因此，对于每个 LOB，您将获得该 LOB 所需 block 大小的倍数。因此，这会导致大多数 LOB 出现一定程度的浪费。

LOB 可用空间使用情况:lob 空间管理的 RETENTION 应该允许随着时间的推移使用整个 lob 段 [我相信行为是:当通过删除释放 lob 段中的 block 时，它会在 UNDO_RETENTION 周期([实例 A] 为 15 分钟)之后进入空闲列表]；这是一个更好的实现，因为它不像 PCTVERSION 那样预留固定百分比的空间来使用。

此外，Oracle LOB 段的一致性读 (CR) 机制使用 LOB 段本身(而不是像大多数 CR 那样使用 UNDO 表空间)。因此，这也会导致 LOB 段需要一些额外的空间来支持 CR。

优化场景包括:1. 内联存储可以提高性能，原因如下:A。小于 3964 字节的 LOB 数据缓存在缓冲区高速缓存中。b.大于 3964 字节的 LOB 数据通过直接路径读/写访问(即更快的 I/O)2. 可以减小块大小以减少空间浪费，但有一些注意事项:A。 CLOB 当前所在的表空间具有 8K DB block 大小， block 大小是 DB block 大小的倍数，因此只能在 block 大小较小的表空间中使其更小。b.较小的 block 大小意味着更多的读写工作，并且您会因较大大小的条目而付出性能损失。消息大小中位数为 3900 个字符，考虑到多字节字符集，中间值约为 8K 个字符。因此，进入较小的 block 将意味着大多数数据将需要至少 2 次访问 [实际时间未确定]。通过将 CLOB 移动到新的表空间(需要停机时间)来填充新的表空间，完成与收缩相同的操作，并且让我们看到影响。3. LOB 重组:目前不建议这样做，因为从已删除的行中清除的空间正在被重新使用。

有关 LOB 的更多信息，请参阅 LOB 性能指南白皮书。

其他选项: 1. 使用 11g LOB 数据类型 SecureFile 在 11g 中，LOB 数据类型已被 完全重新设计。使用SecureFile LOB存储就完成了 在表创建语句的存储子句中以声明方式。 2. 研究高级压缩以减少空间需求 3.研究分区以提高可管理性