方法文章

在关系型（MySQL）和非关系型（MongoDB 与 EXist）规模递增的 ISO/EN 13606 标准化电子健康记录数据库中执行复杂度递增的查询

10.5K 次观看

⸱

DOI：

10.3791/57439

⸱

2018年3月19日

 ,  ,  ,  , 
1Telemedicine and Information Society Department, Health Institute "Carlos III"

本文内容

摘要

本研究比较了关系型与非关系型（NoSQL）标准化医疗信息系统。通过使用规模倍增的数据库，计算了查询此类数据库管理系统（DBMS）响应时间的计算复杂度。这些结果有助于讨论每种数据库方法在不同场景和问题中的适用性。

摘要

本研究展示了一种用于评估查询关系型与非关系型（NoSQL，即不仅限于结构化查询语言）标准化电子健康记录（EHR）医疗信息数据库管理系统（DBMS）计算复杂度的实验方案。该方案采用一组包含三个规模依次倍增的数据库， 即 存储 5000、10000 和 20000 份真实标准化电子健康记录（EHR）提取数据的数据库，涵盖三种不同的数据库管理系统（DBMS）：关系型 MySQL 与对象关系映射 （ORM）、基于文档的 NoSQL 数据库 MongoDB，以及原生可扩展标记语言（XML）NoSQL 数据库 eXist。

计算了对六个复杂度递增查询的平均响应时间，结果显示在 NoSQL 情况下呈线性行为。在 NoSQL 领域中，MongoDB 的线性斜率远比 eXist 更平缓。

由于医疗信息更新策略的特殊性，NoSQL 系统可能更适用于维护标准化的医疗信息系统，此类更新策略不应影响存储在 NoSQL 数据库中的数据的一致性和效率。

本方案的一个局限性在于，缺乏使用相同数据获得的改进型关系系统（如原型关系映射，ARM）的直接结果。然而，将数据库规模加倍后的插值结果与文献中报道的及其他已发表的结果进行比较表明，在许多特定场景和待解决问题中，NoSQL 系统可能更为合适。例如，在基于文档的任务中（如临床实践中使用的电子健康记录（EHR）提取、编辑与可视化），或当目标不仅是查询医学信息，还需将 EHR 完全恢复为其原始形式的情况下，NoSQL 可能更为适用。

引言

NoSQL（不仅仅是 SQL）数据库管理系统最近已成为传统关系型数据库管理系统（RDBMS）的一种替代方案。几十年来，关系型数据库管理系统一直主导着数据在数据库系统中的存储方式。经过深入研究和充分理解的关系代数与关系演算，保证了关系型数据库管理系统的高效性与一致性1。NoSQL 系统并不会取代关系型系统，但在某些特定场景和多种条件下可能表现出优势。

在设计用于管理和存储医疗信息的电子健康记录（EHR）系统的数据库持久化时，可能会遇到上述某些特定场景和条件。为了在实践中实现互操作性和可持续性，已采用若干国际标准（如 ISO/EN 13606、openEHR 和 HL72,3,4,5）来规范 EHR 数据的提取。

诸如 ISO/EN 13606 和 openEHR 等多个标准已将信息与知识分离为两个不同层次的抽象，分别由参考模型（Reference Model, RM）和一种称为原型（archetypes）的特殊数据结构来表示。这种分离通常被称为双模型（dual model），它使得电子健康记录（EHR）系统能够实现语义上的互操作性，并允许医学知识在无需重新编程整个 EHR 系统的前提下持续演进，从而在实践中具备可维护性和可持续性6。然而，在标准化的 EHR 系统中实现的双模型要求信息的组织遵循特定的结构，这对系统数据库持久化层级的设计方式产生了深远影响7。

对象关系映射（Object Relational Mapping, ORM）8 是一种基于关系型数据库范式来实现电子健康记录（EHR）系统的方案。ORM 对系统所使用的标准化 EHR 导出 XML（eXtensible Markup Language）文件的结构进行详尽映射，并据此构建大量关系型数据表。这些关系型数据表通过多个外键相互关联，导致最终的系统可能效率较低。

人们已提出多种对对象关系映射（ORM）的改进方法。openEHR 的 Node+Path9 通过将整个提取的 XML 文件的子树序列化为 BLOB（二进制大对象）来减少关系表的数量。然而，这种简化导致了复杂的检索逻辑，损害了复杂查询的性能。模板关系映射（Archetype Relational Mapping, ARM）10 则采用由模板驱动的数据库建模方法，基于模板与关系表之间的映射关系构建新的关系模式。因此，电子健康记录（EHR）提取物中的部分非医疗信息会丢失。

许多基于文档的 NoSQL 数据库存储整个文档，将其作为完整的 BLOB 保存，并保持原始的 XML 或 JSON（JavaScript 对象表示法）格式。这意味着不会构建关系表。这些 NoSQL 数据库没有模式，也不支持连接操作或（ACID）特性11，即原子性、一致性、隔离性或持久性。因此，如果一个文档中的元素通过间接链接引用同一文档或其他文档中的元素，则此类数据库可能效率极低。这是因为为了保持一致性，必须顺序处理所有被引用的文档。然而，如果数据库管理系统执行的主要任务是基于文档的操作，则非关系型数据库仍可能是合适的。这是因为使用基于文档的 NoSQL 数据库时，数据可以保持更接近其真实表示的形式，尽管这一点也与电子健康记录（EHR）医疗文档所实现的特殊持久化策略有关（参见讨论部分）。

这些方法的目的是展示若干实验，以比较采用三种不同数据库管理系统（DBMS）实现标准化电子健康记录（EHR）系统持久层的性能：一种关系型数据库（MySQL）和两种非关系型数据库（基于文档的 MongoDB 和原生 XML 的 eXist）。通过三个规模递增的数据库以及六个复杂度逐步提高的查询，计算并比较了它们的计算复杂度。这三个数据库服务器均在同一台计算机上本地安装和配置，并在该计算机上执行所有查询。技术细节请见材料表。

为了比较关系型MySQL与非关系型MongoDB数据库管理系统的性能，也开展了并发实验。此外，还利用文献中相关的适当结果对所描述的ORM改进方法（Node+Path和ARM）进行了比较10。

数据库管理系统正在以不断加快的速度持续演进。当关系模型是唯一存在的范式时，人们并未预料到这种指数级的发展。例如，参见文献12，其中提出了一种模型，用于实现响应时间更优且保持ACID特性的关系型数据库。

方案

1. 构建关系型 MySQL 数据库管理系统以存储三个双倍规模的标准电子健康记录提取数据库

  1. 将对应于 ISO/EN13606 RM 和 ISO21090 数据类型的 W3C（World Wide Web Consortium）XML 模式导入“Java IDE”（集成开发环境）。
    注意：ISO 代表国际标准化组织，EN 代表欧洲标准。
  2. 在 IDE 中执行 JAXB（Java XML 绑定）插件；该操作将生成与电子健康记录摘要 XML 文件元素结构相对应的 Java 类。
  3. 手动为 JAXB 生成的 Java 类添加 JPA 标签。这些标签用于定义 MySQL 数据库中关系表之间的基数及其他关联关系。
  4. 将 JPA（Java 持久化 API）的库导入 IDE，并执行根据已标注的 Java 类构建 MySQL 数据库的方法。
  5. 创建三个目录，分别包含 5,000、10,000 和 20,000 个符合实际的电子健康记录摘要 XML 文件。
  6. 执行 JPA 方法，将 5,000 个摘要目录中的所有 XML 摘要文件加载到 MySQL 数据库管理系统中。
  7. 重复步骤 1.6 两次，分别使用 10,000 个和 20,000 个摘要的目录。

2. 构建一个 NoSQL MongoDB 数据库管理系统以存储三个双倍规模的标准 EHR 提取数据库

  1. 使用标准程序（例如 json.org.XML）处理包含 5,000、10,000 和 20,000 份真实电子健康记录（EHR）提取 XML 文件的三个目录，将 XML 文件转换为 JSON 文件。应生成包含 5,000、10,000 和 20,000 个 JSON 文件的三个目录。
  2. 启动 MongoDB 图形用户界面（GUI，参见材料表）。
  3. 在 DOS（磁盘操作系统）系统窗口中执行 mongod 程序，启动 MongoDB 2.6 服务器。
  4. 使用端口 27017 将 MongoDB GUI 连接到本地主机（localhost）服务器。
    1. 选择"连接"菜单。
    2. 为连接输入一个名称（例如“first”）。
    3. 在数据库服务器文本框中输入 localhost:27017。
    4. 点击"连接"按钮；左侧应出现当前数据库的树状结构。
  5. 构建一个包含 5,000 份标准化 EHR 提取数据的数据库。
    1. 点击左侧树状结构顶部的连接名称。
    2. 选择"文件"菜单。
    3. 选择"添加数据库"。
    4. 在弹出的对话框中输入数据库名称。
    5. 点击确定。
  6. 构建一个包含 5,000 份标准化 EHR 提取数据的集合。
    1. 点击左侧树状结构中的数据库名称。
    2. 选择"数据库"菜单。
    3. 选择"添加集合"。
    4. 在弹出的对话框中输入集合名称。
    5. 点击" 创建"。
    6. 点击集合名称。
    7. 选择"导入"菜单。
    8. 选择单选按钮“JSON - mongo shell / / mongoexport"。
    9. 点击"下一步"。
    10. 点击"添加源文件"按钮。
    11. 使用对话框在计算机中导航。
    12. 打开包含 5,000 个 JSON 提取文件的目录。
    13. 选择该目录中的所有文件。
    14. 点击"打开"。JSON 文件列表应出现在导入对话框中。
    15. 点击"下一步"；数据库中新集合的预览将出现在左侧。
    16. 点击"下一步"。
    17. 点击"开始导入"。导入进度将显示在左侧下方，指示已导入的文件数量和所用时间。
  7. 重复步骤 5 和 6，构建一个包含 10,000 份标准化 EHR 提取数据的集合。
  8. 重复步骤 5 和 6，构建一个包含 20,000 份标准化 EHR 提取数据的集合。

3. 构建一个NoSQL eXist数据库管理系统以存储三个双倍规模的标准EHR提取数据库

  1. 启动 eXist 数据库。
  2. 使用数据库图标，打开 Java 管理客户端。
  3. 输入管理员密码。
  4. 按下 "Connect" 按钮。
  5. 构建一个包含 5,000 份标准化电子健康记录（EHR）提取文件的集合。
    1. 在工具栏中，选择菜单 "Create a new Collection"。
    2. 在弹出的对话框中，输入新集合的名称。
    3. 点击 "accept"；新集合将显示出来。
    4. 选择该集合的名称。
    5. 在工具栏中，选择菜单 "Store files in the database"。
    6. 使用对话框在计算机中导航。
    7. 选择包含 5,000 份标准化 XML 提取文件的目录。
    8. 点击按钮 "Select the files or directories to store"。注意，将弹出一个对话框，显示存储进度、正在存储的文件以及已创建的数据库百分比。
  6. 重复步骤 5，构建一个包含 10,000 份标准化电子健康记录（EHR）提取文件的集合。
  7. 重复步骤 5，构建一个包含 20,000 份标准化电子健康记录（EHR）提取文件的集合。

4. 在3个关系型MySQL数据库中设计并执行6个复杂度递增的查询

  1. 根据电子健康记录（EHR）提取物所使用的原型，设计六个复杂度递增的查询。
  2. 在 MySQL 数据库上使用第一个查询编写 SQL 脚本。由于提取物的标准化（原型），SQL 必须适配 MySQL 数据库的特殊结构。该数据库映射了提取物的完整结构，因此 SQL 查询相对复杂。
  3. 识别数据库中若在其上建立索引可加快查询响应时间的属性，然后构建此类索引，尽管大多数索引由数据库管理系统（DBMS）自动创建。
  4. 如果某个查询需要非自动创建的索引，则手动建立该索引。
    1. 连接到 MySQL 服务器（补充图 1）。
    2. 在左侧选择并点击数据库名称。
    3. 选择并点击索引字段所在的关联表。
    4. 点击标签页 "结构"。
    5. 选择并点击将要建立索引的列。
    6. 点击 "索引"。注意显示生成索引的 SQL 语句，并出现提示信息表明该语句已成功创建。
  5. 执行第一个查询。
    1. 在左侧选择并点击数据库名称。
    2. 点击标签页 "SQL"。
    3. 编写或粘贴第一个查询的 SQL 代码（见 补充图 2）。
    4. 按下 "继续"。注意结果显示列表的第一页出现，同时显示查询执行时间的信息。
    5. 重复执行 5 次，并计算平均响应时间。
  6. 对第 2 至第 6 个查询重复步骤 5。
  7. 对包含 5,000、10,000 和 20,000 条提取物的数据库，重复整个过程三次。

5. 在3个NoSQL MongoDB数据库中设计并执行6个复杂度递增的查询

  1. 启动 MongoDB 图形用户界面（参见材料表）。
  2. 通过 DOS 系统窗口执行 mongod 程序来启动 MongoDB 2.6 服务器（参见补充图 3）。
  3. 按照步骤 2.4 的说明，使用端口 27017 将 MongoDB 图形用户界面连接到本地主机服务器。
  4. 在左侧选择并展开 MongoDB 数据库。
  5. 选择集合。
  6. 单击工具栏中的 "集合" 菜单。
  7. 执行第一个 MongoDB 查询。
    1. 双击 "查询构建器" 按钮。
    2. 在右侧的查询构建器中，双击 "查询字段"。
    3. 在查询面板的字段文本框中输入 MongoDB 查询的字段（参见补充图 4）。
    4. 在查询面板的值文本框中输入 MongoDB 查询的值。
      注：该查询应类似于 {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText.value": "Descripcion"}。字段和值均需用引号括起，并以分号分隔。
    5. 双击查询构建器中的“投影字段”。
    6. 在投影文本框中输入第一个投影（参见补充图 5）。
    7. 双击投影字段以添加一个新的投影文本框。
    8. 在投影文本框中输入第二个投影。
      注：投影用于选择由查询检索到的文档的一部分。其格式应类似于 {"ns3:EHRExtract.allCompositions.content.items.parts.parts.value.value": 1} 和 {"ns3:EHRExtract.allCompositions.content.items.parts.parts.value.nullFlavor": 1}。
    9. 单击蓝色的播放按钮以执行查询。
    10. 在“查询代码”选项卡中查看查询代码。
    11. 在“解释”选项卡中查看结果详情：结果数量、执行时间（毫秒）。
    12. 在“结果”选项卡中查看、展开并检查结果。
    13. 如果需要对查询结果进行进一步处理，请使用 MongoDB Java 驱动程序编写包含该查询及结果处理方法的 Java 程序。
    14. 重复执行 5 次，并计算平均响应时间。
  8. 对剩余的第 2 至第 6 个查询执行步骤 5.7。
  9. 在包含 5,000、10,000 和 20,000 条提取记录的 MongoDB 数据库中重复整个过程。

6. 在3个NoSQL eXist数据库中设计并执行复杂度递增的查询

  1. 启动 eXist 数据库管理系统。
  2. 打开 Java 管理客户端。
  3. 按下按钮 "connect to the database"。
  4. 选择数据库并点击它。
  5. 点击菜单 "Consult database using XPath"；此时将出现查询对话框。
  6. 执行第一个 XPath 查询（参见 补充图6）。
    1. 在对话框的上部区域输入或粘贴第一个查询的 XPath 代码。
    2. 点击对话框工具栏中的菜单 "Execute"。
    3. 在对话框下部区域使用 "XML" 标签页查看 XML 结果。
    4. 在对话框底部查看结果数量以及编译和执行时间。
    5. 重复执行5次，并计算平均响应时间。
  7. 对第2至第6个查询重复步骤6。
  8. 对包含 5,000、10,000 和 20,000 个提取物的 eXist 数据库，将整个过程重复三次。

7. 使用 MySQL 和 MongoDB 5,000 条提取物数据库设计并执行并发实验

注意：由于在之前的实验中 eXist 数据库性能较差，目前已从实验中移除。

  1. 从之前使用5,000个提取物数据库的实验中，选择响应时间最短的三个查询（通常在几秒内）。
  2. 如有必要，识别并手动为这些查询建立适当的属性索引。
  3. 编写两个Java多线程应用程序，一个用于MySQL，另一个用于MongoDB；每个应用程序将包含三个不同优先级的线程，分别对应步骤1中选定的每个查询。
  4. 执行并计算每个线程（查询）的CPU（中央处理器）使用分布。
  5. 运行每个多线程应用程序，在每10分钟时间段内点击执行按钮五次，并计算执行次数最多（最高优先级）查询的平均吞吐量以及三个查询的平均响应时间。
  6. 查看正在执行的查询，包括其优先级和执行时间。
  7. 计算三个查询中每个查询的平均吞吐量和平均响应时间。

结果

在包含患者问题信息（包括患者姓名、起始日期、结束日期和严重程度）的真实标准化电子健康记录提取物上执行的六种不同查询如图所示 表1.

三种数据库规模翻倍情况下，各数据库管理系统中六个查询的平均响应时间如表2-4所示。图1-6以图形方式展示了相同的结果（请注意，这些图中的纵坐标轴使用了截然不同的量程）。

在所有NoSQL数据库查询中，计算复杂度均表现出明显的线性行为，尽管由于所使用的3个数据集规模相对较小，需谨慎对待该结论。然而，关系型ORM数据库则表现出不明确的线性行为。MongoDB数据库的斜率远比eXist数据库平缓。

在引言中讨论的改进关系系统在文献中发表的结果可参见表5。将表3中的MongoDB结果与表5中ARM结果在相似查询和数据库规模下进行插值比较，两者在Q1中表现相当，但在Q3中MongoDB更具优势。

并发实验的结果见表5和表6。在吞吐量和响应时间方面，MongoDB 均优于 MySQL。事实上，MongoDB 在并发情况下的表现优于独立运行时的表现，显示出其在并发执行中具有出色的数据库性能。

ORM、MongoDB、eXist 响应时间图；查询 1、4；5000-20000 条记录时的性能比较。
图 1：ORM MySQL、MongoDB 和 eXist 数据库管理系统在查询 Q1 和 Q4 中的算法复杂度。本图基于7修改，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了每种数据库管理系统在 5,000、10,000 和 20,000 条电子健康记录提取数据集规模下，执行查询 Q1 和 Q4 的响应时间（单位：秒）。 请点击此处查看此图的高清版本。

ORM 响应时间与提取物的关系图；性能分析；包含查询 2 数据的折线图。
图 2： ORM MySQL 数据库管理系统在查询 Q2 中的算法复杂度。本图展示了 ORM MySQL 数据库在查询 Q2 时，针对包含 5,000、10,000 和 20,000 条记录的电子健康记录（EHR）提取物的响应时间（单位：秒）。请点击此处查看此图的放大版本。

MongoDB 与 eXist 响应时间对比；查询 Q2、Q5；折线图，提取数量。
图 3： MongoDB 与 eXist 数据库管理系统在查询 Q2 和 Q5 上的算法复杂度。本图改编自文献7，采用知识共享许可协议（http://creativecommons.org/licenses/by/4.0），展示了两种数据库管理系统在 5,000、10,000 和 20,000 条电子健康记录提取数据库规模下，执行查询 Q2 和 Q5 的响应时间（单位：秒）。请点击此处查看此图的高清版本。

显示 ORM 的响应时间与提取数量关系的折线图；Q3、Q5 性能分析。
图 4：ORM MySQL 数据库管理系统在查询 Q3 和 Q5 上的算法复杂度。显示了每种数据库管理系统在包含 5,000、10,000 和 20,000 条记录的电子健康记录提取数据库上执行查询 Q3 和 Q5 的响应时间（单位：秒）。请点击此处查看该图的高清版本。

MongoDB 与 eXistDB 响应时间对比图表；随着数据量增加的查询性能。
图5：eXist 与 MongoDB 数据库管理系统在查询 Q3 上的算法复杂度。本图改编自文献7，采用知识共享许可协议（http://creativecommons.org/licenses/by/4.0/），展示了两种数据库管理系统在处理包含 5,000、10,000 和 20,000 条记录的电子健康记录提取数据库时，执行查询 Q3 的响应时间（单位：秒）。请点击此处查看此图的高清版本。

ORM、eXist、MongoDB 数据提取响应时间性能比较图
图 6： ORM MySQL、eXist 和 MongoDB 数据库管理系统在查询 Q6 上的算法复杂度。该图改编自文献7，采用知识共享许可协议（http://creativecommons.org/licenses/by/4.0/），展示了每种数据库管理系统在包含 5,000、10,000 和 20,000 条记录的电子健康记录提取数据库上执行查询 Q6 时的响应时间（单位：秒）。请点击此处查看此图的高清版本。

查询
Q1查找单个患者的所有问题
Q2查找所有患者的所有问题
Q3查找单个患者某一特定问题的
初始日期、解决日期和严重程度
Q4查找单个患者所有问题的
初始日期、解决日期和严重程度
Q5查找所有患者所有问题的
初始日期、解决日期和严重程度
Q6查找患有“咽炎”问题、
初始日期 >= '16/10/2007'、解决日期
<= '06/05/2008' 且严重程度为“高”的所有患者

表1：在包含标准化患者电子健康记录（EHR）提取数据的关系型和NoSQL数据库上执行的六个查询。 本表格改编自7，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），以自然语言展示了在每种数据库管理系统（DBMS）的三个规模递增的数据库上执行的六个复杂度递增的查询。

ORM/MySQL5000 份文档10,000 份文档20,000 份文档
Q1 (s)25.047432.6868170.7342
Q2 (s)0.01580.01470.0222
Q3 (s)3.38496.4225207.2348
Q4 (s)33.5457114.6607115.4169
Q5 (s)9.639374.376729.0993
Q6 (s)1.43822.4844183.4979
数据库大小4.6GB9.4GB19.4GB
总提取数500010,00020,000

表2：ORM MySQL关系型数据库管理系统在数据库规模成倍增加时，六个查询的平均响应时间（秒） 此表格 展示了使用 ORM MySQL 关系型数据库管理系统和三个数据库的内存大小时，针对每个查询在三个规模依次加倍的数据库上的六次响应时间。

MongoDB5000 条文档10,000 条文档20,000 条文档斜率 (*10exp(-6))
Q1 (s)0.0460.0570.12215.07
Q2 (s)34.518168.6945136.23296,780.99
Q3 (s)0.0480.0580.12014.81
Q4 (s)0.0520.061o.12414.81
Q5 (s)38.020275.4376149.9337460.85
Q6 (s)9.515318.556636.78051,817.68
数据库大小1.95GB3.95GB7.95GB
总提取数500010,00020,000

表3：在MongoDB NoSQL数据库管理系统中，六个查询在数据量翻倍的数据库上的平均响应时间（秒）。 本表格经修改自7，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了使用NoSQL MongoDB数据库管理系统时，三个数据量依次翻倍的数据库中每个查询的六项响应时间，以及这三个数据库的内存占用大小。每个查询的线性斜率也一并列出。

eXist5000 份文档10,000 份文档20,000 份文档斜率 (*10exp(-6))
Q1 (s)0.66083.78347.3022442.76
Q2 (s)60.7761129.3645287.36215,105.73
Q3 (s)0.69761.7714.1172227.96
Q4 (s)0.64453.76047.3216445.17
Q5 (s)145.3373291.2502597.721630,158.93
Q6 (s)68.3798138.9987475.266327,125.82
数据库大小1.25GB2.54GB5.12GB
提取总数500010,00020,000

表4：在eXist NoSQL数据库管理系统上，六个查询在数据库规模逐次加倍时的平均响应时间（秒）。 本表格经7修改，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了使用NoSQL eXist数据库管理系统时，三个规模逐次加倍的数据库中每个查询的六项响应时间，以及这三个数据库的内存占用大小。同时列出了每个查询的线性斜率。

ARM 论文ARM (秒)节点+路径 (秒)
Q1查询 2.10.19124.866
Q3查询 3.10.27294.774
数据库大小2.90GB43.87GB
总提取数29,74329,743

表5：改进的关系型系统中与文献10中Q1和Q3查询类似的查询的平均响应时间（单位：秒）。 本表格改编自文献7，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了与文献10中Q1和Q3最相似的两个查询，分别对应两种改进的关系型数据库系统及其响应时间。同时列出了两个数据库的规模。

ORM/MySQL吞吐量响应时间
Q1 (s)4,711.600.0793
Q3 (s)4,711.600.1558
Q4 (s)4,711.600.9674

表6：ORM MySQL关系型数据库管理系统在并发执行中查询Q1、Q3和Q4的平均吞吐量及响应时间（单位：秒）。 本表格改编自文献7，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了在使用ORM MySQL关系型系统进行并发执行实验时，三个单患者查询的最高平均吞吐量及其平均响应时间。

MongoDB吞吐量响应时间
Q1 (s)178,672.600.003
Q3 (s)178,672.600.0026
Q4 (s)178,672.600.0034

表7：MongoDB NoSQL数据库管理系统在并发执行中查询Q1、Q3和Q4的平均吞吐量及响应时间（单位：秒）。 本表格经7修改，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了在使用MongoDB NoSQL系统进行并发执行实验时，三个单患者查询的最高平均吞吐量及其平均响应时间。

补充图1：截图显示了用于连接到 MySQL 服务器的软件界面。请点击此处下载该图。

补充图2：截图显示了连接到MySQL服务器的SQL界面，其中已编写第一条SQL查询语句。请点击此处下载该图。

补充图3：通过DOS系统窗口执行服务器mongod来启动MongoDB 2.6本地主机服务器。 请点击此处下载该图。

补充图4：截图显示了在查询构建器的文本框中输入的查询语句，如步骤5.7.1至5.7.4所示。本截图展示了步骤5.7.3。请点击此处下载该图。

补充图5：截图显示步骤5.7.6。 请点击此处下载该图。

补充图6：该截图展示了在对话框上半部分编写XPath查询的过程。请点击此处下载该图。

讨论

本方案表明，对于单个患者的查询（Q1、Q3 和 Q4），纯关系型 ORM 系统似乎并不实用，因其响应时间较慢，这可能是由于大量关系表执行了大量高成本的连接操作，以及特定数据库所采用的存储系统所致。NoSQL 数据库以基于文档的方式存储数据，而关系型系统则采用基于表格的方式，将每个文档分散存储在整个数据库中。NoSQL 系统呈现出线性增长趋势，其中 MongoDB 的性能明显优于 eXist DBMS。在并发处理方面，MongoDB 的表现也远优于关系型 MySQL ORM7。

本方案针对文献7中关于 ORM MySQL 数据库管理系统（DBMS）结果的故障排除提供了解决方案。MySQL 系统已更新至最新版本，相关结果也进行了小幅调整。此外，在基于文档的 NoSQL 系统（如 MongoDB）中存在一个关键点：在存储医疗信息时，此类系统可能保持数据一致性7，因为当电子健康记录（EHR）提取件被更新时，并非覆盖原有数据，而是生成并存储一个包含新数据的全新提取件，同时保留原始提取件。这是医疗信息的一项严格要求，因为某些医疗专业人员可能已基于原始数据做出了重要的医疗决策。

改进后的关系型ARM系统大幅减少了关系表的数量，并提升了关系型查询性能。然而，由于该系统修改了关系型模式，因此可以对提取物所包含的医学信息进行查询，但无法将提取物恢复为其原始的精确形式。

对于用于二次利用（研究）的大型数据库，目前尚不明确哪种数据库系统更为合适，因为全患者查询（Q2和Q5）在ORM系统中的表现优于NoSQL系统，但NoSQL系统在12中的表现又优于简化的关系型系统。我们认为Q6是一个介于临床实践与二次利用之间的特殊查询，其性能无法通过这些实验的结果来确定。

然而，该方法的一个局限性在于，目前尚无直接实验将改进的关系型 ARM 系统与 NoSQL MongoDB 在单患者、医疗实践查询方面进行对比，且使用与本方案中完全相同的数据。在包含优化 ARM 的实验完成之前，我们通过插值 表3 和 表5 中关于单患者查询的结果来维持分析。这些实验将留待未来应用中完成。本方案中的一个关键步骤是选择近年来版本相近的免费数据库和类似软件，以便我们能够准确比较这三种技术的最新状态。

这是首次尝试使用真实、合理且标准化的医学信息直接比较关系型数据库与NoSQL系统的研究之一。然而，具体应采用哪种系统在很大程度上取决于实际的应用场景和待解决的问题8。

披露

作者无任何利益冲突需要披露。本实验所使用的数据集由多家西班牙医院在许可条件下提供，仅用于本实验，因此不公开提供。ISO/EN 13606 RM XML 模式由伦敦大学学院健康信息学与多专业教育中心（CHIME）提供。

致谢

作者谨此感谢 EHRCom 任务组负责人、定义 ISO/EN 13606 标准的 Dipak Kalra 博士及其来自伦敦大学学院的团队，感谢他们慷慨授权使用 ISO/EN 13606 W3C XML Schema。

本工作由卡洛斯三世健康研究所资助［资助编号：PI15/00321、PI15/00003、PI1500831、PI15CIII/00010 和 RD16CIII］。

材料

本文使用的材料清单
姓名公司目录编号评论
MySQL 5.7.20MySQL 实验
Red Hat Enterprise Linux Server release 7.4 (Maipo)，2.60GHz，内存 16GB
MongoDB 2.6MongoDB 实验
Windows 7，2.66GHz，内存 12GB 
eXist 3.0RC1eXist 实验
Windows 7，2.66GHz，内存 12GB 
Studio 3T 5.5.13T Software Labs GmbhMongoDB 图形用户界面

参考文献

  1. Codd, E. F. A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).
  2. Kalra, D., Lloyd, D. ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).
  3. Kalra, D., et al. Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).
  4. Kalra, D., Beale, T., Heard, S. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).
  5. Health Level seven. Health Level Seven International. , Available from: http://www.hl7.org (2017).
  6. Beale, T. Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).
  7. Sánchez-de-Madariaga, R., et al. Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches. BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).
  8. Ireland, C., Bowers, D., Newton, M., Waugh, K. Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).
  9. Node+Path Persistence. , Available from: https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).
  10. Wang, L., Min, L., Wang, R., et al. Archetype relational mapping - a practical openEHR persistence solution. BMC Medical Informatics and Decision Making. 15, 88(2015).
  11. Kaur, K., Rani, R. Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).
  12. Sabo, C., Pop, P. C., Valean, H., Danciulescu, D. An innovative approach to manage heterogeneous information using relational database systems. Advances in Intelligent Systems and Computing. 557, Springer. (2017).

重印与许可

标签

关系型数据库系统非关系型数据库系统MySQL MongoDB EXist电子健康记录数据库管理系统计算复杂性分析响应时间测量数据库规模倍增
在关系型（MySQL）和非关系型（MongoDB 与 EXist）规模递增的 ISO/EN 13606 标准化电子健康记录数据库中执行复杂度递增的查询
联系我们
向图书馆推荐

隐私政策

使用条款

政策

版权所有 © 2026 MyJoVE Corporation。保留所有权利。