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

2013 年 3 月 27 日1,6490

        本站主要内容均为原创,转帖需注明出处www.alexclouds.net 

        业界一直有很多的声音,呼吁着关系型数据库正在加速消亡,事实并非如此,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 数据库结构

mysql-nosql1

REDIS数据库结构

mysql-nosql2

 

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

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

0 0