大数据应用到数据集，其大小超出了常用软件工具所能捕捉、管理和在可承受的时间内处理数据的能力。Big Data的规模在不断变化，单一数据集的规模从几十个TB涨到多个PB。

IDC估计到2011年数据约达到1.8ZB。

ZB有多大?答案是10亿个TB。目前世界人口有7亿也就是说，如果给每个人250G硬盘存储空间仍然是不够用的。

这次的数据洪流有诸多来源：

1. 纽约证券交易所每天产生1TB的新交易数据;

2. Facebook主机存储100亿张照片会占用1PB空间;

3. Ancestry.com，家谱网，存储约2.5PB数据;

4. 互联网档案馆存储约2PB数据，并以每月约20TB的速度增长;

5. Geneva附近的Large Harden Colider每年将产生15PB的数据;

6. 人们每天从传感器、移动设备、网上交易和社交网络创造相当于2.5万亿字节的数据。

Facebook、Yahoo和Google发现他们以空前的规模汇集数据。他们是第一批从上百万用户中汇集数据的大公司。

这些数据迅速淹没了传统的例如Oracle和MySQL等的数据系统。即便是最好的、最昂贵的供应商使用最大规模的硬件也只能勉强跟上，无法给他们有力的工具来分析数据的涌入。

在2000年初，开发诸如MapReduce、BigTable、Google File System的新技术来处理大数据。最初，这些技术是专有的。但随后人们注意到公开的概念会更有利-因为越来越多的人会有助于此，并且他们雇佣的毕业生在加入他们之前对此也会有一个良好的理解。

在2004-2005年度，Facebook、Yahoo和Google开始共享描述他们大数据技术的研究论文。

2004年，Google发表题为“MapReduce：在大型集群上简化数据处理(MapReduce: Simplified Data Processing on Large Clusters)”的论文。

MapReduce

是一个编程模型，同时也是一个处理和生成大型数据的工具。用户指定映射函数来处理一对key-value以生成一个中间key-value的集合，指定reduce函数合并相同的中间键关联的所有的中间值。正如这篇文章所写，现实世界的许多工作都可以在这个模型中得以表达。

以此功能所编写的程序自动并行，而且能在商品机大型集群上执行。系统处理分割输入数据的细节，跨机器调度程序执行，处理机器故障，管理所需的机器间的通讯。这样使得没有任何操作并行和分布式系统经验的程序员同样可以轻松地利用大型分布式系统的资源。Google基于MapReduce实现在大型集群的商品机上运行并且这是高度可伸缩的。

一个典型的MapReduce在成百上千台机器上处理大量的数据。设计器和系统是很容易使用的。数以百计的MapReduce程序已经实施并且每天有超过一千的MapReduce工作在Google集群执行。

Nutch

是一个开源的搜索技术，现在由Apache Software Foundation管理，而为其工作的Doug Cutting阅读了由Google发表的此文和由Google分布式文件系统[GFS]发表的另一篇文章，指出GFS可以解决他们的存储要求，MapReduce也会解决Nuth和实施MapReduce及GFS的缩放问题。他们把为Nutch实施的GFS命名为Nutch Distributed Filesystem[NDFS]。

NDFS和Nutch的MapReduce的实现超出了搜索领域，并于2006年2月迁移出Nutch构建成一个名为Hadoop和NDFS的独立的Lucene子项目，成为HDFS[Hadoop分布式文件系统]，这是一个GFS的实现。与此同时，Yahoo延长了他们对Hadoop的支持并雇佣了Doug Cutting。

在HDFS的工作层面，有一个300MB的文件[Hadoop的PB级和TB级文件非常好]。HDFS所需做的第一件事就是将它分割为若干块。HDFS上的默认块的大小为128MB。一旦把他们分割成块，我们将得到分别为128MB和44MB的两个部分。现在，HDFS将"n"["n"即是配置]作为每个块的拷贝/副本的一部分。HDFS将这些副本存储在集群的不同数据节点上。我们也有单一的保持着副本和数据节点路径的数据NameNode。NameNode清楚副本在什么位置-每当它检测到有副本损坏[DataNode一直在副本上进行校验]或者相应的HDFS变为down，它将会寻找集群中该副本的其他副本，并告诉其他节点复制该副本的"n"。NameNode是一个单点故障-两个点就会避免出现这种情况，我们会有与主要NameNode同步的次要NameNode-当主的变为down-从的将会起控制作用。Hadoop项目目前工作在分布式的NameNodes上。

Google在2006年又发表了一篇名为“Bigtable：一个结构化数据的分布式存储系统(Bigtable: A Distributed Storage System for Structured Data)”的文章。

Bigtable

是一个管理结构化数据的分布式存储系统，它的设计扩展到一个非常大的规模，跨越了成千上万服务器的PB级数据。Google许多项目的数据都存储在Bigtable中，其中包括网页索引、Google Earth和Google Finance。这些在Bigtable中的应用有不同的需求，不仅是在数据大小方面(从网页地址到卫星图像)还有在延迟要求方面(从后台数据处理到实时数据服务)。尽管这些需求不同，Bigtable为Google的产品提供了一个柔性的、高性能的解决方案。本文介绍了Bigtable中提供的简单的数据模型，Bigtable使得客户可以对数据的布局和格式进行动态控制，并且描述了Bigtable的设计和实施。

Bigtable映射任意两个字符串值(行值和列值)和时间戳(三维映射)关联的任意字节数组。这并不是个关系型数据库，更应该定义为sparse，分布式多维分类映射。

Bigtable基本上讨论了怎样在GFS上建立分布式数据存储。

由Hadoop所生成的HBase是一个BigTable的实现。HBase

是一个分布式、列导向的、利用HDFS为其底层存储同时支持使用MapReduce和点查询的批量计算的数据库。

Amazon，在2007年出版了“Dynamo：亚马逊高度可用Key-value存储(Dynamo: Amazon"s Highly Available Key-value Store)”的文章。

Dynamo

是一个高度可用的Key-value存储系统，Amazon的核心服务提供一个“always-on”的技巧。Apache Cassandra汇集了Dynamo的完全分布式设计和BigTable的数据模型，用Java进行编写，由Facebook发布的开源系统。这是个NoSQL的解决方案，最初由Facebook开发，直到2010年底，增强他们的收件箱搜索功能。事实上，Cassandra最初的开发工作是由两个由Facebook从Amazon招募的Dynamo工程师进行的。但是在2010年底当Facebook建立了基于HBase的信息平台后便放弃了Cassandra。

此外，除了使用BigTable的建模方法，它具有类似于最终一致性的属性，Gossip协议，master-master方式的读服务和Amazon Dynamo产生的写请求。最终一致性是其中一个重要的属性，意味着在一段足够长的时间内没有发送更改信息，所有的更新都可以预期，最终系统和所有副本也将保持一致。

再说到Cassandra

时，使用了“NoSQL”一词。NoSQL(有时候解释为not only SQL)是数据库管理系统的一个宽泛类，在一些重大方面，它不同于典型的关系型数据库管理系统(RDBMS)。这些数据存储不需要固定的表模式，通常能够避免连接操作，可以进行横向扩展。

“NoSQL”这个名字最初是由Carlo Strozzi在1998年提出的，作为由他开发的基于文件的数据库的名称。具有讽刺意味的是，它仅仅是个没有SQL接口的关系型数据库而已。当Eric Evans在2009年用它来命名非关系型数据库的流冲击(current surge)的时候，这个名字重新复出水面。

NoSQL数据库有四个类别：

1. Key-value stores：基于Amazon的Dynamo文件;

2. ColumnFamily / BigTable clones：例如HBase、Cassandra;

3. Document Databases：例如CouchDB、MongoDB;

4. Graph Database：例如AllegroGrapgh、Neo4j。

正如Marin Dimitrov所言，以下是NoSQL数据库的使用场合，换句话说，是关系型数据库不适合执行的情况。

1. 庞大的数据量;

2. 极端的查询量;

3. 模式演化。

我们从NoSQL上可以得到高可扩展性、高可用性、低成本(与同等规模的解决方案相比)、可预见的弹性和架构灵活性的优势。

对于应用程序来说关系型数据库和Cassandra的主要区别在于基于BigTable的数据模型。Cassandra数据模型是专为大规模的分布式数据所设计的。在性能、可用性和运算管理遵从惯有的优势。