博客服务器最早使用shell脚本定期获取数据记录到日志里,不过把监控日志放在服务器上并不是一个好的选择,一旦服务器异常往往无法登陆上去查看日志,所以用处并不大。后来用了监控宝,感觉还不错,不过时间周期比较长,且记录不能永久保存。于是搞了个GAE版的服务器监控。
程序分两部分,服务器端和GAE端,服务器端用c编写,通过读取/proc/stat等来获取系统当前数据,分割并序列化后用curl推送到GAE,GAE端获取数据后将数据存储。
这个程序相比shell脚本的优势在于直接读取proc目录,减少了中间环节。
这次服务端程序改为常驻系统运行,避免了多次fork,且内存使用更稳定。

现有问题:
时间间隔不准确,由于推送数据是同步推送,导致数据获取时间间隔略大于指定时间。

下一步:
改进时间间隔的问题,增加数据处理功能。优化代码。

Gearman的Persistent Queues使用

[| 2011/04/14 11:55]
Gearman从0.6版起添加了Persistent Queues,通过把任务队列存入mysql等位置达到将队列持久化的目的,可以保证在server重启后任务队列可以恢复。
为了和已有服务器环境兼容,我使用了0.14版本。注意在编译时要加上--with-libdrizzle-prefix[=DIR]选项打开libdrizzle支持,DIR位置为libdrizzle安装的位置。
编译完成后,可以用gearmand -q libdrizzle --libdrizzle-db=some_db --libdrizzle-table=gearman_queue命令来启动gearmand,在0.14版本中gearmand一旦加入了libdrizzle选项,就没有错误日志了。。一旦出错就直接退出,很让人郁闷,出了问题只能盲猜。不知最新版本是否改进了这点。
启动时需要注意指定数据库用户一定要求相应权限,否则程序会直接退出。还有要注意的时候要加上-q libdrizzle来启用libdrizzle。如果不加这个只是指定libdrizzle选项的话是不起作用的。

其它选项可以使用gearmand -h查看或去官方网站gearman.org查询
前几天做了个Memcached的思考,并测试了一些数据,是关于如何提高Memcached内存使用率的问题。
在启动memcached的时候可以加-f参数和-n参数。-f指定各slab里面chunk大小的变化比例,默认1.25,-n指定slab里面chunk大小从多少开始。
使用memcache_add($memcache_obj, md5(rand()), str_repeat(md5(rand()),10), false,80000 );向memcache中持续灌入数据。


Memcached –d start –m 50 启动memcache,增长系数默认为1.25
结果:
2011-03-28 11:15:37:SAR:localh~211: 10 0 0 0 0/0% 0 5 265 50M 0% 0 0 0 4/0/0
2011-03-28 11:15:40:SAR:localh~211: 11 0 0 530 0/0% 0 192K 4K 50M 1% 797 530 0 4/0/0
2011-03-28 11:15:43:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 105K 50M 17% 21K 13K 0 4/0/1
2011-03-28 11:15:46:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 104K 50M 48% 61K 13K 0 4/1/1
2011-03-28 11:15:49:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 102K 50M 77% 98K 13K 580 4/1/2
2011-03-28 11:15:52:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 103K 50M 92% 116K 13K 13K 4/1/3
2011-03-28 11:15:55:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 105K 50M 92% 116K 13K 13K 4/2/4
2011-03-28 11:15:58:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 107K 50M 92% 116K 13K 13K 4/2/5
2011-03-28 11:16:01:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 101K 50M 92% 116K 13K 13K 4/3/6

使用率稳定在92%,存储116k条
stats slabs
STAT 8:chunk_size 440
STAT 8:chunks_per_page 2383
STAT 8:total_pages 50
STAT 8:total_chunks 119150
STAT 8:used_chunks 119150

使用了大小为440字节的chunk。 使用了id为8的slab

Memcached –d start –m 50 –f 2 增长系数为2
结果:
2011-03-28 11:17:53:SAR:localh~211: 10 0 0 0 0/0% 0 5 267 50M 0% 0 0 0 4/0/0
2011-03-28 11:17:56:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 107K 50M 16% 20K 13K 0 4/0/0
2011-03-28 11:17:59:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 106K 50M 47% 60K 13K 0 4/1/1
2011-03-28 11:18:02:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 106K 50M 63% 80K 13K 13K 4/1/2
2011-03-28 11:18:05:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 105K 50M 63% 80K 13K 13K 4/1/3
2011-03-28 11:18:08:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 108K 50M 63% 80K 13K 13K 4/2/4
2011-03-28 11:18:11:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 106K 50M 63% 80K 13K 13K 4/2/5

使用率稳定在63%,存储80k条。
STAT 4:chunk_size 640
STAT 4:chunks_per_page 1638
STAT 4:total_pages 50
STAT 4:total_chunks 81900
STAT 4:used_chunks 81900

使用了大小为640的chunk,使用了id为4的slab


Memcached –d start –m 50 –f 1.001 –n 375 增长率为1.001 (memcache要求增长率必须大于1)
结果:
2011-03-28 14:40:09:SAR:127.0.~211: 11 0 0 12K 0/0% 0 4M 100K 50M 98% 124K 12K 10K 4/1/3
2011-03-28 14:40:10:SAR:127.0.~211: 11 0 0 13K 0/0% 0 5M 104K 50M 99% 125K 13K 13K 4/1/3
2011-03-28 14:40:11:SAR:127.0.~211: 11 0 0 13K 0/0% 0 5M 106K 50M 99% 125K 13K 13K 4/2/4

使用率稳定在99%,存储125k条
STAT 1:chunk_size 408
STAT 1:chunks_per_page 2570
STAT 1:total_pages 6
STAT 1:total_chunks 15420
STAT 1:used_chunks 15022

使用了大小为408的chunk,使用了id为1的slab


可见调整-f和-n的值可有效提高memcache对内存的使用率。
不过需要注意的是,以上测试数据使用了同长度数据,对于长度不定长的数据,需要根据整体数据确定-f和-n的值。
经过我的测试slab的id值最大为200,若id为199的slab中chunk仍小于数据长度,那么需要将数据存放在id为200的slab中,该slab中的chunk大小为1m,造成内存的巨大浪费。
memcached -d start -m 50 -f 1.001 -n 100
2011-03-28 14:51:15:SAR:127.0.~211: 11 0 0 13K 0/0% 0 5M 101K 50M 0% 50 13K 13K 4/1/2

内存使用率约等于0,存储50条数据
STAT 200:chunk_size 1048576
STAT 200:chunks_per_page 1
STAT 200:total_pages 50
STAT 200:total_chunks 50
STAT 200:used_chunks 50

使用了大小为1m的chunk,使用了id为200的slab


现在还有一个问题:
STAT 1:chunk_size 408
STAT 1:chunks_per_page 2570
一个1m大小slab中存放了2570个大小为408的chunk,可见并没有放满,剩余的空间就被浪费了。对于这种情况,每个slab浪费的内存只有几百个字节,可以忽略不计,但是假如chunk大小为几十上百k的时候,空间浪费情况就很客观了。这时可在memcached启动时添加-I(大写的i)参数来改变slab的大小

以上就是我做的评测和总结出来的一些东西,限于个人水平,如有错误之处请大家指正。

MongoDB评测

[| 2011/04/08 18:46]
最近对MongoDB做了个评测。

MongoDB是一种No-SQL数据库,存储数据采用BSON格式将数据序列化后存储。不过BSON对象最大有4m的限制,对于大于4m的,MongoDB会使用GridFs来将文件分块存储。

这里需要注意的是,在OpenVZ的VPS上需要用ulimit来限制程序最大可用的内存,否则程序会试图分配很大的内存导致OpenVZ内存配额耗尽。

测试数据:id字段:1000000-2000000的一个数字
Msg字段:32*30字节
测试脚本语言:PHP
自己搭建的虚拟机:Ubuntu 10.10,总内存:256M。
100w条插入:无索引用时70s,平均1.5w/s。插入后程序占用内存110M
100w条随机读取一条:无索引时30s,有索引12ms。


在一台Intel(R) Xeon(R) CPU E5620 @ 2.40GHz,内存2G的服务器上测试:

100w条插入:无索引用时43s。插入后程序占用内存1G。
100w条随机读取一条:无索引600ms,有索引0.18ms。


Gearman的一些心得

[| 2011/04/02 16:58]
最近项目要用到Gearman,之前在《构建高性能Web站点》这本书上看到过,不过一直没有太注意。最近详细研究了一下,发现还是很有用的。

Gearman是个可以把计算能力分布式部署的工具,由server,worker,client三部分组成。server在linux上叫做gearmand,使用gearmand -d即可运行,默认端口是4730。负责分配任务。
worker由用户编写,可以使用多种语言,c,php,python等等均可,作用是像server注册一个函数,表示自己可以处理该类计算请求。client也是由用户编写,语言不必和worker相同,
向server提交计算请求,并获取计算结果。

关于gearman比较好的一篇blog:http://www.kongch.com/2010/04/gearman-how-to/

之前一直疑惑server是如何根据worker的负载来分配任务的,看了原理后发现原来任务并不是由server分配,而是由worker主动领取的,
这样就大大简化了server和worker的逻辑。
如下是工作流程:
1,Worker通过CAN_DO消息,注册到Job server上。
2,随后发起GRAB_JOB,主动要求分派任务。
3,Job server如果没有job可分配,就返回NO_JOB。
4,Worker收到NO_JOB后,进入空闲状态,并给Job server返回PRE_SLEEP消息,告诉Job server:”如果有工作来的话,用NOOP请求我先。”
5,Job server收到worker的PRE_SLEEP消息后,明白了发送这条消息的worker已经进入了空闲态。
6,这时如果有job提交上来,Job server会给worker先发一个NOOP消息。
7,Worker收到NOOP消息后,发送GRAB_JOB向Job server请求任务。
8,Job server把工作派发给worker。
9,Worker干活,完事后返回WORK_COMPLETE给Job server。

不过看到这里我有一些疑问,就是在第六步的时候server向worker同时发送NOOP,会不会导致惊群效应?这个问题留待考证。

现在版本的gearman并不能监控worker的状态,任务的分配过程对client又是透明的,如果在多台机器上部署多个worker的话并不能直接获取各worker的状态。

不过通过编写一些函数还是可以实现这个功能的,甚至可以完全用gearman来监控多台服务器。网上有篇文章也讲到了这点,不过非常简略。我想了一个方式,比较幼稚,
欢迎指正:
worker基础函数及变量:
setID():用来接收监控端置入id,运行一次后注销。
manage():用来接收控制和状态查询请求,默认关闭,在setID中开启。
functionInUse():已注册的功能函数列表。
functionNotUse():未注册的功能函数列表。
count数组:记录各个功能函数执行次数。
exitWorker():退出worker,导致worker进程退出,慎用。
newWorker():启动新worker。
unregisterFunction:注销指定功能函数。
registerFunction:注册指定功能函数。



1,新worker在启动时只注册setId函数。此时worker处在就绪未注册状态。
2,监控client发送setId请求,参数为唯一id。
3,就绪未注册状态worker收到setId请求,设置id为自己的id,返回自己的主机名和进程号,然后注册manage函数为manage_id,其中id为自己的id,最后注销setId函数,进入就绪已注册状态。
4,监控client收到应答后将id与主机名进程号对应起来。
5,监控client重复2,直到无就绪未注册状态worker。

现在所有的worker都处在就绪已注册状态,监控client处也获得了所有worker的信息,此时初始化完毕,监控client通过调用manage_id来启动相应worker的指定功能函数,
worker进入工作状态。

此时整个系统开始正常工作。监控client可以周期性的调用manage_id来获取各worker的运行状态,并可以控制各个worker的注册功能函数数量。这时无论是根据负载自动调整各个worker还是上线新版本都是很方便的。


Gmagick初体验

[| 2011/03/25 11:07]
最近要用到Gmagick,用php开发,装了相关扩展。开始着手学一下。首先搞到了手册,没有中文的,网上其它资料也很少。于是决定先汉化一下手册,一方面在汉化的过程中能有个整体了解,还有就是利于分享,减少团队重复学习成本。

第一遍翻译大概用了一天时间,一百多个函数,很多由于涉及到图像方面的专业术语,不大了解。手册上也有很多说的模糊的地方,甚至函数的原型都有错误。一遍下来标了很多问号。

然后用一个小时的时间把函数进行了分类,分成图像处理类和图像操作类,便于查询。

然后准备用一天半的时间对每个函数进行使用,明确不清晰的地方,修正错误。并阅读范例代码,了解整体使用思想。

大数据量的问题是很多面试笔试中经常出现的问题,比如baidu google 腾讯 这样的一些涉及到海量数据的公司经常会问到。

下面的方法是我对海量数据的处理方法进行了一个一般性的总结,当然这些方法可能并不能完全覆盖所有的问题,但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目,方法不一定最优,如果你有更好的处理方法,欢迎与我讨论。

1.Bloom filter

适用范围:可以用来实现数据字典,进行数据的判重,或者集合求交集

基本原理及要点:
对于原理来说很简单,位数组+k个独立hash函数。将hash函数对应的值的位数组置1,查找时如果发现所有hash函数对应位都是1说明存在,很明显这个过程并不保证查找的结果是100%正确的。同时也不支持删除一个已经插入的关键字,因为该关键字对应的位会牵动到其他的关键字。所以一个简单的改进就是 counting Bloom filter,用一个counter数组代替位数组,就可以支持删除了。

还有一个比较重要的问题,如何根据输入元素个数n,确定位数组m的大小及hash函数个数。当hash函数个数k=(ln2)*(m/n)时错误率最小。在错误率不大于E的情况下,m至少要等于n*lg(1/E)才能表示任意n个元素的集合。但m还应该更大些,因为还要保证bit数组里至少一半为0,则m应该>=nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2为底的对数)。

举个例子我们假设错误率为0.01,则此时m应大概是n的13倍。这样k大概是8个。

注意这里m与n的单位不同,m是bit为单位,而n则是以元素个数为单位(准确的说是不同元素的个数)。通常单个元素的长度都是有很多bit的。所以使用bloom filter内存上通常都是节省的。

扩展:
Bloom filter将集合中的元素映射到位数组中,用k(k为哈希函数个数)个映射位是否全1表示元素在不在这个集合中。Counting bloom filter(CBF)将位数组中的每一位扩展为一个counter,从而支持了元素的删除操作。Spectral Bloom Filter(SBF)将其与集合元素的出现次数关联。SBF采用counter中的最小值来近似表示元素的出现频率。

问题实例:给你A,B两个文件,各存放50亿条URL,每条URL占用64字节,内存限制是4G,让你找出A,B文件共同的URL。如果是三个乃至n个文件呢?

根据这个问题我们来计算下内存的占用,4G=2^32大概是40亿*8大概是340亿,n=50亿,如果按出错率0.01算需要的大概是650亿个bit。现在可用的是340亿,相差并不多,这样可能会使出错率上升些。另外如果这些urlip是一一对应的,就可以转换成ip,则大大简单了。

2.Hashing

适用范围:快速查找,删除的基本数据结构,通常需要总数据量可以放入内存

基本原理及要点:
hash函数选择,针对字符串,整数,排列,具体相应的hash方法。
碰撞处理,一种是open hashing,也称为拉链法;另一种就是closed hashing,也称开地址法,opened addressing。

扩展:
d-left hashing中的d是多个的意思,我们先简化这个问题,看一看2-left hashing。2-left hashing指的是将一个哈希表分成长度相等的两半,分别叫做T1和T2,给T1和T2分别配备一个哈希函数,h1和h2。在存储一个新的key时,同时用两个哈希函数进行计算,得出两个地址h1[key]和h2[key]。这时需要检查T1中的h1[key]位置和T2中的h2[key]位置,哪一个位置已经存储的(有碰撞的)key比较多,然后将新key存储在负载少的位置。如果两边一样多,比如两个位置都为空或者都存储了一个key,就把新key 存储在左边的T1子表中,2-left也由此而来。在查找一个key时,必须进行两次hash,同时查找两个位置。

问题实例:
1).海量日志数据,提取出某日访问百度次数最多的那个IP。

IP的数目还是有限的,最多2^32个,所以可以考虑使用hash将ip直接存入内存,然后进行统计。

3.bit-map

适用范围:可进行数据的快速查找,判重,删除,一般来说数据范围是int的10倍以下

基本原理及要点:使用bit数组来表示某些元素是否存在,比如8位电话号码

扩展:bloom filter可以看做是对bit-map的扩展

问题实例:

1)已知某个文件内包含一些电话号码,每个号码为8位数字,统计不同号码的个数。

8位最多99 999 999,大概需要99m个bit,大概10几m字节的内存即可。

2)2.5亿个整数中找出不重复的整数的个数,内存空间不足以容纳这2.5亿个整数。

将bit-map扩展一下,用2bit表示一个数即可,0表示未出现,1表示出现一次,2表示出现2次及以上。或者我们不用2bit来进行表示,我们用两个bit-map即可模拟实现这个2bit-map。

4.堆

适用范围:海量数据前n大,并且n比较小,堆可以放入内存

基本原理及要点:最大堆求前n小,最小堆求前n大。方法,比如求前n小,我们比较当前元素与最大堆里的最大元素,如果它小于最大元素,则应该替换那个最大元素。这样最后得到的n个元素就是最小的n个。适合大数据量,求前n小,n的大小比较小的情况,这样可以扫描一遍即可得到所有的前n元素,效率很高。

扩展:双堆,一个最大堆与一个最小堆结合,可以用来维护中位数。

问题实例:
1)100w个数中找最大的前100个数。

用一个100个元素大小的最小堆即可。

5.双层桶划分

适用范围:第k大,中位数,不重复或重复的数字

基本原理及要点:因为元素范围很大,不能利用直接寻址表,所以通过多次划分,逐步确定范围,然后最后在一个可以接受的范围内进行。可以通过多次缩小,双层只是一个例子。

扩展:

问题实例:
1).2.5亿个整数中找出不重复的整数的个数,内存空间不足以容纳这2.5亿个整数。

有点像鸽巢原理,整数个数为2^32,也就是,我们可以将这2^32个数,划分为2^8个区域(比如用单个文件代表一个区域),然后将数据分离到不同的区域,然后不同的区域在利用bitmap就可以直接解决了。也就是说只要有足够的磁盘空间,就可以很方便的解决。

2).5亿个int找它们的中位数。

这个例子比上面那个更明显。首先我们将int划分为2^16个区域,然后读取数据统计落到各个区域里的数的个数,之后我们根据统计结果就可以判断中位数落到那个区域,同时知道这个区域中的第几大数刚好是中位数。然后第二次扫描我们只统计落在这个区域中的那些数就可以了。

实际上,如果不是int是int64,我们可以经过3次这样的划分即可降低到可以接受的程度。即可以先将int64分成2^24个区域,然后确定区域的第几大数,在将该区域分成2^20个子区域,然后确定是子区域的第几大数,然后子区域里的数的个数只有2^20,就可以直接利用direct addr table进行统计了。

6.数据库索引

适用范围:大数据量的增删改查

基本原理及要点:利用数据的设计实现方法,对海量数据的增删改查进行处理。
扩展:
问题实例:


7.倒排索引(Inverted index)

适用范围:搜索引擎,关键字查询

基本原理及要点:为何叫倒排索引?一种索引方法,被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。

以英文为例,下面是要被索引的文本:
T0 = "it is what it is"
T1 = "what is it"
T2 = "it is a banana"
我们就能得到下面的反向文件索引:
"a": {2}
"banana": {2}
"is": {0, 1, 2}
"it": {0, 1, 2}
"what": {0, 1}
检索的条件"what", "is" 和 "it" 将对应集合的交集。

正向索引开发出来用来存储每个文档的单词的列表。正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在校验文档中的验证这样的查询。在正向索引中,文档占据了中心的位置,每个文档指向了一个它所包含的索引项的序列。也就是说文档指向了它包含的那些单词,而反向索引则是单词指向了包含它的文档,很容易看到这个反向的关系。

扩展:

问题实例:文档检索系统,查询那些文件包含了某单词,比如常见的学术论文的关键字搜索。

8.外排序

适用范围:大数据的排序,去重

基本原理及要点:外排序的归并方法,置换选择 败者树原理,最优归并树

扩展:

问题实例:
1).有一个1G大小的一个文件,里面每一行是一个词,词的大小不超过16个字节,内存限制大小是1M。返回频数最高的100个词。

这个数据具有很明显的特点,词的大小为16个字节,但是内存只有1m做hash有些不够,所以可以用来排序。内存可以当输入缓冲区使用。

9.trie树

适用范围:数据量大,重复多,但是数据种类小可以放入内存

基本原理及要点:实现方式,节点孩子的表示方式

扩展:压缩实现。

问题实例:
1).有10个文件,每个文件1G, 每个文件的每一行都存放的是用户的query,每个文件的query都可能重复。要你按照query的频度排序 。

2).1000万字符串,其中有些是相同的(重复),需要把重复的全部去掉,保留没有重复的字符串。请问怎么设计和实现?

3).寻找热门查询:查询串的重复度比较高,虽然总数是1千万,但如果除去重复后,不超过3百万个,每个不超过255字节。

10.分布式处理 mapreduce

适用范围:数据量大,但是数据种类小可以放入内存

基本原理及要点:将数据交给不同的机器去处理,数据划分,结果归约。

扩展:

问题实例:

1).The canonical example application of MapReduce is a process to count the appearances of

each different word in a set of documents:
void map(String name, String document):
// name: document name
// document: document contents
for each word w in document:
EmitIntermediate(w, 1);

void reduce(String word, Iterator partialCounts):
// key: a word
// values: a list of aggregated partial counts
int result = 0;
for each v in partialCounts:
result += ParseInt(v);
Emit(result);
Here, each document is split in words, and each word is counted initially with a "1" value by

the Map function, using the word as the result key. The framework puts together all the pairs

with the same key and feeds them to the same call to Reduce, thus this function just needs to

sum all of its input values to find the total appearances of that word.

2).海量数据分布在100台电脑中,想个办法高效统计出这批数据的TOP10。

3).一共有N个机器,每个机器上有N个数。每个机器最多存O(N)个数并对它们操作。如何找到N^2个数的中数(median)?


经典问题分析

上千万or亿数据(有重复),统计其中出现次数最多的前N个数据,分两种情况:可一次读入内存,不可一次读入。

可用思路:trie树+堆,数据库索引,划分子集分别统计,hash,分布式计算,近似统计,外排序

所谓的是否能一次读入内存,实际上应该指去除重复后的数据量。如果去重后数据可以放入内存,我们可以为数据建立字典,比如通过 map,hashmap,trie,然后直接进行统计即可。当然在更新每条数据的出现次数的时候,我们可以利用一个堆来维护出现次数最多的前N个数据,当然这样导致维护次数增加,不如完全统计后在求前N大效率高。

如果数据无法放入内存。一方面我们可以考虑上面的字典方法能否被改进以适应这种情形,可以做的改变就是将字典存放到硬盘上,而不是内存,这可以参考数据库的存储方法。

当然还有更好的方法,就是可以采用分布式计算,基本上就是map-reduce过程,首先可以根据数据值或者把数据hash(md5)后的值,将数据按照范围划分到不同的机子,最好可以让数据划分后可以一次读入内存,这样不同的机子负责处理各种的数值范围,实际上就是map。得到结果后,各个机子只需拿出各自的出现次数最多的前N个数据,然后汇总,选出所有的数据中出现次数最多的前N个数据,这实际上就是reduce过程。

实际上可能想直接将数据均分到不同的机子上进行处理,这样是无法得到正确的解的。因为一个数据可能被均分到不同的机子上,而另一个则可能完全聚集到一个机子上,同时还可能存在具有相同数目的数据。比如我们要找出现次数最多的前100个,我们将1000万的数据分布到10台机器上,找到每台出现次数最多的前 100个,归并之后这样不能保证找到真正的第100个,因为比如出现次数最多的第100个可能有1万个,但是它被分到了10台机子,这样在每台上只有1千个,假设这些机子排名在1000个之前的那些都是单独分布在一台机子上的,比如有1001个,这样本来具有1万个的这个就会被淘汰,即使我们让每台机子选出出现次数最多的1000个再归并,仍然会出错,因为可能存在大量个数为1001个的发生聚集。因此不能将数据随便均分到不同机子上,而是要根据hash 后的值将它们映射到不同的机子上处理,让不同的机器处理一个数值范围。

而外排序的方法会消耗大量的IO,效率不会很高。而上面的分布式方法,也可以用于单机版本,也就是将总的数据根据值的范围,划分成多个不同的子文件,然后逐个处理。处理完毕之后再对这些单词的及其出现频率进行一个归并。实际上就可以利用一个外排序的归并过程。

另外还可以考虑近似计算,也就是我们可以通过结合自然语言属性,只将那些真正实际中出现最多的那些词作为一个字典,使得这个规模可以放入内存。

Blog V2.0.0发布

[| 2011/02/27 14:41]
查看了下之前的升级编号,发现之前版本号升级过快,所以改动一下,之前的1.0,2.0分别对应1.1和1.2,依次类推,本次更新博客升级为2.0.0版。
最近一段时间博客版本升级不多,一方面是在做别的东西,另一方面是刚开始自己搞的框架实在是扩展性很弱,于是决定将博客在Codeigniter框架下重写。本次更新内容如下:

1,博客主程序重写,采用Codeigniter2.0作为框架。
2,写了一个php扩展:botfilter,增加函数sn_check_bot(),用来检查来访者是否为蜘蛛,对于蜘蛛的抓取不再计入访问量。
3,页面左栏访问量处增加“今日访问量”栏。
4,重写博客日志记录模块,之前blog日志与webserver日志重复,现改为只记录博客运行过程中信息。
5,优化数据库操作。
6,SEO优化,减少页面不相关重复文字。
7,其他bug修正和优化。

本次调整博客外观变化不大,主要是整体重写和一些优化以及修正。
昨天在从nginx1.7.2升级2.0的过程中发生了一个问题,不管url是什么,都会直接调用default_controller。经排查,问题发生在system/core/URI.php里面,在65行开始的一段代码里,是为CLI方式运行CI写的一段代码,在这里,程序被判断成CLI模式运行,然后试图获取_parse_cli_args,为空,于是调用default_controller。

我使用的webserver是nginx,在配置文件里用urlrewrite去掉了index.php,CI配置文件中的uri_protocol使用的AUTO。

CI2.0中判断是否为CLI方式运行的方法是判断$_SERVER['argv']是否为空,不为空就是CLI,为空就不是。我查php手册,上面是这样说的:When the script is run on the command line, this gives C-style access to the command line parameters. When called via the GET method, this will contain the query string. 也就是说$_SERVER['argv']不为空的时候还有一种可能,就是GET方式访问网页,那么该元素中的数据就是query string。也就是说CI2.0默认认为不能使用传统的query string方式,否则会导致误判为CLI。

然后继续分析,在nginx中rewrite的规则是********/index.php?$1,注意,用的是问号而不是斜杠,这是nginx的问题,假如用斜杠的话nginx会试图寻找index.php文件夹下的目标文件,会导致404。也就是说比我我请求的是http:/*****/clock,在ci那变成了http:/*****/index.php?clock,所以在判断时$_SERVER['argv']为clock,于是被判断成CLI,而在_parse_cli_args中,又是从$_SERVER['argv']数组的第二个元素开始取,clock作为第一个元素没有被取到,自然_parse_cli_args取到的是空,导致调用了默认控制器。

综上,有两种修正方法,方法1是暂时注释掉URI.php中判断CLI的那一段,方法2是更改config.php中的uri_protocol为QUERY_STRING。当然还有一种方法是修改nginx的rewrite规则,不使用问号,不过这个我不知道怎么改。
资料网址:http://blog.csdn.net/mwq1984/archive/2010/03/20/5399539.aspx

解决方法:删除/etc/udev/rules.d/70-persistent-net.rules,重启机器即可。原因是mac地址冲突。
分页: 6/23 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]