搜索​​​​

本文是 SqlDatabaseChain 的简单快速入门（我所做的）。 希望大家会感兴趣。 非常感谢： sqlalchemy-iris 作者@Dmitry Maslennikov 您的项目使我的试验变得可能。 文章脚本使用 openai API，因此请注意不要在外部共享您不打算共享的表信息和记录。 如果需要，可以插入本地模型。 创建一个新的虚拟环境 mkdir chainsql cd chainsql python -m venv . scripts\activate pip install langchain pip install wget # Need to connect to IRIS so installing a fresh python driver python -c "import wget;url='https://raw.githubusercontent.com/intersystems-community/iris-driver-distribution/main/DB-API/intersystems_irispython-3.2.0-py3-none-any.whl';wget.download(url)" # And for more magic pip install sqlalchemy-iris pip install openai set OPENAI_API_KEY=[ Your OpenAI Key ] python 初始测试 from langchain import OpenAI, SQLDatabase, SQLDatabaseChain db = SQLDatabase.from_uri("iris://superuser:******@localhost:51775/USER") llm = OpenAI(temperature=0, verbose=True) db_chain = SQLDatabaseChain.from_llm(llm, db, verbose=True) db_chain.run("How many Tables are there") 错误结果 sqlalchemy.exc.DatabaseError: (intersystems_iris.dbapi._DBAPI.DatabaseError) [SQLCODE: <-25>:<Input encountered after end of query>] [Location: <Prepare>] [%msg: < Input (;) encountered after end of query^SELECT COUNT ( * ) FROM information_schema . tables WHERE table_schema = :%qpar(1) ;>] [SQL: SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'public';] (Background on this error at: https://sqlalche.me/e/20/4xp6) ←[32;1m←[1;3mSELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'public';←[0m>>> 开发者之间的对话 IRIS 不喜欢以分号结尾的 SQL 查询。 现在做什么？ ？ 想法：我告诉 LangChain 帮我修理SQL如何 太酷了，我们开工吧 ！！ 测试二 from langchain import OpenAI, SQLDatabase, SQLDatabaseChain from langchain.prompts.prompt import PromptTemplate _DEFAULT_TEMPLATE = """Given an input question, first create a syntactically correct {dialect} query to run, then look at the results of the query and return the answer. Use the following format: Question: "Question here" SQLQuery: "SQL Query to run" SQLResult: "Result of the SQLQuery" Answer: "Final answer here" The SQL query should NOT end with semi-colon Question: {input}""" PROMPT = PromptTemplate( input_variables=["input", "dialect"], template=_DEFAULT_TEMPLATE ) db = SQLDatabase.from_uri("iris://superuser:******@localhost:51775/USER") llm = OpenAI(temperature=0, verbose=True) llm = OpenAI(temperature=0, verbose=True) db_chain = SQLDatabaseChain(llm=llm, database=db, prompt=PROMPT, verbose=True) db_chain.run("How many Tables are there") 结果二 SQLQuery:←[32;1m←[1;3mSELECT COUNT(*) FROM information_schema.tables←[0m SQLResult: ←[33;1m←[1;3m[(499,)]←[0m Answer:←[32;1m←[1;3mThere are 499 tables.←[0m ←[1m> Finished chain.←[0m 'There are 499 tables.' 我就说很快吧 参考资料: https://walkingtree.tech/natural-language-to-query-your-sql-database-using-langchain-powered-by-llms/ https://python.langchain.com/en/latest/modules/chains/examples/sqlite.html#sqldatabasesequentialchain https://python.langchain.com/en/latest/modules/agents/plan_and_execute.html

# 第五十七章 镜像中断程序 - 在手动故障转移之前确定备份是否处于活动状态 ## 在手动故障转移之前确定备份是否处于活动状态 假设有两个名为 `IRIS A` 和`IRIS B` 的故障转移成员。如果 `^MIRROR` 例程确认备份 (`IRIS B`) 在与主 (`IRIS A`) 丢失联系时处于活动状态，因此具有最新的来自 `IRIS A` 的日志数据，可以使用单个过程手动进行故障转移。当连接因主要故障而丢失时，不会造成数据丢失的风险。但是，当发生多个故障时，活动备份可能没有来自主服务器的所有最新日志数据，因为主服务器在连接丢失后继续运行了一段时间。 使用以下过程确定备份是否处于活动状态： 1. 确认 `IRIS` 实例 `IRIS A` 上的 `ISCAgent` 实际上已关闭（并确保它们在整个手动故障转移过程中保持关闭状态）。 2. 在 `IRIS B` 上，在终端的 `%SYS` 命名空间中运行 `^MIRROR` 例程（请参阅使用 `^MIRROR` 例程）。 3. 在主菜单中选择镜像管理，显示如下子菜单： ```java 1) Add mirrored database(s) 2) Remove mirrored database(s) 3) Activate or Catchup mirrored database(s) 4) Change No Failover State 5) Try to make this the primary 6) Connect to Mirror 7) Stop mirroring on this member 8) Modify Database Size Field(s) 9) Force this node to become the primary 10) Promote Async DR member to Failover member 11) Demote Backup member to Async DR member 12) Mark an inactive database as caught up 13) Manage mirror dejournaling on async member (disabled) 14) Pause dejournaling for database(s) ``` 4. 选择 `Force this node to become the primary` 选项。如果在联系丢失时备份处于活动状态，则会显示如下消息： ```java This instance was an active backup member the last time it was connected so if the primary has not done any work since that time, this instance can take over without having to rebuild the mirror when the primary reconnects. If the primary has done any work beyond this point (file #98), C:\InterSystems\MyIRIS\mgr\journal\MIRROR-GFS-20180815.009 then the consequence of forcing this instance to become the primary is that some operations may be lost and the other mirror member may need to be rebuilt from a backup of this node before it can join as a backup node again. Do you want to continue? ``` 如果有权访问主要文件的日志文件，则可以在继续之前确认引用的文件是最新的。 如果在与主服务器失去联系时备份未处于活动状态，则会显示如下消息： ```java Warning, this action can result in forcing this node to become the primary when it does not have all of the journal data which has been generated in the mirror. The consequence of this is that some operations may be lost and the other mirror member may need to be rebuilt from a backup of this node before it can join as a backup node again. Do you want to continue? ``` ## 手动故障转移到活动备份 如果 `^MIRROR` 例程的 `Force this node to become the primary` 选项确认备份在失去与主节点的连接时处于活动状态，请完成手动故障转移过程，如下所示： 1. 在要继续吗？提示继续该过程。 `Force this node to become the primary` 选项等待 `60` 秒以使镜像成员成为主要节点。如果操作未在 `60` 秒内成功完成，`^MIRROR` 报告操作可能未成功并指示您检查消息日志以确定操作是失败还是仍在进行中。 2. 一旦 `^MIRROR` 例程确认备份已成为主要备份，请在可以这样做时重新启动 `IRIS A`。当 `IRIS` 实例重新启动时， `IRIS A` 作为备份加入镜像。 ## 备份不活动时手动故障转移 即使 `^MIRROR` 例程未确认备份 ( `IRIS B`) 在与主 ( `IRIS A`) 失去连接时处于活动状态，仍然可以使用以下过程继续手动故障转移过程，但是如果这样做，会有数据丢失的风险。如本程序所述，可以在手动故障转移之前将最新的镜像日志文件从 `IRIS A`（如果有权访问）复制到 `IRIS` B，从而最大限度地降低这种风险。 1. 如果有权访问主服务器的镜像日志文件，请将最新的文件复制到 `IRIS B`，从 `IRIS B` 上的最新日志文件开始，然后包括来自 `IRIS A` 的任何后续文件。例如，如果 `MIRROR-MIRRORA-20180220.001`是 `IRIS B` 上的最新文件，复制 `MIRROR-MIRRORA-20180220.001` 和 `IRIS A` 上的任何更新文件。检查文件的权限和所有权，并在必要时更改它们以匹配现有日志文件。 2. 如果接受数据丢失的风险，请在提示时输入 `y` 以确认要继续；备份成为主要的。 `Force this node to become the primary` 选项等待 `60` 秒以使镜像成员成为主要节点。如果操作未在 `60` 秒内成功完成，`^MIRROR` 报告操作可能未成功并指示您检查消息日志以确定操作是失败还是仍在进行中。 3. 一旦 `^MIRROR` 例程确认备份已成为主要备份，请在可以这样做时重新启动 `IRIS A`。 - 如果 `IRIS A` 在 `IRIS` 实例重新启动时加入镜像作为备份，则不需要进一步的步骤。任何在故障成员上但不在当前主成员上的日志数据都已被丢弃。 - 如果在 `IRIS` 实例重新启动时 `IRIS A` 无法加入镜像，如重建镜像成员中描述的引用不一致数据的消息日志消息所示 `IRIS A` 上的最新数据库更改晚于最新的日志数据当 `IRIS B` 被迫成为主服务器时，它会出现在 `IRIS B` 上。要解决此问题，请按照该部分中的描述重建 `IRIS A`。

Hi 开发者们， 欢迎观看视频，以了解 InterSystems TrakCare 创新工具包（ Innovation Toolkit），该工具包可免费下载，使 TrakCare 用户能够快速访问标准 HL7® FHIR® 格式的数据，使记录系统成为转型系统： ⏯ TrakCare 创新工具包介绍 @ 2022 年全球峰会 🗣主持人：Eslam Farahat，InterSystems 产品经理 订阅InterSystems B站！

InterSystems 已纠正导致进程内存使用量增加的缺陷。 具体来说，在对局部变量执行$Order 、 $Query 或 Merge时，会出现本地进程分区内存消耗增加的问题。虽然这对大多数运行环境没有不利影响，但支持大量进程或严格限制每个进程最大内存使用的环境可能会受到影响。某些进程可能会遇到<STORE> 错误。 该缺陷存在于2023.1.0.229.0中，但它被重新发布为2023.1.0.235.1，并包含了修复程序，以加快修正，而无需客户等待维护版本。 此缺陷的更正标识为 DP-423127 和 DP-423237。这些将包含在所有未来版本中。 该缺陷出现在 InterSystems IRIS ® 、InterSystems IRIS for Health ™ 和HealthShare ® Health Connect 的版本 2022.2、2022.3 和 2023.1（内部版本 229）中。如果您运行的是这些版本之一，我们建议升级到 2023.1（内部版本 235）。 此修复也可通过 Ad hoc 分发获得。 如果您对此警报有任何疑问，请联系全球响应中心。

在维护IRIS的镜像前，管理员需要清楚的了解以下一些概念： ## Mirror的切换模式(failover mode) 切换模式在镜像监视器里被翻译成”故障转移模式“。 有两种模式： - Agent Controlled模式： - Arbiter Controlled模式：(页面上翻译为“仲裁程序受控制”) 通常情况，生产环境的镜像是安装了arbiter(仲裁者)的。Mirror启动时，在还没有连接上arbiter的时候，自动进入Agent-Controlled模式。而后当两台机器，主机，备机都连通了Arbiter，会保持在这个模式。 - 主备之间有连接； - 又都连到arbiter; - backup is active, 满足上面的条件，就进入arbiter controlled mode。而如果主备的任一方，失去了和arbiter的连接，或者备用侧丢了active, 开始尝试连接另一方，退回到agent-controlled模式。 ## Mirror同步成员的状态 [Mirror Member Journal Transfer and Dejournaling Status](https://docs.intersystems.com/irisforhealth20231/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_mirror_manage#GHA_mirror_set_status). 请注意，这里面有两个概念：一个是**Mirror成员的状态**，一个是**Journal传输和Dejournaling的状态**。下面的图中是3个字段： STATUS, Journal传输，Dejournaling. **STATUS** 镜像成员的状态。 正常工作状态 - 对于同步成员，是Primary(主)， Backup(备机)。 - 对于异步成员，正常状态是Connected(已连接) - In Trouble : 如果主机In Trouble, 是失去了到backup的连接。备机收到主机的同步数据是要返回证实(Ack)消息的。一旦出现问题，主机无法收到备机的Ack， 主机就会把备机标为"In trouble", 从此再也不会向备机发同步数据。 - Transition: 暂时状态，进程正在查看一个成员的状态，很快会转换到一个稳定状态。 如果在mirror配置的member中发现了primary，本机会进入Synchronizing状态，否则自己会尝试进入primary状态。 - Sychronizing: 从Primary接收journal，同步数据库。 ## Journal Transfer and Dejournaling Status Journal Transfer是主机向其他成员发送Journal文件。而Dejournal是把Journal文件读入数据库。 对于backup或者asycn成员，**Journal Transfer**状态表示镜像成员是否有来自主数据库的最新日志数据，如果没有，则表示日志传输的落后程度，**Dejournaling**表示从主数据库收到的所有日志数据是否已经被dejournaled（应用到成员的镜像数据库），如果没有，则表示dejournaling的落后程度。 上图中显示的是正常的状态，其中主机 Journal Transfer 和 Dejournaling 都是N/A, 表示不适用。 对于其他成员，我们分开看： Journal Transfer状态 - Active: backup的正常状态。说明backup从primary收到了最新的journal。注意哪怕是Dejournal状态只是“x秒落后“，而不是"被捕获"，Journal Transfer状态也可以是Active，只要是从主机收到了最新的Journal更新。 - Caught up(被捕获) : 备机被捕获状态，说明备机从主机收到了最新的journal数据，但主机没有在等待备机的证实消息。 这通常是一个暂时的过程，当备机在连接主机的时候会出现。 异步成员，因为不需要向主机发证实，所以正常的状态就是“被捕获” If the Primary Failover Member does not receive an acknowledgment from the Backup every Heartbeat Interval period, it demotes the Backup system from Active status to Catch-Up mode. - time behind (多少秒落后) - Disconnected on time（断开）: 在一个时间点上这个成员和primary断开了。 Dejournaling状态 - Caught up - time behind - Disconnected on time - Warning! Some Databases need attention - Wanring! Dejournaling is stopped **正常状态下的图；** 备机Backup MirrorB, Journal Transfer是Active, Dejournaling是Caught up, 异步机器MirrorDR的Journal Transfer状态和Dejournaling状态都是Caught up. 表示它们收到了最新的journal数据，并且也都把最新的global修改写入了自己的数据库。 ## Mirror的自动切换 Mirror的核心是自动切换。Backup接替主机的工作有两个前提：1. 备机在同步（Active) 状态, 2. 主机不能正常工作。在这两个前提下，我们来看看自动切换的触发条件，涉及主机，备机，仲裁机之间的通信， **自动切换触发条件** 1. Primary要求Backup接替。这种情况，主机会发生一个请求消息给备机， 要求备机接替。 - 主机IRIS正常退出 - 主机发现自己hung 2. 备机收到arbiter的请求，报告失去了到主机的连接。 仲裁机要求是和外部系统以及应用服务器部署在一个网段的。如果仲裁机无法联络主机，可以认为其他的应用系统和服务器也无法连接主机。有可能主机宕机， 也有可能主机还在正常工作，但外界已经无法联络它了， 这时候也是需要备机接手的。 这时备机也要再去核实一下，是不是能联络到主机。如果能联络到， 备机会发请求让主机Down。如果不能， 说明主机要么死了， 要么失联了， 备机先接手，等联络上再让对方force down. 3. 从主机的ISCAgent收到消息，报告Primary已经down or hung. 在agent-controlled的情况。 primary的服务器还活着。备机主动去问主机的agent, 一旦agent报告主机死了， 那备机就可以上位了。 ## Mirror的进程 管理员应该了解mirror涉及的那些进程。当出现故障时，这些进程名字，或者称为User， 经常会出现在message log记录的故障描述中。 On Primary Failover Member(主机)  我们来一个个的看看这些进程： - Mirror Master: 系统启动时自动启动，负载mirror control 和管理。 - Mirror Primary: 出向数据传输通道。 上图中有两个Mirror Primary进程，状态时RUNW, 一个连接MirrorB, 一个连接MirrorDR. - Mirror Svr: Rd*: 入向证实通道(inbound acknowledgement)， 也是单向的。 上图中同样有两个此进程，状态都是READ, IP地址分别是MirrorB和MirrorDR. - Mirror Arbiter: 到aibiter的通信进程，注意它的状态是"EVTW", 也是个单向写的频道。 On Backup Member/Async member(备机)  Mirror Masht, Mirror Arbiter不再重复解释，我们看看其他进程是干什么的。 - Mirror JrnRead: Mirror Journal从Primary发送到backup是先写到硬盘的。 JrnRead进程把收到的journal同步读到内存里，然后才进行下一步，Dejournal的工作。 - Mirror Dejour: backup机器的dejournal job进程。它把从Primary收到的journal中记录的global改变(set and kill)保存到本机的镜像数据库。 - Mirror Prefetch: 这个稍微有点难懂。当收到的journal修改中包括了使用当前backup的journal中已有的内容时，比如收到了一个修改：set ^A=^B+1, 而^B当前存在backup里， Prefetch进程会把^B从硬盘拿到内存，以加快dejournal的速度。 - Mirror Backup: two-way channel， 把收到的primary的journal写到backup的mirror journal，并且返回证实(ACK) 这里我省略了在DR上的进程，如果有兴趣，请自己查看文档。 ## MIRROR状态的监控 根据不同的场景，查看Mirror的状态有以下几种途径 ### **[使用镜像监视器](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_mirror_manage#GHA_mirror_monitor_portal)** ### 使用^MIRROR 如果您只是要简单的获得Mirror成员的状态，最直接的方法是使用^Mirror程序。 我们先看看在IRIS Terminal下^MIRROR的执行。 ```bash %SYS>do ^MIRROR 1) Mirror Status 2) Mirror Management 3) Mirror Configuration Option? 1 1) List mirrored databases 2) Display mirror status of this node 3) Display journal file info 4) Status Monitor Option? 4 Status of Mirror MIRRORTEST at 08:09:24 on 05/19/2023 Arbiter Connection Status: Arbiter Address: arbiter|2188 Failover Mode: Agent Controlled Connection Status: This member is not connected to the arbiter Journal Transfer Member Name+Type Status Latency Dejournal Latency -------------------------- --------- --------------- -------------- MIRRORA Failover Primary N/A N/A Press RETURN to refresh, D to toggle database display, Q to quit, or specify new refresh interval D Database display is now on Status of Mirror MIRRORTEST at 08:09:29 on 05/19/2023 Arbiter Connection Status: Arbiter Address: arbiter|2188 Failover Mode: Agent Controlled Connection Status: This member is not connected to the arbiter Journal Transfer Member Name+Type Status Latency Dejournal Latency -------------------------- --------- --------------- -------------- MIRRORA Failover Primary N/A N/A Mirror Databases: Record To Name Directory path Status Dejournal ------------- ----------------------------------- ----------- ----------- TEST /isc/mirrorA/TESTDB/ Normal N/A Press RETURN to refresh, D to toggle database display, Q to quit, or specify new refresh interval ``` **在操作系统中执行^MIRROR** 您可以把以下的代码写入您的脚本语言，查看mirror的状态 ```bash irisowner@mirrorA:~$ iris session iris -U "%sys" "Monitor^MIRROR" Status of Mirror MIRRORTEST at 02:57:08 on 06/13/2023 Arbiter Connection Status: Arbiter Address: arbiter|2188 Failover Mode: Arbiter Controlled Connection Status: Both failover members are connected to the arbiter Journal Transfer Member Name+Type Status Latency Dejournal Latency -------------------------- --------- --------------- -------------- MIRRORA Failover Primary N/A N/A MIRRORB Failover Backup Active Caught up MIRRORDR Disaster Recovery Connected Caught up Caught up Press RETURN to refresh, D to toggle database display, Q to quit, or specify new refresh interval q Doneirisowner@mirrorA:~$ ``` 或者更简单的，只查看本机的mirror成员状态： ```bash irisowner@mirrorA:~$ iris session iris -U "%sys" "LocalMirrorStatus^MIRROR" This instance is a Failover member Status for mirror MIRRORTEST is "Primary" Current mirror file #2 ends at 681224 Min trans file #2 min trans index: 680744 irisowner@mirrorA:~$ ``` 如果您熟悉ObjectScript， 也可以使用`$SYSTEM.Mirror`类的各个method来查看： ```bash irisowner@mirrorB:~$ echo "write \$SYSTEM.Mirror.GetMemberStatus(),! halt" |iris session iris -U "%sys" Node: mirrorB, Instance: IRIS %SYS> Backup irisowner@mirrorB:~$ ``` 如果您要查看更多的内容，您可以更多的使用%SYSTEM.Mirror类的其他方法，比如%SYSTEM.Mirror.GetFailoverMemberStatus(.pri,.alt)， $SYSTEM.Mirror.ArbiterState()等等。 ### 使用Mirror_MemberStatusList存储过程 如果您从第3方的工具查询mirror成员的状态，还有一个简单的方案，就是调用%SYS命名空间的存储过程。下图是从iris管理门户调用的截图，你可以使用任何SQL客户端调用。 如果是从iris里执行， ``` %SYS>do ##class(%ResultSet).RunQuery("SYS.Mirror","MemberStatusList") Member Name:Current Role:Current Status:Journal Transfer Latency:Dejournal Latency:Journal Transfer Latency:Dejournal Latency:Display Type:Display Status: MDCHCNDBSL1.HICGRP.COM/STAGE:Primary:Active:N/A:N/A:N/A:N/A:Failover:Primary: MDCHCNDBSL2.HICGRP.COM/STAGE:Backup:Active:Active:Caught up:Active:Caught up:Failover:Backup: CDCHCNDRSL.HICGRP.COM/STAGE:Async:Async:Caught up:Caught up:Caught up:Caught up:Disaster Recovery:Connected: ``` ### 通过SNMP获得 如果使用监控工具，您可以通过SNMP获得Mirror的状态，下面是最新的ISC-IRIS.mib中有关Mirror得指标部分。 ``` .4.1.12 = irisMirrorTab | Table of current Mirror Members status and information -- .4.1.12.1 = irisMirrorRow | Conceptual row for Mirror status and metrics | INDEX = irisSysIndex, irisMirrorIndex -- .4.1.12.1.1 = irisMirrorIndex | unique index for each Mirror Member | INTEGER -- .4.1.12.1.2 = irisMirrorName | Name of the mirror this system is a member of | STRING -- .4.1.12.1.3 = irisMirrorMember | Mirror member name | STRING -- .4.1.12.1.4 = irisMirrorRole | "Primary", "Backup", or "Async". | STRING -- .4.1.12.1.5 = irisMirrorStatus | "Active" or "Activate". | STRING -- .4.1.12.1.6 = irisMirrorJrnLatency | Mirror journal latency "Caught up", "Catchup", or "N/A". | STRING -- .4.1.12.1.7 = irisMirrorDBLatency | Mirror database latency "Caught up", "Catchup", or "N/A". | STRING ``` ## MIRROR的日志和告警 通常情况下， 维护人员是通过mirror的日志和警告来获得Mirror状态，Mirror成员之间的连接情况，而不必须定时的用命令或者调用存储过程来查看。 Cache'和IRIS的日志和警告保存在两个文件： console.log/messages.log和alert.log， 其中alert.log中记录了console.log/messages.log中级别为2，3的记录， 并必须实时发送给管理员。有关这部分内容，请参考在线文档，或者我的帖子： 我们来看看在日志中有哪些mirror的记录： **Becoming primary mirror server** 系统固有的通知消息， level =2。当一个iris实例从备机变成了主机，此信息会写到此实例的alert.log, 同时发送给管理员。 可以查看这个[链接](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_monitor#GCM_monitor_errors)。 在Mirror切换时，管理员除了从刚刚接手的机器中收到Becoming primary mirror server的通知。如果原来的主机没有宕机或者从宕机中恢复，它也会将引起切换的故障从alert.log发送给管理员，是一个level2, 或者level3的记录。 **Arbiter connection lost** level =2 , 自动发送给管理员。 当主机和arbiter失去连接后，在主机上会出现此警告。此时在备机上会出现“Switched from Arbiter Controlled to Agent Controlled failover on request from primary”的提示，是个level0的信息。 **MirrorServer: Connection to xxxx(backup) terminated** **MirrorServer: Connection to MIRRORDR (async member) terminated** 当主机和备机(backup)失去连接，在主机上会出现level2的警告。 而和异步成员丢失连接，主机会出现level1的消息。尽管level1的消息不能自动通知管理员，但这时如果同时监控该异步成员的alert.log, 通常会有level2的警告消息发出，能提醒管理员检查MIRRORDR这个镜像成员的状态。 举例说明：如果在MirrorDR中操作系统重启，IRIS启动后会出现这样的level2的警告：“Previous system shutdown was abnormal, ^SHUTDOWN forced down” **Async member for MirrorSetName started but failed to connect to primary** level =2 , 自动发送给管理员 其他更多的关于Mirror出错的level2, 也就是警告记录, 比如： - Could not open mirror journal log to read checksum, errno = 2 - Preserving all mirror journal files for offline failover member - Server^MIRRORCOMM(d): Failed to notify MIRRORB for mirror configuration change - Failed to become either Primary or Backup at startup 这不是个完整的列表，实际环境中会出现各种各样的告警通知。读懂这些通知，需要管理员了解镜像的原理，架构，以及上面介绍的镜像状态和进程的功能。 除此之外，绝大多数的level2日志的同时，会有更多的level0,level1的有关mirror变化的记录。这些内容不需要通知管理员，只是用于分析问题。 如图，下面是在一个messages.log里一个iris从备机变成主机的过程。 ``` 06/13/23-07:16:25:472 (2189) 0 [Generic.Event] MirrorClient: Switched from Arbiter Controlled to Agent Controlled failover on request from primary 06/13/23-07:16:26:274 (2189) 1 [Generic.Event] MirrorClient: Mirror_Client: Primary closed down, last # read = 504 06/13/23-07:16:26:301 (2189) 0 [Generic.Event] MirrorClient: Backup waiting for old Dejournal Reader (pid: 2190, job #31) to exit 06/13/23-07:16:27:394 (2189) 0 [Generic.Event] MirrorClient: Set status for MIRRORTEST to Transition 06/13/23-07:16:28:477 (1996) 0 [Utility.Event] [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Transition 06/13/23-07:16:30:261 (2177) 0 [Utility.Event] Returning to restart, old primary reported: "DOWN 06/13/23-07:16:31:524 (11721) 0 [Utility.Event] Applying journal data for mirror "MIRRORTEST" starting at 1538184 in file #2(/isc/mirrorB/mgr/journal/MIRROR-MIRRORTEST-20230613.001) 06/13/23-07:16:31:804 (2177) 0 [Utility.Event] Manager initialized for MIRRORTEST 06/13/23-07:16:31:986 (2177) 0 [Utility.Event] MIRRORA reports it is DOWN, becoming primary mirror server 06/13/23-07:16:32:381 (2177) 0 [Generic.Event] INTERSYSTEMS IRIS JOURNALING SYSTEM MESSAGE Journaling switched to: /isc/mirrorB/mgr/journal/MIRROR-MIRRORTEST-20230613.002 06/13/23-07:16:32:426 (2177) 0 [Utility.Event] Scanning /isc/mirrorB/mgr/journal/MIRROR-MIRRORTEST-20230613.001 06/13/23-07:16:32:479 (2177) 0 [Utility.Event] No open transactions to roll back 06/13/23-07:16:32:485 (2177) 0 [Generic.Event] MirrorServer: New primary activating databases which are current as of 1538184 (0x00177888) in mirror journal file #2 06/13/23-07:16:32:488 (2177) 0 [Generic.Event] Changed database /isc/mirrorB/TESTDB/ (SFN 5) to read-write due to becoming primary. 06/13/23-07:16:32:924 (2177) 0 [Utility.Event] Initializing Interoperability during mirror initialization 06/13/23-07:16:32:930 (2177) 2 [Utility.Event] Becoming primary mirror server ``` 更多的有关mirror监控和排除的问题， 请各位留言。 谢谢

文章相关视频参见Synthea生成FHIR测试数据，以及FHIR服务器加载FHIR资源文件 1. 什么是Synthea Synthea是一个开源软件包，可以模拟生成患者就诊数据。他的github地址在这里。 生成的就诊模版从最初的模拟美国前十种常见病、前十种慢性病到现今超过90种不同的模型。详细模型参见这里。 基于当前版本，Synthea的特性包括： 从出生到死亡的全生命周期 可配置的人口统计学信息（默认为美国马萨诸塞州人口普查数据） 模块化规则系统 插入通用模块 用于附加功能的自定义 Java 规则模块 主要医疗事件就诊、急诊室就诊和症状驱动的就诊 症状、 过敏、药品、 疫苗接种、观察/生命体征、实验室、处置、 护理计划 支持格式 HL7 FHIR（R4、STU3 v3.0.1 和 DSTU2 v1.0.2） ndjson 格式的批量 FHIR（设置 exporter.fhir.bulk_data = true 以激活） C-CDA （设置 exporter.ccda.export = true 以激活） CSV （设置 exporter.csv.export = true 以激活） CPCDS （设置 exporter.cpcds.export = true 以激活） 使用Graphviz可视化呈现规则和疾病模块 支持的参数可见下图 比如 -p 5 生成5条测试数据 -g M 生成男性测试数据 -a 60-65 生成年龄在60-65周岁患者测试数据 2. 使用Synthea 生成测试数据 为了方便使用，也将该软件做成了docker，所以你可以简单的执行下面命令行 docker run --rm -v $PWD/output:/output --name synthea-docker intersystemsdc/irisdemo-base-synthea:version-1.3.4 -p 5 该命令会在当前路径的output文件夹下生成5条患者符合FHIR标准的就诊数据，数据相关摘要信息如下面终端输出： 3. 加载生成的 FHIR 数据至 InterSystems IRIS for Health 生成完FHIR数据后，需要加载到FHIR服务器（FHIR资源仓库）中。 我们在输出目录下可以看到生成7条json数据，其中5条患者就诊相关，1条就诊医院信息，一条参与者(就诊医生)信息。 在InterSystems IRIS for health中可以方便的使用DataLoader类中的方法，批量加载FHIR资源数据，进入FHIR 资源仓库命名空间后执行： zw ##class(HS.FHIRServer.Tools.DataLoader).SubmitResourceFiles("/external/fhir/","FHIRServer","/fhir/r4") 该方法中的第一个参数是fhir资源文件路径; 第二个参数服务类型，这里一般是FHIRServer; 第三个参数FHIRServer的service名称。 执行后显示如下： 之后我们可以进入管理门户，或者使用SQL客户端查询相关存储表，表明数据被正确导入

大家好！ 这是一篇关于如何将视频嵌入您的帖子的简短文章。 其实很简单。您只需要按照以下步骤操作。 1. 打开您希望嵌入的B站视频，在视频右下角找到分享按钮； 2. 选择“嵌入代码”并复制代码 3.在社区帖子中切换到Source视图，并将您在步骤2中复制的代码粘贴在您希望嵌入视频的地方（如嵌在<p>后）； 4.再次点击“Source”，回到编辑页面，您会看到如下“IFRAME”框； 5.双击红色的“IFRAME”，并如图所示填写视频尺寸（请务必按下图数值填写），点击“确定”，即可完成视频嵌入。 希望这个帖子能帮助到您：） 在评论部分留下您对这个主题的想法，或者告诉我们您还希望了解哪些社区玩儿法。

数据平台一直在进化：从数据中心到数据中台，离散的数据资产得到进一步梳理和整合、按业务封装数据和操作数据的方法，并逐步提供了企业统一的访问、更新、检索、查询等数据服务。 然而市场上不乏听到数据平台的成功案例，却鲜见这些案例得到大规模推广。原因是什么呢？ 一. 传统数据平台建设的挑战 传统数据平台的数据模型基于各自厂商的理解，缺乏统一行业数据模型和行业语义。可供参考的国内卫生信息数据元、数据集标准并非完整的行业语义，例如没有业务实体模型和数据元关系定义。传统的数据平台建设通常根据业务域，围绕数据应用需求组织数据。经常看到按业务域划分为CDR（临床数据中心）、ODR（运营数据中心）、RDR（科研数据中心）...... 这造成了几个挑战： 1. 按业务域、而非业务实体来划分数据，虽然方便相应的业务域数据分析，但跨业务域重叠的业务实体数据，例如患者，需要跨数据中心同步。这些同步由于数据模型上的差异，往往非全息拷贝。随着同步次数越多，跨数据中心的数据越失真，造成数据资产多源不统一、数据资产一致性问题和时效性问题。 2. 数据平台产品语义表达上参差不齐，业务用户依赖数据工程师对数据理解和操作，无论是统计分析还是机器学习，海量的实施工作无法满足业务敏捷性要求； 3. 数据平台及数据应用建设依赖单一厂商的能力，而建设成果，包括数据工具、分析指标和应用都无法跨数据平台复用。往往项目都在做低水平重复建设。 4. 数据互操作标准化程度低，数据的同步、迁移困难。在缺乏数据层互操作性的情况下，各类数据中心建设的依然是数据孤岛。 5. 由于数据中心往往忽视互操作建设，数据缺乏流动，进入数据平台后，往往成为死水一潭。 二. 如何应对挑战 如何解决这些数据平台建设困境？应该如何建设数据平台？ 数据资产不是仅为分析服务的，更重要的是作为生产要素在生产全过程中发挥价值- 这就涉及到数据生成、采集、交换、决策… 在这个全过程链条上的数据互操作能力尤为重要。 HIMSS将互操作定义为4级：基础级、结构级、语义级和组织级，并认为只有到达语义级，才是标准的、才能实现广泛的互操作能力。要达到语义级的互操作，需要进行五位一体的标准化：词汇/术语标准、内容标准、传输标准、隐私和安全标准、标识符标准。 随着我们越来越依赖于机器处理数据、发掘数据背后的知识，对数据资产的开放性和互操作性的要求达到了更高的水平 - 实现机器可以理解的互操作。2016年发表在Scientific Data针对科学数据管理和监管，提出了数据的可发现（Findable）、可访问（Accessible）、可互操作（Interoperable）、可复用（Reusable）的FAIR指导原则。 这些原则的核心是让机器可以理解数据所需的语义层面的要求，尤其是可互操作和可复用两部分提到的语义级要求 - 广泛使用的语言、词汇表、元数据引用、符合相关领域的社区标准... 大家都不约而同地指向了统一行业语义。传统数据中心面临的上述挑战，正是因为缺乏统一的行业语义、缺乏统一的语义级互操作。 那什么是统一语义？ 三. 统一语义数据平台 圣经记载人类曾经联合起来兴建能通往天堂的高塔 - 巴别塔、也称通天塔。上帝为了阻止人类的计划，让人类说不同的语言。人类相互之间不能沟通，造塔计划因此失败。 统一语言是数据能够互相理解、并利用数据的前提。 语言包含2个层面： 1. 语义：真实世界事物及其关系的表达方法。例如不同电子病历系统对疑似肺癌的记录，可能记录为以下三种之一： A。问题: 癌症 身体部位:肺 确定程度:疑似 B。问题: 肺癌 确定程度:疑似 C。问题: 疑似肺癌 这三种语义表达不统一。没有统一的语义就像图里的电源插座，每个国家规格都不同，是不可能互联互通的。 2. 语法：语言的结构规则，包括词法和句法。而词法和句法都可能有歧义，就像图中示例的那样。 行业数据需要通过统一语义达到互联互通。对数据而言，统一语义不仅在数据模型（语义）、也在数据使用方式（语法）上。不仅数据语义是统一的，操作/互操作数据的方法也是统一的，并且需要能避免词法和句法歧义，才能达到语义级互操作能力！ 是不是一定要统一语义？要看数据用途：对于特定的、简单的数据任务，简化的数据模型和数据处理方法可能已经足够，但对于复杂的、跨领域的数据任务，如广泛的自然语言处理、知识图谱构建、大规模机器学习等，统一语义是非常有价值的。 显然，对于数据平台这类多用途平台，应该统一数据语义。 四. 如何建设行业统一语义数据平台 数据平台建设向统一语义迈进，而统一的行业语义模型，应该针对行业用户友好：直观、完整、语义简单、没有二义性，易于数据探索与使用。 统一语义是指要统一物理数据模型和操作数据的语言吗？是要限定到特定的技术栈吗？ 先看一下数据库的结构化查询语言（SQL）：众多的关系型数据库、甚至很多非关系型数据库都支持ANSI SQL语言。SQL定义了自己的语义 - 表、字段、视图、存储过程... 和自己的语法 - 数据定义语言（DDL）、数据操作语言（DML），但它并没有定义任何数据的物理存储方案！也正因如此，任何数据库厂商、任何数据物理存储方案，都可以通过自己的SQL编译器来支持SQL和SQL客户端，从而屏蔽数据库物理层差异，使用相同的SQL语言共同建设SQL生态。这也是SQL生态壮大的原因之一。 SQL的成功告诉我们，统一行业语义是对行业数据的逻辑表达层的要求，它不应对任何数据库技术底层做要求，也就是不应限定任何技术栈。 前面提到统一的数据操作/互操作能力是统一语义的一部分，是要用单一的数据操作方法吗？数据有多种操作方式，每种操作方式都有自己适用的场景，如下： 对同一份数据提供多模型的操作能力，会极大提升语义层的操作/互操作的便捷性，是非常重要的统一语义特性。重要的是可以针对同一份语义数据进行多种模型的操作/互操作，而不是建立针对每种模型的多套语义，并进行数据复制。 也就是说统一语义，并不是数据只能有一种操作/互操作方式，而应提供对同一份统一语义数据的多种操作/互操作方式。 五. InterSystems统一语义数据平台建设 基于上面的建设思路，InterSystems的医疗信息统一语义平台通过对行业语义的理解和其智能数据编织能力，提供医疗信息数据基座。 5.1 行业语义选择 - FHIR 行业语义应具有开放性、成熟性、准确性、完整性、灵活性、简单性、非二义性、可互操作性、机器可理解，并被广泛接受与认可。纵观医疗信息行业，虽然有不少通用数据模型，但目前最满足上述条件的是HL7 FHIR。它的资源模型覆盖面广，不仅是临床、还包括管理、科研等；不仅包括通用数据模型 - FHIR资源模型，还有对其统一的互操作方法 - FHIR API；按80/20原则设计，允许对资源模型和API进行扩展；资源模型和API简单、并有详细的用例指南；FHIR资源模型、API、扩展都可以被计算机理解；FHIR拥有庞大的用例，并且其触角不断扩展到医疗信息应用的各个层面和各个方向。 另外，更重要的是，FHIR的定位就是行业语义标准 - 逻辑层的标准，任何厂商只需要提供自己的FHIR服务器，就可以利用任何技术栈发布统一的FHIR资源和FHIR API，而屏蔽底层不同类型的数据存储方案、数据模型和数据操作方法。因而它是一个强大的生态标准，所有厂商和用户都可以参与其中。 InterSystems的解决方案选择FHIR作为统一语义，在支持FHIR的6种互操作范式的基础上，提供对FHIR资源的SQL投射 - 无需数据拷贝，就可以使用SQL大规模查询FHIR资源，对统计分析、机器学习提供简单易用的数据操作能力。 5.2 利用数据编织技术，无需推倒重来 如果正在规划数据平台，应考虑按统一语义建设。如果已经建设有各类数据中心，并不需要将已有的建设成果推倒重来。InterSystems的解决方案通过数据编织技术，将数据源编织在一起，并建立逻辑上的统一语义层。原有数据中心和其各类应用继续运行，通过统一语义层来支撑新的数据利用和应用创新。 InterSystems利用数据编织技术，提供针对所有数据源、数据模型、互操作标准的接入能力和适配器。现有的数据中心被视为数据源，只需接入而无需推倒现有建设成果。 InterSystems的多模型能力，将这些离散的数据源统一转换、表达，将多数据源的数据，以FHIR资源这个统一语义模型，发布多种数据模型的数据服务：包括FHIR JSON模型、FHIR对象模型、FHIR SQL模型，满足多种应用场景对统一语义数据的最佳操作方式。 InterSystems数据引擎，为统一语义层提供高性能、横向可扩展的持久化层，满足不同规模的数据用户所需的性能和弹性。 InterSystems提供FHIR与互联互通、HL7 V2、CDA等通用模型的开箱即用的转换能力和对用户自定义模型的自定义转换能力，提供全方位的统一语义互操作能力。

++ 更新：2018 年 8 月 1 日 使用内置于 Caché 数据库镜像的 InterSystems 虚拟 IP (VIP) 地址有一定的局限性。特别是，它只能在镜像成员驻留在同一网络子网时使用。当使用多个数据中心时，由于增加了网络复杂性（ 此处有更详细的讨论），网络子网通常不会“延伸”到物理数据中心之外。出于类似的原因，当数据库托管在云端时，虚拟 IP 通常无法使用。 负载均衡器（物理或虚拟）等网络流量管理设备可用于实现相同级别的透明度，为客户端应用程序或设备提供单一地址。网络流量管理器自动将客户端重定向到当前镜像主服务器的真实 IP 地址。自动化旨在满足灾难后 HA 故障转移和 DR 升级的需求。 网络流量管理器的集成 当今市场上有许多支持网络流量重定向的选项。这些中的每一个都支持类似甚至多种方法来根据应用程序要求控制网络流量。为了简化这些方法，我们考虑了三个类别：数据库服务器调用 API、网络设备轮询或两者的组合。 下一节将概述这些方法中的每一个，并就如何将这些方法与 InterSystems 产品集成提供指导。在所有情况下，仲裁器都用于在镜像成员无法直接通信时提供安全的故障转移决策。可以在此处找到有关仲裁器的详细信息。 出于本文的目的，示例图将描述 3 个镜像成员：主机、备份和 DR 异步。但是，我们知道您的配置可能比这更多或更少。 选项 1：网络设备轮询（推荐） 在这种方法中，网络负载均衡设备使用其内置的轮询机制与两个镜像成员通信以确定主镜像成员。 使用 2017.1 中可用的 CSP 网关的mirror_status.cxw页面的轮询方法可以用作 ELB 健康监视器中对添加到 ELB 服务器池的每个镜像成员的轮询方法。只有主镜像会响应“SUCCESS”，从而将网络流量仅定向到活动的主镜像成员。 此方法不需要向 ^ZMIRROR 添加任何逻辑。请注意，大多数负载均衡网络设备对运行状态检查的频率都有限制。通常，最高频率不少于 5 秒，这通常可以接受以支持大多数正常运行时间服务级别协议。 对以下资源的 HTTP 请求将测试本地缓存配置的镜像成员状态。 /csp/bin/mirror_status.cxw 对于所有其他情况，这些镜像状态请求的路径应该使用与请求真实 CSP 页面所用的相同的层次机制解析到适当的缓存服务器和名称空间。 示例：测试 /csp/user/ 路径中应用程序配置服务的镜像状态： /csp/user/mirror_status.cxw 注意：调用镜像状态检查不会消耗 CSP 许可证。 根据目标实例是否是活动主机，网关将返回以下 CSP 响应之一： ** 成功（是主镜像成员） =============================== HTTP/1.1 200 OK Content-Type: text/plain Connection: close Content-Length: 7 SUCCESS ** 失败（不是主镜像成员） =============================== HTTP/1.1 503 Service Unavailable Content-Type: text/plain Connection: close Content-Length: 6 FAILED ** 失败（Caché服务器不支持Mirror_Status.cxw请求） =============================== HTTP/1.1 500 Internal Server Error Content-Type: text/plain Connection: close Content-Length: 6 FAILED 考虑下图作为轮询的示例。 同步故障转移镜像成员之间自动发生故障转移： 下图演示了将 DR 异步镜像成员提升到负载均衡池中，这通常假设同一个负载均衡网络设备正在为所有镜像成员提供服务（地理分割方案将在本文后面介绍）。根据标准 DR 程序，灾难恢复成员的提升涉及人为决策，然后是数据库级别的简单管理操作。但是，一旦采取该操作，就不需要对网络设备执行任何管理操作：它会自动发现新的主要设备。 选项 2：数据库服务器调用 API 在这种方法中，使用了网络流量管理设备，它有一个用故障转移镜像成员和潜在的 DR 异步镜像成员定义的服务器池。 当镜像成员成为主镜像成员时，向网络设备发出 API 调用以调整优先级或权重，以立即指示网络设备将网络流量定向到新的主镜像成员。 相同的模型适用于在主镜像成员和备份镜像成员都不可用的情况下提升 DR 异步镜像成员。 此 API 在 ^ZMIRROR 代码中定义为过程调用的一部分： $$CheckBecomePrimaryOK^ZMIRROR() 在此过程调用中，插入可用于相应网络设备的任何 API 逻辑和方法，例如 REST API、命令行界面等。与虚拟 IP 一样，这是网络配置的突然更改，不涉及任何应用程序逻辑以通知连接到故障主镜像成员的现有客户端正在发生故障转移。根据故障的性质，这些连接可能由于应用程序超时或错误、新主实例强制旧主实例关闭或客户端使用的TCP 保持活动计时器过期造成的故障本身而关闭。 因此，用户可能必须重新连接并登录。您的应用程序的行为将决定此行为。 选项 3：地理分散部署 在具有多个数据中心和可能地理分散的部署（例如具有多个可用性区域和地理区域的云部署）的配置中，需要使用基于 DNS 的负载均衡和本地负载均衡在一个简单且易于支持的模型中考虑地理重定向实践。 通过这种组合模型，引入了与 DNS 服务配合使用的附加网络设备，如 Amazon Route 53、F5 Global Traffic Manager、Citrix NetScaler Global Server Load Balancing 或 Cisco Global Site Selector，在每个数据中心、可用性区域或云地理区域与网络负载均衡器相结合。 在此模型中，前面提到的轮询（推荐）或 API 方法在本地用于操作任何镜像成员（故障转移或 DR 异步）的位置。这用于向地理/全球网络设备报告它是否可以将流量定向到任一数据中心。同样在此配置中，本地网络流量管理设备将其自己的 VIP 提供给地理/全球网络设备。 在正常稳定状态下，活动主镜像成员向本地网络设备报告它是主镜像成员并提供“启动”状态。此“启动”状态被转发到地理/全球设备以调整和维护 DNS 记录，以将所有请求转发到此活动的主镜像成员。 在同一数据中心内的故障转移场景中（备份同步镜像成员成为主镜像成员），API 或轮询方法与本地负载均衡器一起使用，现在重定向到同一数据中心内的新主镜像成员。由于新的主镜像成员处于活动状态，因此本地负载均衡器仍以“启动”状态响应，因此未对地理/全局设备进行任何更改。 出于本示例的目的，API 方法在下图中用于本地集成到网络设备。 在使用 API 或轮询方法到不同数据中心（备用数据中心中的同步镜像或 DR 异步镜像成员）的故障转移场景中，新提升的主镜像成员开始向本地网络设备报告为主要成员。 在故障转移期间，曾经包含主镜像成员的数据中心现在不再从本地负载均衡器向地理/全球报告“Up”。地理/全球设备不会将流量定向到该本地设备。备用数据中心的本地设备将向地理/全球设备报告“Up”，并将调用 DNS 记录更新以现在定向到备用数据中心的本地负载均衡器提供的虚拟 IP。 选项 4：多层和地理分散的部署 为了使解决方案更进一步，引入了一个单独的 Web 服务器层，既可以作为私有 WAN 的内部，也可以通过 Internet 访问。此选项可能是大型企业应用程序的典型部署模型。 以下示例显示了使用多个网络设备安全隔离和支持 Web 和数据库层的示例配置。在此模型中，使用了两个地理位置分散的位置，其中一个位置被视为“主要”位置，另一个位置纯粹是数据库层的“灾难恢复”位置。数据库层灾难恢复位置将在主要位置因任何原因停止服务的情况下使用。此外，此示例中的 Web 层将显示为双活，这意味着用户将根据各种规则（例如最低延迟、最低连接数、IP 地址范围或您认为合适的其他路由规则）定向到任一位置。 如上例所示，如果在同一位置发生故障转移，则会发生自动故障转移，并且本地网络设备现在指向新的主机。用户仍然连接到任一位置的 Web 服务器， Web 服务器及其关联的 CSP 网关继续指向位置 A。 在下一个示例中，考虑在位置 A 发生的整个故障转移或中断，其中主要和备份故障转移镜像成员都无法使用。然后，DR 异步镜像成员将被手动提升为主要和备份故障转移镜像成员。在升级后，新指定的主镜像成员将允许位置 B 的负载均衡设备使用前面讨论的 API 方法（轮询方法也是一个选项）报告“Up”。由于本地负载均衡器现在报告“启动”，基于 DNS 的设备将识别这一点并将流量从位置 A 重定向到现在的位置 B 以用于数据库服务器服务。 结论 在没有虚拟 IP 的情况下设计镜像故障转移有许多可能的排列。这些选项可应用于最简单的高可用性场景或具有多层的多地理区域部署，包括故障转移和 DR 异步镜像成员，以获得高可用性和容灾解决方案，旨在为您的应用程序维持最高水平的运营弹性. 希望本文提供了一些关于成功部署具有故障转移的数据库镜像的可能的不同组合和用例的见解，这些组合和用例适合您的应用程序和可用性要求。

数据分集 （测试数据可以在网上下载 https://catalog.data.gov/dataset/） 1. 创建训练集，80%用于训练集。 CREATE TABLE DataMining.DiabetesTraining AS SELECT top 641 Pregnancies, Glucose, BloodPressure, SkinThickness, Insulin,BMI, Age, Outcome from DataMining.DSTable order by ID 2. 创建测试集，20%用于测试集。 CREATE TABLE DataMining.DiabetesTest AS SELECT top 127 Pregnancies, Glucose, BloodPressure, SkinThickness, Insulin, BMI,Age, Outcome from DataMining.DSTable order by ID DESC Integrated ML 1. 创建ML配置 此步骤用来配置Provider 及不同Provider所使用的配置参数。 InterSystems IRIS提供三种Provider，AutoML、H2O和DataRobot，本实验使用默认Provider - AutoML ，所以可以忽略创建ML配置步骤。如果想尝试开源工具H2O，可以在此实验完成后，按照扩展实验手册进行配置。 2. ML配置 SET ML CONFIGURATION %AutoML 此步骤是用来确定选用的Provider，AutoML是系统自带的Provider。 3. 建模 CREATE MODEL DiabetesModel PREDICTING (Outcome) FROM DataMining.DiabetesTraining DiabetesModel 为模型名称 （模型名称可随意设置）。 DataMining.DiabetesTraining 为糖尿病患者预测模型的训练数据集。 Outcome 为要预测的结果的列名。 4. 训练模型 TRAIN MODEL DiabetesModel DiabetesModel为模型名称。 5. 验证模型 VALIDATE MODEL DiabetesModel FROM DataMining.DiabetesTest DataMining.DiabetesTest为糖尿病患者预测模型的测试集。 6. 查看模型信息 SELECT * FROM INFORMATION_SCHEMA.ML_TRAINED_MODELS 在返回的数据PROVIDER列中，可以或者 在返回的数据MODEL_INFO列中，可以获得ModelType 算法名称, Package 机器学习处理包, ProblemType 算法类型等结果。 6. 查看验证结果 SELECT * FROM INFORMATION_SCHEMA.ML_VALIDATION_METRICS 可以获得Accuracy，Precision，Recall 和 F-Measure 计算结果。 现在，你可以通过Accuracy，Precision，Recall 和 F-Measure 来分析你的模型训练结果。如果训练模型准确率较低，可以重新训练数据集。 7. 查看测试集的预测结果和真实结果 SELECT PREDICT(DiabetesModel) AS PredictedDiabetes, Outcome AS ActualDiabetes FROM DataMining.DiabetesTest 8. 删除模型 DROP MODEL DiabetesModel

医院管理者、信息中心、业务骨干，每个角色都有独特的业务诉求，InterSystems IRIS医疗版互联互通套件专为国内用户设计，可助力医院用户释放数据价值，推动应用创新！截至目前，InterSystems技术已助力150余家医院通过四级及以上医院信息互联互通标准化成熟度评测，其中，五级乙等用户近30家。

在InterSystems IRIS中重新加载更新后的Python模块的方式和直接使用Python 重新加载模块的方式是一样的。 在Python3.4 之后到版本中，直接使用Python 重新加载模块的方式如下： import importlib ​ importlib.reload(module) 同样，在在InterSystems IRIS中重新加载Python模块的方式与其没有区别，示例如下： ClassMethod Hello() As %Status { Set sc = $$$OK Set sm = ##class(%SYS.Python).Import("sample") Set importlib = ##class(%SYS.Python).Import("importlib") do importlib.reload(sm) write sm.hello() Return sc } ​

亲爱的开发者们， 向大家分享一个好消息！InterSystems开发者中文社区版主、InterSystems高级销售工程师祝麟 ( @Lin.Zhu ) 于近日顺利通过“HL7 FHIR R4 Proficiency Exam”并取得资格认证证书！ HL7 FHIR（R4）能力证书可以证明在最新和最热门的HL7标准方面达到行业公认的专业水平。考试涵盖了以下内容：FHIR原则；FHIR资源的基本概念；交换机制；一致性和实施指导；如何使用术语；如何建立安全和可靠的FHIR解决方案；FHIR维护过程；以及如何使用和处理FHIR许可和知识产权（IP）。 FHIR®（快速医疗互操作性资源）是HL7的下一代标准框架，2023年，我们推出的InterSystems IRIS医疗版互联互通套件3.0版（V3.0）就实现了与FHIR更深层的生态互通——借助强大的、打通多个互操作生态的能力，用户可以将互联互通服务和消息与其它互操作标准（如FHIR、HL7 V2）进行自动双向转换，为数据挖掘与价值实现带来更多可能性。 举例来说，在数据利用上，通过V3.0内置的FHIR资源仓库，用户可按业务需要，将互联互通文档和消息通过FHIR资源投射为SQL结构化数据，为实现“原始数据不出院、数据可用不可见”提供了技术基础，从而极大加强现有院内临床数据中心、科研数据中心以及区域健康大数据平台等数据仓库类系统的数据利用，使BI、AI/ML过程可基于数据发掘实现价值洞察，进行数字化业务闭环，把数据转化为可以持续产生价值的资产，为医院实现数据资产变现提供必要条件，全面助力医院数字化转型和生产力提升。 在应用创新上，V3.0 提供强大的FHIR生态能力（包含SMART on FHIR与CDS Hooks），支持快速开发和集成任意支持FHIR标准的、即插即用的第三方创新应用，实现数据利用最大化，为包括居民健康管理、临床决策支持、专科电子病历等打造坚实的数据和平台基础。 InterSystems作为FHIR标准在全球范围的推广者，已经在美国和亚太地区拥有众多成功案例，并且帮助越来越多的国家部署并遵循这种标准。 再次恭喜 @Lin.Zhu ✿✿ヽ(°▽°)ノ✿ 获得这一证书！

嗨社区！ 想与您分享我在Telegram中使用GPT创建“我自己的”聊天的练习。 这个应用需要用到 Open Exchange 上的两个组件：@Nikolay.Soloviev 的Telegram Adapter和@Francisco.López1549的IRIS Open-AI 因此，通过此示例，您可以在 Telegram 中使用 ChatGPT 设置自己的聊天。 让我们看看如何让它发挥作用！ 前提条件 使用@BotFather 帐户创建一个机器人并获取机器人令牌。然后将机器人添加到电报聊天或频道中并赋予其管理员权限。在https://core.telegram.org/bots/api了解更多信息 在https://platform.openai.com/上打开（如果没有，请创建）一个帐户，并获取您的Open AI API Key和Organization id 。 确保您的 InterSystems IRIS 中安装了 IPM。如果没有，这里有一个要安装的衬垫： USER> s r = ##class ( %Net.HttpRequest ). %New (), r .Server= "pm.community.intersystems.com" , r .SSLConfiguration= "ISC.FeatureTracker.SSL.Config" d r .Get( "/packages/zpm/latest/installer" ), $system .OBJ.LoadStream( r .HttpResponse.Data, "c" ) 或者您可以像这样使用带有 IPM 的社区 docker 图像： 安装 在启用互操作性的命名空间中安装 IPM 包。 USER>zpm“安装 Telegram-gpt” 用法 打开Production 将机器人的 Telegram Token 放入 Telegram business service 和 Telegram Business operation 中： 同时使用您的聊天 GPT API 密钥和组织 ID 初始化 St.OpenAi.BO.Api.Connect 操作： 启动Production。 在Telegram聊天中提出任何问题。您将通过 Chat GPT 获得答案。尽情享受吧！ 在可视化追中： 细节 本示例使用 3.5 版本的 Chat GPT Open AI。它可以在模型参数的数据转换规则中更改。

嗨社区！ 我们已经到了#GlobalSummit23 的尾声——最后一天！这是我们的一天——程序员的一天。今天的主题演讲都致力于开发人员、他们的成长、抱负和创新。 更有趣的是，在主题演讲中，@Dean.Andrews2971谈到了开发者社区等话题。你现在可以在Youtube上观看这部分，或者晚些有更新的版本： 午餐后，出席全球峰会的所有主持人齐聚一堂，参加名为“如何充分利用 InterSystems 开发人员生态系统”的会议。今年参加的人比去年多了很多！ @Dean.Andrews2971 谈到了社区、全球大师、开放交流、创意门户的新闻和功能，以及人们如何从中受益。 然后是任何想说几句话的人的开放季节😊 @Dmitry.Maslennikov 英文社区 @José.Pereira 葡语社区 @Muhammad.Waseem 英文社区 西语社区的@Francisco.López1549 法文社区的@Lorenzo Scalese DC 英文社区的@Scott Roth 这是所有在场主持人的照片（从左到右）：@José.Pereira、@Muhammad.Waseem、@Djeniffer.Greffin7753、@Scott.Roth、@Dean.Andrews2971、@John.Murray、@Irène.Mykhailova ，@Lorenzo.Scalese，@Francisco.López1549。 多么好的一群人！ 我希望在场的每个人都喜欢这 45 分钟。 会议结束后，几乎是最后的冰淇淋和咖啡时间了！但在我看见@Guillaume.Rongier7183完成他关于他最喜欢的主题 Python 的演讲之前。 我们联系了@Dmitry.Maslennikov、@Murray.Oldfield 以及在上述会议期间加入的我们的新社区成员 - @Vladimir.Babarykin。 在最后的告别之后，我真的从 Caelestinus 抓住了@Vita.Tsareva 以上就是全部内容，希望您喜欢我的全球峰会进展情况的故事。 在评论中分享您对全球峰会的看法。您认为 2024 年全球峰会的举办地点是什么？这是一个有趣的话题😀到时候见！