在官方文档中看到这样的一个表格，有几个疑问如下：
1）memtable和table、partition、observer、zone的对应关系到底是怎样的？
2）如果memtable是 unit 实例的一部分，而unit实例只是在每个zone上有分布，并不是zone内的每个observer都有有unit实例，更不用说parttion，那么observer级别、partiton级别的 转储是怎么做的？
这个是在哪看到的？4.x的转储与合并都是租户级别的
OceanBase 2.x 版本中，MemTable、Table、Partition、Observer 和 Zone 之间的对应关系如下：
-
MemTable：MemTable 是 OceanBase 数据库的内存存储引擎的一部分，它由 BTree 和 Hashtable 组成。在插入/更新/删除数据时，数据被写入内存块，在 HashTable 和 BTree 中存储的均为指向对应数据的指针。MemTable 主要用于存储最新的数据变更，这些数据最终会被转储到磁盘上成为 SSTable。
-
Table：在 OceanBase 中，表（Table）可以被划分为多个分区（Partition），每个分区可以独立地分布在不同的 Observer 上。这意味着一个表的数据可能分布在多个物理节点上，从而实现了数据的水平扩展。
-
Partition：分区（Partition）是表的一个逻辑部分，每个分区可以包含表的一部分数据。分区的设计允许 OceanBase 在多个 Observer 之间分配工作负载，提高了系统的并发处理能力和数据的可管理性。
-
Observer：Observer 是 OceanBase 的一个实例，负责处理客户端请求。每个 Observer 可能会管理多个分区，这些分区可以属于不同的表。当客户端向 OceanBase 发送请求时，请求会被路由到相应的 Observer，由该 Observer 处理请求并返回结果。
-
Zone：Zone 是一组具有相同地理位置或网络属性的 Observer 的集合。Zone 的设计是为了实现高可用性和灾难恢复。通常情况下，一个 OceanBase 集群会跨多个 Zone 部署，以确保即使某个 Zone 出现故障，整个集群仍然能够正常运行。
综上所述，在 OceanBase 2.x 版本中，MemTable 存储了最新的数据变更，这些变更最终会被转储到磁盘上的 SSTable。表（Table）可以被划分为多个分区（Partition），每个分区可以独立地分布在不同的 Observer 上。Observer 是处理客户端请求的实例，而 Zone 是一组具有相同地理位置或网络属性的 Observer 的集合，用于实现高可用性和灾难恢复。
OceanBase 2.x 中的转储机制涉及多个层面，包括 MemTable 和 SSTable 的处理以及分层转储策略。
a. MemTable 和 SSTable 的处理:
- 在 OceanBase 中，数据首先被写入到内存中的 MemTable。当 MemTable 达到一定大小时，会触发转储操作，即将 MemTable 中的数据持久化到磁盘上的 SSTable 中。
b. 分层转储策略:
-
从 V2.2 版本开始，OceanBase 引入了分层转储策略，以解决单一 SSTable 随着转储次数增加而导致的性能问题。分层转储包括 L0 层（Mini SSTable）、L1 层（Minor SSTable）和 L2 层（Major SSTable）。
-
L0 层（Mini SSTable）：被冻结的 MemTable 会直接 Flush 为 Mini SSTable。OceanBase 内部可以同时存在多个 Mini SSTable。
-
L1 层（Minor SSTable）：大多数情况下仅有一个 Minor SSTable。每次下压都会在 L1 层生成新的 Minor SSTable，代替原有的 Minor SSTable。
-
L2 层（Major SSTable）：基线数据，在合并时产生。一般情况下仅有一个。
c. Observer 级别和 Partition 级别的转储:
-
Observer 级别转储：每个 observer 节点负责其所在资源单元（UNIT）的数据。由于 UNIT 仅在每个 zone 上有分布，并非每个 observer 都有 UNIT 实例，因此 observer 级别的转储是指在每个 observer 节点上对其管理的 MemTable 和 SSTable 进行转储操作。
-
Partition 级别的转储：在 OceanBase 中，分区（Partition）与 Tablet 一一对应。用户可以通过特定的 SQL 语句对指定的 Tablet 发起转储操作。例如：
ALTER SYSTEM MINOR FREEZE TABLET_ID = tablet_id;
其中，tablet_id 可以通过查询视图 DBA_OB_TABLE_LOCATIONS 来获取。
综上所述，尽管 UNIT 实例仅在每个 zone 上有分布，并非每个 observer 都有 UNIT 实例，但每个 observer 节点仍然会对其管理的 MemTable 和 SSTable 进行转储操作。对于分区级别的转储，用户可以针对特定的 Tablet 发起转储请求，确保数据的一致性和高效性。
谢谢！
还想请教下，默认table是不分区partition的，一个table默认一个partition，而partition是数据容灾的基本单位和高可用基本单位，类似hbase region 、tidb的region。如果不分区的情况，一个表有上亿或者几十亿的数据，但是底层只有一个size很大partition。维护起来 岂不是很不友好？！
一个表有上亿或者几十亿的数据是建议使用分区的，不做分区的话维护不友好主要体现在业务层
OceanBase的Partition和TiDB的Region都是用于实现分布式数据库中数据分片的技术，但它们在设计哲学、应用场景以及具体实现上存在一些差异。
设计理念：
-
OceanBase Partition：强调通过分区来提高查询效率和支持大规模并发处理能力。它支持范围分区、哈希分区等多种方式，并且可以灵活地调整分区策略以适应不同的业务需求。
-
TiDB Region：采用的是基于Raft一致性算法的数据复制模型，每个Region代表了一段连续键值范围的数据。TiDB自动将表分成多个Region，并根据负载情况动态调整这些Region的位置，以达到负载均衡的目的。
-
OceanBase 的分区机制 更适合需要定制和优化的场景，尤其是在处理大表和复杂查询时。虽然设计和管理较为复杂，但可以通过合理的分区策略显著提升性能和可用性。
-
TiDB 的 Region 机制 更适合需要自动管理和调度的场景。虽然粒度较细可能导致一些额外的开销，但自动管理特性减少了人工干预的需求。