Chancey's Handbook

亿级数据的统计系统架构

Chancey — Thu, 22 Jul 2010 16:38:39 +0800

公司的统计系统经历了两次比较大的架构变动:

1.数据直接入库的实时分析->

2.数据写入日志文件再归并入库的非实时分析（及时性：天）->

3.数据写入日志文件归并入库，建立不同维度的缓存表, 结合数据仓库（及时性：小时）

当前的系统状况：

数据源：Goolge Analytics / WebServer Log

数据库记录:5亿+

单表最大记录：1.2亿+

服务器数量：三台

1.日志存储服务器

2.日志分析服务器

3.数据库存储服务器

架构示意图：

日志存储服务器：普通时段每秒钟记录2000+条访问

1.从CDN下载Web server日志

2.对点出的日志进行直接存储

日志分析服务器：

从GA/WebServer得到数据后，使用Python多进程并行分析，分析后的数据直接写入数据库中。

数据库存储服务器：

存储引擎：MySQL Myisam、InfoBright(Community)

为了提高查询效率，建立有不同维度的数据表，InfoBright引擎存储相对稳定，不会进行变更的数据，因为Community版进行数据变更成本很高，你们懂得

关于日志分析：

Python的gzip模块能够直接读取压缩过的日志进行分析，相当节省磁盘空间。

由于分析过程使用大量的CPU资源，使用Python的多进程充分利用多核CPU。由于GIL的缘故，多线程不要考虑了。

另外用到了psyco，仅仅多了两行代码，分析效率成数十倍的提高。

关于查询性能：

当前最慢的查询时间应该是跨年度的分组查询，小于20秒。这里其实可以通过再次归并，增大记录粒度的方式优化到更快，只是有这种查询需求的并不多，这个时间也能接受。

另外值得一提的是InfiniDB，实测效果相当惊人，比InfoBright还要快好多倍，只是数据压缩比并不高，并且一些SQL并不支持，此引擎可以列入下次的架构调整中

BBupload: 高效、简单的上传服务 (fastcgi)

Chancey — Wed, 07 Jul 2010 22:37:04 +0800

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

开源项目：
http://code.google.com/p/bbupload/

作者：Chancey

httpwatch 7.0.23 license

Chancey — Thu, 01 Jul 2010 23:24:48 +0800

httpwatch 7.0.23 license, 一年使用期, 支持 IE8、FF3.6.6

download:

http://webarchs.net/soft/httpwatch.lic

Bob Jenkins hash的PHP扩展

Chancey — Fri, 02 Apr 2010 11:22:23 +0800

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

xxtea算法的PHP扩展

Chancey — Fri, 05 Feb 2010 22:47:54 +0800

xxtea属于对称加密算法使用较为广泛的算法，我们同样也在使用。

之前的版本是纯PHP的，后来经过测试发现执行效率比较低，在一台破服务器上测试循环加密解密1000次需要1秒多的时间，对于高并发的互联网应用来讲，这种效率确实惨不忍睹，现在有点量的应用每秒钟也要响应上千次请求，总不能让这么一个简单的功能成为瓶颈吧。

于是参考wiki用C编写了一个PHP扩展：

http://code.google.com/p/xxtea/

经测试，效率成数量级的提高，同样执行上述操作只需要0.05秒

关于xxtea算法的详细介绍也请参考wiki

mysql的merge引擎引发的性能问题

Chancey — Tue, 30 Nov 1999 08:00:00 +0800

MERGE引擎类型可以把许多结构相同的表合并为一个表。通过对merge表的简单查询，可以轻松实现对多个子表进行查询的目的。

我们的日志系统按照月为单位进行分表，由merge联合所有月份子表，实现跨月（跨表）的日志查询。这样的做法是程序端的逻辑比较简单，无需关注多表的数据整合和处理。

随着子表越来越多、数据越来越大，查询的速度越来越慢。子表的数据量增长并非数量级的，那么从理论上讲通过merge进行查询，速度受到影响的浮动应该是很小的，但现实却非如此。

刚开始并不知道原因，通过profiling检查详细的耗时情况，发现Sending data占用了99%的时间，从官方解释来看，Sending data貌似是发送数据到client端的耗时，检查了一下，仅仅只有几K的数据发送，明显不是此原因。SQL挺简单的，基本的优化也都做了，那么是什么原因？

之后调试代码时无意中针对一个子表进行了一次查询，发现速度几十倍的提高，之前对merge的查询需要20多秒，现在仅仅不到1秒就执行完了，这个感觉是很明显的，于是进一步进行了测试，发现问题的确如此。

所以，建议还是在代码逻辑中对多表数据进行处理，避免使用Merge引擎。

有时间看一下源码中Sending data是如何计算的以及Merge是如何进行多表数据集合的。希望Mysql能把Merge引擎做的更加稳定、高效，真正发挥Merge引擎的优势。

Discuz 7.2 集成 Sphinx

Chancey — Tue, 30 Nov 1999 08:00:00 +0800

Google Project：
http://code.google.com/p/dzwithsphinx/

中文社区的全文搜索功能一直是个让人头疼的问题，其实追根究底是由MySQL自身的问题造成的。当数据量大的时候，任何的RDBMS的查询都无法满足现今互联网的要求。

搜索引擎技术一直都作为”非大陆货”的角色存在，Sphinx的出现降低了搜索引擎的门槛、Coreseek的出现则降低了中文搜索引擎的门槛, 许多公司已经纷纷投入他们的怀抱。虽然Sphinx的功能及扩展性对于专业做搜索引擎的公司而言仍显简陋，但对于普通的全文搜索而言是太够了。

近期朋友的论坛刚刚转为Discuz!，就结合Discuz! 7.2版本标准帮朋友将这个毛病给治了。经常看到有站长被搜索功能搞的苦不堪言，不限制搜索就容易造成MySQL锁表等等，容易搞的站点很慢，限制搜索的话就放弃了一个如此便利的功能，Discuz!的使用者通常为中小站长，如果能配合Sphinx即可对搜索效率进行优化。

平台环境：

PHP+ Sphinx API
Sphinx (Coreseek Fulltext Server)
Discuz 7.2（UTF-8）

关于Sphinx支持中文的安装方法：
http://hi.baidu.com/chancey/blog/item/2184746432926dfbf6365436.html

Sphinx的配置文件以及Discuz的搜索部分代码修改：
http://dzwithsphinx.googlecode.com/files/DZwithSphinx.zip

初始化:

1、修改配置文件：
修改sphinx.conf 替换其中的sql连接信息及sphinx服务信息：
sql_host
sql_user
sql_pass
sql_db
sql_port
listen

修改search.php 替换sphinx连接信息以及查询结果数：
$spx_server
$spx_port
$spx_limit

2、导入SQL：
sph_counter.sql

3、执行：
./bin/indexer –config /data/opt/sphinx/etc/sphinx.conf dzbbs
./bin/indexer –config /data/opt/sphinx/etc/sphinx.conf threads
./bin/searchd –config etc/sphinx.conf

4、加入crontab计划任务：

# Incremental Index posts data
* 0-3 * * * /data/opt/sphinx/bin/indexer –config /data/opt/sphinx/etc/sphinx.conf dzbbs_delta –rotate
* 6-23 * * * /data/opt/sphinx/bin/indexer –config /data/opt/sphinx/etc/sphinx.conf dzbbs_delta –rotate
0 4 * * * /data/opt/sphinx/bin/indexer –config /data/opt/sphinx/etc/sphinx.conf dzbbs_merge –rotate && /data/opt/sphinx/bin/indexer –config /data/opt/sphi
nx/etc/sphinx.conf –merge dzbbs dzbbs_merge –rotate

# Incremental Index threads data
* 0-3 * * * /data/opt/sphinx/bin/indexer –config /data/opt/sphinx/etc/sphinx.conf threads_delta –rotate
* 6-23 * * * /data/opt/sphinx/bin/indexer –config /data/opt/sphinx/etc/sphinx.conf threads_delta –rotate
0 4 * * * /data/opt/sphinx/bin/indexer –config /data/opt/sphinx/etc/sphinx.conf threads_merge –rotate && /data/opt/sphinx/bin/indexer –config /data/opt/sp
hinx/etc/sphinx.conf –merge threads threads_merge –rotate

注：
1、xx_delta每分钟进行增量数据更新是为了能够及时查找到新的帖子和回复，但并不会更新sph_counter表的记录。此处不进行记录更新和merge是因为当数据量大以及论坛发帖频繁的时候一分钟之内有可能合并不完，间隔时间长的话又不能及时查找到。

2、dzbbs_merge、 threads_merge 是为了将第一次执行的主数据与之后的新的数据进行合并，如果长时间不合并，那么每次执行xx_delta的时间就会很长，一分钟之内执行不完。

以上说的比较绕，表达能力欠缺

经过上述操作后，此时论坛的查询将成为最大的亮点

Debian安装 Sphinx 支持中文检索

Chancey — Tue, 30 Nov 1999 08:00:00 +0800

一、编译先前条件
确认是否已经安装以下软件, 有些也许不是必须的, 但建议还是都装上。
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

1.安装mmseg
tar zxvf mmseg-3.1.tar.gz
cd mmseg-3.1
./configure –prefix=/data/opt/mmseg
make && make install

2.安装csft
tar zxvf csft-3.1.tar.gz
cd csft-3.1
./configure –prefix=/data/opt/sphinx/ –with-mysql=/data/opt/mysql/ –with-mysql-includes=/data/opt/mysql/include/ –with-mysql-libs=/data/opt/mysql/lib/ –with-mmseg=/data/opt/mmseg/ –with-mmseg-includes=/data/opt/mmseg/include/mmseg/ –with-mmseg-libs=/data/opt/mmseg/lib/
make && make install

3.生成词典

重回到mmseg的源代码目录
cd data
/data/opt/mmseg/bin/mmseg -u unigram.txt
mv unigram.txt.uni uni.lib
cp uni.lib /data/opt/sphinx/

4.配置

charset_type = zh_cn.utf-8
charset_dictpath = /data/opt/sphinx/

对应编码：

sql_query_pre = SET NAMES utf8 #指定编码

#vi /etc/my.cnf
在[client]跟[mysqld]下分别加上default-character-set=utf8

5.运行

建立索引：
./bin/indexer –config etc/sphinx.conf –all

增量索引：
./bin/indexer –rotate –config etc/sphinx.conf test1stemmed

启动进程：
./bin/searchd –config etc/sphinx.conf

查询：
./bin/search -c etc/sphinx.conf 测试

6.问题：

1)
启动索引服务时：
error while loading shared libraries: libmysqlclient.so.16: cannot open shared object file: No such file or directory

解决：
ln -s /data/opt/mysql/lib/libmysqlclient.so.16 /usr/lib/libmysqlclient.so.16

2)
启动查询服务时：
cannot open /data/coreseek/dict/mmseg.ini

解决：
vi /data/coreseek/dict/mmseg.ini，输入下面内容
[mmseg]
merge_number_and_ascii=1;
number_and_ascii_joint=-;
compress_space=0;
seperate_number_ascii=1;

以上解释如下
/*
merge_number_and_ascii: 字母和数字连续出现是非切分
number_and_ascii_joint:连接数字和字母可用的符号，如’-’ ‘.’ 等
compress_space：暂时无效
seperate_number_ascii：是否拆分数字，如 1988 -> 1/x 9/x 8/x 8/x
*/

inotify事件的应用

Chancey — Tue, 30 Nov 1999 08:00:00 +0800

inotify是 linux 2.6内核的一个新特性, 用来实时监控文件系统，对文件进行的操作都能够及时做出响应。

根据此事件的特性，比较适合应用于文件数量非常大的同步操作。

众所周知，最简单的同步方式为rsync，但rsync的弊端就是同步文件之前会遍历所有的文件，此时当文件数量非常大的时候，这个时间消耗是很长的，更不要说实时。inotify的出现完美的解决了这样的问题，当任何一个被监控的文件发生了变化我们都能够及时得知并针对此文件进行同步操作。

有人已经基于 inotify + rsync 做了贡献：

lsyncd： C 的开源程序

pylsyncd： Python 的开源程序

我对这两个程序进行了测试，本来比较倾向pylsyncd的，因为 Python 代码改起来比较简单 : )

但测试后发现pylsyncd效率不是一般的低下，总是会延迟一段时间才同步完成，相反，lsyncd非常高效，为我所选用。

使用此同步机制需要注意的是，将要被监控同步的目录必须是一个HASH树，保证文件尽量分散的存放在不同的子目录中，叶子目录中的文件数或目录数不要太多，尽量不要超过1000，如果文件足够多，那就多分几级目录，具体分多少级合适也可以很简单的算出来。

例如：总共100万个文件，要求每个子目录中的文件数不超过100，那么1000000/100=10000，子目录总数为10000 ，那么一级目录肯定是不够的，分两级的话根目录下100个目录，每个子目录下100个二级子目录，那正好是10000个目录。

对于lsyncd及pylsyncd而言，以上的目录结构效率是非常高的，因为当一个事件被触发时，lsyncd的进程会调用rsync对变动的文件的所属目录进行同步操作，而这个目录下的文件数才100，遍历一次的时间基本可以忽略了。

至于目录结构的创建可以根据以下方式进行：

1、对文件内容或文件名进行crc32取绝对值再取模的算法得出。

2、md5后取前两位作为一级目录，三四位作为二级目录，依此类推

注：如果是文件名的话尽量不要有重复

以及其他的一些算法，如果有更好的方法，欢迎告诉我。

其实，可以完全抛弃rsync，自己写server和client程序来只对触发事件的单一对象进行处理，这样肯定更加高效，有时间的时候一定要写一个出来，受益终身的东西。

在应用中遇到了一个问题，从日志中发现 error: Cannot add watch xxx (28:No space left on device) 这样的提示，检查了一下磁盘空间还很充足，文件系统使用的reiserfs，inode就不考虑了，查了一下inotify手册发现在内核参数中是有设置最大监控对象数量的 cat /proc/sys/fs/inotify/max_user_watches 只有很小的一个默认数。修改/etc/sysctl.conf 加入 fs.inotify.max_user_watches = 262144 具体数根据子目录的大小来决定，如果此值小于需要被监控的子目录数，那么某些子目录会没有被监控，同步自然会出问题。加入后sysctl -p并重新启动lsyncd进程监控初始化。

Mysql 数据库编码转换程序

Chancey — Tue, 30 Nov 1999 08:00:00 +0800

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、执行转换程序