搜索​​​​

开发者社区的同学们，大家好！ 我们一直以来都有一个想法——改进收集、分析和回应开发者社区成员们的产品改进请求的过程。我们知道，我们需要一个良好的用户体验，甚至更好的内部流程，来确保收集、听取和响应最好的想法。现在，这个想法终于实现了！ 我们在此向您介绍 InterSystems官方反馈门户 💡 >> InterSystems Ideas << 💡 InterSystems Ideas InterSystems Ideas是一个全新的、推动改进的渠道，您可以通过它向我们提交与InterSystems服务(文档、开发社区、全球大师等)相关的产品改进请求和想法，看看其他人提交了什么，为你喜欢的想法投票，投票给你最喜欢的，并从InterSystems获得反馈。 我们开始积极开发和推广创意门户网站InterSystems Ideas和您的创意。我们希望这可以为您提供一个公开的方式来获得我们的产品经理和社区成员的反馈。 ✅ 获得投票最多的想法会得到产品管理部门的评审。 来社区分享你的想法吧！通过投票和评论为其他想法提供贡献——投票越多，影响力越大! 点击看看创意网站 InterSystems Ideas portal!

以下是 2023 年 InterSystems 开发者工具大赛的技术红利，您可以在投票中获得额外加分： 嵌入式 Python的使用 Docker容器的使用 ZPM 包部署 在线演示 代码质量通过 开发者社区文章 开发者社区第二篇文章 上传 YouTube 视频 第一次贡献 请参阅下面的额外加分项详细信息： 嵌入式 Python的使用 - 3 分 在您的应用程序中使用嵌入式 Python，可以获得 3 分加分。您至少需要 InterSystems IRIS 2021.2及以上版本。 Docker 容器的使用 - 2 分 如果应用程序使用在 docker 容器中运行的 InterSystems IRIS，则该应用程序将获得“Docker 容器”奖励。这是最简单的模板。 ZPM 包部署 - 2 分 如果您为您的全栈应用程序构建和发布 ZPM（ObjectScript 包管理器）包，您可以获得2分加分，以便它可以使用如下方式部署： zpm "install your-multi-model-solution" 已安装的ZPM 客户端命令，请参考： ZPM客户端。文档。 项目的在线演示 - 2 分如果您将项目作为在线演示提供给云，则可额外获得 3 个奖励积分。您可以自己完成，也可以使用此模板- 这是一个 示例。这是有关如何使用它的视频。 代码质量通过且零错误 - 1 分 包括用于代码静态控制的代码质量 Github 操作，并使其显示 0 个 ObjectScript 错误。 关于开发者社区的文章 - 2 分 在 Developer Community 上发表一篇文章，描述您的项目的功能。每篇文章获得2分。不同语言的翻译也有效。 开发者社区第二篇文章 - 1分 您的第二篇文章或其应用的翻译文章可以获得额外的奖励积分。第 3 篇及以上不会带来更多积分，但文章和应用程序的关注度将全部归您所有。 上传 YouTube 视频 - 3 分 制作演示您的产品的 Youtube 视频，每个视频可获得 3 分奖励积分。例子。 首次贡献 - 3 分 如果您是第一次参加 InterSystems Open Exchange 竞赛，可获得 3 个奖励积分！ 奖励积分清单可能会发生变化。敬请关注！ 祝比赛好运！

亲爱的开发者们， 非常感谢您又在 InterSystems 开发者社区度过了一年！ 我们的团队日复一日地努力让它变得更好，这对我们12000+ 每一位成员都很重要！ 我们想知道目前开发者社区对您有多大用处。请花点时间让我们了解您的想法，以及可以改进的地方： 👉🏼 InterSystems 开发者社区2022年度调查 👈🏼 请知悉：调查可在 5 分钟内完成。 也欢迎您在本文的评论部分提供反馈。 我们期待了解您的意见！ 😉

嘿开发者， 我们想邀请您参加我们的下一场比赛，该比赛致力于创造有用的工具，让您的开发伙伴们的生活更轻松： 🏆 InterSystems 开发者竞赛：Tool（工具）🏆 提交有助于加快开发速度、贡献更多定性代码并有助于使用 InterSystems IRIS 测试、部署、支持或监控您的解决方案的应用程序。 时间： 2023 年 1 月 23 日至 2 月 12 日（美国东部时间） 奖金池： 13,500 美元 话题 💡 InterSystems IRIS 开发者竞赛：Tool（工具）💡 在本次竞赛中，我们期待应用程序能够改善开发人员使用 IRIS 的体验，帮助更快地开发，贡献更多定性代码，帮助测试、部署、支持或监控您使用 InterSystems IRIS 的解决方案。 一般要求： 已接受的应用程序：Open Exchange 应用程序或现有应用程序的新应用程序，但有显着改进。我们的团队将审核所有申请，然后再批准他们参加比赛。 该应用程序应该可以在InterSystems IRIS Community Edition上运行。 匹配的应用程序类型：UI 框架、IDE、数据库管理、监控、部署工具等。 该应用程序应该是开源应用程序并发布在 GitHub 上。 应用程序的自述文件应为英文，包含安装步骤，并包含视频演示或/和应用程序工作原理的描述。 一位开发者最多可以携带 3 个应用程序参加比赛。 奖品 1. 专家提名奖（Experts Nomination）- 获奖者由我们特别挑选的专家团选出：： 🥇第一名 - 5,000 美元 🥈第二名 - 3,000 美元 🥉第三名 - 1,500 美元 🏅第四名 - $750 🏅第五名 - $500 🌟第 6-10 名 - $100 2. 社区提名奖（Community Nomination）- 获得总投票数最多的应用： 🥇第一名 - $750 🥈第二名 - $500 🥉第三名 - $250 如果几个参与者获得相同数量的选票，他们都被认为是赢家，奖金由赢家分享。 重要截止日期： 🛠 应用开发和注册阶段： 2023 年 1 月 23 日（美国东部时间 00:00）：比赛开始。 2023 年 2 月 5 日（美国东部时间 23:59）：提交截止日期。 ✅ 投票时间： 2023 年 2 月 6 日（美国东部时间 00:00）：投票开始。 2023 年 2 月 12 日（美国东部时间 23:59）：投票结束。 注意：开发者可以在整个注册和投票期间改进他们的应用程序。 谁可以参加？ 任何开发人员社区成员，InterSystems 员工除外。 创建一个帐户！ 👥开发人员可以组队创建协作应用程序。一个团队允许 2 到 5 名开发人员。 不要忘记在应用程序的自述文件中突出显示您的团队成员——DC 用户配置文件。 有用的资源 ✓ 示例应用程序： iris-rad-studio - 用于 UI 的 RAD cmPurgeBackup - 备份工具 errors-global-analytics - 错误可视化 objectscript-openapi-definition - 开放 API 生成器 测试覆盖率工具- 测试覆盖率助手 还有更多。 ✓ 我们建议从以下模板开始： IRIS开发模板 rest-api-竞赛模板 本机 API 竞赛模板 IRIS FHIR模板 IRIS全栈模板 IRIS互操作性模板 IRIS分析模板 ✓ 对于 IRIS 初学者： 使用 InterSystems IRIS 构建服务器端应用程序 新手学习路径 ✓ 对于ObjectScript 包管理器 (ZPM)的初学者： 如何使用 InterSystems IRIS 的 REST 应用程序构建、测试和发布 ZPM 包 使用 InterSystems IRIS 和 ZPM 的封装优先开发方法 ✓ 如何提交您的应用程序参加比赛： 如何在 Open Exchange 上发布应用程序 如何提交比赛申请 需要帮忙？ 加入 InterSystems 的Discord 服务器上的竞赛频道或在本文的评论中与我们交谈。 我们迫不及待地想看到您的项目！祝你好运👍 参加本次比赛，即表示您同意此处列出的比赛条款。请在继续之前仔细阅读它们。

Hey Community, Play the new video on InterSystems Developers Bilibili官方频道: ⏯ 与 InterSystems 一起释放机器学习的力量 探索如何使用 InterSystems 的所有最新和最先进技术进行机器学习，包括 使用 SQL 和我们的 InterSystems Cloud SQL 服务进行特征工程。 使用 InterSystems IntegratedML 服务训练 ML 模型。 使用与 InterSystems IRIS 中的数据相连的 Jupyter Notebook 和 Python 训练 ML 模型。 使用 ObjectScript 和嵌入式 Python 将 ML 模型集成到应用程序中。 主讲人: 🗣 Marta Manzin, Senior Developer, InterSystems🗣 @Donald.Woodlock, Vice President of Healthcare, InterSystems🗣 @Alex.MacLeod, Director of HealthShare Commercial Initiatives, InterSystems 祝您观看愉快，并探索更多视频！👍

本贴提供了在 VMware ESXi 5.5 及更高版本的环境中部署 Caché 2015 及更高版本时，关于配置、系统规模调整和容量规划等方面的指南。 我假定您已经了解 VMware vSphere 虚拟化平台，所以直接给出推荐。 本指南中的推荐不特定于任何具体硬件或站点特定的实现，也不应作为规划和配置 vSphere 部署的全面指南，而是一份您可以做出选择的最佳实践配置清单。 我希望您的 VMware 专家实施团队能针对具体站点对这些推荐进行评估。 [这里是 InterSystems 数据平台和性能系列的其他帖子的列表。](https://cn.community.intersystems.com/post/intersystems-数据平台的容量规划和性能系列文章) _注：_本帖更新于 2017 年 1 月 3 日，强调必须为生产数据库实例设置虚拟机内存预留，以保证 Caché 有足够内存可用，并且不会出现内存交换或膨胀而对数据库性能产生负面影响。 更多详细信息，请参见下面的*内存*部分。 ### 参考 本文中的信息基于经验和对公开的 VMware 知识库文章及 VMware 文档（例如 [VMware vSphere 性能最佳实践](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/vsphere-esxi-vcenter-server-67-performance-best-practices.pdf)）的研究以及对 Caché 数据库部署要求的反映。 ## ESXi 支持 InterSystems 的产品吗？ 针对处理器类型和操作系统（包括虚拟化操作系统）验证和发布 InterSystems 产品是 InterSystems 的策略和程序。 有关详情，请参见 [InterSystems 支持策略](http://www.intersystems.com/services-support/product-support/virtualization/)和[版本信息](http://www.intersystems.com/services-support/product-support/latest-platform/)。 > 例如，在 x86 主机上的 ESXi 中，支持在 Red Hat 7.2 操作系统上运行 Caché 2016.1。 注：如果您不编写自己的应用程序，还必须检查应用程序供应商支持策略。 ### 支持的硬件 在配合使用当前服务器和存储组件的情况下，VMware 虚拟化很适合 Caché。 使用 VMware 虚拟化的 Caché 已在客户站点成功部署，并且性能和可伸缩性已在基准测试中得到验证。 在配置正确的存储、网络和搭载较新型号的英特尔至强处理器（具体为英特尔至强 5500、5600、7500、E7 系列和 E5 系列，包括最新的 E5 v4）的服务器上使用 VMware 虚拟化不会对性能产生明显影响。 通常，Caché 和应用程序在客户机操作系统上的安装和配置方式与裸机操作系统上的安装和配置方式相同。 客户有责任查看 [VMware 兼容性指南](http://www.vmware.com/resources/compatibility/search.php)，以了解所使用的特定服务器和存储。 # 虚拟化架构 VMware 常用于 Caché 应用程序的两种标准配置： - 主生产数据库操作系统实例在“裸机”集群上，而 VMware 只用于其他生产和非生产实例，如 Web 服务器、打印、测试、训练等。 - 所有操作系统实例（包括主生产实例）均已虚拟化。 本帖可用作任一方案的指南，不过重点是第二个方案，即包括生产实例在内的所有操作系统实例均已虚拟化。 下图显示了该配置的典型物理服务器设置。 _图 1. 简单的虚拟化 Caché 架构_ 图 1 显示了一个常见的包含至少三台物理主机服务器的部署，可通过 VMware HA 集群中的主机服务器提供 N+1 容量和可用性。 要扩展资源，可能要向集群添加额外的物理服务器。 备份/还原媒体管理和灾难恢复也可能需要额外的物理服务器。 有关特定于 _VMware vSAN_、VMware 的超融合基础架构解决方案的推荐，请参见以下帖子：[第 8 部分 超融合基础架构容量和性能规划](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-8-hyper-converged-infrastructure-capacity)。 本贴中的大部分推荐可以应用于 vSAN，除了下面的“存储”部分有一些明显差异。 # VMWare 版本 下表给出了针对 Caché 2015 及更高版本的主要推荐： vSphere 是包括 vCenter Server 在内的产品套件，允许通过 vSphere 客户端对主机和虚拟机进行集中系统管理。 > 本帖假定将使用 vSphere，而不是“免费的”ESXi Hypervisor 单独版本。 VMware 有多种授权模式；最终选择取决于哪个模式最适合您当前和将来的基础架构规划。 我通常推荐“企业版”，因为它增加了功能，例如让硬件得到更有效利用的动态资源调度 (DRS)，以及用于存储阵列整合（快照备份）的存储 API。 VMware 网站给出了版本比较。 还有高级套件，允许捆绑 vSphere 的 vCenter Server 和 CPU 许可证。 套件有升级限制，因此通常只推荐给不期望增长的小型站点。 # ESXi 主机 BIOS 设置 ESXi 主机是物理服务器。 在配置 BIOS 前，您应该： - 向硬件供应商核实服务器是否正在运行最新的 BIOS - 检查是否有服务器/CPU 型号特定的 BIOS 设置专门用于 VMware。 服务器 BIOS 的默认设置对于 VMware 可能不是最佳设置。 以下设置可以用来优化物理主机服务器以获得最佳性能。 并非下表中的所有设置在所有供应商的服务器上都可用。 # 内存 内存分配应考虑以下关键规则： 在单台物理主机上运行多个 Caché 实例或其他应用程序时，VMware 有多种技术可以实现高效的内存管理，如透明页共享 (TPS)、膨胀、交换和内存压缩。 例如，当多个操作系统实例在同一主机上运行时，TPS 可去除内存页的冗余副本，从而允许内存过载而不会降低性能，这使得虚拟机运行所占用的内存少于物理机所需内存。 > 注：必须在操作系统中安装 VMware Tools，才能利用 VMware 的这些功能和许多其他功能。 虽然这些功能的存在是为了允许内存过载，但建议务必先调整所有虚拟机的 vRAM 大小，以适应可用的物理内存。 在生产环境中，尤其重要的是要仔细考虑内存过载的影响，只有在收集数据以确定可能的过载量后，才能进行内存过载。 要确定给定 Caché 实例的内存共享有效性和可接受的过载程度，请运行工作负载并使用 Vmware 命令 `resxtop` 或 `esxtop` 来观察实际的内存节省情况。 在规划 Caché 实例内存要求时，建议回顾一下[本系列中关于内存的第四个帖子](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-part-4-looking-memory)。 尤其是“VMware 虚拟化注意事项”部分，其中的重点是： > 在生产系统上设置 VMware 内存预留。 您想要*必须*避免任何共享内存交换，所以将生产数据库虚拟机内存预留设置为至少是 Caché 共享内存的大小加上 Caché 进程和操作系统及内核服务的内存。 如果有疑虑，则**预留整个生产数据库虚拟机内存（100% 预留）**，以保证 Caché 实例有足够内存可用，这样就不会出现内存交换或膨胀而对数据库性能产生负面影响。 注：较大的内存预留将影响 vMotion 运行，因此在设计 vMotion/管理网络时必须考虑到这一点。 只有目标主机的可用物理内存大于或等于预留内存的大小时，才能使用 Vmware HA 实时迁移虚拟机或在另一台主机上启动虚拟机。 这对于 Caché 生产虚拟机特别重要。 例如，要特别注意 HA 准入控制策略。 > 确保容量规划允许在 HA 发生故障转移时分配虚拟机。 对于非生产环境（测试、训练等)，可以应用更积极的内存过载，但不要让 Caché 共享内存过载，而是通过减少全局缓冲区来限制 Caché 实例的共享内存。 当前的英特尔处理器架构具有 NUMA 拓扑。 处理器有自己的本地内存，并且可以访问同一主机中其他处理器上的内存。 毫无疑问，访问本地内存的延迟要低于远程内存。 有关 CPU 的讨论，请查看[本系列的第三个帖子](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-3-focus-cpu)，_评论部分_中包括了关于 NUMA 的讨论。 如上面的 BIOS 部分所述，实现最佳性能的策略是，在理想情况下，将虚拟机规模调整为只达到单个处理器支持的最大核心数和内存量。 例如，如果容量规划显示最大的生产 Caché 数据库虚拟机将具有 14 个 vCPU 和 112 GB 内存，则考虑具有 2 个 E5-2680 v4（14 核处理器）和 256 GB 内存的服务器集群是否合适。 > **理想情况下**，调整虚拟机规模以使内存在 NUMA 节点本地。 但不要太过执着于此。 如果需要一个比 NUMA 节点大的“怪兽虚拟机”，那也没问题，VMware 将管理 NUMA 以获得最佳性能。 合理调整虚拟机的规模并且分配的资源不超过所需资源也很重要（参见下文）。 ## CPU 虚拟 CPU 分配应考虑以下关键规则： Caché 生产系统的规模应根据实际客户站点的基准测试和测量结果来确定。 对于生产系统，使用一开始就将系统规模调整为与裸机 CPU 核心数相同的策略，并根据最佳实践进行监测，看是否可以减少虚拟 CPU (vCPU)。 ### 超线程和容量规划 根据物理服务器的规则调整__生产数据库__虚拟机规模的一个良好起点是，针对启用了超线程功能的目标处理器计算物理服务器 CPU 要求，然后简单地进行转换： > 一个物理 CPU（包括超线程）= 一个 vCPU（包括超线程）。 一个常见的误解是，超线程以某种方式使 vCPU 容量增加了一倍。 这对于物理服务器或逻辑 vCPU 来说并不正确。 裸机服务器上的超线程可能会比没有超线程的相同服务器提升 30% 的性能，但这也会根据应用情况的不同而有所不同。 对于初始规模调整，假定 vCPU 具有完整的内核专用资源。 例如，如果您有一台 32 核（2 个 16 核）E5-2683 V4 服务器 – 总共多达 32 个 vCPU 的容量规模，且可能还有余量。 此配置假定在主机级别启用了超线程。 VMware 将管理主机上所有应用程序和虚拟机之间的调度。 在您花时间监测应用程序、操作系统和 VMware 在峰值处理期间的性能后，您可以决定是否进行更高度的整合。 ### 授权 在 vSphere 中，可以为虚拟机配置一定数量的插槽或核心。 例如，如果有一个双处理器虚拟机（2 个 vCPU），则可以将其配置为两个 CPU 插槽，或一个具有两个 CPU 核心的插槽。 从执行的角度看，并没有多大区别，因为虚拟机监控程序将最终决定虚拟机是在一个还是两个物理插槽上执行。 但是，指定双 CPU 虚拟机实际有两个核心而不是两个插槽，会对软件许可证产生影响。 注：Caché 许可证以核心数为准（而非线程数）。 # 存储 > 本部分适用于更为传统的使用共享存储阵列的存储模型。 有关 _vSAN_ 的建议，另请参见以下帖子：[第 8 部分 超融合基础架构容量和性能规划](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-8-hyper-converged-infrastructure-capacity) 对于存储，应考虑以下关键规则： ## 针对性能调整存储大小 存储瓶颈是影响 Caché 系统性能的最常见问题之一，对于 VMware vSphere 配置也是如此。 最常见的问题是简单地按 GB 容量来调整存储大小，而不是分配足够多的磁盘主轴来支持预期的 IOPS。 在 VMware 中，存储问题可能更加严重，因为可能有更多主机通过相同的物理连接访问同一存储。 ## VMware 存储概述 VMware 存储虚拟化可以分为三层，例如： - 存储阵列是底层，由物理磁盘组成，以逻辑磁盘（存储阵列卷或 LUN）的形式呈现给上面的层。 - 下一层是 vSphere 占用的虚拟环境。 存储阵列 LUN 以数据存储的形式呈现给 ESXi 主机，并格式化为 VMFS 卷。 - 虚拟机由数据存储中的文件组成，所包含的虚拟磁盘以磁盘的形式呈现给客户机操作系统，可以对这些磁盘进行分区并在文件系统中使用。 VMware 为管理虚拟机中的磁盘访问提供了两种选择 — VMware 虚拟机文件系统 (VMFS) 和原始设备映射 (RDM)，两者的性能相似。 为了简化管理，VMware 通常推荐 VMFS，但在某些情况下可能需要 RDM。 作为一般建议 – 除非有特别的理由使用 RDM，否则请选择 VMFS，_VMware 的新开发针对 VMFS 而非 RDM_。 ### 虚拟机文件系统 (VMFS) VMFS 是 VMware 开发的一种文件系统，专门针对集群虚拟环境（允许从多个主机进行读/写访问）和大型文件存储进行优化。 VMFS 的结构使虚拟机文件可以存储在一个文件夹中，从而简化了虚拟机管理。 VMFS 还支持 vMotion、DRS 和 VMware HA 等 VMware 基础架构服务。 操作系统、应用程序和数据存储在虚拟磁盘文件（.vmdk 文件）中。 vmdk 文件存储在数据存储中。 一个虚拟机可以由分布在几个数据存储上的多个 vmdk 文件组成。 如下图中的生产虚拟机所示，一个虚拟机可以包括分布在多个数据存储上的存储。 对于生产系统，每个 LUN 使用一个 vmdk 文件可实现最佳性能，对于非生产系统（测试、训练等），多个虚拟机 vmdk 文件可以共享一个数据存储和一个 LUN。 虽然 vSphere 5.5 支持的最大 VMFS 卷大小为 64TB，VMDK 大小为 62TB，但在部署 Caché 时，通常使用映射到不同磁盘组上的 LUN 的多个 VMFS 卷来分离 IO 模式并提高性能。 例如，随机或顺序 IO 磁盘组，或者将生产 IO 与其他环境的 IO 分开。 下图显示了与 Caché 一起使用的 VMware VMFS 存储示例的概览： _图 2. VMFS 上的 Caché 存储示例_ ### RDM RDM 允许将原始 SCSI 磁盘或 LUN 作为 VMFS 文件来进行管理和访问。 RDM 是 VMFS 卷上的特殊文件，用作原始设备的代理。 对于大多数虚拟磁盘存储，推荐使用 VMFS，但在某些情况下可能需要使用原始磁盘。 RDM 仅适用于光纤通道或 iSCSI 存储。 ### 用于阵列集成的 VMware vStorage API (VAAI) 为获得最佳存储性能，客户应考虑使用支持 VAAI 的存储硬件。 VAAI 可以在几个方面（包括虚拟机置备和精简置备的虚拟磁盘）提高性能。 对于较旧的阵列，可以向阵列供应商索取固件更新来支持 VAAI。 ### 虚拟磁盘类型 ESXi 支持多种虚拟磁盘类型： **厚置备** – 在创建时分配空间。 进一步分为： - 快速置零 – 将 0 写入整个驱动器。 这会增加创建磁盘所需的时间，但可获得最佳性能，即使是第一次写入每个块。 - 延迟置零 – 首次写入每个块时写入 0。 延迟置零缩短了创建时间，但第一次写入块时会使性能降低。 不过，后续写入的性能与快速置零的厚磁盘相同。 **精简置备** – 在写入时分配空间并置零。 对未写入的文件块进行第一次写入时，会有较高的 I/O 成本（类似于延迟置零的厚磁盘），但在随后写入精简置备的磁盘时，性能与快速置零的厚磁盘相同。 _在所有磁盘类型中，VAAI 都可以通过将操作卸载到存储阵列来提高性能。_某些阵列还在阵列级别支持精简置备，请勿在精简置备的阵列存储上精简置备 ESXi 磁盘，因为置备和管理可能存在冲突。 ### 其他备注 如上文所述，为了符合最佳实践，请使用与裸机配置相同的策略；生产存储可以在阵列级别分成多个磁盘组： - 随机访问 Caché 生产数据库 - 顺序访问备份和日志，但也可以放置其他非生产存储，如测试、训练等 请记住，数据存储是存储层的抽象表示，因此，它是存储的逻辑表示而不是物理表示。 创建专门的数据存储以隔离特定的 I/O工作负载（无论是日志还是数据库文件），并且不隔离物理存储层，并不会对性能产生预期的影响。 虽然性能是关键，但共享存储的选择更多取决于站点现有或计划的基础架构，其次才是 VMware 的影响。 与裸机实现一样，FC SAN 的性能最好，推荐使用。 对于 FC，建议至少使用 8Gbps 的适配器。 只有在适当的网络基础架构到位的情况下，才能支持 iSCSI 存储，这包括：服务器和存储之间的网络中的所有组件上都必须支持至少 10Gb 的以太网和巨型帧 (MTU 9000)，并且与其他流量分开。 对于数据库虚拟机或具有高 I/O 负载的虚拟机，使用多个 VMware 准虚拟 SCSI (PVSCSI) 控制器。 PVSCSI 可以提高整体存储吞吐量，同时降低 CPU 利用率，从而带来显著效益。 通过使用多个 PVSCSI 控制器，可以在客户机操作系统内执行多个并行 I/O 操作。 此外，建议通过单独的虚拟 SCSI 控制器将日志 I/O 流量与数据库 I/O 流量分开。 作为最佳实践，您可以将一个控制器用于操作系统和交换，另一个控制器用于日志，另外一个或多个控制器用于数据库数据文件（取决于数据库数据文件的数量和大小）。 众所周知，对齐文件系统分区是针对数据库工作负载的存储最佳实践。 物理机和 VMware VMFS 分区上均对齐分区可以防止因 I/O 跨越磁道边界而导致的 I/O 性能下降。 VMware 测试结果显示，将 VMFS 分区与 64KB 磁道边界对齐，可降低延迟并提高吞吐量。 按照存储和操作系统供应商的建议，使用 vCenter 创建的 VMFS 分区应与 64KB 边界对齐。 # 网络 对于网络，应考虑以下关键规则： 如上文所述，VMXNET 适配器比默认的 E1000 适配器具有更好的性能。 VMXNET3 允许 10Gb，并且使用更少的 CPU，而 E1000 只支持 1Gb。 如果各主机之间只有 1 Gb 的网络连接，那么客户端与虚拟机的通信不会有太大变化。 但是，VMXNET3 将允许同一主机上的虚拟机之间建立 10Gb 网络连接，这确实会带来改变，特别是在多层部署或者实例之间有高网络 IO 要求的情况下。 在计划关联性和反关联性 DRS 规则以将虚拟机保持在相同或不同的虚拟交换机上时，也应考虑此功能。 E1000 使用可用于 Windows 或 Linux 的通用驱动程序。 在客户机操作系统上安装 VMware Tools 之后，即可安装 VMXNET 虚拟适配器。 下图显示了一个典型的具有四个物理网卡端口的小型服务器配置，在 VMware 中配置了两个端口用于基础架构流量：用于管理和 vMotion 的 dvSwitch0，两个端口用于 VM 使用的应用程序。 使用网卡绑定和负载平衡来实现最佳吞吐量和 HA。 _图 3. 典型的具有四个物理网卡端口的小型服务器配置。_ # 客户机操作系统 推荐如下： > 将 VMware Tools 加载到所有虚拟机操作系统中并保持该工具为最新是非常重要的。 VMware Tools 是一套实用工具，可增强虚拟机的客户机操作系统的性能，并改进对虚拟机的管理。 如果客户机操作系统中未安装 VMware Tools，则客户机性能会缺乏重要功能。 在所有 ESXi 主机上正确设置时间至关重要 - 这最终会影响客户机虚拟机。 虚拟机的默认设置是不将客户机的时间与主机同步 - 但在某些时候，客户机还是会与主机同步时间，并且如果超时，则已知会导致重大问题。 VMware 建议使用 NTP 而不是 VMware Tools 定期进行时间同步。 NTP 是行业标准，可确保客户机的计时准确。 可能需要开放防火墙 (UDP 123) 才能允许 NTP 流量。 # DNS 配置 如果 DNS 服务器托管在虚拟化基础架构上并且不可用，它会阻止 vCenter 解析主机名，使虚拟环境无法管理 - 然而虚拟机本身保持运行，没有问题。 # 高可用性 高可用性由 VMware vMotion、VMware Distributed Resource Scheduler (DRS) 和 VMware High Availability (HA) 等功能提供。 Caché 数据库镜像也可以用于增加正常运行时间。 为 Caché 生产系统设计 n+1 个物理主机是非常重要的。 在单个主机发生故障时，必须有足够的资源（例如 CPU 和内存）让其余主机上的所有虚拟机都能运行。 在服务器发生故障时，如果 VMware 无法在其余服务器上分配足够的 CPU 和内存资源，VMware HA 将不会在其余服务器上重新启动虚拟机。 ## vMotion vMotion 可以与 Caché 一起使用。 vMotion 允许以完全透明的方式将一个正常运行的虚拟机从一台 ESXi 主机服务器迁移到另一台。 虚拟机中运行的操作系统和 Caché 等应用程序没有服务中断。 使用 vMotion 进行迁移时，只有虚拟机的状态和内存（及其配置）会移动。 虚拟磁盘不需要移动；它保留在相同的共享存储位置。 虚拟机迁移后，它将在新的物理主机上运行。 vMotion 只能在共享存储架构（如共享 SAS 阵列、FC SAN 或 iSCSI）下工作。 由于 Caché 通常配置为使用大量共享内存，因此为 vMotion 提供充足的网络容量是非常重要的，1Gb 网络可能还可以，但也可能需要更高带宽，或者可以配置多网卡 vMotion。 ## DRS 分布式资源调度器 (DRS) 是一种通过在集群中的不同主机服务器之间共享工作负载来在生产环境中自动使用 vMotion 的方法。 DRS 还具有对虚拟机实例实施 QoS 的能力，通过阻止非生产虚拟机过度使用资源来保护生产虚拟机的资源。 DRS 会收集有关集群主机服务器使用情况的信息，并通过在集群的不同服务器之间分配虚拟机工作负载来优化资源。 这种迁移可以自动或手动进行。 ## Caché 数据库镜像 对于要求最高可用性的任务关键型一级 Caché 数据库应用实例，还应考虑使用 [InterSystems 同步数据库镜像](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_mirror#GHA_mirror_set_bp_vm)。同时使用镜像的其他优势包括： - 最新数据的单独副本。 - 故障转移在数秒内完成（比先重启虚拟机再重启操作系统再恢复 Caché 要快）。 - 在应用程序/Caché 发生故障（VMware 未检测到）时进行故障转移。 # vCenter Appliance vCenter Server Appliance 是基于 Linux 的预配置虚拟机，针对 vCenter Server 和相关服务的运行进行了优化。 我一直建议拥有小型集群的站点使用 VMware vCenter Server Appliance 作为在 Windows 虚拟机上安装 vCenter Server 的替代方案。 在 vSphere 6.5 中，建议将该设备用于所有部署。 # 总结 本帖是在 VMware 上部署 Caché 时应考虑的关键最佳实践的综述。 这些最佳实践大多不是 Caché 独有的，而是可以应用于 VMware 上的其他一级业务关键型部署。 如果您有任何问题，请通过下面的评论告诉我。

https://www.intersystems.com/isc-resources/wp-content/uploads/sites/24/InterSystems-IRIS%E6%95%B0%E6%8D%AE%E5%B9%B3%E5%8F%B0%E5%AE%89%E8%A3%85%E6%8C%87%E5%8D%97-20200531.pdf 怎么访问不了呢，404 最新版安装指南请参考：Linux 系统IRIS安装总结 谢谢，我问下有虚拟机分区的部分，应该怎么分区呢 看您是什么操作系统，Linux的话可以用fdisk命令进行分区。

数据分集 （测试数据可以在网上下载 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 做了很多努力，例如在 SQL 查询中使用并行处理，以及在 IRIS中引入最具吸引力的特征：分片（sharding）。然而，许多成熟的开发成果最初是在 Caché中完成的，而且已经迁移到 IRIS 中。这些成熟的开发成果大都使用 DBMS（数据库管理系统）的多模型功能，实现在单独的数据库中共存不同的数据模型。例如， [HIS qMS](https://openexchange.intersystems.com/package/HIS-qMS) 数据库同时包含语义关系（电子病历）、传统关系（与 PACS 的交互）和层次数据模型（实验室数据以及与其他系统的集成）。这些数据模型大多是通过 [SP.ARM](https://openexchange.intersystems.com/company/SP-ARM) 的 qWORD 工具（一种直接访问 Global的小型数据库管理系统）实现的。遗憾的是，由于查询未使用 IRIS SQL，无法利用并行查询处理的新功能进行扩展。 而且，随着数据库规模的不断增长，大型关系型数据库所固有的大多数问题开始出现在非关系型数据库中。这就是我们关注可用于扩展的并行数据处理技术的一个主要原因。 在本文中，我将围绕多年来在解决任务时用到的并行数据处理展开多方位讨论，而这些是我在大数据问题探讨中很少提到的。我将重点讨论数据库的技术改造，或者更确切地说，是数据库转换技术。 众所周知，在系统开发的早期阶段（通常远远早于项目完成的时间）就已经选择好了数据模型、存储架构以及软件和硬件平台。但是在系统完成部署几年后，通常会因为这样或那样的原因需要对数据进行迁移。下面是一些常见的任务（所有示例均为真实案例）： 1. 一家公司正计划走向国际市场，必须将其 8 位编码的数据库转换为 Unicode 格式。 2. 将过时的服务器替换为新的服务器时，但是由于许可限制，无法在服务器之间进行日志的无缝传输（使用 IRIS 的系统功能 Mirroring 或 Shadowing），或者当在您尝试处理任务时，缺少满足如 1 提出的这种需求。 3. 你需要更改数据库之间的 Global 分配，例如将一个包含图像的较大的 Global 迁移到单独的数据库。 你可能会问，这些方案有那么难吗？只需要停止旧系统，导出数据，然后导入到新系统中就可以了。但是，如果你正在处理的是几百 GB（甚至几 TB）的数据库，而且系统在 7x24 运行，那么就无法使用标准的 IRIS 工具解决上述这些任务了。 ## 实现任务并行处理的基本方法 ### "垂直" 并行 假设可以将一个任务分解成几个组件。幸运的话，你会发现可以将其中一些并行解决。例如： - 准备报告数据（计算、数据聚合…） - 应用样式规则 - 打印报告 可以让多个报告同时执行所有操作：一个报告正处在准备阶段，同时另一个报告已经开始打印，等等。这种方法并不新鲜。早在 60 年前批量数据处理技术出现时，它就开始发挥作用了。虽然这不是一个新的概念，但是非常有用。然而，只有当所有子任务的执行时间具有可比性时，才会实现显著的加速效果，实际情况却并非总是如此。 ### "水平" 并行 当任务的操作顺序可以按任意顺序执行并迭代时，它们可以同时执行。例如： - 全局范围内的上下文搜索: - 把 Global 分解成多个部分（$order 作为首个索引）. - 分别对其进行搜索. - 合成搜索结果. - 通过套接字或 ECP 将 Global 传输到另一台服务器: - 把 Global 分解成几个部分. - 分别进行传输. 这些任务具有以下共同特点: - 相同的子任务处理过程（包括共享相同的参数）, - 最终结果的正确性不受子任务的执行顺序影响， - 生成结果报告的过程中不需要任何资源密集型操作，因此仅在此过程中子任务和“父”任务之间存在弱连接。 这些简单的示例表明，水平并行在数据转换任务中是常用到的，事实也的确如此。在接下来的内容中，我们将重点关注此类并行处理。 ## "水平" 并行 ### 方法之一：MapReduce MapReduce 是由谷歌引入的一种分布式计算模型。它在处理大量信息的同时也会执行此类操作。目前流行的开源项目构建在 [Apache Hadoop](https://ru.bmstu.wiki/Apache_Hadoop)和[Mahout](https:// ru.bmstu.wiki/apache_mahout) 的组合之上。 使用该模型的基本步骤：[映射](https://ru.bmstu.wiki/index.php?title=Map&action=edit&redlink=1)（在处理程序之间分配任务）、实际处理和[归约](https://ru.bmstu.wiki/index.php?title=Reduce&action=edit&redlink=1)（合并处理结果）。 对此感兴趣的读者如果想了解更多信息，我推荐 Timur Safin 的系列文章，他在[《Caché MapReduce——大数据和 MapReduce 概念简介》（第一部分）](https://community.intersystems.com/post/cach%C3%A9-mapreduce-introduction-bigdata-and-mapreduce-concept)中介绍了在 IRIS/Caché中创建MapReduce 工具的方法。 请注意，因为 IRIS 具有将数据快速写入数据库的"先天能力"，所以归约这一步通常是微不足道的，类似 [WordCount 分布式版本](https://community.intersystems.com/post/cach%C3%A9-mapreduce-putting-it-all-together-%E2%80%93-wordcount-example-part-iii#comment-14196)中的情况。在处理数据库转换任务时，可能完全没有必要进行这一步。例如，使用并行处理程序将一个大型的 Global 移动到单独的数据库，则不需要任何其他操作。 ### 需要多少台服务器? 并行计算模型的创建者（例如 MapReduce）通常将其扩展到多个服务器，即所谓的数据处理节点，但是在数据库转换任务中，通常一个这样的节点就足够了。事实上，连接多个处理节点（例如，通过企业缓存协议（ECP））是没有意义的，因为数据转换所需的 CPU 负载相对较小——这里不用考虑处理过程中的数据量。在这种情况下，初始数据仅使用一次，也就意味着无法通过分布式缓存带来任何性能提升。 经验表明，比较方便的做法是使用两个角色不对称的服务器。下面稍微进行一下简化: - 将源数据库安装在一台服务器（*源数据库*）上。 - 将转换后的数据库安装在第二台服务器（*目标数据库*）上。 - 只在其中一台服务器上配置水平并行数据处理；此服务器上的操作进程作为*主进程*执行。 - 相应的，在第二台服务器上运行的进程作为*从属进程*；在使用 ECP 时，这些是 DBMS 系统进程（ECPSrvR、ECPSrvW 和 ECPWork），而当使用面向套接字的数据传输机制时，这些是TCP 连接的子进程。 可以说，这种分配任务的方法结合了水平并行（用于在主服务器内分配负载）和垂直并行（用于在主服务器和从属服务器之间分配“职责”）。 ## 任务和工具 让我们思考一下最普通的数据库转换任务：将全部或部分数据从源数据库传输到目标数据库，同时可能对 Global 执行某种重新编码（可以是编码更改、排序规则的更改等等）。在这种情况下，新旧数据库是保存在本地的不同数据库服务器上的。下面列出的是架构师和开发人员需要解决的子任务： 1. 给服务器分配角色。 2. 选择数据传输机制。 3. 选择 Global 转移策略。 4. 选择在多个进程之间分配任务的工具。 接下来我们逐个进行分析。 ### 给服务器分配角色 众所周知，即使 IRIS 以 Unicode 方式安装，它也可以挂载 8 位数据库（本地和远程）。但反之则不行：8 位版本的 IRIS 无法支持 Unicode 数据库，否则会出现错误。在决定将哪个服务器（源服务器或目标服务器）作为主服务器时，必须考虑到数据转换过程中字符编码是否发生了更改。然而，想要决定最终的解决方案，还需要考虑下一个任务，那就是： ### 选择数据传输机制 你有以下几个选项: 1. 如果两台服务器上的许可证和 DBMS 版本均支持 ECP，则应选择 ECP 作为传输机制。 2. 如果不支持，最简单的解决方案就是在目标服务器上本地处理两个数据库（源数据库和目标数据库）。这时必须利用任何可用的文件传输工具将源数据库文件复制到适当的服务器。当然，这个过程将占用额外的时间（通过网络复制数据库文件）和空间（存储数据库文件的副本）。 3. 为了（至少）避免把时间浪费在复制文件上，你可以通过 TCP 套接字机制实现服务器进程之间的数据交换。这种方法支持以下情况: - 由于某些原因无法使用 ECP，例如，为源数据库和目标数据库提供服务的 DBMS 版本不兼容（比如源 DBMS 安装的是非常旧的版本）, - 或者：用户无法停止在源系统上工作，则源数据库在传输过程中发生的数据修改必须反映在目标数据库中。 在选择方法时，我的优先级非常明确：如果 ECP 可用，并且在传输期间源数据库保持静态，则选择方法 1；如果 ECP 不可用，但数据库保持静态，则选择方法 2；如果修改了源数据库，则选择方法 3。结合这些情况及主服务器的选择条件，我们可以生成如下可能性矩阵： | **传输期间源数据库是静态的吗?** | **ECP 协议是否可用?** | **源数据库的位置** | **主系统** | | --- | --- | --- | --- | | 是 | 是 | 目标系统远程 | 目标 | | 是 | 否 | 目标系统本地（副本） | 目标 | | 否 | 不重要，因为我们将使用TCP 套接字机制传输数据. | 源系统本地（原始） | 源| ### 选择 Global 转移策略 乍一看，似乎可以简单地通过读取全局目录逐个传递 Global。但是，同一个数据库中的Global 的大小可能相差很大：我最近遇到的一个生产数据库中的 Global 的大小范围在 1MB -600GB 之间。假设我们有多工作进程（nWorkers）可供使用，并且至少有一个 Global（Globals）^Big 符合下面条件： ^Big 的大小 >（所有^ Globals 的大小）/ nWorkers 然后，无论分布式 Global 转移过程中的其他任务完成的多么顺利，最终分配给^Big 的处理任务将一直保持忙碌，并且可能在其他进程完成之后很久才能完成其任务。如果想要改善这种情况，你可以预先按照大小对 Global 进行排序，并从最大的 Global 开始处理。但是如果^Big的大小明显偏离所有 Global 的平均值（这是 MIS qMS 数据库的典型情况）： ^Big 的大小 >>（所有^ Globals 的大小）/ nWorkers 这个策略不会提供太大的帮助，因为它必定会产生好几个小时的延迟。因此，需要将大型Global 拆分成多个部分，通过多个并行进程对其进行处理。我想强调的是，这个任务（列表中的第 3 项任务）是本文讨论的最难的任务，而且花费了我（而不是 CPU！）很多时间。 ### 选择在多个进程之间分配任务的工具 与并行处理机制进行交互的方式如下: - 创建一个后台工作进程池。 - 为这个后台工作进程池创建一个队列。 - 发起程序（我们称其为本地管理器）将工作单元放入队列（这是在步骤 3 中预先准备好的计划）。工作单元通常包括某类方法的名称和实际参数。 - 工作进程从队列中检索工作单元并执行处理，这里可以理解成调用了一个类方法，将实际参数传递给工作单元。 - 本地管理器在接收到队列中工作单元已处理完毕的确认信息后，将释放并按需结束这些工作进程。 幸运的是，IRIS 提供了一个非常适合该方案的、出色的并行处理引擎（可以通过%SYSTEM.WorkMgr 类实现）。我们将在运行的实例中应用改引擎，并在计划发表的系列文章中进行深入探讨。 在下一篇文章中，我将更加详细地阐述任务 3 的解决方案。 在第三篇文章中（如果大家对我的文章感兴趣的话），我将讨论任务 4 中的细微差别，包括%SYSTEM.WorkMgr 的局限性及其解决方案。

去年，AWS推出了基于ARM架构的AWS Graviton处理器第一代Amazon EC2 A1实例。在2019年AWS re:Invent 大会上，亚马逊宣布了第二代AWS Graviton2处理器和相关的Amazon EC2 M6g实例。相比前一代基于Intel Xeon的M5实例，Amazon EC2 M6g实例的性价比提升幅度高达40%。基于AWS Gravity 2的M6g实例现已推出预览版，InterSystems借此机会利用InterSystems IRIS数据平台对其性能进行了评估。InterSystems很高兴地宣布，我们取得了令人印象深刻的结果，并在2020年实现支持基于ARM架构的AWS Graviton2处理器的Amazon EC2实例！ 我们测试了两种不同的工作负载，它们代表着InterSystems IRIS客户群体的常见用例。第一个工作负载是基于InterSystems IRIS数据平台的金融应用程序的纯数据接收。第二个是基于InterSystems IRIS医疗版的医疗互操作性工作负载。我们对比了Amazon EC2 M6g和M5在每种工作负载下的性能表现。 工作负载#1：InterSystems IRIS数据平台上的数据接收吞吐量 我们测试了相同的工作负载，以便在InterSystems IRIS上模拟纽约证交所在两节点分片集群上运行的数据处理（下单/成交）。该基准测试比较了m5.2xlarge和基于AWS Graviton2的m6g.2xlarge Amazon EC2实例之间的性能表现。每个实例均具有8个vCPU和32GB RAM，唯一的配置差异是处理器和AMI操作系统镜像。所对比的系统配置具有相同的EBS卷、iops、VPC配置和IRIS参数（例如全局缓冲区），且均使用了InterSystems IRIS的预发布版本IRIS-2020.1.0L.188.0-lnxrharm64和IRIS-2020.1.0L.188.0-lnxrh64。 结果显示，m5.2xlarge系统平均每秒处理9.8万条记录，而m6g.2xlarge每秒处理大约12万条记录。在相同数量的vCPU上，后者的性能提高了20%以上！ 工作负载#2：InterSystems IRIS 医疗版上的医疗互操作性吞吐量 我们测试了相同的工作负载，以便在InterSystems IRIS医疗版互操作性技术框架上模拟HL7消息接收、路由和转换。该基准测试对m5.2xlarge和m6g.2xlarge（均具有8个vCPU和32GB RAM）进行了比较。除处理器以外，二者其余配置完全相同，且均在InterSystems IRIS（2020.1）的预发布版本上进行测试。我们同样针对基于第一代AWS Graviton处理器的A1实例进行了测试，以展示AWS Graviton2在性能上的飞跃。结果如下： 左侧轴是衡量此工作负载性能的主要指标，即应用程序每秒处理的消息数。x轴表示基准驱动向应用程序传输的不断增加的消息。从左向右，应用的工作负载不断增加，首先将入站接口的数量增加到16个，然后在保持稳定的情况下增加每秒消息数量。上图中的列则表示在右侧轴上测得的CPU利用率，当CPU利用率接近100%时，可以看到每种实例的最大容量。 正如大家所看到的，基于AWS Graviton2的M6g实例是线性扩展，并且在高工作负载下明显优于M5实例。在相同的工作负载下，M6g实例保持较低的CPU利用率，并在M5实例达到CPU最大利用率后仍可以继续扩展。与相同大小的M5实例相比，M6g实例的消息吞吐量最终提高了约28%。AWS Graviton2处理器以显著优势胜出！ 性价比 通过比较基于AWS Graviton2的M6g和相同大小的M5实例，可以发现前者除了明显的性能提升外，还具有价格优势——与当前的Amazon EC2 M5实例相比，Amazon EC2 M6g实例的成本降低了20%： m5.2xlarge按需：每小时0.384美元 m6g.2xlarge按需：每小时0.308美元 结论 InterSystems致力于为客户提供选择平台的自由。我们很高兴地看到，AWS Graviton2处理器将为InterSystems IRIS客户带来显著的性能提升，并为客户降低成本。我们相信这些综合优势将推动ARM平台在IRIS客户中的广泛应用，我们很高兴可以为此提供支持！ 更多资源 https://aws.amazon.com/ec2/graviton/ https://aws.amazon.com/ec2/instance-types/m6/ https://www.intersystems.com/products/intersystems-iris/ 注：本文为译文，欢迎点击查看原文，原文由Steven LeBlanc撰写 @LU.WANG @na.liu 这个版本的IRIS 我们能发货吗？

这是“IRIS数据库在医疗行业发展”系列课程的第一讲，InterSystems中国技术总监乔鹏为您介绍InterSystems IRIS架构。InterSystems IRIS数据平台是全球首款且唯一一款专门设计用于从医疗数据中提取价值的数据平台。

这是“IRIS数据库在医疗行业发展”系列课程的第二讲，InterSystems中国技术总监乔鹏为您介绍InterSystems IRIS强大的分析能力。InterSystems IRIS数据平台是全球首款且唯一一款专门设计用于从医疗数据中提取价值的数据平台。

这是“IRIS数据库在医疗行业发展”系列课程的第三讲，InterSystems中国技术总监乔鹏为您介绍InterSystems IRIS独立组件。InterSystems IRIS数据平台是全球首款且唯一一款专门设计用于从医疗数据中提取价值的数据平台。