作者文章: Fenng

PHP 中执行排序与 MySQL 中排序

此文首发在 InfoQ 中文站作者:明灵(dragon) , Fenng . Note:要转载的朋友请注意注明这篇文章的第一作者!
这篇文章是dragon 朋友来邮探讨后他做的一个总结。在 DB 中排序还是在 应用程序中排序是个很有趣的话题,dragon 第一份邮件中其实已经总结的很好了,我添加了一点建议而已。现在放上来,与大家共享。这篇文章也投稿到了 InfoQ 中文站

Q:列出在 PHP 中执行排序要优于在 MYSQL 中排序的原因?给一些必须在MYSQL中排序的实例?

A:通常来说,执行效率需要考虑 CPU、内存和硬盘等的负载情况,假定 MYSQL 服务器和 PHP 的服务器都已经按照最适合的方式来配置,那么系统的可伸缩性(Scalability)和用户感知性能(User-perceived Performance)是我们追求的主要目标。在实际运行中,MYSQL 中数据往往以 HASH tables、BTREE 等方式存贮于内存,操作速度很快;同时 INDEX 已经进行了一些预排序;很多应用中,MYSQL 排序是首选。而在应用层(PHP)中排序,也必然在内存中进行,与 MYSQL 相比具有如下优势:

  • 1、 考虑整个网站的可伸缩性和整体性能,在应用层(PHP)中排序明显会降低数据库的负载,从而提升整个网站的扩展能力。而数据库的排序,实际上成本是非常高的,消耗内存、CPU,如果并发的排序很多,DB 很容易到瓶颈。
  • 2、 如果在应用层(PHP)和MYSQL之间还存在数据中间层,合理利用,PHP会有更好的收益。
  • 3、 PHP在内存中的数据结构专门针对具体应用来设计,比数据库更为简洁、高效;
  • 4、 PHP不用考虑数据灾难恢复问题,可以减少这部分的操作损耗;
  • 5、 PHP不存在表的锁定问题;
  • 6、 MYSQL中排序,请求和结果返回还需要通过网络连接来进行,而PHP中排序之后就可以直接返回了,减少了网络IO。

至于执行速度,差异应该不会很大,除非应用设计有问题,造成大量不必要的网络IO。另外,应用层要注意PHP 的 Cache 设置,如果超出会报告内部错误;此时要根据应用做好评估,或者调整Cache。具体选择,将取决于具体的应用。

列出一些 PHP 中执行排序更优的情况:

  • 1、 数据源不在 MYSQL 中,存在硬盘、内存或者来自网络的请求等;
  • 2、 数据存在 MYSQL 中,量不大,而且没有相应的索引,此时把数据取出来用PHP排序更快;
  • 3、 数据源来自于多个 MYSQL 服务器,此时从多个 MYSQL 中取出数据,然后在PHP中排序更快;
  • 4、 除了 MYSQL 之外,存在其他数据源,比如硬盘、内存或者来自网络的请求等,此时不适合把这些数据存入 MYSQL 后再排序;

列出一些必须在 MYSQL 中排序的实例:

  • 1、 MYSQL 中已经存在这个排序的索引;
  • 2、 MYSQL 中数据量较大,而结果集需要其中很小的一个子集;比如 1000000 行数据,取TOP 10;
  • 3、 对于一次排序、多次调用的情况,比如统计聚合的情形,可以提供给不同的服务使用,那么在 MYSQL 中排序是首选的。另外,对于数据深度挖掘,通常做法是在应用层做完排序等复杂操作,把结果存入MYSQL即可,便于多次使用。
  • 4、 不论数据源来自哪里,当数据量大到一定的规模后,由于占用内存/Cache 的关系,不再适合 PHP 中排序了;此时把数据复制、导入或者存在 MYSQL ,并用 INDEX 优化,是优于 PHP 的。不过,用 Java,甚至 C++ 来处理这类操作会更好。 [有些类似大数据集聚合或者汇总的数据,在客户端排序得不偿失。当然,也有用类似搜索引擎的思路来解决类似应用的情况。]

从网站整体考虑,就必须加入人力和成本的考虑。假如网站规模和负载较小,而人力有限(人数和能力都可能有限),此时在应用层(PHP)做排序要做不少开发和调试工作,耗费时间,得不偿失;不如在 DB 中处理,简单快速。对于大规模的网站,电力、服务器的费用很高,在系统架构上精打细算,可以节约大量的费用,是公司持续发展之必要;此时如果能在应用层(PHP) 进行排序并满足业务需求,尽量在应用层进行。

EOF

《构建可扩展的 Web 站点》读后随感

building_scalable_web_sites.jpg对于构建 Web 站点,《构建可扩展的 Web 站点》重点并不是讲述 How-To 的 — 讲述 How-To 的书已经很多了,却很少有图书愿意分一部分篇幅讲述 Why 。所以有的人可能认为”缺少细节”,有的人则读罢大呼过瘾。我一般的建议是,如果你觉得这本书没劲,那就再读一下第二遍。

为什么我推荐这本书? 主要的原因是这本书给出了可扩展站点的必备要素,而书的内容几乎全是作者在 Flickr 站点实战中得来的经验谈,如果您的站点是个发展中的 Web 2.0 站点,你可以认为这本书是个技术”标本”。如果回顾一下我的 Blog 的话,会发现多则关于 Flickr 的技术话题:

当然,这些这些都是皮毛。

如果你正在为你的网站性能问题而苦恼,那么建议直接去读第八章,这一章也是让很多人觉得有价值的章节,因为讲的是”瓶颈”(可见如何解决网站性能瓶颈是个多么普遍的话题啊)。如果严格的来说,这一章的内容并非有多么深入,但对于需要对网站性能瓶颈建立全局概览的朋友来说,足够了。毕竟我们看书不是挑刺,解决自己的问题是首先要考虑的问题。

对我来说,第九章也让我收获良多。第四层负载均衡和第七层负载均衡的差别,什么时候合适用第四层均衡,什么时候用第七层均衡,如何构建一个第七层负载均衡网络… 这些看似都是基础的问题,但实践中是需要仔细平衡的一个事儿。并非想象的那么简单。

如果 Cal Henderson 能有下一部书的写作计划,我倒是希望能看到设计可扩展的 Web 2.0 站点的主题,当然,可能我们看不到了,因为,Flickr 被 Yahoo! 收购后似乎缺失了进取心,谁知道 Cal 会不会跳槽而走呢?

PS: 这也是我认为”Web 2.0 网站架构不可或缺的图书“清单中的一本。

EOF

抛弃洁癖

同事闲聊突然想到的。他 “在Slackware , Arch 与 Ubuntu 之间徘徊…以前一直用 Slackware, 有点洁癖”,我给的建议是”抛弃洁癖”,直接用 Ubuntu 好了。

类似的极致是这样的:用 Mac 笔记本,安装个 Windows ,Windows 上安装一套主题,模拟出苹果的界面 …

洁癖,或者说是强迫症,会害死人。温瑞安小说中有个人物,叫做”神捕”刘独峰,这个人最后的死因居然是因为自己的洁癖 — 衣服脏了而丧失战斗力。

其实工作生活中经常遇到类似的场景,非要所有东西都”对了自己心思”后才能把事情做好。比如用电脑就用 Mac ,MP3 就用 iPod ,迷恋某个品牌不能自拔,其实在苹果之外也有很多精彩的东西。又如技术人员对某个编程语言的痴迷,迷 Python 的就鄙视 Ruby ,迷 Ruby 更不屑微软的技术线…

有些洁癖或者说是”偏执”,到了最后往往容易让人忽略了事物的本身目的。比如有些朋友用 Linux 做共作工作用操作系统,把大量的时间用在了”定制”桌面这个事情上,而忽视了他本来是”使用”操作系统这个事情。

作为一个技术人员,口味还是要放开一些,始终迷恋于一个东西,总会营养不良不是? 而一些不会带来实质性提升的洁癖,还是扔掉吧!

EOF

闲言碎语,很为偏颇

2e3587f6

此文作者:, 位于 Geek 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

《高性能网站建设指南》读后随感

High_performance_web_sites.jpg对于前端优化技术,我之前根据已经从 14 条增加到 34 条的 Exceptional Performance 做了一份笔记:

这些最佳实践看似没什么艰深的技术含量,而网络上也能看到很多关于网络前端优化的文章,但是实际上我发现能操作、执行下去的网站还是不多,更多的时候,大家把类似的信息当成参考信息而已,看过,丢掉,如此而已。Web 前端优化的时间准则有些其实也算是常识。我曾经听到过某家大型网站的案例:用户反映网站速度慢,进行了多次技术会议,多个方案评估之后,”发现”是图片拖慢了整个网站,于是,大家的意见统一了,建设更多的 CDN … 可实际上,这个问题或许不需要过多的投入研究,简单的分析一下页面元素比例就知道了。

这本《高性能网站建设指南》的内容以最初的 14 条优化准则写的,精炼简洁(几个小时就能读完),我觉得已经抓住了前端优化的至少 80% 的内容,加上书中的一些引申内容(尤其是涉及到的 RFC),如果这些都能做好,那么已经能够解决绝大部分问题了。所以是绝对值得网站运维人员一读。而且,我也认为这是 Web 2.0 网站架构不可或缺的图书 之一。

另外,发现博文视点的这一批 O’Reilly 的图书都是有索引的,很难得。

EOF

链接:购买《高性能网站建设指南》