Ontology主键数据类型（STRING与INTEGER）选型疑问及实践探讨

Ontology中是否普遍优先选用STRING类型主键？ #

是的，在Foundry Ontology设计中，优先使用STRING类型作为主键是广泛认可的最佳实践。

优先选用STRING主键的原因 #

• 兼容性极强：能覆盖所有ID格式，包括带业务前缀的（如ORDER_202405）、混合字符的ID，后续业务扩展时无需修改主键类型，避免大规模重构。
• 彻底规避数值溢出：数值型ID（如INTEGER/BIGINT）存在上限，当业务增长导致ID超出范围时会引发数据异常，STRING完全没有这个限制。
• 保留语义信息：部分数值ID背后有业务编码规则，STRING可以直接保留原始标识的语义，避免纯数值带来的歧义。
• 跨系统集成更顺畅：多数外部系统的ID天然是字符串格式，用STRING做主键能减少跨系统交互时的转换工作，降低出错概率。

纯数值ID：STRING vs INTEGER的维度取舍 #

存储大小 #

• INTEGER：固定占用4字节（BIGINT为8字节），空间效率远高于STRING。例如数值123456存为INTEGER仅需4字节，存为STRING则需6字节；18位的大数值存为BIGINT是8字节，STRING则需18字节，差距明显。
• STRING：存储大小随字符长度增加而增长，短数值差距不大，但长数值的存储开销会显著高于数值类型。

索引/过滤速度 #

• INTEGER：数值类型的索引结构更紧凑，Foundry底层存储引擎对数值的比较、过滤操作优化更成熟，尤其是范围查询（如id > 10000），性能远优于STRING。
• STRING：字符串比较是逐位进行的，索引体积更大，范围查询性能明显偏低；但精确主键查询的性能在Foundry优化下，与数值类型差距不大。

连接/Shuffle成本 #

• INTEGER：数值类型的序列化、反序列化速度更快，占用带宽更少，在跨数据集连接、Spark Shuffle过程中，能大幅降低数据传输量和计算开销，提升作业运行效率。
• STRING：字符串序列化后的体积更大，Shuffle时需要传输更多数据，大批次处理时会增加集群资源消耗，拖慢作业速度。

重复转换开销 #

• INTEGER：无需额外转换，直接在流处理、Ontology中使用，代码逻辑简洁，完全避免转换带来的计算开销。
• STRING：源数据为数值型时，需在流处理中执行CAST(id AS STRING)转换；后续若需转回数值进行计算，又会产生额外开销，频繁转换还可能引入格式异常错误。

内容的提问来源于stack exchange，提问作者Jonathan Lam