NoSQL数据库渐入佳境 国内应用案例盘点

数据库 其他数据库
NoSQL数据库正在逐渐地成为数据库领域中不可或缺的一部分,它弥补了关系型数据库在某些应用场景的不足,但是它也并非万能,方法得当的话,能获得很多的好处。

随着互联网的不断发展,各种类型的应用层出不穷,所以导致在这个云计算的时代,对技术提出了更多的需求。虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位,但是由于其天生的几个限制,使其很难满足上面这几个需求:扩展困难、读写慢、成本高、有限的支撑容量。业界为了解决上面提到的几个需求,推出了新类型的 “NoSQL”数据库。总的来说,在设计上,它们非常关注对数据高并发地读写和对海量数据的存储等,与关系型数据库相比,它们在架构和数据模型方量面做了”减法”,而在扩展和并发等方面做了”加法”。

现今的计算机体系结构在数据存储方面要求具备庞大的水平扩展性,而NoSQL致力于改变这一现状。目前Google、Yahoo、Facebook、Twitter、Amazon都在大量应用NoSQL型数据库。本文以NoSQL在国内知名的互联网公司应用为案例,为大家细数国内NoSQL数据库的应用情况。

一、新浪微博

大家都知道,在美国有一个非常有名的信息分享平台叫做Twitter,而在中国,我们也有同样的方式,就是现在非常流行的新浪微博,它还有个非常温馨的名字,叫做围脖。

▲新浪微博

新浪微博从技术上来说,每天用户发表特别容易,这造成每天新增的数据量都是百万级的、上千万级的这样一个量。这样你经常要面对的一个问题就是增加服务器,因为一般一台MySQL服务器,它可能支撑的规模也就是几千万,或者说复杂一点只有几百万,这样,你可能每天都要增加服务器,从而解决所你面对的这些问题。

目前新浪微博是Redis全球最大的用户,在新浪有200多台物理机,400多个端口正在运行着Redis, 有+4G的数据跑在Redis上来为微博用户提供服务。

在新浪NoSQL和MySQL在大多数情况下是结合使用的,根据应用的特点选择合适存储方式。譬如:关系型数据,例如:索引使用MySQL存储,非关系数据库,例如:一些K/V需求的,对并发要求比较高的放入Redis存储。

Redis通过修改源码满足自己的业务需求:完善它的replication机制,加入position的概念,让维护更容易,同时failover能力也大大增强。改善Hashset在rdb里面的存储方式,提升复杂数据类型的加载速度。

二、淘宝数据平台

淘宝网拥有国内最具商业价值的海量数据。截至当前,每天有超过30亿的店铺、商品浏览记录,10亿在线商品数,上千万的成交、收藏和评价数据。如何从这些数据中挖掘出真正的商业价值,进而帮助淘宝、商家进行企业的数据化运营,帮助消费者进行理性的购物决策,是淘宝数据平台与产品部的使命。

[[44724]]

▲淘宝数据平台

数据产品的一个最大特点是数据的非实时写入,正因为如此,可以认为在一定的时间段内,整个系统的数据是只读的。这为设计缓存奠定了非常重要的基础。一些对实效性要求很高的数据,例如针对搜索词的统计数据,希望能尽快推送到数据产品前端,所以在内存中做实时计算,并把计算结果在尽可能短的时间内刷新到 NoSQL存储设备中,供前端产品调用。

淘宝Oceanbase的设计之初,是这样的。公司通过对淘宝的在线存储需求进行分析发现:

淘宝的数据总量比较大,未来一段时间,比如五年之内的数据规模为百TB级别,千亿条记录,另外,数据膨胀很快,传统的分库分表对业务造成很大的压力,必须设计自动化的分布式系统。所以有了淘宝Oceanbase,它以一种很简单的方式满足了未来一段时间的在线存储需求,并且还获得了一些其它特性,如高效支持跨行跨表事务,这对于淘宝的业务是非常重要的。

淘宝Tair是由淘宝自主开发的Key/Value结构数据存储系统,并且于 2010年6月30号在淘宝开源平台上正式对外开源,在淘宝网有着大规模的应用。用户在登录淘宝、查看商品详情页面或者在淘江湖和好友“捣浆糊”的时候,都在直接或间接地和Tair交互。淘宝将Tair开源,希望有更多的用户能从我们开发的产品中受益,更希望依托社区的力量,使Tair有更广阔的发展空间。

三、视觉中国网站

在视觉中国成立之初,他们选用的数据库是MySQL,09年之后他们才选用了MongoDB作为系统的支撑数据库。

[[44725]]

▲视觉中国

采用MongoDB的最初阶段困难是肯定有的,而且还有很多。困难的来源一方面来源于MongoDB的年轻。虽说它的发展很快,但是毕竟是年轻的产品,技术不是特别的成熟,所以会出现很多很多的问题。但是MongoDB有一个好的技术团队,对产品的版本更新速度很快,对问题的响应速度很快,这对解决问题是很大的支撑。一方面是技术,遇到困难,解决困难,在这个过程中,也得到了很多经验,为后续的工作做了很好的准备;

视觉中国的数据量是有限的,只能到千万级别,所以将数据进行分组,大概分为四组,每组的平均数据量大概是几百万到几千万。但是,根据国外的案例来看,数据量已经达到十亿、百亿的级别,MongoDB的使用基本没有出现过太大的问题。如果现在不通过auto-sharding,自己手动切片,也是很不错的。

无论选用哪种数据库,都要根据公司的情况来判断,毕竟这种转移是十分耗费成本的。SQL+NoSQL的方法,十分值得关注。另外优化是十分重要的,但是优化是有技巧的,万不可胡乱优化。

#p#

四、优酷运营数据分析

优酷作为一家大型视频网站,拥有海量播放流畅的视频。它秉承注重用户体验这一产品技术理念,将绝大部分存储用在视频资源上。通过建设专用的视频CDN,建立了可自由扩展、性能优异的架构,在提供更好用户体验的同时优化了存储资源。在除视频资源外的其他方面,优酷也累积了海量数据:仅运营数据,每天收集到的网站各类访问日志总量已经达到TB级,经分析及压缩处理后留存下来的历史运营数据已达数百TB,很快将会达到 PB级,5年后数据量将会达到几十PB级。

▲优酷

目前优酷的在线评论业务已部分迁移到MongoDB,运营数据分析及挖掘处理目前在使用Hadoop/HBase;在Key-Value产品方面,它也在寻找更优的 Memcached替代品,如Redis,相对于Memcached,除了对Value的存储支持三种不同的数据结构外,同一个Key的Value进行部分更新也会更适合一些对Value频繁修改的在线业务;同时在搜索产品中应用了Tokyo Tyrant;对于Cassandra等产品也进行过研究。

[[44726]]

对于优酷来说,仍处于飞速发展阶段,已经在考虑未来自建数据中心,提高数据处理能力,从网站的运营中发掘出更多信息,为用户提供更好的视频服务。

五、飞信空间

飞信的SNS平台数据量大,增长快,目前的状态如下:

[[44727]]

▲飞信空间

  • 日活跃用户100W,平均主动行为1.3次
  • 平均好友20个
  • 平均每条动态存储数据量1.5K
  • 数据容量 2600W*1.5KB=40GB
  • 以关系型数据库估计,占用存储这僮100GB左右

SNS类型应用中,Feed的数据量最大,Feed数据的存储与读写操作往往是技术难度最高的部分,由于Feed要求的高并发写入,弱一致性,使HandlerSocket成为NoSQL技术的主要应用战场。

HandlerSocket还帮飞信解决了缓存的问题,因为Innodb已经有了成熟的解决方案,通过参数可以配置用于缓存数据的内存大小,这样只要分配合理的参数,就能在应用程序无需干涉的情况下实现热点数据的缓存,降低缓存维护的开发成本。

HandlerSocket是日本DeNA公司的架构师Yoshinori开发的一个NoSQL产品,以MySQL Plugin的形式运行。其主要的思路是在MySQL的体系架构中绕开SQL解析这层,使得应用程序直接和Innodb存储引擎交互,通过合并写入、协议简单等手段提高了数据访问的性能,在CPU密集型的应用中这一优势尤其明显。

因为HandlerSocket是MySQL的一个 Plugin,集成在mysqld进程中,对于NoSQL无法实现的复杂查询等操作,仍然可以使用MySQL自身的关系型数据库功能来实现。在运维层面,原来广泛使用的MySQL主从复制等经验可以继续发挥作用,相比其他或多或少存在一些bug的NoSQL产品,数据安全性更有保障。

六、豆瓣社区

BeansDB 是一个由国内知名网站豆瓣网自主开发的主要针对大数据量、高可用性的分布式KeyValue存储系统,采用HashTree和简化的版本号来快速同步保证最终一致性(弱),一个简化版的Dynamo,它在伸缩性和高可用性方面有非常好的表现。

[[44728]]

▲豆瓣社区

它采用类似memcached的去中心化结构,在客户端实现数据路由。目前只提供了Python版本的客户端,其它语言的客户端可以由memcached的客户端稍加改造得到。

它具有如下特性:

  • 高可用:通过多个可读写的用于备份实现高可用
  • 最终一致性:通过哈希树实现快速完整数据同步(短时间内数据可能不一致)
  • 容易扩展:可以在不中断服务的情况下进行容量扩展。
  • 高性能:异步网络IO, 日志结构的存储方式Bitcask.
  • 简单协议:Memcache兼容协议,大量可用客户端

目前,BeansDB在豆瓣主要部署了两个集群:一个集群用于存储数据库中的大文本数据,比如日记、帖子一类;另外一个豆瓣FS集群,主要用于存储媒体文件,比如用户上传的图片、豆瓣电台上的音乐等。

BeansDB采用Key-Value存储架构,其最大的特点是具有高度的可伸缩性;在BeansDB的架构下,在大数据量下,扩展数据节点将轻而易举,只需要添加硬件,安装软件,修改相应的配置文件即可。

BeansDB在可用性方面也有很大的优势,任何一个节点宕机都不会受到影响,数据是自动伸缩冗余的。在运维方面也很简单,基本上没有什么用户数据的冗余残余,所有数据通过一个同步脚本可以快速同步。

总结

综合来看,NoSQL数据库正在逐渐地成为数据库领域中不可或缺的一部分,它弥补了关系型数据库在某些应用场景的不足,但是它也并非万能,方法得当的话,能获得很多的好处。企业应该谨慎行事,要充分地认识到这些数据库的一些限制和问题。按照毛爷爷的话讲就是:前途是光明的,道路是曲折的。

【编辑推荐】

 

责任编辑:艾婧 来源: it168网站
相关推荐

2009-01-05 11:05:28

李开复谷歌中国市场

2020-03-17 20:44:20

区块链物联网Gartner

2022-06-07 16:41:15

5G数字经济数字化转型

2013-09-24 15:07:31

2010-07-22 17:42:35

浪潮湖北国税虚拟化

2013-07-17 09:17:35

守望星Aisino视频监控

2016-07-20 09:57:17

华为

2020-07-10 10:45:41

先导杯

2016-04-22 14:50:18

VR大会现场报道魏明

2020-05-19 08:40:19

人工智能智能语音交互智能语音设备

2018-07-06 18:27:12

人工智能

2017-04-07 21:09:21

海云捷迅

2013-09-26 10:18:08

网络·安全技术周刊

2014-08-14 09:12:50

2012-06-12 09:42:43

应用虚拟化

2019-03-01 11:32:04

华为睿呈时代

2017-11-13 13:26:35

游族

2018-05-19 22:44:58

运营商人工智能通信行业

2024-02-02 10:51:53

2015-03-13 11:02:10

移动协同
点赞
收藏

51CTO技术栈公众号