针对nosql相关的论文,nosql技术

大数据时代数据管理方式研究

大数据时代数据管理方式研究

1数据管理技术的回顾

数据管理技术主要经历了人工管理阶段、文件系统阶段和数据库系统阶段。随着数据应用领域的不断扩展，数据管理所处的环境也越来越复杂，目前广泛流行的数据库技术开始暴露出许多弱点，面临着许多新的挑战。

1.1 人工管理阶段

20 世纪 50 年代中期，计算机主要用于科学计算。当时没有磁盘等直接存取设备，只有纸带、卡片、磁带等外存，也没有操作系统和管理数据的专门软件。该阶段管理的数据不保存、由应用程序管理数据、数据不共享和数据不具有独立性等特点。

1.2 文件系统阶段

20 世纪 50 年代后期到 60 年代中期，随着计算机硬件和软件的发展，磁盘、磁鼓等直接存取设备开始普及，这一时期的数据处理系统是把计算机中的数据组织成相互独立的被命名的数据文件，并可按文件的名字来进行访问，对文件中的记录进行存取的数据管理技术。数据可以长期保存在计算机外存上，可以对数据进行反复处理，并支持文件的查询、修改、插入和删除等操作。其数据面向特定的应用程序，因此，数据共享性、独立性差，且冗余度大，管理和维护的代价也很大。

1.3数据库阶段

20 世纪 60 年代后期以来，计算机性能得到进一步提高，更重要的是出现了大容量磁盘，存储容量大大增加且价格下降。在此基础上，才有可能克服文件系统管理数据时的不足，而满足和解决实际应用中多个用户、多个应用程序共享数据的要求，从而使数据能为尽可能多的应用程序服务，这就出现了数据库这样的数据管理技术。数据库的特点是数据不再只针对某一个特定的应用，而是面向全组织，具有整体的结构性，共享性高，冗余度减小，具有一定的程序与数据之间的独立性，并且对数据进行统一的控制。

2大数据时代的数据管理技术

大数据（big data），或称巨量资料，指的是所涉及的资料量规模巨大到无法透过目前主流软件工具，在合理时间内达到撷取、管理、处理、并整理成为帮助企业经营决策更积极目的的资讯。大数据有 3 个 V,一是大量化（Volume），数据量是持续快速增加的，从 TB级别，跃升到 PB 级别；二是多样化（Variety），数据类型多样化，结构化数据已被视为小菜一碟，图片、音频、视频等非结构化数据正以传统结构化数据增长的两倍速快速创建；三是快速化 （Velocity），数据生成速度快，也就需要快速的处理能力，因此，产生了“1 秒定律”,就是说一般要在秒级时间范围内给出分析结果，时间太长就失去价值了，这个速度要求是大数据处理技术和传统的数据挖掘技术最大的区别。

2.1 关系型数据库（RDBMS）

20 世纪 70 年代初，IBM 工程师 Codd 发表了著名的论文“A Relational Model of Data for Large Shared DataBanks”,标志着关系数据库时代来临。关系数据库的理论基础是关系模型，是借助于集合代数等数学概念和方法来处理数据库中的数据，现实世界中的实体以及实体之间的联系非常容易用关系模型来表示。容易理解的模型、容易掌握的查询语言、高效的优化器、成熟的技术和产品，使得关系数据库占据了数据库市场的绝对的统治地位。随着互联网 web2.0 网站的兴起，半结构化和非结构化数据的大量涌现，传统的关系数据库在应付 web2.0 网站特别是超大规模和高并发的 SNS（全称 Social Networking Services,即社会性网络服务） 类型的 web2.0 纯动态网站已经显得力不从心，暴露了很多难以克服的问题。

2.2 noSQL数据库

顺应时代发展的需要产生了 noSQL数据库技术，其主要特点是采用与关系模型不同的数据模型，当前热门的 noSQL数据库系统可以说是蓬勃发展、异军突起，很多公司都热情追捧之，如：由 Google 公司提出的 Big Table 和 MapReduce 以及 IBM 公司提出的 Lotus Notes 等。不管是那个公司的 noSQL数据库都围绕着大数据的 3 个 V,目的就是解决大数据的 3个 V 问题。因此，在设计 noSQL 时往往考虑以下几个原则，首先，采用横向扩展的方式，通过并行处理技术对数据进行划分并进行并行处理，以获得高速的读写速度；其次，解决数据类型从以结构化数据为主转向结构化、半结构化、非结构化三者的融合的问题；再次，放松对数据的 ACID 一致性约束，允许数据暂时出现不一致的情况，接受最终一致性；最后，对各个分区数据进行备份（一般是 3 份），应对节点失败的状况等。

对数据的应用可以分为分析型应用和操作型应用，分析型应用主要是指对大量数据进行分类、聚集、汇总，最后获得数据量相对小的分析结果；操作型应用主要是指对数据进行增加、删除、修改和查询以及简单的汇总操作，涉及的数据量一般比较少，事务执行时间一般比较短。目前数据库可分为关系数据库和 noSQL数据库，根据数据应用的要求，再结合目前数据库的种类，所以目前数据库管理方式主要有以下 4 类。

（1）面向操作型的关系数据库技术。

首先，传统数据库厂商提供的基于行存储的关系数据库系统，如 DB2、Oracle、SQL Server 等，以其高度的一致性、精确性、系统可恢复性，在事务处理方面仍然是核心引擎。其次，面向实时计算的内存数据库系统，如 Hana、Timesten、Altibase 等通过把对数据并发控制、查询和恢复等操作控制在内存内部进行，所以获得了非常高的性能，在很多特定领域如电信、证券、网管等得到普遍应用。另外，以 VoltDB、Clustrix 和NuoDB 为代表的 new SQL 宣称能够在保持 ACDI 特性的同时提高了事务处理性能 50 倍 ~60 倍。

（2）面向分析型的关系数据库技术。

首先，TeraData 是数据仓库领域的领头羊，Teradata 在整体上是按 Shared Nothing 架构体系进行组织的，定位就是大型数据仓库系统，支持较高的扩展性。其次，面向分析型应用，列存储数据库的研究形成了另一个重要的潮流。列存储数据库以其高效的压缩、更高的 I/O 效率等特点，在分析型应用领域获得了比行存储数据库高得多的性能。如：MonetDB 和 Vertica是一个典型的基于列存储技术的数据库系统。

（3）面向操作型的 noSQL 技术。

有些操作型应用不受 ACID 高度一致性约束，但对大数据处理需要处理的数据量非常大，对速度性能要求也非常高，这样就必须依靠大规模集群的并行处理能力来实现数据处理，弱一致性或最终一致性就可以了。这时，操作型 noSQL数据库的优点就可以发挥的淋漓尽致了。如，Hbase 一天就可以有超过 200 亿个到达硬盘的读写操作，实现对大数据的处理。另外，noSQL数据库是一个数据模型灵活、支持多样数据类型，如对图数据建模、存储和分析，其性能、扩展性是关系数据库无法比拟的。

（4）面向分析型的 noSQL 技术。

面向分析型应用的 noSQL 技术主要依赖于Hadoop 分布式计算平台，Hadoop 是一个分布式计算平台，以 HDFS 和 Map Reduce 为用户提供系统底层细节透明的分布式基础架构。《Hadoop 经典实践染技巧》传统的数据库厂商 Microsoft,Oracle,SAS,IBM 等纷纷转向 Hadoop 的研究，如微软公司关闭 Dryad 系统，全力投入 Map Reduce 的研发，Oracle 在 2011 年下半年发布 Big Plan 战略计划，全面进军大数据处理领域，IBM 则早已捷足先登“,沃森（Watson）”计算机就是基于 Hadoop 技术开发的产物，同时 IBM 发布了 BigInsights 计划，基于 Hadoop,Netezza 和 SPSS（统计分析、数据挖掘软件）等技术和产品构建大数据分析处理的技术框架。同时也涌现出一批新公司来研究Hadoop 技术，如 Cloudera、MapRKarmashpere 等。

3数据管理方式的展望

通过以上分析，可以看出关系数据库的 ACID 强调数据一致性通常指关联数据之间的逻辑关系是否正确和完整，而对于很多互联网应用来说，对这一致性和隔离性的要求可以降低，而可用性的要求则更为明显，此时就可以采用 noSQL 的两种弱一致性的理论 BASE 和 CAP.关系数据库和 noSQL数据库并不是想到对立的矛盾体，而是可以相互补充的，根据不同需求使用不同的技术，甚至二者可以共同存在，互不影响。最近几年，以 Spanner 为代表新型数据库的出现，给数据库领域注入新鲜血液，这就是融合了一致性和可用性的 newSQL,这种新型思维方式或许会是未来大数据处理方式的发展方向。

4 结束语

随着云计算、物联网等的发展，数据呈现爆炸式的增长，人们正被数据洪流所包围，大数据的时代已经到来。正确利用大数据给人们的生活带来了极大的便利，但与此同时也给传统的数据管理方式带来了极大的挑战。

为什么要使用NoSQL？NOSQL的优势

这次的NoSQL专栏系列将先整体介绍NoSQL，然后介绍如何把NoSQL运用到自己的项目中合适的场景中，还会适当地分析一些成功案例，希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。

NoSQL概念随着web2.0的快速发展，非关系型、分布式数据存储得到了快速的发展，它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。）

NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前，这些数据库就被用于各种系统当中，但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。

传统关系数据库的瓶颈

传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。

在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。

到了最近10年，网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期，论坛的流量其实也不大，如果你接触网络比较早，你可能还记得那个时候还有文本型存储的论坛程序，可以想象一般的论坛的流量有多大。

Memcached+MySQL

后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。

Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。当时，如果你去面试，你说你有Memcached经验，肯定会加分的。

Mysql主从读写分离

由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

分表分库随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。

MySQL的扩展性瓶颈

在互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可能又需要一种新的分库方式。

MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。

关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。

NOSQL的优势易扩展NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

大数据量，高性能

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

高可用NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。

总结NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。

MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。

分布式系统领域有哪些经典论文

分布式领域论文译序

sqlnosql年代记

SMAQ：海量数据的存储计算和查询

一．google论文系列

1. google系列论文译序

2. The anatomy of a large-scale hypertextual Web search engine (译 zz)

3. web search for a planet :the google cluster architecture(译)

4. GFS：google文件系统 (译)

5. MapReduce: Simplied Data Processing on Large Clusters (译)

6. Bigtable: A Distributed Storage System for Structured Data (译)

7. Chubby: The Chubby lock service for loosely-coupled distributed systems (译)

8. Sawzall:Interpreting the Data--Parallel Analysis with Sawzall (译 zz)

9. Pregel: A System for Large-Scale Graph Processing (译)

10. Dremel: Interactive Analysis of WebScale Datasets(译zz)

11. Percolator: Large-scale Incremental Processing Using Distributed Transactions and Notifications(译zz)

12. MegaStore: Providing Scalable, Highly Available Storage for Interactive Services(译zz)

13. Case Study GFS: Evolution on Fast-forward (译)

14. Google File System II: Dawn of the Multiplying Master Nodes

15. Tenzing - A SQL Implementation on the MapReduce Framework (译)

16. F1-The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business

17. Elmo: Building a Globally Distributed, Highly Available Database

18. PowerDrill：Processing a Trillion Cells per Mouse Click

19. Google-Wide Profiling:A Continuous Profiling Infrastructure for Data Centers

20. Spanner: Google’s Globally-Distributed Database(译zz)

21. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure(笔记)

22. Omega: flexible, scalable schedulers for large compute clusters

23. CPI2: CPU performance isolation for shared compute clusters

24. Photon: Fault-tolerant and Scalable Joining of Continuous Data Streams(译)

25. F1: A Distributed SQL Database That Scales

26. MillWheel: Fault-Tolerant Stream Processing at Internet Scale(译)

27. B4: Experience with a Globally-Deployed Software Defined WAN

28. The Datacenter as a Computer

29. Google brain-Building High-level Features Using Large Scale Unsupervised Learning

30. Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing(译zz)

31. Large-scale cluster management at Google with Borg

google系列论文翻译集(合集)

二．分布式理论系列

00. Appraising Two Decades of Distributed Computing Theory Research

0. 分布式理论系列译序

1. A brief history of Consensus_ 2PC and Transaction Commit (译)

2. 拜占庭将军问题 (译) --Leslie Lamport

3. Impossibility of distributed consensus with one faulty process (译)

4. Leases：租约机制 (译)

5. Time Clocks and the Ordering of Events in a Distributed System(译) --Leslie Lamport

6. 关于Paxos的历史

7. The Part Time Parliament (译 zz) --Leslie Lamport

8. How to Build a Highly Available System Using Consensus(译)

9. Paxos Made Simple (译) --Leslie Lamport

10. Paxos Made Live - An Engineering Perspective(译)

11. 2 Phase Commit(译)

12. Consensus on Transaction Commit(译) --Jim Gray Leslie Lamport

13. Why Do Computers Stop and What Can Be Done About It?(译) --Jim Gray

14. On Designing and Deploying Internet-Scale Services(译) --James Hamilton

15. Single-Message Communication(译)

16. Implementing fault-tolerant services using the state machine approach

17. Problems, Unsolved Problems and Problems in Concurrency

18. Hints for Computer System Design

19. Self-stabilizing systems in spite of distributed control

20. Wait-Free Synchronization

21. White Paper Introduction to IEEE 1588 Transparent Clocks

22. Unreliable Failure Detectors for Reliable Distributed Systems

23. Life beyond Distributed Transactions:an Apostate’s Opinion(译zz)

24. Distributed Snapshots: Determining Global States of a Distributed System --Leslie Lamport

25. Virtual Time and Global States of Distributed Systems

26. Timestamps in Message-Passing Systems That Preserve the Partial Ordering

27. Fundamentals of Distributed Computing:A Practical Tour of Vector Clock Systems

28. Knowledge and Common Knowledge in a Distributed Environment

29. Understanding Failures in Petascale Computers

30. Why Do Internet services fail, and What Can Be Done About It?

31. End-To-End Arguments in System Design

32. Rethinking the Design of the Internet: The End-to-End Arguments vs. the Brave New World

33. The Design Philosophy of the DARPA Internet Protocols(译zz)

34. Uniform consensus is harder than consensus

35. Paxos made code - Implementing a high throughput Atomic Broadcast

36. RAFT:In Search of an Understandable Consensus Algorithm

分布式理论系列论文翻译集(合集)

三．数据库理论系列

0. A Relational Model of Data for Large Shared Data Banks --E.F.Codd 1970

1. SEQUEL：A Structured English Query Language 1974

2. Implentation of a Structured English Query Language 1975

3. A System R: Relational Approach to Database Management 1976

4. Granularity of Locks and Degrees of Consistency in a Shared DataBase --Jim Gray 1976

5. Access Path Selection in a RDBMS 1979

6. The Transaction Concept:Virtues and Limitations --Jim Gray

7. 2pc-2阶段提交：Notes on Data Base Operating Systems --Jim Gray

8. 3pc-3阶段提交：NONBLOCKING COMMIT PROTOCOLS

9. MVCC：Multiversion Concurrency Control-Theory and Algorithms --1983

10. ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging-1992

11. A Comparison of the Byzantine Agreement Problem and the Transaction Commit Problem --Jim Gray

12. A Formal Model of Crash Recovery in a Distributed System - Skeen, D. Stonebraker

13. What Goes Around Comes Around - Michael Stonebraker, Joseph M. Hellerstein

14. Anatomy of a Database System -Joseph M. Hellerstein, Michael Stonebraker

15. Architecture of a Database System(译zz) -Joseph M. Hellerstein, Michael Stonebraker, James Hamilton

四．大规模存储与计算(NoSql理论系列)

0. Towards Robust Distributed Systems：Brewer's 2000 PODC key notes

1. CAP理论

2. Harvest, Yield, and Scalable Tolerant Systems

3. 关于CAP

4. BASE模型：BASE an Acid Alternative

5. 最终一致性

6. 可扩展性设计模式

7. 可伸缩性原则

8. NoSql生态系统

9. scalability-availability-stability-patterns

10. The 5 Minute Rule and the 5 Byte Rule (译)

11. The Five-Minute Rule Ten Years Later and Other Computer Storage Rules of Thumb

12. The Five-Minute Rule 20 Years Later(and How Flash Memory Changes the Rules)

13. 关于MapReduce的争论

14. MapReduce：一个巨大的倒退

15. MapReduce：一个巨大的倒退(II)

16. MapReduce和并行数据库，朋友还是敌人？(zz)

17. MapReduce and Parallel DBMSs-Friends or Foes (译)

18. MapReduce:A Flexible Data Processing Tool (译)

19. A Comparision of Approaches to Large-Scale Data Analysis (译)

20. MapReduce Hold不住？(zz)

21. Beyond MapReduce：图计算概览

22. Map-Reduce-Merge: simplified relational data processing on large clusters

23. MapReduce Online

24. Graph Twiddling in a MapReduce World

25. Spark: Cluster Computing with Working Sets

26. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

27. Big Data Lambda Architecture

28. The 8 Requirements of Real-Time Stream Processing

29. The Log: What every software engineer should know about real-time data's unifying abstraction

30. Lessons from Giant-Scale Services

五．基本算法和数据结构

1. 大数据量，海量数据处理方法总结

2. 大数据量，海量数据处理方法总结(续)

3. Consistent Hashing And Random Trees

4. Merkle Trees

5. Scalable Bloom Filters

6. Introduction to Distributed Hash Tables

7. B-Trees and Relational Database Systems

8. The log-structured merge-tree (译)

9. lock free data structure

10. Data Structures for Spatial Database

11. Gossip

12. lock free algorithm

13. The Graph Traversal Pattern

六．基本系统和实践经验

1. MySQL索引背后的数据结构及算法原理

2. Dynamo: Amazon’s Highly Available Key-value Store (译zz)

3. Cassandra - A Decentralized Structured Storage System (译zz)

4. PNUTS: Yahoo!’s Hosted Data Serving Platform (译zz)

5. Yahoo!的分布式数据平台PNUTS简介及感悟(zz)

6. LevelDB：一个快速轻量级的key-value存储库(译)

7. LevelDB理论基础

8. LevelDB：实现(译)

9. LevelDB SSTable格式详解

10. LevelDB Bloom Filter实现

11. Sawzall原理与应用

12. Storm原理与实现

13. Designs, Lessons and Advice from Building Large Distributed Systems --Jeff Dean

14. Challenges in Building Large-Scale Information Retrieval Systems --Jeff Dean

15. Experiences with MapReduce, an Abstraction for Large-Scale Computation --Jeff Dean

16. Taming Service Variability,Building Worldwide Systems,and Scaling Deep Learning --Jeff Dean

17. Large-Scale Data and Computation:Challenges and Opportunitis --Jeff Dean

18. Achieving Rapid Response Times in Large Online Services --Jeff Dean

19. The Tail at Scale(译) --Jeff Dean Luiz André Barroso

20. How To Design A Good API and Why it Matters

21. Event-Based Systems:Architect's Dream or Developer's Nightmare?

22. Autopilot: Automatic Data Center Management

七．其他辅助系统

1. The ganglia distributed monitoring system:design, implementation, and experience

2. Chukwa: A large-scale monitoring system

3. Scribe : a way to aggregate data and why not, to directly fill the HDFS?

4. Benchmarking Cloud Serving Systems with YCSB

5. Dynamo Dremel ZooKeeper Hive 简述

八. Hadoop相关

0. Hadoop Reading List

1. The Hadoop Distributed File System(译)

2. HDFS scalability:the limits to growth(译)

3. Name-node memory size estimates and optimization proposal.

4. HBase Architecture(译)

5. HFile：A Block-Indexed File Format to Store Sorted Key-Value Pairs

6. HFile V2

7. Hive - A Warehousing Solution Over a Map-Reduce Framework

8. Hive – A Petabyte Scale Data Warehouse Using Hadoop

转载请注明作者：phylips@bmy 2011-4-30

求SQL数据库论文

ORACLE中SQL查询优化研究

摘 要 数据库性能问题一直是决策者及技术人员共同关注的焦点，影响数据库性能的一个重要因素就是SQL查询语句的低效率。论文首先分析了导致SQL查询语句性能低下的四个常见原因以及SQL调优的一般步骤，然后分别针对如何降低I/O操作、在查询语句中如何避免对查询结果的高成本操作以及在多表连接时如何提高查询效率进行了分析。

关键词 ORACLE；SQL；优化；连接

1 引言

随着网络应用不断发展，系统性能已越来越引起决策者的重视。影响系统性能的因素很多，低效的SQL语句就是其中一个不可忽视的重要原因。论文首先分析导致SQL性能低下的常见原因，然后分析SQL调优应遵循的一般步骤，最后从如何降低I/O、避免对查询结果的高成本操作和多表连接中如何提高SQL性能进行了研究。鉴于目前ORACLE在数据库市场上的主导地位，论文将只针对ORACLE进行讨论。

2 影响SQL性能的原因

影响SQL性能的因素很多，如初始化参数设置不合理、导入了不准确的系统及模式统计数据从而影响优化程序(CBO)的正确判断等，这些往往和DBA密切相关。纯粹从SQL语句出发，笔者认为影响SQL性能不外乎以下四个重要原因：

(1)在大记录集上进行高成本操作，如使用了引起排序的谓词等。

(2)过多的I/O操作(含物理I/O与逻辑I/O)，最典型的就是未建立恰当的索引，导致对查询表进行全表扫描。

(3)处理了太多的无用记录，如在多表连接时过滤条件位置不当导致中间结果集包含了太多的无用记录。

(4)未充分利用数据库提供的功能，如查询的并行化处理等。

第(4)个原因处理起来相对简单。论文将针对前三个原因论述如何提高SQL查询语句的性能。

3 SQL优化的一般步骤

SQL优化一般需经过发现问题、分析问题、提出解决措施、应用措施、测试性能几个步骤，如图1所示。“发现问题就是解决问题的一半”，因此在SQL调优过程中，定位问题SQL是非常重要的一步，一般可借助于ORACLE自带的性能优化工具如STATSPACK、TKPROF、AUTOTRACE等辅助用户进行，同时还应该重视动态性能视图如V$SQL、V$MYSTAT、V$SYSSTAT等的研究。

图1 SQL优化的一般步骤

4 SQL语句的优化

4.1 优化排序操作

排序的成本十分高昂，当在查询语句中使用了引起结果集排序的谓词时，SQL性能必然受到影响。

4.1.1 排序过程分析

当待排序数据集不是太大时，服务器在内存(排序区)完成排序操作，如果排序需要更多的内存空间，服务器将进行如下处理：

(1) 将数据分成多个小的集合，对每一集合进行排序。

(2) 服务器向磁盘申请临时空间，将排好序的中间结果写入临时段，再对另外的集合进行排序。

(3) 在所有的集合均排好序后，服务器再将它们进行合并得到最终的结果，如果排序区尺寸太小，合并无法一次完成时，将分多次进行。

从上述分析可知，排序是一种十分昂贵的操作，它消耗大量的CPU时间和内存，触发磁盘分页和交换操作，因此只要有可能，我们就应该在SQL语句中尽量避免排序操作。

4.1.2 SQL中引起排序的操作

SQL查询语句中引起排序的操作大致有：ORDER BY 和GROUP BY 从句；DISTINCT修饰符；UNION、INTERSECT、MINUS集合操作符；多表连接时的排序合并连接(SORT MERGE JOIN)等。

4.1.3 如何避免排序

1)建立恰当的索引

对经常进行排序和连接操作的字段建立索引。在建立索引后，当服务器向这些字段发出排序请求时，将直接引用索引而不进行排序操作；当进行等值连接查询操作时，若建立连接的字段未建立索引，服务器进行的是排序合并连接(SORT MERGE JOIN)，连接操作的过程如下：

对进行连接的两个或多个表分别进行全扫描；

对每一个表中的行集分别进行全排序；

合并排序结果。

如果建立连接的字段已建立索引，服务器进行嵌套循环连接(NESTED LOOP JOINS)，该连接方式不需要任何排序，其过程如下：

对驱动表进行全表扫描；

对返回的每一行利用连接字段值实施索引惟一扫描；

利用从索引扫描中返回的ROWID值在从表中定位记录；

合并主、从表中的匹配记录。

因此，建立索引可避免多数排序操作。

2)用UNIION ALL替换UNION

UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。大部分应用中是不会产生重复记录的，最常见的是过程表与历史表UNION 。因此，采用UNION ALL操作符替代UNION，因为UNION ALL操作只是简单的将两个结果合并后就返回。

4.2 优化I/O

过多的I/O操作会占用CPU时间、消耗大量内存和占用过多的栓锁，因此有必要对SQL的I/O进行优化。优化I/O的最有效方式就是用索引扫描代替全表扫描。

4.2.1 应用基于函数的索引

基于函数的索引(FUNCTION BASED INDEX，简记为FBI)提供了索引计算列并在查询中使用这些索引的能力。FBI的实质是对查询所需中间结果进行预处理。如果一个FBI与查询语句中的内嵌函数完全匹配，CBO在生成查询计划时，将自动启用索引范围扫描(INDEX RANGE SCAN)替换全表扫描(FULL TABLE SCAN)。考察下面的代码段并用AUTOTRACE观察创建FBI前后执行计划的变化。

select * from emp where upper(ename)=’SCOTT’

创建FBI前，很明显是全表扫描。

Execution Plan

……

1 0 TABLE ACCESS (FULL) OF 'EMPLOYEES' (Cost=2 Card=1 Bytes=22)

idleCREATE INDEX EMP_UPPER_FIRST_NAME ON EMPLOYEES(UPPER(FIRST_NAME))；

索引已创建。

再次运行相同查询，

Execution Plan

……

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMPLOYEES' (Cost=1 Card=1 Bytes=22)

2 1 INDEX (RANGE SCAN) OF 'EMP_UPPER_FIRST_NAME' (NON-UNIQUE) (Cost=1 Card=1)

这一简单的例子充分说明了FBI在SQL查询优化中的作用。FBI所用的函数可以是用户自己创建的函数，该函数越复杂，基于该函数创建FBI对SQL查询性能的优化作用越明显。

4.2.2 应用物化视图和查询重写

物化视图是一个预计算结果集，其中通常包含聚集与多表连接等复杂操作。数据库自动维护物化视图，且随用户的要求进行刷新。查询重写机制就是用数据库中的替代对象(如物化视图)将用户提交的查询重写为完全不同但功能等价的查询。查询重写对用户透明，用户完全按常规编写访问数据库的查询语句，优化程序(CBO)自动决定是否对用户提交的查询进行重写。查询重写是提高查询性能的一种非常有效的方法，尤其是在数据仓库环境中针对汇总、多表连接以及其它高成本的操作方面。

下面以一个非常简单的例子来演示物化视图和查询重写在优化SQL查询性能方面的作用。

select dept.deptno，dept.dname，count(*)

from emp，dept

where emp.deptno=dept.deptno

group by dept.deptno，dept.dname

查询计划及主要统计数据如下：

执行计划：

-----------------------------------------

……

2 1 HASH JOIN (Cost=5 Card=14 Bytes=224)

3 2 TABLE ACCESS (FULL) OF 'DEPT' (Cost=2 Card=4 Bytes=52)

4 2 TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=14 Bytes=42)

主要统计数据：

-----------------------------------------

305 recursive calls

46 consistent gets

创建物化视图EMP_DEPT：

create materialized view emp_dept build immediate

refresh on demand

enable query rewrite

as

select dept.deptno，dept.dname，count(*)

from emp，dept

where emp.deptno=dept.deptno

group by dept.deptno，dept.dname

/

再次执行查询，执行计划及主要统计数据如下：

执行计划：

-------------------------------------

……

1 0 TABLE ACCESS (FULL) OF 'EMP_DEPT' (Cost=2 Card=327 Bytes=11445)

主要统计数据：

------------------------------------

79 recursive calls

28 consistent gets

可见，在建立物化视图之前，首先执行两个表的全表扫描，然后进行HASH连接，再进行分组排序和选择操作；而建立物化视图后，CBO自动将上述复杂操作转换为对物化视图EMP_DEPT的全扫描，相关的统计数据也有了很大的改善，递归调用(RECURSIVE CALLS)由305降到79，逻辑I/O(CONSISTENT GETS)由46降为28。

4.2.3 将频繁访问的小表读入CACHE

逻辑I/O总是快于物理I/O。如果数据库中存在被应用程序频繁访问的小表，可将这些表强行读入KEEP池，从而避免物理I/O的发生。

4.3 多表连接优化

最能体现查询复杂性的就是多表连接，多表连接操作往往要耗费大量的CPU时间和内存，因此多表连接查询性能优化往往是SQL优化的重点与难点。

4.3.1 消除外部连接

通过消除外部连接，不仅使得到的查询更易于读取，而且性能也经常可以得到改善。一般的思路是，有以下形式的查询：

SELECT …，OUTER_JOINED_TABLE.COLUMN

FROM SOME_TABLE，OUTER_JOINED_TO_TABLE

WHERE …=OUTER_JOINED_TO_TABLE(+)

可转换为如下形式的查询：

SELECT …，(SELECT COLUMN FROM OUTER_ JOINED_TO_TABLE WHERE …)FROM SOME_TABLE；

4.3.2 谓词前推，优化中间结果

多表连接的性能低下多数是因为连接操作与过滤操作的次序不合理，大多数用户在编写多表连接查询时，总是先进行连接操作再应用过滤条件，这导致服务器做了太多的无用功。针对这类问题，其优化思路就是尽可能将过滤谓词前推，使不符合条件的记录提前被筛选掉，只对符合条件的少数记录进行连接处理，这样可成倍的提高SQL查询效能。

标准连接查询如下：

Select a.prod_name，sum(b.sale_quant)，

sum(c.sale_quant)，sum(d.sale_quant)

From product a，tele_sale b，online_sale c，store_sale d

Where a.prod_id=b.prod_id and a.prod_id=c.prod_id

and a.prod_id=d.prod_id And a.order_datesysdate-90

Group by a.prod_id；

启用内嵌视图，且将条件a.order_datesysdate-90前移，优化后代码如下：

Select a.prod_name，b.tele_sale_sum，c.online_sale_sum，d.store_sale_sum From product a，

(select sum(sal_quant) tele_sale_sum from product，tele_sale

Where product.order_datesysdate-90 and product.prod_id =tele_sale.prod_id) b，

(select sum(sal_quant) online_sale_sum

from product，tele_sale

Where product.order_datesysdate-90 and product.prod_id =online_sale.prod_id) c，

(select sum(sal_quant) store_sale_sum

from product，store_sale

Where product.order_datesysdate-90 and product.prod_id =store_sale.prod_id) d，

Where a.prod_id=b.prod_id and

a.prod_id=c.prod_id and a.prod_id=d.prod_id；

5 结束语

SQL语言在数据库应用中占有非常重要的地位，其性能的优劣直接影响着整个信息系统的可用性。论文从影响SQL性能的最主要的三个方面入手，分析了如何优化SQL查询的I/O、避免高成本的排序操作和优化多表连接。需要强调的一点是，理解SQL语句所解决的问题比SQL调优本身更重要，因此SQL调优需要系统分析人员、开发人员和数据库管理员密切协作。

参考文献

[1]Thomas Kyte.Effective Oracle by Design：Design and Build High-performance Oracle Application[M]，The McGral- Hill Companies，Inc，2003

[2]Kevin Loney，George Koch，Oracle 9i：The Complete Reference[M]，The McGral-Hill Companies，Inc，2002

[3] Oracle9i SQL Reference release 2(9.2)[OL/M]，2002.10. http：//

[4] Oracle9i Data Warehousing Guide release 2(9.2) [OL/M]，2002.03. http：//

[5]Alexey Danchenkov，Donald Burleson，Oracle Tuning：The Definitive Reference[OL/M]，Rampant Techpress，2006.

[6] Oracle9i Database Concepts release 2(9.2) [OL/M]，2002.08. http：//

[7] Oracle9i supplied plsql packages and types reference release 2(9.2) [OL/M]，2002.12. http：// technology/