技术改变世界 阅读塑造人生! - shaogx.com

This string was altered by TechBlog\Plugins\Example.; This is an example to show the potential of an offcanvas layout pattern in Bootstrap. Try some responsive-range viewport sizes to see it in action.

浅谈如何将NoSQL引入现有架构系统

经常有朋友遇到困惑,看到NoSQL的介绍,觉得很好,但是却不知道如何正式用到自己的项目中。很大的原因就是思维固定在MySQL中了,他们问得最多的问题就是用了NoSQL,我如何做关系查询。那么接下来,我们看下怎么样在我们的系统中使用NoSQL。... 全文

NoSQL

云计算如何影响NoSQL数据库的发展

Guy Harrison是Quest软件研发经理和数据库大师,最近他谈及了在Quest云计算新产品Toad和下一代称之为“NoSQL”的非关系型数据库中所做的工作,并就非关系型数据库的相关领域及云计算的推动作用回答了记者的提问。以下为访谈记录:Quest Software's Chief Officer, Guy Harrison问:什么推动了新型非关系型数据库的出现?是否是如今数量惊人的数据?... 全文

NoSQL

NoSQL生态系统大检阅 不同特性大比拼

虽然NoSQL很火热,但是真正应用NoSQL的用户不多。本文将为大家以对比的形式来介绍不同NoSQL产品的特点,希望对大家有所帮助。空前的数据量正在驱动商业寻找传统关系型数据库的替代方案,它已经为我们服务30多年了(今年5月份ACM刚刚给关系型数据庆祝40岁生日).总体来讲,这些替代方案就是目前知名的“NoSQL数据库.”... 全文

NoSQL

5款主流NoSQL数据库全方位横评

一、测试平台  本次评测并没有采用传统的关系型数据库测试常用的TPC-H标准,而是针对性的 采用写入500万条100个字节的数据,然后随机读出500条记录的方法,来评测数据的存储和读取效率,客户端采用PHP写的程序,接口使用了不同的第三 方类库,使用Apache ab工具进行并发测试。... 全文

nosql

NoSQL运动:缓慢而坚定的前进着

互联网的演化(尤其是云计算)使得关系型数据库越来越不被看好,随之而发起的NoSQL运动在一段时间内吸引了很多人的眼球。不过NoSQL运动真的能产生什么成绩么?看似已经“成熟稳重”的数据库领域居然再次掀起一轮新的浪潮。更确切地说,是数据库领域中最为稳固的关系数据模型最近居然遭遇到NoSQL支持者的尖锐质疑。... 全文

NoSQL运动

部署Oracle NoSQL数据库

一、环境介绍在CentOS系统里安装一个KVM虚拟机,然后再KVM里创建了三个内存为3G的centos虚拟机,网络采用NAT的方式。ip分别为192.168.1.151(node1) 、192.168.1.115(node2)、192.168.1.122(node3)配置hosts文件:shell里输入命令:vi /etc/hosts然后在文件里添加ip地址和对应的主机名,如果主机名不好记,最好修改下主机名(使用hostname命令查看主机名)。这样做的目的是,输入主机名就可识别节点,而不用输入节点的ip。上图中noSQL01.localdomain.com不需要,只需要前两部分二、Java环境变量配置1.在三台虚拟机里分别安装jdk1.7:安装jdk和jre:(假设jdk和jre安装包在/root/software目录下)rpm -i /root/software/jdk1.7.0.rpm rpm -i /root/software/jre1.7.0.rpm2.配置环境变量:vi /etc/profile(注:vi的操作命令自己百度一下,这些知识是操作linux的基本命令,以后经常会使用到) 在文件最后(unset -f pathmunge下面)添加:JAVA_HOME=/usr/java/jdk1.7.0_71 CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar PATH=$PATH:$JAVA_HOME/bin export PATH CLASSPATH JAVA_HOME更改之后,这些环境变量并不能马上使用,在命令行输入:source /etc/profile或者重启,也可得到同样的效果,这样设置的环境变量马上可以生效。三、安装Oracle NoSQL1.环境配置 下载Oracle NoSQL包,然后拷贝到三个虚拟机的/root/Oracle目录下(目录根据自己情况可以修改,但是建议三台虚拟机下的目录一样)。配置KVHOME和KVROOT变量:vi /etc/profile 然后在文件最后加入下内容:KVHOME=/root/Oracle/kv3.0.14 KVROOT=/root/Oracle/KVROOT export KVHOME export KVROOT同上,在命令行输入:source /etc/proile2.检测自己配置的环境变量是否正确在命令行输入:echo $JAVA_HOME echo $KVHOME如果输出的路径与设置的一致,则说明配置正确。 如果,提示$KVROOT(/root/Oracle/KVROOT)目录不存在,则创建这个目录:mkdir -p $KVROOTKVROOT这个目录后面会用到,用于存放数据库的地方。按照上面介绍的方法,在三个虚拟机里面配置KVHOME和KVROOT。如果不会从主机往虚拟机里传文件或文件夹,请参看我之前的博客(使用scp命令)。3.配置数据库服务 选择一个虚拟机作为主节点,运行一下命令:java -Xmx256m -Xms256m -jar $KVHOME/lib/kvstore.jar makebootconfig -root $KVROOT \ -port 5000 -admin 5001 -host node1 -harange 5010,5020 -store-security none -capacity 1 -num_cpus 0 -memory_mb 0如果环境配置正确,这个命令运行之后不会有什么输出。在其余两个节点上同样运行上面的命令,除了红色部分外。紧接着在三个节点上开启SNA服务:nohup java -Xmx256m -Xms256m -jar $KVHOME/lib/kvstore.jar start -root $KVROOT& 利用java的工具,检测ORACLE noSQL的服务是否在运行:#jps -m如果服务在运行就会输出服务的信息。4.配置数据库在node1上进入CLI环境:java -Xmx256m -Xms256m -jar $KVHOME/lib/kvstore.jar runadmin -port 5000 -host node14.1 Name your storekv->configure -name mystore新建数据库的名称为mystore.4.2 Create zonekv->plan deploy-zone -name "wuhan" -rf 3 -wait创建了一个名为wuhan的zone,zone相当于一个数据中心。rf指的是复制因子,wait指这个命令运行结束之后才能运行下一条命令,否则处于等待状态。4.3 Craeate an administration Process//使用 show topology命令查看zone和storage node的ID等信息kv->plan deploy-sn -zn zn1 -host node1 -port 5000 -wait kv->plan deploy-admin -sn sn1 -port 5001 -wait注意,一个是5000,一个是5001.4.4 Create a storage node poolkv->pool create -name wuhanPool将存储节点1放入pool中:kv->pool join -name wuhanPool -sn sn14.5 创建剩余存储节点node2:kv->plan deploy-sn -zn zn1 -host node2 -port 5000 -wait kv->pool join -name wuhanPool -sn sn2node3:kv->plan deploy-sn -zn zn1 -host node3 -port 5000 -wait kv->pool join -name wuhanPool -sn sn3节点ID是自增长的。4.6 配置topologykv->topology create -name topo -pool wuhanPool -partitions 300 kv->plan deploy-topology -name topo -wait4.7 结束kv->exit四、配置过程中遇到的问题1.java的问题在运行java命令(如:java -Xmx256m -Xms256m -jar $KVHOME/lib/kvstore.jar makebootconfig -root $KVROOT \ -port 5000 -admin 5001 -host node1 -harange 5010,5020 -store-security none -capacity 1 -num_cpus 0 -memory_mb 0 )总是提示"main"神马的错误。这个问题是jdk的问题,估计是系统总是启动系统自带的openJDK,而不是自己安装的jdk.解决方案:使用硬链接,将/usr/java/jdk1.7.0_71/bin下的命令链接到:/usr/bin下面,这样使用java命令时就是使用的自己安装的jdk的命令。或者使用alternatives 命令来解决,具体实行方案:1)利用update-alternatives --install选项手工添加再可选择列表中 我们采用 update-alternatives --install 选项,赋予JDK最高的级别(设置为60),以达到添加如列表中的目的,具体如下/usr/sbin/update-alternatives  -install  /usr/bin/java  java  /usr/java/jdk1.7.0_71/jre/bin/java  602)update-alternatives --config java选择添加的JDK1.6配置方案还有一种最简单的方法,就是将/usr/java/jdk1.7.0_71/bin路径添加到PATH的前面,而不是后面:PATH=/usr/java/jdk1.7.0_71/bin:$PATH  但是这种方法只在当前的shell界面里有效。所以,这种方法并不适用。2.防火墙的问题运行命令:kv->plan deploy-sn -zn zn1 -host node2 -port 5000 -wait的时候一般会遇到host is unreachable的错误。通过自己的尝试,在node2上运行 iptable -F命令,然后在运行上面的命令就可以了。记得重启!!!!!3.部署数据库过程中,中途退出adminCLI界面部署数据库的时候,有时候不小心,或者因为出现错误,尚未deploy topology就退出了部署命令行环境。再次进入adminCLI时,运行:“connect store -name [dbName]”总是提示说:“you are no longer connected to store”.或者重新配置一个数据库“configure -name [dbName]”提示说:“This command is valid only in bootstrap/configuration mode.”解决的办法就是关闭SNA服务,然后重启,再次进入adminCLI环境,重新配置一个数据库。参考资料:安装资料,点击这里. 这是Oracle提供的英文文档,里面有详尽的介绍,如果还有什么不明白,欢迎留言... 全文

oracle NoSQL 安装 部署

先睹为快:甲骨文NoSQL数据库

在过去的几年里,NoSQL数据库的世界里充满了各种有趣的新项目,雄心勃勃的声明和大量信誓旦旦的承诺。有传闻称最新的NoSQL数据库软件套装通过调整所有的结构和数据库创建者多年来一直希望增加的三倍校验来实现大幅度的性能提升。可靠性如何呢?据那些没有使用NoSQL数据库来运行大规模企业级应用软件而只是从事一些琐碎交易的华尔街银行编程人员表示,可靠性是被高估了。制表结构如何呢?过于死板和有限了。如果我们将这些问题忽略的话,那么数据库的优势是免费,且运行速度很快。... 全文

NoSQL 数据库

云计算时代NoSQL当道 关系数据库日薄西山

【3月23日51CTO外电头条】笔者参加了在加利福尼亚州圣克拉拉市举行的2010年Cloud Connect大会,这是今年最早举行的云计算重大会议之一。到目前为止,会议一个较大的议题是“不使用关系型数据库来保持数据的持久性”。这被称为 “NoSQL”运动,其宗旨是使用其他形式的数据库,更有效地处理大规模的数据。而关于围绕云计算出现的“大规模数据”,我已经写过一些文章,但是这一运动更为重要,它将推动数据回归到以更简单、但却可能更有效的模型进行物理存储的方式。51CTO数据库频道之前曾报道过《Digg投奔NoSQL 关系数据库行将就木》,也从一个侧面反映了NoSQL的发展。... 全文

NoSQL

云计算利器:Oracle NoSQL Database初体验

在过去几年里,NoSQL数据库的世界里不断涌现出各种新项目,我们时常听到雄心壮志的吹鼓手们拍着胸脯保证他们的新的NoSQL应用是怎样怎样打破了所有的旧框架,能够带来难以想象的性能。事实上呢,有些言过其实了,NoSQL依然无法进入华尔街,即使是新潮的开发者们也只敢把它用在那些人们生活中的无关紧要的琐碎数据上。但是,老式的表式结构确实局限性太大了,如果能够抛弃掉这些,数据库的速度能够得到飞速的提高。... 全文

Oracle NoSQL Database

为什么说很多NoSQL的Benchmark是扯淡?

抱歉我用了这么一个标题党的题目做为标题。写这篇文章只是想引起大家的注意:在选择NoSQL产品时,达到标称性能,需要诸多限制条件,例如本文主要讨论的磁盘I/O。现在NoSQL的产品已经很多了,很多都宣称“我们的QPS可以达到十万,甚至百万”,但是当我们在生产环境中使用的时候,却明显的感觉到,随着数据文件不断增大,NoSQL的性能却指数下降,问题处在哪里了?这些NOSQL的Benchmark的量都有一个前提“你得内存足够放下你的全部数据文件”... 全文

NoSQL

用云和NoSQL扩展PHP应用

作为最流行的Web应用语言,PHP正在被繁重的负载所压垮,除非你选择云扩展和NoSQL后台。PHP和传统关系型数据库的强大之处在于,它们能够让初级开发者快速找出应用的主要特征。但不幸的是,PHP所使用的默认运行环境混乱并且无法扩展。... 全文

云计算 NoSQL PHP

Google利用Megastore解决NoSQL、SQL融合难题

实际上,作为一个建立于Bigtable之上的分布式存储系统,Megastore已经被谷歌使用了数年。Google在2008年的SIGMOD大会上就已经开始讨论它了,但相关技术信息直到最近才被公布,在上个月举行的创新数据系统研讨会上(CIDR),Google公开了其Megastore分布式存储技术的白皮书。论文地址下载:http://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf... 全文

Megastore NoSQL

八种主流NoSQL数据库系统对比(1)

虽然SQL数据库是非常有用的工具,但经历了15年的一支独秀之后垄断即将被打破。这只是时间问题:被迫使用关系数据库,但最终发现不能适应需求的情况不胜枚举。... 全文

NoSQL

NoSQL侵入移动开发平台 CouchDB发布Android版本

【51CTO综合报道】NoSQL数据库CouchDB发布了一个移动版本CouchOne Mobile for Android。目前的版本号是v0.5,还处于早期开发阶段,但它将允许开发者利用CouchDB先进的复制功能在桌面和移动应用之间同步数据。CouchOne让你的数据无处不在... 全文

CouchDB NoSQL

NoSQL 数据建模技术详解(1)

NoSQL 数据库经常被用作很多非功能性的地方,如,扩展性,性能和一致性的地方。这些NoSQL的特性在理论和实践中都正在被大众广泛地研究着,研究的热点正是那些和性能分布式相关的非功能性的东西,我们都知道 CAP 理论被很好地应用于了 NoSQL 系统中(陈皓注:CAP即,一致性(Consistency), 可用性(Availability), 分区容忍性(Partition tolerance),在分布式系统中,这三个要素最多只能同时实现两个,而NoSQL一般放弃的是一致性)。但在另一方面,NoSQL的数据建模技术却因为缺乏像关系型数据库那样的基础理论没有被世人很好地研究。这篇文章从数据建模方面对NoSQL家族进行了比较,并讨论几个常见的数据建模技术。... 全文

NoSQL 数据建模

NoSQL数据库渐入佳境 国内应用案例盘点(1)

随着互联网的不断发展,各种类型的应用层出不穷,所以导致在这个云计算的时代,对技术提出了更多的需求。虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位,但是由于其天生的几个限制,使其很难满足上面这几个需求:扩展困难、读写慢、成本高、有限的支撑容量。业界为了解决上面提到的几个需求,推出了新类型的 “NoSQL”数据库。总的来说,在设计上,它们非常关注对数据高并发地读写和对海量数据的存储等,与关系型数据库相比,它们在架构和数据模型方量面做了”减法”,而在扩展和并发等方面做了”加法”。... 全文

NoSQL

MemBase成为NoSQL家族新成员 部署简单快速

在3月23日,North Scale公开宣布NoSQL数据库解决方案Membase已经可用了。这一发布引发了大量的报导(MarketWire, TheRegister, GigaOM)。该产品主要是由North Scale的memcached核心团队成员开发完成,其中还包括Zynga和NHN这两个主要贡献者的工程师,这两个组织都是很大的在线游戏和社区网络空间的供应商。其他早期的使用者有mig33 (移动应用) 和 Red Aril (广告). ... 全文

MemBase NoSQL

nosql探讨

转载:http://robbin.iteye.com/blog/524977随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,例如: 1、High performance - 对数据库高并发读写的需求web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。其实对于普通的BBS网站,往往也存在对高并发写请求的需求,例如像JavaEye网站的实时统计在线用户状态,记录热门帖子的点击次数,投票计数等,因此这是一个相当普遍的需求。 2、Huge Storage - 对海量数据的高效率存储和访问的需求类似Facebook,twitter,Friendfeed这样的SNS网站,每天用户产生海量的用户动态,以Friendfeed为例,一个月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统,例如腾讯,盛大,动辄数以亿计的帐号,关系数据库也很难应付。 3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服务器节点来实现扩展呢? 在上面提到的“三高”需求面前,关系数据库遇到了难以克服的障碍,而对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地,例如: 1、数据库事务一致性需求很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。 2、数据库的写实时性和读实时性需求对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说我(JavaEye的robbin)发一条消息之后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。 3、对复杂的SQL查询,特别是多表关联查询的需求任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。 因此,关系数据库在这些越来越多的应用场景下显得不那么合适了,为了解决这类问题的非关系数据库应运而生,现在这两年,各种各样非关系数据库,特别是键值数据库(Key-Value Store DB)风起云涌,多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference,各路NoSQL数据库纷纷亮相,加上未亮相但是名声在外的,起码有超过10个开源的NoSQLDB,例如: Redis,Tokyo Cabinet,Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable, Riak,Tin, Flare, Lightcloud, KiokuDB,Scalaris, Kai, ThruDB,  ...... 这些NoSQL数据库,有的是用C/C++编写的,有的是用Java编写的,还有的是用Erlang编写的,每个都有自己的独到之处,看都看不过来了,我(robbin)也只能从中挑选一些比较有特色,看起来更有前景的产品学习和了解一下。这些NoSQL数据库大致可以分为以下的三类: 一、满足极高读写性能需求的Kye-Value数据库:Redis,Tokyo Cabinet, Flare高性能Key-Value数据库的主要特点就是具有极高的并发读写性能,Redis,Tokyo Cabinet, Flare,这3个Key-Value DB都是用C编写的,他们的性能都相当出色,但出了出色的性能,他们还有自己独特的功能: 1、RedisRedis是一个很新的项目,刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过10万次读写操作,是我知道的性能最快的Key-Value DB。 Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作,例如从List两端push和pop数据,取List区间,排序等等,对Set支持各种集合的并集交集操作,此外单个value的最大限制是1GB,不像memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性能消息队列服务,用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一个功能加强版的memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,并且它没有原生的可扩展机制,不具有scale(可扩展)能力,要依赖客户端来实现分布式读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有github,Engine Yard。 2、Tokyo Cabinet和Tokoy TyrantTC和TT的开发者是日本人Mikio Hirabayashi,主要被用在日本最大的SNS网站mixi.jp上,TC发展的时间最早,现在已经是一个非常成熟的项目,也是Kye-Value数据库领域最大的热点,现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎,而TT提供了多线程高并发服务器,性能也非常出色,每秒可以处理4-5万次读写操作。 TC除了支持Key-Value存储之外,还支持保存Hashtable数据类型,因此很像一个简单的数据库表,并且还支持基于column的条件查询,分页查询和排序功能,基本上相当于支持单表的基础查询功能了,所以可以简单的替代关系数据库的很多操作,这也是TC受到大家欢迎的主要原因之一,有一个Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作,用起来非常爽。 TC/TT在mixi的实际应用当中,存储了2000万条以上的数据,同时支撑了上万个并发连接,是一个久经考验的项目。TC在保证了极高的并发读写性能的同时,具有可靠的数据持久化机制,同时还支持类似关系数据库表结构的hashtable以及简单的条件,分页和排序操作,是一个很棒的NoSQL数据库。 TC的主要缺点是在数据量达到上亿级别以后,并发写数据性能会大幅度下降,NoSQL: If Only It Was That Easy提到,他们发现在TC里面插入1.6亿条2-20KB数据的时候,写入性能开始急剧下降。看来是当数据量上亿条的时候,TC性能开始大幅度下降,从TC作者自己提供的mixi数据来看,至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。 这个是Tim Yang做的一个Memcached,Redis和Tokyo Tyrant的简单的性能评测,仅供参考3、FlareTC是日本第一大SNS网站mixi开发的,而Flare是日本第二大SNS网站green.jp开发的,有意思吧。Flare简单的说就是给TC添加了scale功能。他替换掉了TT部分,自己另外给TC写了网络服务器,Flare的主要特点就是支持scale能力,他在网络服务端之前添加了一个node server,来管理后端的多个服务器节点,因此可以动态添加数据库服务节点,删除服务器节点,也支持failover。如果你的使用场景必须要让TC可以scale,那么可以考虑flare。 flare唯一的缺点就是他只支持memcached协议,因此当你使用flare的时候,就不能使用TC的table数据结构了,只能使用TC的key-value数据结构存储。 二、满足海量存储需求和访问的面向文档的数据库:MongoDB,CouchDB面向文档的非关系数据库主要解决的问题不是高性能的并发读写,而是保证海量数据存储的同时,具有良好的查询性能。MongoDB是用C++开发的,而CouchDB则是Erlang开发的: 1、MongoDBMongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。他支持的数据结构非常松散,是类似json的bjson格式,因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。 Mongo主要解决的是海量数据的访问效率问题,根据官方的文档,当数据量达到50GB以上的时候,Mongo的数据库访问速度是MySQL的10倍以上。Mongo的并发读写效率不是特别出色,根据官方提供的性能测试表明,大约每秒可以处理0.5万-1.5次读写请求。对于Mongo的并发读写性能,我(robbin)也打算有空的时候好好测试一下。 因为Mongo主要是支持海量数据存储的,所以Mongo还自带了一个出色的分布式文件系统GridFS,可以支持海量的数据存储,但我也看到有些评论认为GridFS性能不佳,这一点还是有待亲自做点测试来验证了。 最后由于Mongo可以支持复杂的数据结构,而且带有强大的数据查询功能,因此非常受到欢迎,很多项目都考虑用MongoDB来替代MySQL来实现不是特别复杂的Web应用,比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例,由于数据量实在太大,所以迁移到了Mongo上面,数据查询的速度得到了非常显著的提升。 MongoDB也有一个ruby的项目MongoMapper,是模仿Merb的DataMapper编写的MongoDB的接口,使用起来非常简单,几乎和DataMapper一模一样,功能非常强大易用。 2、CouchDB CouchDB现在是一个非常有名气的项目,似乎不用多介绍了。但是我却对CouchDB没有什么兴趣,主要是因为CouchDB仅仅提供了基于HTTP REST的接口,因此CouchDB单纯从并发读写性能来说,是非常糟糕的,这让我立刻抛弃了对CouchDB的兴趣。 三、满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样,它首先必须是一个分布式的数据库系统,由分布在不同节点上面的数据库共同构成一个数据库服务系统,并且根据这种分布式架构来提供online的,具有弹性的可扩展能力,例如可以不停机的添加更多数据节点,删除数据节点等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的: 1、CassandraCassandra项目是Facebook在2008年开源出来的,随后Facebook自己使用Cassandra的另外一个不开源的分支,而开源出来的Cassandra主要被Amazon的Dynamite团队来维护,并且Cassandra被认为是Dynamite2.0版本。目前除了Facebook之外,twitter和digg.com都在使用Cassandra。 Cassandra的主要特点就是它不是一个数据库,而是由一堆数据库节点共同构成的一个分布式网络服务,对Cassandra的一个写操作,会被复制到其他节点上去,对Cassandra的读操作,也会被路由到某个节点上面去读取。对于一个Cassandra群集来说,扩展性能是比较简单的事情,只管在群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。 Cassandra也支持比较丰富的数据结构和功能强大的查询语言,和MongoDB比较类似,查询功能比MongoDB稍弱一些,twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra:http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/,有非常详细的介绍。 Cassandra以单个节点来衡量,其节点的并发读写性能不是特别好,有文章说评测下来Cassandra每秒大约不到1万次读写请求,我也看到一些对这个问题进行质疑的评论,但是评价Cassandra单个节点的性能是没有意义的,真实的分布式数据库访问系统必然是n多个节点构成的系统,其并发性能取决于整个系统的节点数量,路由效率,而不仅仅是单节点的并发负载能力。 2、VoldemortVoldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统,Cassandra来自于Facebook这个SNS网站,而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库,例如Cassandar,Voldemort,Tokyo Cabinet,Flare等等。Voldemort的资料不是很多,因此我没有特别仔细去钻研,Voldemort官方给出Voldemort的并发读写性能也很不错,每秒超过了1.5万次读写。 从Facebook开发Cassandra,Linkedin开发Voldemort,我们也可以大致看出国外大型SNS网站对于分布式数据库,特别是对数据库的scale能力方面的需求是多么殷切。前面我(robbin)提到,web应用的架构当中,web层和app层相对来说都很容易横向扩展,唯有数据库是单点的,极难scale,现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向,这也是为什么现在Cassandra这么热门的主要原因。 如今,NoSQL数据库是个令人很兴奋的领域,总是不断有新的技术新的产品冒出来,改变我们已经形成的固有的技术观念,我自己(robbin)稍微了解了一些,就感觉自己深深的沉迷进去了,可以说NoSQL数据库领域也是博大精深的,我(robbin)也只能浅尝辄止,我(robbin)写这篇文章既是自己一点点钻研心得,也是抛砖引玉,希望吸引对这个领域有经验的朋友来讨论和交流。 从我(robbin)个人的兴趣来说,分布式数据库系统不是我能实际用到的技术,因此不打算花时间深入,而其他两个数据领域(高性能NoSQLDB和海量存储NoSQLDB)都是我很感兴趣的,特别是Redis,TT/TC和MongoDB这3个NoSQL数据库,因此我接下来将写三篇文章分别详细介绍这3个数据库。... 全文

数据库 nosql robbin iteye 职场 休闲

主流NoSQL数据库全方位评测之MongoDB

本篇要评测的NoSQL产品是MongoDB,它是现在开源社区里越来越受到关注的一个NoSQL产品,按照官方的说法,是一个可扩展的、高性能的、开源的、面向文档的数据库。Craigslist、foursquare、国内的淘宝网等知名互联网公司都有在他们的生产环境部署了MongoDB。一、MongoDB简介... 全文

NoSQL MongoDB

1 2 3 4 5 6 7 8