2012 年NOSQL学习笔记之三

前端之家收集整理的这篇文章主要介绍了2012 年NOSQL学习笔记之三前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

2012 年NOsql学习笔记之三@H_403_5@

十一、如何理解最终一致性

最终一致性@H_403_5@

一言以蔽之:过程松,结果紧,最终结果必须保持一致性@H_403_5@

为了更好的描述客户端一致性,我们通过以下的场景来进行,这个场景中包括三个组成部分:@H_403_5@

  • 存储系统

存储系统可以理解为一个黑盒子,它为我们提供了可用性和持久性的保证。@H_403_5@

  • Process A

ProcessA主要实现从存储系统writeread操作@H_403_5@

  • Process B 和ProcessC

ProcessBC是独立于A,并且BC也相互独立的,它们同时也实现对存储系统的writeread操作。@H_403_5@

@H_403_5@

下面以上面的场景来描述下不同程度的一致性:@H_403_5@

  • 强一致性

强一致性(即时一致性)假如A先写入了一个值到存储系统,存储系统保证后续A,B,C的读取操作都将返回最新值@H_403_5@

  • 弱一致性

假如A先写入了一个值到存储系统,存储系统不能保证后续A,C的读取操作能读取到最新值。此种情况下有一个不一致性窗口的概念,它特指从A写入值,到后续操作A,C读取到最新值这一段时间。@H_403_5@

  • 最终一致性

最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统,存储系统保证如果在A,C后续读取之前没有其它写操作更新同样的值的话,最终所有的读取操作都会读取到最A写入的最新值。此种情况下,如果没有失败发生的话,不一致性窗口的大小依赖于以下的几个因素:交互延迟,系统的负载,以及复制技术中replica的个数(这个可以理解为master/salve模式中,salve的个数),最终一致性方面最出名的系统可以说是DNS系统,当更新一个域名的IP以后,根据配置策略以及缓存控制策略的不同,最终所有的客户都会看到最新的值。@H_403_5@

十二、NOsql与传统数据库系统设计上的区别

关系型数据库中的表都是存储一些格式化的数据结构,每个元组字段的组成都一样。@H_403_5@

这样做的好处就是:这样的结构非常方便进行表与表之间连接等操作。@H_403_5@

@H_403_5@

但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。为什么呢?@H_403_5@

因为不是每个元组都需要所有的字段,但是关系型数据库会为每个元组分配所有的字段。@H_403_5@

@H_403_5@

@H_403_5@

而非关系型数据库以键值对存储,它的结构不固定,每一个元组可以有不一样的字段,每个元组可以根据需要增加一些自己的键值对,这样就不会局限于固定的结构,可以减少一些时间和空间的开销。@H_403_5@

十三、NOsql的特点(或者叫优点)是什么?

n 它们可以处理超大量的数据@H_403_5@

n 它们运行在便宜的PC服务器集群上@H_403_5@

PC集群扩充起来非常方便并且成本很低,避免了“sharding”操作的复杂性和成本。@H_403_5@

n 它们击碎了性能瓶颈@H_403_5@

Nosql支持者称,通过Nosql架构可以省去将WebJava应用和数据转换成sql友好格式的时间,执行速度变得更快。@H_403_5@

sql并非适用于所有的程序代码对于那些繁重的重复操作的数据,sql值得花钱。但是当数据库结构非常简单时,sql可能没有太大用处。@H_403_5@

n 没有过多的操作@H_403_5@

虽然Nosql支持者也承认关系数据库提供了无可比拟的功能集合,而且在数据完整性上也发挥绝对稳定,他们同时也表示,企业的具体需求可能没有那么多。@H_403_5@

n Bootstrap支持@H_403_5@

因为Nosql项目都是开源的,因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样,不得不从社区中寻求支持@H_403_5@

十四、Google、FacebookAmazon等大公司用的什么NOsql产品

@H_403_5@

公司@H_403_5@

Nosql产品@H_403_5@

补充说明@H_403_5@

Google@H_403_5@

BigTable@H_403_5@

@H_403_5@

Facebook@H_403_5@

Cassandra@H_403_5@

@H_403_5@

Amazon@H_403_5@

Dynamo@H_403_5@

@H_403_5@

Apache@H_403_5@

HBase@H_403_5@

@H_403_5@

日本第一大SNS网站mix@H_403_5@

Tokyo Cabinet (TC)@H_403_5@

@H_403_5@

日本第二大SNS网站green.jp@H_403_5@

Flare@H_403_5@

@H_403_5@

淘宝网@H_403_5@

Tair@H_403_5@

Tair是由淘宝网自主开发的Key/Value结构数据存储系统,在淘宝网有着大规模的应用。您在登录淘宝、查看商品详情页面或者在淘江湖和好友“捣浆糊”的时候,都在直接或间接地和Tair交互。@H_403_5@

新浪网@H_403_5@

memcachedb@H_403_5@

memcachedb是一个由新浪网的开发人员开放出来的开源项目,给memcached分布式缓存服务器添加Berkeley DB的持久化存储机制和异步主辅复制机制,让memcached具备了事务恢复能力、持久化能力和分布式复制能力,非常适合于需要超高性能读写速度,但是不需要严格事务约束,能够被持久化保存的应用场景,例如memcachedb被应用在新浪博客上面。@H_403_5@

@H_403_5@

@H_403_5@

Leveldb是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了。在这个数量级别下还有着非常高的性能,主要归功于它的良好的设计。特别是LSM算法。@H_403_5@

LevelDB 是单进程的服务,性能非常之高,在一台4Q6600cpu机器上,每秒钟写数据超过40w,而随机读的性能每秒钟超过10w。@H_403_5@

滑铁卢大学@H_403_5@

HBase@H_403_5@

@H_403_5@

@H_403_5@

十五、 NOsql产品的按用途和环境分类

Nosql数据库根据不同的用途和环境大致可以分为以下的三类:@H_403_5@

1.满足极高读写性能需求的Kye-Value数据库

代表性产品有:@H_403_5@

RedisTokyo Cabinet Flare@H_403_5@

2.满足海量存储需求和访问的面向文档的数据库

代表性产品有:@H_403_5@

MongoDBCouchDB@H_403_5@

3.满足高可扩展性和可用性的面向分布式计算的数据库

代表性产品有:@H_403_5@

CassandraVoldemort@H_403_5@

@H_403_5@

十六、 NOsql产品的按数据存储模型分类

@H_403_5@

七、 序号@H_403_5@

数据存储模型@H_403_5@

产品@H_403_5@

特点@H_403_5@

1@H_403_5@

key-value存储@H_403_5@

Kyoto Cabinet/Tycoon@H_403_5@

可以通过key快速查询到其value。一般来说,存储不管value的格式,照单全收。(Redis包含了其他功能@H_403_5@

Redis@H_403_5@

Berkeley DB@H_403_5@

MemcacheDB@H_403_5@

Flare@H_403_5@

2@H_403_5@

文档存储@H_403_5@

MongoDB@H_403_5@

文档存储一般用类似json的格式存储,存储的内容是文档型的。这样也就有有机会对某些字段建立索引,实现关系数据库的某些功能@H_403_5@

CouchDB@H_403_5@

3@H_403_5@

列存储@H_403_5@

Hbase@H_403_5@

顾名思义,是按列存储数据的。最大的特点是方便存储结构化和半结构化数据,方便做数据压缩,对针对某一列或者某几列的查询有非常大的IO优势。@H_403_5@

Cassandra@H_403_5@

Hypertable@H_403_5@

4@H_403_5@

图存储@H_403_5@

Neo4J@H_403_5@

图形关系的最佳存储。使用传统关系数据库解决的话性能低下,而且设计使用不方便。@H_403_5@

FlockDB@H_403_5@

5@H_403_5@

对象存储@H_403_5@

db4o@H_403_5@

通过类似面向对象语言的语法操作数据库,通过对象的方式存取数据。@H_403_5@

Versant@H_403_5@

6@H_403_5@

XML数据库@H_403_5@

Berkeley DB XML@H_403_5@

高效的存储XML数据,并支持XML的内部查询语法,比如XQuery,Xpath@H_403_5@

BaseX@H_403_5@

猜你在找的NoSQL相关文章