在关系 (MySQL) 和 NoSQL (MongoDB 和存在) 中执行复杂度增加的查询大小-增长的 ISO/EN 13606 标准化的电子病历数据库
March 19th, 2018
本研究比较关系和非关系 (NoSQL) 标准化的医疗信息系统。使用双倍大小的数据库计算查询此类数据库管理系统 (DBMS) 的响应时间的计算复杂性。这些结果有助于讨论每个数据库方法对不同方案和问题的适用性。
本实验的总体目标是比较关系和非关系（不仅仅是结构化查询语言或 NoSQL 数据库系统）的计算复杂性，这些复杂性是通过它们对复杂性不断增长的查询的响应时间来衡量的。此方法可以帮助回答数据库管理系统领域中的关键问题，例如哪种类型的查询更适合哪种类型的数据库系统。这种技术的主要优点是它将响应时间与每种类型的双数据库查询以及要计算的计算复杂性进行比较，因此这种方法可以提供对 MySQL MongoDB 和多余数据库系统的见解。
它也可以应用于其他基于关系文档的原生 XML 系统，如 SQL Server 和 base X。当我们必须为电子健康记录系统选择持久系统时，我们第一次听说他们使用这种方法。在关系型 MySQL 数据库中使用非自动构建的索引设计和执行增加复杂性的查询。连接到 MySQL 服务器并选择数据库名称。
在 index 字段中选择关系表，然后打开 structure 选项卡。选择要构建索引的列，然后单击 index。将出现构建索引的 SQL 句子，后跟一条消息，说明已成功构建句子。
要执行第一个查询，请选择数据库名称并打开 SQL 选项卡。输入第一个查询的 SQL 代码，然后单击 continue 。结果列表的第一个屏幕将显示，其中包含查询执行时间的消息。
要设计和执行增加复杂性的查询和非关系性查询，不仅要启动 NoSQL Mongo 数据库，还要启动 Mongo 数据库图形用户间阶段，并从 DOS 系统窗口启动 Mongo 数据库 2.6 服务器执行 Mongo 程序。通过端口 27017 将 Mongo 数据库图形用户界面连接到本地主机服务器，然后选择连接菜单。输入连接的名称，在数据库服务器文本框中输入本地主机位置，然后单击 connect。
应显示包含当前数据库的树。扩展 Mongo 数据库。选择感兴趣的集合并打开 collection 菜单。
要执行第一个 Mongo 数据库查询，请双击查询生成器和查询字段按钮。在查询面板的字段文本框中输入 Mongo 数据库查询的字段，并在查询面板的值文本框中输入查询的值。双击查询生成器的 projection 字段，然后在 projection 文本框中输入第一个投影。
双击 projection 字段以添加新的 projection 文本框并输入第二个投影，然后单击 play，以执行查询，并在 query code 选项卡中可视化查询代码。结果的详细信息将在 explain and results 选项卡下查看。要在 NoSQL EXist 数据库中设计和执行复杂性不断增加的查询，请启动 EXist 数据库并打开 java admin 客户端。
单击 "，连接到数据库，然后选择数据库。单击，使用 X 路径查询数据库。将出现 consult 对话框。
然后执行第一个 X 路径查询。在此表中，显示了对实际标准化电子健康记录摘录执行的六种不同的查询，其中包含有关患者问题的信息，包括他们的姓名、初始和最终日期以及严重程度。每个数据库管理系统中 6 个查询和 3 个大小加倍的数据库的平均响应时间表明，在非关系数据库的所有查询中，计算复杂性存在较长的线性行为，这在关系对象关系映射数据库分析中是未观察到的。
将 Mongo 数据库结果与原型的相似查询和数据库大小进行插值关系映射结果，在两个数据库系统中为第一个查询生成相同的结果，但在第三个查询中使用 Mongo 数据库确定更有利的结果。在并发实验中，Mongo 数据库在吞吐量和响应时间方面都优于 MySQl 数据库，Mongo 数据库在并发性方面的表现优于隔离数据库，并且在并发执行中是一个令人印象深刻的数据库。嗯，我确实认为这一点很重要，记住在客户端执行查询时，将所有服务器本地维护在同一台机器上。
按照此过程，可以执行其他方法（例如使用其他类型的数据库系统）来回答其他问题，例如某种类型的数据库是否可以存在并在单个和所有患者查询中获胜？在它开发之后，这项技术为算法复杂性领域的研究人员铺平了一条道路，以探索不同类型数据库系统中的比较数据库性能。观看此视频后，您应该对如何在类型非常不同的数据库系统的大小不断增长的数据库中执行增加复杂性的查询有一个很好的理解。
概述
本研究通过分析关系型和非关系型（NoSQL）数据库管理系统对复杂度增加的查询的响应时间，比较它们的计算复杂性。研究结果为不同场景下不同数据库方法的适用性提供了见解。
关键研究组成部分
科学领域
- 数据库管理系统
- 计算复杂性
- 信息系统
背景
- 该研究聚焦于关系型（SQL）和非关系型（NoSQL）数据库系统。
- 目的是了解哪些类型的查询最适合每种数据库系统。
- 关系型数据库包括MySQL等系统，而NoSQL数据库包括MongoDB和EXist。
- 先前的研究已经强调了为电子健康记录选择适当数据库系统的重要性。
研究目的
- 比较关系型和非关系型数据库的响应时间。
- 分析数据库大小增加时查询的计算复杂性。
- 提供可以指导特定应用选择数据库系统的见解。
使用的方法
- 在关系型和非关系型数据库上设计并执行复杂度增加的查询。
- 使用MySQL进行关系型数据库查询，使用MongoDB进行NoSQL查询。
- 进行并发实验以比较吞吐量和响应时间。
- 分析不同数据库大小和类型的平均响应时间。
主要结果
- 研究发现非关系型数据库在计算复杂性方面表现出线性行为。
- 在某些查询中，MongoDB比MySQL表现得更好。
- 在并发测试中，MongoDB在吞吐量和响应时间上都超过了MySQL。
- 研究结果表明，数据库的选择可能会根据查询复杂性显著影响性能。
结论
- 这项研究为基于查询复杂性评估数据库性能提供了一个框架。
- 它突出了NoSQL数据库在特定场景下的优势。
- 未来的工作可以探索其他数据库类型及其性能特征。
常见问题
Executive Industry Relevance
This study provides a framework for evaluating database performance based on query complexity, which is critical for biopharma R&D when selecting systems for managing standardized EHR data. Understanding computational complexity helps inform decisions about database suitability for tasks like phenotypic screening data storage, translational biomarker tracking, and preclinical model data integration. The findings support risk-adjusted prioritization of database technologies that ensure reproducibility and scalability across discovery workflows.
Strategic Applications in Biopharma R&D
Early Discovery & Target Validation
- Scientific Value: Enables hypothesis testing about data storage efficiency for complex biological datasets.
- Operational Value: Supports selection of database systems that maintain data consistency during iterative target validation experiments.
Screening & Assay Development
- Scientific Value: Provides quantitative benchmarks for query response times under increasing data loads relevant to high-throughput screening outputs.
- Operational Value: Informs assay database design to ensure linear scalability as compound and readout volumes grow.
Translational & Preclinical Research
- Scientific Value: Highlights how database choice impacts the ability to restore EHR data in original form, supporting data integrity in longitudinal studies.
- Operational Value: Guides standardization of data retrieval processes across discovery and preclinical teams using consistent query performance expectations.
Pipeline & Workflow Integration
The method positions database evaluation as a foundational step in discovery biology, enabling reliable data handling from early target identification through lead optimization and preclinical validation.
- Discovery Biology: Supports hypothesis testing regarding data system performance under growing complexity of biological datasets.
- Screening: Describes how response time analysis informs readiness of databases for screening campaign data storage and retrieval.
- Analytics: Highlights average response time measurements as a quantitative output for comparing database systems under standardized query loads.
- Translational Research: Connects database performance to continuity of EHR data use cases, such as edition and visualization, which require consistent retrieval fidelity.
- Enterprise Reuse: frames the protocol as a reusable capability for ongoing assessment of database systems as EHR standards and data volumes evolve.
Operational & Enterprise Impact
- Scientific Value: Predictive confidence in database behavior under increasing data complexity reduces mechanistic ambiguity in data-driven research.
- Operational Value: Standardization of query performance evaluation enables reproducible database selection across projects and sites.
- Strategic Value: Better go/no-go decisions on database adoption reduce late-stage integration risks and capital inefficiency.
- Portfolio Impact: Risk-adjusted prioritization of database technologies aligns with advancement decisions in data-intensive R&D pipelines.
Implementation Considerations
- Requires expertise in database administration and query design across relational and NoSQL platforms.
- Needs instrumentation capable of executing and timing complexity-increasing queries on MySQL, MongoDB, and EXist systems.
- Demands cross-team standardization on query complexity metrics to ensure comparable performance assessments.
- Involves adaptation considerations when applying the protocol to other database systems like SQL Server or base XML platforms.
- Includes practical limitations such as the lack of direct comparison with archetype relational mapping under identical data conditions, relying instead on interpolation for insights.
