新版博客的全面革新，来源于一支强有力的技术开发团队，在此次开发中，首要目标是完成产品更个性化的需求。开发理念则是坚持简单，稳定。最核心的则是加速。从各个细节去提高各个环节的处理速度。
数据库:
在此次改造前期博客的文章数据库处理能力已经严重不足，而产品在新版中对文章的萃取功能越来越多，所以这次数据库做了较大幅度的改造。博客的数据库物理是采用分库/分表的模式进行物理分离，有效的解决了横向扩展的问题，但由于文章表结构本身比较复杂(包含了所有的应用信息)，再加上博客大量的用户数据，数据库物理文件已经很大，再加上大量的请求，处理能力已经严重不足。假如要从根本上解决这些问题，可能要改变目前的数据库应用模式，为了保证开发进度，根据应用特点进行了三个'取巧'的优化:
一、文章状态属性的无限扩展
文章萃取的需求，导致文章有更多的辅助属性，比如这篇文章是否有图片，这篇文章是否是wap发表的，以前的做法是新增字段来存储属性，这样做最大的坏处就是文章库结构越来越'恶心'，且无法满足日后的一些扩展需求，更坏的是索引无法有效使用。所以本次设计了一个综合字段，用位的概念来代表文章的辅助属性。比如0001代表加密文章，0010代表wap文章，则0001和0010位与的值代表这篇文章既是加密文章也是wap文章。
二、文章大字段的剥离
以前文章库/表包含所有的文章信息，所以不管是什么应用，都要求数据库管理系统大量的进行i/o操作，带来了极大的负载，那么如何去拆分表结构呢?运维同事借鉴了数据库复制功能，便向的实现了大字段的剥离，更巧妙的不需要应用开发做过多的调整，具体的做法是在某些副库中强制将大字段的类型置为整形。这样在复制的过程中，大字段的内容被置为0。变向的实现了一组小字段的副库。
三、应用查询的拆分
传统做的比较多的是数据库物理的拆分，其实应用使用也可以进行拆分，主要是根据索引的使用进行副库拆分，某些副库可能就是大量查询文章列表，某些副库是查询单篇文章，而区别就是这些副库的索引不一样，这些库的存储引擎不一样，这些库的数量不一样，
数据库:
在此次改造前期博客的文章数据库处理能力已经严重不足，而产品在新版中对文章的萃取功能越来越多，所以这次数据库做了较大幅度的改造。博客的数据库物理是采用分库/分表的模式进行物理分离，有效的解决了横向扩展的问题，但由于文章表结构本身比较复杂(包含了所有的应用信息)，再加上博客大量的用户数据，数据库物理文件已经很大，再加上大量的请求，处理能力已经严重不足。假如要从根本上解决这些问题，可能要改变目前的数据库应用模式，为了保证开发进度，根据应用特点进行了三个'取巧'的优化:
一、文章状态属性的无限扩展
文章萃取的需求，导致文章有更多的辅助属性，比如这篇文章是否有图片，这篇文章是否是wap发表的，以前的做法是新增字段来存储属性，这样做最大的坏处就是文章库结构越来越'恶心'，且无法满足日后的一些扩展需求，更坏的是索引无法有效使用。所以本次设计了一个综合字段，用位的概念来代表文章的辅助属性。比如0001代表加密文章，0010代表wap文章，则0001和0010位与的值代表这篇文章既是加密文章也是wap文章。
二、文章大字段的剥离
以前文章库/表包含所有的文章信息，所以不管是什么应用，都要求数据库管理系统大量的进行i/o操作，带来了极大的负载，那么如何去拆分表结构呢?运维同事借鉴了数据库复制功能，便向的实现了大字段的剥离，更巧妙的不需要应用开发做过多的调整，具体的做法是在某些副库中强制将大字段的类型置为整形。这样在复制的过程中，大字段的内容被置为0。变向的实现了一组小字段的副库。
三、应用查询的拆分
传统做的比较多的是数据库物理的拆分，其实应用使用也可以进行拆分，主要是根据索引的使用进行副库拆分，某些副库可能就是大量查询文章列表，某些副库是查询单篇文章，而区别就是这些副库的索引不一样，这些库的存储引擎不一样，这些库的数量不一样，