存档

文章标签 ‘非关系型数据库’

非关系型数据库(NoSQL)Redis实现之String实现

2011年6月25日 sigma 7 条评论 53,708 views

Redis是一个性能非常优异的非关系型数据库,有测试表明,在Linux 2.6, Xeon X3320 2.5Ghz配置的系统中,Redis性能能够达到SET操作每秒钟 110000 次,GET操作每秒钟 81000 次。

其本质上是一个键值(Key-Value)数据库,类似于memcache,但其支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。据新浪微博首席架构师透露,新浪微博系统里就采用了Redis数据库。Redis的最新版本是2.2.11,现在开发非常活跃,更新非常快。

Redis有四种数据类型:string,list,set及sorted set。其中,String是最基本的数据类型,也是其他几种数据类型的基础,其中所有的key值就是String类型的。下面介绍string类型的数据结构及操作:

Redis的String实现是在sds.c文件中实现的(sds代表Simple Dynamic Strings)。

String的结构体定义sdshdr在sds.h中定义:

 struct sdshdr {
    long len;
    long free;
    char buf[];
};
 

 

阅读全文…

非关系型数据库NoSQL理论基础之CAP理论

2011年6月13日 sigma 没有评论 21,592 views

CAP理论是设计分布式web系统的一个很关键的定律,其主要内容是(非官方定义):

When designing distributed web services, there are three properties that are commonly desired: consistency, availability, and partition tolerance. It is impossible to achieve all three.

中译为:

在设计分布式Web服务中,通常需要考虑三个应用的属性:一致性、可用性以及分区宽容性。但是在实际的设计中,不可能这三方面同时做的很好。

CAP理论的C就是一致性(Consistency),这里不多解释,想了解的可以看看我之前写过的一致性的一些东西;A就是可用性(availability),可以理解为是否可获取数据,以及获取数据的速度;P就是分区容忍度(partion tolerance),指的是系统中的数据分布性的大小对系统的正确性,性能的影响(一定程度上就是可扩展性)。这个理论的主要意思就是这三个是不可以同时做到很好的,我们在实现一个分布式系统时(包括分布式数据库),是不可能同时完美的实现三个方面。其实这个理论可以用“鱼和熊掌不可兼得”一言以蔽之。

CAP理论最早是在2000年7月19号,由Berkeley的Eric Brewer教授在ACM PODC会议上的一个开题演讲中提出,PPT在。此后,MIT的Seth GilbertNancy Lynch理论上证明了Brewer猜想是正确的,CAP理论在学术上正式作为一个定理出现了。

NoSQL一定程度上就是基于这个理论提出来的,因为传统的SQL数据库(关系型数据库)都是都是具有ACID属性,对一致性要求很高,因此降低了A(availability)和P(partion tolerance),因此,为了提高系统性能和可扩展性,必须牺牲C(consistency),推翻关系型数据库中ACID这一套。

依据CAP理论,从应用的需求不同,我们对数据库(其实就是一种结构化数据存储,和Bolb恰好不同)时,可以从三方面考虑:

  • 考虑CA,这就是传统上的关系型数据库(RMDB).
  • 考虑CP,主要是一些Key-value数据库,典型代表为google的Big Table
  • 考虑AP,主要是一些面向文档的适用于分布式系统的数据库,如SimpleDB。

而对大型网站尤其是SNS网站,对于数据的短期存储,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着 A、P 的方向设计,而对于数据的持久存储,可以通过传统的SQL来保证一致性(最终一致性)。

CAP理论出现后,很多大规模的网站,尤其是SNS网站的数据库设计都利用其思想,包括Amazon,Facebook和Twitter这几个新兴的IT巨头,因此,一定程度上来讲,他们都是CAP的信徒。另一方面,他们从实践上证明了CAP理论的正确性。

最后,附上一张图片,可以形象的解释CAP理论(来源)
CAP-NoSQL
更多内容,请看这篇介绍CAP理论的文章,本文有些内容译自这里。

NoSQL非关系数据库简介

2011年6月11日 sigma 没有评论 29,852 views

昨天去听了下新浪微博首席架构师的一个讲座,其中讲到新浪微博采用了非关系数据库Redis,感觉这东西有点意思,于是搜了下,大致了解下,把看到的一些东西放到这里,算是小小总结(其中可能有误,请自行辨别)。

在计算机科学中,非关系型数据库(NoSQL)是一个和之前的关系型数据库(RDBM)有很大不同的另一类数据结构化存储管理系统。非关系型数据库通常没有固定的表结构,并且避免使用join操作。和关系型数据库相比,非关系型数据库特别适合以SNS为代表web 2.0应用,这些应用需要极高速的并发读写操作,而对数值一致性要求却不甚高。

关系型数据库的特点

关系型数据库最大特点就是事务的一致性:传统的关系型数据库读写操作都是事务的,具有ACID(原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability)的特点,C就是一致性(Consistency),这个特点是关系型数据库的灵魂(其他三个AID都是为其服务的),这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中,如典型的银行系统。

但是,在网页应用中,尤其是SNS应用中,一致性却不是显得那么重要,用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的,或者说,两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的,因此,关系型数据库的最大特点在这里已经无用武之地,起码不是那么重要了。

相反的,关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差,而像微博,facebook这类SNS的应用,对并发读写能力要求极高,关系型数据库已经无法应付(在读方面,传统上为了克服关系型数据库缺陷,提高性能,都是增加一级memcache来静态化网页,而在SNS中,变化太快,memcache已经无能为力),因此,必须用新的一种数据结构化存储来来代替关系数据库。

关系数据库的另一个特点就是其具有固定的表结构,因此,其扩展性极差,而在SNS中,系统的升级,功能的增加,往往意味着数据结构巨大改动,这一点关系型数据库也难以应付,需要新的结构化数据存储。

于是,非关系数据库(NoSQL)应运而生,由于不可能用一种数据结构化存储方式应付所有的新的需求,因此,非关系型数据库严格上不是一种数据库,应该是一种数据结构化存储方法的集合。

必须强调的是,数据的持久存储,尤其是海量数据的持久存储,还是需要关系数据库这员老将。

非关系型数据库分类

由于关系型数据库本身天然的多样性,以及出现的时间较短,因此,不像关系型数据库,有几种数据库能够一统江山,关系型数据库的非常多,并且大部分都是开源的,这里列出一些:Redis,Tokyo Cabinet,Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable,Riak,Tin, Flare,Lightcloud,KiokuDB,Scalaris,Kai,ThruDB…

这些数据库中,其实实现大部分都比较简单,除了一些共性外,很大一部分都是针对某些特定的应用需求出现的,因此,对于该类应用,具有极高的性能。依据结构化方法以及应用场合的不同,主要分为以下几类:

  1. 面向高性能并发读写的Key-Value数据库:Key-Value数据库的主要特点就是具有极高的并发读写性能,Redis,Tokyo Cabinet,Flare就是这类的代表。
  2. 面向海量数据访问的面向文档数据库(Document store):这类数据库的特点是,可以在海量的数据中快速的查询数据。典型代表为MongoDB以及CouchDB。
  3. 面向可扩展性的分布式数据库(Object Store):这类数据库想解决的问题就是传统数据库在可扩展性上的缺陷,这类数据库可以适应数据量的增加以及数据结构的变化,Google Appengine的Big Table就是这类的典型代表,并且,BigTable特别适用于Map Reduce处理。

这里只对这几类数据库简要的介绍,需要详情可以看:http://en.wikipedia.org/wiki/NoSQL

有空的话,以后也扯扯各类的具体差别,另外,个人感觉RAM Database挺有前途的,果如此,memcache就几乎不用了。最后附上一张图:

database

无觅相关文章插件,快速提升流量