支持NoSQL数据库ACID属性的中间层解决方案的实验结果分析

Journalof King Saud University沙特国王大学沙特国王大学学报www.ksu.edu.sawww.sciencedirect.com一个支持NoSQL数据库ACID属性的中间层解决方案艾曼·ELotfya，*， Ahmed I.Salehb， Haitham A.放大图片作者：El-Ghareebc， Hesham A.阿里da埃及信息技术研究所b计算机工程和系统系，埃及曼苏拉大学工程学院c信息系统部，埃及曼苏拉大学计算机和信息科学学院d计算机工程和系统系，埃及曼苏拉大学工程学院接收日期：2015年1月27日;修订日期：2015年5月10日;接受日期：2015年2015年11月3日在线发布本文的主要目标是保持RDBMS的优势，如一致性和ACID属性，同时提供通过中间层激发NoSQL运动的好处。所提出的中间层使用四阶段提交协议来确保：使用最近的数据，使用Pessimware技术来禁止其他人在使用数据时处理数据，以及驻留在许多位置的数据更新，以避免数据丢失和失望。这种机制是必需的，特别是在基于NoSQL的分布式数据库应用环境中，因为允许冲突事务继续不仅浪费了受限的计算能力并降低了带宽，而且加剧了冲突。中间层跟踪所有正在运行的事务，并与其他层一起管理并发事务的执行。此解决方案将有助于提高可扩展性和吞吐量。最后，实验结果表明，系统的吞吐量提高了增加的中间层在sce- narios的数量和数量的更新读取在一个事务增加。此外，通过更新相同的数据，数据与执行彼此相关的许多事务一致。系统的可扩展性和可用性不受影响，同时确保严格的一致性。©2015作者。制作和主办由爱思唯尔B.V.代表沙特国王大学。 这是CC BY-NC-ND许可下的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。1. 介绍*通讯作者。电 子 邮 件 地 址 ： Eng5ayman@gmail.com （ A.E.Lotfy ） ，aisaleh@yahoo.com（A.I.萨利赫），helghareeb@mans.edu.eg（H.A.El-Ghareeb），K_hesham71@yahoo.com（H.A. Ali）。沙特国王大学负责同行审查制作和主办：Elsevierhttp://dx.doi.org/10.1016/j.jksuci.2015.05.003使用关系数据库管理系统（RDBM）来存储和管理数据。RDBMS通过使用主键和外键等约束来维护数据之间的关系。在数据量不大、系统用户不多、数据一致性要求较强的情况下，关系数据库将是一个理想的解决方案。由于数据存储在一台机器上，因此它们之间的管理关系不会受到挑战。当今的一些1319-1578© 2015作者。制作和主办由爱思唯尔B.V.代表沙特国王大学。 这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。关键词NoSQL;一致性;基础;事务;并发134A.E. Lotfy等人他们希望服务始终可用、可靠并具有高度一致性。随着用户数量的增加和生成的数据量的增加，数据必须存储在可能分布在不同位置的许多服务器中。将数据分布在多个服务器上使得维护数据之间的关系变得困难。Web应用程序需要能够在许多服务器上扩展（Orend，2010）。这种挑战 导 致 了 一 种 新 的 DBMS 趋 势 的 出 现 ， 称 为 NoSQLDBMS。NoSQL DBMS能够在许多节点上分发数据，提供所需的可用性级别，同时将可伸缩性保持在可接受的级别内，并忽略数据一致性。分布式数据库系统的问题是，我们必须克服三个基本属性之 一： 可用性 ，一 致性 和分区 根据CAP 定理 由 EricBrewer教授证明（Gilbert和Lynch，2002）。CAP定理指出，任何DBMS只能提供三个属性中的两个：一致性（C），这意味着DBMS在同一时间向用户提供相同版本的数据，高可用性（A）系统随时响应用户的数据，以及对网络分区（P）数据的容错性（Wei，2012;Gilbert andLynch，2002）。第二部分介绍了传统关系数据库管理系统的背景和基本概念，ACID属性，NoSQL数据库管理系统和BASE属性。第3节介绍了以前的努力。第4节描述了改进NOSQL数据库管理系统ACID属性的框架。第5节介绍了性能指标。第六节是实验结果，第七节是结论.2. 背景和基本概念在本节中，将介绍与传统RDBMS，ACID属性以及NoSQL数据库和BASE属性相关的基本概念。还介绍了与RDBMS和NoSQL2.1. 传统的RDBMS和ACID属性关系数据库是一种将数据存储在关系集合中的系统。保存在关系中的数据通过主键和外键相互关联。典型应用的关系称为表。这样的应用程序的例子在关系数据库系统中，采用SQL语言进行数据管理。SQL语言的范围包括从多个关节查询数据，插入，删除，更新和其他操作。由于其丰富的功能集，如查询功能和事务管理，它们似乎适合几乎所有可能的任务。RDBM的一个重要特性是提供ACID属性，以便执行事务（Wei，2012），因为事务被划分为子事务。RDBM维护ACID属性，这些属性在分布式数据上很难维护。RDBM确保ACID用于处理的每个事务，例如并发事务;此外，根据CAP定理，它们确保了一致性和可扩展性（Gilbert和Lynch，2002）。另一方面，RDBMS在某些场景中不是最合适的解决方案，数据和大规模Web应用程序（Milanovic'andMijajlovic'，2012;Valer，201 3）. 大数据需要3V的体积，速度和多样性（Valer，2013）。大数据需要可扩展性和可扩展性，这是RDBM所不能提供的（Valer，2013）。特别是，在使用RDBMS的分布式系统中进行事务和联合操作是困难的。随着数据的指数增长，系统必须水平扩展，这意味着将数据划分到许多机器上。水平可扩展性很难通过RDBM获得。RDBM需要固定的表结构，这是大数据所不需要的2.2. NoSQL DBMS和BASE属性NoSQL是一个总括术语，包括一组非关系型DBMS。它的意思是它为分布在许多服务器上的简单读/写数据库操作提供了良好的水平可扩展性，与传统的RDBM 相比，RDBM 几 乎 没 有 或 根 本 没 有 水 平 扩 展 能 力 （ Cattell ，2010）。NoSQL数据库不需要固定的表结构，也不提供完整的ACID支持。它最终提供了一致性，这意味着数据在一段时间内是一致的（Orend，2010年）。一些常用的NoSQL数据库是CouchDB，Riak，Cas-sandra，Mnesia，BerkeleyDB，HamsterDB，MongoDB和Redis（Muhammad，2011）。NoSQL数据库有多种分类方法，每种方法都有不同的类别和子类别（Kriha，2011）。然而，大多数人都同意的基本分类是基于数据模型的分类。NoSQL数据库可以根据数据 模 型 进 行 分 类到 列 、 文 档 、 K 值 和 图 （ Kriha ，2011）。NoSQL数据库基于非功能类别及其功能覆盖率的评估。表1总结了这些特性。在面向文档的数据库中，每个数据库由许多集合（如RDBM中的表）组成，每个集合包含许多以二进制结构化对象表示法（BSON）格式编写的文档Cattell，2010。每个文档都有一个ID，我们可以通过它访问该文档。每个文档都由键值对组成。我们可以获取或更新特定集合中特定文档中的特定SimpleDB、mongoDB和coachDB是面向文档的NoSQL数据库的一些例子。在键/值存储中，数据存储在散列上（Cattell，2010）。键是唯一的标识符，值是相应的数据。数据的结构类似于字典。插入、删除和更新操作应用于每个给定的键。许多键值对可以被分组在桶中，并且键具有标识桶的部分。更新和获取操作是在键上完成的。Project Voldermort，Riak，Redis，Scalaris和Tokyo Cabinet是键值NoSQL数据库的一些示例（Franco和Nogueira.，2011年）。列存储将数据保存在行中。每一行都有一个唯一的标识符，称为key和一个或多个列。列本身就是列名不需要预先定义，因此结构不固定。行中的列根据它们的键 （ 名 称 ） 按 排 序 顺 序 保 存。 例如 Google BigTable 、HBase和Facebook的Cas-sandra（Cattell，2010）。NoSQL DBMS提供高吞吐量（Kriha，2011）。例如，采用Google Bigtable方法的列存储Hypertable支持ACID属性的中间层解决方案135表1数据库类别和功能。数据模型性能扩展性灵活性复杂性功能键值高高高低变量（无）列存储高高中度低最小文档存储高变量（高）高低变量（低）图形数据库可变可变高高图论关系数据库可变可变低中度关系代数根据Brewer的说法，他证明了CAP定理放弃了一致性和隔离性的ACID属性，转而支持“可用性、优雅降级和性能”。首字母缩略词BASE由以下特征组成：基本可用、软状态、最终一致性。Brewer将ACID与BASE进行了对比，如表2所示，表2以以下方式总结了BASE属性：应用程序基本上一直工作（基本上可用），不必一直保持一致（软状态），但最终将处于某种已知状态（最终一致性），相反，ACID属性提供严格的一致性。严格一致性意味着所有读操作必须从最近完成的写操作返回相同的数据。根据CAP定理，这种严格一致性不能与可用性和分区容差最终一致性意味着所有读操作可能返回与最近完成的写操作不同的数据，但随着时间的推移：“在稳定状态下”，系统最终将返回最后写入的值。因此，在更新过程中，客户端可能会面临不一致的数据状态。例如，在复制的数据库中，更新可以去往一个节点，该节点将最新版本复制到包含修改的数据集的副本的所有其他节点，使得副本节点最终将具有最新版本。表3总结了RDBMS和NoSQL之间的相似性和差异2.3. NoSQL相关问题Zvent将每天存储10亿个数据单元。NoSQL DBMs提供了有效的水平可扩展性，这意味着数据可以驻留在多台机器上，如果空间不足以容纳数据，可以轻松添加其他机器。而在垂直扩展中，数据驻留在单个机器中，并且通过多核进行扩展，即在该机器的CPU和RAM资源之间分配负载，而水平扩展通过向现有池中添加更多机器来动态扩展通常 更 容 易 - 水 平 扩 展 的 一 个 很 好 的 例 子 是 Cassandra ，MongoDB。垂直扩展的一个很好的例子是MySQL与提供ACID属性的RDBMS不同，NoSQL引入了所谓的BASE属性。的NoSQL DBMS面临着许多挑战。其中一个重要的挑战是如何增加某种程度的数据一致性以及提供ACID属性。在 这 方 面 有 一 些 研 究 ， 如 CloudTPS ， Megastore ，WAS，COPS，Percolator等。同时，由于数据存储在多个服务器上，如何对存储在NoSQL数据库中的分布式数据进行快速检索，以及如何从分布式数据中获取商业智能信息也是一个挑战 如何在多个节点上分发数据是NoSQL DBMS面临的挑战之一诸如“Oracle Cloud上的NoSQL和Hadoop技术”和“简单操作数据存储中可扩展性能的10条规则”等文章2.4. 分布式数据和并发控制有两种数据分发方式：在多个服务器之间共享分发的不同数据，因此每个服务器表2ACID与基地作为布鲁尔说（吉尔伯特和林奇，2002年）。项目ACID一致性强一致性并发执行可用性水平可扩展性发展挑战承诺保守（pessimistic）lock可用参数基地弱一致性简单进化论（E。G.schema）专注于进化论近似回答好表3的 差异 之间 RDBMS和NoSQL数据库项目酸/碱RDBMS提供ACID性能需要固定表结构垂直扩展强一致性可用丰富的查询功能NoSQL提供BASE属性表结构扩大一致性可用性查询功能不需要固定表结构水平扩展弱一致性可用低查询能力136A.E. Lotfy等人表4总结以往的努力。研究目标性能结果度量缺点02 The Dog（2011）Baker等人（2011– 提供完全serializableACID语义在远程副本上，– 支持交互式应用程序- 根据 到客户使用– 提供可用性（至少 -它需要一个手动部件-将数据分为五个组（99.999%）– 平均写入延迟为100-且仅为提供ACID 400 ms，具体取决于该组内数据中心之间的距离MVCC多版本Con-和数据的大小被货币控制书面可扩展的交易-跨异构NoSQL KeyValue数据存储的异构操作，仅使用来自每个Kanwar（2013）存储的最小数据存储（2013）大型商店– 读写操作的可用性。– 平均读写延迟– 吞吐量（每秒交易量（TPS））– 同时改变读与写90：10，80：20至70：30– using 1, 2, 4,16、32、64和128客户端10，000个线程– 访问的记录– 吞吐量– 运行– 的 交易数量可线性扩展到16个客户端– 线程（这使得每秒大约有491个事务，其中使用单个WAS数据存储容器的读和写事务分别为90：10）– 有32个线程，– 取决于假设该数据存储返回所有最终版本的数据– 取决于事务的全局排序取决于中央时钟从交易仍然与16个线程大致相同02The Dog（2012）-提供完整的ACID-04 The Dog（2012） 为 多项交易通过HBase网络发布的信息应用程序，即使在pres-服务器失望和网络分区– CloudTPS 包 含多 个 LTM 。每个LTM负责一个数据– 当Web应用程序提交事务时，LTM充当事务SimpleDB– Maximum TPSmeasured– 使用HBase TPS刻度线-– Does not address早期对 number 死锁的LTM并达到8000 tps，– 使用SimpleDB TPS达到– Using 2pc in a networknumber的延迟执行的LTM 从5-10至15.40交易-充当数据子集的单个源。另一种是复制，它将数据复制到多个服务器上，每一位数据都可以在多个地方找到。系统可 以 使 用 任 一 种 或 两 种 技 术 。 复 制 有 两 种 形 式（Muhammad，2011）：主-从复制，它使一个节点成为处理更新的权威副本，而从节点与主节点同步并可以处理读取。另一种称为多主机复制。与主从式相比主从如果两个操作属于不同的transactions，它们访问相同的数据项，并且其中至少有一个是写操作，则这两个操作是一致的。当两个客户端试图同时写入相同的数据时会发生写-写冲突，而当一个客户端在另一个客户端更新相同数据的过程中读取数据时会发生读-写冲突。有两种方法可以确保一致性。第一种是Pessibility方法，它锁定数据记录以防止冲突。第二种是乐观的方法，它执行任何即使它违反了完整性规则，如可串行化性，并且在它检测到冲突并修复它们之后，它也会处理事务3. 相关工作最近，关系数据库受到NoSQL存储系统的挑战，NoSQL存储系统通常放松一致性保证，以支持更多的可扩展性和可用性。为高度一致性引入了不同的解决方案，并提供基于NoSQL系统的ACID事务，键值存储。一种方法是在数据存储本身中实现事务支持（Baker等人，2011年）。这很复杂，很难在不影响可扩展性和可用性的情况下实现。在我们提出的解决方案中使用的另一种方法是使用一个中间层作为客户端和DBMs之间的接口。这一层将支持ACID属性和并发控制。另一种方法是为每个数据存储定义事务访问协议。该协议提供了一个事务和数据存储抽象API，使客户端应用程序能够访问具有事务语义的数据。此外，拟议的协议保持了支持ACID属性的中间层解决方案137Web应用程序负载平衡器服务器检测器可扩展性管理可伸缩性层事务层事务执行程序事务管理器等待事务处理数据迁移器存储器密钥状态数据芒。层中间层切分1碎片2碎片3DBMS客户图1拟议的中间层概述对数据存储的可扩展和可靠访问的优势。但是这种方法需要从DBMS和客户端本身向API发送元数据。客户提供的数据不可能准确。Google Megastore（Baker等人，2011）是一个基于BigTable的事务索引记录管理器。Megastore支持跨多个数据项的ACID事务。然而，程序员必须手动将数据项链接到分层组中，并且每个事务只能访问单个组。三角帆（Rao等人，2011）使用PAXOS协议来构建可扩展、一致和高可用的数据存储，但它仅提供单个项目的一致性保证。COPS（Lloyd等人，2011）是一个键值存储，它在广域范围内提供这种一致性模型。COPS的一个关键贡献是它的可伸缩性，它可以在整个集群（而不是单个服务器）中存储的密钥之间强制执行因果COPS中的核心方法是在暴露写入之前跟踪并显式检查本地集群中键之间的因果依赖关系是否满足COPS使用get事务来获得多个键的一致视图，而不会锁定或阻塞。它使用复制协议优化来实现更高的性能，同时支持本机多项事务。格兰诺拉麦片（Cowling和Liskov.，2012）是用于构建可靠的分布式存储应用程序的事务协调基础设施。它提供了一个强大的一致性模型，同时显著降低了事务协调开销。Gra- nola引入了对一种新型独立分布式事务的特殊支持，这种事务可以在没有锁定开销的情况下进行序列化，也不会因为写入冲突而中止。Granola使用一种新的基于时间戳的协调机制来安排分布式事务，提供低延迟和高吞吐量。它使用复制协议优化来实现更高的性能，同时支持本地多项事务。跨异构NoSQL键值数据存储的可扩展事务（Kanwar，2013）定义了一个客户端API，该API定义了客户端协调事务管理协议138A.E. Lotfy等人图2中间层算法。具有可插入的数据存储抽象层，使其能够处理跨多个数据存储的事务。 它定义了一个客户端协调的事务协议，通过分布式应用程序在异构的键值存储中实现高效的多项事务它还定义了一个数据存储实现，该实现提供了一个相应的接口来支持多项事务。但是这种方法依赖于客户端时钟，这将给出不准确的结果，它定义了一个中心层，所有客户端都可以从中获取数据。这一层是一个单一的失望点。渗滤器（Peng和Dabek.，2010）实现了具有快照隔离语义的多密钥事务。它依赖于一个称为时间戳oracle（TO）的中央容错时间戳服务来生成时间戳以帮助协调事务，并依赖于一个锁定协议来实现隔离。锁定协议依赖于对记录的读-评估-写操作支持ACID属性的中间层解决方案139数据服务器Web应用服务器中间层中间层图3实验构建。检查与每个记录关联的锁字段。它没有利用大多数关键值存储中可用的测试和设置操作，这使得该技术不适合分布在相对高延迟WAN中的应用程序。没有实现死锁检测或避免，进一步限制了它在这些类型的网络上的使用Cloud TPS（Wei，2012）是客户端Web应用程序和云存储之间的中间层这一层与我们的工作有关，因为它提供了事务ACID属性，但它没有解决死锁问题。事务被划分为子事务。每个子事务只处理一个用于读取或写入的密钥。如果所有子事务都准备好执行，则执行事务。如果一个或多个子事务没有准备好，则事务被中止并被赋予另一个时间戳，然后从第一个重新启动。因此，当另一个事务在相同的数据中操作时，可能会发生一个事务将从第一个事务重新启动多次的情况。它没有按照事务执行的顺序给出调度算法。此外，它对底层存储中的所有数据使用内存数据表4总结了之前尝试解决NoSQL的一致性和ACID属性的工作。4. 提出的解决方案根据Eric Brewer证明的CAP定理，任何数据库管理系统只能满足三个属性中的两个，即一致性、可用性和图5根据请求数量的排序：一个中间层。分区。关系数据库提供ACID属性的一致性和可用性，而NoSQL数据库提供BASE属性的可用性和分区。本文的目标是提高NoSQL数据库在并发事务执行中的一致性并其中一个解决方案是修改NoSQL数据库引擎本身，但这个解决方案将依赖于修改后的数据库引擎，因此它不适合其他数据库引擎。它还需要获得一些引擎无法使用的源代码，并且需要努力理解代码，例如为Big Table和WindowsAzure Storage和Citrus Leaf构建的Megastore。另一种解决方案是基于在NoSQL数据库引擎上构建一个层，该层充当用户应用程序（如Web应用程序）和NoSQL数据库引擎（如云TPS）之间的接口。这个中间层将支持客户端的事务属性，例如ACID和consideration，并维护NoSQL数据库的动机，例如底层NoSQL数据库引擎已经提供的可用性和分区。中间层将只取决于我们如何在底层数据库引擎上获取或更新数据。因此，通过微小的修改，我们可以使它适合许多NoSQL数据库引擎。此外，我们可以通过在事务管理重要的情况下打开中间层，在事务管理不重要的情况下关闭中间层来控制中间层。客户PCWeb应用程序Mongo数据库一个中间层图4实验1构建。8000600040002000无图层层90%读取层80%读取01234140A.E. Lotfy等人中间层中间层两个中间层图6实验2构建。包装：两个中间层80006000400020000图7两层的实验2结果。4.1. 拟议中间层图1示出了具有所提出的中间层的整个系统的架构。图2示出了中间层的主要组件的算法。客户端使用HTTP向Web应用程序发出请求。Web应用程序向中间层发出事务。有多个中间层，以避免中心点的故障。Web应用程序可以向任何现有的中间层提交事务。接收事务的中间层将检测将执行事务的可用中间层的可用性0.90.80.70.60.50.40.30.20.1012一层3两层4图8单层和双层系统的可用性客户PCWeb应用程序Mongo数据库TPS1234无图层200040005000700090/10读写250043005200700080/20读到写2300350045007000支持ACID属性的中间层解决方案141检测到的中间层将充当事务的协调器。协调器（中间层）将收集数据，执行事务，迁移更新并将数据返回到Web应用程序。协调器最初将数据从NoSQL存储加载到层内存中。协调器在层存储器中执行事务。数据读或写操作与数据（数据状态）一起保存。数据状态用于并发事务执行。由事务产生的数据更新与新版本一起保存在层存储器中，并且这些更新被复制到其他层以防止由于中间层服务器失望而导致的数据丢失。Web应用程序提交的事务使用4阶段提交协议执行。在第一阶段，协调器从其他中间层存储器收集数据，如果数据不存在于任何中间层中，则从底层NoSQL数据库收集数据。在第二阶段，协调器选择另一个协调器与它并行执行事务，以使结果即使在主协调器失望的情况下也可用。在第三阶段，主协调器和辅助协调器执行事务。在第四阶段，主协调器将结果发送到Web应用程序和底层NoSQL数据库引擎，同时辅助协调器检测是否发生了失望;失望是否发生在主协调器中。如果它检测到失望，安全协调器将结果返回给Web应用程序并更新底层NoSQL数据库。负载平衡器将用于检测哪一层负责充当事务的协调器。中间层具有最初通过数据迁移器组件从NoSQL数据存储加载的数据的内存副本。数据更新是由于事务迁移到另一个层，以便在层失望的情况下获取数据，并使用此更新的新版本更新NoSQL数据存储和更新密钥状态组件。由于NoSQL DB是水平可伸缩的，我们维护了负责扩展中间层的层可伸缩性管理器。服务器检测组件负责检测哪个节点（数据或层）连接到系统。当层充当事务的协调器时，事务管理将其将在其中操作的密钥发送到数据迁移组件以准备这样的密钥的数据。数据迁移根据密钥状态组件获取密钥数据的最新版本。键状态组件维护每个键的最后一个版本的数据的位置，并要求其他层检测是否有任何其他层操作或具有新版本的键。如果键状态组件中的键可用并且没有对其进行操作，则它通知数据迁移以将数据从指定位置获取到层存储器中，并且操作（读取或写入）与键状态组件中的键一起保存。当另一层请求这些密钥时，它将这些密钥与版本和操作进行比较，并将操作与当前操作进行比较，如果它们中的任何一个（当前的或请求的）是写操作，则将事务发送到等待事务，等待事务定期检查密钥状态组件以便运行事务。当键可用时，事务执行器组件执行事务。在事务执行期间，驻留在键状态组件中的键具有版本和操作状态，其是读或写。当事务执行结束时，密钥的版本增加，操作设置为自由。数据迁移组件将更改传播到其他层和NoSQL DB。4.2. 中间层组件中间层由三个功能层组成。第一层负责可伸缩性和负载平衡，第二层负责事务管理，第三层负责数据和数据状态和版本。以下各节解释了每个组件的重要性4.2.1. 服务器检测器服务器检测器组件是一个关键组件，因为它确定当前连接到网络的中间层和数据服务器。服务器检测器维护当前连接的服务器，并定期向这些服务器发送信号，通知它们该服务器处于活动状态并正在运行。如果服务器检测器没有从特定服务器接收到任何信号，它会尝试向该服务器发送信号并等待响应。如果服务器检测器没有收到任何响应，则检测到服务器失望。如果服务器检测器从当前不在其列表中的服务器接收到信号，则检测到连接到系统的新服务器4.2.2. 可伸缩性管理器由于NoSQL DB为数据存储或传入请求的增加提供了良好的水平可扩展性。我们通过提供可伸缩性管理组件在层中维护这个属性。当工作负载增加或层内存数据增加时，此层负责增加层数。因此，可伸缩性管理器可用于增加中间层内存的大小，或者在工作负载增加时进入系统中的新层4.2.3. 负载平衡器在网络中添加或删除层时，将调用负载均衡器组件来重新平衡中间层中的工作。重新平衡只发生在等待的事务上。重新平衡发生在等待事务的数量上。只有一层负责实现这种平衡。负载均衡器从Web应用程序接收事务并检测事务的主协调器当系统层数增加或减少时，对等待的事务进行再平衡它还负责检测次级协调器。4.2.4. 数据迁移器数据迁移组件负责从其他中间层内存获取数据。如果数据不存在于任何中间层内存中，则数据迁移组件从底层NoSQL DB获取数据。如果数据被更新，数据迁移组件会将这些更新迁移到其他中间层和底层NoSQL DB。此外，该组件还用于实现数据在中间层内存中的驻留，以便为其他数据腾出空间。当在另一个中间层存储器中存在相同数据的另一个更高版本时，应该从中间层存储器中删除该数据。当需要定位时，也142A.E. Lotfy等人内存中的更新迁移到底层NoSQL数据库，其年龄超过管理员设置的限制内存中数据的年龄是从上次使用时开始确定的。系统可以修改数据的年龄。当内存中的数据大小大于管理员确定的阈值大小时，将自动开始删除数据。数据的删除首先是删除旧版本的数据，然后是旧数据，如果更新迁移到底层NoSQL数据库。4.2.5. 密钥状态关键状态组件负责维护数据的最后版本的位置和当前对其的操作。数据的版本是一个增量数字，当此关键数据的任何部分更新时，该数字会增加。数据的状态指示当前对数据的操作，例如读、写或无操作。如果一个层对一个特定的键进行写操作，则中间层将存储在键状态中，并使用该键进行写操作。4.2.6. 交易管理事务管理组件负责为事务提供ACID属性它包含两个主要组成部分。一个组件通过应用4PC 4阶段提交协议来执行事务，而另一个组件包含等待事务。因此，它会定期检查正在运行的事务的可用性。4.3. 系统如何提供ACID属性该层的目标是提供NoSQL数据库中RDBM的ACID属性。在本节中，我们将讨论所提出的层如何通过使用4PC在NoSQL数据库中提供原子性，一致性，隔离性和持久性属性。4.3.1. 原子性对于由多个密钥组成的多密钥事务，我们根据密钥的数量将这些事务划分为多个子事务。因此，每个子事务只处理一个用于读取或写入的密钥。如果一个或多个子事务失败，则整个事务将失败，使数据库没有任何更改。为了保证原子性，我们执行了四阶段提交协议。 考虑到事务的生命周期短，一旦数据可用于协调器的本地存储器中的操作，事务就被无中断地执行。在提交协议的第一阶段，协调器从其他事务管理器或底层NoSQL数据库中获取事务所需的所有数据当协调器准备好执行事务时，它将事务和数据复制到负载均衡器选择的其他事务管理器，以充当辅助协调器。主协调器和次协调器开始执行事务。如果主协调器成功，则它将更新的数据返回到Web应用程序，并在第四阶段中提交事务，将更新的数据复制到N个如果服务器检测到主协调器中存在硬件故障，次协调器，次协调器执行事务并将数据返回到web应用程序，并将数据复制到另一层以提交事务。在所提出的协议中，只有一个节点（协调器）负责在第一阶段数据可用后执行整个事务。我们还提供了一个辅助协调器，它在协议的第二阶段执行相同的事务，并发送相同的数据。如果主协调器在执行事务时出现失望，则辅协调器充当主协调器的替代者。此外，如果在主协调器执行事务之后主协调器中发生硬件故障并且更新没有迁移到底层数据库，则辅助协调器充当另一个数据源。4.3.2. 一致性一致性是指事务的执行将数据库从一个一致的状态带到另一个一致的状态。这是通过检查用于声明用于保存数据的变量的准确数据类型来完成的4.3.3. 隔离对于事务的并发执行，隔离意味着事务的执行必须仅使用已提交的数据。因此，如果多个事务操作多个相同的关键数据，我们必须调度（排序）事务以确保可串行化。在我们的协议中，除非所有使用的密钥都可以自由使用，否则第三阶段的交易不会开始执行。我们使用锁定和时间戳机制的组合。当协调器执行事务时，它将事务划分为子事务。每个子事务只对一个键进行读或写。当任何协调器执行一个事务时，它在键状态中标记所有键所需的操作，如K1：R，K2：W等。当执行完成时，操作从键中删除，更新的键采用新版本。当另一个事务想要对另一个已经运行的事务正在使用的任何键进行操作时，如果对该键的两个操作被读取，则执行第二个事务，否则第二子事务采用从当前运行的协调器确定的数字N这个数字是递增的，因此，如果另一个事务想要以前一个事务状态运行，它需要另一个数字N +1。当一个事务开始执行，并且与其他正在运行的事务没有冲突时，它的值为1。如果在另一个协调器上接收到另一个事务，并且在密钥K上存在与事务号1的冲突，则当前事务中的密钥K取号2，并且整个事务被置于等待状态。当第一个事务的执行完成时，最低数量的事务的执行应该开始。当协调器想要更新密钥时，它通过操作写入锁定该密钥，并且任何其他传入事务想要对该密钥进行操作，它从当前锁定该密钥的协调器获取一个数字当当前锁定密钥的协调器提交更新时，具有最低编号的协调器通过开始执行操作来管理密钥，并向其他传入事务提供从最后编号+1开始的新编号。支持ACID属性的中间层解决方案1434.3.4. 耐久性持久性意味着提交的数据不会被撤消。在协议的第三阶段，我们在数据复制到多个层后提交数据，并使用数据迁移和数据驱逐器将更改迁移到底层NoSQL数据库。如果在我们的协议的第二阶段中有任何硬件故障，我们使一个执行事务的辅助协调器，并通过其服务器检测来确定主协调器是否有硬件故障。如果主协调器中的硬件令人失望，则辅助协调器将更新迁移到另一层和底层NoSQL数据库。我们确保在将数据返回到客户端之前，更新迁移到多5. 性能度量中间层的性能可以根据诸如吞吐量、层的可用性、一致性和可伸缩性等多个度量来评估。在我们提出的中间层的情况下，我们将根据层的传输吞吐量和可用性来测量性能。事务吞吐量是指每秒执行的事务数（TPS）。并发事务将通过多个线程发送到中间层。事务完成的时间写入数据库。并评估每秒执行的事务数我们将根据客户端请求的数量检查事务吞吐量每个请求都包含一个事务。事务读写比率从100%读到0写，从90%读到10%写，从80%读到20%的写作。可用性是指用户社区获得服务或良好访问系统的能力，无论是提交新工作，更新或更改现有工作，还是收集以前工作的结果。如果用户无法访问系统，从用户的角度来看，这是不可用的术语停机时间用于指系统不可用的时间段。事务吞吐量将在复制服务器之一的故障转移期间测量。为了提高系统的可用性，在两个服务器上重复一致性层的检查系 统 任 何 组 件 的 稳 态 可 用 性 可 根 据 以 下 公 式 计 算（Teorey和Teck，1998）：Ai¼ MTTFi= ΔMTTFi ΔMTTRi Δ其中MTTF是部件I失效的平均时间，MTTR是部件I修复的平均时间此功能将应用于我们的层的情况下，事务执行和层失败，并返回到修复后运行。如果系统包含一个层并且故障发生在该层，以及如果系统有两个层并且故障发生在一个层，则发生故障。有一个关于一致性的简短说明，这意味着所有用户将在同一时间处理相同的数据。在传统意义上，一致性属性是系统提供或未能提供的东西。因此，财产可以被验证，但不能被测量。我们验证这些属性通过执行多个用户以特定顺序发送的多个交易，我们获得了正确的数据。6. 实验结果本节提供了实验结果来验证所提出的中间层。实验结果表明，系统吞吐量随请求数近似线性增加，并随中间层数目的增加而增加。我们在Mongo NoSQL DB上构建中间层。在服务器上运行的引擎，Web应用程序托管在另一台服务器上，并通过Web应用程序向中间层发出多个请求。图2显示了实验的结构。客户端向Web服务器发出请求，Web服务器使用中间层从底层MongoDB数据库获取数据。实验中使用的程序的快速描述如下所示我们使用mongodb构建底层NoSQL数据库。存储在数据库中的数据代表数据服务器1中的10，000条学生数据记录。学 生 数 据 包 括 钥 匙 ， fname ， lname ， birthdate ，faculty，choice1，choice2，IQ，English，Email。这些数据（10，000）记录被复制到另一个数据服务器2。● 数据以bson格式存储如下{key：1; fname：'还有另外两个中间层服务器，每个都包含维护ACID属性的算法。该层使用C#编程。有一个包含Web应用程序的服务器;我们将其称为Web应用程序服务器。● 所有服务器都使用交换机连接。● 每台服务器包含内部核心i5处理器● 图3示出了服务器之间的逻辑连接。6.1. 实验1：使用一个中间层评估系统我们测量了只有一个中间层存在的吞吐量。Web应用程序可以同时发出一个请求、两个请求、三个请求或四个请求。每个请求需要执行许多事务，大约3000个事务。图4示出了实验架构。图5显示了实验1的结果。纵轴表示每秒的平均吞吐量（TPS）事务，横轴表示向中间层发出的请求数。在90R：10 W、80 R：20 W的读写比范围内，同时使用1、2、3、4个请求，对不同的键进行操作，进行性能测试。我们增加了每次写入与读取的比例，以增加工作负载，因为写入比读取花费更多的时间。此外，我们使用Web应用程序首先发送一个请求。事务按顺序执行。此外，由于同时请求的数量增加了要执行的所需事务的数量，并控制了数据之间的干扰。交易的一般结构包括（ update （ fname where id= 1 ） ， read （ fnamewhere id= 1 ） ， read （ fname where id= 2 ） ， read（fname where id= 1），read●●●●●●144A.E. Lotfy等人（ fname where id= 1 ） 、 read （ fname where id=1）、read（fname where id= 1）、read（fname whereid= 1）、read（fname where id= 1）、read（fnamewhere id= 1））。前一个事务包括90%R：10%W，当我们更新两个语句并读取8个语句时，这是80%R：20%W。在所有情况下，交易数量大致呈线性增长。随着请求数量的增加，每秒执行的事务数量也会增加，因为所有请求都在不同的线程上运行。如果没有层，事务吞吐量会更