Archive for the ‘默认分类’ Category

我为什么选择MongoDB

Monday, May 30th, 2011

大概在08年,那时候nosql的概念特别热,最早的那批开源项目好多参考google bigtable来设计,我也关注过其中的几个,比如hypertable,couchdb之类,阅读了一些相关的文档和博文,没有太跟进,那些开源项目的设计scope太大,想解决google都不一定很好解决的问题,事实上国内能真正碰到那种数据规模的人少,很少,极少;迁移的成本也很高,我们的项目大多构建在mysql+memcached上,关系型的操作很多,这种key-value或者类key-value的数据库不是特别合用;也觉得很难从那些产品中获得什么可预知的好处,不管是性能上的还是开发上的,所以也在那些项目上浅尝辄止。 mongodb是从09年开始关注,从最初的一些文档可以看出这家伙是来解决实际问题的,mongodb的作者们对mysql+memcached这套东西的优势和弊端看的非常清楚,项目的设计对我们这些lamp程序员来说,也有天然的亲和力,你可以很容易把mysql的那套东西照搬到mongodb,比如collection对于mysql里面的table,没有言必谈分布式,可以很容易在单机上开发测试,可以相信在mongodb早期的auto-sharding只是个噱头,事实上在早期的很多版本官方也不太推荐大家用。 我在选用一些技术的时候大多考虑这些方面: 1. 新的方案能不能解决目前项目中难以忍受的问题? 2. 新的方案是不是足够简单?见过很多的项目为了解决一个稍显复杂的问题引入一个更加复杂的方案,着实累人 3. 新的方案能不能很平滑的应用到项目中去? 4. 新的方案能不能被替换?不能被替换的方案都是烂方案 在mongodb之前,我碰到的问题是: 1. 项目的需求不断变化,数据库表结构需要不断调整来满足新的需求,FriendFeed用的是schema-less方法来解决这种问题,但是schema-less也有一些问题,在设计时候需要考虑动静分离,要不然为了更新某个小数据需要频繁的更新整个大数据块会比较烦躁,数据的一致性和有效性需要在代码中特别注意。 2. 多对多关系的处理,典型的例子是文章tag,一篇文章有多个tag,每个tag对应多篇文章,传统的做法是维护2张表,一张是tag表,里面是tag_id对应的tag_name,另外一张是文章对应tag表,里面维护3个字段,tag_id、文章id、tag被打的次数,然后当有用户新打tag的时候,你需要把新的tag和已有的tag比较,相同的+1,不存在的需要新建,然后置为1,删除什么的也是各种烦躁 mongodb文档型数据库设计可以很好的解决这些问题,schema less的设计可以把整片数据塞进去,可以很方便的对数据key建立索引,提高访问速度,tag处理也非常方便,直接把{tag_name:tag_times}数据丢进去就可以,非常方便。 mongodb支持大多数的mysql操作,原有代码稍作修改即可,可以很平滑的应用,对于一个MVC的应用来说,基本上小修改model层就可以,非常轻松,当然,如果一天mongodb不行了,再切换回去也不是什么困难的事情。 作为一个前中期的开源项目,mongodb也有一些问题需要注意: 1. 运维和监控工具不如mysql那么丰富 2. mongodb采用的mmap机制,在断电和某些异常情况下有可能丢失数据或者crash,好消息是1.8以后可以打开journal日志来避免此类问题 3. schema less是一把双刃剑,因为什么数据都可以往里面存,不像mysql那样会有字段的概念可以对数据有效性把最后一道关,需要在编写程序的时候特别注意一下数据有效性,当然用mysql也要注意 4. 没有auto increment id,这个很不爽,不过可以通过findandmodify来模拟出来 function autoIncrementId($domain, $collection = 'autoIncrementIds', $db = null) { $result = $mongo->command(array( 'findAndModify' => $collection, 'query' => array('_id' => ...

我的SEO搜索引擎优化经验

Wednesday, April 20th, 2011

注意:我不是SEO从业者亦不是搜索引擎排名工程师,我尽量保证提到策略有效且合乎规则的,如有谬误,请略过或指正,我本人不推荐一些所谓的“黑帽”策略,因为能欺骗搜索引擎一时却不能长久,所以做垃圾站的或者想赚快钱的也可以忽略本文,本文的目标是希望和大家一起探讨如何创建一个既对用户又对搜索引擎友好的网站。 搜索引擎优化最值得参考的两篇文档:Google Search Engine Optimization Starter Guide 和 百度搜索引擎优化指南,这是两份官方文档,非常值得仔细研读,网上其他文档充斥太多讹传和猜想(包括本文,虽然我极力想避免)。 一直觉得搜索引擎优化是一个符合马太效应的过程,需要慢慢的积累,表现好的网站越来越好,所以如果已经有一个好的网站尽量持久的运营,如果要换域名的话,原有的链接最好做301跳转到新域名的对应链接,这是搜索引擎推荐的做法,大家可以看看最近javaeye切换域名到iteye,基本的链接都做了301跳转,对用户来说也非常友好,robbin同学是个SEO高手,后面还会再提到他的另一个高明之处。 一、链接篇 传闻hao123站长李兴平曾说过“SEO没有什么技术,就是靠外链”,可见外链对SEO来说有多么重要的,我们把被链接的页面叫做子页面,链接到子页面的页面叫父页面,按照Google Pagerank的算法,子页面的父页面越多,子页面的权威性越高;子页面的父页面权威性越高,子页面的权威性也越高,有个域名是“www.miibeian.gov.cn”的网站,由于基本上全中国网站都链接到他了,不管网站做的怎么样,Google PR稳稳的为10。(不要试图访问这个网站,已废弃了,暴殄天物啊) 除了外链,站内链接也是一个非常重要的部分,作用虽没有外链那么作用大,胜在可以自己控制,添加一些相关链接,除了能够给其他页面提升权威性外,也能很好的提高用户粘性,降低跳出率。 链接里面有一个很重要的部分就是“锚文本”,什么是锚文本呢,比如这个链接 当知网 ,当知网三个字就是锚文本,锚文本对搜索引擎来说非常有用,因为搜索引擎很难获得某个页面的关键字,标题获取是最主要的来源,锚文本也是一个非常重要的因素,可以很简要的描述页面内容。 这里有个小故事,很多美国人对小布什不满意,于是有人发起了个倡议,在自己的博客上建立一个链接,链接的锚文本是"Loser",链接的地址是小布什在白宫的页面,于是很多人用google搜索"Loser",小布什的白宫页面稳稳的排在第一位,虽然小布什的白宫页面上没有"Loser"这个关键字,架不住从"Loser"跳过来的链接太多,也就壮烈了。(Google现在已经改进了算法,避免锚文本被人滥用) 网站添加链接时,尽量避免链接到作弊网站,因为"蛇鼠一窝",搜索引擎很容易把链接到作弊网站的网站也当作作弊网站;需要特别注意的是开放了博客空间、留言板、BBS之类网站,很多spammer用灌水机贴了很多垃圾网址,要注意即时清除,否则容易被误伤,如果业务需求不能随便删除的话,可以参考现在微博的做法,提供一个短地址或者地址跳转服务,最不济的话,加上nofollow标记。 "链接堆砌"也不是一种好的做法,一段文字里面密集的链接到目标网站,现在的搜索引擎已经很容易识别了。 虽然之前百度的“左螺旋哥”风光无限,但"linkfarm"也不是一种好的做法,搜索引擎已经能够识别,作弊的方法虽然能短时间获得排名,一旦被K,基本万劫不复。 对于链接这种事情,建议还是一五一十的慢慢做,当然,有资源的写一些软文投递到一些优质的网站发表也大有裨益。 二、标题篇 页面标题是我认为SEO所有因素中的最重要的那个,一个好的标题应该应该包含关键字,比如本文的标题包含"搜索引擎优化"、"SEO"这两个关键字,标题不宜过长,忌关键词堆砌,标题太长的话,对于每个关键字的权重就降低了,另外,对于搜索引擎来说,页面标题的长度也是有限制的,太长的标题直接容易被切掉,大家可以看一下这个例子,这不是一个好的标题,重要的关键字放最后还被截掉了。 个人觉得一个好的标题设计可以参考这种格式:标题_频道名称_网站名称,好的标题"短小精悍",切实把握用户心理需求,很久以来,我的一篇关于MySQL 分页的文章一直排在Google的第一位 页面的meta信息,包括description和keywords,对排序作用不大,对生成内容摘要有用,所以如果可以的话还是添加上去,免得搜索引擎把不重要的文字当作摘要,影响用户点击。 三、URL篇 url目录不要太深,/a/b/c/d/e/f.html这样的链接权重会有一些影响,另外迷宫型的url有可能会被认为是作弊/a/b/c/d/a/b/c/d/e.html url设计尽可能精简,尽量不包含一些不能被系统自动识别为url的字符,方便用户转帖 尽可能的使用静态URL,虽然说搜索引擎已经能索引动态url,不管对用户还是搜索引擎来说,静态的url更好一点 同一篇内容,只有一个url,尽量避免无效的参数,有些网站为了统计的需要添加类似foobar.html?ref=xxx这样的参数着实不好,流传出去,一个页面多个地址 不同类型的内容url应该有区别,比如列表页/list/9527,内容页/view/3306 关于目录和子域名的选择,子域名的权重会比目录高一些,注意平衡,一般内容较少时用目录,忌滥用子域名,子域名越多,不太容易积累每个域名的权重,还不如重点维护好几个关键子域名 好的内容和差的内容一定要从子域名或子目录区分开,百度百科和百度贴吧两者的权重差别就很大,好的内容和差的内容(比如UGC的内容)混在一起,容易被误伤 url中包含英文关键字,对google来说甚佳,baidu来说不太清楚,url中多个关键字建议以"-"隔开,没有太多的证据证明中文关键字做urlencode对seo有效,不过中文拼音缩写对用户来说可能会更友好一点 对于时效性比较强的内容,可以用日期作为目录,现在的搜索引擎已经可以获取页面内容的时间 好的url设计应该能够会意,这篇URL设计准则值得读一下 四、内容篇 原创的内容更受搜索引擎青睐,搜索引擎对采集的内容也有一定的容忍度,一个好的网站最好不要大量采集,免得自己的优质内容被误伤,搜索引擎判断是否原创内容的方法有很多,比如页面生成时间、来源链接等等,不过很悲剧的是国内很多网站转帖不带来源地址,如果转帖网站的权重比原网站高的话,首先被搜索引擎索引到,很容易排在前面,所以我们经常会看到一些聚合类的网站搜索结果靠前 内容的阅读体验也非常重要,包括网站的打开速度、页面停留时间、跳出率等等,这些指标有的是从各个搜索引擎提供的统计系统中获得,有的是通过用户行为获取,比如页面停留时间,在搜索结果页中点第一个链接和第二个链接之间间隔,很有可能就被当作是第一页面停留的时间,当然这个有些不准,因为很多人喜欢打开多个,不过搜索引擎应该有办法来区分 页面的内容应该要和标题呼应,应用好<h1>……<h6>之类的标签突出你的标题和核心内容,html标签很多是有语义的,如果可以的话,建议按照规范使用 专题性的内容是搜索引擎的最爱,在搜索一些技术关键字的时候,很容跳到javaeye的关键字内容聚合页,这也是robbin高明之处 内容页面设计尽可能的清晰,方便搜索引擎索引需要的内容,如果搜索引擎给页面生成段落或者目录信息,恭喜你,说明你的网站权重已经不错了。 内容结构尽量扁平,可以按照这种结构规划:首页、列表页、内容页 尽量避免用JS/Flash/iframe之类的来展示主体内容,目前只有google宣称能够解析js内容,baidu明确表示不会解析js内容,iframe是被所有搜索引擎抛弃的 五、工具篇 Google网站管理员工具是我认为最好的SEO工具,方便查看网站的搜索引擎表现状况 站长之家的站长工具也是一个非常不错的辅助工具,方便查看pr、外链之类的属性 百度指数、百度火爆地带、Google Adwords关键字工具对于优化关键字来说很有参考意义 善用robots.txt和sitemap对于优化网站搜索引擎表现也大有裨益 后记: 搜索引擎优化是一个漫长的过程,涉及的因素很多,同样的木桶原理在这里也适合,本文的内容大多来自google和百度那两篇官方指导文档,大多经过实践验证,欢迎交流fuchaoqun#gmail.com (#换成什么,你懂的),可以交换一些网站推广方面的资源。

ColaPHP 1.1GA发布

Saturday, March 19th, 2011

距离1.0GA发布有近3个月的时候了,ColaPHP现在来说已经比较稳定了,版本的发布周期会控制在3个月左右,1.1GA主要的变化有: 引入Widget机制,方便页面片管理 全局配置管理优化,配置调用Api微调,更好、更方便的满足大量配置信息管理 其他优化和bugfix 下载ColaPHP 1.1GA,也可以访问ColaPHP项目主页:http://code.google.com/p/colaphp/

基于MongoDb的S3实现

Friday, May 7th, 2010

原理是利用MongoDb的GridFS,伸展性方面交由MongoDb的auto sharding去实现,这里用PHP给MongoDb绑了个S3出来,支持选择文件存储节点,支持文件分目录存储,这样的好处是对于一些受时间影响比较明显的文件,可以按照年月的形式存储,减轻历史包袱。 首先,配置MongoDb GridFS节点信息:

ColaPHP 0.5beta发布

Sunday, January 24th, 2010

ColaPHP的第一个beta版本,代号:Practice,已经实践的优化,可以适量应用在实际项目中,相比较0.4alpha,比较大的修改如下: 增加字符串加密助手,支持XOR、mcrypt加密,支持混淆 增加分页类 重构了HTTP请求类,可定制性更强 重构了Validate类,增加批量校验 其他代码重构以及bug fix 下载ColaPHP 0.5beta,阅读ColaPHP文档,访问ColaPHP项目。 下一个版本0.6beta开发代号:Easy,将在易用性方面进一步优化。

MongoDb In Action

Saturday, January 23rd, 2010

This slide will tell you how to use MongoDb as MySQL in your application.

Python处理MP3的歌词和图片

Thursday, January 21st, 2010

一些MP3播放器(包括iphone、ipod、itouch、blackberry等)可以在播放mp3的时候显示专辑图片、歌词等信息而不需要额外的图片文件和歌词文件,仅仅一个mp3文件就搞定,比较有意思。除了用专门的软件(比如itunes)来制作这样的mp3,我们还可以用程序来批量生成。 查阅mp3头信息ID3V2的技术文档,发现可以往ID3信息里面加入歌词和图片信息(可以在页面上查找Lyrics、Attached picture就能发现相应的内容)。有了官方格式上的支持,我们要做的就是把歌词和图片加入到MP3文件中去。 测试一些开源的软件包,发现一个比较可靠的:eyeD3,由python语言编写,直接上代码: #coding=utf-8 import eyeD3 import re # mp3文件 mp3_file = '/path/to/foobar.mp3' # lrc歌词文件 lrc_file = '/path/to/foobar.lrc' # 专辑图片 pic_file = '/path/to/foobar.jpg' # 实例化eyeD3 tag = eyeD3.Tag() # 绑定到mp3文件 tag.link(mp3_file) # 去掉原文件中可能存在的图片 tag.removeImage() # 去掉原文件中可能存在的歌词 tag.removeLyrics() # 设定编码,非常重要,否则不支持中文 tag.encoding = '\x01' # 添加图片 tag.addImage(3, pic_file, u'') # 添加歌词,注意要utf-8编码,去掉lrc中时间信息 tag.addLyrics(re.sub('(\[.*?\][\n]*)+', '', unicode(open(lrc_file, 'r')).read(), 'utf8'))) # 更新到文件 tag.update() 代码非常简单,需要注意的是设定编码,不然歌词就乱码了。有了eyeD3之后,可以写个爬虫,从网上抓下歌词和图片直接灌进MP3文件里面,剩下的就是享受了。

还在路上

Thursday, December 31st, 2009

又是一年算账的时候,去年的今天写了2009年的一些计划:网络(socket)/桌面(gui)编程;一个精巧的PHP框架;数据挖掘;多一些好朋友。socket/gui编程算是稍稍入门吧;PHP框架(ColaPHP)已经发了4个alpha版本,目前从实际项目中看表现还可以,可能下一个版本就进入beta阶段,beta意味着ColaPHP逐步趋于稳定;数据挖掘前半年做的比较多,进展不算太大;好朋友多了一些,此事甚为欣慰。 2009年技术上主要是代码方面的成长,重构的事情做的比较多,已不太相信过于花哨的玩意。脾气方面,"骄躁"二字少了些。回过头来看2009,不觉太多收获,亦不觉浮度。 2010年想要做的一些事情:学一门新语言;ColaPHP发一个GA版本;数据挖掘,做一个开源的推荐系统;更多的好朋友。 希望春天能在2010年到来。

ColaPHP-0.2-alpha发布

Tuesday, July 28th, 2009

相比较0.1alpha,比较大的修改如下: 增加了Cache处理模块,支持APC、eAccelerator、Memeched、File、Xcache、Dba缓存 增加日志处理模块,支持Echo、File、Null三种类型 去掉了Cola.php中404处理,建议用户在url规则最后的位置加上'/.*/'来处理其他任何没有匹配的请求 demo做了一点小的修改,有一个演示不需要定义url规则、跳过Router.php的方法(参见demo/norouter.php) 一些bug的修订 同时欢迎Python.Han, darkredz加入到项目中来,有你们ColaPHP会更精彩。 下载0.2alpha,不过建议随时跟进我们的SVN://colaphp.googlecode.com/svn/trunk/,ColaPHP一直在活跃开发。 继续招募PHP极客加入Cola,联系fuchaoqun#gmail.com。

解决Pidgin掉线、自动退出、假死、无响应

Tuesday, April 14th, 2009

最近几天,被pidgin折腾疯了,一会上线,一会自动退出,一会假死,看到好友发过来消息,可阅读不了具体内容,折腾的身心疲惫,升级到最新版本也无济于事。 由于在pidgin上登录了msn和gtalk帐号,初步怀疑是MSN插件的问题,貌似MSN之前升级了版本。禁用MSN帐号后,pidgin恢复稳定。 郁闷的不行了,找到一个第三方的MSN插件:http://code.google.com/p/msn-pecan/ wget http://msn-pecan.googlecode.com/files/msn-pecan-0.0.18.tar.bz2 tar xjf msn-pecan-0.0.18.tar.bz2 -C /usr/local/src cd /usr/local/src/msn-pecan-0.0.18/ make make install 安装之前记得安装libpurple-devel yum install libpurple-devel 安装好了之后,pidgin中会出现WLM协议,用这个做MSN登录,世界总算清静下来了。 我这边是CentOS 5.3,Pidgin 2.5.5-1.el5,其他版本安装说明,阅读http://code.google.com/p/msn-pecan/wiki/HowToInstall