本主题下汇集了各种文献，这些文献介绍了InterSystems业务理念和产品使用方法、成功案例、架构以及您可以使用 InterSystems 产品（InterSystems IRIS、InterSystems IRIS for Health、HealthShare、Caché 和 Ensemble）创建、构建和实现的解决方案的演示。
供应商或内部团队要求说明如何为 VMware vSphere 上运行的_大型生产数据库_进行 CPU 容量规划。
总的来说，在调整大型生产数据库的 CPU 规模时，有几个简单的最佳做法可以遵循：
通常，这会引出几个常见问题：
我以下面的示例回答这些问题。 但也要记住，最佳做法并不是一成不变的。 有时需要做出妥协。 例如，大型生产数据库虚拟机很可能不适合 NUMA 节点，但我们会看到，其实是没问题的。 最佳做法是指必须针对应用程序和环境进行评估和验证的准则。
Google Cloud Platform (GCP) 为基础架构即服务 (IaaS) 提供功能丰富的环境，其作为云提供完备的功能，支持所有的 InterSystems 产品，包括最新的 InterSystems IRIS 数据平台。 与任何平台或部署模型一样，必须留心以确保考虑到环境的各个方面，例如性能、可用性、操作和管理程序。 本文将详细阐述所有这些方面。
应用集成技术是市场上被广泛使用的，也是充斥着术语和概念的一个技术领域。集成平台、消息引擎、消息中间件、集成引擎、集成中间件、企业服务总线(ESB)、API网关、API管理… 很多概念与名词。到底它们是什么意思？有什么区别？哪种技术适合解决哪种集成问题？
业务集成的需求和技术的演进是紧随业务系统的软件架构发展而发展的。通过小结软件架构的发展，我们更容易梳理业务集成技术的演进、更容易看清楚各种集成架构的优势和未来发展方向。
01
智慧医院的本质
什么是智慧医院？
国家卫健委提出建设智慧医院的目的是要不断增强人民群众的获得感，要求医院的流程更便捷、服务更高效、管理更精细，主要聚焦于三大领域，面向医务人员的智慧医疗、面向患者的智慧服务以及面向管理的智慧管理。
如果从技术角度进行高度抽象，我们把智慧医院的本质浓缩为一点，就是为智慧的科学决策以及基于科学决策的业务执行闭环。在现实世界里，我们要从真实业务（调查研究）中获得决策依据，同时还要有决策的方法，把决策应用在现实世界上，来影响和改变现实世界。
02
第一个时代是人工决策时代。我们医疗行业就是望闻问切，我们能拿到的数据非常有限，所以属于一个数据饥渴的时代。我们通过有限的数据来进行决策，非常容易落入我们经常批判的“三拍”型决策，“拍脑袋决策、拍胸脯保证、拍屁股走人”。显然这个决策效率不是很高。
.png)
人工决策时代：“数据稀缺”时代的决策
第二个时代是信息化时代。我们有了很多数据，能够把部分现实世界来进行数字化表达，我们也通过信息辅助人工决策进行智能决策，例如通过药品知识库推动合理用药，通过人工智辅助影像判断等等。
然而我们依旧面临着很多数据问题。首先是数据还不够完整，经常无法获取需要的数据，数据模型也不能完全表达医院的实际业务；其次，我们也还是会遇到很多数据来源问题（我们常常不知道该信任哪一份数据）、数据的关联性、实时性等问题。
关于 "智慧医院 "的真正内涵，有很多误解在流传。术语 "智慧Smart "已经成为 "自动化 "或 "数字设备 "的同义词。然而，事实是，增加技术、设备和传感器并不一定能使建筑或者医院变得'智慧'。而且，在某些情况下，数字创新被强加于医院，而没有真正考虑到其效果。
这种情况导致了一系列的复杂性和矛盾。例如，一方面，人们对医院采用数字技术的期望越来越高，但另一方面，人们越来越担心数字医疗解决方案正在创造更多离散的、孤岛的生态系统。同样，尽管医院面临着实现实时医疗系统的更大压力，但往往受制于其运营模式的孤岛性质或围绕各种医疗信息系统的互操作性问题。
这些相互冲突的压力表明，需要一种更协同、更集成、更综合、更全面的数字化转型方法--一种将系统整合在一起并从各个角度考虑影响的方法。
智慧医院数字孪生的出现，证明了这一技术为解决这些日益严峻的挑战提供了可行的手段。
在过去的几年里，数字孪生已经有了很大的发展，成为一项值得期待的技术。然而，尽管数字孪生被炒得沸沸扬扬，但对于数字孪生是什么（不是什么）以及它是否能实现其承诺，仍然存在相当大的困惑。像许多新技术一样，数字孪生正在 "幻觉破灭 "中挣扎并且在某些情况下被错误地描述。
在本文中，我们将通过回答这六个关键问题来正面解决这种困惑。
在本帖中，我将展示使用_外部备份_来备份 Caché 的策略，以及与基于快照的解决方案集成的示例。 如今，大多数解决方案部署在基于 VMware 的 Linux 上，因此许多帖子都以展示解决方案如何集成 VMware 快照技术为例。
Caché 安装后即包含 Caché 在线备份，可提供不间断的 Caché 数据库备份。 但随着系统规模的扩大，您应该考虑更高效的备份解决方案。 集成了快照技术的_外部备份_是推荐的系统（包括 Caché 数据库）备份解决方案。
外部备份的在线文档包含了全部详细信息。 一个关键考虑事项是：
“为确保快照的完整性，Caché 提供了在创建快照时冻结数据库写操作的方法。 在创建快照期间，只冻结对数据库文件的物理写入，从而允许用户进程继续在内存中不间断地执行更新。”
还需要注意的是，虚拟化系统上的部分快照过程会导致正在备份的虚拟机短暂暂停，这段时间通常称为关闭时间。 该时间通常不到一秒，因此不会被用户注意到，也不会影响系统运行，但在某些情况下，关闭时间可能较长。 如果关闭时间长于 Caché 数据库镜像的 QoS 超时时间，那么备份节点将认为主节点出现故障，并将进行故障转移。 在本帖的后面部分，我将说明在需要对镜像 QoS 超时时间进行更改时如何查看关闭时间。
大家应该都已经很熟悉 InterSystems Ensemble（一个集成和应用程序开发平台），每个人都知道 Ensemble Workflow 子系统是什么以及它对于自动化人类交互的作用。 对于那些不了解 Ensemble Workflow 的人，我将简要介绍它的功能（已经熟悉的朋友可以直接跳过这一部分并学习如何使用 Angular.js 中的 Workflow 接口）。
InterSystems Ensemble 是一个集成和应用程序开发平台，旨在集成异构系统、自动化业务流程和创建新的复杂应用程序，这些应用程序通过新的业务逻辑或新的用户界面增强集成应用程序的功能：EAI、SOA、BPM、BAM 甚至 BI （感谢 InterSystems DeepSee：一种用于开发分析应用程序的内置技术）。
Ensemble 具有以下关键功能：
适配器：与应用程序、技术和数据源交互的组件。 Ensemble 提供技术和应用程序集成适配器（Web 和 REST 服务、文件、FTP、电子邮件、SQL、EDI、HL7、SAP、Siebel、1S Enterprise 等）。 您可以使用适配器 SDK 创建自己的适配器。
业务服务：将来自外部系统的数据转换为 Ensemble 消息并启动业务流程和/或业务运营的组件。
.png)
关注FHIR的大侠们估计都注意到了，FHIR更新了它支持的互操作范式，除了消息、文档、服务、API这4种，增加了2个：资源仓库、订阅。前面4个好理解，为什么资源仓库和订阅会成为FHIR的新的互操作范式？互操作与应用集成是什么关系？
这里借FHIR的新互操作范式，聊聊应用集成，看看集成平台是什么？有什么样的集成方案？以及怎么评价不同的方案。
本文是上一篇关于如何从流行数据库（如 PostgreSQL 和 MySQL）迁移到 IRIS 的后续文章。
我们将使用与从 PostgreSQL 迁移相同的过程。 但是，您会发现它更容易，因为 MySQL 中的数据类型与 IRIS 非常相似。 这就是为什么我们不需要在列中创建转换规则。
获取示例数据到迁移过程
在 GitHub 中，可以下载 docker-compose 项目来构建和运行 2 个数据库：
要获取示例并运行它，请执行以下步骤：
转到 git 存储库 https://github.com/yurimarx/migration-mysql-iris。
克隆项目：https://github.com/yurimarx/migration-mysql-iris.git。
转到项目文件夹migration-mysql-iris。
进行构建：docker-compose build。
执行容器：docker-compose up -d。
我们不必等待SAM发布才开始规划和试用该API来监控IRIS实例。在以后的文章中，我将更深入地探讨可用的指标及其意义，并提供一些交互式仪表板的示例。首先，我将介绍一下相关背景和一些问题及答案。
IRIS（和Caché）一直在收集自身及其运行平台的数十个指标。收集这些指标来监控Caché和IRIS的方法向来有很多。我发现，很少有安装软件使用IRIS和Caché的内置解决方案。譬如，History Monitor作为性能和系统使用指标的历史数据库，已经推出很长时间了，但它没有简便方法可实时显示这些指标和仪表系统。
IRIS平台解决方案（以及整个业界）正在从仅在一些本地实例上运行的单体式应用程序过渡到“随处”部署的分布式解决方案。在许多用例中，原有的IRIS监控方案并不适用于这些新的模式。InterSystems没有做重复工作，而是将目光投向当前流行的、经过验证的监控和告警开源解决方案。
AWS 的核心是 Amazon EC2。 它是支持各种操作系统和机器配置（例如 CPU、RAM、网络）的云计算基础设施。 AWS 提供预先配置的虚拟机 (VM) 映像（称为 Amazon 系统映像或 AMI），客户操作系统包括各种 Linux® 和 Windows 发行版及版本。 可以将其它软件用作 AWS 中运行的虚拟化实例的基础。 您可以将这些 AMI 用作实例化以及安装或配置其他软件、数据等的起点，以创建特定于应用程序或工作负载的 AMI。
与任何平台或部署模式一样，必须留心以确保考虑到应用程序环境的各个方面，例如性能、可用性、操作和管理程序。
本文将详细介绍以下每个方面。
众说周知，EPIC 是电子病历厂商中当之无愧的领导者，本文让我们看看EPIC是如何玩转FHIR的，并进一步了解其互操作性方法、资源和API工具。
几十年来，EPIC和其他主要的EHR供应商一直在围绕着互操作性作斗争，有时候互相容忍，有时也得接受（开放接口）。
今天，大多数电子病历厂商已经针对市场和监管的压力采取了行动，采用FHIR API标准，扩大病人对医疗记录的访问。
但在早期，EPIC和其他竞争对手争先恐后地抢占市场份额，为了成为院内系统的主导者，与其他厂商分享数据、给别人提供数据访问似乎是自我毁灭。
那么今天，EPIC在FHIR API、SMART on FHIR 应用市场、患者访问和互操作性战略方面的立场如何？ 以下是关于EPIC在FHIR API和互操作性上提供的简单介绍和链接。
大多数EPIC集成的重点是通过EPIC系统提供扩展访问，但不一定与其他厂商共享。
Epic提供了以下几种连接方式（https://www.epic.com/interoperability/ehr-interoperability-from-anywhere）：
国务院于2022年12月19日发布了《中共中央 国务院关于构建数据基础制度更好发挥数据要素作用的意见》（后简称《数据二十条》），如何有效利用数据已经成为下一步的趋势。另一方面，无论是基于数据中台还是数据编织理念，两者也都对如何利用数据提出了构想。因此医疗行业数字化建设的目标已不能再局限于如何收集数据，建立医疗行业数据的流通机制将会是为越来越普遍的需求。
时钟拨回几年前，数据中台概念开始火爆。人们对数据中台的定义、诠释尽管有诸多差异，通过数据中台降低数据共享和利用的成本则是共同的期望。但经过这几年的探索之后，中台已死的观点也在涌现。究其原因，除去中台概念在技术上的不确定，数据流通过程中的责权益的不清晰也是严重的制约因素。毕竟，数据中台自身作为一套技术框架并不能代替法律法规与市场自动将数据转变为商品从而创造出流通价值。
那么，如何能够使数据的流通合规合法，使数据能够如货币和商品一般自由流动，则是我们需要思考和探索的主题，这次《数据二十条》的出现，无疑为医疗信息技术工作者提供了一个明确的思考方向。
背景
作为集成平台厂商，在医院同其它系统联调的时候所做的事情中，多的不是开发代码而是查消息。我先演示一下目前我正在使用的IRIS查消息的方式：
例子1：
需要看【个人信息注册服务】
我只需要在框中输入【个人信息注册】回车
点击【查看消息】，显示的是消息里面的内容,如图所示：
点击【查看流程】，显示的是IRIS消息可视化的页面，如图所示：
例子2:
需要查询患者ID为【2874621】这患者在集成平台调用了哪些服务
我只需要选择下拉选择【患者ID】，然后输入【2874621】,回车
这个是我们以用户需求的角度直观的查询到指定的消息,IRIS也有这个功能—消息查看器，它是如何使用的呢？首先，我们得知道这条消息使用了哪些Production组件，其次我们需要了解这个消息使用的实体类的结构。比如同样查这个人的消息，我需要输入request.Body.PatientID=“2874621”，选择消息类。如果我需要查多个服务的我还需要多选消息类 …… 本文不是来介绍如何使用消息查看器的，各位大概知道就好。
程序分析与设计思路
原始消息查看器的使用
我们先使用IRIS自带的【消息查看器】查患者ID为【2874621】个人信息注册服务，如图所示：
选时间，输入图中所示的条件去检索。步骤上好像也挺简单的，但是这里有两个前提条件，一是我得知道每个服务对应的消息类是哪个。
在之前的帖子中，我展示了如何使用 pButtons 收集历史性能指标。 我首选 pButtons 是因为我知道它随每个数据平台实例（Ensemble、Caché、...）一起安装。 不过，还有其他方法可以实时收集、处理和显示 Caché 性能指标，以进行简单的监视，或进行更重要的并且复杂得多的运营分析和容量计划。 最常见的数据收集方法之一是使用 SNMP（简单网络管理协议）。
SNMP 是 Caché 向各种管理工具提供管理和监控信息的标准方式。 Caché 在线文档包含了 Caché 和 SNMP 之间接口的详细信息。 虽然 SNMP 应该可以直接与 Caché 配合工作，但仍有一些配置技巧和陷阱。 我经历了很多次错误的开始，并且在 InterSystems 其他同事的帮助下，才让 Caché 与操作系统 SNMP 主代理建立对话，所以我写了这篇帖子，希望您可以避免同样的痛苦。
.png)
对于有海量数据运算场景的机器学习项目来说，IRIS 是一个很好的选择，原因包括：
本帖概述了通过为 InterSystems 数据平台（InterSystems IRIS、Caché 和 Ensemble）上的数据库磁盘创建 LVM 物理盘区 (PE) 条带来实现低延迟存储 IO 的最佳实践配置，并提供了有用链接。
一致的低延迟存储是获得最佳数据库应用程序性能的关键。 例如，对于在 Linux 上运行的应用程序，经常在数据库磁盘中使用逻辑卷管理器 (LVM) ，因为它能够扩展卷和文件系统，或者为在线备份创建快照。 对于数据库应用程序，在使用 LVM PE 条带化逻辑卷的情况下，并行写入还可提高数据 I/O 的效率，从而有助于提高大规模连续读取和写入的性能。
下文按顺序列出了数据平台上容量计划和性能系列中的所有帖子。 也列出了我的其他帖子。 我将随着该系列中新帖子的增加进行更新。
我们为什么要关注医疗领域的数字孪生？
环顾四周，你会看到无数的设备监测和收集我们身体状态数据的例子。可穿戴智能手表和健身追踪器、医疗成像设备、数字健康应用程序、温度计等。同样，这些设备本身也在产生关于其当前运行环境和状况的大量数据。但是，我们如何才能理解所有这些数据，并从中获得有意义的洞察？一种可能性是对这些数据进行动态展示，即所谓的数字孪生。
数字孪生是一个物理对象或系统在其生命周期内的虚拟表达。这意味着，数字孪生包含了关于其现实世界对应物状态的最新和历史数据。将这些动态数据纳入不同医疗应用的虚拟表示中，可以实现主动决策、流程优化和医疗领域的完整生命周期管理。
想必大家都听说过 FHIR 是解决系统间所有互操作性和兼容性问题的灵丹妙药和解决方案。就在这里，我们可以看到他手持一份 FHIR 资源，愉快地享受其中：
.png)
但对于我们这些普通人，我们将做一个小小的介绍。
让我们直接进入定义：FHIR（Fast Healthcare Interoperability Resource）是由HL7（Health Level 7标准组）开发的一种互操作性标准，旨在实现医疗行业中不同系统之间的电子医疗数据交换。
主要是通过 REST API 和 JSON 格式进行 HTTP 调用的结合（尽管它可以是 XML 以及我们可用的任何其他通信，具体根据我们的使用情况）。
一般来说，最简单的方式是拥有一个FHIR服务器，我们将使用诸如GET（从服务器获取数据）、PUT（更新数据）、POST（保存数据）和DELETE（删除数据）等HTTP调用与其通信。
FHIR处理了“资源”（Resource）的概念，用于在服务器和客户端之间发送和接收数据。这些资源旨在涵盖系统间80%的互通性需求。在这里，我们可以看到默认情况下可用的资源图示。
如您所见，每个资源都附带一个表示资源成熟度的数字或字母（其中N = 正式）。如果您访问官方的FHIR文档，您将能够获取到众多示例。
企业信息库（MessageBank）是一个可选的远程归档设施，可以从多个来自不同实例的互操作性Production中收集信息、事件日志项目和搜索表项。如下图所示：
这套环境由两种角色的实例构成： 企业信息库服务器，它本身也是一个Production，完全由Message Bank服务组成，接收来自任何数量的客户Production提交的消息、日志等。
客户端Operation（Message Bank Operation），将其添加到一个正在运行的Production中，并用企业信息库服务器的地址进行配置。如连接通畅，消息和日志即可自动转发到Message Bank并在其中存储。
为了使你能方便地看到信息库中的信息，InterSystems IRIS®提供了以下附加选项。
对于企业信息库实例，管理门户自动包括企业监控器页面，在那里你可以监控客户端Production的状态，浏览消息库，并对被监控客户的消息进行检索。
对于每个客户端实例，你在消息库实例中配置一个到企业监控器的链接。
如下所示：
在使用IRIS互操作性时，对于生产环境，为保障其有充足的磁盘空间和即时查询的效率，通常会采用消息和日志过期策略。在生产环境中只保留近期（如一个月）的信息以备回溯，过期数据将定期被清除。
尽管作为一个没有资金支持的医科专业学生，Case Western Reserve大学的Jane Hinkle最近在不到一周的时间里利用EHR供应商Epic的去识别化病人数据库Cosmos进行了临床研究，还得了奖。
Cosmos是一个HIPAA限定的数据集，整合了超过1.22亿名患者的Epic EHR数据。
"我们围绕Cosmos建立的概念就是我们所说的自助分析，这意味着Cosmos中的大数据被设置为Cosmos的任何用户都可以访问，"Epic的临床信息学家Dave Little博士在采访中告诉EHRIntelligence。"在简的案例中，我们看到一个医科学生能够带着一个有针对性的问题，从1.22亿的患者数据中找到她所需要的数据来回答这个问题。这在研究界历来是闻所未闻的。"
Hinkle的研究发现，儿科病人从COVID-19引发心肌炎的可能性是COVID-19疫苗的三到五倍。她告诉EHRIntelligence，她最初关注的是一项使用大数据工具来分析阻塞性睡眠呼吸暂停的研究。然而，当关于心肌炎是否是COVID-19疫苗接种的不良反应的问题出现时，Hinkle和她的研究导师、公共卫生硕士、医学博士、MetroHealth 公司的首席医疗信息官David Kaelber转移了他们的重点。
在医院但凡接触“数据”和“指标”的人，对以下场景应该是深有感触。同样的指标、同样的时间，有可能是同一个部门出的，最后“数据不一致”。除了“匪夷所思”，更有“深恶痛绝”。那么，如何解决这个问题？我的答案是商业智能(BI)。随着技术和市场的发展，有很多公司开始研发直接面向业务用户的敏捷BI工具，FineBI就是这样的一款BI工具。这个也是我接触的第一款国产BI。
项目的前提条件和设置
FineBI、JDK、HealthConnect、FineBI的相关安装步骤网上有很多，在此就暂时略过。要在FineBI上创建仪表板，我们需要一点数据，在此我使用的是开发过程中的一些测试数据，相关测试数据和互联互通的69个交互服务息息相关，有需要可以自己模拟的造。
将FineBI和IRIS连接
我们首先找到HealthConnect的安装文件，我们需要找到intersystems-jdbc-3.2.0.jar这样一个文件。
本贴提供了在 VMware ESXi 5.5 及更高版本的环境中部署 Caché 2015 及更高版本时，关于配置、系统规模调整和容量规划等方面的指南。
我假定您已经了解 VMware vSphere 虚拟化平台，所以直接给出推荐。 本指南中的推荐不特定于任何具体硬件或站点特定的实现，也不应作为规划和配置 vSphere 部署的全面指南，而是一份您可以做出选择的最佳实践配置清单。 我希望您的 VMware 专家实施团队能针对具体站点对这些推荐进行评估。
这里是 InterSystems 数据平台和性能系列的其他帖子的列表。
_注：_本帖更新于 2017 年 1 月 3 日，强调必须为生产数据库实例设置虚拟机内存预留，以保证 Caché 有足够内存可用，并且不会出现内存交换或膨胀而对数据库性能产生负面影响。 更多详细信息，请参见下面的内存部分。
以下步骤展示如何显示 /api/monitor 服务提供的指标列表示例。
在上个帖子中，我概述了以 Prometheus 格式显示 IRIS 指标的服务。 该贴介绍了如何在容器中设置和运行 IRIS 预览版 2019.4，然后列出了指标。
本帖假定您已安装 Docker。 如果未安装，现在就为您的平台安装吧 :)
按照预览发行版的下载说明下载预览版许可证密钥和 IRIS Docker 映像。 例如，我选择了 InterSystems IRIS for Health 2019.4。
按照 Docker 容器中的 InterSystems 产品初见中的说明操作。 如果您熟悉容器，请跳转到标题为“下载 InterSystems IRIS Docker 映像”的部分。
以下终端输出说明了我用来加载 docker 映像的过程。 docker load 命令可能需要几分钟的时间才能运行；
$ pwd
/Users/myhome/Downloads/iris_2019.4
$ ls
InterSystems IRIS for Health (Container)_2019.4.0_Docker(Ubuntu)_12-31-2019.ISCkey irishealth-2019.4.0.379.0-docker.tar
$ docker load -i irishealth-2019.4.0.379.0-docker.tar
762d8e1a6054: Loading layer [==================================================>] 91.39MB/91.39MB
e45cfbc98a50: Loading layer [==================================================>] 15.87kB/15.87kB
d60e01b37e74: Loading layer [==================================================>] 12.29kB/12.29kB
b57c79f4a9f3: Loading layer [==================================================>] 3.072kB/3.072kB
b11f1f11664d: Loading layer [==================================================>] 73.73MB/73.73MB
22202f62822e: Loading layer [==================================================>] 2.656GB/2.656GB
50457c8fa41f: Loading layer [==================================================>] 14.5MB/14.5MB
bc4f7221d76a: Loading layer [==================================================>] 2.048kB/2.048kB
4db3eda3ff8f: Loading layer [==================================================>] 1.491MB/1.491MB
Loaded image: intersystems/irishealth:2019.4.0.379.0
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
intersystems/irishealth 2019.4.0.379.0 975a976ad1f4 3 weeks ago 2.83GB
“这是一套用于在公司中实施、管控、管理和执行数据操作的硬件基础架构、软件、工具和资源，功能包括跨所有数据存储平台的数据采集、转换、存储、分发、整合、复制、可用性、安全性、保护、灾难恢复、演示、分析、保存、保留、备份、恢复、归档、召回、删除、监视和容量规划，并可使应用程序的使用满足公司的数据需求”。 (Alan McSweeney)
Data Fabric 是一种可利用包括多模型数据库、Analytics、AI、ESB/SOA、微服务和 API 管理在内的所有可用资源和技术创新来获取商业价值的新型数据操作方法。
|
大数据的 5 个 V 与 InterSystems IRIS
|
|
| Velocity（速度）：水平和垂直节点扩展传递出的弹性速度 实现者：分布式内存缓存、分布式处理、分片和多模型架构 https://www.intersystems.com/isc-resources/wp-content/uploads/sites/24/… 和 https://learning.intersystems.com/course/view.php?id=1254&ssoPass=1 | |
| Value（价值）：Analytics 和 AI产生的指数数据价值实现：BI、NLP、ML、AutoML 和多模型架构 https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=S… 和 https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls? | |
最近完成了针对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吞吐量基准测试相比，扩展性提高了一倍多。
本文提供了一个参考架构，作为示例说明基于 InterSystems Technologies（适用于 Caché、Ensemble、HealthShare、TrakCare 以及相关的嵌入式技术，例如 DeepSee、iKnow、Zen 和 Zen Mojo）提供的强大性能和高可用性应用。
Azure 有两种用于创建和管理资源的不同部署模型：Azure Classic 和 Azure Resource Manager。 本文中的详细信息基于 Azure Resource Manager (ARM) 模型。
Amazon Web Services (AWS) 云提供广泛的云基础设施服务，例如计算资源、存储选项和网络，这些都非常实用：按需提供，几秒内就可用，采用即付即用定价的模式。 新服务可得到快速配置，且前期无需支出大量资金。 这使得大企业、初创公司、中小型企业以及公共部门的客户可以访问他们所需的基础设施，从而快速响应不断变化的业务需求。
更新日期：2019 年 10 月 15 日
.png)
参见下表：