基于 IRIS SQL高级功能实现 CI/CD的技术原理和指导

在数量众多、形形色色的 SQL 数据库市场中，InterSystems IRIS 作为一个超越 SQL 的平台脱颖而出，它提供无缝的多模型体验，支持丰富的开发范式。 特别是，先进的对象-关系引擎已经帮助组织为其数据密集型工作负载的每个方面使用了最适合的开发方式，例如在通过对象获取数据并同时通过 SQL 查询数据。 持久类与 SQL 表相对应，其属性与表中的各列相对应，可以使用用户定义的函数或存储过程轻松访问业务逻辑。 在这篇文章中，我们将深入了解表面之下的一点底层技术，讨论它可能如何影响您的开发和部署方式。 这是我们计划发展和改进的产品领域，因此请不要犹豫，在下面的评论区分享您的观点和体验。

保存存储定义 {Saving the Storage Definition}

编写全新的业务逻辑很容易，而且假如您有定义明确的 API 和规范，那么调整或扩展通常也很容易。 但是，当它不仅仅是业务逻辑，还涉及持久化数据时，从初始版本更改的任何内容都将需要能够妥善处理通过早期版本获取的数据。

在 InterSystems IRIS 上，数据和代码在一个高性能引擎中共存，没有您在其他 3GL 或 4GL 编程框架中可能看到的六个抽象层。 这意味着，在使用默认存储时，只有一个非常薄且透明的映射将您的类属性映射到每行数据Global节点的 $list 位置。 如果想添加或移除属性，您不希望已移除的属性中的数据显示在新属性下。 类属性的这个映射是由存储定义进行处理的，这是一个您可能已经在类定义的底部注意到的神秘XML 块。 首次编译类时，将根据该类的属性和参数生成新的存储定义。 当您对类定义进行更改后，在重新编译时，这些更改将与现有存储定义进行协同和修正，以便与现有数据保持兼容。 因此，当您试着重构类时，存储定义会仔细考虑您之前做的事情，并确保新旧数据都可以访问。 我们称之为**Schema 演进**。

在其他大多数 SQL 数据库中，表的物理存储是不透明的，如果可见的话，并且只能通过类似 `ALTER TABLE` 语句进行修改。 这些都是标准 DDL（数据定义语言）命令，但表达能力比直接在 IRIS 上修改类定义和过程代码要差很多。 

InterSystems 致力于让 IRIS 开发者能够干净利落地分离代码和数据，因为这对于确保应用程序的顺利打包和部署至关重要。 存储定义在这方面发挥着独特的作用，因为它可以捕获两者之间的映射方式。 这就是值得在传统开发和 CI/CD  pipeline不同实践的背景下对其进行深入研究的原因。

导出为通用描述语言 Universal Definition Language 

如今，源代码管理是以文件为基础的，所以我们先来看看 IRIS 的主要文件导出格式。 顾名思义，通用描述语言UDL意味着您在 InterSystems IRIS 上编写的所有代码的文件格式是通用的。 这是使用 VS Code ObjectScript 插件时的默认导出格式，并产生易于读取的文件，该文件与您在 IDE 中看到的内容几乎完全相同，并且您的应用程序中的每个类（表）都有一个单独的 .cls 文件。 您可以使用$SYSTEM.OBJ.Export 或者是用 VS Code 插件来创建 UDL 文件。

在Studio的时代，您可能还记得一种 XML 格式，它会捕获与 UDL 相同的信息，并允许将多个类分组到一个导出中。 虽然这种格式在某些场景中很方便，但在读取和跟踪不同版本之间的差异时却不太实用，因此我们暂时将其忽略。

由于 UDL 旨在捕获 IRIS 可以表达的关于类的所有内容，它会包含类定义的所有元素，包括完整的存储定义。 在导入已包含存储定义的类定义时，IRIS 会验证该存储定义是否涵盖该类的所有属性和索引，如果是，只需按原样接受并覆盖该类先前的存储定义即可。 这使得 UDL 成为一种管理类及其存储定义版本的实用格式，因为无论您将它部署到何处，它都会保留通过先前版本的类获取的数据的向后兼容性。 

如果您是一位硬核开发者，您可能想知道这些存储定义是否会不断增长，是否需要无限期地携带这些“包袱”。 存储定义的目的是保持与预先存在的数据的兼容性，因此如果您知道没有这些数据，并且希望摆脱冗长的兼容和继承关系，则可以通过从类定义中移除存储定义并让类编译器重新生成来“重置”存储定义。 例如，您可以使用它来利用新的最佳实践，比如扩展集的使用，它们会实现经过哈希处理的Global名称，并将每个索引分离到自己的全局名称中，从而提高效率。 为了在应用程序内实现向后兼容性，我们不能在 %Persistent 超类中统一更改此类默认值（但我们在使用 `CREATE TABLE` DDL 命令从头开始创建表时会应用它们），因此定期检查类及其存储是很有价值的。 用户也可以直接编辑存储定义 XML文件，但应格外小心，因为这可能会导致现有数据无法访问。

存储定义会提供类之间的智能映射，并随着Schema的演进而自动调整。 还有什么？

静态还是动态？

您可能知道，InterSystems IRIS SQL 引擎充分利用表统计信息来确定用户执行的任何给定语句的最佳查询计划。 表统计信息包括表大小、值在列中的分布方式等指标。 此信息可以帮助 IRIS SQL 优化器确定哪个索引最有用，按何种顺序连接表等，因此直观地说，统计信息越新，优化查询计划的机会就越大。 遗憾的是，直到我们在 IRIS 2021.2 中引入快速块采样之前，收集准确的表统计信息一直是一项计算成本高昂的操作。 因此，当客户将同一应用程序部署到数据模式基本相同的许多环境中时，有必要考虑应用程序代码中的表统计信息部分并将其包含在表定义中。

这就是如今在 IRIS 上您会发现存储定义内嵌入了表统计信息的原因。 通过手动调用 `TUNE TABLE` 收集表统计信息或通过查询（见下文）隐式收集表统计信息时，新统计信息会写入存储定义，此表的现有查询计划将失效，因此它们可以在下次执行时利用新统计信息。 由于它们是存储定义的一部分，这些统计信息将是 UDL 类导出的一部分，因此会出现在源代码存储库中。 如果是经过仔细审查的已打包应用程序的统计信息，这是可取的，因为您会希望这些特定的统计信息能够推动生成所有应用程序部署的查询计划。

从 2021.2 开始，当查询一个根本没有任何统计资料且符合快速块采样条件的表时，IRIS会在查询计划开始时自动收集表的统计数据。在我们的测试中，使用最新的统计数据对比完全没有统计数据而言的好处，明显大于即时收集统计数据的成本。然而，对于一些客户来说，这会有一些副作用，即在开发人员的实例上自动收集的统计数据最终出现在源控制系统的存储定义中，并最终出现在打包的应用程序中。很明显，该开发者环境中的数据以及其上的统计数据可能无法代表真正的客户部署，并导致次优的查询计划。

这种情况可以轻松避免。 可以在调用$SYSTEM.OBJ.Export()时使用 `/exportselectivity=0` 限定符，在类定义导出中排除表统计信息。 可以使用$SYSTEM.OBJ.SetQualifiers("/exportselectivity=0")配置此标志的系统默认值。 然后，可以由最终部署中的自动收集来决定如何获取代表性的统计信息，将明确的统计信息收集作为部署过程的一部分，这会覆盖应用程序可能打包的任何内容，或者通过它们自己的导入/导出函数单独管理表统计信息：$SYSTEM.SQL.Stats.Table.Export()和 Import()。  

从长远来看，我们打算将表统计信息移到数据中，而不是作为代码的一部分，并且更清晰地区分开发者明确定义的统计信息与从实际数据中收集的统计信息。 此外，我们正在计划实现更大程度的自动化，以根据表数据随时间的变化情况定期更新这些统计信息。 

总结

在这篇文章中，我们概述了存储定义在 IRIS 对象-关系引擎中的作用，它如何支持Schema的演进，以及将其包含在源代码管理系统中的意义。 我们还介绍了目前将表统计信息存储在该存储定义中的原因，以及为了确保您的应用程序部署最终具有代表实际客户数据的统计信息而建议的开发做法。 如上所述，我们计划进一步增强这些功能，因此我们期待您对当前功能和计划功能提供反馈意见并适当优化我们的设计。