NOSQL与关系型数据库mysql的将来

业界一直有很多的声音，呼吁着关系型数据库正在加速消亡，事实并非如此，MYSQL还活的好好地，而且mysql的创始人还跑出去自创了MariaDB，也是关系型数据库。放眼望去，大的机构都在从IOE向MYSQL平台迁移，这到底是闹哪样？ 其实用脑子想想也能明白了，主要的应用决定了你的数据库，你是干什么的，就用什么类型的工具，比如你是厨师，总部可能用锄头吧，你是耕地的农民，不可能用菜刀耕地吧。这是个基本道理，有时候我们就是太激动。 思维能够从NOSQL马上就跳到HADOOP再跳到大数据了，跨度可真大。。。。

        有的时候我们的态度其实是把NoSQL数据库作为关系数据库在某些方面（性能，扩展）的一个弥补，单从功能上讲，NoSQL的几乎所有的功能，在关系数据库上都能够满足，所以选择NoSQL的原因并不在功能上。所以，一般很多公司都会把NoSQL和关系数据库进行结合使用，各取所长，需要使用关系特性的时候我们使用关系数据库，需要使用NoSQL特性的时候我们使用NoSQL数据库，各得其所。很多国内的大公司正是如此。

        不得不提的一点就是国外对于MYSQL已经有普遍的迁移意思了，因为MYSQL被ORACLE收购后更加更加封闭了，Oracle 对于 MySQL 的日趋封闭和缓慢的安全更新，各大linux发行版也纷纷宣布将从MySQL 迁至 MariaDB 。 MariaDB 是一个采用 Maria 存储引擎的 MySQL 分支版本，是由原来 MySQL 的作者 Michael Widenius 创办的公司所开发的免费开源的数据库服务器，其实2010后国外对于MYSQL已经有了隔阂，主因还在于ORACLE的封闭与更新缓慢。      

        openSUSE 12.3，前卫的滚动发行版 Arch Linux 、老牌发行版 Slackware Linux 的开发者也宣布将迁移至 MariaDB，Fedora Project 依然按部就班的计划在今年夏季的 Fedora 19 中换用 MariaDB。现有 mysql 软件包将被全部重命名为 MySQL （注意区分大小写），MariaDB 将成为依赖软件的默认选择。Fedora 并不打算支持同时安装 MySQL 和 MariaDB，必须两者择一。

        我在想一个问题，最近的什么架构师会上，很多公司都在讲述自己如何的大规模部署MYSQL集群，如何的高效率运维等等，这下有意思了，是不是下一阶段的主要工作就是迁移到MariaDB了？ 因为国外业界的联合行动，也同时会导致MYSQL的后续支持越来越弱，假如到了无法忍受的地步，难道还要自己去改MYSQL底层代码吗？ 连MYSQL的父亲Michael Widenius都觉得ORACLE继续发展开源的MYSQL不靠谱。在改MYSQL底层代码与MariaDB之间，which one to choose？

       这样看下来，NOSQL主要有以下几点用途

1、关系型数据库的弥补品。

2、作为缓存服务器替代MEMCACHE 。

3、类似于 REDIS这种NOSQL数据库都被用在缓存里。  如新浪微博、赶集网等。

把NoSQL当作Cache使用的模式，在很多大数据量、有热点、以及查询非热点数据、消耗资源较多的场景下较有用。

4、NOSQL与MYSQL结合，NOSQL作为主数据源，MYSQL为辅 。

 

NoSQL数据库根据数据的存储模型和特点分为很多种类：

 

现在看来以Hbase这类搞LOG分析的，MongoDB这类搞文档存储、MEMCACHE这类搞缓存等等。

 

类型	部分代表	特点
列存储	Hbase Cassandra Hypertable	顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。
文档存储	MongoDB CouchDB	文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有有机会对某些字段建立索引，实现关系数据库的某些功能。
key-value存储	MemcacheDB Tokyo Cabinet / Tyrant Berkeley DB Redis	可以通过key快速查询到其value。一般来说，存储不管value的格式，照单全收。（Redis包含了其他功能）
图存储	Neo4J FlockDB	图形关系的最佳存储。使用传统关系数据库来解决的话性能低下，而且设计使用不方便。
对象存储	db4o Versant	通过类似面向对象语言的语法操作数据库，通过对象的方式存取数据。
xml数据库	Berkeley DB XML BaseX	高效的存储XML数据，并支持XML的内部查询语法，比如XQuery,Xpath。

 

我们看微博上面的数据，比如评论，比如LIKE这类，就会比较好的用到NOSQL.

有一篇文章叫做nosql轻松打造千万级数据量的微博系统。 即是使用 MYSQL+NOSQL这两种混合（我上面提到的弥补品）。

我没有做过微博方面的开发工作，因此只是以此作为例子借鉴，用来说明白说清楚 NOSQL是可以干什么，怎么去干的问题。

可以先参考一下 Retwis, Retwis是用纯redis实现的简单微博.

微博的明星会员问题的处理，比如有千万百万粉丝的订阅者，发一条微博信息,那得一下子把微博 信息发布到几百万的粉丝里去 。所以这时消息队列上场了。在架构里 有一个异步publish集群,publish的任务都去zeromq队列读取队列.zeromq是目前已知开源的消息传递最快的一个。具体关于 zeromq可以自己google。zeromq有一个问题是不能持久化数据,这个自己做持久化存储.回过刚才那个话题, 把明星会员的粉丝按照"活跃度"进行分级。"活跃度"是根据登陆频度,时间,发布微博等因素大致分为铁杆粉丝、爱理不理、半死不活三大类分到不同的发布集 群中去. 铁杆粉丝类型的异步发布集群，发布速度肯定是最快的.微博的信息是用handler socket保存到mysql。这个信息ID,是用rdtsc+2位随机整数拼接而成的 64位整数唯一ID，防止出现自增ID出现的多服务器 id一致性的问题. 在publish的时候，集群只是把微博信息的ID发送给redis的订阅者。所以这个数据是很快的。而且订阅者的list里只保存的是ID.在内存的占用率上也不是很高.

MYSQL 数据库结构

REDIS数据库结构

 

该架构师还说了几个关键点：

1、Key GPS Server，分布式数据存储的中心索引服务器.一切数据的存储和获取,都通过KGS来定位. KGS支持多个服务器,多个机房多重备份存储。KGS是以Tokyo Cabinet的hash db为存储的socket server。记录key跟服务器之间的对应关系. KGS的任务就是告知key该存储在哪几台服务器上,或者告知该key存储在哪几台服务器上，并不做其他的服务.这样大大的减轻KGS的压力.

2、Redis集群， 水平切分。redis是以纯内存形式模式运行,关闭了热备的功能(redis的热备并不是那么好). 自己写了个backend server在每台运行redis的机子上都运行着backend socket 进程, backend进程也是以tc的hash db为存储。备份着当前服务器的redis数据。当redis重启的时候，从本机的bakcend db 加载所有数据. Redis的集群是以用户水平切分法来分布的

3、mysql里, 在这个架构中基本消除了这边缓存那边缓存的问题。因为在这个集群中的每个服务都是高速运行的.唯一的一处的cache 就是在php端的eAccelerator local cache. eAccelerator是基于共享内存的,所以速度比基于socket类型的cache快多了. eAccelerator 缓存了用户top N条的微博信息还有从KGS查询的结果。

4、handler socket，怎么能不用mysql cache了.因为 handler socket。HS 是小日本写的一款mysql插件.HS避开了MySQL通讯协议,直接读取MySQL引擎。在多核、大内存、 InnoDB引擎环境,性能直超memcached.HS能以Key-Value方式直接读写mysql引擎

 

要是看更详细的这部分架构的资料，原文在：http://www.cellphp.com/article-read-nosql-20-handlersocket-nosql-zeromq-micro-blog-gps-tokyocabinet.html