高并发数据访问（共3篇）
高并发数据访问 篇1
今天,数据处理正在接受来自两个方面的挑战,一是数据量的急剧增长;二是访问数据的用户数的快速膨胀。第一类挑战通常需要借助于系统的横向扩展进行解决;第二类挑战通常可以基于现有系统硬件,调优等措施,采用纵向扩展模式解决。网上订票、在线购物等应用属于典型的第二类挑战制造者,其核心特征是以数据库为核心构建应用,具有广泛用户群,在多数情况下系统性能稳定,但在一些特定政策和活动的影响下,例如春运的订票、淘宝的双11活动和秒杀活动等,常常出现访问量急剧增长,从而使得系统负荷短时间内快速攀升,导致服务器响应变慢、处理出错、宕机、甚至整个系统的瘫痪。
本文针对系统的现有设施和需求,具体结合用户并发度、数据库访问接口、内存大小、索引等因素,聚焦于单表查询和多表连接查询,基于大规模综合实验和深入分析从纵向扩展角度来审视系统性能提升的可能途径。
1 相关工作
数据库的核心任务是保证数据的可用性和一致性,但两者又相互制约。由于数据库会有极大一部分开销用于维护事务特性,在一定程度上影响了系统可用性,并发访问数越高,对系统的可用性影响越大,因此需要权衡数据的一致性和可用性。其中,CAP理论从理论视角给出了一致性、可用性和分区容错性三者之间的制约关系[1]。订票、购物等应用数据量不算庞大,但对数据一致性与系统可用性均具有高要求,即实时响应是用户体验的核心,文献[2,3]等从程序优化视角进行了研究,提出了的解决方案。
关于系统横向扩展的研究也不断深入。例如,针对新型计算机体系结构为数据处理带来了新的可能和机遇,文献[4,5]等进行了研究。国内的电商平台淘宝为解决用户访问瞬时爆炸增长的困扰,设计了Ocean Base系统,基于其数据访问特点,采用分布式方案来解决问题。文献[6,7]等从云计算视角审视了大数据和大量用户访问的数据应用系统的性能优化技术。
2 影响因素分析与实验设计
2.1 数据库基本访问模式与性能影响因素
以数据库为核心构建应用,基本的环节包括数据库、数据库管理系统、软件开发框架和客户端,这四者构成了多级客户端/服务端的访问模式,如浏览器向软件开发框架提出访问请求,软件开发框架将其提交给数据库管理系统,进而实际操作数据库中的数据。
在上述数据库访问模式中,就数据库本身而言,其性能影响因素主要包括,数据表本身的大小、是否建有索引等。对数据库管理系统而言,高并发访问的制约因素包括:内存的大小、CPU的性能、选用数据库管理系统的响应能力等。对某个具体的查询请求而言,性能影响因素主要包括返回结果集的大小、查询涉及数据源的大小以及需要进行I/O的次数等。同时,为了进行快速开发,系统采用合适的软件开发框架进行构建,因此,软件开发框架的性能也是影响的数据库访问性能的核心因素之一。下面将针对上述因素进行实验设计和测试。
2.2 实验设计方案
2.2.1 实验设计
围绕2.1节中的各项性能影响因素,基于数据库在经过查询优化分解后最频繁的两类查询操作,即单表查询和多表连接查询,进行实验设计。实验选用开源数据库系统My SQL,根据各影响因素的不同属性,设计5组实验,分别进行有无软件开发框架的性能对比、不同数据源大小的性能对比、不同查询结果集大小的性能对比、不同内存大小的性能对比、基于索引的性能对比。对每一组实验,分别进行单表查询实验和多表连接查询实验。为了避免其它因素影响,每一组实验重复执行5次,采用平均值作为评测时间。
针对开发框架对系统性能的影响,采用Hibernate框架和Java数据库连接(Java Data Base Connectivity,JDBC)直接连接的模式进行实验,以验证开发框架在带来开发便捷性的同时,也付出了性能开销。
具体实现方面,设计一个模拟客户端来发起并发访问,在一个客户端中采用多线程模拟不同用户,向服务器发出访问请求。
2.2.2 实验环境
硬件环境上,CPU配置为Intel core i5-3230M 2.6GHz,最大内存8G。实验所用的服务器采用真机和虚拟机两种模式,即由虚拟机模拟2G和4G内存时的实验环境。在软件环境方面,编码语言采用Java语言,Java开发环境是jdk 1.6,Web服务器采用apache tomcat 6,数据库管理系统采用My SQL 5.7。
2.2.3 实验数据集
数据集由三张基本表构成,分别是消息表(message)、用户表(human)和消息类型表(kind),模拟生成三张表的中数据。不同实验条件下,每张表中含有不同数目的记录。message表中存在外键与human表和kind表进行连接,连接结果集的大小也根据实际需求进行变化。
所有查询时间以毫秒(ms)为单位,具体查询语句如下,
(1)单表查询:select*from message;
(2)表连接查询:select*from message m inner join human h on m.from_user=h.id inner join kind k on m.type=k.id;
3 实验结果与分析
3.1 软件开发框架对查询性能影响与分析
本组实验主要验证Hibernate框架和JDBC对高并发数据库访问的性能影响。实验中,在数据库的message表中存放11 100条记录,服务器端分别设置成基于Hibernate和JDBC访问数据模式,客户端则采用多线程模拟并发数分别为10、20、40、80、160、320、640、1280数量的访问请求。分别从单表查询和多表连接查询两个方面进行比较,其中多表连接查询采用内连接模式,实验结果如图1和图2所示。
从实验结果看,在结果集大小固定的情况下,由于Hibernate框架本身占用了一定的系统资源,其与数据库的交互效率要低于JDBC的直接访问效率。但开发框架在提交大量相同查询的情形下,可以借助二级缓存机制来提升效率,即第一个查询返回结果后,后续的相同查询则可直接访问缓存中的数据。JDBC并不具备这方面的灵活性。总体上,开发框架虽然提供了开发的便捷性,但加重了系统负担,导致了大规模并发访问的性能下降。
3.2 原始数据大小对查询性能影响与分析
本组实验主要验证在不同并发用户访问数下,原始数据集大小对高并发数据库访问的性能影响。实验中,让message表中记录数从千条、万条、十万条变化到百万条,同时保持着每张表中的索引和固定查询的返回记录数为100,客户端模拟的并发用户数分别为10,20,40,80,160,320,640,1280,进行单表查询和多表连接查询,实验结果如图3和图4所示。
根据该组实验结果,数据表的总记录数对查询性能的影响不明显,但当并发访问用户数上升时,由于存在资源竞争,导致了系统性能下降较快。
3.3 查询结果集大小对查询性能影响与分析
该组实验的主要目标是验证查询结果集大小对高并发数据库访问的性能影响。基于上述实验环境,分别限定查询结果集为30、300、3000条记录,客户端模拟并发访问用户数为10,20,40,80,160,320,640,1280,原始数据表中总记录数为100 000,分别进行单表查询和多表连接查询测试。实验结果如图5和图6所示。
从该组实验的结果可以看出数据表的查询返回的记录数对查询速度的影响是非常直接的。当返回的记录数分别为30、300、3000时,查询的速度完全不同,存在较大差异。在单表查询中,30与300之间查询时间增长平均倍率为2.93,而300与3000之间查询时间增长平均倍率为5.26。也就是说,随着查询返回记录数的增加,查询所用的时间也会增加。
3.4 内存对查询性能影响与分析
本组实验主要测试内存的大小对高并发数据库访问的性能影响。实验中,将内存分别设置成2G、4G和8G,查询数据表总记录为100000条,模拟用户并发数为10,20,40,80,160,320,640,1280,进行查询结果集大小为100条记录的单表查询和多表连接查询。实验结果如图7和图8所示。
该组实验的实验结果表明内存对于查询速度的影响比较明显,随着并发访问数的增多,大的内存由于能够提供足够的存储空间,不会引发资源竞争,从而表现出了很好的性能。
3.5 索引对查询性能影响与分析
本组实验的主要目标是测试索引对高并发数据库访问的性能影响。实验中,数据表中总记录数仍保持为100 000,查询返回记录数为100,模拟用户并发数为10,20,40,80,160,320,640,1280,分别在表未建索引和建有索引的情况下进行单表查询和多表连接查询。实验结果如图9和图10所示。
该组实验表明索引对查询性能具有很大影响,有效的索引能提升数据库的并发访问性能。建有索引的查询比没有索引的查询大约在查询性能上提升了3倍,而且随着并发数、总记录数、查询记录数的增加,没有索引时的查询时间相比于有索引时的查询时间的倍数会增加。
4 结论
基于大量的实验和分析,高并发访问数据库时的主要性能影响因素有:(1)返回记录数;(2)索引;(3)内存。在各影响因素中,查询结果集大小是最有影响的。当返回记录数在增加时,查询所用的时间也会不断的增长,而且当返回记录数每增加10倍时,查询时间的倍数差异也会越大。索引对查询性能也具有显著影响,在模拟并发用户数为1280时,基于索引的查询性能比没有索引的查询性能提升了3倍左右。不使用索引,My SQL必须从第一条记录开始查找。表越大,花费的时间越多。内存对于查询所用时间的影响也比较明显,随着内存的增加,多用户访问不在内存资源竞争,从而减少了查询时间。开发框架尽管本身占用了一部分系统资源,对并发访问存在影响,但其通过二级缓存、伪静态页面等多种技术能减少用户访问数据库的次数,从而在大量用户提交相同请求时(例如查询某趟车次余票,)减少了数据库服务器的压力。上述影响因素在指导高并发访问模式下的系统建设和优化,具有高的应用价值。
另外,本文的研究焦点仍聚焦于集中模式下数据访问的性能制约因素。在实际应用中,可在探寻应用的纵向扩展能力的同时,结合平台的横向扩展,例如采取负载均衡分担并发压力等,多视角地改进从而搭建高效的应用。
参考文献
[1]倪超.1.2.3 CAP和BASE理论[EB/OL].[2015-03-20].http://book.51cto.com/art/201503/469187.htm.
[2]王峰,顾明,李丽.基于J2EE应用的数据库访问的性能优化[J].计算机工程,2003,29(1):278-279.
[3]张志宽,罗晓沛.基于Web Dynpro Java平台的查询技术应用分析[J].计算机工程与设计,2009,30(20):4808-4810.
[4]Bruno N,Kwon YC,Wu MC.Advanced Join Strategies for Large-Scale Distributed Computation[J].Proceedings of the Vldb Endowment,2014,7:1484-1495.
[5]Pirk H,Manegold S,Kersten M.Waste.Not...Efficient CoProcessing of Relational Data[J].Data Engineering(ICDE),2014 IEEE 30th International Conference,2014:508-519.
[6]史英杰,孟小峰.云数据管理系统中查询技术研究综述[J].计算机学报,2013,36(2):209-225.
[7]林子雨,赖永炫,林琛,等.云数据库研究[J].软件学报,2012,23(5):1148-1166.
高并发数据访问 篇2
Memcached是一个开源的、高性能的分布式内存对象缓存系统, 一般用于动态应用以减轻数据库压力。它通过在内存中缓存数据和对象来减少读取数据库的次数, 从而提高动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。其守护进程是用C语言实现的, 但是客户端可以用任何语言来编写, 并通过memcached协议与守护进程通信。
现在常用的Memcached客户多有多种, 如传统Memcached、Xmemcached和Spy Memcached。本文主要讨论Xmemcached。Xmemcached是一个Java实现的Memcached客户端, 比起官方客户端, 它有以下优势:
(1) 支持所有的文本协议和二进制协议, 支持连接Kestrel和Tokyo Tyrant等Memcached协议兼容的系统并作特殊处理。
(2) 支持动态添加和删除Memcached节点。
(3) 支持客户端统计
(4) 支持JMX监控和统计, 可以通过JMX增删节点。
(5) 高性能
(6) 支持节点的权重设置
(7) 支持nio的连接池, 在高负载环境下提高吞吐量
2 Memcached的安装和使用
2.1 Memcached的安装
(1) 环境:X86_64架构服务器、Linux系统、jdk5.0+、Memcached服务器端、Xmemcached客户端。
(2) 服务器端安装
下载wget http://memcached.org/latest
解压缩tar-zxvf memcached-1.x.x.tar.gz
安装./configure&&make&&make test&&sudo make install
(3) 客户端安装
客户端可使用maven的方式进行安装使用:
<dependency>
<group Id>com.googlecode.xmemcached</group Id>
<artifact Id>xmemcached</artifact Id>
<version>{version}</version>
</dependency>
具体maven的使用不再赘述。
2.2 Memcached的使用
安装完毕之后就可以使用java调用xmencached的功能, 具体如下:
(1) 首先创建xmemcached实例, 此实例使用二进制协议。并且可动态添加服务器端实例。
XMemcached Client Builder builder=new
XMemcached Client Builder (Addr Util.get Addresses ("localhost:11211") ) ;
builder.set Command Factory (new Binary Command Factory () ) ;
XMemcached Client client=builder.build () ;
(2) 将数据加入缓存以及取出
加入:client.add ("key", 0, "value") ;
取出:String value=client.get ("key") ;
设置服务器权重为2:client.add Server ("localhost", 12000, 2) , 服务器权重越大, 则从此服务器取出数据的几率越大。
3 Memcached的数据测试
本测试将java-memcached, spymemcached与xmemcached进行性能对比, 对比包含三项参数, 并发量 (TPS) 、传输数据大小和线程数。
3.1 测试环境
(1) 软件环境
Memcached服务器版本:1.4.5, 默认设置, 运行参数"-p 12000-m1572864"。
Memcached客户端:JVM版本:Sun JDK 1.6.0_06, 使用memcached文本协议, Xmemcached版本1.2.6.1, 默认设置, Spymemcached 2.5版本, 默认设置, Memcached-Java客户端版本2.5.1, 由于Xmemcached和Spymemcached是基于异步模式所以他们需要设置超时时间, 设置为5秒过期。
(2) 硬件环境
1号服务器端:
CPU::8 x Intel (R) Xeon (R) CPU E5410@2.33GHz, 操作系统:Linux 2.6.9-67.ELsmp#1 SMP GNU/Linux, 内存:16 Gi B, 网络适配器:Broadcom Net Xtreme Gigabit Ethernet PCI express
2号服务器端
CPU:4 x I Intel (R) Xeon (R) CPU 5120@1.86GHz, 操作系统:Linux 2.6.9-67.ELsmp#1 SMP GNU/Linux, 内存:4 Gi B, 网络适配器:Broadcom Net Xtreme Gigabit Ethernet PCI express
3号服务器端
CPU:4 x I Intel (R) Xeon (R) CPU 5120@1.86GHz, 操作系统:Linux 2.6.9-67.ELsmp#1 SMP GNU/Linux, 内存:4 Gi B, 网络适配器:Broadcom Net Xtreme Gigabit Ethernet PCI express
客户端
CPU:8 x Intel (R) Xeon (R) CPU E5410@2.33GHz, 操作系统:2.6.9-67.ELsmp#1 SMP GNU/Linux, 内存:16 Gi B, 网络适配器:Broadcom Net Xtreme Gigabit Ethernet PCI express
3.2 测试结果
通过测试结果我们可以得出结论:随着网络数据传输量的增大, 同线程数下吞吐量越来越小, 增加线程数可有效提高吞吐量。在低线程数下, Java-memcached客户端性能优势比较明显, 高线程数下javamemcached客户端与Xmemcached客户端性能接近。在低网络传输量条件下, Spymemcached客户端劣势比较明显, 在传输较大数据时, 各客户端表现趋于相同。
4 总结
(1) 若需要提高动态应用读取能力, 可部署多台高性能大内存服务器运行Memcached服务器端, 利用空间换时间得到最优的效果。
(2) 为了提高Memcached效率, 尽量使用业务逻辑来区分Memcached服务器, 使得取值命中率提升, 避免遍历服务器造成无谓的性能损失。
(3) 为更强cpu和更大内存的服务器设置高权重值, 达到物尽其用的效果。
(4) 故障转移和扩容的问题:memcached它不是一个分布式的系统, 严格来说是个单点系统, 所谓的分布式只是借助客户端来实现的。所以它没有那些开源分布式系统那样的高可用性, 所以需要从客户端这里解决单点问题和扩容问题。可使用以下两种方法:
1) 一致性哈希:依赖于一致性哈希的特点, 节点故障或扩容加节点时对集群影响较小, 节点调整的最初一段时间内, 会有一部分缓存丢失, 穿透到后端的数据库上, 在高并发的应用里, 要做好并发控制, 以免对数据库造成压力。
2) 双写机制:客户端维护两个集群, 每次更新数据的时候同时更新两份, 读取的时候随机 (或固定) 读取一份, 这种情况下集群的可用性和稳定性很高, 可以无痛变更, 节点故障或扩容对缓存和后端数据库都没有影响。当然, 这样做也是有代价的:一是两份数据的一致性问题, 不过对缓存来说, 这种极少数的不一致情况是可以容忍的;另一个是内存浪费的问题, 通过冗余一份数据来减少故障率, 但是代价比较大, 并不适合大型的互联网应用。
(5) 随着网络传输量的增大, 性能下降比较大, 应避免传输过大的数据。
(6) 数据预热问题。由于Memcached是一套内存缓存系统, 当系统刚刚启动时, 会有一个写缓存的过程, 数据量不同写入时间也不同。所以系统启动初期会有一个访问较慢的过程, 随着缓存机制逐渐起作用, 系统性能会逐渐过渡到加缓存后的正常状态。
(7) 通过设置合适的算法如LRU和合理的过期时间, 能够使得Memcached系统的命中率有效的提高。
(8) Memcached将数据保存在内存里, 并没有持久化, 遇到停电或者故障等情况数据会丢失, 所以并不能将其当作传统的数据库来使用。
摘要：随着互联网和物联网的高速发展, 使用网络的人数和电子设备的数量急剧增长, 对互联网后台服务程序提出了更高的性能和并发要求。同时用户对网络服务内容也有了更高的的要求, 以web页面举例, 区别于传统新闻资讯类网页, 现在网民使用更多的是具有个性化功能的动态页面和移动客户端app, 这些都对服务器、网络和软件提出了性能方面更高的要求。传统的服务器端脚本调用数据库的方式在如此大的访问压力下变得越来越力不从心, 而新兴的NOSQL文档型数据库又对事务的处理力度不够, 这样的情况下就需要对现有模式进行改造, 使软件整体架构既能保留对事务的完整支持, 又能承受高并发带来的压力。本文对此种新架构进行了探索。
高并发数据访问 篇3
本文提出了一种能够超大规模地存储数据,并且支持高并发读写的非关系型数据库引擎,并提供建立云服务平台的技术服务,解决传统关系数据库在面对Web 2.0技术架构类型网站的缺陷,有效解决了关系数据库的瓶颈问题,满足当前互联网海量实时数据交互需求。
1 数据库技术研究
1.1 国内外研究概况
No SQL数据库起源于美国,最著名的是Google公司的Big Table,Big Table从2004年初开始研发,到如今已有12年。Big Table是通过分布式的方式工作的,依靠多维度排序Map实现持久化存储。Bigtable设计目的是可靠处理PB级别的数据,具有广泛适用性、可扩展性、高性能和高可用性等特点。
HBase是由Changetal提出的一个分布式的、面向列的开源数据库。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样,HBase在Hadoop之上类似于Bigtable,利用Google文件系统(File System)所提供的分布式数据存储提供底层支持。
Cassandra是Facebook开发的一套基于Amazon专有的完全分布式Dynamo,由一堆数据库节点共同构成的一个分布式网络服务,用于储存规模超大的数据,拥有种类多样的数据结构和功能强大的查询功能。
国内No SQL的发展主要是基于国外开源的项目进行修改,开发出适应国内互联网环境的No SQL数据库。国内某电子商务公司开发了基于内存和文件的,对应缓存和持久化存储的使用Key-Value结构的存储系统Tair。
1.2 No SQL技术研究
(1)No SQL可以在不改变原有关系数据库作为存储的架构,以辅助镜像存储的形式使用,极大提升了数据库性能。
(2)No SQL可以通过与关系类型数据库组合使用,关系数据库中只存储需要查询的小字段,而由No SQL存储所有数据。
(3)No SQL自身即可作为数据存储架构。
(4)以No SQL为数据源:数据可以通过直接写入No SQL同步协议的方式复制到其他存储器。完全根据实际应用中的逻辑关系决定获取相应的存储数据。
(5)No SQL可以通过内存模式和磁盘持久化模式进行缓存数据,这里的No SQL可看作缓存使用。
2 超大规模数据库引擎设计
超大规模数据库引擎是一款区别于现有关系型数据库的非关系型多维数据库引擎,提供分布式文档存储功能,支持超大规模存储数据和高并发读写的新一代数据库,由C++语言实现,提供规范的面向对象的操作语言。
多维数据库引擎的架构图见图1。多维数据引擎包含了以下功能模块。
Block(B):数据块,在服务器上用于保存数据的物理空间,一个物理服务器可以划分很多数据块。
Fragment:数据片,一个多维数据引擎包括多个数据片,每个数据片包含4个数据块,这四个数据块来源于不同的物理服务器。在这四个数据块中,其中一个为主数据块MASTER,另外三个数据块从主数据块上复制数据,为REPLICA。只有MASTER具备读和写的功能,而REPLICA只负责读取数据,这样就可以实现读写分离,并且保持读写的一致性。
Address Server:地址服务器。多维数据引擎包括了多台地址服务器,其中每台地址服务器都记录了数据存储的地址信息。在数据库运行之初,Address Server要把自己所有记录的地址列表复制到Cache里面,当数据在服务器的存储位置发生变化后,Address Server要修改地址列表,并且更新Cache的地址列表。
Cache:存储Address Server的数据地址列表,Cache的地址列表要和Address Server的保持一致。
Processing Unit:处理单元。每个处理单元都可以处理一个或多个客户端的服务请求。客户端向Processing Unit发起查询和更新,Processing Unit根据Cache记录的地址信息将请求分发到合适的服务器上。
Client:客户端。客户端是用户应用程序的一部分,它使用自身语言的多维数据引擎客户端驱动向Processing Unit发起请求。
3 超大规模数据库引擎实现
3.1 三级结构组织数据库
超大规模数据库引擎是一种面向集合(Collection)的、模式自由的文档(Document)数据库引擎。各种数据结构(二维、三维、四维等)的数据记录均以不同结构的文档形式表示,若干个文档组成一个集合。多维数据引擎的最小存储单位就是文档对象,各种维度的数据在多维数据引擎中以BSON(Binary-JSON)文档的格式存储在磁盘上。
3.2 Large FS文件系统存储大型文件
Large FS利用Linux Kernel 2.6的Device Mapper特性,实现了多路径IO的选址。将多块硬盘组合一个逻辑的整体,实现了最简单意义上的“云存储”,提高了硬件的效能。
Large FS的技术重点在Large FS缓存层,是在Device Mapper层和设备驱动之间新增的一层缓存层,以模块化的方式加入到Device Mapper层。
Large FS分为四个模块,即调度模块、逻辑处理模块、底层存储模块以及后台清理模块。
3.3 Fragment集群
在多维数据引擎中,每个Fragment包含了4个存储数据的Block,当文件的大小大于一个Fragment的容量时,这个文件可以自动被切分,再存储在多个Fragment数据片上。每个Fragment包含四个存储数据的数据块Block,在这几个Block中,只有一个作为MASTER,剩余的都作为REPLICA。只有MASTER才能够写入数据,从属的REPLICA自动从MASTER复制数据,REPLICA只能够读数据,这样就实现了读写分离,保持了数据的一致性。Address Server(地址服务器)会介入节点的控制,以秒级频率对节点进行心跳检查。如果MASTER出现了故障或者断电,其中一个REPLICA会自动接管,并且从那一刻起成为MASTER,保障数据库继续稳定运行。当原来出现故障的MASTER恢复后,就可以自动加入集群,并且作为一个REPLICA提供备障和分摊读压力。
4 结语
通过对数据库存储结构、存储文件系统、Fragment集群的设计,完整地提出了一套高性能的超大规模数据库引擎的设计思路。本文给出了一个支持高并发的超大规模数据库设计方案,解决了传统关系数据库在面对Web 2.0技术架构类型网站的缺陷,有效解决了关系数据库的瓶颈问题,满足当前互联网海量实时数据交互需求。
摘要：针对传统关系数据库在面对大数据处理中的瓶颈以及Web 2.0技术架构类型网站的缺陷,提出了一种能够超大规模地存储数据,并且支持高并发的数据库引擎的设计,并阐述了其实现的设计方案和技术。
关键词：关系数据库,高并发,数据库引擎
参考文献
[1]黄贤立.No SQL非关系型数据库的发展及应用初探[J].福建电脑,2010(7):30-32.
[2]Fay Chang,Jeffrey Dean,Sanjay Ghemawat,Wilson C.Hsieh,Deborah A.Wallach,Mike Burrows,Tushar Chandra,Andrew Fikes,Robert E.Gruber.Bigtable[J].ACM Transactions on Computer Systems(TOCS),2008(2).
[3]范范.No SQL数据库大比拼[N].网络世界,2011-08-15.