NoSQL数据库的性能评估：案例研究外文翻译资料

英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料

NoSQL数据库的性能评估：案例研究

John Klein, Ian Gorton, Neil Ernst, Patrick Donohoe Kim Pham, Chrisjan Matser

软件工程学院 远程医疗与先进技术研究中心

卡内基梅隆大学 美国陆军医学研究与物资司令部

匹兹堡，宾夕法尼亚州，美国 弗雷德里克，马里兰州，美国

{jklein, igorton, nernst, pd}@sei.cmu.edu kim.solutionsit@gmail.com,cmatser@codespinnerinc.com

概要

特定NoSQL数据库的选择强加了特定的分布式软件架构和数据模型，并且是整个系统吞吐量的主要决定因素。 NoSQL数据库性能又受到数据模型和查询功能如何适应应用程序用例的强烈影响，需要系统特定的测试和表征。本文介绍了一项研究的方法和结果，该研究选择了三个NoSQL数据库，用于大型分布式医疗保健组织。虽然方法和研究考虑了影响选择决策的一致性，可用性和分区容差（CAP）权衡以及其他质量属性，但本文报告了绩效评估方法和结果。在我们的测试中，典型的工作负载和配置产生的数据库产品之间的吞吐量从每秒225到3200次不等，而读取操作延迟变化5倍，写入延迟为4倍（吞吐量最高的产品提供最高延迟）。我们还发现，与最终的一致性相比，强大的一致性将吞吐量降低了10-25％。

类别与主题描述

C.4 [系统性能]：测量技术，性能属性，

一般条款：性能，测量。

关键词：性能，NoSQL，大数据

1. 介绍

COTS产品选择在软件工程[1] [2] [3]中得到广泛的研究。 在具有多个竞争产品的复杂技术景观中，组织必须平衡技术选择过程的成本和速度与决策的忠实度[4]。 虽然在应用程序中选择复杂的组件很少有一个“正确的”答案，但选择不合适的组件可能是昂贵的，由于返工而降低下游生产力，甚至导致项目取消。对于大规模，大数据系统尤其如此 由于其复杂性和投资规模。

在这种情况下，COTS选择用于大数据应用的NoSQL数据库提出了几个独特的挑战：

• 这是一个​​早期的架构决策，不可避免地会由于对需求的不完全了解;
• NoSQL产品的功能和特点差别很大，广泛的比较困难;
• 以生产规模进行性能分析的原型设计通常是不切实际的，因为这将需要数百台服务器，多TB数据集和数千万个客户端;
• 解决方案空间迅速变化，新产品不断涌现，现有产品每年发布多个版本，不断发展的功能集。

在最近的一个医疗保健提供者的项目中，我们面临着这些挑战，希望采用NoSQL技术进行电子健康记录（EHR）系统。该系统支持全球超过100家设施的900多万患者的医疗保健服务。数据目前每月增长超过1 TB，所有数据必须保留99年。在本文中，我们概述了我们为大数据系统设计的技术评估和选择方法。然后，我们描述我们为上述医疗服务提供者所进行的一项研究。我们介绍研究背景，我们的评估方法，以及广泛的性能和可扩展性测试的结果以及详细的功能比较。我们得出结论，描述了NoSQL方法带来的软件架构和设计的一些挑战。本文的具体贡献如下：

• 企业可以采用严格的方法来评估NoSQL数据库的性能和可扩展性。
• 性能和可扩展性结果，经验性地证明了在我们测试的数据库的能力支持我们的医疗保健客户的要求的吞吐量高达14倍的可变性和5倍的延迟。

1. EHR案例研究

我们的方法受到早期中间件评估工作的启发[5] [6]，被定制以解决大数据系统的特点。 基本的主要步骤如图1所示，并概述如下：

2.1 项目背景

我们的客户是一家大型医疗保健提供商，开发新的电子医疗记录（EHR）系统，以取代现有系统，该系统在世界各地访问集中式关系数据库的场所使用厚客户端应用程序。 客户决定考虑NoSQL技术的两个具体用途，即：

• EHR系统的主要数据存储
• 每个站点的本地缓存，以提高请求延迟和可用性

由于客户对这些用例熟悉RDBMS技术，但没有使用NoSQL的经验，他们指示我们将技术评估仅集中在NoSQL技术上。

图1 大数据的重量级评估和原型（LEAP4BD）

• 1. 规定要求

我们进行了利益相关者研讨会，以引出需求和驱动因素。 出现的一个关键需求是了解每个候选NoSQL数据库可实现的固有性能和可扩展性。

我们与客户合作，为EHR系统定义用例，构成了我们的性能和可扩展性评估的基础。 第一个用例是检索特定患者的最近的医疗测试结果。 因为所有使用EHR进行病人护理决定的临床医生都需要看到与该患者相同的信息，无论位置如何，所以第二次使用案例为所有读者提供了强有力的一致性。

2.3 选择候选的NoSQL数据库

我们的客户特别有兴趣了解不同的NoSQL数据模型（键值，列，文档，图表）将支持其应用程序，因此我们从每个类别中选择一个NoSQL数据库进行详细调查。 我们后来排除了图形数据库，因为它们不支持客户要求所需的水平分区。 基于各种产品的功能评估，我们将Riak，Cassandra和MongoDB作为我们的三种候选技术，因为它们是每个NoSQL类别的市场领导者。

• 1. 设计和执行性能测试

复杂数据库平台的全面评估需要与每个平台进行原型开发，以显示性能和可扩展性功能，并进行比较[4]。 为此，我们开发并执行了一个系统的程序，用于对我们评估的三个数据库进行“苹果对比”比较。 根据需求步骤中定义的用例，我们：

• 定义了一个一致的测试环境，用于评估每个数据库，包括服务器平台，测试客户端平台和网络拓扑。
• 将患者记录的逻辑模型映射到每个数据库的数据模型，并使用大型合成测试数据集加载数据库。
• 创建一个负载测试客户端，执行为每个用例定义的数据库读写操作。 该客户端可以发出许多并发请求，以表征每个产品如何响应请求负载增加。
• 使用测试客户端对数据库执行指定负载的定义和执行的测试脚本。

在多个分布式配置上执行测试用例以测量性能和可扩展性，从单个服务器的基线测试到分割和复制数据的九个服务器实例。

基于这种方法，我们能够生成测试结果，以便比较该客户的EHR系统的每个数据库的性能和可扩展性。 我们的测试结果并不是通用的基准测试，因此不会使用其他类型的工作负载，服务器配置和数据集大小进行测试。

1. 评估设置

3.1 测试环境

我们测试的三个数据库是：

• MongoDB version 2.2,文件存储

(http://docs.mongodb.org/v2.2};

• Cassandra version 2.0,列存储

(http://vvww.datastax.com/documentation/cassandral2.0);

• Riak version 1.4,键值存储

(http://docs.basho.com/riak/1.4.10}.

在两个数据库服务器配置上执行测试：单个节点服务器和代表生产部署的九节点配置。 单个节点测试验证了每个数据库的基本测试环境。 九节点配置使用了一个拓扑，表示跨三个数据中心的地理位置分布式部署。

数据集在三个节点之间分割（即“分片”），并复制到两个另外的三个节点组。 我们使用MongoDB的主要/次要功能，以及Cassandra的数据中心意识分配功能。 Riak不支持这种“3x3”数据分发，所以我们使用了一个扁平化的配置，其中数据在所有九个节点上分片，每个分片的三个副本存储在九个节点。

所有测试均使用Amazon EC2云（http://aws.amazon.com/ec2）进行。数据库服务器在“ml.large”实例上执行，数据库数据和日志文件存储在连接到每个服务器的不同EBS卷上 实例EBS卷未配置EC2 IOPS功能，以最小化每个测试配置中使用的调整参数。服务器实例运行CentOS操作系统（http://vvww.centos.org），测试客户端也执行 一个“ml.large”实例，并且还使用CentOS操作系统，所有实例都在相同的EC2可用区域（即相同的云数据中心）。

• 1. 映射数据模型

我们使用HL7快速医疗互操作性资源（FHIR）（http：www.hl7.org/implement/standards/fhir/）进行我们的原型设计。逻辑数据模型由FHIR患者资源组成（例如人口统计信息，如姓名，地址，和电话号码），以及表示为FHIR观察资源（例如，测试类型，结果数量和结果单位）的实验室测试结果。每个患者记录与相关测试结果记录之间存在一对多关系合成数据该数据集包含100万个患者记录和1000万个实验室结果记录，每个患者有0到20个测试结果记录，平均为7个。“这些患者和观察资源被映射到数据我们测试的每个数据库的模型，这个数据集大小是在保真度（实际系统可能更大，取决于数据老化和归档策略）与测试执行时间之间的折衷和为不同数据模型和测试配置构建和加载数据集的大量成本。

• 1. 创建负载测试客户端

测试客户端基于YCSB框架[7]，它提供了管理测试执行和执行测试测量的功能。对于测试执行，YCSB具有默认数据模型，数据集和工作负载，我们使用特定于用例数据和请求的实现修改和替换。

我们能够利用YCSB的测试执行管理功能来指定要执行的操作总数，以及工作负载中读写操作的组合。测试执行功能还允许使用多个执行线程创建并发客户端会话。

YCSB内置测量框架测量执行的每个操作的延迟时间，作为从请求发送到数据库之间的时间，直到从数据库接收到响应。 YCSB报告框架分别记录读写操作的延迟测量。延迟分布是大数据系统的关键可扩展性测度[8] [9]，因此我们收集了平均值和第95百分位数值。

我们扩展了YCSB报告框架，以报告每秒的运营总体吞吐量。该测量通过将执行的操作总数（读取加写）除以工作负载执行时间，从第一操作开始测量到在工作负载执行中完成上次操作，不包括预测试设置和测试后清理时间。

• 1. 定义并执行测试脚本

利益相关者研讨会确定了EHR系统的80％读取和20％写入操作的典型工作负载。对于这种操作组合，我们定义了一个读取操作来检索单个患者的五个最近的观察结果，以及为单个现有患者插入一个新的观察记录的写入操作。

我们的客户也有兴趣在本地缓存中使用NoSQL技术，因此我们定义了一个只写入工作负载，代表当日计划约会病人的记录集中主要数据存储的每日下载。我们还定义了一个只读工作负载，以将缓存刷新回集中的主数据存储。

每个测试运行所选的工作负载三次，以便最小化云基础设施中任何瞬态事件的影响。对于这三个运行中的每一个，使用不同数量的客户端线程（1，2，5，10，25，50，100，200，500和1000）重复工作负载执行。通过对每个线程计数的三次运行进行平均测量，对结果进行后处理。

1. 性能和可扩展性结果

我们在这里报告一个九节点配置的结果，反映了典型的生产部署。 如上所述，我们还测试了其他配置，从单个服务器到九个节点集群。 单节点配置的可用性和可扩展性限制使生产使用不切实际，然而，在下面的讨论中，我们将单节点配置与分布式配置进行比较，以提供数据库分布式协调机制和资源使用效率的见解，以及 通过添加更多节点与使用更快的节点与更多存储来指导缩放之间的折衷。

定义配置需要进行多项设计决策。第一个决定是如何在服务器节点之间分配客户端连接。 MongoDB使用集中的路由器节点，所有客户端连接到该单个节点。 Cassandra的数据中心感知分布功能用于创建三个每个三个节点的子集群，客户端连接在一个子集群中的三个节点之间均匀分布。在Riak的情况下，产品架构只允许客户端连接在整个九个节点的整个集合中均匀分布。然而，另一种可能是在没有复制的三个节点上测试Riak，Riak架构中的其他限制导致此配置的性能极差，因此使用了九节点配置。

第二个设计决定是如何实现所需的一致性水平，

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[137624]，资料为PDF文档或Word文档，PDF文档可免费转换为Word