#InterSystems IRIS

InterSystems 常见问题系列FAQ

InterSystems 产品里数据 (表、对象、实例数据) 是存在global 变量里的。
每个global 的数据大小可以从管理门户中中点击属性查看Management Portal > System > Configuration > Local Database > Globals page, 然后在global 属性页点击计算大小Calculate Size 按钮。
你可以在终端上调用^%GSIZE 来在命名空间里显示数据大小，方法如下.

在 OEX 最近一次编程竞赛之后，我有一些令人惊讶的发现。
几乎所有的应用程序都是基于人工智能与预制 Python 模块的结合。
但深入研究后发现，所有示例都使用了 IRIS 的相同技术组件。

从 IRIS 的角度来看，无论是搜索文本还是搜索图像或其他模式都是一样的。 其底层基本都是一样的。

这让我想起了我家里的情况。我的妻子和女儿对家里的大量裙子、衬衫和其他衣服的信息进行了整理。
但无论如何进行整理、分类、归档，我依然通过和我的妻子和女儿说话，来确定我的穿着。
无论怎样包装，其结果都是如此。

回到这次竞赛比赛：
同样的 IRIS 技术内容，却有很多花哨的包装。
每个人都在同一条高速公路上奔跑。没有人提到它有什么限制。

于是我试着深入挖掘，找出新数据类型 VECTOR 的使用限制。
所有向量都有两个基本参数
- 静态 DATATYPE："整型integer"（或 "int"）、"double"、"十进制decimal"、"字符串 "和 "时间戳"。
- 半动态 LEN(gth)： > 0 通常也称为 POSITION；纯整数。

你可以使用List query 对 %SYS.Audit 查询审计日志，代码如下：

低代码挑战

想象一下那个场景。您正在 Widgets Direct 愉快地工作，这是互联网上首屈一指的小部件和小部件配件零售商。您的老板有一些毁灭性的消息，一些客户可能对他们的小部件不太满意，我们需要一个帮助台应用程序来跟踪这些投诉。为了让事情变得有趣，他希望代码占用非常小，并挑战您使用 InterSystems IRIS 以少于 150 行代码交付应用程序。这可能吗？

免责声明：本文记录了一个非常基本的应用程序的构建，为了简洁起见，省略了安全性和错误处理等细节。该应用程序仅供参考，不得用于任何生产应用。本文使用IRIS 2023.1作为数据平台，并非所描述的所有功能在早期版本中都可用

第 1 步 - 定义数据模型

我们首先定义一个新的干净的命名空间 - 带有代码和数据数据库。虽然所有内容都可以位于 1 个数据库中，但将它们拆分以便于数据刷新。

列式存储是 InterSystems IRIS 提供的一项较新的技术。与传统的基于行的存储不同，它通过将数据存储在列而不是行中来优化查询处理，从而实现更快的访问和检索相关信息。

下面是使用SQL创建此类表的例子

最近有某国内三甲医院为满足评级和飞行检查要求，希望提升HIS和IRIS的SQL查询效率，客户和实施工程师整理了一个慢查询的SQL列表， 有一些查询比较慢， 查询时间在甚至大于60分钟。

在我们和厂商共同努力下，对整个库的SQL查询做了优化。 下表是记录了我们在进行了大部分优化工作后的结果，您可以看到大多查询从几十分钟减少到了几十秒甚至1秒以内。其中有几个慢到几分钟的查询，最后经过细调， 也把查询耗时减少到了一分钟以内。 优化的效果还是很明显的。

这里我分享一下操作的要点，以便给其他有同样问题的客户一个思路。

其实如果您看过我前面的帖子，应该已经有了基本的概念。我就把工作流程总结一下，其实就这么几个步骤：

步骤一：

SQL查询优化器一般情况下能给出最好的查询计划，但不是所有情况都这样，所以InterSystems SQL还提供了一个方式， 也就是在查询语句里加入optimize-option keyword（优化关键字）, 用来人工的修改查询计划。

比如下面的查询：

SELECT AVG(SaleAmt) FROM %PARALLEL User.AllSales GROUP BY Region

其中的%PARALLEL, 就是最常用的优化关键字， 它强制SQL优化器使用多进程并行处理这个SQL。

您可以这样理解： 如果查询优化器足够聪明，那么绝大多数情况下，根本就不需要优化关键字来人工干预。因此，您也一定不奇怪在不同的IRIS/Caché版本中， 关键字的表现可能不一样。越新的版本，应该是越少用到。比如上面的%PARALLEL， 在Caché的大多数版本中， 在查询中加上它一般都能提高查询速度，而在IRIS中，尤其是2023版本以后， 同样的SQL查询语句，很大的可能查询优化器已经自动使用多进程并行查询了，不再需要用户人工干预了。

因此，先总结有关优化关键字的要点：

VIP：192.168.30.111，故障转移节点一（192.168.30.10），故障转移节点二（192.168.30.11），ECP地址192.168.30.100

在配置时ECP里增加数据服务器IP为【主】故障转移节点一（192.168.30.10）【文档说不能使用VIP地址】后，

如果主从切换。ECP里的数据服务器IP，会自动变换成故障转移节点二（192.168.30.11）【此时为主】吗？

如果不能，需要手动变更吗？还是不需要？

当我们在设计一个需要重复使用的BP时候，往往需要开发一个可配置<call>的对象的组件，我们将call的target 设置为

@process.TargetConfigName

即可实现。

下面是完整代码：

Hey Community,

Play the new video on InterSystems Developers Bilibili官方频道:

⏯ 与 InterSystems 一起释放机器学习的力量

//player.bilibili.com/player.html?aid=1553341786&bvid=BV181421d73a&cid=1509585441&p=1
[这是一个嵌入式链接，但由于您拒绝了访问嵌入式内容所需的 Cookie，您无法直接在网站上进行查看。要查看嵌入式内容，您需要在 Cookie 设置中接受所有 Cookie。]

SQL Performance Analysis Toolkit，或者叫SQL性能分析工具，并不是给维护人员使用的。

在RIS文档里是这么说的： 这个工具包里的工具收集SQL执行的详细信息，用来找出一个查询计划的特殊问题。 使用这些信息，开发人员改善这个查询的效率。 它可以非常大的增加服务器的开销。..., 它不应该被持续执行。

要做分析，首先您需要打开一个采集“SQL runtime Statistics"的开关来收集详细信息，这个开关默认的状态是OFF。 文档里说： The SQL Performance Analysis Toolkit offers support specialists the ability to profile specific SQL statements or groups of statements.

这里的"support specialists"指的是厂家的技术支持人员。

因此，总结如下：

为什么要读Query Plan, 在线文档中有句话是这么说的：

While the SQL compiler tries to make the most efficient use of data as specified by the query, sometimes the author of the query knows more about some aspect of the stored data than is evident to the compiler. In this case, the author can make use of the query plan to modify the original query to provide more information or more guidance to the query compiler.

翻译一下是这样：系统给你的查询计划并不总是最好的，如果您能对查询计划，可以人工做更精细的优化。

2024年3月26日，InterSystems数据平台全球主管Scott Gnau发文，宣布InterSystems IRIS数据平台新增了向量搜索（vector search）功能。

本文作者为Scott Gnau，InterSystems数据平台全球主管。

这是在 IRIS 中完全运行向量搜索演示的尝试。
没有外部工具，您需要的只是终端/控制台和管理门户。
特别感谢Alvin Ryanputra作为他的软件包iris-vector-search的基础
灵感和测试数据的来源。
我的软件包基于 IRIS 2024.1 版本，需要注意您的处理器功能。

我尝试用纯 ObjectScript 编写演示。
仅描述向量的计算是在嵌入式Python中完成的

计算 2247 个记录的 384 维向量需要时间。
在我的 Docker 容器中，它正在运行 01:53:14 来完全生成它们。