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

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

抽象

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

类别和主题描述符

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

一般条款：性能，测量。 关键词：性能，NoSQL，大数据

介绍

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

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

（c）2015年计算机协会。 ACM承认，这笔捐款是由美国政府的雇员，承包商或附属机构撰写或合作的。 因此，美国政府保留出版物或复制本条款的非独占性，免版税权利，或允许其他人出于政府目的。

2015年2月1日，PABS15，美国德克萨斯州奥斯汀版权所有

bull;这是一个早期的架构决策，不可避免地会因为对需求的不完全了解而做出;

bull;NoSQL产品的功能和特点差异很大，使得广泛的比较困难;

bull;以生产规模进行性能分析的原型设计通常是不切实际的，因为这将需要数百台服务器，多TB数据集以及数千万个客户端;

bull;解决方案空间迅速变化，新产品不断涌现，现有产品每年发行多种版本，并且不断发展的功能集。

在最近的一个医疗保健提供者的项目中，我们面临着这些挑战，希望采用NoSQL技术进行电子健康记录（EHR）系统。该系统支持全球超过100家设施的900多万患者的医疗保健服务。数据目前每月增长超过1 TB，所有数据必须保留99年。

在本文中，我们概述了我们为大数据系统设计的技术评估和选择方法。然后，我们描述我们为上述医疗服务提供者所进行的一项研究。我们介绍研究背景，我们的评估方法，以及广泛的性能和可扩展性测试的结果以及详细的功能比较。我们得出结论，描述了NoSQL方法带来的软件架构和设计的一些挑战。本文的具体贡献如下：

bull;组织可以遵循的严格的方法来评估NoSQL数据库的性能和可扩展性。

bull;性能和可扩展性的结果，经验性地证明了我们测试的数据库能力支持我们医疗保健客户需求的高达14倍的吞吐量和5倍的延迟。

EHR案例研究

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

2.1项目背景

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

bull;EHR系统的主要数据存储

bull;每个站点的本地缓存，以改善请求延迟和可用性

客户对这些用例熟悉RDMS技术，但是使用NoSQL没有经验，所以我们将技术评估仅专注于NoSQL技术

图1 - 大数据轻量级评估和原型开发（LEAP4BD）

.2指定要求

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

NoSQL数据库。

我们与客户合作，为EHR系统定义了两个驾驶用例，构成了性能和可扩展性评估的基础。第一个用例是检查患者的接受医疗测试。当为病人编写新的媒介测试结果时，第二个用例是为所有读者提供强大的一致性，因为使用E HR进行病人护理决策的所有临床医生都需要查看该患者的信息，无论如何位置。

.3选择候选NoSQL数据库

客户特别感兴趣的是了解不同的NoSQL数据模型如何支持他们的应用，所以我们从每个类别中选择一个NoSQL数据库进行详细的调查。我们后来统治了图形数据，因为它们并不支持客户要求的水平定位。基于各种产品的功能评估，我们将riak，assandra和mongoDB作为我们的三种候选技术，作为这些都是每个NoSQL类别的市场领导者。

.4设计和执行性能测试

对复杂数据进行全面评估

设计和执行性能测试

复杂数据库平台的全面评估需要与每个人一起转型，以表彰性能和可扩展性能力和允许比较[4]。为此，我们开发了并执行“苹果苹果”的系统程序比较我们评估的三个数据库。根据需求步骤中定义的用例，我们：
bull;定义一个一致的测试环境，用于评估每个测试环境
数据库，其中包括服务器平台，测试客户端平台，
和网络拓扑。

bull;将病人记录的数学模型映射到每个数据库的数据模型，并使用大型合成数据集加载数据。

bull;创建一个负载测试客户端，执行为每个用例定义的数据库读写操作。客户端可以发出许多并发请求，每个产品在请求负载增加时响应。
bull;使用测试客户端对数据库执行指定负载的定义和执行的测试脚本。

测试程序在几个分布式配置上执行，以测量性能和可扩展性，从单个服务器上的基线测试到硬件和复制数据的九个服务器状态。

基于这个想法，我们能够产生测试结果，可以比较本客户EHR系统的每个数据库的性能和可扩展性。 我们的结果并不是通用的基准测试，所以使用其类型的工作负载，服务器配置和数据集大小进行的测试没有执行。

E VALUATI ON SETUP

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

bull;MongoDB版本2 .2，文件存储（http：//docs.mongodb.org/v2.2/）;
bull;Cassandra 2.0版，一个列存储
（http：//www.datasta x.com/documentation/cassandra/2.0）;
bull;Riaversion 1.4，一个关键价值商店
（http：//docs.basho.co m / riak / 1.4.10 /）。

在两个数据库服务器配对上执行测试：单个节点服务器和代表生产部署的九节点配置。单个节点测试验证我们的基本测试环境或每个数据库。九节点配置使用了一个拓扑，它代表了三个存在者的地理分布式部署。
数据集在三个节点之间分割（即“分片”），并复制到两个另外三个节点组。我们使用MongoDB的主要/次要功能，以及Cassandra的数据中心意识分配功能。 Riak不支持这种“3x3”数据分发，所以我们使用了一个扁平化的配置，其中数据在所有九个节点上都被覆盖，每个分片的三个副本存储在九个节点之间。

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

3.2映射数据模型

我们使用了HL7 Fast Healthcare互操作性资源
（FHIR）（http：//www.h l7.org/implement / standards / fhir /）为我们
原型。逻辑数据模型由FHIR患者资源（例如名称，地址和电话号码等人口统计信息）组成，实验室测试结果表示为FHIR观察资料（例如，测试类型，结果数量和结果） 。从每个患者记录到相关的测试结果记录中存在一对一的关系。

使用合成数据集进行测试。该数据集包含一个病人诊所和1000万实验室结果。每名患者的测试结果记录为0至20次，平均为7次。这些患者和观察资源被映射到我们测试的每个数据库的数据模型。这种数据集大小是保真度（实际系统可能更大，取决于数据老化和归档策略）与测试执行时间之间的差异，以及为不同数据模型和测试配置构建和加载数据集的实质成本。

3.3创建负载测试客户端

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

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

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

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

3.4定义并执行测试脚本

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

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

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

性能和可扩展性

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

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

第二个设计决定是如何实现所需的一致性水平，这需要协调写操作设置和读操作设置[10]。三个数据库中的每一个提供了略微不同的选择，我们探讨了两种方法，在接下来的两节中进行了讨论。第一个报告结果使用强一致性，第二个报告结果使用最终的一致性。

4.1使用强一致性进行评估

选定的选项总结在表1中。对于MongoDB，其效果是所有写入都在主服务器上提交，所有读取都来自主服务器。对于Cassandra，效果是所有写入都是在三个子集群中的每个子集上的大多数仲裁中提交的，而读取仅在本地子集群上需要大多数法定人数。对于Riak，效果是要求整个九节点集群的大多数仲裁用于写操作和读操作。

每个工作负载的代表性生产配置的吞吐量性能如图2，图3和图4所示。Cassandra性能以每秒大约3200次操作达到峰值，Riak峰值，峰值为每秒480次，MongoDB峰值约为225每秒操作

在所有情况下，Cassandra提供了最佳的整体性能，只读工作负载性能大致与单节点配置相当，只写和读/写工作负载性能略好于单节点配置。这意味着对于Cassandra来说，由于磁盘I / O和其他每个节点资源（与单个节点配置相比）的争用减少而产生的性能提升大于在副本和数据中心之间协调写入和读取仲裁的附加工作。此外，Cassandra的“数据中心感知”功能提供了复制配置与分片配置的一些分离。在该测试配置中，与Riak相比，

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

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