MySQL在NoSQL的缓存变革

我那个时候就在想MySQL迟早要兼容一组key：value接口，果然不久就看到MySQL支持了Memcached 接口，此物一处，多少中间方案消亡啊

MySQL这个互联网生出来的数据库被无数个网站、游戏等使用，据说google、tencent、taobao都在使用它，在互联网高速发展的过程中，由于高速缓存的需要以及传统数据库难于应付巨量写，于是各种NoSQL方案都出来了，最经典就是Memcached，以及后来出现的redis，由于Memcached本身是不支持持久化的，但实际需求却可能是需要持久化的，面对数据的持久化和缓存化，各种组合方案也出来了，redis就支持了持久化，sina的朋友通过Memcached+berkeleydb做了个Memcachedb，也有通过MySQL+Memcached的，通过手工方式更新毕竟太麻烦，后来又有MySQL+udf更新Memcached，再后来出现了神器MySQL+handler socket，据说能达到80w qps，震惊业界，我那个时候就在想MySQL迟早要兼容一组key：value接口，果然不久就看到MySQL支持了Memcached 接口，此物一处，多少中间方案消亡啊，之前需要高手才能玩的MySQL + Memcached，在集成Memcached的MySQL面前再没存在的必要了，不过暂时这东西还是在实验版，我试了下果然效率还不高，期待它早日正式发布。

MongoDB也算是各种NoSQL下的一个怪胎，前一个项目我竟然被逼用了一下，从使用的感觉来看我不看好它，优点是有一些的，就是读写速度都还可以，不过也就是比MySQL略快点，个人以为肯定比不过提供Memcached接口的MySQL，缺点倒是有很多，那玩意太耗空间了，伤不起啊，我起初用1.8后来换2.0耗费空间更大了，差不多相当于MySQL存储的10倍吧，实际上如果使用索引则占用的空间剧增，另外就是那种json的查询语法实在是太怪异了，要适应还真需要一点时间，另外那个_id也很不爽，24个字节，作为字符串和作为OID的时候还不一样，很容易用错，对大多数应用来说，如果将MongoDB当作MySQL那么用，那么我奉劝你别玩了，伤不起啊。虽然这东西看上去很火爆，也有一些尝鲜的用户在用，但到现在为止依然没有很有震撼力的应用，我觉得在传统数据库的各种变革之下，MongoDB的一些曾经的优点已经再没优势甚至已变成劣势，MongoDB很可能只是昙花一现的产品，也或许它能生存很久，但终归摆脱不了小众的命运，选择者慎之。

互联网时代，各种新技术新方案层出不穷的年代，选择是需要大智慧的，，选得好，滋润2-3年，选不好，自找麻烦自讨苦吃。