QClub NoSQL主题 : : 硕鼠的博客站

QClub NoSQL主题

Filed Under : 梦想园 by Luke Fan

8月.7,2012

QClub是InfoQ下面的一个活动品牌，主要是以技术活动为主。这次在盛大创新院北京office做了一场NoSQL数据库的专场活动。

本人作为地主，欢迎大家走进盛大创新院，参加在盛大创新院举办的活动。

做Cassandra分享的是盛大云，云存储项目的王旭，他是《cassandra的权威指南》的译者。

做MongoDB分享的，是盛大云，数据库云和MongoIC项目的负责人，郭理靖

什么是NoSQL

NoSQL，是现在很时髦的一个概念了。现在有越来越多的成功应用，号称在后台使用NoSQL数据库。为什么在SQL数据库几乎一统天下的时候，NoSQL又卷土重来了呢？

数据库的作用主要有两个：第一、存储数据；第二、检索数据。以前的SQL数据库，能够将数据之间的复杂关系处理得很好，能够将万千世界中的各种各样的数据模型，存储到数据库中，然后再取出来。在这个过程中还能够保证各种各样现实世界中存在的约束得以实行。

随着互联网的发展，很多应用的需求不再是描述复杂的业务逻辑，而变成了将某些简单的业务逻辑进行高并发处理。而这个高并发，使用传统的SQL数据库来处理，其成本会高得让人难以想象的。于是就有了很多NoSQL数据库的应用场景。

所谓的NoSQL，最开始说的是不使用SQL的数据库，后来发现NoSQL这种非常畸形的设计，很难满足各种需求，有时候应用也无法逃避那些复杂的数据业务逻辑，最终的妥协就是NoSQL变成了不仅仅有SQL的数据库。

NoSQL比SQL还早产生，并一直伴随着SQL

在SQL产生之前，或者说是一统江湖之前，所有的数据存储方式，其实都是NoSQL的。在SQL基本上一统江湖之后，那些不是使用SQL进行数据存储和检索的方式，被剥夺了数据库的身份。那个时候很多程序是使用数据文件，自己处理数据的存储和提取问题的，在这个阶段，NoSQL就是以这种形式继续陪伴着SQL数据库。

现在，大家谈NoSQL，就是那些通过数据文件存储数据的应用，经过发展，产生出了一些如同神迹一般的应用。而数据文件的存储方式，功能也逐步丰富，加入了分布式、以及Map/Reduce等能力。一些成功的公司，将自己内部使用的数据存储程序封装成了开源系统，开放出来给大家使用。大家又重新承认NoSQL也是一种数据库了。

为极限设计而生的NoSQL

当我们的应用环境变得越来越追求极限，那么原来那些较为平衡的解决方案，那些通常情况下放之四海皆准，或者说至少是以放之四海而皆准为目标设计的解决方案，已经无法适应于现在这种极致的环境了。在这种情况下，才需要NoSQL数据库的介入。

NoSQL数据库通常解决几种特殊的问题

大并发存储

facebook是一个非常极限的应用，数据结构相对比较简单，但是数据并发异常庞大。全世界的人，除了天朝之外，都可以在上面分享自己当前正在想什么、做什么，这些人可以自由的选择和哪些人成为好友，及时的了解到他们的正在做些什么。几亿用户在线发布各种信息，查看他人的信息和状态，那么数据压力可想而知。这种情况，使用传统的大型数据库就很难满足要求了。也不是绝对无法满足，只是如果那么做的话，成本实在是太高了。

分布式存储，并进行弹性、线性扩展

这个问题，通常情况下和上一个是同一个问题。当并发达到一定程度，使用一台服务器将很难满足并发的需要，购买更大型的服务器，性价比肯定没有购置大量低端服务器来得划算。而且，大型的服务器，扩展起来也是非常不划算的。

于是，为了响应巨大的并发和数据量，进行分布式部署也就成了一个必然的选择。使用多台廉价服务器来分担并发压力，分散存储数据，将数据进行多份存储以确保数据的安全，这就是分布式存储的最基本要求。

对于分布式存储的另外一个要求，就是进行在线弹性、线性扩展。购买100万的服务器，当服务器负荷达到一定程度的时候，再购买一台100万的服务器，这种扩展方式肯定不是线性的。使用廉价服务器，根据需要灵活的添加或减少服务器的数量。

弹性扩展，也就是说要能够在需要的时候，将服务器增加上去，在不需要的时候还要能够将不需要的服务器裁减下来。现在的NoSQL数据库很多都采用了Hash离散环的架构来存储数据，弹性、线性的扩展都在设计考虑的范围之内。

Map/Reduce

当需要对分布在几百、上千甚至是上万台服务器上的数据进行统计分析的时候，利用所有服务器的运算能力，对服务器上的数据进行就近的处理和运算也是必然的结果。这就是著名的Map/Reduce了。多台服务器上的数据进行统计分析时，运算效率会极大的受到网络传输效率的影响，NoSQL数据库通常都是分布式存储的，那么在运算的时候，也同样需要分布式的运算。

相对自由的MetaData

SQL数据库也叫关系型数据库，数据之间的关系和约束肯定是非常严格的。以前的传统系统都需要通过数据模型设计来将这个数据的结构确定下来。传统系统中，调整数据库结构是非常麻烦的一件事情，所有和这些数据相关的程序都需要重新调整，才能确保系统的可用。

互联网应用中，数据的形态千变万化，很难在设计的时候进行穷举，于是有些基于文档的NoSQL数据库，其数据结构就相对比较灵活，每一条数据里面存储的数据结构都可以是不同的。

选择NoSQL数据库

极致的设计，通常并不适合用来解决那些特定需求之外的其他问题，每一种NoSQL数据库都是为特定环境而设计的，需要根据需求来进行选择。

Cassandra就更适合与要求大并发存取的环境，Cassandra的读性能一般，但是写入性能，系统的在线、线性、弹性扩展性能堪称完美。甚至可以在牺牲数据一致性的情况下，将速度进一步提高。

MongoDB则是文档数据库的典范，数据结构异常灵活，而且现在应用相对广泛，稳定性和成熟度也是非常不错的。

对于那些需要进行复杂逻辑处理的数据，不防继续使用传统的SQL数据库。选择正确的，而不是时髦的解决方案。

留有余地

做事要留有余地，即使是为了极限环境而设计的NoSQL数据库，如果真的达到了极致的状态，也是无法应对的。

digg的cassandra案例，foursquire的MongoDB案例，都是在系统达到极限，添加节点的时候崩溃的。此类系统在添加节点的时候，所有节点的负荷都会上升，这是因为，新加入的节点是空的，新节点需要从其他节点上复制和迁移数据，以便为应用服务，而这个复制和迁移数据的过程，就成为了压死骆驼的最后一根稻草。

即使使用转为大并发和在线扩展而设计的NoSQL数据库，也不要等到服务器达到极限状态的时候，再添加节点。要留有余地。

硕鼠的博客站

范路的博客主站，时而会发些东西。