MySQL在NoSQL的缓存变革

WBOY
WBOYオリジナル
2016-06-07 17:13:24894ブラウズ

我那个时候就在想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年,选不好,自找麻烦自讨苦吃。

linux

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。