大型网站优化三部曲

　　当一篇博文发布的时候并插入标签的时候一般是三步走(也 可以理解为四步，以为还要判断标签是否存在的问题)，第一步插入文章数据库并获取文章的ID，第二步插入标签数据库同时查询标签是否存在，如果存在就取出 标签的ID，否则的话插入新标签并取出ID，第三部，将文章的ID和标签的ID插入索引表来建立关联。如果这个时候在索引表上建立了索引的话就是灾难性 的，特别是在数据量大的情况下，尽管它可以有效的提高查询速度，但是发布的速度可能就会让人无法忍受了。

　　我们处理的方法也是三部曲，对多对多关系进行进一步的处理。

　　用标签的时候，我们用的最多的就是查询标签下的文章和显示文章的标签，所以我们实现这例就成了。

　　第一步，抛弃索引表。

　　对文章做冗余字段，加一个TAG列，我们可以讲TAG的标签如下写[TagID,TagName]| [TagID,TagName]| [TagID,TagName] 同样 对于TAG表，我们做如下冗余加个Article字段，如下内容[ArticleID,Title]| [ArticleID, Title]| [ArticleID, Title],在需要增加的时候我们只要APPEND一下就可以了，至于ARTICLE的结构和TAG的结构可以参考我上一篇文章的介绍。其实根据需要还 可以存贮更多。

　　有人会问，为什么要存贮TagName和ArticleTitle呢，其实是为了避免跨表查询和INNERJOIN查询来做的，In查询和跨表查询会造成全表遍历，所以我们在执行的时候In查询是必须要找到一个有效的替代方法的。

　　第二部：异步加载。

　　在设计模式下我们常思考的是单件模式，我们采用另类的单件模式来处理，也就是把文章和标签之间的索引作为专门的进程来做，异步的实现。

　　为了避免文章在发布的时候以为要检查TAG表而造成的线程拥堵，我们需要采取延迟加载的方案来做。服务器应该维护一个进程专业的对标签和文章地段的查询和索引，我们在发布文章的时候应该把标签同步这一块托管给另外的一个程序进行处理，并进行索引。

　　第三部：标签缓存索引：

　　对于频繁的判断标签去或者热门的标签我们还可以组织一套有效的索引，比如对于标签“疯狂代码”和”傲博知识库”,我们用树来把它表示出来。对于 疯狂代码我们索引一个疯,其实用程序表达就是疯狂代码[0]，同样傲博知识库就是傲博知识库[0]。而在数组”疯”中存贮以疯开头的标签组，以”傲”的数 组中存贮以”傲”开头的标签。如果量更大的话还可以再做二级索引。

　　这涉及另外一个话题了就是分词，上面是一个简单的分词方案，大家在进行GOOGLE搜索的时候应该很输入它的Suggest方法吧，就是这个道理。最终讲标签有效的索引，并提取热门的作为一个全局静态变量，我们就可以绕过数据查询这一关，对第二部的单件模式又是一个进化。

　　以上是对多对多关系的一个简单的架构说明，肯定有人会问，如果这样做的话工作量不是太大了吗，分词处理什么的，对每个多对多关系进行处理。

　　OK，咱们可以进一步的把它来抽象化，我们用TableA 表示Article表，用TagbleT表示Tag表，我们可以讲字段抽象化出来，也就是一个ID,一个Tag的String 同理对于标签表也是如此。朋友们应该可以理解我的意思了。

　　对，就是做个代码生成器把对应的多对多关系给生成出来，这个很好写的，几个Append就可以搞定。如果想更方便的处理，那么把这个东西做成单件的模式抽象化出来，然后再违反一下原则，做成基类，其他关系继承这个基类。。。。。剩下的应该很简单了，具体实现大家思考吧。