搜索​​​​

近日，InterSystems极客俱乐部举办了线上直播“InterSystems Caché系统运维培训”，这是系列视频之一。InterSystems中国资深售前顾问祝麟讲解了“InterSystems Caché系统高可用与数据库镜像”。

InterSystems 是一家已经深耕数据库平台领域达44年的公司，成立于1978年，现在已经在全球的80多个国家开展相关业务，每天有超过10亿患者的电子病历数据都跑在以我们的数据库平台构建的应用系统之上。 我们的客户遍布国内外，国内的大几百家三甲医院客户，中国复旦排行榜上超过1/3的顶级医院都在使用我们产品（包括北京协和医院，华西医院，湘雅等等），我们的技术合作伙伴，如东华医为，嘉和，和仁等也都是国内医疗信息领域的著名厂商。 而在国外，我们也有非常多的顶级客户，仅仅以美国举例，美国最顶级的排名前20的所有医院，无一例外全部都是使用的interSystems公司的数据库平台产品。 美国排名前20的所有顶级医院 2020-2021《美国新闻与世界报道》(U.S. News & World Report)最顶级医院名单（前20家医疗机构）均应用InterSystems公司的数据库平台： Mayo Clinic, Rochester, Minnesota （明尼苏达州罗彻斯特市梅奥诊所）Cleveland Clinic（克利夫兰诊所） Johns Hopkins Hospital, Baltimore（巴尔的摩约翰霍普金斯医院）(tie). New York-Presbyterian Hospital-Columbia and Cornell, New York（纽约长老会医院 ） (tie). UCLA Medical Center, Los Angeles（加州大学洛彬矶分校医学中心）Massachusetts General Hospital, Boston（波士顿麻省总医院 ）Cedars-Sinai Medical Center, Los Angeles（洛杉矶Cedars-Sinai医疗中心 ）UCSF Medical Center, San Francisco（旧金山加州大学旧金山分校医疗中心 ）NYU Langone Hospitals, New York（纽约大学朗格尼医学中心）Northwestern Memorial Hospital, Chicago（芝加哥西北纪念医院）University of Michigan Hospitals-Michigan Medicine, Ann Arbor（安娜堡密歇根大学医学院）Brigham and Women’s Hospital, Boston（波士顿哈佛医学院教学附属医院布列根和妇女医院）Stanford Health Care-Stanford Hospital, Stanford, California（斯坦福医疗中心）Mount Sinai Hospital, New York（纽约西奈山医院）Hospitals of the University of Pennsylvania-Penn Presbyterian, Philadelphia（费城宾夕法尼亚大学-宾夕法尼亚长老会医院）Mayo Clinic-Phoenix（凤凰城梅奥诊所）Rush University Medical Center, Chicago（芝加哥拉什大学医学中心）(tie). Barnes-Jewish Hospital, St. Louis（圣路易斯巴恩斯医院）(tie). Keck Hospital of USC, Los Angeles（洛杉矶南加州大学凯克医院）Houston Methodist Hospital（休斯顿卫理公会医院） InterSystems 公司久负盛名的两款产品: Cache 与 Ensemble , 以其稳定性好，速度快著称，在国内外均有无数医院用户。 自2018年底InterSystems 公司推出其新一代的 IRIS for Health 数据库平台后，基于新产品更高的性能表现及更强大的功能与扩展能力，我们鼓励所有的Cache 及Ensemble 老用户逐渐向最新一代的IRIS 以及Health Connect 平台迁移。以获得更好的性能及用户体验,并且在未来可以支撑更多新的发展需求。 Cache 与 Ensemble 的最新版本也止于2018年，未来我们将继续对使用这两款产品的客户提供支持服务，但不会在其之上开发新的功能。 以下附件中，提供了截止目前这两款产品Cache / Ensemble 与其新的下一代的产品 IRIS for Health / Health Connect 的功能清单对比，可点击参考：

当进程中的数据不需要持久化保存，但又需要用到global的高性能特性时，我们常常将数据保存在临时global中，也就是保存在IRISTEMP/CACHETEMP数据库中。 系统使用 IRISTEMP/CACHETEMP 数据库保存临时的数据，用户也可以进行同样的操作。 关于临时global以及IRISTEMP数据库的更多内容，可以参见文档 Temporary Globals and the IRISTEMP Database 以下情况global作为临时使用： 系统临时global (^IRIS.Temp*, ^%cspSession, ^CacheTemp*, ^Mtemp*, 等) 用户定义的 globals 映射至 IRISTEMP/CACHETEMP 处理私有globals (^||name, ^|"^"|name, ^["^"]name,^["^",""]name,等) GLOBAL TEMPORARY 表 1和2的大小可以通过使用 ^%GSIZE 获取 USER>do ^%GSIZE Directory name: c:\intersystems\iris\mgr\user\ => c:\intersystems\iris\mgr\iristemp\ // 指明iristemp 数据库的位置 All Globals? No => yes // Yes 为显示所有globals: 34 项被选中 34 available globals Show details?? No => No // No 为不显示更多信息 Device: Right margin: 80 => ： 3和4 进程私有global 可以通过使用 ^GETPPGINFO 查看。 更多关于 ^GETPPGINFO 的信息请查阅文档 这里 下面的例子列出了当前进程下所有的私有globals： set ^||flintstones(1)="Fred" set ^||flintstones(2)="Wilma" znspace "%SYS" do ^GETPPGINFO("*") 另一个方法用于输出单个进程使用较大数量的私有global： set ns=$namespace znspace "%SYS" // Only processes with more PPG blocks than the total number of processes are included set st=##class(%SQL.Statement).%New() set status=st.%PrepareClassQuery("%SYS.ProcessQuery","AllFields") set rs=st.%Execute() while rs.%Next() { set pid=rs.%Get("Pid") // Process ID set cnt=rs.%Get("PrivateGlobalBlockCount") // Number of PPG blocks // When the number of PPG blocks per process is 0 or more, the contents are output (the following example shows 20 or more blocks). if cnt > 20 { set rs2=##class(%ResultSet).%New("%SYS.ProcessQuery:PPG") // "N" Do not return subscripts of a PPG, just return the root name // "B" Return the number of blocks used by the PPG (needs the "N" option) do rs2.Execute("*",pid,"NB") for { quit:'rs2.Next() write cnt_" PID:"_pid_", PPG name "_rs2.GetData(1)_" is using "_rs2.GetData(3)_" disc blocks",! } } } znspace ns

2022年9月9日，我们将举办线上“InterSystems 2022全球峰会亮点解读”，点击此处参会。 亮点一：Smart Data Fabric（智能数据编织） 认识Data Fabric（数据编织）：概念与应用场景 Data Fabric如何实现高质量数据驱动业务决策？ InterSystems IRIS数据平台提供的Smart Data Fabric解决方案 亮点二：InterSystems IRIS数据平台的三大能力 释放数据价值：通过HL7 FHIR标准支撑CDSS应用和数据探索，使传统数据中心不再受制于特定消息格式，提升医院按需投放数据、释放数据价值的能力。 与Python数据交换：InterSystems IRIS数据平台具有5种与Pyhton数据交互方式，本次研讨会重点介绍DB-API和Embedded Python，并进行实操演示。 列存储：新增的一种数据存储方式，与传统的行存储相比，它将复杂的聚合类分析查询性能提升了一个数量级。 亮点三：HealthShare Health Connect 功能提升 通过HL7 V2 特性提升、数据转换编辑器增强、规则编辑器增强、集成产品扩展架构、接口关系图等，提高实施效率、降低实施成本、提升平台价值。

这里只讨论Caché和IRIS本身产生的错误和警告。用户在维护工作中通常会需要更多的内容， 那些我们在后面的 “系统性能指标”里介绍。另外， 关于集成平台的告警和日志， 也会在后面单独讨论。集成平台，也就是Ensemble Production，是IRIS系统上运行的应用，它的日志，告警，以及指标，测量，是单独的内容。 ### 控制台日志 控制台日志是系统运行状态的日志文件，在IRIS里是messages.log, 在Cache‘里的名字是console.log，默认放在安装目录的mgr子目录。 用户也可以在管理门户的"系统操作>系统日志>控制台日志"里查看。以下是一个实际的例子： ``` *** Recovery started at Fri Jan 03 16:26:05 2020 Current default directory: c:\intersystems\hsap\mgr Log file directory: c:\intersystems\hsap\mgr\ WIJ file spec: c:\intersystems\hsap\mgr\CACHE.WIJ Recovering local (c:\intersystems\hsap\mgr\CACHE.WIJ) image journal file... Starting WIJ recovery for 'c:\intersystems\hsap\mgr\CACHE.WIJ'. 0 blocks pending in this WIJ. Exiting with status 3 (Success) 01/03/20-16:26:43:627 (8108) 2 Failed to allocate 2880MB shared memory using large pages. Switching to small pages. 01/03/20-16:26:43:627 (8108) 0 Allocated 2880MB shared memory: 2048MB global buffers, 512MB routine buffers 01/03/20-16:26:43:627 (8108) 0 Intel Sandy Bridge AES-NI instructions detected. 01/03/20-16:26:43:731 (8108) 0 Jrn info from prior WIJ (imflags: 0): (Skip multiple records…) 01/04/20-00:00:00:804 (6900) 1 Warning: Alternate and primary journal directories are the same 01/04/20-00:00:00:820 (16272) 0 CACHE JOURNALING SYSTEM MESSAGE Journaling switched to: c:\intersystems\hsap\mgr\journal\20200104.001 01/04/20-10:15:41:703 (16096) 0 DELETE: c:\intersystems\hsap\mgr\journal\20191231.001 01/04/20-10:15:41:734 (12224) 0 Purging old application errors 01/05/20-00:00:00:497 (6900) 1 Warning: Alternate and primary journal directories are the same...(repeated 1 times) 01/05/20-00:00:00:528 (12472) 0 CACHE JOURNALING SYSTEM MESSAGE Journaling switched to: c:\intersystems\hsap\mgr\journal\20200105.001 01/05/20-00:00:01:653 (11436) 1 %SYS.Task.FeatureTracker failed to transfer data 01/05/20-18:18:34:726 (2260) 0 DELETE: c:\intersystems\hsap\mgr\journal\20200101.001 01/05/20-18:18:34:789 (14444) 0 Purging old application errors ``` 控制台日志的记录包括系统的启动停止记录，许可证的使用情况，各种底层资源，网络连接，数据库日志等等的所有内容。记录按严重程度四个等级，分别是 - 0: 一般性消息 (Information/Status) - 1: 警告性错误 (Warning) - 2: 严重错误 (Severe) - 3: 致命性错误 (Fatal) **除了等级为0的一般性消息，剩下的1，2，3个等级的记录都被称为错误**。错误的严重程度从1到3逐渐升高，其中2和3两个级别通常被称为严重错误(Serious Alert)。默认的配置下，它们会被写如另一个警告通知的日志Alert.log，以通知管理员。比如上面例子中的第9行 *“01/03/20-16:26:43:627 (8108) 2 Failed to allocate 2880MB shared memory using large pages. Switching to small pages.”*，就是一个Severe错误，应该被管理员马上知晓。 ### 错误是怎么来的 这里只说控制台日志中呈现的错误，也就是等级1-3的记录，它们的来源有： #### 系统底层直接产生的错误 系统底层产生的基本是严重错误 (Severe)和致命性错误 (Fatal)级别，这里给几个常见的例子，文章z > Write to journal file has failed > ECP client daemon/connection is hung > Failure during PIJ processing - Declaring a crash > Error reading block – recovery read error > Error writing block – recovery write error > ... 这里是[完整的列表的链接](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_monitor#GCM_monitor_errors) #### 系统监视器产生的错误 系统运行中默认的系统监视器(System Monitor)和健康监视器(Health Monitor)负责系统的监控工作。他们工作在%SYS命名空间，默认会随系统启动而启动，然后以30秒一次的频率读取系统指标，当指标达到并超过预置的门限值时会触发错误信息写入控制台日志， 级别是Warning(警告)或者严重错误 (Severe)。 > 这里只列出默认情况下什么样的指标会触发错误消息，而背后详细的技术细节会在 “Caché和IRIS的监控器”章节介绍。 **系统监视器产生的错误**针对系统的运行状态和资源，**产生告警的规则不可修改**。注意下图中Warning, Alert对应着Console log里的Waring级别和Severe或者fatal级别。 下表可以在最新版本的IRIS文档中的[这个链接](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_healthmon#GCM_healthmon_sysmon_alerts)找到。  #### 健康监视器产生的错误 Health Monitor是另一个评估内部产生的指标的监视器，也是工作在%sys命名空间。它和System Monitor的区别是: **用户可以修改评估的规则，设置适合自己的告警门限值。** Health Monitor默认不激活，因此需要人工启动。但是，如果你发现虽然你没有启动HealthMonitor， 但系统正按照它的规则发送通知，那也不用奇怪，那就是这个监视器的一部分规则不需要启动就自动工作。它的监控项目和规则如下图。 ``` Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ CPUPct 50 90 0 80 0 CPUusage 50 85 0 75 0 CSPActivity 100 0 2 0 1.6 CSPActualConnections 100 0 2 0 1.6 CSPGatewayLatency 1000 2000 0 1000 0 CSPInUseConnections 100 0 2 0 1.6 CSPPrivateConnections 100 0 2 0 1.6 CSPSessions 100 0 2 0 1.6 DBLatency 1000 3000 0 1000 0 DBReads 1024 0 2 0 1.6 DBWrites 1024 0 2 0 1.6 DiskPercentFull 50 99 0 95 0 ECPAppServerKBPerMinute 1024 0 2 0 1.6 ECPConnections 100 0 2 0 1.6 ECPDataServerKBPerMinute 1024 0 2 0 1.6 ECPLatency 1000 5000 0 3000 0 ECPTransOpenCount 100 0 2 0 1.6 ECPTransOpenSecsMax 60 0 2 0 1.6 GlobalRefsPerMin 1024 0 2 0 1.6 GlobalSetKillPerMin 1024 0 2 0 1.6 JournalEntriesPerMin 1024 0 2 0 1.6 JournalGrowthRate 1024 0 2 0 1.6 LicensePercentUsed 50 0 1.5 0 0 LicenseUsedRate 20 0 1.5 0 0 LockTablePercentFull 50 99 0 85 0 LogicalBlockRequestsPerMin 1024 0 2 0 1.6 MirrorDatabaseLatencyBytes 20000000 0 2 0 1.6 MirrorDatabaseLatencyFiles 3 0 2 0 1.6 MirrorDatabaseLatencyTime 1000 8000 0 4000 0 MirrorJournalLatencyBytes 20000000 0 2 0 1.6 MirrorJournalLatencyFiles 3 0 2 0 1.6 MirrorJournalLatencyTime 1000 5000 0 3000 0 PhysicalBlockReadsPerMin 1024 0 2 0 1.6 PhysicalBlockWritesPerMin 1024 0 2 0 1.6 ProcessCount 100 0 2 0 1.6 RoutineCommandsPerMin 1024 0 2 0 1.6 RoutineLoadsPerMin 1024 0 2 0 1.6 RoutineRefsPerMin 1024 0 2 0 1.6 SMHPercentFull 50 98 0 85 0 ShadowConnectionsLatency 1000 0 2 0 1.6 ShadowLatency 1000 0 2 0 1.6 TransOpenCount 100 0 2 0 1.6 TransOpenSecsMax 60 0 2 0 1.6 WDBuffers 1024 0 2 0 1.6 WDCycleTime 60 0 2 0 1.6 WDWIJTime 60 0 2 0 1.6 WDWriteSize 1024 0 2 0 1.6 ``` 表格很长，共列有47个sensor。大概的意思都可以从名字看出来，如果要阅读具体的定义，请看[原始文档](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_healthmon#GCM_healthmon_overview_api_sensors)。后面的几个字段，Base，Max，Max M，Warn，Warn M定义了这个sensor是怎么确定门限值的。 **第1类：固定的门限值** 也就是定义了Base, Max, Warning字段内容的条目，比如这个条目： ``` Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ CPUusage 50 85 0 75 0 ``` - 只要System Monitor已经启动，这个rule就工作，不需要Health Monitor处于激活状态。 - 只用max和warning值来决定是否超门限。连续3次读数超过了max值，产生alert, 连续5次读数超过了warning值，产生warning. 对于这些指标，系统允许用户自己设置告警的门限值，比如把上面CSPUsage的Warn, Max修改为80，90，或其他适合用户自己的数值。 **第2类：动态的门限值** 也就是定义了Base, Multiplier, WarningMultiplier字段内容的条目。例如下面的DBReads： ``` Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ DBReads 1024 0 2 0 1.6 ``` 统计学上， 均值(Mean)加3个Sigma是最常用的判断一个采样是否偏离太多的方法。因为是要设置门限值，这里添加了两个乘法系数(Multiplier), MAX M和Warn M，得到一个动态的门限值。当sensor的采样值比均值大的太多了，就会产生错误条目，warning或者alert. 具体的公式是： `产生错误的门限= Max((平均值+3*Sigma)*Multiplier，最大值+Sigma)` 因为大多数情况Max()中第一项的数值都是大的，所以公式可以翻译为：比（平均值+3个sigma)*Multiplier，就是告警的门限。 以上面例子中DBReads说明： Base= 1024, Multiplier=2；WarningMultplier=1.6。监视器开始运行时，会不停的计算这个时段内的平均值，最大值和sigma，产生一个Chart。假如某一刻平均值=2145, sigma=141，最大值为2327，那么根据上面的公式： `Warning门限 = Max((2145+3*141) * 1.6，2327+141) = 4108.8` `Alert门限 = Max((2145+3*141) * 2， 2327+141) = 5136` 也就是说，当您DBReads, 也就是数据库读的平均值是2145/s时，突然来了一个超过4109/s的业务，就会有一个错误信息写到控制台日志，严重级别是1, warning。短时间数据库查询再增加，超过alert门限，就会有严重级别为2的控制台日志被写入，同时这个条目也会写到alert.log文件，用来向管理员发通知。 可以看出，这个设置中base不重要，它只在监视器刚启动时有用，而使这个门限值有意义的是multipler的设置。 这要求用户对自己的业务很熟悉，而且经常的调整才能得到合适的设置，否则就可能在业务波动大的时候得到很多的错误信息，或者得不到自己想要记录的大的业务波动。 重要的一点： 拥有动态门限值的sensor默认是不工作的， 您想要激活Health Monitor。 是这么操作的： ``` %SYS>do ^%SYSMONMGR 1) Start/Stop System Monitor 2) Set System Monitor Options 3) Configure System Monitor Classes 4) View System Monitor State 5) Manage Application Monitor 6) Manage Health Monitor 7) View System Data 8) Exit Option? 6 1) Enable/Disable Health Monitor 2) View Alerts Records 3) Configure Health Monitor Classes 4) Set Health Monitor Options 5) Exit Option? 1 ...后面省略... ``` 用户还可以自定义了Chart，或者修改及自定义默认的14个监控时段(Period)，以得到更准确的错误产生的控制。有关这些内容请参见在线文档。 #### 上层应用产生的错误 上层的应用可以调用代码把它认为的错误写到控制台日志，而且可以任意定义级别。实际情况中，真正使用控制台日志来发送应用层面的错误的不多，如果您的系统中发现有， 那么一定能很清楚的把这部分错误条目和上述Caché , IRIS系统本身产生的区分出来。 ### 维护人员对错误的控制 维护人员对错误的控制最基本就是调整健康监视器的门限值。上面讲了两类门限值的理论，下面给出一个例子，显示是怎么修改固定门限值的设置的： ```bash %SYS>do ^%SYSMONMGR 1) Start/Stop System Monitor 2) Set System Monitor Options 3) Configure System Monitor Classes 4) View System Monitor State 5) Manage Application Monitor 6) Manage Health Monitor 7) View System Data 8) Exit Option? 6 1) Enable/Disable Health Monitor 2) View Alerts Records 3) Configure Health Monitor Classes 4) Set Health Monitor Options 5) Exit Option? 3 1) Activate/Deactivate Rules 2) Configure Periods 3) Configure Charts 4) Edit Sensor Objects 5) Reset Defaults 6) Exit Option? 4 1) List Sensor Objects 2) Edit Sensor Object 3) Exit Option? 1 Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ CPUPct 50 90 0 80 0 CPUusage 50 85 0 75 0 CSPActivity 100 0 2 0 1.6 CSPActualConnections 100 0 2 0 1.6 CSPGatewayLatency 1000 2000 0 1000 0 CSPInUseConnections 100 0 2 0 1.6 CSPPrivateConnections 100 0 2 0 1.6 CSPSessions 100 0 2 0 1.6 DBLatency 1000 3000 0 1000 0 DBReads 1024 0 2 0 1.6 DBWrites 1024 0 2 0 1.6 DiskPercentFull 50 99 0 95 0 ...(省略多行) WDWriteSize 1024 0 2 0 1.6 1) List Sensor Objects 2) Edit Sensor Object 3) Exit Option? 2 Sensor? 12 DiskPercentFull Base? 50 => Enter either an Alert Value or a Multiplier Alert Value? 99 => 90 Setting Max Multiplier and Warn Multiplier to 0. Enter a Warn Value Warn Value? 95 => 60 Sensor object DiskPercentFull updated. Base 50 MaxMult 0 AlertValue 90 WarnMult 0 WarnValue 60 1) List Sensor Objects 2) Edit Sensor Object 3) Exit ``` 上面的操作中有一个‘神秘数字’ 12. 怎么知道DiskPercentFull是第12个sensor? 我是从列表里数下来的。 注意在修改senosr会出提示要把System Monitor停掉。修改后再启动System Monitor, 这样如果您的硬盘使用超过了60%, 就会收到类似的控制台日志条目： > 12/12/18-15:32:37:349 (13700) 1 [SYSTEM MONITOR] DiskPercentFull(d:\htp\data\) Warning: DiskPercentFull = 74.52 ( Warnvalue is 60). **重复发生的错误会被再次写入控制台日志吗？** 除了最底层的，关乎系统整体运行的少数错误，大部分错误如果在一个小时内重复发生，只有第一次会被写入日志。这就要求用户必须有实时的通知机制， ### 控制台日志的管理 大多数用户不需要操心控制台日志的管理，少数很老的Caché的用户会拥有一个很大尺寸的console.log， 最大的曾见过80MB的文件，这时候从操作门户的页面去查看，已经出现了显示的延迟。 console.log或者messages.log的大小是由系统设置参数‘MaxConsoleLogSize’设定的。 在IRIS和最近些版本的Caché中， 这个设置的值是5MB(您可以在**操作门户的‘系统>设置>其它设置>启动**‘的列表里查看或者修改这个值。 如果一个控制台日志超过了5MB, 会自动切换， 原来的console.log, message.log，会改名为console.log.old.yyyymmdd, 或者message.log.old.yyyymmdd。

大家好！ 我想跟大家分享一个个人项目，该项目始于工作中的一个简单需求：“能否知道我们使用了多少个Caché许可证？” 在阅读社区的其他文章时，我发现了一篇David Loveluck写的非常棒的文章：APM——使用Caché History Monitor。 我根据David的这篇文章，开始使用Caché History Monitor并显示所有这些信息。 在面临“选择哪种很酷的技术”这个问题时，我决定使用简单而强大的CSP，这样我的客户可以认识到Caché不仅仅是MUMPS/终端。 在创建了页面以显示许可、数据库增长和CSP会话的历史记录后，我决定为System Dashboard和进程页面创建一个新设计。 我的Caché实例运行得良好。 但是，如果使用IRIS呢？根据Evgeny Shvarov的文章：在InterSystems IRIS开发存储库中使用Docker，我实现了docker技术，并把代码放到了GitHub上，现在大家只需几个步骤就可以进行尝试。 如何运行？ 如要使用这里的repo进行编码，请执行以下操作： 1. 通过Clone/git命令将repo 更新到任意本地目录中： $ git clone https://github.com/diashenrique/iris-history-monitor.git 2. 打开这个目录下的终端，并运行： $ docker-compose build 3. 在项目中运行IRIS容器： $ docker-compose up -d 如何测试 打开浏览器，并转到链接：http://localhost:52773/csp/irismonitor/dashboard.csp 使用用户名_SYSTEM可以运行仪表盘dashboard和其他功能。 系统仪表盘 系统仪表盘（System Dashboard）可展示： ·许可 ·系统时间 ·应用程序错误 ·缓存过程 ·CSP会话 ·Lock Table ·日志空间 ·日志状态 ·ECP AppServer ·ECP DataServer ·编写守护进程 ·缓存效率 ·严重警告 折线图小工具每5秒绘制一个点： 系统菜单 系统进程 进程过滤器 通过使用不同的过滤器可以实现你所需的结果。也可以使用“Multiple Sort（多重排序）”，按Shift +单击列标题，甚至可以将数据网格导出到Excel！ History Monitor（历史记录监控器） CSP会话和许可的History Monitor可显示三个部分的信息： ·每5分钟 ·每天 ·每小时 “Database Growth”部分只显示当日信息。历史记录页面共享以下功能： Date Range Picker（日期选择插件） 默认值为“过去7天” Chart / Data Table（图表/ 数据表） 在每个部分的右上角有两个按钮（Chart / Data Table [图表/ 数据表]） Data Table（数据表）显示创建图表所用的信息，同样可以以Excel格式下载。 Excel中显示CSP中定义的相同格式、内容和组。 缩放 所有图表都有Zoom（缩放）选项，以可视化方式显示更多详细信息。 平均值和最大值 对于“每小时”和“每天”部分，图表显示的是平均值和最大值。 平均值 最大值 希望这篇文章对您有用！ 注：本文为译文，点击此处阅读原文，原文由Henrique Gonçalves Dias撰写。

。之前我展示了如何运行 pButtons 来收集我们在下列帖子中研究的性能指标。 - [第 1 部分 - 入门：收集指标。](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-–-第-1-篇) - [第 2 部分 - 研究收集的指标。](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-–-第-2篇) ## 更新：2020 年 5 月。 _自四年前写下本帖以来，我们已从 Caché 迁移到 IRIS。 有关 pButton (Caché) 和 SystemPerformance (IRIS) 文档的更新链接，请参见评论。 另请注意如何将系统更新到最新版本的性能工具。_ pButtons 与 Caché 5 及更高版本兼容，并已包含在最近的 InterSystems 数据平台分发版（HealthShare、Ensemble 和 Caché）中。 本帖旨在提醒您下载并安装最新版的 pButttons。 最新版本始终可以通过 WRC 下载。需要有WRC登录账户。 https://wrc.intersystems.cn/wrc/coDistTools.csp 您需要下载以下文件： pButtons 它是xml文件，以确保为您的 Caché 版本安装正确的文件。 要检查您现在已安装哪个版本，可以运行： %SYS>write $$version^pButtons() 备注 1： - 当前版本的 pButtons 需要一个许可证单元才能运行，将来的发行版将满足此要求。 - 此 pButtons 发行版的版本已更改。 — 之前的 pButtons 版本为 1.16c — 新发行版为版本 5。 备注 2： - pButtons 版本 5 还更正了版本 1.16a 引入的一个问题，该问题可能导致收集时间非常长。 版本 1.16a 包含在 Caché 2015.1.0 中。 如果您有 pButtons 版本 1.16a 至 1.16c，则应该从 ftp 站点下载 pButtons 版本 5。 有关 pButtons 的更多详细信息，请参见下载的文件以及在线 Caché 文档。

您的应用程序已部署，一切运行正常。 很好，击个掌！ 然后电话突然响个不停 – 用户投诉应用程序有时很“慢”。 这是什么意思？ 有时？ 您有哪些工具，查找和解决这个缓慢问题应查看哪些统计数据？ 您的系统基础架构是否能承担用户负载的任务？ 在投入生产之前，应该询问哪些基础架构设计问题？ 如何自信地为新硬件规划容量，而不会过度规定？ 如何停止电话铃声？ 如何一开始就不让它响？ * * * [本系列其他帖子的列表](https://cn.community.intersystems.com/post/intersystems-数据平台的容量规划和性能系列文章) * * * ## 这将是一次旅程 这是本系列的第一个帖子，本系列将探讨可用于对系统性能进行监视、审查和故障排除的工具和指标，以及影响性能的系统和架构设计注意事项。 在旅程中，我们将朝多个方向前进，了解 Caché、操作系统、硬件、虚拟化以及根据评论中的反馈变为热门的其他方面的性能。 我们将关注反馈循环，其中性能数据提供了一个视角，通过它可查看已部署的应用程序和基础架构的优势和局限性，然后形成反馈以实现更好的设计和容量计划。 不言而喻，您应该不断检查性能指标，但不幸的是，如果客户只是查看数据，他们会多次对长期可见的性能问题感到惊讶。 但问题当然是 - 什么数据？ 我们将从收集一些基本的 Caché 和系统指标来开始这一旅程，这样我们可以对您的系统当前的运行状况有一个感觉。 在以后的帖子中，我们将深入了解主要指标的含义。 有多个可用于系统监视的选项 – 来自 Caché 内部和外部，我们将在本系列中探讨其中的许多选项。  首先，我们将了解我最喜欢的用于连续收集数据的必备工具 ^pButtons，它已经安装在每个 Caché 系统上。 为确保您拥有最新的 pButtons 副本，请查看以下帖子： ## 收集系统性能指标 - ^pButtons Caché 的 pButtons 实用工具可根据其创建的日志文件生成可读的 HTML 性能报告。 pButtons 输出的性能指标可以被轻松提取、绘图和审核。  pButtons html 文件中收集的数据包括： * Caché 设置：配置、驱动器映射等。 * mgstat：Caché 性能指标 - 大多数的值是每秒平均数。 * Unix：vmstat 和 iostat：操作系统资源和性能指标。 * Windows：性能监视器：Windows 资源和性能指标。 * 其他有用的指标。 pButtons 数据收集对系统性能的影响非常小，这些指标已经由系统收集，pButtons 只是将它们打包以便归档和传输。  要保存基准以进行趋势分析和故障排除，好的做法是在一个完整的业务周期内每天收集 24 小时 pButtons（午夜到午夜）。 一个业务周期可能是一个月或更长时间，例如，从月末处理中捕获数据。 如果没有任何其他外部性能监视或收集，则可以全年运行 pButtons。  应注意以下关键点： * 将日志目录更改为远离生产数据的位置，以存储累积的输出文件，避免出现磁盘满的问题！ * 定期运行操作系统脚本或以其他方式压缩和存档 pButtons 文件，这在 Windows 上尤其重要，因为文件可能很大。 * 定期审核数据！ 如果出现需要立即分析的问题，可以预览（立即收集）pButtons 数据，同时继续存储指标，以便在当天运行结束时进行收集。 有关 pButtons 的更多信息（包括预览、停止运行和添加自定义数据收集），请参见最新的 Caché 文档中的 _Caché 监视指南_：  http://docs.intersystems.com 可以将 pButtons HTML 文件数据分离并提取（例如提取为 CSV 文件），以通过脚本或简单的剪切和粘贴将其处理成图形或进行其他分析。 我们以后将在下一个帖子中看到图表输出的例子。 当然，如果您有紧急的性能问题，请联系 WRC。 ### 计划 24 小时 pButtons 数据收集 ^pButtons 可以手动从终端提示符启动，也可以按计划启动。 要计划每天 24 小时收集： 1. 启动 Caché 终端，切换到 %SYS 命名空间，然后手动运行一次 pButtons 以设置 pButtons 文件结构： %SYS>d ^pButtons Current log directory: /db/backup/benchout/pButtonsOut/ Available profiles: 1 12hours - 12 hour run sampling every 10 seconds 2 24hours - 24 hour run sampling every 10 seconds 3 30mins - 30 minute run sampling every 1 second 4 4hours - 4 hour run sampling every 5 seconds 5 8hours - 8 hour run sampling every 10 seconds 6 test - A 5 minute TEST run sampling every 30 seconds 选择选项 6 test - 5 minute TEST run sampling every 30 seconds。 请注意，您的编号可能有所不同，但 test 应该是显而易见的。 在运行期间，运行 Collect^pButtons（如下所示），您将看到包括 runid 在内的信息。 在此例中为“20160303\_1851\_test”。 %SYS>d Collect^pButtons Current Performance runs: 20160303_1851_test ready in 6 minutes 48 seconds nothing available to collect at the moment. %SYS> 注意到这个 5 分钟运行还剩 6 分 48 秒吗？ pButtons 为所有运行增加了 2 分钟宽限期，以便有时间将日志收集和整理成 html 格式。  2. 重要！更改 pButtons 日志输出目录 – 默认的输出位置为 <Caché安装路径>/mgr 文件夹。 例如，在 unix 上，日志目录的路径可能如下所示： do setlogdir^pButtons("/somewhere_with_lots_of_space/perflogs/") 确保 Caché 有该目录的写权限，并且有足够的磁盘空间用于累积输出文件。 3. 运行以下命令以创建一个新的 24 小时配置文件，间隔为 30 秒： write $$addprofile^pButtons("My_24hours_30sec","24 hours 30 sec interval",30,2880) 检查该配置文件是否已添加到 pButtons： %SYS>d ^pButtons Current log directory: /db/backup/benchout/pButtonsOut/ Available profiles: 1 12hours - 12 hour run sampling every 10 seconds 2 24hours - 24 hour run sampling every 10 seconds 3 30mins - 30 minute run sampling every 1 second 4 4hours - 4 hour run sampling every 5 seconds 5 8hours - 8 hour run sampling every 10 seconds 6 My_24hours_30sec- 24 hours 30 sec interval 7 test - A 5 minute TEST run sampling every 30 seconds select profile number to run: 注意：您可以更改收集间隔 – 30 秒对于例行监视是可以的。 对于例行 24 小时运行，我不会选择低于 5 秒的间隔 (…”,5,17280)，因为 pButtons 在每个间隔都会收集数据，而导致输出文件变得非常大。 如果您要对一天中的某个特定时间进行故障排除，并需要更细化的数据，请使用默认的配置文件之一，或创建一个新的自定义配置文件，取较短的时间段，例如 1 小时，间隔为 5 秒 (...",5,720)。 多个 pButtons 可以同时运行，因此可以同时运行一个间隔为 5 秒的短 pButtons 和一个 24 小时 pButtons。 4. 提示 对于 UNIX 站点，可审查磁盘命令。 “iostat”命令使用的默认参数可能未包括磁盘响应时间。 首先显示当前配置了哪些磁盘命令： %SYS>zw ^pButtons("cmds","disk") ^pButtons("cmds","disk")=2 ^pButtons("cmds","disk",1)=$lb("iostat","iostat ","interval"," ","count"," > ") ^pButtons("cmds","disk",2)=$lb("sar -d","sar -d ","interval"," ","count"," > ") 要收集磁盘统计数据，请使用适合您的 UNIX 安装版的命令来编辑语法。 注意尾部空格。 以下是一些示例： LINUX: set $li(^pButtons("cmds","disk",1),2)="iostat -xt " AIX: set $li(^pButtons("cmds","disk",1),2)="iostat -sadD " VxFS: set ^pButtons("cmds","disk",3)=$lb("vxstat","vxstat -g DISKGROUP -i ","interval"," -c ","count"," > ") 您可以同时运行 iostat 和 sar 命令来创建非常大的 pButtons html 文件。 对于定期的性能审查，我通常只使用 iostat。 要仅配置一个命令： set ^pButtons("cmds","disk")=1 有关配置 pButtons 的更多详细信息，请参见在线文档。 5. 在 Management Portal > System Operation > Task Manager 中安排 pButtons 在午夜启动： Namespace: %SYS Task Type: RunLegacyTask ExecuteCode: Do run^pButtons("My_24hours_30sec") Task Priority: Normal User: superuser How often: Once daily at 00:00:01 ### 收集 pButtons 数据 最新版的 InterSystems 数据平台中随附的 pButtons 包括自动收集功能。 要手动收集数据并整理成一个 html 文件，请在 %SYS 命名空间中运行以下命令以生成未完成的 pButtons html 输出文件： do Collect^pButtons 该 html 文件将位于您在步骤 2 设置的日志目录中（如果您未设置，就**现在去设置！**）。 否则默认位置为 <Caché 安装目录/mgr> 文件将命名为 <主机名\_实例\_名称\_日期\_时间\_配置文件名.html>，例如 vsan-tc-db1\_H2015\_20160218\_0255_test.html ### Windows 性能监视器注意事项 如果操作系统是 Windows，则可以使用 Windows 性能监视器 (perfmon) 收集数据，与所收集的其他指标同步。 在 pButtons 的旧版 Caché 发行版中，需要手动配置 Windows perfmon。 如果帖子评论有需求，我将写一篇帖子介绍如何创建 perfmon 模板来定义要监视的性能计数器，并安排与 pButtons 相同的运行期间和间隔。 ### 总结 我们从本帖开始收集一些要研究的数据。 在本周晚些时候，我将开始研究一些样本数据及其含义。 您可以使用您在自己的系统上收集的数据。 到时见。

跨行业用例大多要求具备每秒接收数千或数百万条记录的能力，同时能够支持实时同步查询，例如：股票交易处理、欺诈检测、物联网应用（包括异常检测和实时OEE监控）等。Gartner将这种能力称为“HTAP”（混合事务分析处理）。Forrester等其他公司将其称为Translytics。InterSystems IRIS是功能强大、可扩展、高性能、资源高效的事务分析型数据平台，同时具备内存数据库的高性能以及传统数据库的一致性、可用性、可靠性以及低成本的特性。 混合事务分析处理（HTAP）示例 此示例展示了InterSystems IRIS如何实现每秒接收数千条记录，同时允许对同一集群上的数据进行同步查询，该平台不仅具有很高的接收和查询性能，而且保持了较低的资源利用率。此示例可在单个InterSystems IRIS实例或云端InterSystems IRIS集群上运行。 大家也可以在SAP HANA、MySQL、SqlServer及Amazon Aurora上运行这个示例，以便对性能和资源利用率进行公平、合理的对比。 大家可以在AWS上运行该测试！以下是部分结果： 在AWS上运行InterSystems IRIS和SAP HANA： o在接收记录量方面，InterSystems IRIS比SAP HANA多39% o在查询速度方面，InterSystems IRIS比SAP HANA快3699% 在AWS上运行InterSystems IRIS和AWS Aurora（MySQL）： o在接收记录量方面，InterSystems IRIS比AWS Aurora多831% o在查询速度方面，InterSystems IRIS比AWS Aurora快485% 大家可以在自己的PC上使用Docker（3个CPU和7GB RAM）运行该测试！以下是部分结果： 在个人PC上运行InterSystems IRIS和MySQL 8.0： o在接收记录量方面，InterSystems IRIS比MySQL 8.0多3043% o在查询速度方面，InterSystems IRIS比MySQL 8.0快643% 在Ubuntu系统中运行InterSystems IRIS和SQL Server 2019 o在接收记录量方面，InterSystems IRIS比SQL Server 2019多223%，速度也更快 o在查询速度方面，InterSystems IRIS比SQL Server 2019快134,632%（请注意，数字没有打错哦！） o为公平起见，我们未来将在AWS和Azure上对SQL Server进行测试。敬请期待！ 在测试任何数据库的运行速度时，请先将速度测试运行一段时间进行预热，然后再记录结果。这样可以对数据库进行预扩展并执行其他操作。每次启动速度测试时，我们都需要清空表格重新开始。 1-在AWS上运行速度测试 请点击链接，查看如何在AWS上运行速度测试以便将InterSystems IRIS和其他数据库（如SAP HANA和AWS Aurora）进行对比。 2- 如何在PC上运行速度测试 在PC上运行速度测试的前提条件是： Docker和Docker Compose Git（可以克隆源代码） 目前，可以使用InterSystems IRIS、MySQL、SqlServer及SAP HANA在PC上运行本示例。 2.1 -在InterSystems IRIS Community上运行速度测试 要想在PC上运行本示例，请确保PC已经安装了Docker。您可以使用以下命令在Mac或Linux系统的PC上快速启动并运行： wget https://raw.githubusercontent.com/intersystems-community/irisdemo-demo-htap/master/docker-compose.yml docker-compose up 如果在Windows系统中运行速度测试，请将docker-compose.yml文件下载到一个文件夹中。打开命令提示符，并切换到该文件夹，然后运行docker-compose up c:\MyFolder\docker-compose up 您也可以将存储库克隆到本地计算机上，从而获得完整的源代码。这时需要安装git，并将其放在git文件夹中： git clone https://github.com/intersystems-community/irisdemo-demo-htap cd irisdemo-demo-htap docker-compose up 这两种技术都可行，并会触发示例中用于演示的镜像文件下载，之后将立刻启动所有的容器。 容器启动过程中，将出现与启动中容器相关的大量消息。这是正常的，不用担心！ 启动完成后，它会一直挂在那里，不会把控制权交还给你。这也是正常的。将窗口开着就可以。如果在此窗口上按CTRL+C，docker compose将停止所有容器并停止示例演示。 在所有容器启动之后，在浏览器上打开http://localhost:10000可查看示例的界面。点击“Run Test”按钮即可运行HTAP Demo！ 完成Demo演示后，返回到该终端并按CTRL+C。也可以输入以下命令，停止并删除仍在运行的容器： docker-compose stop docker-compose rm 这点很重要，特别是要在一个数据库（如InterSystems IRIS）和另一个数据库（如MySQL）之间反复运行速度测试时。 2.2 -PC上的MySQL 基于MySQL运行此示例，可以输入以下命令： wget https://raw.githubusercontent.com/intersystems-community/irisdemo-demo-htap/master/docker-compose-mysql.yml docker-compose -f ./docker-compose-mysql.yml up 现在，我们将下载一个不同的docker-compose yml文件：一个带有mysql后缀的文件。我们必须在docker-compose命令中使用-f选项来使用此文件。如前所述，将该终端窗口保持打开状态，并在浏览器上打开http://localhost:10000。 示例运行完成后，请返回终端并按CTRL+C。也可以输入以下命令，停止并删除仍在运行的容器： docker-compose -f ./docker-compose-mysql.yml stop docker-compose -f ./docker-compose-mysql.yml rm 这点很重要，特别是要在一个数据库（如InterSystems IRIS）和其他数据库之间反复运行速度测试时。 我们在测试中发现，InterSystems IRIS的数据接收速度比MySQL和Amazon Aurora快25倍。 2.3 -PC上的SQL Server 2019-GA-ubuntu-16.04 基于SQL Server运行此示例，可以输入以下命令： wget https://raw.githubusercontent.com/intersystems-community/irisdemo-demo-htap/master/docker-compose-sqlserver.yml docker-compose -f ./docker-compose-sqlserver.yml up 与前面一样，将该终端窗口保持打开状态，并在浏览器上打开http://localhost:10000。 我们在本地PC上运行速度测试后发现，InterSystems IRIS的数据接收速度比SQL Server快2.5倍，查询速率则快400倍！我们将与AWS RDS SQL Server相比较，进行速度测试并生成报告。 2.4 -PC上的SAP Hana 要在PC上基于SAP HANA运行速度测试，需要满足以下条件： 包含了Ubuntu 18 VM、docker和docker-compose的虚拟机——因为SAP HANA要求对Linux内核参数进行一些更改，否则将无法支持Mac或Windows上的Docker。另外，SAP HANA需要Linux内核4或更高版本。 该虚拟机至少配置9GB RAM，否则将无法启动！虚拟机崩溃后将显示无用的错误消息。 基于SAP HANA运行此Demo，可以输入以下命令： git clone https://github.com/intersystems-community/irisdemo-demo-htap cd ./irisdemo-demo-htap ./run.sh hana 等待下载镜像和启动容器。当docker-compose停止向屏幕写入时，一切已准备就绪。但是请耐心等待——SAP HANA大约需要6分钟才能启动！因此，屏幕会冻结一分钟左右，然后你会看到SAP HANA写入更多文本。这个重复写入过程大约持续6分钟。看到“启动完成！（Startup finished!）”后，就可以开始下一步了。如果在此过程中因为错误而发生崩溃，则可能需要配置更多的内存。 如您所知，与在InterSystems IRIS和MySQL中运行速度测试一样，使用SAP HANA测试不仅仅是运行docker-compose，还需要对Linux内核进行一些配置。大家可以通过run.sh文件来完成这些配置。 我们在虚拟机上运行速度测试后发现，InterSystems IRIS的数据接收速度比SAP HANA快1.3倍，查询数据的速度快20倍，并且使用了更少的内存。 3-资源 我们正在制作有关本示例的视频。在此期间，您可以点击链接查看一篇有意思的文章，该文章介绍了InterSystems IRIS的体系结构，并解释了为什么它能以更快的速度接收和查询数据。 4-该基准测试与YCSB或TPC-H等标准基准测试相比如何？ Yahoo Cloud Serving Benchmark（YCSB）是一项开源项目，其目的是开发一个框架和一组通用的工作负载，来评估不同的“键-值存储”和“云”服务的性能。 尽管YCSB上有一些工作负载可以描述成HTAP，但YCSB不一定要依靠SQL来完成。但是该基准必须依靠SQL。 TPC-H侧重于决策支持系统（DSS），而这并不是我们正在研究的用例。 此基准测试针对的是接收速度和查询响应时间之间的关系。我们有一个表格，其中包含许多不同数据类型的列。我们想衡量一个数据库在允许响应式查询的同时，其接收记录的速度能有多快。 这是一个复杂的问题。金融服务和物联网等许多行业都要求每秒必须接收数千条记录。在如此高的接收速率下，内存消耗得非常快。传统数据库需要写入磁盘，而内存数据库也将被迫不断写入磁盘（更改log/journal，甚至在某些情况下部分数据会写入内存，就像传统数据库一样）。问题是：如果InterSystems IRIS不仅要将事务日志写入磁盘（像内存数据库一样），还要异步保持数据库的最新状态，那么InterSystems IRIS是如何做到比内存数据库更快的呢？ 一切都与效率有关。接收工作负载会使数据库非常繁忙。CPU和内存都将努力运转。一些内存数据库将尝试压缩内存中的数据。其他内存数据库在内存已满时会将数据持久化到磁盘。所有这些在我们试图实时查询数据库时都有发生。 我们想要证明，在某些工作负载上（例如股票交易、高接收吞吐量[物联网]等），内存数据库的性能不及InterSystems IRIS。这就是我们设计本测试的原因。这意味着该测试比一般用途的测试要简单得多： （1）它只有一个表格，包含19个列和3种差别很大的数据类型 （2）表格上声明了主键（Primary Key）。 （3）我们执行的查询将通过主键（账户ID）获取记录，并使用固定的8个键随机查询：W1A1、W1A10、W1A100、W1A1000、W1A10000、W1A100000、W1A1000000和W1A10000000。这样做的原因如下： 我们知道，在生产系统的内存中保存所有数据是不可能的。内存数据库虽然具有复杂的体系结构，但当内存满了之后，就会将数据移出内存。为了简化测试并使其具有可比性，我们通过主键获取固定记录集，以避免对数据库中可能存在的其他类型的索引进行比较。 通过账号（主键）获取客户账户数据记录是我们许多客户的真实工作负载。数据库在高速接收数据的同时，也需要对查询做出响应。 由于账户ID是主键，因此数据库将使用它的首选（即最优）索引对其进行索引。这样在比较数据库时能够保持公平、简单。 当我们不断请求相同的账号时，数据库有可能将该数据缓存在内存中。这对于内存数据库来说是一项轻松的任务。 InterSystems IRIS是一个混合型数据库。与传统数据库一样，它也尝试将数据保存在内存中。但由于每秒需要接收成千上万的记录，因此内存清理得非常快。通过这个测试可以看到，与其他传统数据库和内存数据库相比，InterSystems IRIS在缓存方面更加智能。你会看到： （1）传统数据库在同时处理接收和查询时表现不佳 （2）内存数据库： 在测试的最初几分钟内表现良好，随着内存填满，数据压缩变得更加困难，不可避免地要写入磁盘 由于系统忙于接收、压缩数据，以及将数据移出内存等，因此查询性能表现不佳。 5-表是怎样的？ 以下是我们发送到所支持的全部数据库的建表语句： CREATE TABLE SpeedTest.Account ( account_id VARCHAR(36) PRIMARY KEY, brokerageaccountnum VARCHAR(16), org VARCHAR(50), status VARCHAR(10), tradingflag VARCHAR(10), entityaccountnum VARCHAR(16), clientaccountnum VARCHAR(16), active_date DATETIME, topaccountnum VARCHAR(10), repteamno VARCHAR(8), repteamname VARCHAR(50), office_name VARCHAR(50), region VARCHAR(50), basecurr VARCHAR(50), createdby VARCHAR(50), createdts DATETIME, group_id VARCHAR(50), load_version_no BIGINT ) 插入程序Ingestion Worker会尽可能多地发送INSERT数据，以测量每秒插入的记录数据量以及每秒的兆字节数。 查询程序Query worker将通过account_id从此表中进行选择，并尝试选择尽可能多的记录来测量性能（即每秒选择的记录以及每秒选择的兆字节），以测试端到端性能，并提供工作量证明（Proof of Work）。 端到端性能与一些JDBC驱动程序最优化有关。如果仅执行查询操作，JDBC驱动程序可能不会从服务器获取记录，只有当实际请求列值后，JDBC驱动程序才会从服务器获取记录。 为了证明实际读取的正是我们选取的列，我们将返回的所有fild的字节加起来作为工作量证明。 6-如何实现接收和查询的最大吞吐量？ 为了实现最大吞吐量，每个ingestion worker将启动多个线程，每个线程将： （1）为上述表格的每一列准备1000个随机值。这样做是为了让每一列具有不同的数据类型和大小。所以我们希望生成可相应变化的记录 （2）对于要插入的每个新记录，ingestion worker将在每列的1000个值中随机选择一个值，准备好之后，该记录将被添加到批处理中 （3）使用批量插入，默认批量大小为每批1000条记录 Ingestion worker的默认线程数量是15，但是可以在测试过程中单击“设置”进行更改。 另一方面，query worker也启动多个线程来查询尽可能多的记录。如上所述，我们也将提供工作量证明。我们将读取返回的列，并汇总读取的字节数，以确保数据是从数据库通过连接传输进入query worker的，从而避免某些JDBC驱动程序实现优化后，仅在实际使用数据时才通过连接传输数据。我们实际使用返回的数据，并提供每秒读取数据的兆字节总和以及读取的总兆字节数作为工作量证明。 7-占用多少磁盘空间? 在接收171,421,000条记录后，我填满了一个70Gb的数据文件系统。这意味着，每条记录平均占用439个字节（向上取整）。 我还填写了第一个日志目录的100%和第二个日志目录的59%。这两个文件系统都有100Gb，这意味着171,421,000条记录将占用大约159Gb的日志空间，换言之，每条记录平均占用996个字节。 8-HTAP Demo体系架构 HTAP Demo的体系架构如下图所示： 本示例使用docker compose启动五项服务： （1）htapui——这是用于运行示例的Angular UI。 （2）htapirisdb——由于本示例在InterSystems IRIS Community上运行，所以不需要InterSystems IRIS许可证即可运行。但请注意，InterSystems IRIS Community有两个重要限制条件： 最多5个连接 数据库最大为10Gb （3）htapmaster——这是HTAP 示例主程序。UI与主程序对话，主程序与worker对话，以及启动/停止速度测试，并收集指标。 （4）ingest-worker1——这是插入程序ingestion worker。实际上，大家可以拥有多个ingestion worker，只需给每个worker分配不同的服务名称即可。它们将尝试尽快地将记录插入数据库。 （5）query-worker1——这是查询程序query worker，大家也可以拥有多个query worker。它们将尝试尽快地从数据库中读取记录。 在PC上运行示例时，我们使用的是Docker和Docker Compose。Docker Compose需要一个docker-compose.yml来描述这些服务及其使用的Docker镜像。本示例实际上提供了许多docker-compose.yml文件，并且很快将添加更多此类文件： （1）docker-compose.yml——这是针对InterSystems IRIS Community（上述项目及图片中有所描述）运行速度测试的默认演示程序。 （2）docker-compose-mysql.yml——这是针对MySQL的速度测试。大家应该注意到，该测试结果表明，InterSystems IRIS比MySQL快25倍。在Amazon Aurora MySQL（MySQL的微调版本）上运行此测试可得到相同的结果。 （3）docker-compose-sqlserver.yml——这是针对使用Docker部署的SqlServer的速度测试。 （4）docker-compose-enterprise-iris.yml——如果要在标准版本的InterSystems IRIS上运行速度测试示例，这是一个docker-compose.yml的文件例子。 9. 可以在没有容器的情况下在InterSystems IRIS集群上运行本Demo吗？ 可以！完成此示例最简便的方法是将此存储库克隆到即将运行master（主程序）和（在同一服务器上运行的）UI的每台服务器上以及每种worker类型（接收和查询worker）上。你可以根据自己的需要，拥有任意数量的接收worker和查询worker！ 对于InterSystems IRIS，请查看文件夹./standalone_scripts/iris-jdbc.中的文件。每个服务器都有一个脚本： （1）在主程序上：start_master_and_ui.sh——此脚本将启动主程序和UI。 （2）在Ingestion Worker上：start_ingestion_worker.sh——此脚本将启动Ingestion Worker，后者随后将与主程序连接并进行注册。 （3）在Query Worker上：start_query_worker.sh——此脚本将启动query worker，然后query worker将与主程序连接并进行注册。 对于InterSystems IRIS，大家有两种选择： （1）可以使用start_iris.sh脚本在Docker容器上启动InterSystems IRIS服务器进行快速测试。 （2）可以手动或使用ICM设置InterSystems IRIS集群。然后做一些有趣的事情，比如： 使接收和查询worker都指向同一InterSystems IRIS 使用ECP配置InterSystems IRIS，让ingestion worker指向数据库服务器，同时让query worker指向ECP服务器 配置分片的InterSystems IRIS集群 等等 只要确保更改start_master.sh脚本中对应使用正确的InterSystems IRIS端点、用户名和密码来配置环境变量。 10-自定义 10.1 -如何配置本Demo让其与更多worker、线程等一起工作？ Docker-compose.yml文件中的环境变量支持配置所有内容。docker-compose.yml文件只是个不错的起点：大家可以复制它们并对副本进行更改，从而得到更多的worker（如果在PC上运行，不会有太大区别），每个worker类型都可以得到更多线程数，还可以更改接收数据的批处理大小，以及各查询之间的等待时间（以毫秒为单位）等。 10.2 -可以更改表的名称或结构吗？ 可以，但必须： （1）在PC上将复制此存储库 （2）更改源代码 （3）使用shellscript build.sh在PC上重建demo。 更改表的结构也很简单。 复制了该存储库后，需要更改/image-master/projects/master/src/main/resources文件夹下的文件。 如果更改表的结构，请确保使用与现有表相同的数据类型，这些数据类型是受支持的。另外还可以更改表的名称。 其次，需要配合更改其他* .sql脚本，如INSERT脚本、SELECT脚本等。 最后，只需运行build.sh来重建demo就可以了！ 11-其他示例应用程序 我们还有一些其他涉及不同主题的InterSystems IRIS 示例应用程序，例如NLP、ML、与AWS服务的集成、Twitter服务、性能基准测试等。以下是其中的部分内容： （1）HTAP Demo——混合事务分析处理（HTAP）基准。可以测试InterSystems IRIS同时插入和查询数据的速度。你会发现它的速度比AWS Aurora快20倍！ （2）欺诈预防——InterSystems IRIS通过机器学习和制定业务规则，防止金融服务交易中出现欺诈行为。 （3）Twitter情绪分析——演示InterSystems IRIS如何实时使用Tweet，并通过其NLP（自然语言处理）和业务规则功能来评估Tweet的情绪和元数据，从而决定何时与某人联系以提供支持。 （4）HL7协议和SMS（文本消息）应用程序——演示InterSystems IRIS医疗版如何解析HL7协议消息，从而给患者发送SMS（文本消息）提醒。它还演示了基于存储在标准化数据湖中预约数据的实时仪表板。 （5）Readmission Demo——患者再入院在医疗保健领域被称为"机器学习的Hello World"。针对这个问题，我们在本示例中演示了如何使用InterSystems IRIS安全地构建并运行用于实时预测的ML模型，以及如何将其集成到应用程序中。本InterSystems IRIS医疗版示例旨在展示如何构建针对再入院问题的完整解决方案。 12-支持的数据库 这是目前为止支持的数据库列表： Runing on your PC with docker-compose (NO mirroring/replication) InterSystems IRIS 2020.2 MySQL 8.0 MariaDB 10.5.4-focal MS SQL Server 2019-GA-ubuntu-16.04 SAP HANA Express 2.0 (on Linux VM only) Postgres 12.3 Running on AWS: InterSystems IRIS (with or without mirroring) AWS RDS Aurora (MySql) 5.6.10a (parallel query) with replication AWS RDS SQL Server 2017 Enterprise Edition (production deployment) with replication AWS RDS Postgres (production deployment) with replication AWS RDS MariaDB (production deployment) with replication SAP HANA Express Edition 2.0 without replication SAP Sybase ASE 16.0 SP03 PL08, public cloud edition, premium version, without replication AWS RDS Oracle (production deployment) with replication 注：本文为节选，欢迎点击原文链接，了解更多详情。

简介 最近完成了针对IRIS医疗版2020.1版本的性能及可扩展性基准测试，重点关注HL7v2的互操作性。本文介绍了在各种工作负载下观察到的吞吐量，并提供了IRIS医疗版用作HL7v2消息传输互操作性引擎时的系统常规配置和调整准则。 基准测试模拟了与实际环境接近的工作负载（详细信息请参见“工作负载说明和方法”部分）。本次测试的工作负载包括HL7v2患者管理（ADT）和生命体征结果（ORU）数据，并包含数据内容转换和路由。 IRIS医疗版2020.1版本可以表明，采用第二代Intel®Xeon®可扩展处理器和Intel®Optane™SSD DC P4800X系列SSD存储的商用服务器，每天的持续消息吞吐量超过23亿条（入站和出站总量），与此前的Ensemble 2017.1 HL7v2吞吐量基准测试相比，扩展性提高了一倍多。 在这些测试过程中，将IRIS医疗版配置为先进/先出（FIFO）顺序，并且在磁盘中完整保存每个入站和出站消息以及消息队列信息。通过持久化消息队列和消息内容，IRIS 医疗版能够在系统崩溃时提供数据保护，并提供完整的历史消息搜索和重新发送功能。 下面将继续介绍配置准则，帮助您选择适当的配置和部署，以充分满足工作负载性能和可扩展性需求。 通过实验结果可以证实，IRIS 医疗版能够满足商用硬件上的极端消息吞吐量需求，并且在大多数情况下支持仅用单个小型服务器可为整个组织提供HL7互操作性服务。 结果概述 以下三种工作负载代表了HL7互操作性活动的不同方面： ·T1工作负载：使用HL7消息的简单传递，每条入站消息对应一个出站消息。不需要路由引擎就可以直接将消息从Ensemble业务服务传递到Ensemble业务操作。不使用任何路由规则，也不执行任何消息内容转换。每条入站消息都在数据库中创建了一个HL7消息对象。 ·T2工作负载：通过路由引擎将入站消息平均分成4个分段，并将其路由到单个出站接口（1对1转换）。对每条入站消息执行一次数据转换，并在数据库中创建两个HL7消息对象。 ·T4工作负载：使用路由引擎将单独修改的消息路由到四个出站接口中的每一个接口。平均而言，每次转换都会修改入站消息的4个分段（1条入站消息对应4条出站消息，进行4次转换）。对于每条入站消息，将执行4次数据转换，向外发送4条消息，并在数据库中创建5个HL7消息对象。 这三个工作负载是在一个物理48核系统上运行的，该系统有两个Intel®可扩展Gold 6252处理器和两个运行Red Hat Enterprise Linux 8的750GB Intel®Optane™SSD DC P4800X SSD驱动器。测试记录每秒（和每小时）入站的消息数、每秒（和每小时）出站的消息数，以及一天10小时内的总消息数（入站与出站）。此外，CPU利用率是用于衡量既定吞吐量水平下可用系统资源的指标。 可扩展性结果 表1：该测试硬件配置的四个工作负载吞吐量汇总 * 包含25%的T1，25%的T2和50%T4的“混合工作负载” 工作负载描述及方法论 测试的工作负载包括HL7v2患者管理（ADT）和生命体征结果（ORU）消息，平均大小为1.2KB，平均14个片段。通过转换大约修改了4个片段（针对T2和T4工作负载）。测试包括48至128个入站接口和48至128个出站接口，通过TCP/IP接收和发送消息。 在T1工作负载中，使用了四个单独的命名空间，每个命名空间有16个接口；T2工作负载使用了三个命名空间，每个命名空间有16个接口；T4工作负载使用了四个命名空间，每个命名空间有32个接口；最后的“混合工作负载”使用了三个命名空间，在所有的接口中：T1工作负载为16个，T2工作负载为16个，T4工作负载为32个。 逐渐增加每个接口上的通信量来衡量可扩展性，以寻找可接受性能标准范围内的最高吞吐量。为了获得可接受的性能标准，必须以持续不变的速率处理消息，无需排队，消息传递没有可测量的延迟，且平均CPU使用率必须保持在80%以下。 之前的测试表明，HL7消息类型对集成的性能或可扩展性没有显著影响；重要的影响因素包括入站消息的数量、入站和出站消息的大小、在路由引擎中创建的新消息的数量，以及修改的消息段的数量。 之前的测试还表明，在数据转换中处理HL7消息的各个字段通常对性能影响不大。这些测试中的转换通过相当简单的赋值来创建新消息。请注意，复杂的处理（例如在数据转换中使用大量的SQL查询）可能会导致结果发生变化。 之前的测试还验证了规则处理的影响通常不大。这些测试中使用的路由规则集平均为32条规则，所有规则都很简单。请注意，非常大或非常复杂的规则集可能会导致结果发生变化。 硬件 服务器配置 测试中使用的服务器采用了第二代Intel®可扩展Gold 6252“Cascade Lake”处理器，带有48核@ 2.1GHz的2插槽系统，每个插槽提供24个核心，并具有192GB DDR4-2933 DRAM和10Gb以太网网络接口。本测试使用的是Red Hat Enterprise Linux Server 8操作系统和InterSystems IRIS医疗版 2020.1。 磁盘配置 通过IRIS 医疗版传递的消息将完全持久化保存到磁盘上。本次测试中系统内部的两个Intel 750GBIntel®Optane™SSD DC P4800X SSD驱动器分开使用，一个用于数据库，一个用于日志。此外，除了确保与真实环境进行比较之外，还对日志启用了同步提交以确保数据持久化。对于本文前面提到的T4工作负载，每条入站HL7消息都会生成大约50KB的数据，这些数据可以进行细分（如表2所述）。事务日志的在线时间通常比消息数据或日志的时间短，在计算总磁盘空间时应该考虑到这一点。 表2：每条入站HL7 T4消息所需的磁盘空间 组成部分 数据要求 分段数据 4.5 KB HL7消息对象 2 KB 消息头 1.0 KB 路由规则日志 0.5 KB 事务日志 42 KB 总计 50 KB 回顾上文，T4工作负载使用路由引擎将每个修改后的消息路由到四个出站接口中的每一个接口。平均而言，每次转换都会修改入站消息的4个分段（1条入站消息对应4条出站消息，进行4次转换）。每条入站消息将进行4次数据转换，将4条消息发送到出站，并在数据库中创建5个HL7消息对象。 在配置生产系统时，计算净需求时应考虑到每日入站量、HL7消息的删除计划以及日志文件的保留策略。此外，应该在系统上配置适当的日志文件空间，以防止保存日志的磁盘卷被占满。出于性能和可靠性方面的考虑，日志文件和数据库文件应分别保存至两个物理磁盘。 结论 InterSystems IRIS医疗版HL7v2消息吞吐量测试结果表明，简单的2插槽商用服务器配置即具有巨大的吞吐量能力，可满足任何组织中的极限消息工作负载的需求。此外，InterSystems致力于通过不断的版本迭代和升级，利用最新的服务器特性或者云技术，达到更高的性能和扩展性。 下图概述并比较了Ensemble 2015.1和Ensemble 2017.1基于英特尔®E5-2600 v3（Haswell）处理器的基准测试，以及Ensemble 2017.1基于第一代Intel®可扩展白金系列（Skylake）处理器的基准测试，和IRIS医疗版2020.1版本基于第二代Intel®可扩展黄金系列（Cascade Lake）处理器的基准测试最新结果。 图1：单个服务器上每天10小时的消息吞吐量（百万） InterSystems IRIS 医疗版不断提高版本之间互操作性吞吐量的标准，并提供灵活的连接功能。如上图所示，IRIS 医疗版消息吞吐量已有显著增加，在T2工作负载情况下比2017版翻了一番，与2015版测试相比，在相同的10小时窗口内吞吐量增加了两倍多，24小时总消息速率保持在23亿以上。 证明IRIS 医疗版性能提升的另一个关键指标是更复杂的T2和T4工作负载（包含转换和路由规则，而不是T1工作负载的纯直通操作）中的吞吐量的提高。 InterSystems可随时与您探讨组织中遇到的与互操作性需求相关的解决方案。 注：本文为译文，欢迎点击查看原文，原文由Mark Bolinsky撰写 这篇能不能发个微信公众号？：） 欢迎查看：https://mp.weixin.qq.com/s?__biz=MzA4MTg3OTU4Mg==&mid=2656760711&idx=1&sn=b098179e1947105917517a7ceeede3f4&chksm=842064f6b357ede044475009db72bf3777a5e18427904f893390e466e16703c289830d0beda6&token=2031523301&lang=zh_CN#rd

亲爱的社区开发者们！ 本周进入 InterSystems多模型数据库竞赛的投票环节！是时候为你所认可的最佳方案投票了！ 🔥 投票通道: 点击投票 🔥 如何投票？ 使用我们全新的投票引擎和算法提名专家（Experts)和社区提名，您可以选择3个项目，分别投出心目中的第一、第二和第三位。 以下是社区排行榜说明: 社区排行榜: 名次 得分 1st 3 2nd 2 3rd 1 专家（Experts）排行榜会有更复杂的数学计算，不同级别的专家有更多的“点数”权力: 专家（Experts）排行榜: 级别 名次 1st 2nd 3rd VIP级：总经理，版主，产品经理 9 6 3 Global Masters中的专家（Expert）级 6 4 2 Global Masters中的专业（Specialist）级 3 2 1 专家投票也将为按“3-2-1”为社区排行榜贡献出分数。 投票说明 投票在 Open Exchange 竞赛页面 ，用户需要登录 Open Exchange 进行投票（使用开发者社区的账号即可登录）。 投票后您可以取消投票，将宝贵的票票投给其他更心仪的项目， 参赛者可以在投票周修复bug并进一步改进程序，欢迎订阅程序发布，不要错过 ！ ➡️ 请查收最新的 InterSystems在线竞赛投票规则. 注：本文为译文，欢迎点击阅读原文，原文由Anastasia Dyubaylo撰写。

部分 在上个帖子中，我们安排了使用 pButtons 进行 24 小时的性能指标收集。 在本帖中，我们将研究几个收集到的关键指标，以及它们与底层系统硬件的关系。 我们还将开始探索 Caché（或任一 InterSystems 数据平台）指标与系统指标之间的关系。 以及如何使用这些指标来了解系统的每日节拍率并诊断性能问题。 [本系列其他帖子的列表](https://cn.community.intersystems.com/post/intersystems-数据平台的容量规划和性能系列文章) ***2016 年 10 月编辑...*** *[用于将 pButtons 数据提取到 .csv 文件的脚本示例。](https://cn.community.intersystems.com/post/将-pbuttons-数据提取到-csv-文件以便绘制图表)* ***2018 年 3 月编辑...*** 图片消失，重新添加它们。 # 硬件食物群  您将会看到，随着本系列帖子的不断深入，影响性能的服务器组件可以逐项列出： - CPU - 内存 - 存储 IO - 网络 IO 如果这些组件中的任何一个承受压力，那么系统性能和用户体验很可能会受到影响。 这些组件也都相互关联，对一个组件进行更改可能会影响另一个组件，有时会产生意外的后果。 我见过这样一个例子：修复某个存储阵列中的 IO 瓶颈使 CPU 的使用率跳增至 100%，导致用户体验更差，原因是系统突然可以做更多工作，但没有 CPU 资源来为增加的用户活动和吞吐量提供服务。 我们还将了解 Caché 系统活动如何直接影响服务器组件。 如果存储 IO 资源有限，那么可以做出的积极改变是增加系统内存，并增加 __Caché global 缓冲区__的内存，从而降低__系统存储读取 IO__（但可能会增加 CPU 使用率！）。 要定期监视或在用户报告问题时要检查的一个最明显的系统指标是 CPU 使用率。 在 Linux 或 AIX 中查看 _top_ 或 _nmon_，或在 Windows 中查看_性能监视器_。 由于大多数系统管理员会定期查看 CPU 数据，特别是当数据以图形方式呈现时，快速浏览一下就可以很好地了解系统当前的运行状况 - 正常情况或出现活动激增，后者可能是异常情况或表示出现问题。 在本帖中，我们将快速查看 CPU 指标，但会重点关注 Caché 指标，我们首先将查看 _mgstat_ 数据，了解以图形方式表示的数据如何让系统运行状况一目了然。 # mgstat 简介 mgstat 是 pButtons 中包含并在其中运行的一个 Caché 命令。 mgstat 是一个非常好的工具，可收集基本性能指标，帮助您了解系统运行状况。 我们将查看从 24 小时 pButtons 收集的 mgstat 数据，但是，如果您希望捕获 pButtons 之外的数据，也可以根据需要以交互方式运行 mgstat，或者从 Caché 终端将其作为后台作业运行。 要从 %SYS 命名空间按需运行 mgstat，一般格式是： do mgstat(sample_time,number_of_samples,"/file_path/file.csv",page_length) 例如，运行一小时后台作业，采样周期为 5 秒，然后输出为 csv 文件： job ^mgstat(5,720,"/data/mgstat_todays_date_and_time.csv") 要显示到屏幕，但丢弃几个列，则输入 dsp132。 给您留个作业，去查看一下输出以了解差异。 do dsp132^mgstat(5,720,"",60) > mgstat 中的列的详细信息可以在最新的 Caché 文档（[InterSystems 在线文档](https://docs.intersystems.com)）中的 _Caché 监视指南_中找到 # 查看 mgstat 数据 pButtons 已设计为整理成一个 HTML 文件，以便导航和打包发送给 WRC 支持专家来诊断性能问题。 不过，当您自己运行 pButtons 并想以图形方式显示数据时，可以再次将其拆分为 csv 文件以处理成图形，例如可以使用 Excel、通过命令行脚本或简单的剪切和粘贴来完成。 在本帖中，我们将深入研究几个 mgstat 指标，来说明即使是快速浏览数据，也能让您感觉到系统是否运行良好，或者是否存在会影响用户体验的现有或潜在问题。 ## Gloref 和 CPU 下图显示了一个以高事务处理速率运行医院应用程序的站点的数据库服务器 CPU 使用率。 注意活动的高峰期在上午，此时有许多门诊病人，而在午餐时间，活动大幅下降，在下午和晚上则逐渐消失。 此例中的数据来自于 Windows 性能监视器 _(_Total)\% Processor Time_ - 图形的形状符合工作日的情况 - 没有异常的峰值或低谷，所以对这个站点来说是正常的。 通过对您的站点执行相同分析，您可以开始获取“正常”情况的基准。 如果出现大的尖峰，尤其是延长的尖峰，可能说明出现了问题。将来会有一个帖子以 CPU 为重点。  作为参考，该数据库服务器是具有两个 E5-2670 8 核处理器的戴尔 R720，服务器的内存为 128 GB，global 缓冲区为 48 GB。 下图显示了来自 mgstat 的更多数据 — 与 CPU 图形同一天的 Gloref（Global 引用数）或数据库访问量。 Gloref 指示正在发生的工作量，代表当前工作负载；虽然 global 引用会消耗 CPU 时间，但由于 Caché 使用 global 内存缓冲池的方式，这些引用并不始终消耗物理读取等其他系统资源。  在典型的 Caché 应用程序中，Gloref 与 CPU 使用率之间有非常强的相关性。 > 这些 CPU 数据和 gloref 数据所展示出的另一方面是_减少 gloref 将降低 CPU 使用率_，从而可以在核心数较少的服务器上部署或在现有系统上进一步扩展。 还可以通过提高应用程序效率来减少 global 引用，我们将在以后的帖子中重新讨论这个概念。 ## PhyRds 和 Rdratio 根据 mgstat 数据 _PhyRds_（物理读取数）和 _Rdratio_（读取比）绘制的图形的形状也可以深入了解系统性能的预期水平，帮助您制定容量计划。 我们将在以后的帖子中深入探讨 Caché 的存储 IO。 _PhyRds_ 只是从磁盘到 Caché 数据库的物理读取 IOPS，您应该看到逻辑磁盘和物理磁盘的操作系统指标中反映了相同的值。 注意，查看操作系统 IOPS 可能还会显示来自非 Caché 应用程序的 IOPS。 不考虑预期的 IOPS 就调整存储大小会导致灾难，您需要了解系统在高峰时段的 IOPS 是多少，才能制定适当的容量计划。 下图显示了午夜零点到 15:30 之间的 _PhyRds_。  注意 05:30 到 10:00 之间的读取数激增。 其他较短的峰值在 11:00 以及 14:00 之前。 您认为这些峰值是由什么引起的？ 您的服务器有这些类型的峰值吗？ _Rdratio_ 更有趣一点，它是逻辑块读取数与物理块读取数的比值。 也就是内存中的 global 缓冲区（逻辑）的读取次数与磁盘的读取次数之比，后者的读取速度要慢几个数量级。 _Rdratio_ 高是好事情，但长时间降至接近于零就不好了。  注意读取数高的同时，_Rdratio_ 降至接近于零。 我曾被要求调查过这个站点，当时 IT 部门接到用户电话，报告系统长时间运行缓慢。 当我被要求查看系统时，这种情况已在几个星期内看似随机地出现。 > _**由于 pButtons 已设定为每天 24 小时运行，因此可以相对简单地回溯几周的数据，以查看与支持电话相关的高 _PhyRds_ 和低 _Rdratio_ 的模式。*** 经过进一步分析后，原因追溯到一名新的轮班员工身上，他当时运行了多个报告，输入了“错误”参数，加上写得不好的查询，并且没有适当的索引，导致数据库读取数很高。 这就解释了看似随机的缓慢。 由于这些长时间运行的报告将数据读取到 global 缓冲区中，结果是交互用户的数据从物理存储中获取，而不是从内存以及用于为读取提供服务的存储中获取。 监视 _PhyRds_ 和 _Rdratio_ 将让您了解系统的节拍率，也许还可以追踪不良报告或查询。 高 _PhyRds_ 可能有合理的原因 - 也许必须在某个时间运行报告。 使用现代 64 位操作系统和具有大容量物理内存的服务器，您应该能够将生产系统上的 _PhyRds_ 降到最低。 > 如果您在系统上看到高 _PhyRds_，可以考虑以下几种策略： - 通过增加数据库 (global) 缓冲区（和系统内存）的数量来提高性能。 - 可以将长时间运行的报告或提取移出办公时间。 - 可以在单独的影子服务器或异步镜像上运行长时间运行的只读报告、批处理作业或数据提取，以最大限度地降低对交互用户的影响，并减少对 CPU 和 IOPS 等系统资源的使用。 通常，低 _PhyRds_ 是好事情，这也是我们在确定系统规模时的目标。 然而，如果您的 _PhyRds_ 较低，而用户正在抱怨性能，仍然可以进行一些检查以确保存储不是瓶颈 - 读数低的原因可能是系统无法再提供服务。 我们将在以后的帖子中进一步探讨存储。 # 总结 在本帖中，我们研究了将 pButtons 中收集的指标图形化如何让运行状况检查可以一目了然地进行。 在接下来的帖子中，我将深入探讨系统和 Caché 指标之间的关系，以及如何利用这些指标来规划未来。

假设您想编写一些真正的web应用程序，例如medium.com网站的简单克隆。这类应用程序可以在后端使用任何不同的语言编写，也可以使用前端的任何框架编写。编写这样一个应用程序有很多方法，你也可以看看这个项目。它为完全相同的应用程序提供了一堆前端和后端实现。您可以轻松组合它们，任何所选前端应该与任何后端搭配。 我来介绍一下这个使用后端InterSystems IRIS来实现后端的相同的应用程序。 RealWorld项目使用REST并提供预设swagger规范，以及Postman/Newman集合自动化测试。因此，它有助于实现完全相同的REST API。幸运的是，InterSystems已经实现了通过swagger规范生成REST API实现的方法。最佳实践在这里。 我实现这个应用程序的步骤是： 从swagger规范生成API 为应用程序中使用的每个对象类型添加一些持久类，包括 Users Articles Comments 实现API并用Postman测试 最后，用任何前端查看实际效果。 用 docker 启动 你可以自己使用docker 来实验一下。 // clone github repository git clone https://github.com/daimor/realworld-intersystems-iris.git cd realworld-intersystems-iris // build and run it with docker-compose docker-compose up -d --build 启动后可以通过URL http://localhost:12000/conduit获取IRIS中的REST API，可以用newman测试，需要已安装npm和npx包。 APIURL=http://localhost:12000/conduit ./run-api-tests.sh 运行Postman的相同测试 可以通过URL http://localhost/访问前端 可以通过zpm运行UnitTest，只需要进入iris会话 $ docker-compose exec server iris session iris Node: 0790684cf488, Instance: IRIS CONDUIT>zpm zpm: CONDUIT>test realworld [realworld] Reload START [realworld] Reload SUCCESS [realworld] Module object refreshed. [realworld] Validate START [realworld] Validate SUCCESS [realworld] Compile START [realworld] Compile SUCCESS [realworld] Activate START [realworld] Configure START [realworld] Configure SUCCESS [realworld] Activate SUCCESS [realworld] Test START Use the following URL to view the result: http://172.22.0.3:52773/csp/sys/%25UnitTest.Portal.Indices.cls?Index=48&$NAMESPACE=CONDUIT All PASSED [realworld] Test SUCCESS zpm: CONDUIT> 默认使用Vue前端，但也能运行Angular和React web=angular docker-compose up -d --build web web=react docker-compose up -d --build web web=vue docker-compose up -d --build web 通过ZPM安装 InterSystems IRIS部分（后端）可以通过ZPM安装 USER>zpm zpm: USER>install realworld [realworld] Reload START [realworld] Reload SUCCESS [realworld] Module object refreshed. [realworld] Validate START [realworld] Validate SUCCESS [realworld] Compile START [realworld] Compile SUCCESS [realworld] Activate START [realworld] Configure START [realworld] Configure SUCCESS [realworld] Activate SUCCESS zpm: USER> 它将创建`/conduit` Web应用程序，只要设置正确的端口，也能用newman进行测试。 APIURL=http://localhost:52773/conduit ./run-api-tests.sh 可以用ZPM进行UnitTest zpm: USER>test realworld [realworld] Reload START [realworld] Reload SUCCESS [realworld] Module object refreshed. [realworld] Validate START [realworld] Validate SUCCESS [realworld] Compile START [realworld] Compile SUCCESS [realworld] Activate START [realworld] Configure START [realworld] Configure SUCCESS [realworld] Activate SUCCESS [realworld] Test START Use the following URL to view the result: http://172.17.0.2:52773/csp/sys/%25UnitTest.Portal.Indices.cls?Index=4&$NAMESPACE=USER All PASSED [realworld] Test SUCCESS 备注 在开发这个项目的过程中，我遇到了一些问题。 %JSON.Adaptor 它在导入全新对象时效果非常好。但如果需要部分更新现有对象，则%JSONImport对于来源JSON中应该有的必需字段无效。 所以我没用%JSONImport更新对象，而是用了一个从传入的JSON到对象的简单集（如果定义了值）。 只能导出到字符串、流和输出设备。无法导出到原生JSON API需要返回被另一个对象（属性被命名为返回对象的类型）包装的任何对象。并用%JSONExportToString解决了这个问题，对于数组，将其转换为原生JSON 忽略空集合属性（如：数组和列表）的导出。虽然应用程序可能期望得到字段的空数组，但它根本没有得到任何字段 这个问题没解决。太棘手，只能在%JSON.Adapter端解决。 %REST - REST实现的生成器及REST实现本身 即使没有任何更改，`spec`类的任何编译都会更新`impl`类。因此，切记保持生成的部分（如：方法名、参数列表和变量名）不变，否则将会被下一次`spec`编译重写，这可能会在构建用于生产的应用程序时发生。 REST可以有`/users/` 端点，也能获取`/users/`请求，在这种情况下，两者效果相同。但如果只定义了第一种方式，REST就不能识别第二种方式。 要解决这个问题，必须修改swagger规范，只复制带新端点`/users/`的`/users/` Swagger规范定义了参数化请求的默认值，而生成器忽略了 在方法/生成器的代码中手动设置默认值可能会重写方法定义，而参数的设置默认值将被删除。所以可能在部署后破坏实现。 %REST.REST中的方法不可用于覆盖，仅由`disp`类使用，且将被`spec`类的编译完全重写。 无法访问实例的OnPreDispatch方法，也就无法进行更多控制，如：检查访问 Swagger规范定义了哪些端点是公共的，哪些需要授权。%REST生成器无法使用。 API必须用JWT来授权请求，且必须手动检查哪个端点需要检查访问。超出了%OAuth2实现的范围，在IRIS中使用JWT也很麻烦。 在`impl`类中生成的方法应该返回原生JSON对象、流或字符串。但我认为如果它也能接受%JSON.Adaptor对象就很好。 无论如何，实现这样的应用程序是非常有趣的。至少知道了可以用IRIS来实现。 这个应用程序使用了IRIS的这些特性 原生JSON + %JSON.Adaptor REST，及其遵守swagger规范的实现生成器 OAuth2的JWT 容器化 竞赛 这个项目正在参加InterSystems全栈竞赛，如果您喜欢请投票。

**什么是分布式人工智能 (DAI)？** 试图找到一个“无懈可击”的定义是徒劳的：这个术语似乎有些“超前”。 但是，我们仍然可以从语义上分析该术语本身，推导出分布式人工智能也是人工智能（请参见我们为提出一个“实用”定义所做的[努力](https://www.linkedin.com/pulse/ai-robotization-intersystems-iris-data-platform-sergey-lukyanchikov/)），只是它分布在多台没有聚合在一起（既不在数据方面，也不通过应用程序聚合，原则上不提供对特定计算机的访问）的计算机上。 即，在理想情况下，分布式人工智能的安排方式是：参与该“分布”的任何计算机都不能直接访问其他计算机的数据和应用程序，唯一的替代方案是通过“透明的”消息传递来传输数据样本和可执行脚本。 与该理想情况的任何偏差都会导致出现“部分分布式人工智能”- 一个示例是通过中央应用程序服务器分发数据， 或者其反向操作。 不管怎样，我们都会得到一组“联合”模型（即，在各自数据源上训练的模型，或者按自己的算法训练的模型，或者同时以这两种方式训练的模型）。 **“面向大众”的分布式人工智能方案** 我们不会讨论边缘计算、机密数据操作员、分散的移动搜索，或者类似的引人入胜但又不是最有意识和最广泛应用（目前不是）的方案。 我们将更“贴近于生活”，例如，如果考虑以下方案（其详细演示应该可以在此处观看）：一家公司运行一个生产级 AI/ML 解决方案，其运行质量正在由一名外部数据科学家（即，不是该公司员工的专家）系统地进行检查。 由于种种原因，该公司无法授予数据科学家访问该解决方案的权限，但可以按照时间表或在特定事件（例如，解决方案终止一个或多个模型的训练会话）后向其发送所需表中的记录样本。 我们据此假定，该数据科学家拥有某个版本的 AI/ML 机制，且这些机制已经集成在公司正在运行的生产级解决方案中，而且数据科学家本人很可能正在开发、改进和调整这些机制，以适应该具体公司的具体用例。 将这些机制部署到正在运行的解决方案中、监控机制的运行以及其他生命周期方面的工作由一名数据工程师（公司员工）负责。 我们在[这篇文章](https://www.linkedin.com/pulse/intersystems-iris-all-purpose-universal-platform-aiml-lukyanchikov/)中提供了一个在 InterSystems IRIS 平台上部署生产级 AI/ML 解决方案的示例，该解决方案可自主处理来自设备的数据流。 上一段提供的链接下的演示中也运行了相同的解决方案。 您可以使用我们的仓库 Convergent Analytics 中的内容（免费且无时间限制，请访问 Links to Required Downloads 和 Root Resources 部分）在 InterSystems IRIS 上构建您自己的解决方案原型。 通过这样的方案，我们可获得“分布程度”如何的人工智能？ 在我们看来，此方案相当接近理想情况，因为数据科学家与公司的数据和算法均保持“切割”（只是传输了有限的样本，但在某个时间点前很重要；而且数据科学家自己的“样本”永远不会与作为实时生产级解决方案的一部分部署和运行的“活跃”机制 100% 同步），他完全不能访问公司的 IT 基础架构。 因此，数据科学家的作用变为在他的本地计算资源上部分重放该公司生产级 AI/ML 解决方案的运行片段，获得可接受置信级别的运行质量评估，并向公司返回反馈（在我们的具体方案中，以“审核”结果表示，可能还加上该公司解决方案涉及的 AI/ML 机制的改进版本）。 _图 1 分布式人工智能方案表示_ 我们知道，在人类执行人工智能项目交换的过程中，不一定需要表示和传输反馈，这源于有关现代方法的出版物以及已有的分布式人工智能实现经验。 但是，InterSystems IRIS 平台的优势在于，它允许同样高效地开发和启动“混合”（人类和机器串联）且完全自动化的人工智能用例，因此，我们将继续根据上述“混合”示例进行分析，同时为读者留下自行阐述其完全自动化的可能性。 **如何在 InterSystems IRIS 平台上运行具体的分布式人工智能方案** 本文上一节提到的带有方案演示的视频介绍对作为实时 AI/ML 平台的 InterSystems IRIS 进行了总体概述，并解释了其对 DevOps 宏机制的支持。 在演示中，没有明确覆盖负责定期将训练数据集传输给外部数据科学家的“公司侧”业务流程，因此，我们将从该业务流程及其步骤的简介开始。 发送方业务流程的一个主要“引擎”是 while 循环（使用 InterSystems IRIS 可视业务流程编辑器实现，该编辑器基于平台解释的 BPL 表示法），负责将训练数据集系统地发送给外部数据科学家。 该“引擎”内部执行以下操作（参见下图，跳过数据一致性操作）： _图 2“发送方”业务流程的主要部分_ (a) 负载分析器 – 将训练数据集表中的当前记录集加载到业务流程中，并基于它在 Python 会话中形成一个数据框架。 调用操作会触发对 InterSystems IRIS DBMS 的 SQL 查询，并触发对 Python 接口的调用以将 SQL 结果传输给它，以便形成数据框架； (b) Azure 分析器 – 另一个调用操作，触发对 Python 接口的调用，以向其传输一组 Azure ML SDK for Python 指令，从而在 Azure 中构建所需的基础架构，并在该基础架构上部署前一个操作中形成的数据框架数据； 作为执行上述业务流程操作的结果，我们在 Azure 中获得一个存储对象（一个 .csv 文件），其中包含公司的生产级解决方案用于模型训练的最近数据集的导出： _图 3 训练数据集“到达”Azure ML_ 这样，发送方业务流程的主要部分已经结束，但是我们还需要再执行一个操作，同时请记住，我们在 Azure ML 中创建的任何计算资源都是可计费的（参见下图，跳过数据一致性操作）： _图 4“发送方”业务流程的最后部分_ (c) 资源清理 – 触发对 Python 接口的调用，以向其传输一组 Azure ML SDK for Python 指令，从 Azure 中删除上一个操作中构建的计算基础架构。 数据科学家所需的数据已经传输完毕（数据集现在在 Azure 中），因此我们可以继续启动将访问数据集的“外部”业务流程，运行至少一次替代模型训练（从算法上讲，替代模型不同于作为生产级解决方案一部分运行的模型），并向数据科学家返回得到的模型质量指标及可视化，从而表示有关公司生产级解决方案运行效率的“审核结果”。 我们现在看一下接收方业务流程：与发送方业务流程（在包含公司自主 AI/ML 解决方案的其他业务流程中运行）不同，它不需要 while 循环，而是包含与在 Azure ML 和 IntegratedML（InterSystems IRIS 中用于自动 ML 框架的加速器）中训练替代模型有关的一系列操作，并将训练结果提取到 InterSystems IRIS 中（该平台也被认为在数据科学家处本地安装）： _图 5“接收方”业务流程_ (a) 导入 Python 模块 – 触发对 Python 接口的调用，以向其传输一组指令，导入进一步操作所需的 Python 模块； (b) 设置 AUDITOR 参数 – 触发对 Python 接口的调用，以向其传输一组指令，为进一步操作所需的变量指定默认值； (c) Azure ML 审核 –（我们将跳过任何对 Python 接口触发的进一步引用）将“审核任务”提交到 Azure ML； (d) 解释 Azure ML – 将发送方业务流程传输到 Azure ML 的数据与 Azure ML 的“审核”结果一起获取到本地 Python 会话中（此外，在 Python 会话中创建“审核”结果的可视化）； (e) 流式传输到 IRIS – 将发送方业务流程传输到 Azure ML 的数据与 Azure ML 的“审核”结果一起从本地 Python 会话中提取到 IRIS 中的业务流程变量； (f) 填充 IRIS – 将发送方业务流程传输到 Azure ML 的数据与 Azure ML 的“审核”结果一起从 IRIS 中的业务流程变量写入 IRIS 中的表； (g) IntegratedML 审核 – 使用 IntegratedML 加速器“审核”从 Azure ML 接收的数据以及上一个操作中写入 IRIS 的 Azure ML“审核”结果（在此特定情况下，该加速器处理 H2O auto-ML 框架）； (h) 对 Python 进行查询 – 将数据和 IntegratedML“审核”结果传输到 Python 会话中； (i) 解释 IntegratedML – 在 Python 会话中，创建 IntegratedML“审核”结果的可视化； (j) 资源清理 – 从 Azure 中删除先前的操作中创建的计算基础架构。 _图 6 Azure ML“审核”结果的可视化_ _图 7 IntegratedML“审核”结果的可视化_ **分布式人工智能一般如何在 InterSystems IRIS 平台上实现** InterSystems IRIS 平台实现分布式人工智能有三种基本方法： ·       根据用户定义的规则和算法，直接交换人工智能项目，并对其进行本地和中央处理 ·       人工智能项目处理委托给专门的框架（例如：TensorFlow、PyTorch），交换的编排和各个准备步骤由用户在 InterSystems IRIS 的本地和中央实例上配置 ·       人工智能项目的交换和处理都通过云提供商（Azure、AWS、GCP）来完成，本地和中央实例只向云提供商发送输入数据并接收最终结果 _图 8 在 InterSystems IRIS 平台上实现分布式人工智能的基本方法_ 这些基本方法可以修改/组合使用：尤其是，在本文的上一节（“审核”）所描述的具体方案中，使用了第三种方法“以云为中心”，将“审核员”部分划分到云端，而在数据科学家一侧执行本地部分（作为“中央实例”）。 目前，在我们生活的现实中，“分布式人工智能”学科的理论和应用要素正在不断积累，但还没有形成“规范形式”，这使得创新实现具有巨大潜力。 我们的专家团队密切关注分布式人工智能作为一门学科的发展，并为其在 InterSystems IRIS 平台上的实现设计加速器。 我们乐于分享我们的内容，并帮助每一个认为这里讨论的领域有用的人开始分布式人工智能机制的原型设计。 您可以使用以下电子邮件地址联系我们的 AI/ML 专家团队 – MLToolkit@intersystems.com。

InterSystems IRIS 下使用 DataOps .png) Gartner 对 DataOps 的定义是：“DataOps 是一种协作式的数据管理方法，侧重于改善整个组织中数据管理者和数据消费者之间数据流的沟通、整合与自动化。 DataOps 的目标是创建可预测的数据、数据模型和相关项目的交付和变更管理，从而更快地交付价值。 DataOps 采取特殊技术手段和相应治理水平自动化数据交付的设计、部署和管理，以元数据提高动态环境中数据的易用性和价值。” 2014 年 6 月 19 日，InformationWeek 特约编辑 Lenny Liebmann 发表于 IBM Big Data & Analytics Hub 的题为“3 reasons why DataOps is essential for big data success”的文章中首次提出 DataOps 这一概念。 DataOps 一词后被 Andy Palmer 推广到 Tamr。 DataOps 是“数据运营”的专属名称。 2017 年对 DataOps 来说是意义重大的一年，生态系统取得巨大发展，分析师覆盖范围进一步扩张，关键字搜索量以及调查、出版物和开源项目数均有所提升。 Gartner 在 2018 年的 Hype Cycle for Data Management 中添加了 DataOps 。 （资料来源：） DataOps 宣言确立了以下 DataOps 原则：()   1. **持续满足客户需求**：我们的首要任务是在几分钟到几周内及尽早并持续交付有价值的内容给客户，并以此满足客户的需求。 2. **有价值工作的分析**：我们认为评价工作效率的主要度量指标是，提交了多少深度分析的内容、产出多少高准确度的数据以及在顶层框架和系统中贡献了多少。 3. **拥抱变化**：我们并不抗拒客户需求的变化，事实上，我们欣然接受这些变化，并以此产生竞争优势。 我们相信，与客户直接交谈是最高效、最实用、最敏捷的沟通方式。 4. 这是一项团队运动：分析团队将始终具有各种角色、技能、偏好工具和头衔。 多元化的背景和意见可以提高创新力和生产力。 5. **日常互动**：客户、分析团队和运营必须每天都在整个项目中协同工作。 6. **自发组织**：我们相信，最好的分析见解、算法、架构、需求和设计都来自于自发组织的团队。 7. **减少英雄主义**：对于分析的深度和广度，需求正在加速扩大，我们认为分析团队应尽力减少英雄主义，创建可持续且可扩展的数据分析团队和流程。 8. **反思**：分析团队应定期根据客户、自身和运营统计提供的反馈意见开展自我反思，优化运营绩效。 9. **分析即代码**：分析团队使用各种工具对数据进行访问、集成、建模和可视化。 从根本上讲，每种工具都会生成代码和配置，这些都会对数据进行操作，从而为进一步理解数据提供帮助。 10. **编排**：从头到尾编排数据、工具、代码、环境以配合分析团队的工作，这是分析成功的关键因素。 11. 使其可复现：结果需要可复现，我们对所有内容进行版本控制：包括数据、底层硬件、软件配置以及特定于工具链中各工具的代码和配置。 12. **一次性的工作环境**：我们认为，必须为分析团队成员提供易于创建、隔离、安全并能反映其生产环境的一次性工作环境，从而最大程度地降低分析团队的实验成本。 13. **简洁性**：我们认为，持续关注卓越的技术和良好的设计不仅可以提高敏捷性，也可以提高简洁性，特别是突出显示未完成的工作量。 14. **分析即生产**：分析管道类似于精益生产线。 我们认为，DataOps 的一个基本概念是注重过程思维，提升分析及生产的效率。 15. **质量至上**：分析管道在基础上应该有能力自动检测代码、配置和数据中的异常 (jidoka) 与安全问题，并应向操作员提供持续反馈以避免错误 (poka yoke)。 16. **监视质量和性能**：我们的目标是对性能、安全和质量措施进行持续监视，及时发现意外变化并生成运营统计信息。 17. **重用**：我们认为，提升分析及生产效率的一个基本方面是避免个人或团队重复以前的工作。 18. **缩短周期时间**：从将客户需求转化为分析思路，到在开发中创建、并作为可重复生产的流程发布，再到最后的重构和重用产品，我们应尽全力将这一周期耗费的时间和精力降到最低。 当您分析这些原则时，也许会发现 InterSystems IRIS 能够在某些方面起到作用： * 持续满足客户需求：您可以通过冲刺或迭代创建新的短集成产品、编排、IRIS 多维数据集、报告、BI 可视化和 ML 模型。 * 有价值工作的分析：IRIS 帮助您提供高质量的数据（在持久化类中使用production、适配器和类方法），并使您能够在 IRIS BI 数据透视表（分析设计器）和 IRIS NLP（文本分析）中进行数据探索。 * 自组织：IRIS 简化了自组织，借助统一的数据平台，您只需一个工具即可收集、处理、分析和发布见解。 * 反思：您可以通过此用户门户与用户互动并收集反馈，以改进交付的产品。 * 分析即代码：在 IRIS 数据模型中，多维数据集、仪表板都是代码，具有版本控制和治理功能。 * 编排：IRIS 数据平台可在单个工具中编排数据的引入、扩充、分析工作、数据可视化和 ML。 * 使其可复现：IRIS 支持使用 Docker、Kubernetes (IKO) 和 DevOps 复现结果。 * 一次性环境：IRIS 支持为集成、数据模型、BI 多维数据集和可视化创建 Docker 一次性环境。 * 简洁性：IRIS 数据多维数据集的创建非常简单，无需创建 ETL 脚本，分析器、多维数据集、仪表板的创建均实现可视化和网络化，并且可由用户而不仅是开发者团队完成。 同时，IntegratedML 允许在没有源代码开发的情况下针对常见场景创建 ML。 * 监视质量和性能：IRIS 使用 SAM 监视性能并具有 Web 管理门户。 * 重用：在 IRIS 中，DataOps 项目是类，这些类默认可扩展、可重用。 * 缩短周期时间：用户可以通过自助服务创建仪表板、分析、报告，以及发布和共享工作。 ODSC () 指出以下 DataOps 策略： InterSystems IRIS 对以上几点均有所帮助： * 自助服务配置：用户可以创建和发布多维数据集与仪表板。 * 共享、标记、注解：用户门户可用于共享仪表板，IRIS Analytical Web Portal 允许用户创建、记录、整理到文件夹并标记您的工作。 * 扩充：BPL 可用于扩充数据。 * 准备：BPL、DTL、适配器和 ObjectScript 逻辑可以帮助准备数据。 * 数据市场：数据资产可以发布到 REST API 并通过 IRIS API Manager 获利。 * 数据目录：IRIS 中的数据被组织成类，这些类被存储在类目录系统 (%Dictonary) 中 * 配置文件与分类：可在用户门户和管理门户中为分析项目创建组、文件夹。 * 质量：IRIS 具有实用工具类，可生成示例数据和进行单元测试。 * 沿袭：在 IRIS 中，所有数据资产都相互连接，您可以从数据模型构建多维数据集，再从多维数据集构建仪表板，所有数据资产均可由数据管理者（IRIS 权限系统）控制。 * 掌控：通过管理门户，您可以掌控分析项目的各个方面。 * 数据库数据、文件数据、SaaS API、流：IRIS 为多模型，支持持久性以及数据和文本分析 (NLP)。 以 IRIS API Manager 支持 SaaS API，以 Integration Adapters 和 PEX（带有 Kafka）与 Streams 结合使用。 * 应用程序、BI 工具、分析沙盒：通过 IRIS，您可以使用您喜欢的语言（Java、Python、.NET、Node.js、ObjectScript）创建 DataOps 应用。 虽然 IRIS 是 BI 工具，但是在这个工具中，您可以将连接器与 Power BI 或 MDX 桥结合使用，将 IRIS 作为分析沙盒。 参见我反映 IRIS 和 DataOps 的汇总： .png)