最新活动:柏林的NoSQL(非关系数据库) 大会

越来越多的Web应用程序需要数据存储,传统的关系数据库已经不能完全满足要求。面向对象和面向文档的数据库提供了一个选择,最近这个发展领域的发生很多活动,10月22日柏林举办了一次NoSQL大会:

Happenings: NoSQL Conference, Berlin


几十年来,关系数据库提供了对许多应用程序的所有数据类型的持久存储。基本的数据模型(图式与明确的约束)(预先确定变量的取值范围)提供所需的数据的一致性,确保交易和锁定原子访问,并提供多种方便用户访问。此外,SQL还是可靠的灵活的查询语言,特别是在数据挖掘领域最多样化的情况下。

然而,随着开发的应用越来越多,对性能的不断渴求,需要更新的持久存储解决方案,传统关系型数据库(RDBMS)已经不能满足这样的要求。有大量的系统像亚马逊,网络商店,因为放弃了数据库管理系统的锁定机制和执行客户端代码冲突的解决机制,结果大大增加了吞吐量。

二十多年前,面向对象的数据库已经建立了一支替代数据存储解决方案,更接近的面向对象,而不是一个僵化,不灵活的数据表架构。最近,“非关系型”数据库的继续发展,大有回升势头。这些数据库通常着眼于处理高数据吞吐量,并优化,高度并行,全球分布式访问情景。这样的数据库模式往往是免费:数据是关键,而不是预先确定的表,这意味着数据结构可以用较少的努力大大改变值对存储。

在10月22日,第一NoSQL发布会上对在欧洲的非关系型数据库在柏林举行。 70多个开发人员,用户包括(Peritor,nugg.ad,StudiVZ)和学术研究人员(楚泽研究所柏林,代替标准的应用科学大学法人代表NoSQL爱好者,柏林)。在Tucholskystraße聚会,newthinking商店演示概述了当前NoSQL项目的发展。

Paxos, Redis

第一个演讲这是Monika Moser, 她是Scalaris的事务存储层的开发者,现在是Erlang/Ruby/Hadoop开发者。分析了key-value存储的一致性问题。Brewer's CAP定理:只有对一致性,可用性和分区容错三个属性中两者可以在分布式系统的保障。按照沃纳福格尔斯(亚马逊)意思,该协议指出:一致性在高度可扩展系统中迟早会成为瓶颈。Moser提出Paxos:容错,可扩展的协议,协议已经应用在key-value存储中。

下面Mathias Meyer介绍了Redis,一个侧重ACID key-value存储,Redis使用基于文本的协议。该数据库支持类似字符串的基本数据类型,列表和设置以及原子操作各自的内容。数据保存在内存中,但也可以存储在转储文件的新局面。贮存场是时间依赖性,可以作出调整,以在数据库中作出的一些改变。

Redis可以通过垂直伸缩进行主从配置;水平伸缩是通过额外的库是可以实现的。Redis主要适用于高速缓存,适合工作队列和储存的统计数据。 Redis是不适合的情况:该数据不适合到主内存中。

CouchDB:

是一个面向文本数据库。文本采取以JSON格式保存,查询采取类似Hadoop和google的 Map/Reduce API ,采取的是乐观锁。

MongoDB:
融合了面向文本数据库和面向对象数据库特点,是带有HTTP/REST API的分布式key-value存储。提供javascript实现复杂查询,支持主从复制,应用在SourceForge 项目上。

这次演讲的视频和PPT可见:http://nosqlberlin.de/

专门的非SQL官方网站:
http://www.nosqloakland.org/

[该贴被admin于2009-10-30 21:38修改过]

NoSQL East 2009 第一天总结

我们首先学习的MySQL or PostgreSQL并不总是最好的解决方案。

Tokyo Tyrant 是一个数据库复制方案,可以实现在单台数据库donw机时,写操作还能够实现,Tokyo Tyrant并不是唯一数据库复制方案,key-value存储,NoSQL非关系数据库也是一个方案, NoSQL East大会正在如火如荼进行。
....

Oracle 和 SQL由于在NASDAQ遭遇瓶颈,他们的架构是用于优化写,但不擅长读回,数百万兆字节的数据,每年积累。这是解决输出数据到CSV文件,上传一个容易被猜到的文件命名为S3,服务通过HTTP文件实现。是非常愚蠢简单。

演讲有:
Cambrian Explosion—John Willis
他专注于云计算的业务方面。什么是新的数据中心将会是什么样?这家伙现在实际使用的DSL是抽象phenomenoal技术。我们认为,在一个主要由四个因素推动创新能力的爆炸基础是:
1.抽象和容错部分组成:抽象的组件,因此他们很容易把消费者在一起。

2.无限的基础设施:我们从来没有用完,不存在资源短缺,因为它们是重复性和duplicateable。

3.世界各地的合作:您可以对项目工作会议上从来没有一起人彼此负载(多见于开源世界)。

4.在知识产权的变化:开源是改变我们如何看待知识产权的主要推动力。

NoSQL 是一个伟大的名字,是新时代的开始,你得自己检查你的业务情况,不是每件事都可以填入到关系模型的标准的表和列中。

约翰在70年代开始与大型数据打交道,他曾经在与IBM 3850的500GB的数据备份系统工作。此安装费用但是是天价$ 20,000,000,。对比与西部数据硬盘,从2009年这个500GB的存储为50美元。
我们是如何越来越方便访问当今世界上大型的数据,而且比昨天便宜呢?

Voldemort的Geir Magnusson
传统的电子商务数据模型导致的性能和去耦作用非规范化。例如,为了分离用户数据和信用卡资料,就不能使用joins语法了。一旦你走上这条路,游离于标准工具外(ORM之类)。你就会寻找到其他的持久性解决方案。

Voldemort是一个带有一致性hashing的分布式映射Map,我们可以在无需重建基础上容易方便加入新的节点数据, vector clocks决定version ordering, 带有一个可插拔的存储后备系统,没有主从节点,没有单点风险。

Voldemort 有几种序列化存储选择:
1: String字符串蕾西, JSON, Protocol Buffers, Thift
2: BDB, MySQL, memory, Hadoop, MongoDB.

基本架构有下面几层:
客户端 API 层, 冲突解决层, 序列化层, 路由和读取修复层, 容错失败恢复层, 存储持久化层.

数据保存到带名称存储系统,他们有互相独立的配置,取决于与存储引擎和请求路由设置。

客户端API很简单,如下:
get(key)
getAll([key1, key2, key3, keyN])
put(key, value, version)
delete(key)
delete(key, version)

Gilt Groupe是一个非常高端的电子商务公司,每小时拥有快速启动的数百万页访问量,高交易量(注册,登录,等待清单),以及高容量的共享状态(添加到图表,结帐)。

在开始销售的产品在特定时间一直都面临的挑战是巨大的尖峰访问。他们实际上几乎关闭的一天系统中的一半。
原来的架构是:后端是使用 Rails编制的无共享几台服务器, 使用Zeus进行水平伸缩,带有一个前端的负载平衡器。问题是他们单一的PostgreSQL 遭遇瓶颈,而Rails程序虽然有效工作。

他们通过引入Voldemort作为购物车以及订单处理系统,解决了数据库的瓶颈问题。当决定使用什么存储系统时,他们看上了Tokyo Cabinet.带来问题是问,当数据集大于内存大小是,性能大大下降, BDB 工作得更好,因为它实现将内存缓存中数据异持久化到磁盘(广告:最新JdonFramework 6.2推出DomenEvents,可以实现缓存中模型进行异步持久化,代码见JiveJdon3.8的creaeReplyMessage建回帖和UpdateMessage修改帖子功能)。


[该贴被banq于2009-11-02 14:41修改过]
[该贴被banq于2009-11-02 14:41修改过]

概念是很好,但是仍有许多问题需要解决。
首要问题必须要解决如何移植。

NoSQL East 2009 第一天总结 继续:

Dynomite是一个分布式key/value store模型, 在 Amazon的Dynamo paper之后 ,使用Erlang编写。

它设计擅长存储大型数据包括图片, 他们在Microsoft收购的Powerset用来镜像实现Wikipedia 和Flickr的图片,如果你通过Bing搜索图片,很多图片是用是来自Dynomite实现.

Dynomite是使用merkle tree复制,集群式的quorum设置, vector clock都修复, physical token partitioning scheme (buckets are real buckets on disk), loads of protocol adapters (binary Erlang, Thift, ASCII), 和可插拔的后端存储。

在微软收购Powerset后,Cliff 没有再发布Dynomite新代码,这样这个项目就停滞了,他进行了几次代码提高,但是无法发布,希望微软律师能够注意到这点。

Dynamo paper 的架构是非常广泛的,程序员可以发布有态服务,而不是存储保存,一个Dynomite框架应该是这样:逻辑随着数据分布,任何模型都可以自己持久化,这样做的优点是系统有低延迟,你就不必依赖无态服务器了,缺点是它只能工作在纯粹的RESTful应用,需要一个URI作为Key实现存储。
[该贴被banq于2009-11-02 15:50修改过]
[该贴被banq于2009-11-02 15:51修改过]

NoSQL East 2009 第一天总结 继续:
CouchDB—Mike Miller

CouchDB是一个无schema的文本数据库,使用Erlang完成. 它基本特点是健壮robustness, 高并发, 和容错fault tolerance

相比其他系统,它的特点是双向增长复制.CouchDB现在有超过100的产品用户 production users, 3在写的书籍,和充满活力的社区CoucbDB是非常健壮,因为它永远不会覆盖先前写入的数据。

并发上它采用轻量级进程Erlangs方法,这意味着每个TCP连接的进程,是无锁的。

API是基于REST的, 使用标准的动词操作: GET, PUT, POST, and ELETE.

Map/reduce视图是用来产生文本数据持久化的表示,通常使用avaScript完成,这个视图保存在B-tree并且当有新数据加入时,即时更新。

双向复制是基于peer的,能够复制文本子集以符合查询约束要求,复制通过Http进行,这样复制很容易跨数据中心。

CouchDB 第一个客户是BBC,他们使用CouchDB作为已有应用设施的key/value 存储。几年下来已经被证明是非常稳定,并且能够随着数据增长而伸缩扩展。

Meebo 选择CouchDB,是因为它灵活 易于查询,可以应付数以百万计文本规模,他们还写了他们自己的Lounge库。

Scoopler 是一个大型聚合服务公司,有着快速大量的数据增长,他们从超过 40+数据表的PostgreSQL 迁移到一个 CoucbDB后,只需要两张视图.

Ubuntu 9.10 已经用CoucbDB存储用户地址簿,复制是这个领域的杀手特性。

NoSQL East 2009 第一天总结 继续
Riak—Justin Sheehy—Basho Technologies

Riak是一个面向文本数据库,非中心化的key/value store.
它是受下列思想的鼓舞和影响开发出来的:Amazon Dynamo, CAP 定理, 和 Web (至今为止最成功分布式系统the most successful distributed system to date)

Riak强调写的适用性,不像其他系统,Riak使用map/reduce,使用Riak比Hadoop+ CouchDB能够使Map/reduce更有余地。一个应用程序的请求可以处理一个小而高效的map/reduce功能。遍历网站链接是一个完美的map/reduce工作。所有关于连接指向都能够成为map/reduce功能

CAP 原理似乎以一种更加简化的方式使用,不只是简单在一致性consistency, 可用性availability, 和分区容错partition tolerance之间选择两个。它是一种你愿意采取的妥协,你要优先考虑你自己目前的水平层次。

Scalable可伸缩性不只是关于多大和多快。它是关于理解并且预测,花费多少能够使你得到更好的。它告诉你你花多少可以得到更多,有关伸缩性,关键点是你预先定义它有多伸缩。

分布式只是意味着多个系统和谐地一起工作。有必要知道如果一个系统是分散的或均匀的homogeneous(没有瓶颈,没有单点故障,没有特殊的节点)。

Cassandra Arin Sarkissian Digg

Digg 是一个使用Cassandra运营的大型网站系统,直到现在Digg还是使用LAMP stack。第一步是将Msql碎片化切分,先垂直再水平,最后结果是数据库再也不是关系型的了(no joins)。他们要选择另外一种方案:open source, 可伸缩scalable, 高性能performant, 易于管理 easily administrable。

选择Cassandra 是因为易于管理,无单点风险,比简单的 key/value store更加稳定,非常快地写,基于Java的。

Digg 实现一个绿标识功能,用户知道谁dugg过这篇文章,他们使用这个功能验证Cassandra,最后他们决定全面选择Cassandra。装入Lazyboy,一个接口Cassandra的ORM工具,易于CRUD 。

Digg最先架构是在PHP前台和Cassandra(依次是Memcached, 和 MySQL)之间有一个Python 编写的服务层,在PHP到Python通讯是用Thrift。

MongoDB Kyle Banker—10gen

MongoDB是一个面向JSON文本数据库,文本以BSON 方式保存数据库,BSON 比JSON更快速有效丰富。文本被组装成集合,这种集合类似关系数据表,但是没有表结构限制。

GridFS 是MongoDB中保存大型图片和视频的规范,MongoDB把大型文件分成多个4M大小装入集合中,MusicNation.com存储了所有音乐和视频进入MongoDB,大概1TB。

MongoDB 提供一个优化查询语句,强于SQL,MongoDB懂得文本内部结构激活动态查询。

BusinessInsider.com使用MongoDB已经两年,每个月有12M的页访问量,
使用一台MongoDB database server, 3 台Apache web servers, 和
一个前端的Memcached caching.

SourceForge.net将要移植到MongoDB, 将首页 项目页面和下载页面保存在一个文本中。

以前也是想专注oracle数据库,但是正如banq老师提出的,我们的软件的负载重心都放到了数据库身上!导致我们无法面向应用,面向服务扩展,软件的用户量也上不去!在jdon混了一段时间之后,了解了domain,entity等,发现还是没有好好学过java,ejb里面的很多思想是非常棒的!一上来就用struts这些框架,使得我们的很多面向对象的思想都淡化了,僵硬的三层结构,充血的服务层实现,以及毫无意思的dao层工具类实现变成了“非主流”式的流行!!!
总是在看了一点ejb之后才发现一些对象的知识早就有,早就存在却从没接触!看了ddd,不能理解这种思想的关键所在,没有思想的学习ddd就变成了“书虫”,什么理论性的知识,都希望配套一个方法论,照搬!
现在的感觉就是,中国的教育让我们走了很多弯路,中国的软件环境也让我们迷茫了很久,最大的关键是我们自己基础不好,没找到方向,真正的软件架构思想欠缺!!!

在此对jdon心存感激,尽管自己水平还是一般,但是看到前进的曙光了!!!

banq,您好,这次演讲的视频网站好像被屏蔽了,您那有吗?