本主题下汇集了各种文献，这些文献介绍了InterSystems业务理念和产品使用方法、成功案例、架构以及您可以使用 InterSystems 产品（InterSystems IRIS、InterSystems IRIS for Health、HealthShare、Caché 和 Ensemble）创建、构建和实现的解决方案的演示。
我的几个孩子都很喜欢手工艺品，您可能会觉得作为一个父亲我会用夸张的表情表扬他们很有创意然后还拍照片发到Pinterest（世界上最大的图片社交分享网站）上去，但是我从来都没这么做过。我肯定爱我的孩子，我也确实认为他们有创意，但老实讲如果你有一个正上小学的孩子，你肯定很清楚他们实际的水平。
现代医疗有无数来自数字技术的机会，包括优化流程的指挥中心、支持洞察力和决策的人工智能和机器学习、提供实时数据的物联网和连接设备，以及管理和保护大型数据流的强大数字基础设施。创建数字孪生和使用虚拟技术来推动医疗行业的真实世界价值将这一切结合起来。
数字孪生是一个物理对象或过程的虚拟副本，通过模拟和反馈物理对应物来学习和发展。它在动态系统建模的同时部署了人工智能和机器学习，并适用于医疗保健和生命科学环境。数字孪生创造了一个机会，在实施干预措施、路径变化和操作改进之前，对系统的影响进行建模和预测，以实现效益最大化和风险最小化。
这种模拟创造了以下机会：测试情景以预测影响和帮助决策（例如，在系统设计和病人治疗中）；识别低效、瓶颈和机会，并模拟效益/副作用（例如，在流程优化中）；自动化反应和决策（例如，在环境控制中）；以及越来越多地在虚拟环境中进行测试（例如，硅研究 - 美国和欧洲监管机构都在探索在新医疗药物和技术的审批中使用此类 "数字证据"）。
我们为什么要关注医疗领域的数字孪生？
环顾四周，你会看到无数的设备监测和收集我们身体状态数据的例子。可穿戴智能手表和健身追踪器、医疗成像设备、数字健康应用程序、温度计等。同样，这些设备本身也在产生关于其当前运行环境和状况的大量数据。但是，我们如何才能理解所有这些数据，并从中获得有意义的洞察？一种可能性是对这些数据进行动态展示，即所谓的数字孪生。
数字孪生是一个物理对象或系统在其生命周期内的虚拟表达。这意味着，数字孪生包含了关于其现实世界对应物状态的最新和历史数据。将这些动态数据纳入不同医疗应用的虚拟表示中，可以实现主动决策、流程优化和医疗领域的完整生命周期管理。
正如德勤最近的一份报告所强调的，数字孪生的设计和部署是为了实现虚拟协作，吸收和处理大数据，以及协助我们以更有效和安全的方式管理物理世界。
有几个行业在使用数字孪生能力方面取得了重大进展，如汽车、飞机、能源、城市规划和医疗保健等，仅举几例。疫情的影响和对全球经济造成的破坏只会加速全球数字孪生的发展速度和采用。因此，预计到2026年，全球数字孪生市场将达到482亿美元，年复合增长率为58%。虽然目前北美市场拥有最大的份额，但预计亚太市场将在未来几年经历最快的增长。
按照Gartner的说法，数字孪生是现实世界实体或系统的数字代表。数字孪生体的实现是一个封装的软件对象或模型，它反映了一个独特的物理对象、过程、组织、人或其他抽象概念。
数字孪生的设计和部署是复杂的，与其他数字技术密切相关，如云计算、人工智能、物联网、5G网络、区块链和虚拟、增强或混合现实。预计所有这些技术的采用率将对数字孪生产业产生深远影响。迄今为止，系统数字孪生体已经在所有行业中占主导地位，但专家们一致认为，产品和流程数字孪生体类型将在未来几年内上升。
对于那些在某种程度上需要测试ECP的水平可扩展性（计算能力和/或用户和进程的并发性），但又懒得建立环境、配置服务器节点等的人来说，我刚刚在Open Exchange上发布了OPNEx-ECP部署的应用/示例。
应用集成技术是市场上被广泛使用的，也是充斥着术语和概念的一个技术领域。集成平台、消息引擎、消息中间件、集成引擎、集成中间件、企业服务总线(ESB)、API网关、API管理… 很多概念与名词。到底它们是什么意思？有什么区别？哪种技术适合解决哪种集成问题？
业务集成的需求和技术的演进是紧随业务系统的软件架构发展而发展的。通过小结软件架构的发展，我们更容易梳理业务集成技术的演进、更容易看清楚各种集成架构的优势和未来发展方向。
关于 "智慧医院 "的真正内涵，有很多误解在流传。术语 "智慧Smart "已经成为 "自动化 "或 "数字设备 "的同义词。然而，事实是，增加技术、设备和传感器并不一定能使建筑或者医院变得'智慧'。而且，在某些情况下，数字创新被强加于医院，而没有真正考虑到其效果。
这种情况导致了一系列的复杂性和矛盾。例如，一方面，人们对医院采用数字技术的期望越来越高，但另一方面，人们越来越担心数字医疗解决方案正在创造更多离散的、孤岛的生态系统。同样，尽管医院面临着实现实时医疗系统的更大压力，但往往受制于其运营模式的孤岛性质或围绕各种医疗信息系统的互操作性问题。
这些相互冲突的压力表明，需要一种更协同、更集成、更综合、更全面的数字化转型方法--一种将系统整合在一起并从各个角度考虑影响的方法。
智慧医院数字孪生的出现，证明了这一技术为解决这些日益严峻的挑战提供了可行的手段。
在过去的几年里，数字孪生已经有了很大的发展，成为一项值得期待的技术。然而，尽管数字孪生被炒得沸沸扬扬，但对于数字孪生是什么（不是什么）以及它是否能实现其承诺，仍然存在相当大的困惑。像许多新技术一样，数字孪生正在 "幻觉破灭 "中挣扎并且在某些情况下被错误地描述。
在本文中，我们将通过回答这六个关键问题来正面解决这种困惑。
在医疗领域，开发创新可以挽救更多的生命。
这也是为什么我们更需要去倾听负责构建未来的人：开发人员。 他们需要什么工具才能更有效地使应用程序更加高效？ 他们面对着什么样的障碍？
InterSystems 不想去做无用的猜测，因此我们推动进行了一项研究，该研究综合了 200 名医疗行业开发者的反馈，深入了解了他们的最大需求。我们认为，这些研究结果为医疗单位和医疗技术公司提供了一个机会，可以帮助他们的开发团队为业务带来新机遇，同样也为临床医生和患者带来更光明的未来。
以下是三个关键要点：
1. 开发人员想要一个统一的医疗平台。
在接受本次研究采访的 200 名开发人员中，有88% 的受访者表示他们是医疗 IT 领域的专家或该领域的技术人员——他们都希望能有最好的、为他们的行业量身定制的开发工具。 这就是为什么一半的受访者将统一的、专注于医疗的数据平台列为购买新开发工具的关键原因。
一个合适的医疗行业开发平台应该包括互操作性/集成引擎、分析工具、面向医疗行业的自然语言处理功能、机器学习工具和 FHIR 服务器，以及其他组件。
如果一家公司能够提供一个包含所有上述组件的平台，那么超过 90% 的开发人员将对这项技术非常感兴趣。
2. 临床数据模型必不可少
这是一个我开发的名为NiPaRobotica Pharmacy的小应用。 从附件可以看到一个界面，能够接收药房配药请求，并将订单上的行项目转换为发送给机器人的配药对话 。我在3家医院的药房部署了这个接口，其中两家药房有6个机器人被安排来将药物从分配槽配送到药剂师的窗口，每天能服务1200个病人。这些机器人能够将病人平均等待时间从2小时减少一半到1小时.接下来我把这个接口部署到专门为慢病病人建的6个配送点，例如如结核病、艾滋病毒、糖尿病、癫痫、高血压和哮喘等等。这个项目的目标是“把药物带给病人”。 这些点有六个6 ATM形式的药房配药设备 (Pharmacy Dispense Units ，PDU)，可以让病人直接与呼叫中心的药剂师沟通。在每个PDU
开发者们好！
我们很高兴地宣布推出InterSystems公司的合作伙伴名录!
这里是寻找基于InterSystems产品的商业服务 和 解决方案 的地方。
为什么选择InterSystems合作伙伴目录？
以下步骤展示如何显示 /api/monitor 服务提供的指标列表示例。
在上个帖子中，我概述了以 Prometheus 格式显示 IRIS 指标的服务。 该贴介绍了如何在容器中设置和运行 IRIS 预览版 2019.4，然后列出了指标。
本帖假定您已安装 Docker。 如果未安装，现在就为您的平台安装吧 :)
按照预览发行版的下载说明下载预览版许可证密钥和 IRIS Docker 映像。 例如，我选择了 InterSystems IRIS for Health 2019.4。
按照 Docker 容器中的 InterSystems 产品初见中的说明操作。 如果您熟悉容器，请跳转到标题为“下载 InterSystems IRIS Docker 映像”的部分。
以下终端输出说明了我用来加载 docker 映像的过程。 docker load 命令可能需要几分钟的时间才能运行；
供应商或内部团队要求说明如何为 VMware vSphere 上运行的_大型生产数据库_进行 CPU 容量规划。
总的来说，在调整大型生产数据库的 CPU 规模时，有几个简单的最佳做法可以遵循：
通常，这会引出几个常见问题：
我以下面的示例回答这些问题。 但也要记住，最佳做法并不是一成不变的。 有时需要做出妥协。 例如，大型生产数据库虚拟机很可能不适合 NUMA 节点，但我们会看到，其实是没问题的。 最佳做法是指必须针对应用程序和环境进行评估和验证的准则。
(ECP) Caché 出色的可用性和扩展特性之一是企业缓存协议 (ECP)。 在应用程序开发过程中，如对使用 ECP 的分布式处理加以考虑，可以横向扩展 Caché 应用程序的架构。 应用程序处理可以调整为非常高的速率，处理能力从单个应用程序服务器扩展到最多 255 个应用程序服务器，并且不需要任何应用程序更改。
在我参与的 TrakCare 部署中，ECP 已广泛使用多年。 十年前，主要供应商之一的一台“大型”x86 服务器可能总共只有八个核心。 对于大型部署来说，ECP 是横向扩展商业服务器处理能力的方式，不适合单台昂贵的大型企业服务器。 即使是高核心数的企业服务器也有限制，因此 ECP 也用于扩展这些服务器上的部署。
如今，大多数的新 TrakCare 部署或升级到当前硬件_不需要 ECP_ 即可扩展。 目前的双插槽 x86 生产服务器可以拥有数十个核心和巨大容量的内存。 我们看到，在最近的 Caché 版本中，TrakCare 以及许多其他 Caché 应用程序具有可预测的线性扩展能力，能够随着单台服务器中 CPU 核心数量和内存的增加而支持逐渐增多的用户和事务。 在现场，我看到大多数的新部署都是虚拟化的，即使如此，虚拟机也可以根据需要扩展到主机服务器的规模。 如果资源需求超过单个物理主机可以提供的资源，则使用 ECP 进行横向扩展。
一位客户请求估计使用 cvencrypt 实用工具加密一个数据库需要多久。
这个问题有点像问一根绳子有多长 — 视情况而定。 但这是一个有趣的问题。 答案主要取决于客户使用的目标平台上的 CPU 和存储的性能，因此答案更关乎的是提出一个简单方法，可以在运行 cvencrypt 时使用该方法对 CPU 和存储进行基准测试。
InterSystems 数据平台包括了用于系统监视和警报的实用程序及工具，但对于不熟悉构建于 InterSystems 数据平台（又名 Caché）的解决方案的系统管理员来说，他们需要知道从何处下手以及需要配置什么。
本指南以在线文档和开发者社区帖子为参考，介绍了实现最低限度的监视和警报解决方案的途径，以及如何启用和配置以下组件：
本帖概述了通过为 InterSystems 数据平台（InterSystems IRIS、Caché 和 Ensemble）上的数据库磁盘创建 LVM 物理盘区 (PE) 条带来实现低延迟存储 IO 的最佳实践配置，并提供了有用链接。
一致的低延迟存储是获得最佳数据库应用程序性能的关键。 例如，对于在 Linux 上运行的应用程序，经常在数据库磁盘中使用逻辑卷管理器 (LVM) ，因为它能够扩展卷和文件系统，或者为在线备份创建快照。 对于数据库应用程序，在使用 LVM PE 条带化逻辑卷的情况下，并行写入还可提高数据 I/O 的效率，从而有助于提高大规模连续读取和写入的性能。
这是一个系列的第一篇文章。我将使用bpmn符号提供细节，如何开发、部署、保护、运营和消费IRIS数字服务，并与IRIS文档相联系。每一个子流程都将用一个单独的bpmn图来描述。这就是宏观过程。
Documentation links:
“这是一套用于在公司中实施、管控、管理和执行数据操作的硬件基础架构、软件、工具和资源，功能包括跨所有数据存储平台的数据采集、转换、存储、分发、整合、复制、可用性、安全性、保护、灾难恢复、演示、分析、保存、保留、备份、恢复、归档、召回、删除、监视和容量规划，并可使应用程序的使用满足公司的数据需求”。 (Alan McSweeney)
Data Fabric 是一种可利用包括多模型数据库、Analytics、AI、ESB/SOA、微服务和 API 管理在内的所有可用资源和技术创新来获取商业价值的新型数据操作方法。
Alan McSweeney 列出了以下 Data Fabric 使用原则：
作为一个软件架构师，如果要设计一个企业级的架构来满足当前的业务需求时，你需要达到5级的水平，这是一个巨大的挑战。有了InterSystems IRIS。
这是有可能的。通过1个产品，你可以得到SQL + NoSQL + ESB + BI + Open Analytics + Real Time Virtual cubes + NLP + AutoML + ML（使用Python）和高级云支持 + Sharding支持。
以Oracle为例，你需要Oracle数据库+ Oracle NoSQL+ Oracle BI+ Oracle SOA套件+一些附加组件，如R、Partitioning和RAC以及一些Oracle云产品的NLP和AI功能。对于开源架构、IBM或者其他友商来说，也是类似的，你需要的组件只可能更多。
医疗机构在数字化转型在技术上最大的挑战之一，就是技术栈过于丰富、快速变化以及对人的技术要求很高（这也是为什么全栈工程师最值钱的原因）；一个统一、高效、稳定、现代化、专为医疗定制的一体化数据平台能帮助客户很好地解决这个问题。IRIS for Health 是您的不二选择。
我本人和其他技术架构师经常需要向客户和供应商说明 Caché IO 要求以及 Caché 应用程序使用存储系统的方式。 在向客户和供应商说明典型的 Caché IO 配置文件和事务性数据库应用程序的要求时，下面的表格很有用。 原始表格由 Mark Bolinsky 创建。
在以后的帖子中，我将讨论更多关于存储 IO 的内容，所以现在贴上这些表格也作为将来文章的参考。
。之前我展示了如何运行 pButtons 来收集我们在下列帖子中研究的性能指标。
## 更新：2020 年 5 月。您的应用程序已部署，一切运行正常。 很好，击个掌！ 然后电话突然响个不停 – 用户投诉应用程序有时很“慢”。 这是什么意思？ 有时？ 您有哪些工具，查找和解决这个缓慢问题应查看哪些统计数据？ 您的系统基础架构是否能承担用户负载的任务？ 在投入生产之前，应该询问哪些基础架构设计问题？ 如何自信地为新硬件规划容量，而不会过度规定？ 如何停止电话铃声？ 如何一开始就不让它响？
在上一篇文章《互操作消息统一管理系列：Message Bank》中，我们了解到在Message Bank中，消息均以半结构化（XML）或非结构化（Stream）的形式保存，因此无法与客户端的结构化消息一样，直接支持基于索引的检索。为此，需要在Message Bank中定义Search Table以支持查询。关于Search Table的定义和作用，请查阅https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI.Page.cls?KEY=EEDI_search_tables。
大家如果使用过消息查看器，则能够了解IRIS自动持久化消息并提供界面让大家能够根据消息头中（如发生事件、来源、目标等）或消息体中（如患者姓名、诊断名称等消息的具体属性）来查询消息。
而在Message Bank上进行查询时，如果直接使用消息查看器，能够查询的是Message Bank的Production中传输的消息，而若不是在源系统中出现的消息，这一点一定不要混淆。
Message Bank提供了消息仓库查看器供大家查询源系统中的消息
企业信息库（MessageBank）是一个可选的远程归档设施，可以从多个来自不同实例的互操作性Production中收集信息、事件日志项目和搜索表项。如下图所示：
这套环境由两种角色的实例构成： 企业信息库服务器，它本身也是一个Production，完全由Message Bank服务组成，接收来自任何数量的客户Production提交的消息、日志等。
客户端Operation（Message Bank Operation），将其添加到一个正在运行的Production中，并用企业信息库服务器的地址进行配置。如连接通畅，消息和日志即可自动转发到Message Bank并在其中存储。
为了使你能方便地看到信息库中的信息，InterSystems IRIS®提供了以下附加选项。
对于企业信息库实例，管理门户自动包括企业监控器页面，在那里你可以监控客户端Production的状态，浏览消息库，并对被监控客户的消息进行检索。
对于每个客户端实例，你在消息库实例中配置一个到企业监控器的链接。
如下所示：
本贴提供了在 VMware ESXi 5.5 及更高版本的环境中部署 Caché 2015 及更高版本时，关于配置、系统规模调整和容量规划等方面的指南。
我假定您已经了解 VMware vSphere 虚拟化平台，所以直接给出推荐。 本指南中的推荐不特定于任何具体硬件或站点特定的实现，也不应作为规划和配置 vSphere 部署的全面指南，而是一份您可以做出选择的最佳实践配置清单。 我希望您的 VMware 专家实施团队能针对具体站点对这些推荐进行评估。
这里是 InterSystems 数据平台和性能系列的其他帖子的列表。
_注：_本帖更新于 2017 年 1 月 3 日，强调必须为生产数据库实例设置虚拟机内存预留，以保证 Caché 有足够内存可用，并且不会出现内存交换或膨胀而对数据库性能产生负面影响。 更多详细信息，请参见下面的内存部分。
在本帖中，我将展示使用_外部备份_来备份 Caché 的策略，以及与基于快照的解决方案集成的示例。 如今，大多数解决方案部署在基于 VMware 的 Linux 上，因此许多帖子都以展示解决方案如何集成 VMware 快照技术为例。
Caché 安装后即包含 Caché 在线备份，可提供不间断的 Caché 数据库备份。 但随着系统规模的扩大，您应该考虑更高效的备份解决方案。 集成了快照技术的_外部备份_是推荐的系统（包括 Caché 数据库）备份解决方案。
外部备份的在线文档包含了全部详细信息。 一个关键考虑事项是：
“为确保快照的完整性，Caché 提供了在创建快照时冻结数据库写操作的方法。 在创建快照期间，只冻结对数据库文件的物理写入，从而允许用户进程继续在内存中不间断地执行更新。”
还需要注意的是，虚拟化系统上的部分快照过程会导致正在备份的虚拟机短暂暂停，这段时间通常称为关闭时间。 该时间通常不到一秒，因此不会被用户注意到，也不会影响系统运行，但在某些情况下，关闭时间可能较长。 如果关闭时间长于 Caché 数据库镜像的 QoS 超时时间，那么备份节点将认为主节点出现故障，并将进行故障转移。 在本帖的后面部分，我将说明在需要对镜像 QoS 超时时间进行更改时如何查看关闭时间。
部分 在上个帖子中，我们安排了使用 pButtons 进行 24 小时的性能指标收集。 在本帖中，我们将研究几个收集到的关键指标，以及它们与底层系统硬件的关系。 我们还将开始探索 Caché（或任一 InterSystems 数据平台）指标与系统指标之间的关系。 以及如何使用这些指标来了解系统的每日节拍率并诊断性能问题。
本周，我将关注 CPU - 主要硬件食物群之一 :) 一位客户请我就以下情况提供建议：他们的生产服务器已接近使用寿命终止，是时候更新硬件了。 他们还考虑通过虚拟化来整合服务器，并希望适当调整裸机或虚拟机的容量规模。 今天我们将关注 CPU，在后面的帖子中，我将介绍适当调整其他主要食物群（内存和 IO）规模的方法。
所以问题是：
本帖将展示为 InterSystems 数据平台上运行的数据库应用调整共享内存需求（包括 global 和例程缓冲区、gmheap 以及 locksize）的方法，以及在配置服务器和虚拟化 Caché 应用程序时应考虑的一些性能提示。 和以往一样，当我谈到 Caché 时，我指的是所有数据平台（Ensemble、HealthShare、iKnow 和 Caché）。
[本系列其他帖子的列表](https://cn.community.intersystems.com/post/intersystems-数据平台的容量规划和性能系列文章)当我最初开始使用 Caché 时，大多数客户的操作系统是 32 位的，Caché 应用程序的内存有限且昂贵。 通常部署的英特尔服务器只有几个核心，唯一的扩展方式是选择大型服务器，或者使用 ECP 横向扩展。 现在，即使是基本的生产级服务器也具有多个处理器、几十个核心，并且最小内存为 128 或 256 GB，可能达到 TB。 对于大多数数据库安装，ECP 已被遗忘，我们现在可以在单台服务器上大幅提高应用事务处理速率。
Intersystems IRIS 是开发、运行和消耗数据科学服务的绝佳平台。 IRIS 可以使用适配器从任何类型、格式、协议和时间提取数据。 这些数据集可以通过 BPL、DTL 和 Object Script 准备，并存储为 SQL 或 NoSQL 数据。 最后，它可以被 IRIS 内部的开放 ML 算法所消耗，并在 IRIS 仪表板中可视化。 了解详情：https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=PAGE_data_science。