在公司近几年,遇到过的重大BUG都是因为数据库使用不当而导致的,所以说数据库的使用演变左右了整个技术架构,未来想做好一个优秀的程序员,学习数据库是必不可少的。
涉及的东西希望不要透露公司机密。
第一阶段:
刚进公司的时候,数据库已经很前瞻性的使用了sharding.采用了分库,分表的拆分方法。根据产品功能类别进行了数据库的拆分，根据用户的编号进行了分表拆分.从设计上来说,当初的设计也是能够满足日后数据膨胀需求的.几个明显的特点就是:
1:没有使用主从配置配置
2:Sql的使用不是很合理,不过由于数据量和访问不大,再加上具有数据cache,问题不是很严重.
3:虽然采用分库,分表策略。但是类似于文章内容这样的大字段没有进行合理的拆分，导致日后数据量的无限庞大.这已经是拆分策略无法解决的问题.
当时一旦遇到负载的问题,就是导数据-扩库.经常晚上发布公告,进行数据的的导出.其实导的策略非常不好,用户运气极坏的情况下,可能会出现二篇相同编号的文章.
第二阶段:静态化
2007年后,博客的访问量和数据容量越来越大,必然要在架构上进行重构了,也诞生了静态化项目.这是我第一次真正学习的一段过程.不过从数据库上来说,静态化项目中真正具有进步意义的是数据库辅库的使用.在后续中我们必然看到其存在的一些列问题.
1)延迟问题,导致核心应用不能完全读取副库,当时DBA还居然禁止了主库的读取操作(是个悲剧),愿望和结果总是那么的残酷.
2)应用架构只有同数据库的使用紧密结合,才能充分发挥数据库的作用,也必然会解决一些隐藏的问题.
第三阶段:博客V4阶段
在2007年,博客产品真正走向了全面交互的产品状态,诞生了很多非常不错的功能和技术,包括访客,点击数.主要的特点就是:
1:过度依赖前端的RIA渲染.
2:nginx+memcached+mysql,nginx+memcachedb大量使用
虽然上述的演变和数据库没有多大的关系.但也给了我们一个思路:除了数据库我们还可以使用其它的.比较有趣的是,上述二点也正是我们大力进行改造的.
所以不同时期的技术演变都是有其历史原因的,反过来想,目前做的技术改造难道一定是正确的吗?所以思路要更广一点,站得高才能看的远.
那个时刻我特别想批评一个观点就是:做的酷的未必就是好的.有些就不说了...
第四阶段:博客V5阶段
这是一个具有特殊意义的阶段,简单的来说就是博主管理的功能和页面直接查询后端数据库,无任何Cache,到目前来说,我还是觉得从另外一个方面来说,这是个不错的设计,简单但有效.但从后面的发展来看,还是有一些问题:
1:过渡依赖数据库,尤其对博主来说.访问的页面速度也许确实上不去.
2:过度依赖数据库,博客就像一个脆弱的孩子,说不好就会倒下去.
从那时候开始我就在想,数据库目前的状况是什么样的,数据库的容量规划是什么样的,数据库能支撑多大的查询.
第五阶段:混乱的时代
由于技术原因和时代混乱原因.在数据库的使用上缺乏规划,有些决定太草率了,亲历了几个痛苦的阶段.上下篇的改造导致整个数据库垮掉,定制化的功能开发后导致后端更新数据库过多,评论数据库由于加精功能的原因,延迟高的离谱.在这里想说的是:
1:我情愿相信一个技术不强的人,也不愿相信那些根本只会在上面忽悠的人(因为不是执行者，不了解实际情况).
2:技术人员不完全是实现者,要注意长期发展,只有把产品当孩子才能更好的关注,发展.
3:从理论上来说,只有关注数据库索引的优化,80%的问题都能解决.
第六阶段:博客V7阶段
V7是最成功的一个阶段,没有大量的投诉,在数据库上也进行了大刀阔斧的改造.
1:虽然文章内容没有物理剥离,但博文列表库的建立(强制将副库的大字段格式化为int字段,表扬下我们的DBA).
2:根据应用路由不同的数据库,这些数据库的区别至于索引不一样.
3:应用的改造,仅仅在纠正以前犯的错.
4:字段萃取的使用,避免了以前经常扩字段的困惑.
在这个阶段,我们思考了很多,数据库应该干什么,数据库如何同产品功能合作,数据库如何进行真正意义上的扩展,数据库如何同应用架构合作,开发工程师如何和DBA合作,如何监控数据库。其实并不难,期待我们的下一阶段.