1

我有一个带有类型列的 SE11 表，STRING我想知道它是如何存储在底层数据库系统（本例中为 SAP Hana）上的。

我读到只有对 LOB 的引用实际上保存在键入为的列中，STRING而字符串本身保存在表之外。这是真的吗？它在 Hana 上也一样吗？我尝试使用 RTFM，但找不到该信息。

通常是否建议尽可能使用CHAR特定长度？

4

1 回答 1

2

免责声明。虽然我为 SAP SE 工作，但我与 SAP HANA 的团队或代码无关。以下信息是在 SAP HANA 2 SP02 (2.00.024.00.1519806017) 中通过反复试验收集的。它既不可靠，也不具有法律约束力，并且可能会在未来更改，恕不另行通知。

好的，现在已经不碍事了，让我们来看看一些事情：

  • SAP HANA 有一个列存储（= 花哨的新事物）和一个行存储（= 从其他关系数据库中得知）。两者非常不同。因此，在优化结构时，您应该知道您正在处理的是哪个商店。

  • ABAP DDIC 将STRING透明表中的列转换为NCLOB列，并CHAR转换为NVARCHAR.

  • ABAP DDIC 对字符串非常特殊：它们不能用作键，因为它们超过了 255 个字符的最大键长度。它们还可以防止应用程序服务器缓冲表，从而增加重复查询的响应时间。仅此一项通常是避免STRING使用的理由CHAR。STRING总之，可以说在透明表中添加多于一列是没有意义的。

  • SAP HANA 确实将 LOB 存储在表之外，而表只包含一个引用。内容被视为类似于文件。它们CONTAINER_ID可以从系统视图"SYS"."M_TABLE_LOB_FILES"中收集。相关的系统视图"SYS"."M_TABLE_LOB_STATISTICS"为您提供了有关已用空间的更多详细信息。

  • （相当）最近关于混合 LOB 的博客揭示了另一个有趣的事实：“因为 SAP HANA 不会压缩 LOB 列，无论它是驻留在磁盘还是内存中 [...]”。这意味着该列将消耗与您放入的内容一样多的磁盘空间。这与 SAP HANA 的其他列存储内容完全不同，后者被大量压缩以优化存储和访问。得出的结论也很有趣：“[...] 任何可能的压缩算法逻辑（例如 gzip）都必须在应用程序层应用于从数据库写入/读取”。

  • 一般来说——我知道的所有数据库管理系统都是这样——最好选择可变字符类型，因为它们让系统可以自由地优化它实际保留的空间。由于SAP 的指南不鼓励将VARCHAR(= non-Unicode) 用于纯 ASCII 以外的任何内容，因此 SAP HANA 的合理默认值应该是NVARCHAR(= Unicode-capable)'。

于 2018-03-28T11:21:42.997 回答