摘要: 1 概述 Zope和CMF都是Plone需要的核心技术。 Zope是由Python编写的,他是一个强大的面向对象的、开源的编程语言,他和Perl及Tcl比较类似。使用Plone,甚至基本的管理,都不需要Python的知识;然而,定制产品和Plone上脚本编程是需要一些Python知识的。 如果你打算使用Plone做一些复杂的事情,就需要花1-2天学习Python的基础知识。这不仅将让你能更充分地定...  阅读全文
posted @ 2012-04-12 16:10 小马歌 阅读(3299) | 评论 (0)编辑 收藏
 
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\cmd\command]
@="cmd.exe /k \"cd %L\""


保存为 cmd.reg并双击即可生效。
posted @ 2012-04-12 16:01 小马歌 阅读(373) | 评论 (0)编辑 收藏
 

最近遇到一个因为页面中有多个ajax request请求,导致页面中的其它请求,如link,button事件被堵塞,不被响应。

        想到之前学习jquery的ajax时,其帮助文档有提到ajax request对象的abort功能。那就想到解决这个问题可以将页面的所有的ajax reqeust全部abort掉。后面在google查到jquery中已经有一个AjaxManager库,几乎就是为我所遇到的这个问题而生的。哈哈。。。下面介绍一下AjaxManager的简单的用法:(v2.5.4)

project site: http://plugins.jquery.com/project/AjaxManager

       //需要先建立AjaxManager(直接呼叫$.manageAjax.Add也會自動建立)
var ajaxManager = $.manageAjax.create('cacheQueue', {
    queue: true, 
    cacheResponse: true
});

这里的setting,default如下:

queue: true, //clear
maxRequests: 1,
abortOld: false,
preventDoubbleRequests: true,
cacheResponse: false

ajaxManager.add({
success: function(html) {
      $('ul').append('<li>'+html+'</li>');
},
url: 'test.html'
});
//另一種使用方式
$.manageAjax.add('clearQueue', {
success: function(html) {
      $('ul').append('<li>'+html+'</li>');
},
url: 'test.html'
});

abort使用:ajaxManager.abort(); 这样子就把队列中的request全abort了,就可以响应用户的操作行为了。

posted @ 2012-04-10 11:47 小马歌 阅读(489) | 评论 (0)编辑 收藏
 

Linux配置支持高并发TCP连接(socket最大连接数)及优化内核参数  

2011-08-09 15:20:58|  分类:LNMP&&LAMP|  标签:内核调优  文件系统调优  高并发调优  socket连接  ip_conntract  |字号大中小 订阅

Linux配置支持高并发TCP连接(socket最大连接数)
1、修改用户进程可打开文件数限制
在Linux平台上,无论编写客户端程序还是服务端程序,在进行高并发TCP连接处理时,最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄,每个socket句柄同时也是一个文件句柄)。可使用ulimit命令查看系统允许当前用户进程打开的文件数限制:
[speng@as4 ~]$ ulimit -n
1024
这表示当前用户的每个进程最多允许同时打开1024个文件,这1024个文件中还得除去每个进程必然打开的标准输入,标准输出,标准错误,服务器监听 socket,进程间通讯的unix域socket等文件,那么剩下的可用于客户端socket连接的文件数就只有大概1024-10=1014个左右。也就是说缺省情况下,基于Linux的通讯程序最多允许同时1014个TCP并发连接。
对于想支持更高数量的TCP并发连接的通讯处理程序,就必须修改Linux对当前用户的进程同时打开的文件数量的软限制(soft limit)和硬限制(hardlimit)。其中软限制是指Linux在当前系统能够承受的范围内进一步限制用户同时打开的文件数;硬限制则是根据系统硬件资源状况(主要是系统内存)计算出来的系统最多可同时打开的文件数量。通常软限制小于或等于硬限制。
修改上述限制的最简单的办法就是使用ulimit命令:
[speng@as4 ~]$ ulimit -n 
上述命令中,在中指定要设置的单一进程允许打开的最大文件数。如果系统回显类似于“Operation notpermitted”之类的话,说明上述限制修改失败,实际上是因为在中指定的数值超过了Linux系统对该用户打开文件数的软限制或硬限制。因此,就需要修改Linux系统对用户的关于打开文件数的软限制和硬限制。
第一步,修改/etc/security/limits.conf文件,在文件中添加如下行:
speng soft nofile 10240
speng hard nofile 10240
其中speng指定了要修改哪个用户的打开文件数限制,可用'*'号表示修改所有用户的限制;soft或hard指定要修改软限制还是硬限制;10240则指定了想要修改的新的限制值,即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。
第二步,修改/etc/pam.d/login文件,在文件中添加如下行:
session required /lib/security/pam_limits.so
这是告诉Linux在用户完成系统登录后,应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制),而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后保存此文件。
第三步,查看Linux系统级的最大打开文件数限制,使用如下命令:
[speng@as4 ~]$ cat /proc/sys/fs/file-max
12158
这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)12158个文件,是Linux系统级硬限制,所有用户级的打开文件数限制都不应超过这个数值。通常这个系统级硬限制是Linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制,如果没有特殊需要,不应该修改此限制,除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改/etc/rc.local脚本,在脚本中添加如下行:
echo 22158 > /proc/sys/fs/file-max
这是让Linux在启动完成后强行将系统级打开文件数硬限制设置为22158。修改完后保存此文件。
完成上述步骤后重启系统,一般情况下就可以将Linux系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。如果重启后用 ulimit-n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值,这可能是因为在用户登录脚本/etc/profile中使用ulimit -n命令已经将用户可同时打开的文件数做了限制。由于通过ulimit-n修改系统对用户可同时打开文件的最大数限制时,新修改的值只能小于或等于上次 ulimit-n设置的值,因此想用此命令增大这个限制值是不可能的。所以,如果有上述问题存在,就只能去打开/etc/profile脚本文件,在文件中查找是否使用了ulimit-n限制了用户可同时打开的最大文件数量,如果找到,则删除这行命令,或者将其设置的值改为合适的值,然后保存文件,用户退出并重新登录系统即可。
通过上述步骤,就为支持高并发TCP连接处理的通讯处理程序解除关于打开文件数量方面的系统限制。
2、修改网络内核对TCP连接的有关限制(参考对比下篇文章“优化内核参数”)
在Linux上编写支持高并发TCP连接的客户端通讯处理程序时,有时会发现尽管已经解除了系统对用户同时打开文件数的限制,但仍会出现并发TCP连接数增加到一定数量时,再也无法成功建立新的TCP连接的现象。出现这种现在的原因有多种。
第一种原因可能是因为Linux网络内核对本地端口号范围有限制。此时,进一步分析为什么无法建立TCP连接,会发现问题出在connect()调用返回失败,查看系统错误提示消息是“Can't assign requestedaddress”。同时,如果在此时用tcpdump工具监视网络,会发现根本没有TCP连接时客户端发SYN包的网络流量。这些情况说明问题在于本地Linux系统内核中有限制。其实,问题的根本原因在于Linux内核的TCP/IP协议实现模块对系统中所有的客户端TCP连接对应的本地端口号的范围进行了限制(例如,内核限制本地端口号的范围为1024~32768之间)。当系统中某一时刻同时存在太多的TCP客户端连接时,由于每个TCP客户端连接都要占用一个唯一的本地端口号(此端口号在系统的本地端口号范围限制中),如果现有的TCP客户端连接已将所有的本地端口号占满,则此时就无法为新的TCP客户端连接分配一个本地端口号了,因此系统会在这种情况下在connect()调用中返回失败,并将错误提示消息设为“Can't assignrequested address”。有关这些控制逻辑可以查看Linux内核源代码,以linux2.6内核为例,可以查看tcp_ipv4.c文件中如下函数:
static int tcp_v4_hash_connect(struct sock *sk)
请注意上述函数中对变量sysctl_local_port_range的访问控制。变量sysctl_local_port_range的初始化则是在tcp.c文件中的如下函数中设置:
void __init tcp_init(void)
内核编译时默认设置的本地端口号范围可能太小,因此需要修改此本地端口范围限制。
第一步,修改/etc/sysctl.conf文件,在文件中添加如下行:
net.ipv4.ip_local_port_range = 1024 65000
这表明将系统对本地端口范围限制设置为1024~65000之间。请注意,本地端口范围的最小值必须大于或等于1024;而端口范围的最大值则应小于或等于65535。修改完后保存此文件。
第二步,执行sysctl命令:
[speng@as4 ~]$ sysctl -p
如果系统没有错误提示,就表明新的本地端口范围设置成功。如果按上述端口范围进行设置,则理论上单独一个进程最多可以同时建立60000多个TCP客户端连接。
第二种无法建立TCP连接的原因可能是因为Linux网络内核的IP_TABLE防火墙对最大跟踪的TCP连接数有限制。此时程序会表现为在 connect()调用中阻塞,如同死机,如果用tcpdump工具监视网络,也会发现根本没有TCP连接时客户端发SYN包的网络流量。由于 IP_TABLE防火墙在内核中会对每个TCP连接的状态进行跟踪,跟踪信息将会放在位于内核内存中的conntrackdatabase中,这个数据库的大小有限,当系统中存在过多的TCP连接时,数据库容量不足,IP_TABLE无法为新的TCP连接建立跟踪信息,于是表现为在connect()调用中阻塞。此时就必须修改内核对最大跟踪的TCP连接数的限制,方法同修改内核对本地端口号范围的限制是类似的:
第一步,修改/etc/sysctl.conf文件,在文件中添加如下行:
net.ipv4.ip_conntrack_max = 10240
这表明将系统对最大跟踪的TCP连接数限制设置为10240。请注意,此限制值要尽量小,以节省对内核内存的占用。
第二步,执行sysctl命令:
[speng@as4 ~]$ sysctl -p
如果系统没有错误提示,就表明系统对新的最大跟踪的TCP连接数限制修改成功。如果按上述参数进行设置,则理论上单独一个进程最多可以同时建立10000多个TCP客户端连接。
3、使用支持高并发网络I/O的编程技术
在Linux上编写高并发TCP连接应用程序时,必须使用合适的网络I/O技术和I/O事件分派机制。
可用的I/O技术有同步I/O,非阻塞式同步I/O(也称反应式I/O),以及异步I/O。在高TCP并发的情形下,如果使用同步I/O,这会严重阻塞程序的运转,除非为每个TCP连接的I/O创建一个线程。但是,过多的线程又会因系统对线程的调度造成巨大开销。因此,在高TCP并发的情形下使用同步 I/O是不可取的,这时可以考虑使用非阻塞式同步I/O或异步I/O。非阻塞式同步I/O的技术包括使用select(),poll(),epoll等机制。异步I/O的技术就是使用AIO。
从I/O事件分派机制来看,使用select()是不合适的,因为它所支持的并发连接数有限(通常在1024个以内)。如果考虑性能,poll()也是不合适的,尽管它可以支持的较高的TCP并发数,但是由于其采用“轮询”机制,当并发数较高时,其运行效率相当低,并可能存在I/O事件分派不均,导致部分TCP连接上的I/O出现“饥饿”现象。而如果使用epoll或AIO,则没有上述问题(早期Linux内核的AIO技术实现是通过在内核中为每个 I/O请求创建一个线程来实现的,这种实现机制在高并发TCP连接的情形下使用其实也有严重的性能问题。但在最新的Linux内核中,AIO的实现已经得到改进)。
综上所述,在开发支持高并发TCP连接的Linux应用程序时,应尽量使用epoll或AIO技术来实现并发的TCP连接上的I/O控制,这将为提升程序对高并发TCP连接的支持提供有效的I/O保证。
posted @ 2012-03-26 11:49 小马歌 阅读(1682) | 评论 (0)编辑 收藏
 

去apache下载到couchDB 1.1.1版本,在debian上解压到目录couchDB,进入目录,命令:
./configure
报错:
configure: error: Could not find the js library.
Is the Mozilla SpiderMonkey library installed?
需要先安装SpiderMonkey,这是一个JS的引擎由Mozilla基金维护,安装不难,下载地址
http://ftp.mozilla.org/pub/mozilla.org/js/
下载了1.7那个,然后在debian上解压,进入js/src,命令:
make BUILD_OPT=1 -f Makefile.ref
命令:
make BUILD_OPT=1 JS_DIST=/usr/local -f Makefile.ref export
然后再去couchDB那儿
./configure
报错:
configure: error: Your SpiderMonkey library is too new.
真让人难受不是,现在卸载1.7的SM,根据当时make的信息,在usr/local/的目录下bin,lib,included子目录下删除make命令拷贝进去的东西,然后回过来把整个SpiderMonkey都删除了。接着下载js185-1.0.0版本,解压,进入到src目录,命令
./configure
make
编译完成后,回去配置couchDB,说找不到spider的库,因为,这个185xx的版本没有那个拷贝库到usr/local/lib的流程,所以,在configure的时候设置库路径参数,命令:
 ./configure --with-js-lib=/usr/local/spidermonkey/lib --with-js-include=/usr/local/spidermonkey/include
把路径改成到src目录的路径。这样之后报错:
The icu-config script could not be found.
安装icu似乎很简单,命令
apt-get install libicu-dev
然后在像上面那样configure,报错:
Could not find the `erl' executable. Is Erlang installed?
安装erl,,命令:
apt-get install erlang-nox erlang-dev
安装好了,在按上面的命令configure,哦yeah,提示:You have configured Apache CouchDB, time to relax.,接下来,命令
make install
然后,哈哈!提示我:You have installed Apache CouchDB, time to relax.

posted @ 2012-03-23 11:12 小马歌 阅读(749) | 评论 (1)编辑 收藏
 

在 NoSQL 的文档型分支中,有两个杰出的代表,一个当然是被称为下代mySQL的 MongoDB,而另一个就是CouchDB,同是文档型存储,CouchDB 与MongoDB 在应用层面上走了两条截然不同的路线,下面推荐的一篇文文章,是一篇非常好的CouchDB教程,想了解CouchDB的话,非常值得一看:

CouchDB 特性介绍:

  • CouchDB is a JSON document-oriented database written in Erlang.CouchDB是一个用Erlang 写的文档型数据库。
  • It is a highly concurrent database designed to be easily replicable, horizontally, across numerous devices and be fault tolerant.支持高并发访问,支持数据同步,高容错性的分布式存储
  • It is part of the NoSQL generation of databases.它是NoSQL 体系中的一员
  • It is an open source Apache foundation project. 它是一个Apache 基金下的开源项目
  • It allows applications to store JSON documents via its RESTful interface. 它支持JSON 数据的存储,支持RESTful方式的接口。
  • It makes use of map/reduce to index and query the database.他使用map/reduce 来构建索引及进行数据查询操作

CouchDB的优势:

  • JSON Documents – 文档在CouchDB中以JSON格式存储.
  • RESTful Interface – 对CouchDB的所有操作,包括数据CRUD,数据库管理及数据同步,都可能通过HTTP方式进行。
  • N-Master Replication – 你可以使用无限多个 master 机器,这样可能会让你能够构建很有意思的数据网络拓扑。
  • Built for Offline – CouchDB 能够运行在移动设备上(Android 系统),他可以让你的移动设备在离线时存储数据,在接入网络时再同步到云端存储。
  • Replication Filters – 可以在同步复制操作中加上一个过滤器,让你有选择性的同步数据。

CouchDB:为Internet而生:

使用CouchDB,你不仅可以把它当作一个存储,更推荐的方式是完全使用它来构建应用程序,你可以把工作代码直接写在CouchDB 中,完全不需要另外的WEB Server,可以减少开销。这也是CouchDB将自己称为是为Internet而生的原因。

CouchDB的数据查询:

与其他很多存储设备不同的是,CouchDB并不支持动态查询,相反的,它需要事先换需要查询的条件构建view,view通常是一个map函数,在已有数据基础上生成一个数据子集,在查询这个view时,如果数据有变更,会触发map函数增量更新view的内容并返回。这种方式也被称作惰性索引机制。

使用教程:

文章接下来的部分还列出了一个详细的CouchDB 使用教程:

  1. 安装CouchDB
  2. 使用CouchDB 强大的 WEB 管理工具:FUTON
  3. CouchDB 用户管理
  4. 创建一个数据文档
  5. 更新数据文档
  6. 通过CURL创建文档
  7. 查询所有文档
  8. 创建一个map函数
  9. 运行一个reduce函数

原文链接:http://goo.gl/WK7q0

posted @ 2012-03-23 11:04 小马歌 阅读(587) | 评论 (0)编辑 收藏
 

本文见于MongoDB官方网站,MongoDB与CouchDB 很相似,他们都是文档型存储,数据存储格式都是JSON型的,都使用Javascript进行操作,都支持Map/Reduce。但是其实二者有着很多本质的区别,本文透过现象追寻本质,让你更好的理解MongoDB 与CouchDB。nosqlfan 翻译如下:

原文链接:Comparing Mongo DB and Couch DB

1.MVCC(Multiversion concurrency control)

MongoDB 与 CouchDB 的一大区别就是CouchDB 是一个MVCC的系统,而MongoDB是一个update-in-place 的系统。这二者的区别就是,MongoDB 进行写操作时都是即时完成写操作,写操作成功则数据就写成功了,而CouchDB 一个支持多版本控制的系统,此类系统通常支持多个结点写,而系统会检测到多个系统的写操作之间的冲突并以一定的算法规则予以解决。

2.水平扩展性

在扩展性方面,CouchDB 使用replication 去做,而MongoDB 的replication 仅仅用来增强数据的可靠性,MongoDB 在实现水平扩展性方面使用的是Sharding。(据说CouchDB 也有开发分片功能的计划)

3.数据查询操作

这个区别在用户接口上了,MongoDB 与传统的数据库系统类似,支持动态查询,即使在没有建立索引的行上,也能进行任意的查询。而 CouchDB 不同,CouchDB 不支持动态查询,你必须为你的每一个查询模式建立相应的view,并在此view的基础上进行查询。

4.原子性

这一点上两者比较一致,都支持针对行的原子性修改(concurrent modifications of single documents),但不支持更多的复杂事务操作。

5.数据可靠性

CouchDB 是一个”crash-only” 的系统,你可以在任何时候停掉CouchDB 并能保证数据的一致性。而MongoDB 在不正常的停掉后需要运行 repairDatabase() 命令来修复数据文件,在1.7.5 版本后支持单机可靠的 –dur命令。

6.Map/Reduce

MongoDB 和 CouchDB 都支持Map/Reduce ,不同的是MongoDB 只有在数据统计操作中会用到,而CouchDB 在变通查询时也是使用 Map/Reduce。

7.使用 javascript

MongoDB 和CouchDB 都支持javascript,CouchDb 用javascript来创建view。MongoDB 使用JSON作为普通数据库操作的表达式。当然你也可以在操作中包含javascript语句。MongoDB还支持服务端的javascript脚本(running arbitrary javascript functions server-side),当然,MongoDB 的Map/Reduce 函数也是javascript 格式的。

8.REST

CouchDB 是一个RESTFul 的数据库,其操作完全走HTTP协议,而MongoDB是走的自己的二进制协议。MongoDB Server在启动时可以开放一个HTTP 的接口供状态监控。

9.性能

  • 此处主要列举了MongoDB 自己具有高性能的原因
  • 采用二进制协议,而非CouchDB REST的HTTP 协议
  • 使用Momary Map 内存映射的做法
  • collection-oriented,面向集合的存储,同一个collection的数据是连续存储的
  • update-in-place 直接修改,而非使用MVCC的机制
  • 使用C++ 编写

10.适用场景

  • 如果你在构建一个 Lotus Notes 型的应用,我们推荐使用CouchDB,主要是由于它的MVCC机制。另外如果我们需要master-master 的架构,需要基于地理位置的数据分布,或者在数据结点可能不在线的情况下,我们推荐使用CouchDB。
  • 如果你需要高性能的存储服务,那我们推荐 MongoDB,比如用于存储大型网站的用户个人信息,比如用于构建在其它存储层之上的Cache层。
  • 如果你的需求中有大量 update 操作,那么使用MongoDB吧。就像我们在例子updating real time analytics counters 中的一样,对于那种经常变化的数据,比如浏览量,访问数之类的数据存储。

anyShare一切看了好文章不转的行为,都是耍流氓!
posted @ 2012-03-23 11:02 小马歌 阅读(239) | 评论 (0)编辑 收藏
 

本文有标题党之嫌。在NoSQL如日中天的今天,各种NoSQL产品可谓百花齐放,但每一个产品都有自己的特点,有长处也有不适合的场景。本文对CassandraMongodbCouchDBRedisRiak 以及 HBase 进行了多方面的特点分析,希望看完此文的您能够对这些NoSQL产品的特性有所了解。

CouchDB

  • Written in: Erlang
  • Main point: DB consistency, ease of use
  • License: Apache
  • Protocol: HTTP/REST
  • Bi-directional (!) replication,
  • continuous or ad-hoc,
  • with conflict detection,
  • thus, master-master replication. (!)
  • MVCC – write operations do not block reads
  • Previous versions of documents are available
  • Crash-only (reliable) design
  • Needs compacting from time to time
  • Views: embedded map/reduce
  • Formatting views: lists & shows
  • Server-side document validation possible
  • Authentication possible
  • Real-time updates via _changes (!)
  • Attachment handling
  • thus, CouchApps (standalone js apps)
  • jQuery library included

Best used: For accumulating, occasionally changing data, on which pre-defined queries are to be run. Places where versioning is important.

For example: CRM, CMS systems. Master-master replication is an especially interesting feature, allowing easy multi-site deployments.

Redis

  • Written in: C/C++
  • Main point: Blazing fast
  • License: BSD
  • Protocol: Telnet-like
  • Disk-backed in-memory database,
  • but since 2.0, it can swap to disk.
  • Master-slave replication
  • Simple keys and values,
  • but complex operations like ZREVRANGEBYSCORE
  • INCR & co (good for rate limiting or statistics)
  • Has sets (also union/diff/inter)
  • Has lists (also a queue; blocking pop)
  • Has hashes (objects of multiple fields)
  • Of all these databases, only Redis does transactions (!)
  • Values can be set to expire (as in a cache)
  • Sorted sets (high score table, good for range queries)
  • Pub/Sub and WATCH on data changes (!)

Best used: For rapidly changing data with a foreseeable database size (should fit mostly in memory).

For example: Stock prices. Analytics. Real-time data collection. Real-time communication.

MongoDB

  • Written in: C++
  • Main point: Retains some friendly properties of SQL. (Query, index)
  • License: AGPL (Drivers: Apache)
  • Protocol: Custom, binary (BSON)
  • Master/slave replication
  • Queries are javascript expressions
  • Run arbitrary javascript functions server-side
  • Better update-in-place than CouchDB
  • Sharding built-in
  • Uses memory mapped files for data storage
  • Performance over features
  • After crash, it needs to repair tables
  • Better durablity coming in V1.8

Best used: If you need dynamic queries. If you prefer to define indexes, not map/reduce functions. If you need good performance on a big DB. If you wanted CouchDB, but your data changes too much, filling up disks.

For example: For all things that you would do with MySQL or PostgreSQL, but having predefined columns really holds you back.

Cassandra

  • Written in: Java
  • Main point: Best of BigTable and Dynamo
  • License: Apache
  • Protocol: Custom, binary (Thrift)
  • Tunable trade-offs for distribution and replication (N, R, W)
  • Querying by column, range of keys
  • BigTable-like features: columns, column families
  • Writes are much faster than reads (!)
  • Map/reduce possible with Apache Hadoop
  • I admit being a bit biased against it, because of the bloat and complexity it has partly because of Java (configuration, seeing exceptions, etc)

Best used: When you write more than you read (logging). If every component of the system must be in Java. (“No one gets fired for choosing Apache’s stuff.”)

For example: Banking, financial industry (though not necessarily for financial transactions, but these industries are much bigger than that.) Writes are faster than reads, so one natural niche is real time data analysis.

Riak

  • Written in: Erlang & C, some Javascript
  • Main point: Fault tolerance
  • License: Apache
  • Protocol: HTTP/REST
  • Tunable trade-offs for distribution and replication (N, R, W)
  • Pre- and post-commit hooks,
  • for validation and security.
  • Built-in full-text search
  • Map/reduce in javascript or Erlang
  • Comes in “open source” and “enterprise” editions

Best used: If you want something Cassandra-like (Dynamo-like), but no way you’re gonna deal with the bloat and complexity. If you need very good single-site scalability, availability and fault-tolerance, but you’re ready to pay for multi-site replication.

For example: Point-of-sales data collection. Factory control systems. Places where even seconds of downtime hurt.

HBase

  • Written in: Java
  • Main point: Billions of rows X millions of columns
  • License: Apache
  • Protocol: HTTP/REST (also Thrift)
  • Modeled after BigTable
  • Map/reduce with Hadoop
  • Query predicate push down via server side scan and get filters
  • Optimizations for real time queries
  • A high performance Thrift gateway
  • HTTP supports XML, Protobuf, and binary
  • Cascading, hive, and pig source and sink modules
  • Jruby-based (JIRB) shell
  • No single point of failure
  • Rolling restart for configuration changes and minor upgrades
  • Random access performance is like MySQL

Best used: If you’re in love with BigTable. :) And when you need random, realtime read/write access to your Big Data.

For example: Facebook Messaging Database (more general example coming soon)

原文链接:Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase comparison

posted @ 2012-03-23 10:28 小马歌 阅读(321) | 评论 (0)编辑 收藏
 

本文是一篇转载翻译文章,原文标题是 Is CouchDB The Anti-Redis? 作者在对比了Redis和CouchDB之后得出这样一个结论,这两家伙是反着来的,当然,这个反着来没有对和错,只是适合的应用场景不同,本人觉得其评价还是比较中肯,下面是对其主要内容的摘录和翻译,希望对你有用。

相比来看,CouchDB 的长处正是Redis的短处:存储大量的不易变但会被经常查询的数据。Redis的长处正是CouchDB的短处:存储小量的常变数据。

以一个博客系统为例,CouchDB作为一个文档型数据库,可以用来存储文章,评论,模板及附件等,而Redis以其丰富的数据类型的数据结构,更适合用来存储评论列表,网站实时状态,过滤spam,用户session信息以及页面缓存。

作为一个内存数据库,Redis提供了快速对其数据结构进行复杂操作的功能,另外通过一份顺序的日志来保证其数据可靠性。

CouchDB使用了一种append-only的数据模型,不仅在数据库数据存储上,包括其B-tree和R-tree索引都是append-only的,所以如果你的数据修改操作太多(比如计数器应用),那么CouchDB的数据文件会飞速膨胀。

Redis采用定时将内存数据Flush成RDB文件的方法来实现数据的持久化,而CouchDB的数据需要定时做数据压缩以缩减数据文件的大小,这一过程会把数据文件读入,压缩后再写成新的文件。是一个非常耗时的过程。

Redis提供了简单的索引机制和复杂的数据结构,而CouchDB提供的是复杂的索引和简单的数据结构。Redis适合用来存储实时数据,而CouchDB适合用来存储大量的文档型数据。

下面是一个更详细的各方面对比表格:

CouchdbRedis
Written inErlangC
LicenseApacheBSD
Release1.1.0, 2.0 preview2.2.12, 2.4.0RC5
APIRESTTelnet-style
API SpeedSlowFast
DataJSON documents, binary attachmentsText, binary, hash, list, set, sorted set
IndexesB-tree, R-tree, Full-text (with Lucene), any combination of data types via map/reduceHash only
QueriesPredefined view/list/show model, ad-hoc queries require table scansIndividual keys
StorageAppend-only on diskIn-memory, append-only log
UpdatesMVCCIn-place
TransactionsYes, all-or-nothing batchesYes, with conditional commands
CompactionFile rewriteSnapshot
ThreadingMany threadsSingle-threaded, forks for snapshots
Multi-CoreYesNo
MemoryTinyLarge (all data)
SSD-FriendlyYesYes
RobustYesYes
BackupJust copy the filesJust copy the files
ReplicationMaster-master, automaticMaster-slave, automatic
ScalingClustering (BigCouch)Clustering (Redis cluster*)
ScriptingJavaScript, Erlang, others via pluginLua*
FilesOne per databaseOne per database
Virtual FilesAttachmentsNo
OtherChanges feed, Standalone applicationsPub/Sub, Key expiry

来源:ai.mee.nu

posted @ 2012-03-23 10:18 小马歌 阅读(349) | 评论 (0)编辑 收藏
 

xhprof是facebook开源出来的一个php性能测试工具,也可以称之为profile工具,这个词不知道怎么翻译才比较达意。跟之前一直使用的xdebug相比,有很多类似之处。以前对xdebug有一些记录还可以供参考,但是它的缺点是对性能影响太大,即便是开启了profiler_enable_trigger参数,用在生产环境中也是惨不忍睹,cpu立刻就飙到high。

而xhprof就显得很轻量,是否记录profile可以由程序控制,因此,用在生产环境中也就成为一种可能。在它的文档上可以看到这样一种用法:

以万分之一的几率启用xhprof,平时悄悄的不打枪。

if (mt_rand(1, 10000) == 1) {  xhprof_enable(XHPROF_FLAGS_MEMORY);  $xhprof_on = true; }

在程序结尾处调用方法保存profile

if ($xhprof_on) { // stop profiler  $xhprof_data = xhprof_disable(); // save $xhprof_data somewhere (say a central DB) ... }

也可以用register_shutdown_function方法指定在程序结束时保存xhprof信息,这样就免去了结尾处判断,给个改写的不完整例子:

if (mt_rand(1, 10000) == 1) {  xhprof_enable(XHPROF_FLAGS_MEMORY);  register_shutdown_function(create_funcion('', "$xhprof_data = xhprof_disable(); save $xhprof_data;")); }

至于日志,我暂时用的是最土的文件形式保存,定期清除即可。

BTW:xhprof生成的图形方式profile真是酷毙了,哪段代码成为瓶颈,一目了然。

posted @ 2012-03-22 14:53 小马歌 阅读(320) | 评论 (0)编辑 收藏
仅列出标题
共95页: First 上一页 37 38 39 40 41 42 43 44 45 下一页 Last