公司的统计系统经历了两次比较大的架构变动:
1.数据直接入库的实时分析->
2.数据写入日志文件再归并入库的非实时分析（及时性：天）->
3.数据写入日志文件归并入库，建立不同维度的缓存表, 结合数据仓库（及时性：小时）
当前的系统状况：
数据源：Goolge Analytics / WebServer Log
数据库记录:5亿+
单表最大记录：1.2亿+
服务器数量：三台
1.日志存储服务器
2.日志分析服务器
3.数据库存储服务器
Continued…
BBupload: 高效、简单的上传服务 (fastcgi)
BBupload是一款高效的文件上传服务。
特点：
遵循FastCGI规范进行开发，优点在于能够自由选择Web Server作为上层服务，无论是偏爱Nginx、Lighttpd还是Apache，只要WebServer支持FastCGI就能与BBupload完美的进行结合, 仅仅需要对Web Server进行简单配置，不会影响到原本提供的服务。
客户端支持：
IE / Flash
使用平台：
Linux
编译安装：
Debian系统APT方式安装依赖包： apt-get install libfcgi-dev libconfuse-dev spawn-fcgi #进入程序目录 cd uploadserver-xx #初始化上传目录 python script/initpath.py #编译源码 make #修改配置文件 vi conf/uploadserver.conf #启动守护进程 ./run
Categories: C.
httpwatch 7.0.23 license
Categories: Others.
Bob Jenkins hash的PHP扩展
lookup3 hash是Bob Jenkins发明的一个非常优秀的hash算法。
Bob Jenkins’s Web Site:
http://www.burtleburtle.net/bob/
性能测试：
From: http://www.azillionmonkeys.com/qed/hash.html
AMD Athlon XP 1.620Ghz
Power4 1Ghz
UltraSparc
III 1.2Ghz
Intel C/C++
CRC32 6.42 5.66 5.66 5.67 14.06 8.75
One at a Time 5.76 5.66 5.66 5.69 12.79 5.57
Alpha Numeric 3.29 4.06 4.06 5.67 10.26 5.52
FNV Hash 4.88 4.84 4.83 4.87 8.92 11.98
Bob Jenkins 2.08 2.36 2.03 2.07 6.16 3.08
SuperFastHash 1.54 1.92 1.59 1.34 3.71 2.15
Data is time in seconds taken to hash a random buffer of 256 bytes 5 million times.
实际应用中lookup3执行效率也相当高，至少是crc32两倍以上的速度，散列效果也很好，现已封装入PHP Extension，方便广大PHPer使用。
项目首页：
http://code.google.com/p/phpfasthash/
下载地址：
http://phpfasthash.googlecode.com/files/lookup3.tar.gz
Categories: C.
xxtea算法的PHP扩展
xxtea属于对称加密算法使用较为广泛的算法，我们同样也在使用。
之前的版本是纯PHP的，后来经过测试发现执行效率比较低，在一台破服务器上测试循环加密解密1000次需要1秒多的时间，对于高并发的互联网应用来讲，这种效率确实惨不忍睹，现在有点量的应用每秒钟也要响应上千次请求，总不能让这么一个简单的功能成为瓶颈吧。
于是参考wiki用C编写了一个PHP扩展：
http://code.google.com/p/xxtea/
经测试，效率成数量级的提高，同样执行上述操作只需要0.05秒
关于xxtea算法的详细介绍也请参考wiki
Categories: C.
mysql的merge引擎引发的性能问题
MERGE引擎类型可以把许多结构相同的表合并为一个表。通过对merge表的简单查询，可以轻松实现对多个子表进行查询的目的。
我们的日志系统按照月为单位进行分表，由merge联合所有月份子表，实现跨月（跨表）的日志查询。这样的做法是程序端的逻辑比较简单，无需关注多表的数据整合和处理。
随着子表越来越多、数据越来越大，查询的速度越来越慢。子表的数据量增长并非数量级的，那么从理论上讲通过merge进行查询，速度受到影响的浮动应该是很小的，但现实却非如此。
刚开始并不知道原因，通过profiling检查详细的耗时情况，发现Sending data占用了99%的时间，从官方解释来看，Sending data貌似是发送数据到client端的耗时，检查了一下，仅仅只有几K的数据发送，明显不是此原因。SQL挺简单的，基本的优化也都做了，那么是什么原因？
之后调试代码时无意中针对一个子表进行了一次查询，发现速度几十倍的提高，之前对merge的查询需要20多秒，现在仅仅不到1秒就执行完了，这个感觉是很明显的，于是进一步进行了测试，发现问题的确如此。
所以，建议还是在代码逻辑中对多表数据进行处理，避免使用Merge引擎。
有时间看一下源码中Sending data是如何计算的以及Merge是如何进行多表数据集合的。 希望Mysql能把Merge引擎做的更加稳定、高效，真正发挥Merge引擎的优势。
Categories: Database.
Discuz 7.2 集成 Sphinx
Google Project：
http://code.google.com/p/dzwithsphinx/
中文社区的全文搜索功能一直是个让人头疼的问题，其实追根究底是由MySQL自身的问题造成的。当数据量大的时候，任何的RDBMS的查询都无法满足现今互联网的要求。
搜索引擎技术一直都作为”非大陆货”的角色存在，Sphinx的出现降低了搜索引擎的门槛、Coreseek的出现则降低了中文搜索引擎的门槛, 许多公司已经纷纷投入他们的怀抱。虽然Sphinx的功能及扩展性对于专业做搜索引擎的公司而言仍显简陋，但对于普通的全文搜索而言是太够了。
近期朋友的论坛刚刚转为Discuz!，就结合Discuz! 7.2版本标准帮朋友将这个毛病给治了。经常看到有站长被搜索功能搞的苦不堪言，不限制搜索就容易造成MySQL锁表等等，容易搞的站点很慢，限制搜索的话就放弃了一个如此便利的功能，Discuz!的使用者通常为中小站长，如果能配合Sphinx即可对搜索效率进行优化。
Categories: Search.
Debian安装 Sphinx 支持中文检索
一、编译先前条件
确认是否已经安装以下软件, 有些也许不是必须的, 但建议还是都装上。
apt-get install autoconf automake autotools-dev cpp curl gawk gcc lftp libc6-dev linux-libc-dev make libpcre3-dev libpcrecpp0 g++ libtool libncurses5-dev
aptitude install libmysql++-dev libmysqlclient15-dev checkinstall
apt-get install python python-dev
CSFT介绍
CSFT，全称为CoreSeek Fulltext Search Server，也就是CoreSeek 全文检索服务器。Sphinx默认不支持中文索引及检索，CSFT是在Sphinx基础上开发的全文检索软件，按照GPLv2协议发行。Coreseek (http://www.coreseek.com) 为sphinx在中国地区的用户提供支持服务。
http://www.coreseek.cn/products/ft_down/
CSFT下载
Coreseek Fulltext Server(源代码) : = Sphinx打过中文分词补丁的版本
http://www.coreseek.cn/uploads/csft/3.1/Source/csft-3.1.tar.gz
Coreseek Mmseg(源代码)
http://www.coreseek.cn/uploads/csft/3.1/Source/mmseg-3.1.tar.gz
安装配置CSFT
Categories: Search.
inotify事件的应用
inotify是 linux 2.6内核的一个新特性, 用来实时监控文件系统，对文件进行的操作都能够及时做出响应。
根据此事件的特性，比较适合应用于文件数量非常大的同步操作。
众所周知，最简单的同步方式为rsync，但rsync的弊端就是同步文件之前会遍历所有的文件，此时当文件数量非常大的时候，这个时间消耗是很长的，更不要说实时。inotify的出现完美的解决了这样的问题，当任何一个被监控的文件发生了变化我们都能够及时得知并针对此文件进行同步操作。
有人已经基于 inotify + rsync 做了贡献：
lsyncd： C 的开源程序
pylsyncd： Python 的开源程序
Categories: Linux.
Mysql 数据库编码转换程序
http://code.google.com/p/mysqlencodingconvertor/
帮助你转换mysql数据库的数据编码
修改convert.php中以下内容：
// variables $user = 'user'; //连接数据库的用户名 $password = 'password'; //连接数据库的密码 $ip = 'dbserver'; //连接数据库的IP // source server $src_db = 'dbname1'; //需要转换的库名 $src_table_encoding = 'latin1'; //需要转换的数据表编码 $src_data_encoding = 'gbk'; //数据本身编码 // target server $dst_db = 'dbname2'; //转换后的库名 $dst_table_encoding = 'utf8'; //转换后的数据表的编码 $dst_data_encoding = 'utf8'; //转换后的数据的编码 // select number per process $per_num = 200000; //每次处理的数据条数，根据硬件情况以及资源分配情况酌情修改
需要执行的操作：
1、将老的数据库的表结构导出
2、修改建表SQL语句的编码为你想要的编码
3、导入数据结构到新的库中
4、执行转换程序
Categories: Php.