看了一些人的所谓大型项目的方法,我感觉都是没有说到点子上，有点难受。
我也说说自己的看法.我个人认为,很难衡量所谓项目是否大型,
即便很简单的应用在高负载和高增长情况下都是一个挑战.因此,按照我的想法,姑且说是高负载
高并发或者高增长情况下,需要考虑的问题.这些问题,很多是和程序开发无关,而是和整个系统的
架构密切相关的.
一般来说MySQL是最常用的，可能最初是一个mysql主机，当数据增加到100万以上，
那么，MySQL的效能急剧下降。常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的
服务器上进行操作。我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，
但是同时只有1个是Active，我们可以在一定时候切换。之所以用2个M，是保证M不会又成为系统的SPOF。
Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。
以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了
SPOF。你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，
从业务层面上进行分区。最简单的，以用户数据为例。根据一定的切分方式，比如id，切分到不同的数据库集群去。
全局数据库用于meta数据的查询。缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到
全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。
每个cluster可以用m-m方式，或者m-m-slaves方式。
这是一个可以扩展的结构，随着负载的增加，你可以简单的增加新的mysql cluster进去。
需要注意的是：
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。
4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，或者干脆自己做，因为php4中mysql的
链接池经常出问题。
swap，最好关闭linux的swap。
负载均衡和加速。我认为Lighttped+Squid是最好的方式了。
LVS <------->lighttped====>squid(s) ====lighttpd
上面是我经常用的。注意，我没有用apache，除非特定的需求，否则我不部署apache，因为我一般用php-fastcgi配合lighttpd,
性能比apache+mod_php要强很多。
squid的使用可以解决文件的同步等等问题，但是需要注意，你要很好的监控缓存的命中率，尽可能的提高的90%以上。
squid和lighttped也有很多的话题要讨论，这里不赘述。
小文件的存储最简单的方法是结合lighttpd来进行分布。或者干脆使用Redhat的GFS，优点是应用透明，缺点是费用较高。我是指
你购买盘阵的问题。我的项目中，存储量是2-10Tb，我采用了分布式存储。这里要解决文件的复制和冗余。
这样每个文件有不同的冗余，这方面可以参考google的gfs的论文。
大文件的存储，可以参考nutch的方案，现在已经独立为hadoop子项目。(你可以google it)
其他：
此外，passport等也是考虑的，不过都属于比较简单的了。
吃饭了，不写了，抛砖引玉而已。
作者: terry39 时间: 2007-1-2 09:42
学习~ 还没开发过如楼主所说的大型项目！！！ 感谢分享经验！
作者: kenus 时间: 2007-1-2 11:51
:victory:
作者: fengyun 时间: 2007-1-2 15:05
作者: Nickboy 时间: 2007-1-2 15:34
新手，看不太懂！
作者: geniuscynic 时间: 2007-1-2 15:39
新手，看不太懂！
作者: zhaogequ 时间: 2007-1-2 15:54
不要那么狠好不好!我们只是想用来搞点小玩意.
作者: programboy 时间: 2007-1-2 16:23
一直想了解大型网站项目的策划,希望楼主以后多发此类文章
作者: forest 时间: 2007-1-2 21:06
好文章,收藏了!
作者: dzjzmj 时间: 2007-1-2 21:49
作者: yuking 时间: 2007-1-2 22:49
为什么 禁用全部auto_increment ？
作者: qinyf 时间: 2007-1-3 00:24
因为ID已经分布在多台机器上了吧
作者: Yimin 时间: 2007-1-3 12:56
支持楼主分享更多的经验。
希望还能给出测试数据。。。
UP。
作者: 9tmd 时间: 2007-1-3 15:04
说了关键的几个部分，还有一些比如squid群、LVS或者VIP（四层交换）之类的必须考虑，数据库逻辑分表不需要master里面查id，可以定期缓存或者程序逻辑上进行控制。
跟大家分享一下我的经验： http://www.toplee.com/blog/archives/337.html （欢迎讨论）
作者: nightsailer 时间: 2007-1-3 16:20
楼上说的很好.
我 再说一下关于为何要在主表查询，最主要的因素是考虑到复制和维护的问题。假设按照程序逻辑，用户nightsailer应该在s1集群，但是由于种种原 因，我须要将nightsailer的数据从s1集群转移到s5集群或者某些时候，我需要将某几个集群的数据合并，此时，我维护的时候只需要更新一下主数 据库中nightsailer的cluster id从1变成5,，维护的工作可以独立进行，无需考虑更新应用程序的逻辑。也许程序的id分配逻辑可以考虑到这种情况，但是这样一来，你的这个逻辑会发散 到各个应用中，产生的代码的耦合是很高的。相反，采用查表这种方式，只需要在最初的时候进行初始分配，那么其他的应用是无需考虑这些算法和逻辑的。
当然，我最初提到的增加这次查询并不是说每次查询都需要找主数据库，缓存策略是必定要考虑的。
至于说为什么要禁用auto_increment,我想也清楚了，数据的合并和分隔，肯定是不能用auto_increment的。
作者: nightsailer 时间: 2007-1-3 16:35
在闲扯一下，PHP的优化可以有很多，主要的措施：
1、使用FCGI方式，配合lighttpd,Zeus.
我个人比较喜欢Zeus，简单可靠。不过，需要￥￥￥。
lighty也不错，配置文件也很简单，比较清爽。最新的1.5,虽然不稳定，但是配合linux的aio,性能的提升
非常明显。即便现在的稳定版，使用2.6的epoll可以得到的性能是非常高。当然，lighty比zeus缺点是对于smp
的支持很有限，所以可以采用多服务器负载,或者干脆起不同的进程服务监听不同的端口。
2、专门的PHP FCGI服务器。
好处多多，在这个服务器上，就跑php的fcgi服务，你可以把一些缓存加上，比如xcache，我个人喜欢这个。
还有别的，套用大腕的话，把能装的都装上，呵呵。
另外，最主要的是，你可以只维护一个php的环境，这个环境能够被apache,zeus,lighttpd同时share，
前提是这些都使用php的fcgi模式，而且，xcache可以充分发挥！
3、apache+mod_fastcgi
apache并非无用，有时候也需要。比如我用php做了一个web_dav的服务器，在其他有问题，只能跑apache.
那么，apache安装一下mod_fastcgi，通过使用externl server，使用2配置的php fastcgi。
4、优化编译
ICC是我的首选，就是intel的编译器啦，用icc重新编译php,mysql,lighty,能编的都编，会有不小的收获的。尤其是你用
intel的cpu的话。
5、php4的64位需要patch
好像没有人在linux x86_64上编译过php4吧，我曾经googleit
,别说国内了，连老外都很少用。
这里就做个提醒把，如果用php官方下载的(包括最新的php-4.4.4)，统统无法编译通过。问题是出在autoconf上，需要
手工修改config.m4，一般是在mysql,gd,ldap等一些关键的extension上，还有phpize的脚本。把/usr/lib64加入到
config.m4中相关搜索的path中。
不过我估计很少人像我这样死用php4不防，呵呵。php5就没有问题。
我也考虑正在迁移到php5.2，写代码太方便了，一直忍着呢。
[ 本帖最后由 nightsailer 于 2007-1-3 16:38 编辑 ]
作者: wuexp 时间: 2007-1-3 16:54
大部分跟系统有关,对程序员来说是透明的
作者: wuexp 时间: 2007-1-3 17:01
分表会使操作数据(更改,删除,查询)边的很复杂,特别是遇到排序的时候就更麻烦了.
曾经考虑根据用户id哈希一下,插入到相应的分表里
作者: nightsailer 时间: 2007-1-3 17:33
明白你的意思。
不过我们可能讨论的不完全一样，呵呵。
我所说的分表要依据不同的业务情况来划分的，
1、可以是垂直划分，
比如依据业务实体切分，比如用户a的blog贴子，用户的tag，用户的评论都在a数据库u，甚者是完整的一套数据结构(这种情况下应该说是分数据库）
2、也可以水平划分，
一个表的数据分在不同的数据库上。
比如message表，你可能分为daily_message,history_message，
dialy_meesage可能是hot对象，week_message是warm，2个月以前的帖子
可能属于cold对象了。这些对象依据访问频度不同会划分到不同的数据库群上。
3、二者结合
不过，不论如何，更改、删除并不复杂，和未分区的表没有区别。
至于查询和排序，不可能仅仅是通过select，order吧？
而是应该产生类似摘要表，索引表，参考表。。。
另外，要根据业务具体分析减少垃圾数据，有些时候，只需要最初的1万条记录，那么所有表
数据的排序就不需要了。很多传统的业务，比如零售，流水表很大，但是报表的数据
并非实时生成的，扎报表应该不陌生。
也可以参考很多网站的做法，比如technorati啊,flickr之类的。
所谓的麻烦是你设计系统的结构的时候要考虑到，在设计数据库的时候更要注意，
因此只要项目的framework最初设计比较完备，那么可以说大部分对开发人员是透明的。
前提是，你一定要设计好，而不是让程序员边写代码边设计，那会是噩梦。
我写这么多废话，并非仅仅是对程序员来说，也许对设计者更有用。
[ 本帖最后由 nightsailer 于 2007-1-3 17:36 编辑 ]
作者: MySQL 时间: 2007-1-3 17:47
很好的文章。！
作者: 9tmd 时间: 2007-1-4 11:20
程序逻辑上控制表拆分只需要维护一个数据库访问的配置文件即可，对于开发来说，完全透明，可以不用关心访问的是哪里，而只需要调用通用的接口即可，曾经做过的系统里面，这样的应用经常遇到，尤其在全网passport、社区帖子等方面的处理上应用最多。
原来在yahoo工作和后来mop工作都使用了这样的架构，整体感觉来说还是值得信赖的，单表毕竟存在面对极限数据量的风险。
作者: 9tmd 时间: 2007-1-4 11:39
前 面老是有人问auto_increment的问题，其实这是MySQL官方专门针对M/S的Replication做过的说明，因为MySQL的同步是依 靠同步MySQL的SQL日志来实现的，事实上单向的Master->Slave使用auto_increment是没有问题的，而双向的M/M模 式就会存在问题了，稍微一思考就知道怎么回事了。官方文档：
http://dev.mysql.com/tech-resour ... ql-replication.html
http://dev.mysql.com/doc/refman/ ... auto-increment.html
另 外，在使用MySQL的同步时，需要注意在自己的代码里面，写SQL的时候不要使用MySQL自己提供的类似 NOW()之类的函数，而应该使用php程序里面计算的时间带入SQL语句里面，否则同步的时候也可能导致值不相等，这个道理可以牵涉出另外一些类似的问 题，大家可以考虑一下。
作者: wuexp 时间: 2007-1-5 11:54
明白业务分表,但是有时候一些基本表会随着数据的增加回变的很大,如果mysql的表达到千万条数据,效率会下降的非常快,对某条记录进行操作会非常容易锁表.
两个m,多个s,之间同步速度会随着降低,反映速度很慢,这需要一些中间件来解决
作者: zhwb36 时间: 2007-1-6 10:45
楼主是个强淫！
作者: laozei 时间: 2007-2-5 15:03
我在linux x86_64(AMD,Centos 4.3/4.4)上编译过php4,php5
php4费了很大的劲才编译好
php5装好之后，程序运行不正常，现在还继续用着php4
从探针的探测结果来看,php4在那台机子上的效率好像很差，不过，网站运行起来好像还可以
试过xcache，那时候还是低版本，网站运行不正常，就没用了，用的是eAccelerator
web server 是lighttpd 1.4.13
作者: leidong8 时间: 2007-2-6 15:14
好!
作者: 深空 时间: 2007-5-15 11:27
上面我想有个问题很严重，就是时间的问题，数据库分布到不同的服务器，NOW()就不同，PHP分布到不同服务器，time()也不同，我想是不是需要一个标准来获取时间。
另外就是auto_increment的问题，我觉得可以通过维护一张包含auto_increment的id表来实现INSERT的id唯一。
我也说说自己的看法.我个人认为,很难衡量所谓项目是否大型,
即便很简单的应用在高负载和高增长情况下都是一个挑战.因此,按照我的想法,姑且说是高负载
高并发或者高增长情况下,需要考虑的问题.这些问题,很多是和程序开发无关,而是和整个系统的
架构密切相关的.
- 数据库
一般来说MySQL是最常用的，可能最初是一个mysql主机，当数据增加到100万以上，
那么，MySQL的效能急剧下降。常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的
服务器上进行操作。我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，
但是同时只有1个是Active，我们可以在一定时候切换。之所以用2个M，是保证M不会又成为系统的SPOF。
Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。
以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了
SPOF。你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，
从业务层面上进行分区。最简单的，以用户数据为例。根据一定的切分方式，比如id，切分到不同的数据库集群去。
全局数据库用于meta数据的查询。缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到
全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。
每个cluster可以用m-m方式，或者m-m-slaves方式。
这是一个可以扩展的结构，随着负载的增加，你可以简单的增加新的mysql cluster进去。
需要注意的是：
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。
4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，或者干脆自己做，因为php4中mysql的
链接池经常出问题。
- 缓存
swap，最好关闭linux的swap。
- 负载均衡/加速
负载均衡和加速。我认为Lighttped+Squid是最好的方式了。
LVS <------->lighttped====>squid(s) ====lighttpd
上面是我经常用的。注意，我没有用apache，除非特定的需求，否则我不部署apache，因为我一般用php-fastcgi配合lighttpd,
性能比apache+mod_php要强很多。
squid的使用可以解决文件的同步等等问题，但是需要注意，你要很好的监控缓存的命中率，尽可能的提高的90%以上。
squid和lighttped也有很多的话题要讨论，这里不赘述。
- 存储
小文件的存储最简单的方法是结合lighttpd来进行分布。或者干脆使用Redhat的GFS，优点是应用透明，缺点是费用较高。我是指
你购买盘阵的问题。我的项目中，存储量是2-10Tb，我采用了分布式存储。这里要解决文件的复制和冗余。
这样每个文件有不同的冗余，这方面可以参考google的gfs的论文。
大文件的存储，可以参考nutch的方案，现在已经独立为hadoop子项目。(你可以google it)
其他：
此外，passport等也是考虑的，不过都属于比较简单的了。
吃饭了，不写了，抛砖引玉而已。
作者: terry39 时间: 2007-1-2 09:42
学习~ 还没开发过如楼主所说的大型项目！！！ 感谢分享经验！
作者: kenus 时间: 2007-1-2 11:51
:victory:
作者: fengyun 时间: 2007-1-2 15:05
作者: Nickboy 时间: 2007-1-2 15:34
新手，看不太懂！
作者: geniuscynic 时间: 2007-1-2 15:39
新手，看不太懂！
作者: zhaogequ 时间: 2007-1-2 15:54
不要那么狠好不好!我们只是想用来搞点小玩意.
作者: programboy 时间: 2007-1-2 16:23
一直想了解大型网站项目的策划,希望楼主以后多发此类文章
作者: forest 时间: 2007-1-2 21:06
好文章,收藏了!
作者: dzjzmj 时间: 2007-1-2 21:49
作者: yuking 时间: 2007-1-2 22:49
为什么 禁用全部auto_increment ？
作者: qinyf 时间: 2007-1-3 00:24
因为ID已经分布在多台机器上了吧
作者: Yimin 时间: 2007-1-3 12:56
支持楼主分享更多的经验。
希望还能给出测试数据。。。
UP。
作者: 9tmd 时间: 2007-1-3 15:04
说了关键的几个部分，还有一些比如squid群、LVS或者VIP（四层交换）之类的必须考虑，数据库逻辑分表不需要master里面查id，可以定期缓存或者程序逻辑上进行控制。
跟大家分享一下我的经验： http://www.toplee.com/blog/archives/337.html （欢迎讨论）
作者: nightsailer 时间: 2007-1-3 16:20
楼上说的很好.
我 再说一下关于为何要在主表查询，最主要的因素是考虑到复制和维护的问题。假设按照程序逻辑，用户nightsailer应该在s1集群，但是由于种种原 因，我须要将nightsailer的数据从s1集群转移到s5集群或者某些时候，我需要将某几个集群的数据合并，此时，我维护的时候只需要更新一下主数 据库中nightsailer的cluster id从1变成5,，维护的工作可以独立进行，无需考虑更新应用程序的逻辑。也许程序的id分配逻辑可以考虑到这种情况，但是这样一来，你的这个逻辑会发散 到各个应用中，产生的代码的耦合是很高的。相反，采用查表这种方式，只需要在最初的时候进行初始分配，那么其他的应用是无需考虑这些算法和逻辑的。
当然，我最初提到的增加这次查询并不是说每次查询都需要找主数据库，缓存策略是必定要考虑的。
至于说为什么要禁用auto_increment,我想也清楚了，数据的合并和分隔，肯定是不能用auto_increment的。
作者: nightsailer 时间: 2007-1-3 16:35
在闲扯一下，PHP的优化可以有很多，主要的措施：
1、使用FCGI方式，配合lighttpd,Zeus.
我个人比较喜欢Zeus，简单可靠。不过，需要￥￥￥。
lighty也不错，配置文件也很简单，比较清爽。最新的1.5,虽然不稳定，但是配合linux的aio,性能的提升
非常明显。即便现在的稳定版，使用2.6的epoll可以得到的性能是非常高。当然，lighty比zeus缺点是对于smp
的支持很有限，所以可以采用多服务器负载,或者干脆起不同的进程服务监听不同的端口。
2、专门的PHP FCGI服务器。
好处多多，在这个服务器上，就跑php的fcgi服务，你可以把一些缓存加上，比如xcache，我个人喜欢这个。
还有别的，套用大腕的话，把能装的都装上，呵呵。
另外，最主要的是，你可以只维护一个php的环境，这个环境能够被apache,zeus,lighttpd同时share，
前提是这些都使用php的fcgi模式，而且，xcache可以充分发挥！
3、apache+mod_fastcgi
apache并非无用，有时候也需要。比如我用php做了一个web_dav的服务器，在其他有问题，只能跑apache.
那么，apache安装一下mod_fastcgi，通过使用externl server，使用2配置的php fastcgi。
4、优化编译
ICC是我的首选，就是intel的编译器啦，用icc重新编译php,mysql,lighty,能编的都编，会有不小的收获的。尤其是你用
intel的cpu的话。
5、php4的64位需要patch
好像没有人在linux x86_64上编译过php4吧，我曾经googleit
,别说国内了，连老外都很少用。
这里就做个提醒把，如果用php官方下载的(包括最新的php-4.4.4)，统统无法编译通过。问题是出在autoconf上，需要
手工修改config.m4，一般是在mysql,gd,ldap等一些关键的extension上，还有phpize的脚本。把/usr/lib64加入到
config.m4中相关搜索的path中。
不过我估计很少人像我这样死用php4不防，呵呵。php5就没有问题。
我也考虑正在迁移到php5.2，写代码太方便了，一直忍着呢。
[ 本帖最后由 nightsailer 于 2007-1-3 16:38 编辑 ]
作者: wuexp 时间: 2007-1-3 16:54
大部分跟系统有关,对程序员来说是透明的
作者: wuexp 时间: 2007-1-3 17:01
分表会使操作数据(更改,删除,查询)边的很复杂,特别是遇到排序的时候就更麻烦了.
曾经考虑根据用户id哈希一下,插入到相应的分表里
作者: nightsailer 时间: 2007-1-3 17:33
QUOTE:
原帖由
wuexp 于 2007-1-3 17:01 发表
分表会使操作数据(更改,删除,查询)边的很复杂,特别是遇到排序的时候就更麻烦了.
曾经考虑根据用户id哈希一下,插入到相应的分表里
分表会使操作数据(更改,删除,查询)边的很复杂,特别是遇到排序的时候就更麻烦了.
曾经考虑根据用户id哈希一下,插入到相应的分表里
明白你的意思。
不过我们可能讨论的不完全一样，呵呵。
我所说的分表要依据不同的业务情况来划分的，
1、可以是垂直划分，
比如依据业务实体切分，比如用户a的blog贴子，用户的tag，用户的评论都在a数据库u，甚者是完整的一套数据结构(这种情况下应该说是分数据库）
2、也可以水平划分，
一个表的数据分在不同的数据库上。
比如message表，你可能分为daily_message,history_message，
dialy_meesage可能是hot对象，week_message是warm，2个月以前的帖子
可能属于cold对象了。这些对象依据访问频度不同会划分到不同的数据库群上。
3、二者结合
不过，不论如何，更改、删除并不复杂，和未分区的表没有区别。
至于查询和排序，不可能仅仅是通过select，order吧？
而是应该产生类似摘要表，索引表，参考表。。。
另外，要根据业务具体分析减少垃圾数据，有些时候，只需要最初的1万条记录，那么所有表
数据的排序就不需要了。很多传统的业务，比如零售，流水表很大，但是报表的数据
并非实时生成的，扎报表应该不陌生。
也可以参考很多网站的做法，比如technorati啊,flickr之类的。
所谓的麻烦是你设计系统的结构的时候要考虑到，在设计数据库的时候更要注意，
因此只要项目的framework最初设计比较完备，那么可以说大部分对开发人员是透明的。
前提是，你一定要设计好，而不是让程序员边写代码边设计，那会是噩梦。
我写这么多废话，并非仅仅是对程序员来说，也许对设计者更有用。
[ 本帖最后由 nightsailer 于 2007-1-3 17:36 编辑 ]
作者: MySQL 时间: 2007-1-3 17:47
很好的文章。！
作者: 9tmd 时间: 2007-1-4 11:20
程序逻辑上控制表拆分只需要维护一个数据库访问的配置文件即可，对于开发来说，完全透明，可以不用关心访问的是哪里，而只需要调用通用的接口即可，曾经做过的系统里面，这样的应用经常遇到，尤其在全网passport、社区帖子等方面的处理上应用最多。
原来在yahoo工作和后来mop工作都使用了这样的架构，整体感觉来说还是值得信赖的，单表毕竟存在面对极限数据量的风险。
作者: 9tmd 时间: 2007-1-4 11:39
前 面老是有人问auto_increment的问题，其实这是MySQL官方专门针对M/S的Replication做过的说明，因为MySQL的同步是依 靠同步MySQL的SQL日志来实现的，事实上单向的Master->Slave使用auto_increment是没有问题的，而双向的M/M模 式就会存在问题了，稍微一思考就知道怎么回事了。官方文档：
http://dev.mysql.com/tech-resour ... ql-replication.html
http://dev.mysql.com/doc/refman/ ... auto-increment.html
另 外，在使用MySQL的同步时，需要注意在自己的代码里面，写SQL的时候不要使用MySQL自己提供的类似 NOW()之类的函数，而应该使用php程序里面计算的时间带入SQL语句里面，否则同步的时候也可能导致值不相等，这个道理可以牵涉出另外一些类似的问 题，大家可以考虑一下。
作者: wuexp 时间: 2007-1-5 11:54
QUOTE:
原帖由
nightsailer 于 2007-1-3 17:33 发表
1、可以是垂直划分，
比如依据业务实体切分，比如用户a的blog贴子，用户的tag，用户的评论都 ...
1、可以是垂直划分，
比如依据业务实体切分，比如用户a的blog贴子，用户的tag，用户的评论都 ...
明白业务分表,但是有时候一些基本表会随着数据的增加回变的很大,如果mysql的表达到千万条数据,效率会下降的非常快,对某条记录进行操作会非常容易锁表.
两个m,多个s,之间同步速度会随着降低,反映速度很慢,这需要一些中间件来解决
作者: zhwb36 时间: 2007-1-6 10:45
楼主是个强淫！
作者: laozei 时间: 2007-2-5 15:03
QUOTE:
原帖由
nightsailer 于 2007-1-3 16:35 发表
在闲扯一下，PHP的优化可以有很多，主要的措施：
1、使用FCGI方式，配合lighttpd,Zeus.
我个人比较喜欢Zeus，简单可靠。不过，需要￥￥￥。
lighty也不错，配置文件也很简单，比较清爽。最新的1.5,虽然不稳定 ...
在闲扯一下，PHP的优化可以有很多，主要的措施：
1、使用FCGI方式，配合lighttpd,Zeus.
我个人比较喜欢Zeus，简单可靠。不过，需要￥￥￥。
lighty也不错，配置文件也很简单，比较清爽。最新的1.5,虽然不稳定 ...
我在linux x86_64(AMD,Centos 4.3/4.4)上编译过php4,php5
php4费了很大的劲才编译好
php5装好之后，程序运行不正常，现在还继续用着php4
从探针的探测结果来看,php4在那台机子上的效率好像很差
，不过，网站运行起来好像还可以
试过xcache，那时候还是低版本，网站运行不正常，就没用了，用的是eAccelerator
web server 是lighttpd 1.4.13
作者: leidong8 时间: 2007-2-6 15:14
好!
作者: 深空 时间: 2007-5-15 11:27
上面我想有个问题很严重，就是时间的问题，数据库分布到不同的服务器，NOW()就不同，PHP分布到不同服务器，time()也不同，我想是不是需要一个标准来获取时间。
另外就是auto_increment的问题，我觉得可以通过维护一张包含auto_increment的id表来实现INSERT的id唯一。
扫一扫
321
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
