医疗本体存储性能比较

比较医疗领域中的关系型与本体三元组存储

摘要

当今的技术进步已使普遍存在的医疗系统汇聚成智能医疗应用，以解决患者的问题、与患者进行有效沟通并提高医疗服务的质量。构建智能医疗信息系统的第一步是将医疗数据表示为可连接、可访问和可共享的形式。为了实现这种表示，采用本体来描述医疗数据。通过将本体化的医疗数据与已使用和获取的数据相结合，并存储在支持关系型和基于图的本体数据的大数据存储中，可以维护整个健康领域的数据。在医疗领域存在多种大数据存储和不同类型的医疗大数据集。本文的目标是确定最适合存储大规模医疗数据的本体数据存储。为此，基于其基础设施容量、加载时间和查询响应时间，对AllegroGraph和Oracle12c数据存储进行了比较。因此，采用了医疗本体（基因本体、基因表达本体（GEXO）、转录调控本体（RETO）、基因表达调控本体（REXO））来测量本体加载时间。随后，针对基因本体构建并执行了多种查询，以测量容量和查询响应时间，从而对AllegroGraph和Oracle 12c三元组存储进行性能比较。

关键词 : 大型健康数据；大数据存储；三元组存储性能；语义网；医疗本体

引言

高计算能力的最新进展推动了医疗系统的改进。借助这一进步，医疗系统被用于提高医疗服务的质量和效率，并降低医疗服务的成本。尽管患者的健康记录存储在不同的医院和数据库中，但共享和重用这些记录仍是一个具有挑战性的过程。在任何医疗机构中为提供医疗服务而重用患者的健康数据，可以在加速诊断过程的同时降低医疗中的材料成本。为此，语义网技术可被整合到医疗服务中，用于医疗信息的建模与推理。在语义网中，信息具有明确定义的含义，从而促进计算机与人类之间更好的协作[1]。因此，数据以机器可理解格式表示，以支持更强大的知识表示。因此，本体被用于在不同系统之间共享和重用信息。

本体是对概念化的一种显式规范[2]。它通过定义所有相关概念以及这些概念之间的关系，来描述特定领域中的实体。语义网技术使用资源描述框架（RDF）[3]和网络本体语言（OWL）[4]作为信息描述语言，以描述元数据、定义本体，并对已定义的本体进行推理。将本体定义存储在特定的统一资源标识符（URI）使本体具有通用性、可共享性和可重用性。本体描述对于在人员或软件代理之间共享信息结构的共同理解至关重要，能够实现领域知识的重用，使领域假设显式化，将领域知识与操作知识分离，并支持对领域知识的分析[5]。

在开放世界假设下，状态包含正向和负向流，如果某个流未出现，则其值未知[6]。因此，信念状态恰好对应于满足该描述的可能世界集合。因此，信息仅在其存在的环境中具有意义，并且信息的可靠性会随着环境变化而变化。在采用开放世界假设的知识库中，对信息及其与其他来源依赖关系的访问会影响信息的意义和使用方式。本体开发者通过与领域专家合作来定义本体。不同的领域专家意味着不同的个人经验，这自然会导致同一领域出现不同的本体设计。尽管一些本体知识库可以连接这些不同定义，但如果领域定义未通过其元数据层次知识进行描述，则同一领域可能会存在多个离散的本体定义。因此，本体的连通性在为相关领域选择合适本体时成为一个关键瓶颈。

将领域信息存储在本体中，可以消除不同信息源之间的集成问题。语义网技术与本体所提供的协作性和连通性，使得信息的访问不再依赖于任何特定的数据结构。由于本体提供了唯一的定义，信息可根据使用该信息的领域上下文和系统被适配到不同的结构中。这种适配赋予了数据灵活性，使其可在任何信息系统中使用而无需对数据进行重新排列。然而，信息的访问是通过通用查询语言实现的，这些查询的响应时间会根据信息存储环境的内部结构而变化。

全球的医疗系统正在改变其信息系统，以实现患者信息的共享和重用，不仅限于信息生成的部门，还包括组织内部的不同部门以及不同组织之间。此外，医疗领域是少数拥有大量领域知识的领域之一。医疗信息作为大数据的可获得性不断提高且增长迅速，这有助于提升整体患者护理质量，并有利于提供更优质的个性化医疗服务。为了支持与语义网技术的互操作性，通过本体来定义和存储医疗数据，有望为医疗信息系统提供一种高效且有效的解决方案。传染病本体（IDO）[7,8],、唾液本体（ SALO）[9]和血液本体（BLO）[10]是采用形式化本体语言描述的医疗领域本体示例。

医疗领域信息量巨大，需要进行有效管理，以便快速做出决策并立即应对紧急卫生情况，其中时间至关重要。例如，发生交通事故的人员应被送往最近的医院。医生必须紧急获取患者的关键医疗信息，例如，了解其是否对任何物质或药物有过敏反应。高效地存储、插入、检索、更新和查询大型健康本体，以确保及时获取正确的信息，与本体的开发同样重要。因此，存储方法，特别是本体存储，对医疗信息系统性能至关重要。不同的三元组存储以不同方式存储和使用本体。加载新本体、查询分解以及查询结果时间可能因本体在相关三元组存储内部结构中的表示方式而异。

本研究根据 AllegroGraph [11] 和 Oracle 12c [12], 在健康领域信息方面的性能对这两种三元组存储进行了比较。AllegroGraph 和 Oracle 12c 被 W3C [13] 推荐为高效的三元组存储，其存储容量超过十亿三元组。因此，我们选择了这两种两个存储库，AllegroGraph 和 Oracle12c，用于对大型医疗数据进行性能评估。为此，执行了以下步骤： 探索健康领域的本体并选择合适的本体；
•将选定的本体加载到数据存储中；
•插入、更新和删除三元组；
•为健康领域选择相关查询； 执行所选查询，以根据响应时间比较两种数据存储的性能。

本文组织如下：第2节介绍相关工作。第3节描述评估的材料与方法。评估结果4中给出。最后，第5节总结贡献并展望未来工作方向。

相关工作

语义网是当前网络的扩展，其中信息具有明确定义的含义，从而促进计算机与人类之间更好的协作[14]。语义网的研究重点在于开发特定领域的本体以及语义推荐系统。近年来，基于本体的数据访问技术(OBDA)成为在关系型数据库上存储语义数据的一种流行方法。在[15],中提出了一种名为 Ontop的开源系统架构，用于通过相关领域的语义表示来查询关系数据源。Ontop的架构被用作在 [16]中开发的Optique平台的查询转换组件。Optique平台为最终用户提供可视化查询界面，通过解锁对大数据的访问来表达用户信息需求。

在文献中，有多种RDF数据存储用于存储、查询和操作这些本体。各种研究也对这些RDF数据存储进行了比较 [17–21]。除了比较RDF存储外，RDF加载器也在 [22] 中进行了比较。与我们的工作不同的是；[17–19] 使用生成数据，[17,18] 用于性能评估的数据量不足，[17–20,22] 未使用医疗数据，而 [19,22] 比较了AllegroGraph和Oracle 12c。这些研究使用不同的指标来查询RDF数据，但这些研究中没有一项比较三元组存储在执行构造查询时的性能。在本研究中，我们使用真实的医疗数据而非生成数据，并执行构造查询。

大学本体基准(UOBM) [23]的数据集被用作基准来比较RDF数据存储：Jena TDB [24],、 Virtuoso [25],、AllegroGraph [11],、BigOWLIM[26],、Eclipse RDF4J (Sesame) [27],和 Oracle [12]。基准测试使用了十四种不同的比较变量。根据其架构，RDF数据存储被分为简单型、基于内存型或基于数据库型；根据推理方法，分为前向式、后向式或混合链式推理方法。物理基准测试变量还包括本体加载时间、查询响应时间、查询语言、查询结果的准确性以及完整性。基于查询能力，讨论了简单协议和RDF查询语言(SPARQL) [28]与标准RDF查询语言之间的比较，以及复杂查询的可扩展性。此外，基准测试还包含针对推理引擎集成、集群能力、终端用户接口支持、关系型数据支持以及不同平台和操作系统之间互操作性的评估。

RDF三元组存储使用RDF对数据建模，存储RDF三元组，并通过SPARQL进行查询。在[33]中评估了RDF三元组存储4Store [29], BigData[30], OWLIM‐SE [31], Mulgara [32],和Virtuoso [33]。[33]中使用的数据集并非模拟生成，而是已在各种应用中使用的现实世界数据集。来自细胞周期本体 [34],、Allie本体[35],、PDBj（日本蛋白质数据库）[36],、UniProt（通用蛋白质资源）[37],和 DDBJ（日本DNA数据库）[38]的数据集被加载到RDF三元组存储中。在这些数据集中，DDBJ是最 大的数据集，包含100亿三元组。本体加载时间、内存位置、查询响应时间、查询准确性以及环境情况被用作比较指标。根据这些指标；细胞周期本体在4Store存储库中具有最快的加载时间，DDBJ本体在Virtuoso中具有最快的加载时间。基于内存分配；细胞周期本体在BigData存储库中占用最小的内存空间，而OWLIM‐SE在存储DDBJ本体时使用的内存最少。在比较查询响应时间时，细胞周期本体在所有存储库中均提供最快的响应时间。然而，在十九个查询中，有九个查询的最快响应时间属于OWLIM‐SE。本研究有助于比较不同数据集与不同的三元组存储库。但最常用的三元组存储库AllegroGraph和Oracle RDF三元组存储未包含在[33]。

在我们的研究中，通过使用基因本体 [39] 对 AllegroGraph 和 Oracle 12c RDF 三元组存储库 进行评估，以考察它们的查询能力和查询响应时间，同时对基因（GENE）、基因表达本体（GEXO）、转录调控本体（RETO）和基因表达调控本体（REXO）的加载时间进行评估。这些本体是医疗领域中最知名且使用最广泛的健康本体。基因本体揭示了生物体基因产物功能的相关信息。基因本体已被超过5000篇经审阅的文章引用，并被用于研究中以提供或验证假设 [40]。开发特定于医疗领域本体的研究人员会将其本体加载到 BioPortal（https://bioportal.bioontology.org/），这是一个知名的生物医学本体知识库。BioPortal 是一个开放访问的平台。基因表达本体（GEXO）整合了基因本体和分子相互作用本体（MI）的片段。转录调控本体（RETO）是用于基因转录调控领域的本体，同样整合了基因本体和 MI 本体的片段。基因表达调控本体（REXO）是用于基因表达调控领域的本体，该本体也整合了基因本体和 MI 本体的片段。GEXO、RETO 和 REXO 本体均基于基因本体。

AllegroGraph 是一种高性能的基于图的数据库，用作开发语义网应用的后端。它提供 Java、 Python、Lisp 和 Prolog 接口，并支持 SPARQL、RDFS++、Prolog 和 TwinQL 等语言。AllegroGraph 通过基于磁盘的存储实现高效的内存使用。AllegroGraph 支持 OWL 2 推理和 Prolog 语句。此外，AllegroGraph 定义了额外的功能，如社交网络分析、全文索引、用于权重的命名图、动态自动索引以及高效范围查询。

Oracle 12c 将本体存储在支持 RDF 和 RDFS 的关系型数据库中。从 Oracle 10gR2 版本开始， RDF 语句可以以其自然的三元组结构存储在数据库中。对 OWL 语言的支持始于 Oracle 11g 版本，并延续至 Oracle 12c 版本。Oracle 提供了完整支持，用于存储、查询和操作作为三元组的本体数据。Oracle 12c 还通过为本体定义规则来支持推理，此外还提供诸如 RDF 和 RDFS 的 Oracle 内置规则库。众所周知，创建索引可提高某些语义查询的性能。为此，Oracle 提供了内置函数以创建语义索引。尽管它是关系型数据库，但除了 SQL 查询外，还通过其语义子程序支持 SPARQL 查询。

材料与方法

资源描述框架（RDF，https://www.w3.org/RDF/）由万维网联盟（W3C， https://www.w3.org/）设计，是一种元数据模型。RDF 是用于网络资源中数据的概念性描述和建模的标准模型。在 RDF 中，每个源都通过一个三元组 来定义，该三元组由主语、谓语和宾语组成。传统数据仓库基于关系型数据库，用于处理关系数据。然而，在存储 RDF 数据时，应保持三元组数据结构以实现更优的表示和知识表示。为满足这一需求，已开发出多种RDF存储系统。本研究对 AllegroGraph 和 Oracle 12c 三元组存储进行了考察。

网络本体语言（OWL，https://www.w3.org/OWL/）也是一种W3C规范，旨在以语义丰富的方式表示知识以及事物之间的关系。OWL 表示由 XML（https://www.w3.org/XML/）、RDF 和 RDF 构造（RDF‐S，https://www.w3.org/TR/rdf‐schema/）通过提供形式化的语义和附加的描述结构。此外，语义网知识通过本体进行表达。因此，知识的内容不仅可由人类解读，也可由机器解读。这样一来，应用程序便能像人类一样处理这些知识。

基于描述逻辑的工具，例如 Fact [41]和 Racer [42],可用于推理小规模本体。然而，这些工具在查询大量数据时并不成功。因此，在考虑实际的语义知识库时，无法达到预期结果。为此，使用诸如 AllegroGraph、Oracle 12c、Virtuoso 和 4Store 等三元组存储来存储、更新和查询包含大量语义数据的本体。此外，如果知识库随着时间增长，查询时间也会增加。除了查询性能外，查询结果还必须完整且准确。

本研究中，考察了两种三元组存储，用于存储、更新和查询大型本体。为此，采用为医疗领域开发的本体来衡量语义知识库的性能。此外，还测量了信息访问时间，并对所访问的信息进行核对，以验证查询结果的准确性。同时，也测量了不同查询复杂度下的信息访问时间。因此，我们首先安装了相关工具，然后更新了医疗本体，并制定了比较标准。基于这些标准，我们构建了查询并对本体进行了查询。随后，对查询结果进行了比较和评估。性能测量在一台配置为2.40 GHz Intel(R) CPU、16 GB内存（Intel CPU，Kingston内存，华硕主板，土耳其伊兹密尔组装）的虚拟机上完成。以下各小节分别介绍AllegroGraph和Oracle 12c、所使用的数据集以及在这些数据集上执行的查询。

AllegroGraph 和 Oracle 12c

AllegroGraph [11]是一个RDF三元组存储库，用于存储RDF三元组。它被各种开源、学术研究和商业项目所使用[43–45]。AllegroGraph支持Java、Python、Ruby、Perl、C#、Lisp和Prolog接口，以及SPARQL、RDFS++和Prolog推理。AllegroGraph被用于存储多个不同的数据集。

Oracle 是一个知名的关系数据库管理系统。Oracle 10gR2 发布于 2005 年，是首个支持 RDF 和 RDF‐S 并允许在数据库中存储三元组的 Oracle 数据库版本。它为用户提供诸如将本体存储在关系型数据库中，并对这些用作语义网应用程序信息库的本体进行查询的功能。Oracle 11g（发布于 2007 年）在支持 RDF 和 RDF‐S 的基础上，还支持 OWL 本体定义语言。在本研究中，使用的是 2013年6月 发布的 Oracle 12c [12],。Oracle 12c 数据库的语义属性及其关系如图 1[46] 所示。从图 1 可以看出，Oracle 12c 能够同时包含语义数据和关系数据。

DB‐Engines（http://db‐engines.com/en/）收集并展示数据库管理系统的相关信息，并根据使用范围（如RDF存储、关系型数据库管理系统、键值存储、文档存储等）对它们进行排名。根据 DB‐Engines的数据，Oracle是关系型数据库管理系统以及整体数据库管理系统中最受欢迎的系统。Oracle是首个支持RDF存储的关系数据库管理系统。因此，使用Oracle作为RDF存储可以简化现有传统数据与三元组的集成。在DB‐Engines的RDF存储排名中，AllegroGraph位列第五。

AllegroGraph支持SPARQL，即W3C的标准查询语言。AllegroGraph还支持使用Prolog和 JavaScript等语言查询三元组。此外，它通过支持RDF、RDFS和OWL‐DL谓语提供推理机制。为了执行语义网规则，AllegroGraph集成了Racer这一语义网推理系统。

高效加载语义数据的方法是批量加载。在本研究中，使用批量加载将来自本体的语义数据插入到 Oracle 12c三元组存储中。然而，也可以通过SPARQL中的INSERT语句逐条添加语义数据。在 Oracle 12c中，可以高效地查询语义数据。此外，还可以利用本体对关系型和语义数据进行查询，以发现关系型和语义数据之间的关联。在加载语义数据后，可通过使用规则和推理引擎来增强语义数据的查询能力。推理能够根据数据和规则提供逻辑结果。但在本研究中，未对推断出的三元组进行评估，以避免使评估过程更加复杂。

数据集

在本研究中，我们使用了以下本体：基因表达调控本体（REXO）[47],转录调控本体（RET O）[48],基因表达本体（GEXO） [49],细胞周期本体（CCO） [34],和基因本体 [39]。这些本体的类、三元组、个体、属性和深度数量如表 1所示。

本体特征	REXO	RETO	GEXO	CCO	GENE
三元组	2,124,784	1,936,933	2,404,581	11,315,866	1,381,808
类	158,308	147,807	166,325	277,764	53,234
个体	0	0	0	0	136,524
属性	13	13	13	13	75
深度	21	21	21	21	6

如表1所示，大多数医疗本体大约有200万条三元组。尽管本体中的三元组数量较多，但很难找到具有足够个体数量的数据集用于评估。现有文献中的本体在个体数量方面均不充足。因此，我们使用 GENE、GEXO、RETO和REXO本体来比较AllegroGraph和Oracle 12c的加载时间。由于 AllegroGraph的免费版本仅允许加载最多500万条三元组，CCO本体无法在我们的评估中加载。由于GENE本体包含一定数量的个体，而其他本体没有任何个体，因此我们使用GENE本体来比较查询响应时间，而其他本体因无个体而不适用于此比较。查询采用SPARQL 1.1语言编写[50]并在GENE本体上执行。最后，测量了查询响应时间以进行比较。

查询

在此小节中，对执行的查询进行了解释。在本研究中，我们为评估创建了五个查询。这五个查询的选择基于语义上递增的难度。此外，这些查询的结构基于用于测试RDF存储的基本结构属性案例，如[33]中所述。然而，在本研究中，这五个查询是专门为基因本体构造的，而[33]中提到的案例是为细胞周期本体构造的[34]。

第一个查询是一个简单的复合三元组查询。该查询用于测量三元组存储在简单查询使用情况下的响应时间。

查询1 ：这是一个简单的多句查询，如图 2所示。 查询具有分子_功能、同义词为“MOO活性”且类型为GO的基因_0016701。查询1是一个简单的“GENE”查询。通过创建第一个查询，我们旨在测量三元组存储对包含多个内部查询的简单查询的响应。

查询2 ：第二个查询如图3所示，通过使用“UNION”操作符合并两个简单查询构造而成。“ UNION”操作符用于测量将查询空间合并为单个结果集时每个RDF存储的响应时间。查询2返回的结果与查询1相同。这两个查询用于捕捉三元组存储对以不同格式编写的相同查询的响应方式。

查询3 ：在第三个查询中，研究了RDF三元组数据存储之间的差异。为此，在“过滤器”选项中使用了 REGEX函数。REGEX是一种布尔字符串函数，可根据给定的字符串返回结果。在此查询中，基因是分子_功能，GO的类型_0016701，并且具有以“my o”开头的确切同义词正在被查询。图4中所示的查询3用于测量字符串处理能力 Oracle 12c 和 AllegroGraph 三元组存储在字符串函数和索引方面的能力。

查询4 ：在图5所示的第四个查询中，使用了“FILTER”选项 R查询3中的EGEX函数被替换为一个完整的单个值。在查询4中，仅 i字符串值与给定值匹配的个体作为结果集返回。在 o为了使查询更复杂，添加了多个“FILTER”选项的值，并 c通过“AND”操作连接。因此，每个三元组数据存储的响应超过一个“FILTER”选项可以进行评分。

查询5 ：在第五个查询中，验证的是“构造”查询而非“选择”查询。构造查询用于创建满足由 WHERE子句限制的结果集的图响应。在三元组存储的分层结构内部，构造查询难以去碎片化，可能导致无限循环并返回无关结果。因此，在查询5中，使用构造查询来揭示每个三元组存储从其语义模型生成给定查询的语义图的速度。尽管使用了简单的“构造”查询以返回图结果，但仍构建了一个包含多个“过滤器”选项的复杂查询。查询5如图6所示。在此查询中考察了AllegroGraph与Oracle 12c在使用任意给定过滤器选项创建图时的差异。在查询5中，正在查询具有以字母“malt”开头的同义词的基因。由匹配的基因及其父类构成的图将作为结果返回。

结果与讨论

第3节中给出的查询首先在AllegroGraph SPARQL端点上进行实验。整个加载和查询时间在 Jena API [51]中进行评估，该API使用Java编程语言编写。Jena使用描述逻辑创建连通查询空间，并提供接口以在Java中使用和操作本体。在批量加载语义数据之前，必须确保加载的本体完整且准确，即本体不应包含任何冲突信息。本体中的任何不一致性都会导致加载错误，并需要在将本体加载到三元组存储之前予以纠正。尽管本体采用开放世界假设，但本体结构是通过封闭世界假设来描述的，因此本体中的不一致性可能导致本体模型失败。AllegroGraph和Oracle 12c在表示和存储本体结构时均采用开放世界假设。此外，它们都支持Jena。因此，将本体结构转换为Jena可能会导致语义丢失。然而，为了比较这些RDF三元组存储的查询性能，这是一个可以接受的风险。

通过Jena加载和使用本体始于将本体结构与Jena描述相匹配，并以将此Jena描述空间保存到本地数据存储结束。在查询本体模型之前，必须完成与三元组数据存储服务器的连接、Jena本体模型的初始化以及将连接绑定到模型。完成这些阶段后，可以测量查询响应时间。随后，查询开始执行针对 Jena模型的查询，查询时间以从三元组数据存储返回查询结果至Jena结果集为止。

由于AllegroGraph支持Jena API，因此使用Jena来计算GENE、GEXO、RETO和REXO本体加载到三元组数据存储中的加载时间差异。AllegroGraph和Oracle 12c的加载时间如表2所示。所有加载时间均已转换为秒。

本体	AllegroGraph	Oracle 12c
GENE	62.3 秒	1683.2 秒
GEXO	33.8 秒	1823.2 秒
RETO	37.8 秒	1707.5 秒
REXO	44.8 s	1694.5 s

创建Jena本体模型并将本体加载到该模型后，进行查询的构造。在表3中，给出了每个查询的查询时间。整个查询时间以Java世界时间衡量，并转换为毫秒。

查询	AllegroGraph	Oracle 12c
1	678.7 毫秒	51.7 毫秒
2	220.5 毫秒	52.2 毫秒
3	968.4 毫秒	63.0 毫秒
4	47.9 毫秒	54.8 毫秒
5	13360.4 毫秒	18486.7 毫秒

AllegroGraph 和 Oracle 12c 可用于存储相似的数据，但它们对同一数据集的加载时间和查询时间有所不同。在表2中可以明显看出，这两种数据存储的加载时间存在较大差异。造成这种差异的原因在于这些数据存储的基础架构及其设计目的。Oracle 12c 根据其传统数据库结构来存储结构化数据。而 AllegroGraph 是一种基于图的纯 RDF 三元组存储。因此，在加载本质上是基于图描述的本体结构时，AllegroGraph 具有更好的性能。随着三元组数量的增加，加载时间也随之增加。然而，三元组的数量对 Oracle 12c 的影响不像对 AllegroGraph 那样显著。此外，两种三元组存储的查询结果准确性相同。图7和8展示了加载时间和查询时间的图形表示。

在图8中，查询时间显示Oracle 12c对基本且已索引的简单查询（如查询1–3）的响应速度比 AllegroGraph更快。Oracle 12c对基本且已索引的查询响应更迅速。然而，对于更复杂的查询（如查询4和查询5），其响应速度较慢。AllegroGraph的响应时间不依赖于查询的复杂性。因此，查询空间中的三元组数量不会影响AllegroGraph的响应时间。

因此，与Oracle 12c相比，AllegroGraph是加载医疗本体更高效的三元组存储。然而，对于长期运行的软件系统应用，频繁的软件维护是一种不希望出现的情况。用于描述系统信息库的本体只需一次性加载到三元组存储中，之后系统信息通过插入或删除实例来增长，而无需批量加载。由于每个人在其一生中都会产生大量的健康记录，医疗信息是大数据应用领域的一个典型示例。此外，由于遗传因素对诊断具有重要意义，个人健康记录在个体去世后仍可被查询，以用于构建家族健康画像。另外，时间在诊断和治疗中是最关键的因素之一。因此，及时访问所需的健康数据至关重要。考虑到以上所有因素，三元组存储的查询响应时间成为选择适用于医疗领域的三元组存储的关键因素。结果表明，Oracle 12c 在查询时间上优于 AllegroGraph。因此，当查询响应时间具有重要意义时，Oracle 12c 作为三元组存储将更适用于实时医疗信息系统。

结论

AllegroGraph和Oracle 12c是用于存储大数据集的RDF三元组存储。这两种三元组存储均被广泛用于存储不同类型的数据。AllegroGraph可以存储基于图的数据和RDF本体。Oracle 12c借助其语义网扩展，用于存储与RDF和OWL本体相关的结构化数据。在本研究中，比较了AllegroGraph和 Oracle 12c RDF三元组存储在本体加载和查询时间上的差异，并讨论了这些差异背后的原因。

AllegroGraph 和 Oracle 12c 都能针对同一数据集准确响应查询。Oracle 12c 的加载时间比 AllegroGraph 慢。相反，由于其设计目的，AllegroGraph 在加载和匹配 RDF/OWL 数据方面比 Oracle 12c 更快。Oracle 由于其分层架构，在大数据集上的加载时间较慢。然而，当数据已加载完成后，Oracle 12c 的查询速度比 AllegroGraph 更快。尽管 Oracle 12c 在基本查询中响应时间较快，但在处理基于描述逻辑或基于图的本体结构的查询时会变慢。当查询空间变得足够大或更加完整时，AllegroGraph 也会如预期般变慢。

除了上述所有比较之外，AllegroGraph 和 Oracle 12c 都能够准确存储大型医疗数据集并高效地对其进行查询。综上所述，AllegroGraph 是用于存储需要反复加载到三元组存储中的快速变化数据集的更合适候选方案。Oracle 12c 更适合存储静态的大数据集。此外，当查询时间比加载时间更为重要时，Oracle 12c 是比 AllegroGraph 更可行的三元组存储。