Java架构师第九步——非关系型数据库与公司的最佳实践（读书笔记）

NoSQL优秀公司的最佳实践

1. 新浪微博 - Redis

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

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

新浪微博面临的问题如下：

数据结构(Data Structure)需求越来越多, 但memcache中没有, 影响开发效率

随着读操作的量的上升，性能问题需要解决，经历的过程有:

数据库读写分离(M/S)-->数据库使用多个Slave-->增加Cache (memcache)-->转到Redis

解决写的问题：

水平拆分，对表的拆分，将有的用户放在这个表，有的用户放在另外一个表。

可靠性需求

Cache的"雪崩"问题难以解决，面临着快速恢复的挑战。

开发成本需求

Cache和DB的一致性维护成本越来越高，但开发需要跟上不断涌入的产品需求。且硬件成本最贵的就是数据库层面的机器，基本上比前端的机器要贵几倍，主要是IO密集型，很耗硬件。

维护性复杂

一致性维护成本越来越高

BerkeleyDB使用B树，会一直写新的，内部不会有文件重新组织；这样会导致文件越来越大；大的时候需要进行文件归档，归档的操作要定期做，这样，就需要有一定的down time。

基于以上考虑，新浪微博选择了Redis。

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

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



业务场景如下：

1. 业务使用方式：

hash sets: 关注列表, 粉丝列表, 双向关注列表(
3ff0
key-value(field), 排序)

string(counter): 微博数, 粉丝数, ...(避免了select count(*) from ...)

sort sets(自动排序): TopN, 热门微博等, 自动排序

lists(queue): push/sub提醒,...

上述四种, 从精细化控制方面，hash sets和string(counter)推荐使用, sort sets和lists(queue)不推荐使用

还可通过二次开发，进行精简。比如: 存储字符改为存储整形, 16亿数据,只需要16G内存

存储类型保存在3种以内，建议不要超过3种；

将memcache +mysql 替换为Redis：

Redis作为存储并提供查询，后台不再使用mysql，解决数据多份之间的一致性问题；

2. 对大数据表的存储（eg：140字微博的存储）

一个库就存唯一性id和140个字；

另一个库存id和用户名，发布日期、点击数等信息，用来计算、排序等，等计算出最后需要展示的数据时再到第一个库中提取微博内容；

3. 一些技巧

很多应用, 可以承受数据库连接失败, 但不能承受处理慢

一份数据, 多份索引(针对不同的查询场景)

解决IO瓶颈的唯一途径: 用内存

在数据量变化不大的情况下，优先选用Redis

2. 淘宝数据平台 – Oceanbase,Tair（均为自研）

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

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

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

OceanBase由如下几个部分组成：

客户端：用户使用OceanBase的方式和MySQL数据库完全相同，支持JDBC、 C客户端访问，等等。基于MySQL数据库开发的应用程序、工具能够直接迁移到OceanBase。

RootServer：管理集群中的所有服务器，子表（tablet）数据分布以及副本管理。 RootServer一般为一主一备，主备之间数据强同步。

UpdateServer：存储OceanBase系统的增量更新数据。UpdateServer一般为一主一备，主备之间可以配置不同的同步模式。部署时，UpdateServer进程和RootServer进程往往共用物理服务器。

ChunkServer：存储OceanBase系统的基线数据。基线数据一般存储两份或者三份，可配置。

Merge Server：接收并解析用户的SQL请求，经过词法分析、语法分析、查询优化等一系列操作后转发给相应的ChunkServer或者UpdateServer。如果请求的数据分布在多台ChunkServer上，MergeServer还需要对多台ChunkServer返回的结果进行合并。客户端和MergeServer之间采用原生的MySQL通信协议，MySQL客户端可以直接访问MergeServer。

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



Tair 的分布采用的是一致性哈希算法, 对于所有的key, 分到Q个桶中, 桶是负载均衡和数据迁移的基本单位. config server 根据一定的策略把每个桶指派到不同的data server上. 因为数据按照key做hash算法, 所以可以认为每个桶中的数据基本是平衡的. 保证了桶分布的均衡性, 就保证了数据分布的均衡性。

3. 优酷运营数据分析 – HBase,MongoDB, Redis

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



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

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

4. 豆瓣社区 – BeansDB（自研KV数据库）

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

高可用：通过多个可读写的用于备份实现高可用

最终一致性：通过哈希树实现快速完整数据同步(短时间内数据可能不一致)

容易扩展：可以在不中断服务的情况下进行容量扩展。

高性能：异步网络IO, 日志结构的存储方式Bitcask.

简单协议：Memcache兼容协议，大量可用客户端

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



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

BeansDB项目可以说是一个简化版的AWS DynamoDB。BeansDB对key做哈希运算找到节点来实现分布和冗余， 一个写操作会写好几个节点，而现在的配置是写三份读一份。BeansDB主要的特点是支持海量KV数据库——相比Redis这种支持几十个G到几百个G的内存KV数据库，BeansDB可以支持到上百T的数据。另外BeansDB最大的好处就是运维很简单，性能、扩容都很好，也实现了最终一致性。

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