zoukankan      html  css  js  c++  java
  • OceanBase架构浅析(二)

    单点性能

      OceanBase架构的优势在于既支持跨行跨表事务,又支持存储服务器线性扩展。当然,这个架构也有一个明显的缺陷:UpdateServer单点,这个问题限制了OceanBase集群的整体读写性能。下面从内存容量、网络、磁盘等几个方面分析UpdateServer的读写性能。其实大部分数据库每天的修改次数相当有限,只有少数修改比较频繁的数据库才有每天几亿次的修改次数。另外,数据库平均每次修改涉及的数据量很少,很多时候只有几十个字节到几百个字节。假设数据库每天更新1亿次,平均每次需要消耗100字节,每天插入1000万次,平均每次需要消耗1000字节,那么,一天的修改量为:1亿×100+1000万×1000=20GB,如果内存数据结构膨胀2倍,占用内存只有40GB。而当前主流的服务器都可以配置96GB内存,一些高档的服务器甚至可以配置192GB、384GB乃至更多内存。

      从上面的分析可以看出,UpdateServer的内存容量一般不会成为瓶颈。然而,服务器的内存毕竟有限,实际应用中仍然可能出现修改量超出内存的情况。例如,淘宝双11网购节数据库修改量暴涨,某些特殊应用每天的修改次数特别多或者每次修改的数据量特别大,DBA数据订正时一次性写入大量数据。为此,UpdateServer设计实现了几种方式解决内存容量问题,UpdateServer的内存表达到一定大小时,可自动或者手工冻结并转储到SSD中,另外,OceanBase支持通过定期合并或者数据分发的方式将UpdateServer的数据分散到集群中所有的ChunkServer机器中,这样不仅避免了UpdateServer单机数据容量问题,还能够使得读取操作往往只需要访问UpdateServer内存中的数据,避免访问SSD磁盘,提高了读取性能。

      从网络角度看,假设每秒的读取次数为20万次,每次需要从UpdateServer中获取100字节,那么,读取操作占用的UpdateServer出口带宽为:20万×100=20MB,远远没有达到千兆网卡带宽上限。另外,UpdateServer还可以配置多块千兆网卡或者万兆网卡,例如,OceanBase线上集群一般给UpdateServer配置4块千兆网卡。当然,如果软件层面没有做好,硬件特性将得不到充分发挥。针对UpdateServer全内存、收发的网络包一般比较小的特点,开发团队对UpdateServer的网络框架做了专门的优化,大大提高了每秒收发网络包的个数,使得网络不会成为瓶颈。

      从磁盘的角度看,数据库事务需要首先将操作日志写入磁盘。如果每次写入都需要将数据刷入磁盘,而一块SAS磁盘每秒支持的IOPS很难超过300,磁盘将很快成为瓶颈。为了解决这个问题,UpdateServer在硬件上会配置一块带有缓存模块的RAID卡,UpdateServer写操作日志只需要写入到RAID卡的缓存模块即可,延时可以控制在1毫秒之内。RAID卡带电池,如果UpdateServer发生故障,比如机器突然停电,RAID卡能够确保将缓存中的数据刷入磁盘,不会出现丢数据的情况。另外,UpdateServer还实现了写事务的成组提交机制,将多个用户写操作凑成一批一次性提交,进一步减少磁盘IO次数。

      磁盘随机IO是存储系统性能的决定因素,传统的SAS盘能够提供的IOPS不超过300。关系数据库一般采用高速缓存(Buffer Cache)[注释]的方式缓解这个问题,读取操作将磁盘中的页面缓存到高速缓存中,并通过LRU或者类似的方式淘汰不经常访问的页面;同样,写入操作也是将数据写入到高速缓存中,由高速缓存按照一定的策略将内存中页面的内容刷入磁盘。这种方式面临一些问题,例如,Cache冷启动问题,即数据库刚启动时性能很差,需要将读取流量逐步切入。另外,这种方式不适合写入特别多的场景。

      最近几年,SSD磁盘取得了很大的进展,它不仅提供了非常好的随机读取性能,功耗也非常低,大有取代传统机械磁盘之势。一块普通的SSD磁盘可以提供35000 IOPS甚至更高,并提供300MB/s或以上的读出带宽。然而,SSD盘的随机写性能并不理想。这是因为,尽管SSD的读和写以页(page,例如4KB,8KB等)为单位,但SSD写入前需要首先擦除已有内容,而擦除以块(block)为单位,一个块由若干个连续的页组成,大小通常在512KB~2MB。假如写入的页有内容,即使只写入一个字节,SSD也需要擦除整个512KB~2MB大小的块,然后再写入整个页的内容,这就是SSD的写入放大效应。虽然SSD硬件厂商都针对这个问题做了一些优化,但整体上看,随机写入不能发挥SSD的优势。

      OceanBase设计之初就认为SSD为大势所趋,整个系统设计时完全摒弃了随机写,除了操作日志总是顺序追加写入到普通SAS盘上,剩下的写请求都是对响应时间要求不是很高的批量顺序写,SSD盘可以轻松应对,而大量查询请求的随机读,则发挥了SSD良好的随机读的特性。摒弃随机写,采用批量的顺序写,也使得固态盘的使用寿命不再成为问题,主流SSD盘使用MLC SSD芯片,而MLC号称可以擦写1万次(SLC可以擦写10万次,但因成本高而较少使用),即使按最保守的2500次擦写次数计算,而且每天全部擦写一遍,其使用寿命为2500/365=6.8年。

    数据正确性

      数据丢失或者数据错误对于存储系统来说是一种灾难。OceanBase设计为强一致性系统,设计方案上保证不丢数据。然而,TCP协议传输、磁盘读写都可能出现数据错误,程序Bug则更为常见。为了防止各种因素导致的数据损毁,OceanBase采取了以下数据校验措施:

    ●数据存储校验。每个存储记录(通常是几KB到几十KB)同时保存64位CRC校验码,数据被访问时,重新计算和比对校验码。

    ●数据传输校验。每个传输记录同时传输64位CRC校验码,数据被接收后,重新计算和比对校验码。

    ●数据镜像校验。UpdateServer在机群内有主UpdateServer和备UpdateServer,集群间有主集群和备集群,这些UpdateServer的内存表(MemTable)必须保持一致。为此,UpdateServer为MemTable生成一个校验码,MemTable每次更新时,校验码同步更新并记录在对应的操作日志中。备UpdateServer收到操作日志并重放到MemTable时,也同步更新MemTable校验码并与接收到的校验码对照。UpdateServer重新启动后重放日志恢复MemTable时也同步更新MemTable校验码并与保存在每条操作日志中的校验码对照。

    ●数据副本校验。定期合并时,新的子表由各个ChunkServer独立地融合旧的子表中的SSTable与冻结的MemTable而生成,如果发生任何异常或者错误(比如程序bug),同一子表的多个副本可能不一致,则这种不一致可能随着定期合并而逐步累积或扩散且很难被发现,即使被察觉,也可能因为需要追溯较长时间而难以定位到源头。为了防止这种情况出现,ChunkServer在定期合并生成新的子表时,也同时为每个子表生成一个校验码,并随新子表汇报给RootServer,以便RootServer核对同一子表不同副本的校验码。

  • 相关阅读:
    20161101学习笔记
    20161031学习笔记
    20161028学习笔记
    20161027学习笔记
    ReentrantLock Condition
    ReentrantLock 重入锁
    CountDownLatch用法与原理
    场景化解释 AQS原理
    Atomic
    多线程工具类
  • 原文地址:https://www.cnblogs.com/LiJianBlog/p/4779990.html
Copyright © 2011-2022 走看看