根据status信息对MySQL服务器进行优化(一)

March 24th, 2009

网上有很多的文章教怎么配置MySQL服务器,但考虑到服务器硬件配置的不同,具体应用的差别,那些文章的做法只能作为初步设置参考,我们需要根据自己的情况进行配置优化,好的做法是MySQL服务器稳定运行了一段时间后运行,根据服务器的”状态”进行优化。

mysql> show global status;

可以列出MySQL服务器运行各种状态值,另外,查询MySQL服务器配置信息语句:

mysql> show variables;

一、慢查询

mysql> show variables like '%slow%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| log_slow_queries | ON    |
| slow_launch_time | 2     |
+------------------+-------+

mysql> show global status like '%slow%';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| Slow_launch_threads | 0     |
| Slow_queries        | 4148 |
+---------------------+-------+

配置中打开了记录慢查询,执行时间超过2秒的即为慢查询,系统显示有4148个慢查询,你可以分析慢查询日志,找出有问题的SQL语句,慢查询时间不宜设置过长,否则意义不大,最好在5秒以内,如果你需要微秒级别的慢查询,可以考虑给MySQL打补丁:http://www.percona.com/docs/wiki/release:start,记得找对应的版本。

打开慢查询日志可能会对系统性能有一点点影响,如果你的MySQL是主-从结构,可以考虑打开其中一台从服务器的慢查询日志,这样既可以监控慢查询,对系统性能影响又小。

二、连接数

经常会遇见”MySQL: ERROR 1040: Too many connections”的情况,一种是访问量确实很高,MySQL服务器抗不住,这个时候就要考虑增加从服务器分散读压力,另外一种情况是MySQL配置文件中max_connections值过小:

mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 256   |
+-----------------+-------+

这台MySQL服务器最大连接数是256,然后查询一下服务器响应的最大连接数:

mysql> show global status like 'Max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 245   |
+----------------------+-------+

MySQL服务器过去的最大连接数是245,没有达到服务器连接数上限256,应该没有出现1040错误,比较理想的设置是:

Max_used_connections / max_connections  * 100% ≈ 85%

最大连接数占上限连接数的85%左右,如果发现比例在10%以下,MySQL服务器连接数上限设置的过高了。

三、Key_buffer_size

key_buffer_size是对MyISAM表性能影响最大的一个参数,下面一台以MyISAM为主要存储引擎服务器的配置:

mysql> show variables like 'key_buffer_size';
+-----------------+------------+
| Variable_name   | Value      |
+-----------------+------------+
| key_buffer_size | 536870912 |
+-----------------+------------+

分配了512MB内存给key_buffer_size,我们再看一下key_buffer_size的使用情况:

mysql> show global status like 'key_read%';
+------------------------+-------------+
| Variable_name          | Value       |
+------------------------+-------------+
| Key_read_requests      | 27813678764 |
| Key_reads              | 6798830     |
+------------------------+-------------+

一共有27813678764个索引读取请求,有6798830个请求在内存中没有找到直接从硬盘读取索引,计算索引未命中缓存的概率:

key_cache_miss_rate = Key_reads / Key_read_requests * 100%

比如上面的数据,key_cache_miss_rate为0.0244%,4000个索引读取请求才有一个直接读硬盘,已经很BT了,key_cache_miss_rate在0.1%以下都很好(每1000个请求有一个直接读硬盘),如果key_cache_miss_rate在0.01%以下的话,key_buffer_size分配的过多,可以适当减少。

MySQL服务器还提供了key_blocks_*参数:

mysql> show global status like 'key_blocks_u%';
+------------------------+-------------+
| Variable_name          | Value       |
+------------------------+-------------+
| Key_blocks_unused      | 0           |
| Key_blocks_used        | 413543      |
+------------------------+-------------+

Key_blocks_unused表示未使用的缓存簇(blocks)数,Key_blocks_used表示曾经用到的最大的blocks数,比如这台服务器,所有的缓存都用到了,要么增加key_buffer_size,要么就是过渡索引了,把缓存占满了。比较理想的设置:

Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

四、临时表

mysql> show global status like 'created_tmp%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Created_tmp_disk_tables | 21197   |
| Created_tmp_files       | 58      |
| Created_tmp_tables      | 1771587 |
+-------------------------+---------+

每次创建临时表,Created_tmp_tables增加,如果是在磁盘上创建临时表,Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数,比较理想的配置是:

Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%

比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables * 100% = 1.20%,应该相当好了。我们再看一下MySQL服务器对临时表的配置:

mysql> show variables where Variable_name in ('tmp_table_size', 'max_heap_table_size');
+---------------------+-----------+
| Variable_name       | Value     |
+---------------------+-----------+
| max_heap_table_size | 268435456 |
| tmp_table_size      | 536870912 |
+---------------------+-----------+

只有256MB以下的临时表才能全部放内存,超过的就会用到硬盘临时表。

五、Open Table情况

mysql> show global status like 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables   | 919   |
| Opened_tables | 1951  |
+---------------+-------+

Open_tables表示打开表的数量,Opened_tables表示打开过的表数量,如果Opened_tables数量过大,说明配置中table_cache(5.1.3之后这个值叫做table_open_cache)值可能太小,我们查询一下服务器table_cache值:

mysql> show variables like 'table_cache';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| table_cache   | 2048  |
+---------------+-------+

比较合适的值为:

Open_tables / Opened_tables  * 100% >= 85%
Open_tables / table_cache * 100% <= 95%

待续,本文参考以下网页:

1.http://dev.mysql.com/doc/refman/5.1/en/server-status-variables.htm

2.http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html

3.http://www.ibm.com/developerworks/cn/linux/l-tune-lamp-3.html

4.http://www.day32.com/MySQL/tuning-primer.sh 具体数值主要参考此工具

Tags: ,

jQuery选择器使用演示

March 16th, 2009

上周在内部和大家分享了一下jQuery的选择器,做了一个简单的demo:http://chaoqun.17348.com/static/jQuery-selector-demo.html,直接调用的google js api,可以直接下载到本地运行,列出了一些常用的选择器方法,最后一个是动态选择器,可以传入一个变量来选择。文档就不写了,参阅:http://docs.jquery.com/Main_Page,直接看Demo演示吧。

Tags: ,

我也不知道的MySQL

March 13th, 2009

以前看过很多文章说MySQL一次查询只能用到一个索引,在实践中也没注意,一直奉为金科玉律,以此教育自己不要乱建索引,殊不知已是明日黄花

MySQL5.0以后引入了index_merge,在一些特定的查询中可以合并索引,详细的内容查看[中文] [英文],接着测试一下,还是那张表,数据还是10,000条。

mysql> desc tbl_name;
+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| uid   | int(11)      | NO   | MUL | NULL    |       |
| sid   | mediumint(9) | NO   |     | NULL    |       |
| times | mediumint(9) | NO   |     | NULL    |       |
+-------+--------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

执行查询测试:

mysql> explain select * from tbl_name where uid = 104460 and times = 38\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ref
possible_keys: uid
          key: uid
      key_len: 4
          ref: const
         rows: 9
        Extra: Using where
1 row in set (0.00 sec)

用到了uid索引,扫描了9行。在times上也加上索引:

mysql> create index times on tbl_name(times);

再执行上面的查询:

mysql> explain select * from tbl_name where uid = 104460 and times = 38\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: index_merge
possible_keys: uid,times
          key: uid,times
      key_len: 4,3
          ref: NULL
         rows: 1
        Extra: Using intersect(uid,times); Using where
1 row in set (0.00 sec)

用到了索引合并交集访问算法,只扫描了一行。注意索引合并只对一些特定的查询有用(注意看文档),比如下面的:

mysql> explain select * from tbl_name where uid = 104460 and times > 38\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ref
possible_keys: uid,times
          key: uid
      key_len: 4
          ref: const
         rows: 9
        Extra: Using where
1 row in set (0.00 sec)

挂了,还是只用到了uid索引,貌似还和MySQL的版本有一些关系,可以看看这篇博文http://www.alidba.net/index.php/archives/81

致歉,我传讹了,请大家更新”大脑数据库”,感谢xiaowei同学提醒,不知道的还很多,共同学习,一起进步。

Tags: ,

Python转换office word文件为HTML

March 12th, 2009

这里测试的环境是:windows xp,office 2007,python 2.5.2,pywin32 build 213,原理是利用win32com接口直接调用office API,好处是简单、兼容性好,只要office能处理的,python都可以处理,处理出来的结果和office word里面“另存为”一致。

#!/usr/bin/env python
 
#coding=utf-8
 
from win32com import client as wc
 
word = wc.Dispatch('Word.Application')
 
doc = word.Documents.Open('d:/labs/math.doc')
 
doc.SaveAs('d:/labs/math.html', 8)
 
doc.Close()
 
word.Quit()

关键的就是doc.SaveAs(‘d:/labs/math.html’, 8)这一行,网上很多文章写成:doc.SaveAs(‘d:/labs/math.html’, win32com.client.constants.wdFormatHTML),直接报错:

AttributeError: class Constants has no attribute ‘wdFormatHTML’

当然你也可以用上面的代码将word文件转换成任意格式文件(只要office 2007支持,比如将word文件转换成PDF文件,把8改成17即可),下面是office 2007支持的全部文件格式对应表:

wdFormatDocument                    =  0
wdFormatDocument97                  =  0
wdFormatDocumentDefault             = 16
wdFormatDOSText                     =  4
wdFormatDOSTextLineBreaks           =  5
wdFormatEncodedText                 =  7
wdFormatFilteredHTML                = 10
wdFormatFlatXML                     = 19
wdFormatFlatXMLMacroEnabled         = 20
wdFormatFlatXMLTemplate             = 21
wdFormatFlatXMLTemplateMacroEnabled = 22
wdFormatHTML                        =  8
wdFormatPDF                         = 17
wdFormatRTF                         =  6
wdFormatTemplate                    =  1
wdFormatTemplate97                  =  1
wdFormatText                        =  2
wdFormatTextLineBreaks              =  3
wdFormatUnicodeText                 =  7
wdFormatWebArchive                  =  9
wdFormatXML                         = 11
wdFormatXMLDocument                 = 12
wdFormatXMLDocumentMacroEnabled     = 13
wdFormatXMLTemplate                 = 14
wdFormatXMLTemplateMacroEnabled     = 15
wdFormatXPS                         = 18

照着字面意思应该能对应到相应的文件格式,如果你是office 2003可能支持不了这么多格式。word文件转html有两种格式可选wdFormatHTML、wdFormatFilteredHTML(对应数字8、10),区别是如果是wdFormatHTML格式的话,word文件里面的公式等ole对象将会存储成wmf格式,而选用wdFormatFilteredHTML的话公式图片将存储为gif格式,而且目测可以看出用wdFormatFilteredHTML生成的HTML明显比wdFormatHTML要干净许多。

当然你也可以用任意一种语言通过com来调用office API,比如PHP.

Tags: , , ,

你可能不知道的MySQL

March 11th, 2009

前言:

实验的数据表如下定义:

mysql> desc tbl_name;
+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| uid   | int(11)      | NO   |     | NULL    |       |
| sid   | mediumint(9) | NO   |     | NULL    |       |
| times | mediumint(9) | NO   |     | NULL    |       |
+-------+--------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

存储引擎是MyISAM,里面有10,000条数据。

一、”\G”的作用

mysql> select * from tbl_name limit 1;
+--------+--------+-------+
| uid    | sid    | times |
+--------+--------+-------+
| 104460 | 291250 |    29 |
+--------+--------+-------+
1 row in set (0.00 sec)

mysql> select * from tbl_name limit 1\G;
*************************** 1. row ***************************
  uid: 104460
  sid: 291250
times: 29
1 row in set (0.00 sec)

有时候,操作返回的列数非常多,屏幕不能一行显示完,显示折行,试试”\G”,把列数据逐行显示(”\G”挽救了我,以前看explain语句横向显示不全折行看起来巨费劲,还要把数据和列对应起来)。

二、”Group by”的”隐形杀手”

mysql> explain select uid,sum(times) from tbl_name group by uid\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using temporary; Using filesort
1 row in set (0.00 sec)

mysql> explain select uid,sum(times) from tbl_name group by uid order by null\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using temporary
1 row in set (0.00 sec)

默认情况下,Group by col会对col字段进行排序,这就是为什么第一语句里面有Using filesort的原因,如果你不需要对col字段进行排序,加上order by null吧,要快很多,因为filesort很慢的。

三、大批量数据插入

最高效的大批量插入数据的方法:

load data infile ‘/path/to/file’ into table tbl_name;

如果没有办法先生成文本文件或者不想生成文本文件,可以一次插入多行:

insert into tbl_name values (1,2,3),(4,5,6),(7,8,9)…

注意一条sql语句的最大长度是有限制的。如果还不想这样,可以试试MySQL的prepare,应该都会比硬生生的逐条插入要快许多。

如果数据表有索引,建议先暂时禁用索引:

alter table tbl_name disable keys;

插入完毕之后再激活索引:

alter table tbl_name enable keys;

对MyISAM表尤其有用。避免每插入一条记录系统更新一下索引。

四、最快复制表结构方法

mysql> create table clone_tbl select * from tbl_name limit 0;
Query OK, 0 rows affected (0.08 sec)

只会复制表结构,索引不会复制,如果还要复制数据,把limit 0去掉即可。

五、加引号和不加引号区别

给数据表tbl_name添加索引:

mysql> create index uid on tbl_name(uid);

测试如下查询:

mysql> explain select * from tbl_name where uid = '1081283900'\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ref
possible_keys: uid
          key: uid
      key_len: 4
          ref: const
         rows: 143
        Extra:
1 row in set (0.00 sec)

我们在整型字段的值上加索引,是可以用到索引的,网上不少人误传在整型字段上加引号无法使用索引。修改uid字段类型为varchar(12):

mysql> alter table tbl_name change uid uid varchar(12) not null;

测试如下查询:

mysql> explain select * from tbl_name where uid = 1081283900\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ALL
possible_keys: uid
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using where
1 row in set (0.00 sec)

我们在查询值上不加索引,结果索引无法使用,注意安全。

六、前缀索引

有时候我们的表中有varchar(255)这样的字段,而且我们还要对该字段建索引,一般没有必要对整个字段建索引,建立前8~12个字符的索引应该就够了,很少有连续8~12个字符都相等的字段。

为什么?更短的索引意味索引更小、占用CPU时间更少、占用内存更少、占用IO更少和很更好的性能。

七、MySQL索引使用方式

MySQL在一个查询中只能用到一个索引(5.0以后版本引入了index_merge合并索引,对某些特定的查询可以用到多个索引,具体查考[中文] [英文]),所以要根据查询条件建立联合索引,联合索引只有第一位的字段在查询条件中能才能使用到。

如果MySQL认为不用索引比用索引更快的话,那么就不会用索引。

mysql> create index times on tbl_name(times);
Query OK, 10000 rows affected (0.10 sec)
Records: 10000  Duplicates: 0  Warnings: 0

mysql> explain select * from tbl_name where times > 20\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ALL
possible_keys: times
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using where
1 row in set (0.00 sec)

mysql> explain select * from tbl_name where times > 200\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: range
possible_keys: times
          key: times
      key_len: 3
          ref: NULL
         rows: 1599
        Extra: Using where
1 row in set (0.00 sec)

数据表中times字段绝大多数都比20大,所以第一个查询没有用索引,第二个才用到索引。

Tags: , ,

一生所爱

March 4th, 2009

用自建的推荐系统给自己推荐歌曲,排在前面的居然有一首《一生所爱》,看大话西游的时候就特别喜欢这首歌,一直不知道叫什么名字,人生要是如算法那样简单该是多么的好。

一生所爱

曲:卢冠廷
词:唐书琛
编:卢冠廷
唱:卢冠廷

从前现在过去了再不来
红红落叶长埋尘土内
开始终结总是没变改
天边的你飘泊白云外
苦海翻起爱浪
在世间难逃避命运
相亲竟不可接近
或我应该相信是缘份
情人别后永远再不来(消散的情缘)
无言独坐放眼尘世外(愿来日再续)
鲜花虽会凋谢(只愿)但会再开(为你)
一生所爱隐约(守候)在白云外(期待)
苦海翻起爱浪
在世间难逃避命运
相亲竟不可接近
或我应该相信是缘份
苦海翻起爱浪
在世间难逃避命运
相亲竟不可接近
或我应该相信是缘份

自觉好像一条狗。

PHP SESSION解惑

February 28th, 2009

一、PHP SESSION原理

我们知道,session是在服务器端保持用户会话数据的一种方法,对应的cookie是在客户端保持用户数据。HTTP协议是一种无状态协议,服务器响应完之后就失去了与浏览器的联系,最早,Netscape将cookie引入浏览器,使得数据可以客户端跨页面交换,那么服务器是如何记住众多用户的会话数据呢?

首先要将客户端和服务器端建立一一联系,每个客户端都得有一个唯一标识,这样服务器才能识别出来。建议唯一标识的方法有两种:cookie或者通过GET方式指定。默认配置的PHP使用session的时会建立一个名叫”PHPSESSID”的cookie(可以通过php.ini修改session.name值指定),如果客户端禁用cookie,你也可以指定通过GET方式把session id传到服务器(修改php.ini中session.use_trans_sid等参数)。

我们查看服务器端session.save_path目录会发现很多类似sess_vv9lpgf0nmkurgvkba1vbvj915这样的文件,这个其实就是session id “vv9lpgf0nmkurgvkba1vbvj915″对应的数据。

真相就在这里,服务器将session id传递到服务器,服务器根据session id找到对应的文件,读取的时候对文件内容进行反序列化就得到session的值,保存的时候先序列化再写入。

事实就是这样,所以如果服务器不支持session或者你想自定义session,完全可以DIY,通过PHP的uniqid生成永不重复的session id,然后找个地方存储session的内容即可,你也可以学flickr把session存储在MySQL数据库中。

二、使用session之前为什么必须先执行session_start()?

了解的原理之后,所谓的session其实就是客户端一个session id服务器端一个session file,新建session之前执行session_start()是告诉服务器要种一个cookie以及准备好session文件,要不然你的session内容怎么存;读取session之前执行session_start()是告诉服务器,赶紧根据session id把session文件反序列化。

只有一个session函数可以在session_start()之前执行,session_nam():读取或指定session名称(比如默认的就是”PHPSESSID”),这个当然要在session_start之前执行。

三、session影响系统性能

session在大访问量网站上确实影响系统性能,影响性能的原因之一由文件系统设计造成,在同一个目录下超过10000个文件时,文件的定位将非常耗时,PHP支持session目录hash,我们可以通过修改php.ini中session.save_path = “2;/path/to/session/dir”,那么session将存储在两级子目录中(修订:参见david回复),不过好像PHP session不支持创建目录,你需要事先把那么些目录创建好 。

还有一个问题就是小文件的效率问题,一般我们的session数据都不会太大(1~2K),如果有大量这样1~2K的文件在磁盘上,IO效率肯定会很差,PHP手册上建议使用Reiserfs文件系统,不过Reiserfs的前景堪忧,Reiserfs的作者把媳妇给杀了,SuSE也抛弃了Reiserfs。

其实还有很多中存储session的方式,可以通过php -i|grep “Registered save handlers”查看,比如Registered save handlers => files user sqlite eaccelerator可以通过文件、用户、sqlite、eaccelerator来存,如果服务器装了memcached,还有会mmcache的选项。当然还有很多,比如MySQL、PostgreSQL等等。都是不错的选择。

四、session的同步

我们前端可能有很多台服务器,用户在A服务器上登录了,种下了session信息,然后访问网站的某些页面没准跳到B服务器上去了,如果这个时候B服务器上没有session信息又没有做特殊处理,可能就会出问题了。

session同步有很多种,如果你是存储在memcached或者MySQL中,那就很容易了,指定到同样的位置即可,如果是文件形式的,你可以用NFS统一存储

还有一种方式是通过加密的cookie来实现,用户在A服务器上登录成功,在用户的浏览器上种上一个加密的cookie,当用户访问B服务器时,检查有无session,如果有当然没问题,如果没有,就去检验cookie是否有效,cookie有效的话就在B服务器上重建session。这种方法其实很有用,如果网站有很多个子频道,服务器也不在一个机房,session没办法同步又想做统一登录那就太有用了。

当然还有一种方法就是在负载均衡那一层保持会话,把访问者帮定在某个服务器上,他的所有访问都在那个服务器上就不需要session同步了,这些都是运维层面的东西。

就说这么多吧,根据自己的应用来选择使用session,不要因为大家都说session影响系统性能就畏首畏尾,知道问题,解决问题才是关键,惹不起躲得起不适合这里。

Tags: ,

改善MySQL上16进制标识符性能的5种方法

February 13th, 2009

前言:

原文地址:5 ways to make hexadecimal identifiers perform better on MySQL,作者是《High Performance MySQL, Second Edition.》的主要作者。这里是原文的节译。

在我们的业务中,经常会用md5()或者uuid()作为作为数据的标识,比如B2C网站,经常会有一些电子优惠券,常用就是通过md5()获得一个32位字符串,给字符串建立索引,然后用户输入优惠券代码之后系统查出此优惠券对应的折扣率:select discount from coupon where id = ’0cc175b9c0f1b6a831c399e269779527′,这样的做法存在两个问题:数据和索引很大以及非顺序数据,本文忽略“非顺序数据”的问题,因为顺序数据和非顺序数据的优劣很大程度上由技术特性决定。这里讲得是如何在使用16进制大数据的情况下保持好的性能,主要讲的是MySQL数据库,对其他数据库应该也起作用。

一、小心你的字符编码

看一下下面这个SQL语句:

mysql> explain select * from t where id = ’0cc175b9c0f1b6a831c399e269772661′\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 98
ref: const
rows: 1
Extra: Using index

为什么索引是98byte?简单,因为我们用的是UTF-8:

CREATE TABLE `t` (
`id` varchar(32) NOT NULL,
PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

没有必要用UTF-8存储16进制数据,采用UTF-8存储16进制数据不会增加磁盘空间的占用,但是当你使用排序(order by)、统计(group by)、隐式临时表(MySQL查询时自建的临时表)等的时候,需要耗费多达3倍的内存和硬盘空间,至少在MySQL上是这样的。

二、使用固定长度,不要有空值

可以看到上面那个表采用的是varchar字段,我们都知道varchar是一个变长字段,如果你确认所有的数据都一样长(比如像md5()出来的,都是32个字节),最好使用char()定长字段,另外就是如果字段中不可能有空值,最好指定为not null

三、使用二进制数据存储

实际上,你并不需要存储字符串,16进制字符串不过是数字的另一种表现形式,直接保存数字。比如:00000000000000000000000000002E2A是什么呢?这正是16进制数字11818,使用一个4字节(或者更少)的整型代替一个32字节的字符存储更好。

问题是MySQL没有合适的类型来存储这么大的数字,它们比BIGINT还要大很多,不过MySQL允许我们存储到BINARY字段,数据更紧凑比较起来更快速,可以使用HEX()和UNHEX()来转换格式,或者16进制操作符’x’

mysql> select x’7861707262′;
+—————+
| x’7861707262′ |
+—————+
| xaprb         |
+—————+

用BINARY(16)代替varchar(32)之后:

explain select * from t where id = x’0cc175b9c0f1b6a831c399e269772661′\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 16
ref: const
rows: 1
Extra: Using index

索引长度变成16字节了(对比原来98字节),减小了不少,如果你使用的是UUID(),存入之前先用replace()把”-”题换掉。

四、使用前缀索引

很多时候,我们不需要索引全部字段,索引字段的前8~10个字符就可以了,如果你当前存储的是字符串,这很有用,不用转换成BINARY,只是改变索引策略而已。

你可以通过类似下面的SQL语句判断合适的前缀索引个数:

mysql> select count(distinct id), count(distinct left(id, 8)), count(distinct left(id, 9)) from t\G
*************************** 1. row ***************************
count(distinct id): 2
count(distinct left(id, 8)): 2
count(distinct left(id, 9)): 2

找一个差不多行就可以,不一定要索引“唯一”。

五、创建hash索引

直接上代码,不用多余的解释:

mysql> alter table t add crc int unsigned not null, add key(crc);
mysql> update t set crc=crc32(id);
mysql> explain select * from t use index(crc) where id = ’0cc175b9c0f1b6a831c399e269772661′ and crc=crc32(’0cc175b9c0f1b6a831c399e269772661′)\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t
type: ref
possible_keys: crc
key: crc
key_len: 4
ref: const
rows: 1
Extra: Using where

使用crc32()获取到字符串的校验值,一般这样的碰撞概率不会太大,索引数字比索引字符不知道要快多少,极力推荐,不仅仅适用16进制字符,任意字符也适合:

mysql> select crc32(‘good good study, and day day up!’);
+——————————————-+
| crc32(‘good good study, and day day up!’) |
+——————————————-+
|                                2265998365 |
+——————————————-+
1 row in set (0.00 sec)

总结:

16进制标识符让表和索引的变大,降低比较和查找的速度,建议非不得已不要使用,如果非要使用,希望上面的五条建议对你有用。

后记:

有时候我们确实必须使用字符串作为唯一标识符,比如我这篇博客地址:http://chaoqun.17348.com/2009/02/5-ways-to-make-hexadecimal-identifiers-perform-better-on-mysql,系统需要通过“5-ways-to-make-hexadecimal-identifiers-perform-better-on-mysql”去找出相应的博文,这个时候使用前面的建议就非常有用,很不幸的是WordPress没有用。

Tags:

扩展Digg和其他的网络应用

February 12th, 2009

前言:

关于Digg的架构,之前Fenng已经写过一篇Digg 网站架构的文章,Fenng在文章开头说“越来越发现其实都是自我重复的劳动,后续的信息都是嚼别人剩下的甘蔗。”,其实是Fenng过谦了,我就是从DBA notes一点一滴开始学习的。

原文在Scaling Digg and Other Web ApplicationsTodd Hoff总能给我们带来一些有意思的文章。这里既不直译也不全译,保持原文骨干加上肤浅的理解。

Digg用户在3000W左右,网站每秒请求数达到13000个,规模算是很大了,Lamp(Linux+Apache+MySQL+PHP)结构,Web2.0网站中钟情PHP的不少,国外的Facebook、Digg、Flickr…,国内的新浪博客、开心网、51.com等等,扩展的不是编程语言而是网站架构,因为编程语言从来都不会是网站瓶颈,每种语言都有自己适合做和不适合做的事情。喜欢比较语言快慢的可以看看http://shootout.alioth.debian.org/,看看而已不要用速度去衡量编程语言的优劣。

Digg的扩展战略:

  • 扩展是有特殊性的,当已有的方案不能满足需求时,你需要根据自己的特殊需求来建立方案。要熟悉自己的业务需求,找出系统的短板,解决问题,避免过度优化。
  • 编程语言不需要扩展,因为语言从来都不是瓶颈,把PHP提速300%不会是什么大问题。
  • 去中心化,分布式处理高并发请求。
  • 水平扩展,用更多更便宜的机器代替更高效更昂贵的机器。
  • 数据库驱动的网站需要作水平分区和垂直分区扩展,水平分区就是把数据放到不同的机器上,比如按照时间划分:2009年的数据一组服务器,2009年的数据一组服务器,或者按照用户ID划分:每200W用户一组服务器;垂直分区把一个表分成多个表,每个表只包含一部分字段,可以按照业务分或者常用的“动静分离”,比如对文章计数的字段大可以和文章内容字段分开。
  • 建立数据应用层,程序不要直接操作数据库分区,这样可以保持好的扩展性。这一点非常重要,如果没有数据应用层API,一旦对数据库分区做了修改,你的程序就需要大改了。程序的稳定性和持续性就不能保证。比较常见的MVC开发模式,数据层和逻辑层分开,一旦数据库底层改变了,只需要对数据层做简单的修改,不影响既有业务。
  • 一致性、高可用性、分区容忍性(Partition Tolerance)三者只能取其二,具体的阅读http://camelcase.blogspot.com/2007/08/cap-theorem.html,一致性:每个人看到的都一样,哪怕当时就有更新;高可用性:部分故障不影响使用;分区容忍性:数据分区还能保持系统所有属性。
  • 数据分区要求反常规化,这是在Digg是大问题,同样的数据要复制到多个对象上去,而且还好保持同步。
  • 采用异步的队列架构,把任务放到队列中交由多台机器处理,而不是一次同步处理,关于异步任务处理可以阅读 Flickr – Do the Essential Work Up-front and Queue the RestThe Canonical Cloud Architecture
  • icons和图片采用MogileFS存储,MogileFS是一个分布式的文件系统,由memcached作者开发,国内的好看簿也有使用MogileFS。
  • 采用APC作为PHP加速器,Facebook用的也是这个,PHP5.30以后将自带APC加速器,同样的产品还有eAcceleratorXcache,国内可能用eAccelerator的比较多,windows的版本我一般用这个网站编译的
  • 缓存策略:永久性缓存和失效期缓存;基本不更新的内容采用文件缓存;动态缓存采用memcached;极少修改的数据采用APC缓存,APC不是分布式缓存,直接缓存的机器内存中,所以速度更快,适合缓存那些配置文件,比如MySQL的配置信息;缓存采用链责任模式,首先看PHP全局变量,如果没有就查APC,再没有就查memcached,最后没有就查数据库,这个觉得不太必要,你的缓存存在哪来你自己还不清楚阿。
  • Digg的推荐引擎是一个自定义的图形数据库,数据库最终保证一致性,先写如一个分区,然后再逐步写到其他的分区。在更新的过程中,可能取出来的数据不一致,是因为有不同的数据库分区处理,最终将会是一致。

MemcacheDB:性能革命性的一步

想象一下Kevin Rose,Digg的创建者,当前有4000个追随者,如果Kevin Rose一天digg一次,将会有4000个写操作,最热门的digg有最多的追随者,这会导致巨大的性能瓶颈:

  • 你不能同时更新4000个追随者的帐号信息,幸运的是我们可以通过前面提到的异步队列方式解决。
  • Digg面临的海量写操作,如果平均每个人有100个追随者,一天就有3亿条写操作,平均到每秒有3000个写操作,每天有5GB的数据存储,在50~60台服务器之间有5TB的数据交换。

如果是MySQL的话估计早就挂了,Digg在笔记本上的测试是memcachedb每秒可以处理15000个写操作,memcachedb的测试结果表明每秒可以支持23000个写操作或者64000个读操作,足以应付Digg洪水般的请求。

memcachedb是一个分布式的kye-value型数据持久化解决方案,提供兼容memcached协议接口,由Sina工程师Steve Chu开发。

提到Digg为什么采用memcachedb,Digg的工程师给出的理由是:需要持久化缓存数据,与memcached协议兼容,Digg已经有很多业务应用了memcached,可以很方便的切换到memcachedb上去,开源。

后记:

很高兴的看到除了Sina,memcachedb又有一个超重量级的应用了,性能和可靠性都得到了极大的检验,大可放心应用生产环境中。我还说今年有空写个玩具版的类memcachedb项目,还是不要了,有时间还是去做些更有意义的事情,无谓重复发明。

Tags: ,

基于Infobright的MySQL数据仓库方案测试

February 10th, 2009

数据仓库之父Bill Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受——数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。

上面这段是抄的,简单的讲数据仓库是一个面向主题的、集成的、不可更新的、随时间不断变化的数据集合,它用于支持企业或组织的决策分析处理,这一句也是抄的,更直白的举例就是公司的历史交易数据集合,网站的历史访问数据集合,这一句是原创的。

Infobright是开源的MySQL数据仓库解决方案,引入了列存储方案,高强度的数据压缩,优化的统计计算(类似sum/avg/group by之类),下面是Infobright的架构图:

安装篇:

Infobright目前还不支持windows系列操作系统,不过你可以装在Linux虚拟机上,或者从官方直接下载做好的VMWARE虚拟机,这里的测试环境是CentOS 5.2 32bit操作系统。Infobright也不支持以插件的形式集成到已有的MySQL系统中去,官方的说法是对MySQL做了很多修改,不支持以插件的形式使用。

详细的安装参照http://www.infobright.org/wiki/Install_Guide/,需要注意的是如果你的系统中已经有MySQL(默认端口3306),你需要重新设定一下安装参数,比如像我的:

./install-infobright.sh –datadir=/data/infobright/data –cachedir=/data/infobright/cache –port=9527 –config=/etc/my-ib.cnf –socket=/tmp/mysql-ib.sock –user=mysql –group=mysql

配置文件包括MySQL配置文件(/etc/my-ib.cnf)和Infobright配置文件(在安装时候指定的数据目录内,比如/data/infobright/data/brighthouse.ini),如果需要支持MySQL原生的SQL查询,需要修改brighthouse.ini设定

AllowMySQLQueryPath = 1

这样不至于有些SQL语句不能执行,安装完成,启动服务:

/etc/init.d/mysqld-ib start

通过命令行:mysql-ib -uroot直接连接,默认密码为空,修改密码:

/usr/local/infobright/bin/mysqladmin  -u root -p password NEWPASSWORD

测试篇:

测试数据是一个1.5GB大的文本数据,数据格式类似:

用户ID  内容ID  用户打分
765331  3868    5
716091  3868    3
1663216 3868    3
51971   3868    5

在测试数据库中新建两张表,一个为Infobright支持的brighthouse存储引擎,一个为MySQL原生的MyISAM存储引擎,其他内容一致:

CREATE TABLE `t_ib` (
`uid` mediumint(9) NOT NULL,
`cid` smallint(6) NOT NULL,
`rating` tinyint(4) NOT NULL
) ENGINE=BRIGHTHOUSE;

CREATE TABLE `t_mis` (
`uid` mediumint(9) NOT NULL,
`cid` smallint(6) NOT NULL,
`rating` tinyint(4) NOT NULL
) ENGINE=MyISAM

将数据load进表:

load data infile ‘path/to/data.txt’ into table table_name fields terminated by “\t”;

我们比较一下文件大小:

数据类型      数据大小
data.txt      1.5GB
data.tar.gz   429MB
MyISAM表      671MB
Infobight表   280MB

超过5:1的压缩比,虽然没有传说中10:1,但数据的大小比tar.gz过还要小近一半,压缩能力可见一斑。

准备进行SQL的测试,不能在BRIGHTHOUSE存储引擎上建索引,因为根本就不需要建,我们在MyISAM引擎表上建立如下索引:

create index id on t_mis(cid);

执行下列SQL语句,查询内容ID大于9527的条目数(为了节省篇幅,略去结果集,只返回执行时间):

mysql> select count(*) from t_mis where cid > 9527;
1 row in set (41.81 sec)

mysql> select count(*) from t_ib where cid > 9527;
1 row in set (13.66 sec)

Infobright花费的时间只有MyISAM的1/4左右,再测试一下找出被用户打分最多的10条内容:

mysql> select cid from t_mis group by cid order by count(*) desc limit 10;
10 rows in set (1 min 21.30 sec)

mysql> select cid from t_ib group by cid order by count(*) desc limit 10;
10 rows in set (39.02 sec)

Infobright大概只花费了MyISAM 1/3多一点的时间。再查询一下评价最好的10条内容:

mysql> select cid from t_mis group by cid order by avg(rating) desc limit 10;
10 rows in set (6 min 16.15 sec)

mysql> select cid from t_ib group by cid order by avg(rating) desc limit 10;
10 rows in set (1 min 1.25 sec)

不到1/6时间。

后记:

强悍的压缩比率,高效的SQL统计性能,Infobright的表现很是不错。对于网站开发者来说,建立一个Infobright数据仓库系统用来保存网站的历史访问元数据应该是一个不错的选择,尤其是需要OLAP或者更为灵活的统计功能的时候。

Tags: , , ,