非鱼观点 - 互联网观察

程序中用到树形结构的地方有很多，比如自定义文章分类，允许用户无限级添加子分类，比如用户交流的时候的回复，可以对回复进行回复。树形结构可以完全避免让用户的逻辑思维和使用习惯受程序的限制，最大限度的给用户自由，实现对数据的最大利用。

对于以行和列为基础来保存数据的关系形数据库而言，无法直接保存树形的数据，所以必须以其它的方式来实现。

最基本的方式就是保存一个ParentID，显示每条记录的时候去它的下级内容，以递归的形式把树显示出来。这是最简单的逻辑，而且实现起来不复杂，代码写出来也很容易阅读和理解，而且对条目数量也没有任何限制。但是如果每条记录都要执行一下Select，无疑会给数据库造成巨大的压力。即便一次读到数据库里，在内存中一次次的遍历，也会非常浪费CPU资源。

另外一个方式是给每个对象加一个排序字段，让数据在取出来的时候就直接排成按照树形结构的顺序取出来，在显示的时候也无需多次遍历，只要逐条输出就可以，只要根据排序字段和深度来计算它的缩进深度就可以了。

通常的排序字段使用一个简单的字符串即可，比如第一条记录的值为01，第二条为02，第一条的下级内容为0101，0102，依次类推。从数据库中取出的时候，数据库对字符串字段的排序是以字节所代表的值的大小来排的，所以排序之后的顺序就是01/0101/0102/02/0201这个样子。显示的时候这一个值就可以表示出它的上级和它的深度，相当方便。但是这种方式的一个主要坏处是内容的条数受限制，如果每一级用两位数字来表示，那同一级最多就只允许99条内容。用三位就是999条，一旦超出，整个逻辑就被破坏了。所以使用之前需要考虑清楚你所容许的最大条数是多少。（这个字段不止限于数字，同样可以用字母，比如009之后是00A，一直到Z，那么三位所允许的条数限制就是36*36*36，也就是46656条。如果用四位，就达到了168万条，通常这已经足够了。）每层的条目有限制，但是总的层数却是没有限制的，因为可以用nvarchar(max)来保存这个字段，字段长度不限。所以理论上你每一层给它10位也没问题，这样每层的条目限制就成了36的10次方，已经足够多了。

还有一种排序字段是使用数字，比如这篇文章http://www.cnblogs.com/zhuor/archive/2006/08/26/487095.html，但是这篇文章的使用方式有个问题，新的回复会出现在同一级回复的最前面。如果用于回复表，这个显示顺序是很奇怪的。但是让小数不断的除以2，也会受到float的小数点容量限制。

所以，目前我们认为，最好的方式还是使用字符串。

百度很惨，成了过街老鼠，人人喊打。是个报纸就出来揭一下搜索黑幕，是个电视台都站出来摆明立场，逼的老总出来道歉，股价暴跌。

百度所做的事情其实是很自然的，作为一个纯商业公司，利益是第一位的，手段没有错，只是执行力度的问题。好比养猪，一个好的养猪人知道应该在三个月的时候杀才是最大利益，一个差的养猪人却喜欢在两个月的时候杀掉，钱是一样赚的，只是长远与否的问题。

不管怎么骂百度，对它的MP3搜索丝毫没有影响，百度最大的市场在哪里？在网吧。百度最大的用处在哪里？在MP3。这场道德危机被媒体和个人站长过分的夸大了，其实真正受竞价排名伤害的，还是这些出钱做竞价排名的人，而不是搜索这些关键字的人。因为一条搜索记录被不良医院骗一万块钱，发生的概率和波及范围绝对要比电视直销里不怕高空摔的国产名牌全能手机要少很多。

搜索技术文章，我用Google，因为百度其实不怎么懂中文，特别是中英文混合的时候。但是这并不是我骂百度的理由，搜MP3的时候，我必须用百度。当然，百度把竞价排名的搜索结果跟非竞价排名的放在一起，很容易被点到，但是这也不是我骂百度的理由。出钱做竞价排名的网站上满屏的广告比这个厉害多了，毕竟百度还是标出了哪些是推广链接。

就像开源软件，Linux是免费的，所以你要求他按照你习惯把桌面做成跟Windows一样，不好意思，没人理你。Mysql是免费的，所以你想让他们加上Oralce的一些特性，对不起，也不会理你，人家有人家的开发目标，你只有选择用或者不用的权利，没有别的。百度也是免费的，你可以选择用或者不用，但是你不能要求他不放广告，或者少放广告，这与你无关。

现在大家最开心的，百度最担心的，就是因为这个事件影响了百度的竞价排名销售体系，如果ZF这时候插一脚，非得出个什么规定，每个关键字广告条目不能多于三个，那才真的是没有天理了。其实百度大可不必担心，一个愿打一个愿挨的问题。当我想找一个商业的Flash报表控件的时候，我就会去Google搜Flash图表，然后在右边的广告里点一个。因为免费的基本上没几个好用的。当然，如果我要找搬家公司，我是不会去百度搜索搬家公司的，我会打114，而如果我要找家具卖场或者家电评论，用百度也不会带来任何问题。

至于那些自愿去点击了推广链接，而又寄期望于这是家诚信合法的公司，就好像你让出租车司机带你去PJ，而又寄希望于他无私的帮你推荐了一个最漂亮最实惠的店一样，又或者你跑到电脑城让促销人员帮你推荐机器而又指望他是个完全诚信的人一样。这不是脑残吗？你会去信任电线杆子上的治疗性病的小广告吗？不会，那你为什么相信百度上贴的小广告呢？如果电线杆子属于私人企业的话，它们也会被标价贴小广告的。

CCAV曝光百度的非法医院问题，有什么法律依据吗？没有，拿的还是道德的准绳。一个企业以道德为由在13亿人面前骂另一个企业，无非还是因为垄断地位和政府背景。如果阿里妈妈站出来骂百度，即使说的再怎么有道理，也没权利上CCAV吧？再说，中央台的广告有人审核吗？奶粉不是照样做广告，不孕医院不是照样做广告？全能手机不也照样卖？

百度不会因为少卖几个关键字而死掉，百足之虫，死而不僵，中国被人骂着活下来的企业并不少见，橡果国际都没死掉，百度当然更没有理由死掉。只是一个活着的身份而已，伪君子或是真小人，照样活。

劝那些跟风骂百度的人闭嘴吧，这年头，哪个生意人的道德都高尚不到哪里去。

数据库出问题的过程：数据库体积很大，分两个文件，共40多G，没有启动完整日志，用的是简单日志。经过几次非法关机重启，数据库状态被标为可疑，无法使用。为了尽量减少损失，没有采取还原备份的方式，想办法恢复此数据库。按照下面的步骤解决了状态为可疑的问题：

USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO
ALTER DATABASE MyDB SET EMERGENCY
GO
sp_dboption 'MyDB', 'single user', 'true'
GO
DBCC CHECKDB('MyDB','REPAIR_ALLOW_DATA_LOSS')
GO
ALTER DATABASE MyDB SET ONLINE
GO
sp_configure 'allow updates', 0 reconfigure with override
GO
sp_dboption 'MyDB', 'single user', 'false'
GO

数据库可以用了，但是操作系统日志里频繁的出现一些sql server的错误日志，类似于

伺服器: 訊息 7105，層級 22，狀態 6，行 1

text、ntext、或是 image 節點的分頁 (1:62855)，插槽 19 不存在。

这种（原文找不到了，这个是网上找的）。后来对几个大的表进行了单独的dbcc checktable修复操作，显示修复了一些错误，数据库使用起来比较正常了。

为了防止这种意外再次发生，把数据库日志改成了完整。后来发现日志膨胀的速度非常快，到了20G的时候，想收缩一下日志，结果失败。

无论是把日志改为简单，还是执行BACKUP LOG with no_log，再去收缩日志仍然显示可用空间为0，收缩没有任何效果。

最后日志一直增长到60G，正好这个时候换了台新服务器，于是只复制了数据库文件过来，日志文件没有复制过来，再附加，可以自动生成一个新的日志文件（前提是必须在原服务器上分离，直接停止数据库服务是不行的，附加的时候会说数据库没有正常关闭，必须要原来的日志文件才能附加。因为这个，40几G的数据库在两台机器之间拷了两回。）

在这个新的日志增长到6G的时候，再尝试截断后收缩，结果还是说里面的可用空间为0，无法收缩。后来再博客园朋友的提示下，用DBCC UPDATEUSAGE命令修复数据库的行记录数，修复了一些错误，但是还是无法收缩。根据该网友的提示，换了一些英文关键词在Google上搜索，后来找到这样一个函数：DBCC OPENTRAN(dbname)，显示

已复制的事务信息:
最早的分布式 LSN : (0:0:0)
最早的非分布式 LSN : (1051867:2025:1)
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

而在其它正常的数据库上运行这个命令，则没有前面三行东西。那么，问题应该是在这里了。再加上这些关键词，最后，终于找到一个跟我差不多原因的一篇帖子：http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3757111&SiteID=1&pageid=0

这篇文章的最后给出了微软MSDN的一个链接，里面提到了一个命令：sp_removedbreplication。通常如果你设置过数据库复制或发布，而后来设置失败并没有启用，可能会导致这个问题，你看不到跟复制有关的内容，但是在数据库里却存在这样的东西，于是日志被它堵住了，这成了一个永远无法完成的命令，所以后续的日志都无法截断。执行了这个命令以后，强制清除了复制内容。虽然我的数据库从来没有手工设置过复制相关的东西，但是不知道修复数据库的时候改错了什么东西，造成了这样的后果。执行了这个函数以后，再去收缩日志，可用空间变成了99%，成功将日志文件收缩到10M大小。

一个困扰了一个月的问题终于解决了。

中国在恶搞了蜡笔小新之后，又来了一次恶搞奥特曼。金甲战士的造型说不是抄袭奥特曼的话，连村头的二傻子也不会相信。但是，很容易的可以看出，这部片子在恶搞之余，真正的目的，也不过是为了钱。

片子的拍摄成本很低。为了降低拍摄成本，一切都趋于简化，尽最大努力减少道具成本，而大量的使用电脑技术来补充。但是真正的电脑特效一点也不比制作道具便宜，所以，本片不得不使用最最简单的电脑技术，画出来的卡通人物，基本上连七巧板的过场动画都不如。另外，把超级英雄做成跟真人一样大小，也省却了搭建迷你城市模型的工作，所有的战斗场面，都是在公园里拍的，两个人拍拍姿势，用电脑加点闪光上去，就OK了。

而跟成本最小化相对应的，就是想办法把利益最大化。片子里所有使用到的道具和模型，包括服装，刀剑，还是飞机，全部使用最最简单易行的造型来实现，毫无质感可言，很明显，这样最有利于市场化，而且市场化的成本也很低。当然了，越是精致的玩具越容易卖的贵，但是买的人少的话，可能会有亏本的危险，而现在这样就不会，就算卖不出去，也亏不了多少。如果能借点奥特曼的东风卖上一些，那就大赚特赚了。

中国的动画片工作者，已经愚昧到只能靠抄袭人家几十年前的东西来混口饭吃了。而国家又用法律手段禁止在黄金时段播放国外动画片，小孩子在9点钟睡觉之前都不可能看到一部好的动画片，只能看一些低幼的东西，长此以往，一定会大大影响我们下一代的想像力和创造力，而抄袭事件本身，又会严重影响他们的道德观和价值观，这样的幼儿教育，如何保证我们的未来？

这个周末做了件很久之前就应该做的事，给公司换了台新服务器。

这台新的服务器目前是两个4核CPU+8G内存+5个140G SAS硬盘，虽然CPU的频率不如原来那台（现在的只有2.4G，原来的是3G的），但是速度确实是高了很多，毕竟多了四个核心，CPU占用率低了下来。而且主要是内存的增加效果比较大，最新的Windows 2008配合8G内存，Sql Server启用了AWE内存管理模式，一启动起来就占用了93%的系统内存，但是系统反应那不是一般的快啊。缓存还是最有效的方式。

换下来的那台旧服务器配置也不差，两个双核3G至强，4G内存，4个硬盘（两个72G两个140G，因为不是一起买的），这么好的机器可不能浪费了。正好最近公司对网站内容的全文检索有了更高的要求，而且研究了一阵子Apache solr，于是把这台服务器装上CentOS5.2，作为三个网站的搜索服务器来使用。虽然三个搜索可以放在同一个Tomcat下，但是这样会导致重新配置的时候需要将三个站点一起重启，不利于管理。反正内存多，于是放了三套Tomcat（需要改Server.xml里面的端口）。

目前来看，效果非常不错，搜索的速度快了很多，建索引的速度也快了很多。

另外，WEB服务器上发邮件使用Windows下的邮件服务器软件，这个东西很容易死掉，最近每两三天就会死掉一次。一旦死掉，新用户注册的时候发激活邮件就会出问题，用户无法激活。前天坏了一个晚上，700多注册用户无一激活，结果第二天不得不打电话到客服求助。于是想趁这个机会把邮件也换到Linux下。卸载了系统自带的Sendmail，装上postfix。写了个页面测试用这台机器来发激活邮件，哇，果然是好快的速度了。postfix不愧是以速度著称的邮件系统。速度是其次的，最重要的是它的稳定。我相信它不会像md**一样那么容易死。

这台服务器目前只利用了不到四分这一的资源，以后还可以把svn代码服务器移到这上面来，也可以给它装个squid做前端代理，还可以装个memcache，来缓存部分数据表，解决一些windows下做不到的事。

公司的网站的搜索一直是使用DotLucene做的，不过一直有很多问题。比如，生成索引的速度太慢，所以不能经常的去生成索引，索引里面坏的东西太多的时候，重新生成索引基本上会失败，因为索引文件被网站进程占用，所以无法删除。没有做搜索服务，而是每个页面去打开索引目录，搜索，然后关闭，导致重复的开关动作浪费极多的CPU，而且占用相当多的内存，无法释放。而且复杂一些查询（比如范围查询，时间查询，分组统计等）因为写法比较复杂，所以根本就没有去做。关键字高亮显示也因为性能和算法问题一直没有做。自己的个人网站上，搜索用的也是PyLucene，情况差不多。

最近在查找更好的搜索引擎供应商的过程中，发现了一个好东西，Apache solr，是由Apache组织基于Lucene所做的扩展应用，详细的介绍网上有不少，就不多说了，大体来说，solr是一个基于Java服务器的服务程序，就像WebService，它自己维护索引，进行查询动作，其它需要使用全文检索功能的程序通过Post和Get的方式使用这个服务，查询命令直接返回结果XML。通过在xml配置文件里面定义字段类型和字段名字，就可以让它支持任意需要的字段数量和类型，而且能够正确处理数值类型的排序和时间类型的范围查询。而且可以通过传递查询参数简单的实现分组统计和高亮显示。

不过因为它是java的，而我又没玩过Java程序，安装和配置着实是花了不少功夫，用了整整一天，把网上那么几篇说明文章看了又看，最后终于算是搞定了。因为几遍文章写的都不全，需要凑合成一篇看才行。所以在这里记一下标准的安装配置流程：（Linux上的）