搜索​​​​

亲爱的社区用户，大家好！ InterSystems多模型数据库竞赛 已圆满结束，感谢大家积极参加这次编程马拉松！ 现在，我们来宣布此次竞赛优胜者！ 下面这些开发者及其开发的应用值得拥有雷鸣般的掌声！！！ 🏆专家提名奖（Experts Nomination） - 获奖者由我们特别挑选的专家团选出: 🥇 第一名，$2,000 的获奖者 @José.Pereira ，提交项目为：iris-image-index-demo 🥈 第二名，$1,000 的获奖者@MikhailenkoSergey ，提交的项目为： zapm 🥉 第三名， $500 的获奖者 @Renato.Banzai ，提交的项目为： iris-multimodel-suite 🏆 社区提名奖（Community Nomination） - 获得总投票数最多的应用： 🥇 第一名，$1,000的获奖者@Botai.Zhang ，提交的项目为： HealthInfoQueryLayer 🥈 第二名，$500 的获奖者 @Henrique ，提交的项目为： iris-vaccine-tracker 🥉 第三名，$250 的获奖者@José.Pereira ，提交的项目为： iris-image-index-demo 恭喜所有获奖用户！ 感谢您对本次大赛的关注，感谢您在这场令人兴奋的编程大赛中付出的努力！ 接下来呢？ 我们的 InterSystems 编程大奖赛！ 已经开始了 奖金总额: $16,000 加入大奖赛，不见不散哦😉 热烈恭喜@Botai Zhang！

本帖将展示为 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 已被遗忘，我们现在可以在单台服务器上大幅提高应用事务处理速率。 Caché 的一个关键特性是我们在共享内存（通常称为数据库缓存或 global 缓冲区）中使用数据的方式。 简单地说，如果适当调整 global 缓冲区的大小并为其分配“更多”内存，通常会提高系统性能 - 访问内存中的数据要比访问磁盘上的数据快得多。 当年，当 32 位系统占主导地位时，对问题_我应该为 global 缓冲区分配多少内存？_的回答很简单 - _尽可能多！_反正也没有很多内存可用，所以人们努力计算操作系统需求、操作系统和 Caché 进程的数量和大小以及每个进程使用的实际内存，以找到剩余的内存来分配尽可能大的 global 缓冲区。 ## 趋势已经转变 如果您在当代服务器上运行应用程序，可以为 Caché 实例分配大量内存，并且由于内存现在既“便宜”又充足，因此通常放任其使用。 然而，趋势再次转变，除了最大型的系统，现在部署的几乎所有系统都是虚拟化的。 所以，虽然在需要时可以为“怪兽”虚拟机分配大量内存，但重点仍然回到适当调整系统规模上。 为了最大程度地利用服务器整合，需要进行容量计划以充分利用可用主机内存。 # 什么在使用内存？ 通常，Caché 数据库服务器上有四个主要的内存消耗者： * 操作系统，包括文件系统缓存。 * 其他非 Caché 应用程序（如果已安装）。 * Caché 进程。 * Caché 共享内存（包括 global 和例程缓冲区以及 GMHEAP）。 从高级别看，所需的物理内存量只是将列表上每一项的需求都加起来。 上面的所有项目都使用实际内存，但它们也可以使用虚拟内存，容量计划的一个关键部分是将系统规模调整为有足够的物理内存，使分页不会发生或尽量少发生，或者至少尽量减少或消除必须从磁盘恢复内存的硬页面故障。 在本帖中，我将重点介绍 Caché 共享内存的大小调整以及优化内存性能的一些通用规则。 操作系统和内核的要求因操作系统而异，但大多数情况下为几个 GB。 文件系统缓存视情况而定，将是列表上其他项目获得内存分配之后的其余任何可用内存。 Caché 主要是进程 - 如果在应用程序运行时查看操作系统统计信息，则会看到缓存进程（例如 cache 或 cache.exe）。 因此，观测应用程序内存要求的一个简单方法是查看操作系统指标。 例如，通过 Linux 上的 `vmstat` 或 `ps` 或者 `Windows 进程资源管理器`，以及使用中的实际内存总量，推断出增长需求和峰值需求。 请注意，某些指标会报告包含共享内存的虚拟内存，因此收集实际内存需求时务必小心。 ## 调整 global 缓冲区大小 - 一种简化的方法 对于高事务数据库，容量计划的目标之一是将 global 缓冲区的大小调整为使内存中容纳尽可能多的应用数据库工作集。 这将最大程度地减少读取 IOPS，并且通常会使应用程序的性能更好。 我们还需要取得平衡，使其他内存用户（如操作系统和 Caché 进程）不会被移出分页，并且有足够的内存用于文件系统缓存。 我在[本系列的第 2 部分](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-–-part-2)中展示了一个示例，来说明如果对磁盘过度读取会发生什么情况。在该示例中，高读取数是由不良的报告或查询引起的，但是如果 global 缓冲区太小而迫使应用程序不断从磁盘读取数据块，则会产生同样的效果。 另外，值得注意的是，存储的格局一直在变化 - 随着固态硬盘技术的进步，存储速度越来越快，但靠近运行中的进程的内存数据仍然是最好的。 当然，每个应用程序都是不同的，所以必须指出__“您的情况可能有所不同”__，但有一些通用规则可以帮助您开始为应用程序的共享内存制定容量计划。 之后，您可以根据您的具体要求进行调整。 ### 从哪里开始？ 很遗憾，并没有万能答案。但是，正如我在之前的帖子谈到的，一个好的做法是确定系统 CPU 容量规模，使得在达到所需峰值事务处理速率的情况下，峰值处理期间的 CPU 使用率为大约 80%。 为短期增长或意外的活动激增留出 20% 余量。 例如，当我调整 TrakCare 系统的规模时，我通过基准测试和查看客户站点指标来了解已知事务处理速率的 CPU 要求，并且可以针对基于英特尔处理器的服务器使用普遍性的经验法则： `经验法则：`每个 CPU 核心对应 _n_ GB 大小的物理内存。 - 对于 TrakCare 数据库服务器，_n_ 为 8 GB。 对于小型 Web 服务器则为 4 GB。 `经验法则：`为 Caché global 缓冲区分配 _n_% 的内存。 - 对于中小型 TrakCare 系统，_n_% 为 60%，其余 40% 的内存留给操作系统、文件系统缓存和 Caché 进程。 如果您需要许多文件系统缓存或有许多进程，可以更改该值，例如改为 50%。 或者，在大型系统上使用超大内存配置时，将其调整为更高的百分比。 - 此经验法则假定服务器上只有一个 Caché 实例。 所以如果应用程序需要 10 个 CPU 核心，则虚拟机将有 80 GB 内存，其中 48 GB 为 global 缓冲区，32 GB 用于其他所有用途。 内存大小调整规则适用于物理或虚拟化系统，因此对于 TrakCare 虚拟机，1 vCPU : 8 GB 内存的比例同样适用。 ### 调整 global 缓冲区 要查看规模调整的效果如何，需要观察几个项目。 您可以使用操作系统工具观察 Caché 之外的可用内存。 根据最佳计算结果进行设置，然后观察一段时间内的内存使用情况，如果一直有可用内存，则可以重新配置系统以增加 global 缓冲区或适当调整虚拟机规模。 global 缓冲区大小调整适当的另一个关键指标是读取 IOPS 尽可能低 - 这意味着 Caché 缓存效率会很高。 您可以使用 mgstat 观察不同的 global 缓冲区大小对 PhyRds 和 RdRatio 的影响，[本系列的第 2 部分](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-–-part-2)提供了查看这些指标的示例。除非您的整个数据库都在内存中，否则总会有一些对磁盘的读取，目的只是保持尽可能低的读取数。 请记住您的硬件食物群并做好平衡 - 为 global 缓冲区分配更多内存会降低读取 IOPS，但可能会提高 CPU 使用率，因为您的系统现在可以在更短时间内完成更多工作。不过降低 IOPS 终归是好事，您的用户会因为更快的响应时间而更满意。 _有关如何将您的要求应用于__物理内存__，请参见下面的部分。 _ 对于虚拟服务器计划，_不要_超额预定生产虚拟机内存，_尤其是 Caché 共享内存_，更多信息也请参见下文。 您的应用程序甜蜜点是每 CPU 核心 8GB 物理内存吗？ 我说不准，但要看是否有相似的方法适合您的应用程序。 不管每核心 4GB 还是 10GB， 如果您找到了另一种调整 global 缓冲区大小的方法，请在下面留下评论。 ### 监视 Global 缓冲区使用情况 Caché 实用工具 `^GLOBUFF` 可显示 global 缓冲区在任意时间点的使用情况统计。 例如，按百分比显示前 25 名： do display^GLOBUFF(25) 例如，输出可能如下所示： Total buffers: 2560000 Buffers in use: 2559981 PPG buffers: 1121 (0.044%) Item Global Database Percentage (Count) 1 MyGlobal BUILD-MYDB1 29.283 (749651) 2 MyGlobal2 BUILD-MYDB2 23.925 (612478) 3 CacheTemp.xxData CACHETEMP 19.974 (511335) 4 RTx BUILD-MYDB2 10.364 (265309) 5 TMP.CachedObjectD CACHETEMP 2.268 (58073) 6 TMP CACHETEMP 2.152 (55102) 7 RFRED BUILD-RB 2.087 (53428) 8 PANOTFRED BUILD-MYDB2 1.993 (51024) 9 PAPi BUILD-MYDB2 1.770 (45310) 10 HIT BUILD-MYDB2 1.396 (35727) 11 AHOMER BUILD-MYDB1 1.287 (32946) 12 IN BUILD-DATA 0.803 (20550) 13 HIS BUILD-DATA 0.732 (18729) 14 FIRST BUILD-MYDB1 0.561 (14362) 15 GAMEi BUILD-DATA 0.264 (6748) 16 OF BUILD-DATA 0.161 (4111) 17 HISLast BUILD-FROGS 0.102 (2616) 18 %Season CACHE 0.101 (2588) 19 WooHoo BUILD-DATA 0.101 (2573) 20 BLAHi BUILD-GECKOS 0.091 (2329) 21 CTPCP BUILD-DATA 0.059 (1505) 22 BLAHi BUILD-DATA 0.049 (1259) 23 Unknown CACHETEMP 0.048 (1222) 24 COD BUILD-DATA 0.047 (1192) 25 TMP.CachedObjectI CACHETEMP 0.032 (808) 这在几个方面很有用，例如，查看有多少工作集保留在内存中。 如果你觉得此实用工具很有用，请在下面发表评论，让其他社区用户了解它为什么对您有帮助。 ## 调整例程缓冲区大小 应用程序运行的例程（包括编译的类）存储在例程缓冲区中。 调整例程缓冲区共享内存大小的目标是让所有例程代码都在例程缓冲区中加载并驻留。 与 global 缓冲区一样，从磁盘读取例程的成本很高且效率低下。 例程缓冲区的最大大小为 1023 MB。 一般来说，您希望获得的例程缓冲区比需要的多，因为将例程缓存总是可以大幅提高性能。 例程缓冲区由不同大小的缓冲区组成。 默认情况下，Caché 确定每种大小的缓冲区数量，在安装时，2016.1 的默认缓冲区为 4、16 和 64 KB。 可以更改不同大小的内存分配，但是要开始容量计划，建议保持 Caché 默认值，除非您有特殊原因需要进行更改。 有关更多信息，请参见 [Caché 文档](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RCPF_routines)中的《Caché 参数文件参考》的“config”附录中的 routines，以及《Caché 系统管理指南》的“配置 Caché”一章中的“内存和启动设置”。 应用程序运行时，例程从磁盘加载，并存储在可容纳该例程的最小缓冲区中。 例如，如果某个例程为 3 KB，理想情况下将存储在一个 4 KB 缓冲区中，如果没有可用的 4 KB 缓冲区，则使用更大的缓冲区。 大于 32 KB 的例程将根据需要使用多达 64 KB 的例程缓冲区。 ### 检查常规缓冲区的使用 #### mgstat 指标 RouLas 了解例程缓冲区是否足够大的一个方法是 mgstat 指标 RouLas（例程加载次数和保存次数）。 一个 RouLas 是指从磁盘获取或保存到磁盘一次。 例程的加载/保存次数多可能表示存在性能问题，在这种情况下，可以增加例程缓冲区数量来提高性能。 #### cstat 如果您已将例程缓冲区增加到最大值 1023 MB，但仍然发现 RouLas 很高，那么可以使用 `cstat` 命令进行更详细的检查，以了解缓冲区中有哪些例程以及它们使用了多少内存。 ccontrol stat cache -R1 这将生成一个例程指标列表，其中包括例程缓冲区列表和缓存中的所有例程。 例如，默认安装 Caché 后，该列表的一部分如下所示： Number of rtn buf: 4 KB-> 9600, 16 KB-> 7200, 64 KB-> 2400, gmaxrouvec (cache rtns/proc): 4 KB-> 276, 16 KB-> 276, 64 KB-> 276, gmaxinitalrouvec: 4 KB-> 276, 16 KB-> 276, 64 KB-> 276, Dumping Routine Buffer Pool Currently Inuse hash buf size sys sfn inuse old type rcrc rtime rver rctentry rouname 22: 8937 4096 0 1 1 0 D 6adcb49e 56e34d34 53 dcc5d477 %CSP.UI.Portal.ECP.0 36: 9374 4096 0 1 1 0 M 5c384cae 56e34d88 13 908224b5 %SYSTEM.WorkMgr.1 37: 9375 4096 0 1 1 0 D a4d44485 56e34d88 22 91404e82 %SYSTEM.WorkMgr.0 44: 9455 4096 0 0 1 0 D 9976745d 56e34ca0 57 9699a880 SYS.Monitor.Health.x 2691:16802 16384 0 0 7 0 P da8d596f 56e34c80 27 383da785 START etc etc 上面第 2 行中的“rtns/proc”表示，默认情况下，每种大小的缓冲区可以缓存 276 个例程。 使用此信息来调整例程缓冲区大小的另一种方法是，运行应用程序并使用 cstat -R1 列出正在运行的例程。 然后可以计算使用中的例程大小，例如将此列表放在 Excel 中，按大小排序，并精确地查看有哪些例程正在使用中。 如果每种大小的缓冲区没有被全部使用，则说明有足够的例程缓冲区，或者如果每种大小的缓冲区都已全部使用，则需要增加例程缓冲区，或者可以更直接地配置每个存储桶的大小。 ## 锁表大小 locksiz 配置参数是为管理并发控制锁而分配的内存大小（以字节为单位），该锁用于防止不同的进程同时更改一个特定的数据元素。 在内部，内存中的锁表包含当前锁，以及持有这些锁的进程的信息。 由于用于分配锁的内存取自 GMHEAP，所以用于锁的内存不能超过 GMHEAP 中的内存。 如果增加 locksiz 的大小，请按照下面 GMHEAP 部分中的公式增加 GMHEAP 的大小以进行匹配。 有关应用程序使用锁表的信息可以使用系统管理门户 (SMP) 进行监视，或者更直接地使用 API 来监视： set x=##class(SYS.Lock).GetLockSpaceInfo()。 该 API 返回三个值：“可获空间、可用空间、已用空间”。 检查可用空间和已用空间可粗略计算合适的值（某些锁空间为锁结构预留）。 更多信息，请参见 [Caché 文档](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RCPF_locksiz)。 注：如果编辑 locksiz 设置，更改会立即生效。 ## GMHEAP GMHEAP（通用内存堆）配置参数定义为：Caché 的通用内存堆的大小（以 KB 为单位）。 锁表、NLS 表和 PID 表也是根据它来进行分配的。 注：更改 GMHEAP 需要重启 Caché。 为了帮助您确定应用规模，可以使用 API ​​来检查 GMHEAP 的使用信息： %SYSTEM.Config.SharedMemoryHeap 该 API 还提供获取可用的通用内存堆的功能，并推荐了用于配置的 GMHEAP 参数。 例如，`DisplayUsage` 方法显示每个系统组件使用的所有内存以及可用堆内存的数量。 更多信息，请参见 [Caché 文档](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RCPF_gmheap#RCPF_B172591)。 write $system.Config.SharedMemoryHeap.DisplayUsage() 要了解任何时间点的 GMHEAP 使用情况和建议，可以使用 `RecommendedSize` 方法。 但是，您将需要多次运行该方法才能为系统建立基线和建议。 write $system.Config.SharedMemoryHeap.RecommendedSize() `经验法则：`再次说明，您的应用情况会有所不同，但仍可以使用以下选项之一来开始调整大小： （最小 128MB）或（64 MB * 核心数）或（2 倍 locksiz）或采用其中较大者。 记住，必须调整 GMHEAP 的大小以包括锁表。  # 大页内存 Mark Bolinsky 写了一篇非常好的帖子，解释了为什么[在 Linux 中开启大页内存可大幅提高性能](https://community.intersystems.com/post/linux-transparent-hugepages-and-impact-caché)。 ## 危险！ Windows 大页内存和共享内存 Caché 在所有平台上的所有版本都使用共享内存，它可以大幅提高性能，包括在 Windows 中也总是使用，但您需要注意一些特定于 Windows 的问题。 Caché 在启动时会分配一大块共享内存，用于数据库缓存（global 缓冲区）、例程缓存（例程缓冲区）、共享内存堆、日志缓冲区和其他控制结构。 在 Caché 启动时，可以使用小页或大页来分配共享内存。 在 Windows 2008 R2 及更高版本中，Caché 默认使用大页，但如果系统已长时间运行，由于内存已碎片化，可能无法在 Caché 启动时分配连续内存，Caché 可能会改用小页。 意外地以小页启动 Caché 可导致 Caché 启动时的共享内存小于配置中定义的值，或者 __Caché 可能需要很长时间才能启动或启动失败__。 我在具有故障转移集群的站点上看到过这种情况，这些站点中的备份服务器已经很长时间没有用作数据库服务器了。 ` 提示：`一种缓解策略是定期重启离线的 Windows 集群服务器。 另一个策略是使用 Linux。 # 物理内存 物理内存取决于处理器的最佳配置。 不良的内存配置可能会严重影响性能。 ## 英特尔内存配置最佳实践 以下信息只适用于__英特尔__处理器。 请与供应商确认哪些规则适用于其他处理器。 决定 DIMM 最优性能的因素包括： - DIMM 类型 - DIMM rank - 时钟速度 - 相对于处理器的位置（最近/最远） - 内存通道数 - 所需的冗余功能。 例如，在 Nehalem 和 Westmere 服务器（至强 5500 和 5600）上，每个处理器有三个内存通道，因此应以三个为一组的方式安装内存。 对于当前处理器（例如 E5-2600），每个处理器有四个内存通道，因此应以四个为一组的方式安装内存。 当存在不平衡的内存配置时（没有以三个/四个为一组的方式安装内存，或者内存 DIMM 的大小不同），不平衡的内存可能导致 23% 的内存性能损失。 请记住，Caché 的特点之一是在内存中进行数据处理，因此获得最佳的内存性能很重要。 另外值得注意的是，为了获得最大带宽，应该为服务器配置最快的内存速度。 对于至强处理器，只有每通道多达 2 条 DIMM 时才支持最大内存性能，因此对于常见的具有 2 个 CPU 的服务器来说，最大内存配置取决于包括 CPU 频率和 DIMM 大小（8GB、16GB 等）在内的因素。 `经验法则：` - 使用平衡的平台配置：为每个通道和每个插槽填充相同数量的 DIMM - 在整个平台中使用相同的 DIMM 类型：相同的大小、速度和 rank 数。 - 对于物理服务器，根据这些英特尔处理器最佳实践，将主机服务器的物理内存总数四舍五入到自然断点 - 64GB、128GB 等。 # VMware 虚拟化注意事项 我会在将来另写一篇帖子来继续介绍虚拟化 Caché 的更多准则。 不过，内存分配应考虑以下关键规则： `规则：`在生产系统上设置 VMware 内存预留。 如上文所述，Caché 在启动时会分配一大块共享内存，用于 global 和例程缓冲区、GMHEAP、日志缓冲区和其他控制结构。 您想要避免任何共享内存交换，所以将_生产数据库虚拟机_内存预留设置为至少是 Caché 共享内存的大小加上 Caché 进程和操作系统及内核服务的内存。 如果有疑问，请预留全部生产数据库虚拟机内存。 一般来说，如果在相同系统上混合使用生产服务器和非生产服务器，则不要在非生产系统上设置内存预留。 让非生产服务器争夺剩下的内存 ;)。 VMware 通常将具有 8 个以上 CPU 的虚拟机称为“怪兽虚拟机”。 高事务 Caché 数据库服务器通常是怪兽虚拟机。 在怪兽虚拟机上设置内存预留还有其他考虑因素，例如，如果要迁移某个怪物虚拟机进行维护，或者由于高可用性触发重启，那么目标主机服务器必须有足够的可用内存。 我会在将来的帖子中讨论这方面的计划策略，以及其他内存考虑因素，如计划充分利用 NUMA。 # 总结 这是对内存进行容量计划（一个混乱的领域）的开始，当然不像调整 CPU 规模那样明确。 如果您有任何疑问或意见，请留下评论。 发布本帖后，我将去参加 Global Summit 2016。 如果您今年也参加，欢迎观看我的两场关于性能主题的演讲，我也很乐意在开发者区域与您当面交流。

本周，我将关注 CPU - 主要硬件食物群之一 :) 一位客户请我就以下情况提供建议：他们的生产服务器已接近使用寿命终止，是时候更新硬件了。 他们还考虑通过虚拟化来整合服务器，并希望适当调整裸机或虚拟机的容量规模。 今天我们将关注 CPU，在后面的帖子中，我将介绍适当调整其他主要食物群（内存和 IO）规模的方法。 所以问题是： - 如何将五年多以前对处理器的应用要求转换成针对当今的处理器？ - 目前的处理器有哪些是合适的？ - 虚拟化如何影响 CPU 容量计划？ 2017 年 6 月添加： 要深入了解 VMware CPU 注意事项和规划的细节，以及一些常见问题，另请查看以下帖子：[虚拟化大型数据库 - VMware cpu 容量计划](https://community.intersystems.com/post/virtualizing-large-databases-vmware-cpu-capacity-planning) [本系列其他帖子的列表](https://cn.community.intersystems.com/post/intersystems-数据平台的容量规划和性能系列文章) # 使用 spec.org 基准比较 CPU 性能 要针对使用 InterSystems 数据平台（Caché、Ensemble、HealthShare）构建的应用程序在不同的处理器类型之间转换 CPU 使用率，可以使用 SPECint 基准作为可靠标准，来粗略计算处理器之间的伸缩性。 [http://www.spec.org](http://www.spec.org) 网站提供了一套标准化基准测试的可信结果，这些测试由硬件供应商运行。 具体来说，SPECint 是一种在同一供应商的不同处理器型号之间以及在不同供应商（例如戴尔、惠普、联想以及英特尔、AMD、IBM POWER 和 SPARC）之间比较处理器的方法。 当需要升级硬件时，或者要将您的应用部署在一系列不同的客户硬件上，而您需要为规模调整指标设置基准（例如英特尔至强 E5-2680 或所选任何处理器的每个 CPU 核心的峰值事务数）时，可以使用 SPECint 来了解您的应用的预期 CPU 要求。 SPECint 网站上使用了多个基准，不过 **SPECint_rate_base2006** 结果最适合 Caché，而且根据多年的客户数据研究和我们自己的基准测试，这一点已得到确认。 在本帖的示例中，我们将比较客户的戴尔 PowerEdge 服务器（运行英特尔至强 5570 处理器）与当前的戴尔服务器（运行英特尔至强 E5-2680 V3 处理器）之间的差异。 当英特尔至强 V4 服务器处理器普遍可用（本帖写于 2016 年初，预计很快就会上市）时，可以应用同样的方法。 ## 示例：比较处理器 在 spec.org 的 __SPECint2006_Rates__ 数据库中搜索处理器名称，例如 __E5-2680 V3__，如果目标服务器品牌和型号已知（例如戴尔 R730），可以进一步优化搜索结果，否则请使用流行的供应商。我发现戴尔或惠普的型号是很好的标准服务器基准，不同供应商硬件上的处理器之间通常不会有太大差异。 > 在本帖的最后，我逐步演示了一个使用 spec.org 网站搜索结果的示例。 假设您已搜索 spec.org，并找到现有服务器和一个可能的新服务器，如下所示： 现有：戴尔 PowerEdge R710，搭载至强 5570 2.93 GHz：8 个核心，双芯片，4 个核心/芯片，2 个线程/核心： __SPECint_rate_base2006 = 251__ 新服务器：PowerEdge R730，搭载英特尔至强 E5-2680 v3，2.50 GHz：24 个核心，双芯片，12 个核心/芯片，2 个线程/核心： __SPECint_rate_base2006 = 1030__ 不出所料，新 24 核服务器的 SPECint_rate_base2006 基准吞吐量是旧 8 核服务器的 4 倍以上，即使新服务器的时钟速度较低。 请注意，示例中的两台双处理器服务器均已插满处理器插槽。 ### 为什么对 Caché 使用 SPECint_rate_base2006？ spec.org 网站上有各种基准的解释，但总结起来就是 **SPECint_rate2006** 基准是一个完整的系统级基准，通过超线程使用所有 CPU。 对于具体的 SPECint_rate2006 基准，会报告两个指标：_base_ 和 _peak_。 base 是保守的基准，peak 则更为激进。 要进行容量计划，请使用 __SPECint_rate_base2006__ 结果。 ## 四倍的 SPECint_rate_base2006 是否意味着四倍的用户或事务容量？ 如果全部 24 个核心均被使用，应用吞吐量可能会扩展为旧服务器容量的四倍。 不过，有几个因素可能会导致不同情况。 SPECint 将提供大致可能的规模和吞吐量结果，但有几点注意事项。 在上面的示例中，虽然 SPECint 给出了两台服务器之间的明确比较，但并不保证 E5-2680 V3 服务器的峰值并发用户容量或峰值事务吞吐量比基于至强 5570 的旧服务器多 75%。 其他因素也会起作用，例如食物群中的其他硬件组件是否已升级，新存储或现有存储是否能满足吞吐量的增长（我很快会写一篇深入探讨存储的帖子）。 根据我对 Caché 进行基准测试的经验和对客户性能数据的研究，随着计算资源（CPU 核心）的增加，__在单台服务器上，Caché 能够线性扩展到极高的吞吐率__，而且 Caché 每年都在改进，性能会进一步提高。 换句话说， 随着 CPU 核心的增加，最大应用吞吐量（例如，应用事务数或 Caché gloref 中反映的值）会线性扩展。 但是，如果存在应用瓶颈，它们可能在较高的事务处理速率下出现，并影响线性扩展。 在以后的帖子中，我将介绍在哪里查找应用瓶颈的症状。 要提高应用性能，最好的方法之一是将 Caché 升级到最新版本。 > **注：**Caché 不支持具有超过 64 个逻辑核心的 Windows 2008 服务器。 例如，40 核服务器必须禁用超线程功能。 对于 Windows 2012，支持多达 640 个逻辑处理器。 Linux 上没有任何限制。 ## 应用需要多少个核心？ 应用各不相同，并且您知道自己的应用情况，但在为服务器（或虚拟机）规划 CPU 容量时，我常用的方法是通过连续的系统监视来了解某个“标准”处理器的特定数量的 CPU 核心可以维持的峰值事务速率：每分钟 _n_ 个事务。 这些事务可能是情节、遭遇、实验室测试或您的世界中任何有意义的事情。 重点是，标准处理器的吞吐量基于您在当前系统或客户系统上收集的指标。 如果您知道已知的具有 _n_ 个核心的处理器当前的峰值 CPU 资源使用情况，您可以使用 SPECint 结果将其转换为较新或不同的处理器实现相同事务处理速率所需的核心数量。 如果预期的线性扩展结果是每分钟 2 x _n_ 个事务数，则大致相当于需要 2 倍的核心数量。 ## 选择处理器 正如您从 spec.org 网站或从首选供应商产品中所见，有许多处理器选择。 本示例中的客户对英特尔很满意，因此如果我坚持推荐当前的英特尔服务器，那么一种方法是力求“物有所值”- 或者每美元和每核心的 SPECint_rate_base2006 分数。 例如，下图绘制了戴尔商用服务器的性能价格图表，您的价格表可能有所不同，但这说明在价格和适合使用虚拟化整合服务器的高核心数中存在着甜蜜点。 我是通过先确定生产服务器（例如戴尔 R730）的价格，然后查看不同的处理器选项来制作这份图表的。  根据图表中的数据和客户站点的经验，E5-2680 V3 处理器显示出良好的性能以及按 SPECint 或按核心计算的出色价格点。 其他因素也在起作用，例如，如果您正在寻找用于虚拟化部署的服务器处理器，以更高的成本增加每个处理器的核心数可能反而更实惠，因为这样做的效果是减少了支持所有虚拟机所需的主机服务器总数，从而节省了按处理器插槽进行授权的软件（例如 VMware 或操作系统）成本。 您还必须根据高可用性 (HA) 要求来平衡主机数量。 我将在以后的帖子中重新讨论 VMware 和 HA。 例如，由三台 24 核主机服务器组成的 VMware HA 集群可提供良好的可用性和强大的处理能力（核心数），允许运行各种灵活配置的生产和非生产虚拟机。 请记住，VMware HA 的规模是 N+1 台服务器，因此三台 24 核服务器相当于总共 48 个核心可用于虚拟机。 ## 核心数与 GHz - 哪个更适合 Caché？ 如果在更快的 CPU 核心与更多的 CPU 核心之间进行选择，您应该考虑以下几点： - 如果您的应用需要许多 cache.exe 线程/进程，那么更多核心将允许更多线程/进程同时运行。 - 如果您的应用进程较少，您希望每个进程都尽可能快地运行。 另一种考虑方式是，如果您的客户端/服务器应用有许多进程，假设每个并发用户一个（或多个），那么您需要更多可用核心。 对于使用 CSP 的基于浏览器的应用程序，用户被绑定到数量较少但非常繁忙的 CSP 服务器进程，那么您的应用程序将受益于数量可能较少但速度更快的核心。 在理想情况下，假设当多个 cache.exe 进程在所有核心中同时运行时没有资源争用，则两种应用程序类型都将受益于多个快速核心。 上文已叙述，但值得重申的是，每个 Caché 版本在 CPU 资源使用方面都有改进，因此将应用程序升级到最新版的 Caché 确实可以从更多的可用核心中受益。 另一个关键考虑事项是在使用虚拟化时最大程度地增加每个主机的核心数。 单个虚拟机的核心数量可能不高，但综合来看，您必须在可用性所需的主机数量与最大程度地减少主机数量（为了管理和成本考虑，通过增加核心数量来实现）之间取得平衡。 ## VMware 虚拟化和 CPU 在配合使用当前服务器和存储组件的情况下，VMware 虚拟化很适合 Caché。 通过遵循与物理容量计划相同的规则，在正确配置的存储、网络和服务器上使用 VMware 虚拟化不会有明显的性能影响。 较新型号的英特尔至强处理器对虚拟化的支持更好，具体来说，您只应考虑在英特尔至强 5500 (Nehalem) 及更高版本（即英特尔至强 5500、5600、7500、E7 系列和 E5 系列）上进行虚拟化。 --- # 示例：硬件更新 - 计算最低 CPU 要求 如果我们考虑这样一个示例：对在具有 8 个核心（两个 4 核至强 5570 处理器）的戴尔 PowerEdge R710 上运行的工作负载进行服务器升级，那么将上述提示和程序结合在一起。 通过绘制客户的主生产服务器的当前 CPU 利用率，我们看到，服务器在当天最繁忙时段的峰值不到 80%。 运行队列没有压力。 IO 和应用也表现良好，因此不存在人为抑制 CPU 的瓶颈。  > **经验法则**：首先在考虑到预期增长（例如用户数/事务数增长）的前提下调整系统规模，使得在硬件寿命结束时的最大 CPU 利用率为 80%。 这样可以容许出乎预期的增长、异常事件或意外的活动激增。 为了使计算更清楚，我们假设在新硬件的生命周期内，预计吞吐量不会有任何增长： 每核心的扩展可以计算为：(251/8) : (1030/24)，或者每核心吞吐量增长 26%。 **8 核心**旧服务器上的 80% CPU 大致相当于新的 **6 核心** E5-2680 V3 处理器上的 80% CPU。 因此，6 个核心即可支持相同数量的事务。 客户有几个选择，他们可以购买新的裸机服务器以满足 6 核 E5-2680 V3 或相同 CPU 核心数的最低 CPU 要求，或者继续推进在 VMware 上虚拟化生产工作负载的计划。 虚拟化对于利用服务器整合、灵活性和高可用性更有意义。 由于我们已经得出 CPU 要求，客户可以放心地继续在 VMware 上适当调整生产虚拟机的规模。 另外，目前低核心数的服务器很难采购到或者价格昂贵，这使得虚拟化更具吸引力。 如果预期有显著增长，虚拟化也是一个优势。 可以根据前几年的增长来计算 CPU 要求。 在持续监视的前提下，一个有效策略是只在出现资源需求之前才添加额外资源。 --- # CPU 和虚拟化注意事项 正如我们所看到的，Caché 生产系统的规模根据实际客户站点的基准测试和测量结果来确定。 通过裸机监视来确定 VMware 虚拟 CPU (vCPU) 的规模需求也是有效的。 与裸机相比，使用共享存储的虚拟化所增加的 CPU 开销非常小**。 对于生产系统，使用的策略是将系统初始规模调整为与裸机 CPU 核心数相同。 __**注：__对于 VMware VSAN 部署，必须添加 10% 的主机级 CPU 缓冲区才能进行 VSAN 处理。 虚拟 CPU 分配应考虑以下关键规则： __建议：__分配的 vCPU 数量不要超过满足性能需求的安全数量。 - 虽然可以为虚拟机分配大量 vCPU，但最佳做法是不要分配超过所需数量的 vCPU，因为管理未使用的 vCPU 会有性能开销（通常很小）。 这里的关键是定期监视系统，以确保虚拟机的规模合适。 __建议：__生产系统，特别是数据库服务器，按 1 个物理 CPU = 1 个虚拟 CPU 进行初始规模设置。 - 生产服务器，特别是数据库服务器预计将被高度利用。 如果需要六个物理核心，则设置六个虚拟核心的规模。 另请参见下文关于超线程的说明。 ## 超额预定 通过超额预订方法，可以将比物理主机上可用资源更多的资源分配给该主机支持的虚拟服务器。 通常，可以通过超额预定虚拟机中的处理、内存和存储资源来整合服务器。 运行生产 Caché 数据库时，仍然可以对主机进行超额预定，但是对于_生产_系统的初始规模设置，假定 vCPU 能够完全发挥核心能力。 例如，如果您有一台 24 核（2 个 12 核）E5-2680 V3 服务器 – 总共多达 24 个 vCPU 的容量规模，且可能还有余量可供整合。 此配置假定在主机级别启用了超线程。 在您花时间监测应用程序、操作系统和 VMware 在峰值处理期间的性能后，您可以决定是否进行更高度的整合。 如果混合非生产虚拟机，要计算 CPU 核心总数，我经常使用的系统规模调整经验法则是_最初_将非生产虚拟机的物理 CPU 与虚拟 CPU 的比例调整为 2:1。 但是，这并不是绝对的，具体情况可能各不相同，需要监视来帮助您进行容量计划。 如果您有疑问或没有经验，可以在主机级别或使用 vSphere 配置将生产虚拟机与非生产虚拟机分开，直到了解工作负载为止。 VMware vRealize Operations 和其他第三方工具能够随时间监视系统，并可提供整合建议或发出虚拟机需要更多资源的提醒。 在将来的帖子中，我将讨论更多可用于监视的工具。 最重要的是，在我们的客户示例中，他们可以确信他们的 6 vCPU 生产虚拟机会很好地工作，当然前提是其他主要食物群组件（如 IO 和存储）有足够容量 ;) ## 超线程和容量计划 根据物理服务器的已知规则调整虚拟机规模的一个良好起点是，针对启用了超线程功能的目标处理器计算物理服务器 CPU 要求，然后简单地进行转换： > 一个物理 CPU（包括超线程）= 一个 vCPU（包括超线程）。 一个常见的误解是，超线程以某种方式使 vCPU 容量增加了一倍。 这对于物理服务器或逻辑 vCPU 来说并不正确。 根据经验，开启超线程的裸机服务器可能比未开启超线程的相同服务器多提供 30% 的性能。 同样的 30% 规则也适用于虚拟化的服务器。 ## 授权和 vCPU 在 vSphere 中，您可以将虚拟机配置为具有一定数量的插槽或核心。 例如，如果您有一个双处理器虚拟机，可以将其配置为具有两个 CPU 插槽，或者具有单个插槽，但支持两个 CPU 核心。 从执行的角度看，并没有多大区别，因为虚拟机监控程序将最终决定虚拟机是在一个还是两个物理插槽上执行。 但是，指定双 CPU 虚拟机实际有两个核心而不是两个插槽，会对非 Caché 软件许可证产生影响。 --- # 总结 在本帖中，我概述了如何使用 SPECint 基准结果比较不同供应商、服务器或型号的处理器。 以及如何根据性能和体系结构进行容量计划和选择处理器，而不管是否使用虚拟化。 这些都是很深的主题，很容易陷入牛角尖... 不过，与其他帖子一样，如果您想要转移到其他方向，请评论或提问。 — # 示例：搜索 SPECint_rate2006 结果。 #### 下图显示了如何选择 SPECint_rate2006 结果。  ---- #### 使用搜索屏幕缩小结果范围。 #### 请注意，您还可以将所有记录转储为一个大约 20MB 的 .csv 文件，以进行本地处理，例如使用 Excel 处理。 #### 搜索的结果显示戴尔 R730。   --- #### 选择 HTML 以提供完整的基准结果。  --- 在我们的示例中，您可以看到以下服务器及处理器结果。 戴尔 PowerEdge R710，2.93 GHz：8 个核心，双芯片，4 个核心/芯片，2 个线程/核心 至强 5570：__SPECint_rate_base2006 = 251__ PowerEdge R730（英特尔至强 E5-2680 v3，2.50 GHz），24 个核心，双芯片，12 个核心/芯片，2 个线程/核心 至强 E5-2680 v3：__SPECint_rate_base2006 = 1030__

我找不到在Internet上连接到InterSystems Iris的spark或Kafka的情况。是否可以共享任何相关资源？ InterSystems 提供一个专门的 Spark connector. Documentation. 当然也可以用 JDBC 驱动 以下是一些IRIS--Kafka 互操作性的例子： PEX Demo Kafka demo

众所周知，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 的局限性及其解决方案。

亲爱的社区用户，您好！ 您知道吗，在 Global Masters，您可以兑换关于以下任何 InterSystems 产品的 InterSystems 专家咨询：InterSystems IRIS数据平台、IRIS医疗版、互操作平台 (Ensemble)、IRIS Analytics (DeepSee)、Caché、HealthShare统一的健康档案。 我们还有一个振奋人心的消息要分享，我们现在可以提供以下语言的咨询： 英语、葡萄牙语、俄语、德语、法语、意大利语、西班牙语、日语、汉语 而且！ 咨询时长延长到 1.5 小时，让您与专家深入探讨主题。 如果您有兴趣，不要犹豫，快来 Global Masters 兑换奖励吧！ 如果您还不是 Global Masters 的会员，欢迎您“点击此处加入”点击 InterSystems 登录按钮，然后使用您的 InterSystems WRC 凭据）。 要了解关于 Global Masters 的更多信息，请阅读文章：认识Global Masters 倡导中心，从这里开始！ 让我们在 InterSystems Global Masters 上见！🙂

亲爱的社区开发者们，大家好！ 你可能已经听说过Discord，很多人或许已经是Discord的资深用户了。此刻我们邀请您走近InterSystems技术的世界，加入我们的开发人员社交俱乐部! 用一种超级便捷的方式交流沟通： 💥 Discord：InterSystems开发者社区 💥 在开发者社区Discord Server上, 你会发现许多与intersystems相关的频道和讨论，以及日常生活对话的频道。只要加入我们的俱乐部，就能更接近InterSystems开发者的世界! 约起来，在 Discord：InterSystems开发者社区 与您相聚✌️ 如果您对提升Discord Server有任何建议，或者想在某个特定话题上创建一个新频道，欢迎在评论中分享：）

InterSystems编程大奖赛取得圆满成功，来自中文社区的两位参赛者获得项目奖励，项目简介如下。 获奖者@Botai Zhang 获奖情况：获得专家提名奖（Experts Nomination）第三名和社区提名奖（Community Nomination）第一名 提交项目：HealthInfoQueryLayer（基于Intersystems IRIS平台整合医院信息查询业务解决方案） 项目简介：随着医院信息化建设的逐步完善，医院子系统越来越多，系统间接口越来越多，同时接口费用不断增加，管理工作变得越来越复杂。其中，查询类业务接口根据业务类型分化，数量也是逐步递增，带来接口量大、开发工作繁重、代码冗余、维护困难等等问题。针对这一困境，我们基于Intersystems IRIS数据平台整合医院信息查询业务解决方案。该应用程序可通过配置完成查询业务接口实现，大大缩小开发、维护、实施等项目关键运转周期。 欢迎移步项目链接了解更多详情： HealthInfoQueryLayer 获奖者@Weiwei Yang获奖情况：社区提名奖（Community Nomination）第二名提交项目：Dictionary comparison scheme of cache database项目简介（应用场景）：现场需要将各个科室部门内的数据统一汇总到医院总部，但是汇总后发现各个科室使用的字典并不统一，需要将表中的现存的字典统一更换为医院制定字典。例如：A科室中人员的性别字典使用0/1/2表示各种性别，B科室中性别字典使用F/M/O表示各种性别，但是现在医院要求所有性别字典保存Female/Male/Other性别信息，此时就需要替换原有的性别字典为新用字典。当初，此处只是列举了一个使用场景，未来有多个需要对照字典的工作都可以考虑此项目的设计和实现思想。欢迎移步项目链接了解更多详情：Dictionary comparison scheme of cache database

10月26日-29日，InterSystems 2021全球线上峰会将聚焦于“Analytics”，为您提供全球先进经验和分享。 除了丰富的演讲外，针对使用InterSystems技术的开发者们，InterSystems的认证团队提供了最新福利，注册参加InterSystems2021全球线上峰会，可在2021年12月31日前免费参加以下几项认证考试（价值150美元，每人限选一项）： InterSystems IRIS Core Solutions Developer Specialist 考核认证使用ObjectScript和其他InterSystems IRIS®技术构建应用程序的开发人员的核心技能。 HealthShare HealthConnect HL7 Interface Specialist 考核认证使用Health Connect构建和测试HL7®v2 新产品的开发人员的核心技能。 HealthShare Unified Care Record Technical Specialist 考核认证实施、扩展和管理HealthShare®统一健康档案（Unified Care Record）各个方面的技术专业人员的核心技能。 HealthShare Patient Index Technical Specialist (Beta) 考核认证实施、培训和支持HealthShare Patient Index各个方面的技术专业人员的核心技能。 如果您对该项目感兴趣，请在峰会结束后至11月12日（含）发邮件至wechat@intersystems.com进行咨询、申请，申请通过后，需要在12月31日前完成考试。 10月26日-27日，我们为中国用户专门开通了本地直播平台，欢迎点击免费注册参会。

数据平台不仅要安全，还要合规，三级等保是我们要符合的主要安全规范。InterSystems的数据平台和集成平台产品都和三级等保有关。如果没有正确配置它们的安全选项，就会影响到整个系统的安全，影响到合规性。 在生产环境上，如何配置安全的InterSystems的数据平台，并达到三级等保的要求？ 这个系列文章，针对InterSystems 数据平台的安全架构，围绕对三级等保的合规性展开，介绍如何配置出一个安全、合规的数据平台。 注：本文提到的InterSystems的数据平台，包括Caché数据库、Ensemble集成平台、HealthConnect医疗版集成平台和InterSystems IRIS数据平台。 三级等保的要求 三级等保要求 对数据平台的要求 身份鉴别 确保用户身份是真实、准确的 访问控制 控制：谁、以什么方式、从什么设备可以访问什么数据和功能？ 入侵防范 防范静态数据、传输中的数据、日志和备份中的数据被入侵 恶意代码防范 防止恶意代码被植入和执行，例如SQL注入 可信验证 数据完整性 保证数据完整性和一致性的能力 数据备份恢复 对数据的备份与恢复能力和策略 InterSystems数据平台安全架构 InterSystems数据平台提供了一个完善的安全架构，用以保护从接入到数据保存的各个层面的数据安全： InterSystems数据平台提供丰富的安全相关特性，用以保障系统安全性和合规性： 我们按数据的流向逐一展开，看看应该如何加强InterSystems数据平台的安全。 1. InterSystems数据平台连接通道安全 客户端可以使用多种技术连接到InterSystems数据平台，包括ODBC/JDBC、Java、.net、TCP、Telnet、HTTP、SOAP、REST等。除了客户端的连接，InterSystems数据平台之间也有很多连接通道，例如高可用镜像成员之间、数据平台和Web网关之间… 这些连接通道都应该考虑使用SSL/TLS进行通讯加密，从而保护数据的安全和一致性。 1.1配置InterSystems数据平台的超级服务器接入通道加密 除了通过HTTP、SOAP、REST之外的客户端，其它的客户端都连接到InterSystems数据平台的超级服务器。InterSystems数据平台在系统范围内使用SSL/TLS协议为超级服务器端口通道加密。 配置步骤如下： 在管理门户中，通过路径 系统 > 安全管理 > SSL/TLS 配置，建立名为%SuperServer的SSL/TLS配置项。参考文档 在管理门户中，通过路径 系统 > 安全管理 > SSL/TLS 配置，在超级服务器SSL/TLS支持 选项上选中“要求”。它的三个选项分别为： 禁用（默认选项）- 拒绝使用TLS的客户端连接 启用 - 允许使用TLS的客户端连接，但不必要 要求 – 仅接受使用TLS的客户端连接 如果Telnet也要通过TLS加密传输，将上面配置的基础上，再建立一个名为%TELNET/SSL的SSL/TLS配置项，然后将上图的Telnet server SSL/TLS support 设置为“要求”。具体配置 1.2 配置客户端使用SSL/TLS连接到InterSystems数据平台的超级服务器 不同的客户端技术配置SSL/TLS的方式不同，具体的配置详见： Java .net ODBC/Studio/Windows Terminal Windows配置 这里以ODBC为例，看看Windows客户端上ODBC设置的步骤： 1. 在Windows客户端上下载IRIS服务器上的CA证书文件，并保存在指定目录。例如：c:\InterSystems\certificates\certificateSQLaaS.pem 2. 在Windows客户端上编辑并保存C:\Program Files (x86)\Common Files\InterSystems\IRIS\SSLDefs.ini，其中[IRISServer]是你起的SSL/TLS配置名，后面的Address和Port是 InterSystems数据平台的服务器地址和超级服务器端口号。[TLSConfig]是SSL/TLS的配置项，注意其中的CAfile是第一步得到的CA证书文件路径。 [IRISServer] Address=172.168.3.10 Port=1972 SSLConfig=TLSConfig [TLSConfig] TLSMinVersion=16 TLSMaxVersion=32 CipherList=ALL:!aNULL:!eNULL:!EXP:!SSLv2 Ciphersuites=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 KeyType=2 VerifyPeer=1 Password= CAfile=c:\InterSystems\certificates\certificateSQLaaS.pem 3. 配置Windows的ODBC DSN，选中“Password with SSL/TLS", 并在“SSL/TLS Server Name”中填写SSLDefs.ini中特定的配置名，例如：IRISServer 之后ODBC客户端就可以使用这个DSN通过TLS加密传输连接到InterSystems数据平台了。 1.3 安全建议 虽然不是三级等保必须的，建议配置和开启InterSystems数据平台的超级服务器SSL/TLS连接。 2. Web服务器 InterSystems 数据平台在安装时，可以选择安装一个私有的Apache，用于访问管理门户和基于HTTP的开发、测试，例如网页应用、SOAP和RESTful API。 这个私有Apache并不是全功能的，因此不应作为生产环境的Web服务器，尤其是生产环境有基于HTTP的服务、应用或接口时。这时，应该部署独立的Web服务器和InterSystems Web网关，连接到InterSystems的数据平台。并且应该配置HTTPS，而非使用无加密的HTTP。 InterSystems的数据平台支持Apache、IIS和Nginx等Web服务器。 2.1 独立Web服务器的配置 如何配置独立的Web服务器和InterSystems Web网关，如何配置Web服务器的HTTPS？请参考这篇非常棒的社区系列文章： WebGateway系列 2.2 安全建议 生产环境上，部署独立的Web服务器，而非使用InterSystems 数据平台的私有Web服务器。 Web服务器应使用HTTPS，而非HTTP，提供Web服务。 3. 服务与接口 InterSystems数据平台提供一系列服务和接口，用于各种外部系统和技术的接入，例如常见的ODBC/JDBC的SQL客户端、开发者使用的Studio、管理员常用的Telnet。另外，InterSystems数据平台组件和实例之间的连接也是通过服务实现的，例如Web网关和InterSystems数据平台之间的连接、配置为镜像高可用的多台InterSystems数据平台之间的连接。 3.1 InterSystems数据平台的服务 下表列出了InterSystems数据平台的服务和它们服务的对象： 服务名称 描述 %Service_Bindings 控制 SQL 或对象访问方式，包括Studio、XDBC客户端、Java、C++、ActiveX %Service_CacheDirect 控制 Caché 直连访问方式 %Service_CallIn 控制使用CallIn的C/C++应用的访问 %Service_ComPort 控制从Windows系统COM端口的访问 %Service_Console 控制Windows本地服务器上 CTERM (TRM:pid) 和 Windows 控制台访问 %Service_Terminal 控制UNIX, Linux, Mac本地服务器上的控制台访问 %Service_DataCheck 控制实例间数据一致性检查DataCheck时，作为数据源的访问 %Service_DocDB 控制文档数据库的访问 %Service_ECP 控制是否ECP %Service_Login 控制通过 SYSTEM.Security.Login的登录访问 %Service_Mirror 控制镜像成员访问 %Service_Monitor 控制 SNMP 和远程监视命令 %Service_Shadow 控制此系统是否可以是shadow来源 %Service_Sharding 控制是否可以作为分片服务器访问 %Service_Telnet 控制来自于Windows 服务器的本地或远程Telnet 会话访问 %Service_CSP %Service_WebGateway %Service_CSP（Caché/Ensemble）或%Service_WebGateway（IRIS）控制通过Web网关的访问，也就是web应用 %Service_Weblink 控制旧有的WebLink应用访问 3.2 InterSystems数据平台服务的安全选项 这些向外开放的服务和接口有多种机制保护安全： 是否启用 是否是公用服务（意味着所有用户都有权限） 身份认证的方式 接入客户端的IP限制 其它特殊限制 在管理门户>系统>安全管理>服务，可以对每一项服务进行单独的安全配置： 3.3 安全建议 关闭不必要的服务。 对开启的服务，应选择安全的认证方式，不应使用“未验证”方式。 进一步限定允许接入的客户端IP地址。 4. 用户认证 用户认证是保障数据安全的核心之一。 4.1 InterSystems数据平台的用户认证机制 InterSystems数据平台支持多种用户认证机制，包括： Kerberos 基于操作系统的认证 IRIS用户名/密码 LDAP 代理认证 – 用户自定义认证 无认证 – 无需用户认证，进来的用户自动为UnknownUser 二阶段认证 它同时可以开启和使用多种用户认证，允许用户使用不同的认证方式接入数据平台。在启用多种用户认证机制时，InterSystems数据平台会以一定优先顺序来应用用户认证机制： Kerberos > 基于操作系统的认证 > IRIS用户名/密码 >无认证 LDAP > 代理认证 >无认证 4.2 用户认证方式的设置 这些用户认证方式，可以在系统层面开启或禁用，也可以在服务/接口层面进行选择。对于InterSystems数据平台提供的Web应用，例如网页应用、SOAP服务和RESTful API，还可以在Web应用层面进行用户认证方式的配置。 系统层面的配置，在管理门户>系统>安全管理>Authentication/Web Session Options ； 服务层面的配置，见3.2； 应用层面的配置，将在后面的应用安全章节详细介绍。 4.3 安全建议 系统级禁用 “无认证”，和其它不需要使用的认证方式 系统级，采用更安全的认证方式 5. 用户授权 InterSystems数据平台提供一套基于角色的权限控制机制，它可以保障细颗粒度的数据与服务安全。 5.1基于角色的权限控制机制 在这套机制下，被保护的数据与服务被称之为资产。资产可以是任何具体事物，例如数据库、服务、平台应用、管理工具，甚至可以是抽象的事物，例如工作身份、“对患者联系方式的权限”。 权限控制机制是： InterSystems数据平台定义资源，对应一个或多个资产；系统已经定义了一系列系统资源，同时用户可以自定义资源。 对资源的许可，例如读、写、使用，就是权限； 将权限分配给InterSystems数据平台定义的角色和/或用户； 用户就具有了相应的资产权限。 5.2资源的权限配置 通过管理门户>系统>安全管理>资源，管理可以创建新资源、配置已有资源的权限。 以%开头的资源是系统已经创建好的资源，例如： %Admin_* 是工作身份资源 %DB_* 是数据库资源 %Service_* 是服务资源 %Ens_* 是互操作相关的资源 其中，对资源的权限可以被设置为“公有权限”，即所有用户都有相应的权限。 5.3 安全建议 用户自定义的数据库应该设置自己独立的资源，而非使用%DB_%DEFAULT 谨慎使用公共权限 创建自己需要保护的新资源

6. 用户与角色 InterSystems 数据平台对用户和角色提供全面的管理和安全配置功能。加强数据平台的安全，需要加强对于用户和角色的管理。 6.1 用户管理 系统提供了一系列预置的用户账户，这些账户管理对应特殊的系统功能： 用户 说明 UnknownUser 匿名用户，通过“未验证”方式登录到系统的用户 _SYSTEM SQL系统管理员 SuperUser 超级用户 Administrator 安装系统的用户 Admin 系统管理员 CSPSystem Web网关管理员 IAM IAM用户 _PUBLIC 内部使用 _Ensemble 内部使用 6.1.1 系统级用户安全配置 InterSystems数据平台有一些系统级别的用户安全配置，例如密码模式、密码有效天数、无效登录限制（多少次登录失败后要禁用用户账户）、非活动限制（多少天未登录后禁用用户账户）等。这些系统级配置通过管理门户>系统>安全管理>系统范围的安全参数： 三级等保对于用户的密码强度是有要求的。弱密码只需要0.19毫秒就能被破解，而8位强密码破解需要上百年。密码强度可以通过上面配置页面的密码模式或密码验证routine来配置： 密码模式只能配置简单的密码强度约束逻辑，例如3.32ANP意思是允许3位到32位长度到密码，密码可以由字符、数字和符号组成。 密码验证routine可以配置任意复杂的密码强度约束逻辑，它通过用户自定义的密码检查逻辑进行判断。例如要求“密码必须是包括数字、大写字母和半角符号的8位以上的字符串”，可以在%SYS命名空间下编写一个routine，里面提供密码验证逻辑的方法。方法名由自己决定，它有两个固定的参数Username和Password，您只要实现密码约束逻辑：如果符合约束，返回$$$OK，否则返回相应的错误提示即可。 这里给出一个routine示例，这个%SYS下的routine名为IRISPWD，里面的CHECK方法用于判断密码合规性，它利用正则表达式判断密码是否符合“必须是包括数字、大写字母和半角符号的8位以上的字符串”的约束，违反约束时给出提示错误。 #include %occInclude CHECK(Username,Password) PUBLIC { s tValid=(Password?8.E)&&(Password?.E1.U.E)&&(Password?.E1.N.E)&&(Password?.E1.P.E) q:(tValid=0) $$$ERROR($$$GeneralError,"密码需要是包括数字、大写字母和半角符号的8位以上的字符串") q $$$OK } 然后将方法调用的名称更新到“系统范围的安全参数”中的密码验证routine中。方法调用名称是方法名^Routine名，本示例为CHECK^IRISPWD。 设置好后即可生效，但要注意它不会对旧有密码进行验证。当设置或修改用户密码后保存时，它会进行检查，对违反约束的密码设置，会报如下错误提示： 6.1.2用户管理 通过管理门户>系统>安全管理>用户，可以创建、管理用户。在这里可以执行每个用户的初始密码设置、账户启用/禁用条件，用户的角色设置、SQL权限等管理。 另外，也可以查看用户的概要信息，它会显示用户的权限列表、登录历史等信息： 注意： CSPSystem用户是CSP网关登录到InterSystms IRIS/Cache'的用户。如果需要修改它的密码，需要先在IRIS/Cache'用户管理页面修改CSPSystem的密码，然后再登录到CSP网关上修改CSP网关连接IRIS服务器的账户信息，保持二者密码一致。1. 登陆到私有Apache的CSP网关或独立安装的Web服务器的CSP网关，访问http://<IP+端口>/csp/bin/Systems/Module.cxw 2. 修改CSP网关连接IRIS服务器的账户信息: 2.1 Configuration>Default Parameters>Security>User Name 和Password2.2 Configuration>Server Access>Connection Security>User Name 和Password 6.2 角色管理 InterSystems数据平台预置了一些%开头的系统角色，例如%Developer开发者角色、%Manager系统管理员角色、%Operator系统操作员角色。 其中%All是一个特殊角色，它是超级用户角色，属于这个角色下的用户都是超级用户。因此属于这个角色的用户数量不宜过多，当然也不建议少于2个，以避免密码遗失造成无法管理系统而只能进入紧急模式。 6.3 安全建议 1.仅管理员有%All角色，尤其要确保UnknownUser没有%All角色 2.删除不需要的系统角色和系统用户 3.要求用户账号更安全的密码模式 4.设置密码错误数次后停用账号 7. 数据安全 InterSystems数据平台提供了丰富的数据安全特性，包括数据与数据库加密、数据访问控制机制。这里相当多的特性都是三级等保要求的。 7.1 数据加密 InterSystems数据平台内建多种加密算法，包括AES CBC (128, 192, 256位)、HMAC、MD5、SHA-1、SHA-512、PKCS、PBKDF2、Base64等。同时，它可以直接调用外部的Python、Java和.net算法库，实现包括国密SM算法在内的算法扩展。 它支持对全数据库加密，或仅对数据元素加密。 7.1.1 全数据库加密 全数据加密时，InterSystems数据平台使用AES加密算法，自动负责数据库数据的加解密。加密的数据库在加载时，需要向系统提供密钥。通常密钥保存在可移除的设备上，例如U盘，仅在加密数据库加载时使用，加载后就可以移除并保存在安全的地方。 InterSystems数据平台的数据库和命名空间架构让用户可以将需要加密保护的数据，例如患者基本信息数据和支付数据单独保存在一个较小的数据库中。 在全数据库加密的情况下，可以对日志、审计日志都进行加密，从而避免任何的数据泄密渠道。这样，即便数据库文件、日志文件和审计日志被盗走，没有密钥文件都无法解密数据。 创建一个新密钥文件及新的加密数据库的过程非常简单，在管理门户即可完成： 产生密钥文件。只有管理员才有权限产生密钥文件。 输入密钥文件产生路径、管理员账户、密钥文件管理密码、AES加密位数，保存时会产生用于加密的密钥文件。 注意，产生的密钥文件的管理是需要权限的 – 只有密钥管理员才可以激活该密钥文件并使用它进行数据库加密。在密钥文件产生后，尽快加入多个可以管理该密钥的管理员，并为他们设置不同的密钥密码，以避免一个密钥管理员账户失效。 密钥文件产生后，你就可以将其拷贝到安全的位置，并将原始产生的文件删除。如果你有多个密钥，应记住密钥ID (如下图的0535458F-A895-4915-BADF-2C257602880D)和密钥文件、密码的关系。 激活密钥文件 在InterSystems数据平台实例上激活密钥，才能使用它进行数据库加解密。只有密钥管理员，使用密钥文件的密码才能激活密钥。 每个实例可以激活多个密钥，因为你可能有使用不同密钥加密后的数据库文件。可以设置某个密钥为默认密钥，新产生的加密数据库会使用默认密钥加密；同时可以设置某个密钥文件为默认的Journal日志密钥，新的Journal日志会使用默认Journal密钥加密。 这里还可以设置密钥使用的方式：“交互”或“无人参与”。 “无人参与”需要将密钥文件保存在一个InterSystems数据平台启动时可以访问到的固定路径上，因此不推荐使用。“交互”方式下，InterSystems数据平台会在启动和加载加密数据库时向管理员询问密钥位置，因此更加安全。 创建加密的数据库： 在数据库创建过程中，选择加密数据库。这样InterSystems数据平台会使用当前默认的密钥进行加密。 现在你就有了一个加密的数据库了，里面的任何数据都是被加密的。即便数据库文件被copy走，只要没有密钥文件，这个数据库就无法被加载或解密其中的数据。 在今后的InterSystems数据库平台的启动过程中，都将要求输入加密密钥文件的完整路径、密钥管理员账户和密钥文件密码： 如果要对之前未加密的数据库加密、或者将加密数据库重新部署为不加密的数据库、或者为加密数据库更换加密密钥，这些操作需要通过^EncryptionKey 管理工具完成，而不能在管理门户中完成。参见文档 7.1.2 数据元素加密 除了全数据库加密，用户也可以选择通过代码控制仅对特定数据元素加密，因此它可以控制非常细颗粒度的加密策略。 InterSystems数据平台提供系统类%SYSTEM.Encryption，里面有密钥创建和管理、加密解密的方法。用户开发的程序可以使用这些方法进行密钥管理和加解密工作。 如何使用的文档在这里。 7.2 数据访问控制 InterSystems数据平台提供多个层面的数据访问控制机制。包括： 数据库层面的访问权限控制，即数据库读、写权限控制 SQL层面的访问权限控制，包括 SQL操作的权限，例如创建表和视图的权限 对表、视图级别的访问权限 对存储过程的执行权限 行级安全 – 例如每个医生只能看自己的出诊记录 列级安全 – 例如医生角色可以看到患者表中除了患者支付卡号列之外的其它数据 这些数据访问控制机制可以自由组合，满足严格的数据访问控制。 7.3 安全建议 对敏感数据进行全数据库加密，并保存好密钥文件和密钥文件密码 合理的数据读写权限 必要时，添加行级和列级安全

Hi 开发者们，你或许已经知道了，今年InterSystems全球峰会线下会议再次开启！我们非常期待能在现场见到诸位！ 然而，并不是所有的开发者社区成员都有机会参加（我也是！）所以我们决定制作一个很酷的视频收集来自社区成员们问候🎥 无论身在何方，让我们一同以虚拟方式来参加这次伟大的盛会吧！🌏 ⬆️要求：您录制一句2-3秒的短视频，视频内容是向我们的社区成员说 “Hi From your country (来自XX的问候，英语视频最佳）”，然后将视频上传至 这里 ，这样，我们可以把来自各地的许多视频剪辑在一起，在2022年全球峰会上展示。您也可以通过开发者社区联系我，将视频直接分享给我。 截止日期：美东时间6月18日（周五） 期待见到你！

这篇文章的目的是为了说明如何使用互操作菜单实现系统集成。 图片左侧窗口是接受外部系统发送信息的窗口。 信息接收方式种类很多，如定时监控指定目录来读取文件，定期查询数据库，输入且等待信息输出，或直接调用其他应用程序系统传送信息。 在系统集成配置中创建IRIS 互操作性菜单，接收到存储在一个对象中的信息被称为一条消息message（以下统称为消息）。消息被发送到组件component （以下统称为组件）中做后续处理。 使用所有接收到的信息或仅使用其中的一部分就能用来创建消息。 假设您要将信息中包含的消息发送给外部系统。这种情况下，需要将该消息发送给负责请求外网处理的组件（图右侧）。接收到消息的组件会请求外部系统对其进行处理。 此外，假设一条消息需要人工审查、数据转换或附加数据。这种情况下，消息会被发送到图表中间的业务流程管理组件（BPM），该组件负责协调处理业务流程。 消息用于在每个组件之间发送和接收数据。当发送或接收消息时，消息会被自动存储在数据库中。 由于消息存储在数据库中，因此在数据转换前后可以检查其差异性。在操作期间，或过程中间重新开始（重新发送），可以检查作为问题根源的消息。在开发、测试和操作的每个阶段可以验证正在使用的消息状态。 一个简单的系统集成图将分为三个部分（业务服务Business Service、业务流程Business Process和业务操作 Business Operation），如下图所示。 还有一个称为“生产Production”的定义，它存储有关要使用的组件信息（例如，连接信息）。 各组件功能如下： 业务服务Business Service 负责从外部源接收信息，创建消息，以及向其他组件发送消息。 业务流程Business Process 该功能在收到消息时被激活，并负责协调流程（按预先定义的顺序调用组件、等待响应、等待人工审核结果等）。 业务运营Business Operation 此功能在收到消息时被激活，会请求外部系统处理该消息。 消息是用于在组件之间发送和接收数据。 当收到一个消息时，业务服务以外的所有组件开启处理流程。 问题是，创建和使用此消息的目的是什么？ 通过创建消息可获取中继到外部系统的数据并检索进入业务服务。 由于不是所有的外部系统都用相同类型的数据格式连接到 IRIS，并且要中继的内容各不相同，因此生产者可以根据信息自由定义消息类别。 有两种类型的消息：请求（= 请求消息）和响应（= 响应消息）。触发组件激活的消息被称为request（=请求消息），组件处理后响应的消息称为response（=响应消息）。 这些消息在考虑中继流程时会被设计。 在接下来的文章中，我们将使用一个案例来概述生产、消息和组件的创建。 上一篇链接，请参考：《首次使用InterSystems IRIS 》-让我们来使用互操作性！链接如下：https://cn.community.intersystems.com/post/%E3%80%8A%E9%A6%96%E6%AC%A1%E4%BD%BF%E7%94%A8intersystems-iris-%E3%80%8B-%E8%AE%A9%E6%88%91%E4%BB%AC%E6%9D%A5%E4%BD%BF%E7%94%A8%E4%BA%92%E6%93%8D%E4%BD%9C%E6%80%A7

这篇文章是前面文章[首次使用InterSystems IRIS] 互操作性: 它是如何工作的？的延续。 在上一篇文章中，解释了互操作性菜单如何用于系统集成。 在本文中，我想解释如何用互操作菜单开发系统集成。 首先，您想创建什么样的业务流程？ 请一边思考，一边开始以下内容。 Production（生产） 消息 组件 业务服务 业务流程 业务运营 Production被定义和用作指定系统集成所需的组件及存储组件的配置，这些配置通过管理门户界面使用（内部被存储为生产的类定义）。 例如，假设您正在创建一个业务服务，该服务定期处理放置在指定目录中的文件。 在这种情况下，有必要准确配置要监测的目录和要处理的文件。 一个生产就是预先准备好用于存储这些配置。 这些配置取决于发送和接收数据的组件所使用的适配器。 适配器是用于简化与外部系统连接的类，有些是协议特定的，如 Mail/File/SOAP/FTP/HTTP/SQL/TCP，有些是标准特定的，如 HL7。 有关适配器的更多信息，请参阅文档（protocol-specific adapters and adapters related to EDI documentation） 由于我们将必要的组件定义为Production，“启动Production”将启动系统集成，而“停止Production”将停止系统集成。 完成Production需要的开发是系统集成所需组件的创建，具体包括以下内容： • 信息 • 组件（业务服务、业务流程、业务运营） • 数据转换等。 上面的内容会在后面的文章中慢慢讲解。 首先，让我们使用Production示例来启动Production，并在检查配置的同时通过查询数据来检查消息处理的流程。 模版可以从这里下载https://github.com/Intersystems-jp/selflearning-interoperability。 如使用容器，请使用 git 克隆 下载示例代码，导航到克隆的目录，然后运行 docker-compose up -d 就这么简单！ 请在此处参考流程here （创建容器需要一些时间）。 如果不使用容器，下载示例后新建一个命名空间，并将src文件夹下的所有类定义文件（extension .cls）导入创建的命名空间。 更多关于创建命名空间的过程，请参考本文this article.07:03之后的视频。 有关示例代码的更多详细信息，请参阅README。 准备就绪后，访问管理门户（更改 Web 服务器的端口号以匹配您的环境）。 http://localhost:52773/csp/sys/UtilHome.csp 进入管理门户 > 互操作性 > 配置 > 生产。 如果您使用的是容器以外的方法，请连接到您导入源代码的命名空间，访问[[配置] > [生产],，单击[打开] 按钮，选择[开始] > [生产],，然后单击 [开始] 按钮。 ※ 如果您使用容器以外的东西，则需要进行一些初始设置。 请在尝试以下内容之前设置以下描述的内容contents described below。 生产页面将为每一个 “服务”、“流程”和“操作”组件显示为[● 组件名称] ]。 单击组件名称可更改屏幕右侧“设置”选项卡的内容。 例如点击Start.GetKionOperation（单击），显示如下。 组件有[HTTP Server] 和 [URL] 配置来连接Web API. 配置底部有一个 [appid] 字段，您可以在其中输入您获得的 API 密钥。 [appid] 附近有一个 [lang] 字段，设置为“ja”（“ja”=日语）。 [lang] 设置来自 OpenWeather 的响应语言。 如用英语，设置为“en”。 完成设置这些配置后，单击“应用”按钮。 如果您使用的是容器，则该配置完成。 欲了解更多信息，请点击here。 如果您正在尝试容器以外的其他配置 请提前做好以下两项设置： 1)　配置SSL客户端。 由于要连接的 Web API 将使用 HTTPS 进行通信，因此请提前在 IRIS 端配置 SSL 客户端。 为了匹配生产模版的设置，我们将使用名称 [openweather]。 生产中的设置如下： 单击管理门户 > [系统管理] > [安全] > [SSL/TLS 配置] > [新建配置] 按钮，在“配置名称”字段中输入“openweather”，然后单击“保存”按钮 结束。 2)　为 REST 创建一个基本 URL 在示例制作中，为使能够通过 REST 输入信息，我们已经进行了配置，基本 的URL for REST配置需要在 IRIS 端。 在生产示例中，我们将配置 /启动设置为基本 的URL。 由于 Start.REST 类存在于导入示例的命名空间中，因此我们将指定该类作为调度类，并添加 %All 作为应用程序角色，以在访问时省去身份验证。 管理门户 > 系统管理 > 安全 > 应用程序 > Web 应用程序路径 > 单击“创建新的 Web 应用程序”按钮。 在名称字段中，指定 /start； 在命名空间字段中，指定从中导入样本的命名空间； 在 Dispatch Class 字段中，指定 Start.REST； 在允许的身份验证方法字段中，选择“未Unauthenticated”，然后保存文件。 保存后，将 %All 角色添加到“application role ”选项卡上的应用程序角色中。 尝试发送数据 全部配置好后，尝试用业务服务通过 REST 发送信息并让它运行。 http://localhost:52773/start/weather/Takoyaki/Osaka 上面的例子是假设某人在大阪购买了“章鱼烧”的 URL。 运行后画面如下。 检查已发送到生产的消息。 在管理门户 > 互操作性 > 配置 > 生产中，单击以下服务： 选择屏幕右侧的“消息”选项卡，然后单击标题字段列下方的任意数字。 如果您没有看到它，请重新加载您的浏览器。 使用 Visual Trace 页面，您可以看到组件之间发送和接收的消息信息。 您可以看到天气信息是从 Web API 检索并在浅蓝色框架中发送回来的。 通过这种方式，您可以使用跟踪来查看当时正在发送和接收哪些数据以及以什么顺序。 在整篇文章中，我们已经确认了Production已经定义了需要的组件和参考示例代码设置的系统集成 我们还确认，我们可以使用 Visual Trace 页面按时间顺序参考通过 Production 的消息。 在下一篇文章中，我们将讨论创建此跟踪中显示的“消息”背后的概念以及如何实际定义它。

HI 开发者们, 我们在bilibili 发布了新的视频！ 看看VS Code的InterSystems ObjectScript的调试器如何帮助你浏览和检查代码。了解如何为调试类方法和production组件编写启动配置，并获得VS Code调试器界面的概述--包括变量部分、观察窗格和调试控制台。 请欣赏并继续关注! B 站视频可以支持中文字幕：https://www.bilibili.com/video/BV1cb4y1p7RE?spm_id_from=333.337.search-card.all.click