系统架构概念图
OceanBase数据库的存储引擎基于LSM Tree架构
静态基线数据（放在SSTable中）
动态增量数据（放在MemTable中）
本质上是一个基线加增量的存储引擎，跟关系数据 库差别很大，同时也借鉴了部分传统关系数据库存 储引擎的优点。
由于OceanBase 数据库采用基线加增量的设计，一部分数据在基线，一部分在增量，原理上每次查 询都是既要读基线 ，也要读增量 。为此， OceanBase数据库做了很多的优化，尤其是针对单行的优化。
内存分配（一）
OceanBase是支持多租户架构的准内存分布式数据库，对大容量内存的管理和使用提出了很高要求
OceanBase会占据物理服务器的大部分内存并进行统一管理
OceanBase是支持多租户架构的准内存分布式数据库，对大容量内存的管理和使用提出了很高要求
OceanBase会占据物理服务器的大部分内存并进行统一管理
通过参数设定observer占用的内存上限
memory_limit_percentage
memory_limit
memory_limit的默认单位为MB例如，memory_limit='40G'表示设置OceanBase 数据库进程的使用内存上限40GB。由于默认单位为MB，则memory_limit=40960 与memory_limit='40G'设置的值相同。
如果希望限制运行中的OceanBase数据库的内存大小，可以直接修改 memory_limit的值，使其达到预期。设置后，后台参数Reload线程会使其动态生效，无需重启。但是在设置时，需要保证memory_limit的值小于系统总的值。
参数说明
OceanBase提供两种方式设置observer内存上限：、
按照物理机器总内存的百分比计算observer内存上限：由memory_limit_percentage参数配置
直接设置observer内存上限：由memory_limit参数配置
memory_limit=0时，memory_limit_percentage决定observer内存大小；否则由memory_limit决定observer内存大小
以100GB物理内存的机器为例，下述表格展示了不同配置下机器上的observer
memory_limit_percentage |
mermory_limit |
Observer内存上限 |
|
场景1 |
80 |
0 |
80GB |
场景2 |
80 |
90GB |
90GB |
场景1：memory_limit=0，因此由memory_limit_percentage确定observer内存大小，即100GB*80% = 80GB
场景2：memory_limit='90GB'，因此observer内存上限就是90GB，memory_limit_percentage参数失效
内存分配（二）
OB系统内部内存
每一个observer都包含多个租户（sys租户 & 非sys租户）的数据，但observer的内存并不是全部分配给租户
observer中有些内存不属于任何租户，属于所有租户共享的资源，称为“系统内部内存”
通过参数设定“系统内部内存”上限 system_memory
租户可用的总内存 “observer内存上限”-“系统内部内存”
内存分配（三）
每个租户内部的内存总体上分为两个部分
不可动态伸缩的内存：MemStore， MemStore用来保存DML产生的增量数据，空间不可被占用
可动态伸缩的内存：KVCache， KVCache空间会被其它众多内存模块复用
MemStore
1.大小由参数memstore_limit_percentage决定，表示租户的 MemStore 部分占租户总内存的百分比。
2.默认值为50，即占用租户内存的50%
3.当MemStore内存使用超过freeze_trigger_percentage定义的百分比时（默认70%），触发冻结及后续的转储/合并等行为
KVCache
保存来自SSTable的热数据，提高查询速度
大小可动态伸缩，会被其它各种Cache挤占
内存结构总体结构回顾
