缓存数据库杂谈

        最近研究一下大数据的问题,比如一个表CURD的频率是非常高的,然后记录是以千万条来计算,咱先不考虑里面字段是什么情况,就单指这个问题,我想如果只用普通的处理方式很难解决问题.

       马上会有人说YII的AR效率非常高,这些神马的一下子就搞定了,说实在的最近在AR里面泡了2周多,CActiveRecord类也全部追踪了一遍,各种论坛帖子逛了逛,不得不说AR的好评那是4.9星级啊.首先我不否认AR的表对象模型这些构思非常不错,而且他提供的属性,方法我也十分膜拜,只可惜了一点,PHP的好基友mysql不给力,mysql的联合查询还真是一个痛,第一点AR不能直接返回数据,第二点他虽然高性能的组合SQL但是改变不了基友的短处,再说说面向对象的理念而言,数据库在我眼里只能3个功能,第一个存,第二个取,第三个改!实在要把这个对象再分划成无数个表对象你才觉得这样才面向对象,更让业务逻辑清晰化,我个人觉得意义不大,咱也不过多的讨论他的好与坏,这个问题我和同事整了几天都不了了之!只能说见人见智,一切按喜好来.

     绕了一圈才回到主题,我们回到了神器缓存这里了,对于刚才所说的那张表要怎么样进行缓存呢,有按条件缓存啊,sql缓存等等很多方式,但其实这些都是按一定的识别去处理而已,不可否认这可以大大减轻了数据库的压力,但是这只是一个治标不治本的办法,只是因为你的业务需求没扩散所以你满足了!如果你现在面对的是一个产品表,里面有很多用户发布了上亿的产品信息,很多用户正在观赏,修补,新增产品,同时前面又有无数游客在那里看看产品信息,顺顺产品列表,那我估计数据库挂掉的概率那就很不低了.

    那接下来怎么玩呢,突然想起前面提过的大神说过,什么都丢给数据库做的PHPer是草根,那么我们为了不做草根,一次性把table全部拿出来放入缓存,接下来我们把search_user的数组塞满,这样我们就满足了用户观赏自己产品的爱好了,那么修改和新增,删除呢,目前逻辑删除大家都不需要再过多解释了吧,那么只剩下修改和新增了,首先能有这个能力的一定会给我一个东西叫userid,那么我们是不是可以找到对应缓存修改或者追加了呢？那么我们是不是还可以把这些修改啊,追加的SQL也缓存起来放在那里呢,然后写一个定时器,好好的利用一下JAVA来个多线程,然后我们就从数据库脱离了,马上大家就会想起前台怎么办,那我能告诉你你也可以再来一个search然后进行同样的处理,只不过个人觉得再来一个search是应该的,但是这还做同步处理的话,这就有点过了,你可以让定时器1小时执行一次,然后索引就更新了,前台的东西没必要更新那么即时吧,理由嘛需要审核啊什么的我想大家都懂啦!

     最后提醒一下,对于数据库而已自动建立好索引,不管你堆积多少记录都不会很慢的,但是你这里删除一条给它段一下那里在补一刀的话我就不多说了.只要有删除的地方记得让他变成修改,堆积多了来个压缩处理就得了,别没事手痒!以上所说个人观点,仅供参考,思路和构架已打好但是我自己也还没实现。。。