现有架构中数据存储面临的挑战与应对

Posted on Sun 18 July 2010 in 我思

传统数据库方案(Oracle)面临的挑战

  1. High Performance: 高并发的读写
    • 高并发读写造成的锁等待问题
  2. Huge Storage: 海量数据的存储和访问
    • 传统数据库对海量XML数据结构的存储解决方案不太友好，类似vCard的存储
  3. High Scalability & High Available: 高扩展性和高可用性
    • 传统数据库Scale Out的解决方案复杂性高（业务相关的）且代价高

现有架构中数据存储面临的挑战

OLTP到OLAP的数据同步，实时性要求越来越高

我们很早就做到了OLTP和OLAP系统分开的：

  • OLTP（On-Line Transaction Processing）联机事务处理：OSS
  • OLAP（On-Line Analytical Processing）联机分析处理：DA-Server， SBX
但越来越多的数据分析需求，要求能够获得实时性性更高的数据。而高实时性会增加同步的代价。

业务间对共有数据操作的竞争

由于现有的数据库设计并没有对用户数据和业务数据进行逻辑上的区分，所有服务对用户数据都有相同的权限，操作同一块用户数据引起的问题无法从根本上进行避免。

业务间对数据库资源的竞争

目前的数据库是建立在一个Oracle实例（并且在一个用户下）中的，同时为杀毒、通管、公共服务、计费服务等应用提供服务。

一个实例的输出上限是固定的，各个业务对数据库服务资源也存在竞争关系。

相关理论

1. 必然性理论

云计算平台是非常 巨大的分布式系统，需要处理庞大的业务请求，因此任何小概率事件在此平台中都必然发生。 这句话说出了一个事实，也为我们的设计提出了明确的要求，就是要有容错性考虑。这个可以参考我之前的帖子：《网络应用系统设计的基本原则》。

2. CAP理论

  • CAP 理论：
    • 一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两 个。
      1. Consistency(一 致性), 数据一致更新，所有数据变动都是同步的
      2. Availability(可 用性), 好的响应性能
      3. Partition tolerance/Tolerance to network Partitions(分区容错性)，部分节点故障或节点之间连接故障下系统仍可正常工作
CAP理论给我们带来一个全新的视角看待数据存储的性能扩展，基于这个理论，我们可以得到后面的应对思路。 接下来还是从CAP理论的视角看看另外两个存储模型：

从CAP的角度看ACID模型

传统关系数据库的ACID 模型： 高一致性 + 可靠性 丧失可用性
  1. Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。
  2. Consistency一致性. 在事务开始或结束时，数据库应该在一致状态。
  3. Isolation隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。
  4. Durability. 一旦事务完成，就不能返回。

适应CAP的BASE模型

BASE模型：牺牲高一致性，获得可用性或可靠性
  1. Basically Availble 基本可用。支持分区失败(e.g. sharding划分数据库)
  2. Soft-state 软状态 状态可以有一段时间不同步
  3. Eventual Consistency 最终一致，最终数据是一致的就可以了，而不是时时高一致

应对

在云计算平台中采用传统 数据库作为数据持久化的解决方案之所以会遇到这些挑战，是因为传统数据库都是采用了高一致性要求的ACID模型所致。按照后来提出并被证明是正确的CAP 理论来分析，一致性、可用性和分区容错性三者只能同时满足其二。

拿传统数据库的集群解决方 案来看：ORACLE RAC采用了共享存储的方式，重点明显放到了一致性和分区容错性上，对于可用性（包括可扩展性）必然不会有很好的表现；MySQL的单Master写+多 Slaver同步、读的方案也不完美，频繁写的情况下Slaver同步可能出现瓶颈，造成一致性的问题，看起来更偏重可用性和分区容错性。

思路一：逻辑拆分

对OLTP中用户数据和业务数据进行逻辑拆分

思路二：混搭

根据CAP理论，架构师 不应该把精力浪费在如何设计能满足三者的完美分布式系统，而是应该根据实际业务需求，进行取舍。

一般来说，确认业务对数据一致性的要求是一个入手点：不同数据对于一致性的要求往往是不同的。举例来讲，用户评论对不一 致是不敏感的，可以容忍相对较长时间的不一致，这种不一致并不会影响交易和用户体验。而对用户信息、交易信息都是非常敏感的，例如产品价格数据，通常不能 容忍超过10秒的价格不一致。

对高并发的系统，可用性与分 区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。

实际互联网系统往往都是ACID和BASE两种系统的结合，例如用户身份数据、交易数据通常采取ACID模型；

2. 实现（How to 混搭）

基本思路： 面向服务的架构+特定模式的存储解决方案

面向服务的架构SOA

面向服务的架构把系统拆解 成一个个的服务单元，通过网络把各个单元连接起来共同提供服务。这种架构能够有效的降低我们系统的耦合性和复杂度。

基于这个架构，我们可以为特定的服务单元选择特定的存储解决方案。SOA技术架构目前采用的是Spring HttpInvoke， 后续如果有合适的需求，打算引入Apache Thrift。

  1. Spring HttpInvoke
  2. Apache Thrift

现有业务逻辑调研分析

目标是搞清实体模型和基本 业务流程。

我们需要发现受到存储挑战的业务逻辑，搞清需要存储的数据实体 模型和业务逻辑：

  1. 用户信息认证和更新
    • 面临挑战： 海量规范格式数据高并发读写
      1. 数据量：100M条；
      2. 并发度： 1000次读写/s；
      3. 一致性： 要求高
    • 数 据实体模型：用户信息（包含服务关系等）
    • 业务 逻辑: 用户信息的认证、添加、更新等；
  2. 用户会话管理
    • 面临挑战： 海量规范格式数据高并发读写
      1. 数据量：取决于并发用户数和会话持续时 间，目前的数量级应小于1万；
      2. 并发度： 1000次读写/s；
      3. 一致性： 要求高
      4. 持久性： 低，会话结束就可以销毁
    • 数据实体模型：用户基本信息（包含一个 唯一的会话ID）
    • 业务逻辑: 获取、验证或者添加用户信息；
  3. 通讯录备份、 编辑和还原
    • 面临挑战： 海量非结构化的存储
      1. 数据量：1M人X200条=2亿条通讯录 记录；
      2. 并发度：一般 ；
      3. 一致性： 一般
    • 数据实体模型：用户实体模型、通讯录记录模型
    • 业务逻辑： 通讯录的添加、修改等

业内成熟解决方案学习

  1. 内存式Key-Value存储 解决方案：
    • 例如基于Redis的会话管理方案（已经实施）
  2. Huge Storage和面向文档的数据库
    • 例如MongoDB，CouchDB， 通讯录服务的存储如果遇到挑战，可以向这个方向转型
  3. 灵 活的分布式方案（我们可以借鉴具体实施中的经验）
    • 领域模型 + 分布式缓存 + 存储

新型持久存储服务调研

  1. 满足High Performance的Key-Value数据库： Redis，Tokyo Cabinet， Flare
  2. 满足Huge Storage和面向文档的数据库： MongoDB，CouchDB
  3. 满足HS和HC的数据库：Cassandra，Voldemort, Yahoo! PNUTS
搞清楚业务实体模型和业务流程是根本；掌握新型数据存储服务的特性是前提。

Architecture CAP Database