OceanBase写入限速源码解读

一、简介

OceanBase中的写入限速机制旨在控制系统中写入操作(一般写入操作包括插入、更新和删除等)的速率,目的是为了提高数据库系统的稳定性。本文主要通过以下2个参数来解释写入限速的实现机制。

**1.**writing_throttling_trigger_percentage:设置写入速度的阈值百分比。当内存使用达到该阈值时,触发写入限速机制。默认值为60,取值范围为1到100(100表示关闭写入限速)。
**2.**writing_throttling_maximum_duration:指定触发写入限速后,所需的剩余内存分配时间。默认值为2小时。通常情况下,不需要修改该参数。
请注意,OceanBase 2.2.30 及之后版本才开始支持该机制。

二、实现原理

1. 进入限速逻辑
当执行写入操作申请内存时,触发写入限速条件:已使用的 Memstore 内存超过设定的比例(比例阈值由 writing_throttling_trigger_percentage 参数确定),系统进入限速逻辑。

2. 多次限速
限速逻辑会将本次申请内存的任务分成多次进行限速。每次限速的执行时间最多为20毫秒。

3.系统在每次限速中进行一个限速循环,在限速循环中,系统会检查以下条件:

  • 内存释放:系统检查内存是否已经释放足够多的内存(满足不进入限速的条件),系统已经不需要限速。
  • SQL执行时间限制:系统检查SQL的执行时间是否已经达到限制。如果已经达到限制,则系统退出限速循环,并将SQL完成的信息发送给客户端。
  • 休眠时间:系统检查是否已经休眠了20秒。如果已经休眠,则系统退出限速循环,并将SQL完成的信息发送给客户端。

4. 完成限速
如果上述任意一项条件满足,系统将退出限速循环,并将SQL完成的信息发送给客户端。这样可以确保SQL能够成功执行完成,并保证系统的稳定性。

5. 流程参考
在这里插入图片描述

三、源码解读

以下通过源码以一条insert语句的部分堆栈来解释writing_throttling_trigger_percentage和writing_throttling_maximum_duration是如何影响限速逻辑的。
ObTablet::insert_row_without_rowkey_check()

int ObTablet::insert_row_without_rowkey_check(
    ObRelativeTable &relative_table,
    ObStoreCtx &store_ctx,
    const common::ObIArray<share::schema::ObColDesc> &col_descs,
    const storage::ObStoreRow &row)
{
  int ret = OB_SUCCESS;
  {
    // insert_row_without_rowkey_check 执行结束时会调用ObStorageTableGuard的析构函数,进行限速处理
    ObStorageTableGuard guard(this, store_ctx, true);
    ObMemtable *write_memtable = nullptr;
    ...
    //write_memtable->set()会调用ObFifoArena::alloc()申请内存, 在分配内存时进行限速判断
    else if (OB_FAIL(write_memtable->set(store_ctx, relative_table.get_table_id(),
    full_read_info_, col_descs, row)))
    ...
  }
  return ret;
}

该方法会实例化 ObStorageTableGuard类 , 限速的执行过程定义在该类的析构函数内, 所以程序会在执行完 write_memtable 后才进行限速。后续会进行写Memtable的流程,这里不做赘述, 大致调用堆栈如下:

| > oceanbase::storage::ObTablet::insert_row_without_rowkey_check(...) (/src/storage/tablet/ob_tablet.cpp:1425)
| + > oceanbase::memtable::ObMemtable::set(...) (/src/storage/memtable/ob_memtable.cpp:339)
| + - > oceanbase::memtable::ObMemtable::set_(...) (/src/storage/memtable/ob_memtable.cpp:2538)
| + - x > oceanbase::memtable::ObMemtable::mvcc_write_(...) (/src/storage/memtable/ob_memtable.cpp:2655)
| + - x = > oceanbase::memtable::ObMvccEngine::create_kv(...) (/src/storage/memtable/mvcc/ob_mvcc_engine.cpp:275)
| + - x = | > oceanbase::memtable::ObMTKVBuilder::dup_key(...) (/src/storage/memtable/ob_memtable.h:77)
| + - x = | + > oceanbase::common::ObGMemstoreAllocator::AllocHandle::alloc(...) (/src/share/allocator/ob_gmemstore_allocator.h:84)
| + - x = | + - > oceanbase::common::ObGMemstoreAllocator::alloc(...) (/src/share/allocator/ob_gmemstore_allocator.cpp:125)
| + - x = | + - x > oceanbase::common::ObFifoArena::alloc(...) (/src/share/allocator/ob_fifo_arena.cpp:157)
| + - x = | + - x = > oceanbase::common::ObFifoArena::speed_limit(...)(/src/share/allocator/ob_fifo_arena.cpp:301)
| + - x = | + - x = | > oceanbase::common::ObFifoArena::ObWriteThrottleInfo::check_and_calc_decay_factor(...)(/src/share/allocator/ob_fifo_arena.cpp:75)
| + > oceanbase::storage::ObStorageTableGuard::~ObStorageTableGuard(...) (/src/storage/ob_storage_table_guard.cpp:53)

ObFifoArena::alloc()

写memtable时会申请内存, 这时候会去判断是否需要限速

void* ObFifoArena::alloc(int64_t adv_idx, Handle& handle, int64_t size)
{
  int ret = OB_SUCCESS;
  void* ptr = NULL;
  int64_t rsize = size + sizeof(Page) + sizeof(Ref);
  // 调用speed limit 判断限速
  speed_limit(ATOMIC_LOAD(&hold_), size);
  ...
}

ObFifoArena::speed_limit()

这个方法主要用来判断是否需要限速,同时根据配置的writing_throttling_maximum_duration值,计算出一个衰减因子用于等待时间的计算

void ObFifoArena::speed_limit(const int64_t cur_mem_hold, const int64_t alloc_size)
{
  int ret = OB_SUCCESS;
  //获取租户的writing_throttling_trigger_percentage值
  int64_t trigger_percentage = get_writing_throttling_trigger_percentage_();
  int64_t trigger_mem_limit = 0;
  bool need_speed_limit = false;
  int64_t seq = 0;
  int64_t throttling_interval = 0;
  // trigger_percentage <100 ,表示开启限速,再进行内存使用是否达到触发阈值的判断
  if (trigger_percentage < 100) {
    if (OB_UNLIKELY(cur_mem_hold < 0 || alloc_size <= 0 || lastest_memstore_threshold_ <= 0 || trigger_percentage <= 0)) {
      COMMON_LOG(ERROR, "invalid arguments", K(cur_mem_hold), K(alloc_size), K(lastest_memstore_threshold_), K(trigger_percentage));
    } else if (cur_mem_hold > (trigger_mem_limit = lastest_memstore_threshold_ * trigger_percentage / 100)) {
      // 当前使用内存超过触发阈值,需要限速,设置need_speed_limit 为true
      need_speed_limit = true;
      // 获取writing_throttling_maximum_duration的值,默认 2h
      int64_t alloc_duration = get_writing_throttling_maximum_duration_();
      // 计算衰减因子,用于sleep时间计算
      if (OB_FAIL(throttle_info_.check_and_calc_decay_factor(lastest_memstore_threshold_, trigger_percentage, alloc_duration))) {
        COMMON_LOG(WARN, "failed to check_and_calc_decay_factor", K(cur_mem_hold), K(alloc_size), K(throttle_info_));
      }
    }
    
    //这块代码是将内存和时钟值绑定,确保内存分配和写入限速的稳定性
    advance_clock();
    seq = ATOMIC_AAF(&max_seq_, alloc_size);
    get_seq() = seq;
     
    // 将need_speed_limit 赋值给tl_need_speed_limit 线程变量
    tl_need_speed_limit() = need_speed_limit;
    //日志记录,限速信息
    if (need_speed_limit && REACH_TIME_INTERVAL(1 * 1000 * 1000L)) {
      COMMON_LOG(INFO, "report write throttle info", K(alloc_size), K(attr_), K(throttling_interval),
                  "max_seq_", ATOMIC_LOAD(&max_seq_), K(clock_),
                  K(cur_mem_hold), K(throttle_info_), K(seq));
    }
  }
}

ObFifoArena::ObWriteThrottleInfo::check_and_calc_decay_factor()
计算衰减因子

int ObFifoArena::ObWriteThrottleInfo::check_and_calc_decay_factor(int64_t memstore_threshold,
                                                                  int64_t trigger_percentage,
                                                                  int64_t alloc_duration)
{
  int ret = OB_SUCCESS;
  if (memstore_threshold != memstore_threshold_
      || trigger_percentage != trigger_percentage_
      || alloc_duration != alloc_duration_
      || decay_factor_ <= 0) {
    memstore_threshold_ = memstore_threshold;
    trigger_percentage_ = trigger_percentage;
    alloc_duration_ = alloc_duration;
    int64_t available_mem = (100 - trigger_percentage_) * memstore_threshold_ / 100;
    double N =  static_cast<double>(available_mem) / static_cast<double>(MEM_SLICE_SIZE);
    decay_factor_ = (static_cast<double>(alloc_duration) - N * static_cast<double>(MIN_INTERVAL))/ static_cast<double>((((N*(N+1)*N*(N+1)))/4));
    decay_factor_ = decay_factor_ < 0 ? 0 : decay_factor_;
    COMMON_LOG(INFO, "recalculate decay factor", K(memstore_threshold_), K(trigger_percentage_),
               K(decay_factor_), K(alloc_duration), K(available_mem), K(N));
  }
  return ret;
}

decay_factor公式中,alloc_duration为writing_throttling_maximum_duration的值,4.0版本中为2h,MIN_INTERVAL默认值20ms。

简单来说,这个衰减因子是根据当前可用内存和writing_throttling_maximum_duration的值通过一个多项式计算出来的,整个过程如果writing_throttling_maximum_duration值不做调整,每次休眠时间会随着可用内存逐渐减少而慢慢增加。

ObStorageTableGuard::~ObStorageTableGuard()
限速流程执行

ObStorageTableGuard::~ObStorageTableGuard()
{
  //tl_need_speed_limit 在ObFifoArena::alloc()方法中赋值
  bool &need_speed_limit = tl_need_speed_limit();
  // 在写操作的上下文中, 创建ObStorageTableGuard 实例时,need_control_mem_ 会被赋值为true
  if (need_control_mem_ && need_speed_limit) {
    bool need_sleep = true;
    int64_t left_interval = SPEED_LIMIT_MAX_SLEEP_TIME;
    //SPEED_LIMIT_MAX_SLEEP_TIME 默认20s,表示最大sleep时间
    if (!for_replay_) {
        // 如果不是回放日志
        //store_ctx_.timeout_ - ObTimeUtility::current_time() 表示距离事务超时还要多久,如果该值小于0,表示事务已经超时
        //两者取小
      left_interval = min(SPEED_LIMIT_MAX_SLEEP_TIME, store_ctx_.timeout_ - ObTimeUtility::current_time());
    }
    // 如果memtable是冻结状态,不需要限速
    if (NULL != memtable_) {
      need_sleep = memtable_->is_active_memtable();
    }
    uint64_t timeout = 10000;//10s
    //事件记录, 可以在v$session_event中查看,event名: memstore memory page alloc wait
    //可以通过sql: select * from v$session_event where EVENT='memstore memory page alloc wait' 查询;
    common::ObWaitEventGuard wait_guard(common::ObWaitEventIds::MEMSTORE_MEM_PAGE_ALLOC_WAIT, timeout, 0, 0, left_interval);
 
    reset();
    int tmp_ret = OB_SUCCESS;
    bool has_sleep = false;
    int64_t sleep_time = 0;
    int time = 0;
    int64_t &seq = get_seq();
    if (store_ctx_.mvcc_acc_ctx_.is_write()) {
      ObGMemstoreAllocator* memstore_allocator = NULL;
      //获取当前租户的memstore内存分配器
      if (OB_SUCCESS != (tmp_ret = ObMemstoreAllocatorMgr::get_instance().get_tenant_memstore_allocator(
          MTL_ID(), memstore_allocator))) {
      } else if (OB_ISNULL(memstore_allocator)) {
        LOG_WARN_RET(OB_ALLOCATE_MEMORY_FAILED, "get_tenant_mutil_allocator failed", K(store_ctx_.tablet_id_), K(tmp_ret));
      } else {
        while (need_sleep &&
               !memstore_allocator->check_clock_over_seq(seq) &&
               (left_interval > 0)) {
          if (for_replay_) {
            // 如果是回放日志,并且当前租户下有正在进行的日志流,不做休眠,直接break
            if(MTL(ObTenantFreezer *)->exist_ls_freezing()) {
              break;
            }
          }
          //计算休眠时间
          int64_t expected_wait_time = memstore_allocator->expected_wait_time(seq);
          if (expected_wait_time == 0) {
            break;
          }
          //SLEEP_INTERVAL_PER_TIME 单次休眠时间,默认20ms
          //线程休眠,每次最多20ms
          uint32_t sleep_interval =
            static_cast<uint32_t>(min(min(left_interval, SLEEP_INTERVAL_PER_TIME), expected_wait_time));
          ::usleep(sleep_interval);
          // 累加休眠时间
          sleep_time += sleep_interval;
          // 休眠次数
          time++;
          //每次休眠之后,减去休眠时间
          left_interval -= sleep_interval;
          has_sleep = true;
          //每次休眠之后,重新判断是否需要限速,因为可能在休眠过程中,内存经过转储后已经释放出来了,这时候就不需要继续限速了
          need_sleep = memstore_allocator->need_do_writing_throttle();
        }
      }
    }
    // 日志记录,限速执行详情
    if (REACH_TIME_INTERVAL(100 * 1000L) &&
        sleep_time > 0) {
      int64_t cost_time = ObTimeUtility::current_time() - init_ts_;
      LOG_INFO("throttle situation", K(sleep_time), K(time), K(seq), K(for_replay_), K(cost_time));
    }
 
    if (for_replay_ && has_sleep) {
      get_replay_is_writing_throttling() = true;
    }
  }
  reset();
}

总结
OB的写入限速功能是在ObStorageTableGuard类的析构函数中实现的。由于该函数会在memtable写入完成后才被调用,因此限速行为是后置的,会影响下一次内存分配。换言之,在当前写入操作完成后,才会判断是否需要执行限速,若需要,会延迟下一次内存分配。这种设计既确保限速不会影响当前的写入操作,又能有效控制内存的分配和消耗。

四、使用方法

该参数是租户级别的参数,可以在租户管理员账号下或者在sys租户中指定租户,设置内存写入达到 80% 开始限速,并保证剩余内存足够提供 2h 的写入限速,示例:

obclient> ALTER SYSTEM SET writing_throttling_trigger_percentage = 80;
Query OK, 0 rows affected
obclient> ALTER SYSTEM SET writing_throttling_maximum_duration = '2h';
Query OK, 0 rows affected
  
或者在sys租户中指定租户
obclient> ALTER SYSTEM SET writing_throttling_trigger_percentage = 80 tenant=<tenant_name>;

五、使用场景

1. 创建租户时使用 在写压力比较大的情况下,比如做导入数据时,限制写入速度也是一种简单高效的解决方法,虽然OceanBase的LSM-Tree存储引擎架构可以及时冻结memtable并释放内存,但在写入速度高于转储速度的场景下,仍有可能导致Memstore耗尽。最新版本4.0默认开启此配置,结合转储配置,可以有效控制Memstore的消耗。

2. 发现qps异常下降时,尤其是包含大量写时,也可以通过以下方式确认是否是由于写入限制导致。

  • 系统表

    如果是触发限速导致的qps值下降,根据上面的代码分析可知,会记录在session_event表中,事件名是“memstore memory
    page alloc wait”。

select * from v$session_event where EVENT='memstore memory page alloc wait' \G;
*************************** 94. row ***************************
           CON_ID: 1
           SVR_IP: 10.186.64.124
         SVR_PORT: 22882
              SID: 3221487713
            EVENT: memstore memory page alloc wait
      TOTAL_WAITS: 182673
   TOTAL_TIMEOUTS: 0
      TIME_WAITED: 1004.4099
     AVERAGE_WAIT: 0.005498403704981032
         MAX_WAIT: 12.3022
TIME_WAITED_MICRO: 10044099
              CPU: NULL
         EVENT_ID: 11015
    WAIT_CLASS_ID: 109
      WAIT_CLASS#: 9
       WAIT_CLASS: SYSTEM_IO
  • 日志

通过grep ‘report write throttle info’ observer.log ,如果输入如下日志就可以确定是由于限速导致的。

[2023-04-17 17:17:30.695621] INFO  [COMMON] speed_limit (ob_fifo_arena.cpp:319) [26466][T1_L0_G0][T1][Y59620ABA407C-0005F9818D1BFE06-0-0] [lt=2] report write throttle info(alloc_size=32, attr_=tenant_id=1, label=Memstore, ctx_id=1, prio=0, throttling_interval=0, max_seq_=11045142952, clock_=11045143112, cur_mem_hold=524288000, throttle_info_={decay_factor_:"6.693207379708156213e-02", alloc_duration_:7200000000, trigger_percentage_:21, memstore_threshold_:2147483600, period_throttled_count_:0, period_throttled_time_:0, total_throttled_count_:0, total_throttled_time_:0}, seq=11045142952)
同时grep 'throttle situation' observer.log,可以看到这次限速的具体内容。

[2023-04-17 17:17:31.006880] INFO  [STORAGE] ~ObStorageTableGuard (ob_storage_table_guard.cpp:109) [26466][T1_L0_G0][T1][Y59620ABA407C-0005F9818D1BFE06-0-0] [lt=85] throttle situation(sleep_time=4, time=1, seq=11048795064, for_replay_=false, cost_time=7025)

本文关键字: #Oceanbase# #写入限速#

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
//供学习用,禁止用于商业用途。 2012.04.20   OceanBase解决什么问题   许多公司的核心资产是各种各样的商业数据,例如淘宝的商品、交易、订单、购物爱好等等,这些数据通常是结构化的,并且数据之间存在各种各样的关联,传统的关系数据库曾经是这些数据的最佳载体。然而,随着业务的快速发展,这些数据急剧膨胀,记录数从几千万条增加到数十亿条,数据量从百GB增加到数TB,未来还可能增加到数千亿条和数百TB,传统的关系型数据库已经无法承担如此海量的数据。OceanBase解决不断增加的结构化数据存储与查询的问题。   从Eric Brewer教授的CAP(一致性C: Consistency, 可用性A: Availability,分区容错性P: Tolerance of network Partition)理论角度分析,作为电子商务企业,淘宝和其他公司的业务对一致性和可用性的要求高于分区容错性,数据特征是数据总量庞大且逐步增加,单位时间内的数据更新量并不大,但实时性要求很高。这就要求我们提供一套更加偏重于支持CA特性的系统,同时兼顾可分区性,并且在实时性、成本、性能等方面表现良好。   OceanBase的架构   OceanBase的逻辑架构简图    ▲   OceanBase架构的一些基本概念   主键   row key,也称为primary key,类似于DBMS的主键,与DBMS不同的是,OceanBase的主键总是二进制字符串(binary string),但可以有某种结构。OceanBase以主键为顺序存放表格数据   sstable   一种数据存储格式,OceanBase用来存储一个或几个表的一段按主键连续的数据   tablet   一个表按主键划分的一个(前开后闭的)范围,通常包含一个或几个sstable,一个tablet的数据量通常在256MB左右   基准数据和动态数据   OceanBase以增量方式记录一段时间内的表格数据的增删改,从而保持着表格主体数据在一段时间内相对稳定,其中增删改的数据称为动态数据(通常在内存,也称为内存表),而一段时间内相对稳定的主体数据称为基准数据,基准数据和转储后(保存到SSD固态盘或磁盘)的动态数据以sstable格式存储   ChunkServer   保存基准数据的服务器,通常是多台,为了避免软件硬件故障导致的服务中断,同一份基准数据通常保存了3份并存储在不同ChunkServer上   UpdateServer   保存动态数据的服务器,一般是单台服务器。为了避免软件硬件故障导致的服务中断,UpdateServer记录commit log并通常使用双机热备   MergeServer   进行静态动态数据合并的服务器,常常与ChunkServer共用一台物理服务器。MergeServer使得用户能够访问到完整的最新的数据   RootServer   配置服务器,一般是单台服务器。为了避免软件硬件故障导致的服务中断,RootServer记录commit log并通常采用双机热备。由于RootServer负载一般都很轻,所以它常常与UpdateServer共用物理机器   冻结   指动态数据(也称为内存表)的更新到一定时间或者数据量达到一定规模后,OceanBase停止该块动态数据的修改,后续的更新写入新的动态数据块(即新的内存表),旧的动态数据块不再修改,这个过程称为冻结   转储   出于节省内存或者持久化等原因将一个冻结的动态数据块(内存表)持久化(转化为sstable并保存到SSD固态盘或磁盘上)的过程   数据合并(merge)   查询时,查询项的基准数据与其动态数据(即增删改操作)合并以得到该数据项的最新结果的过程。此外,把旧的基准数据与冻结的动态数据进行合并生成新的基准数据的过程也称为数据合并   联表(join)   一张表与另一张或几张表基于主键的左连接关系,类似于DBMS的自然连接   COW   Copy on Write的缩写,在OceanBase中特指BTree在更新时复制数据备份写入,避免系统锁的技术手段   OceanBase的特点   OceanBase功能   OceanBase设计和实现的时候暂时摒弃了不紧急的DBMS的功能,例如临时表,视图(view),研发团队把有限的资源集中到关键点上,当前OceanBase主要解决数据更新一致性、高性能的跨表读事务、范围查询、join、数据全量及增量dump、批量数据导入。   OceanBase数据访问特点   虽然数据总量比较大,但跟许多行业一样,淘宝业务一段时间(例如小时或天)内数据的增删改是有限的(通常一天不超过几千万次到几亿次),根据这个特点,OceanBase把一段时间内的增删改等修改操作以增量形式记录下来(称之为动态数据,通常保存在内存中),这样也使得了主体数据在一段时间内保持了相对稳定(称之为基准数据)。   由于动态数据相对较小,通常情况下,OceanBase把它保存在独立的服务器UpdateServer的内存中。以内存保存增删改记录极大地提高了系统写事务的性能。此外,假如每条修改平均消耗100 Bytes,那么10GB内存可以记录100M(即1亿)条修改,且扩充UpdateServer内存即增加了内存中容纳的修改量。不仅如此,由于冻结后的内存表不再修改,它也可以转换成sstable格式并保存到SSD固态盘或磁盘上。转储到SSD固态盘后所占内存即可释放,并仍然可以提供较高性能的读服务,这也缓解了极端情况下UpdateServer的内存需求。为了应对机器故障,动态数据服务器UpdateServer写commit log并采取双机(乃至多机)热备。由于UpdateServer的主备机是同步的,因此备机也可同时提供读服务。   因为基准数据相对稳定,OceanBase把它按照主键(primary key,也称为row key)分段(即tablet)后保存多个副本(一般是3个)到多台机器(ChunkServer)上,避免了单台机器故障导致的服务中断,多个副本也提升了系统服务能力。单个tablet的尺寸可以根据应用数据特点进行配置,相对配置过小的tablet会合并,过大的tablet则会分裂。   由于tablet按主键分块连续存放,因此OceanBase按主键的范围查询对应着连续的磁盘读,十分高效。   对于已经冻结/转储的动态数据,OceanBase的ChunkServer会在自己不是太繁忙的时候启动基准数据与冻结/转储内存表的合并,并生成新的基准数据。这种合并过程其实是一种范围查询,是一串连续的磁盘读和连续的磁盘写,也是很高效的。   传统DBMS提供了强大的事务性、良好的一致性和很短的查询修改响应时间,但数据规模受到严重制约,缺乏扩展性;现代云计算提供了极大的数据规模、良好的扩展性,但缺乏跨行跨表事务、数据一致性也较弱、查询修改响应时间通常也较长,OceanBase的设计和实现融合了二者的优势:   --------------------------------------------------------------------------------   UpdateServer:类似于DBMS中的DB角色,提供跨行跨表事务和很短的查询修改的响应时间以及良好的一致性。   ChunkServer:类似于云计算中的工作机(如GFS的chunk server),具有数据多副本(通常是3)、中等规模数据粒度(tablet大小约256MB)、自动负载平衡、宕机恢复、机器plug and play等特点,系统容量及性能可随时扩展。   MergeServer:结合ChunkServer和UpdateServer,获得最新数据,实现数据一致性。   RootServer:类似于云计算中的主控机(如GFS master),进行机器故障检测、负载平衡计算、负载迁移调度等。   --------------------------------------------------------------------------------   上述的DBMS和云计算技术的优势互补使得OceanBase既具有传统DBMS的跨行跨表事务、数据的强一致性以及很短的查询修改响应时间,还有云计算的海量数据管理能力、自动故障恢复、自动负载平衡以及良好的扩展性。   OceanBase当前在淘宝的应用   OceanBase现在已经应用于淘宝收藏夹,用于存储淘宝用户收藏条目和具体的商品、店铺信息,每天支持4~5千万的更新操作。等待上线的应用还包括CTU、SNS等,每天更新超过20亿,更新数据量超过2.5TB,并会逐步在淘宝内部推广,也期待外部合作者。   主要的性能数据   测试软硬件环境   Red Hat Enterprise Linux Server release 5.4 (Tikanga)   gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)   Intel(R) Xeon(R) CPU E5520 @ 2.27GH   ChunkServer & MergeServer:Memory 16GB Disk 300GB SAS*10 NO Raid   UpdateServer & RootServer:Memory 48GB Disk 300GB SAS*6 Raid1   测试环境部署简图   ▲   测试数据规模   21亿条数据,基准数据3备份。   测试Schema   两张表,其中表1中有21列,表2中11列。   其中表1中的11列和表2中的11列存在join关系。   单条记录大小为500字节。   测试性能曲线图   Range数据查询   ▲   单条数据查询   ▲   当压力最大时,ChunkServer单台输出数据90MB/S,已经接近了千兆网卡的极限   更新数据   ▲

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值