【 使用环境 】 测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.3.1
【问题描述】最近在测试环境的oceanbase的各种适配和测试，也在学习oceanbase的官方文档。知晓了oceanbase是一个分布式的可水平扩展的数据库系统，在此过程中也有一些疑惑一直没有得到解答，望oceanbase专家解答：
背景：在部署了一个3-3-3架构的oceanbase集群上创建一个10c100G规格3个全功能副本的租户，在该租户下创建了一个数据库，该数据库数据从mysql上迁移过来，mysql上的数据大小约1TB，迁移过来后数据表并未进行分区。因现在使用observer节点的存储能力有限，除去redo日志磁盘后能够用于数据存储的磁盘大小只有1TB左右。
1、现阶段在不对数据表做分区的情况下，在单机无法全量存储数据的时候，怎么扩容？是增加unit_num还是增加一个资源池，还是必须对数据表分区？
2、不对数据表做分区，增加unit_num或新增资源池这种方式可以扩容存储空间吗？
3、是不是数据必须存储在unit被调度的节点上？
4、每个zone一个全功能副本，那在新增unit_num后，是不是每个unit调度到的节点上有一份全量的数据？或者是部分数据？
5、如果在不增加unit_num的情况下，当单节点快无法存储全量数据时，数据会不会自动被分散到其他节点上，如果会的话，这样unit怎么计算？
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
说明你3个zone，每个zone有3台服务器，共9台服务器。unit_num最大可以是3，如果设置少了，比如只设置1，那每个zone下面只会有1台服务器存储空间可用。
按你说的MySQL节点才1T数据，OBServer单节点也有1T的数据盘空间，那目前是够用的。只是你unit为1，数据只会在每个zone其中一台上。
要扩容加大unit就行了，会自动分布数据。除非你只有1张非分区表
-
如何在不进行数据表分区的情况下，应对单机存储容量不足
应对单机存储容量不足，确实可以通过增加unit_num来实现水平扩展，这会增加新的 Unit 来分担存储压力，而不需要对数据表进行物理分区。另外，调整资源规格（垂直扩展）也是一种方式，但可能受限于单机硬件限制。添加资源池（如果是指在 OceanBase 中类似资源隔离的概念）更多是为了精细化管理资源，不一定直接增加存储空间，但可以帮助优化资源分配。 -
增加unit_num或新资源池能否扩大存储空间而不进行分区
增加unit_num可以扩大存储空间，因为这相当于在集群中添加了更多的存储单元来承载数据。新资源池的创建本身不直接增加存储空间，但通过合理配置资源池，可以更有效地管理和分配存储资源，间接支持存储扩容需求，且不需要对数据进行物理分区。 -
数据是否必须位于被调度的unit节点上
是的，OceanBase 通过其智能调度机制确保数据均匀分布在集群的所有 Unit 上。这意味着数据会被自动放置到当前活动的 Unit 节点上，以实现负载均衡和高可用性。 -
新增unit_num后，每个unit调度的节点上存储的是全量数据还是部分数据
新增unit_num后，随着数据的重新平衡，每个新老 Unit 上存储的将是整个租户数据的一部分，而非全量数据。OceanBase 会自动进行数据重分布，确保数据在所有 Unit 间均匀分布，以达到最佳的存储和计算负载均衡。 -
不增加unit_num时，数据是否会自动分散到其他节点，如何计算unit
如果不增加unit_num，在正常情况下，数据已经分布在当前的 Unit 节点上，OceanBase 会持续进行负载均衡，以优化数据分布。至于如何计算 Unit，这涉及到租户的资源规划，通常基于业务预期的 QPS、存储需求、并发度等因素。每个 Unit 的配置（如 CPU、内存、磁盘空间）需根据实际业务负载和未来增长预测来设定，确保既能满足当前需求，又留有一定的扩展空间。
具体信息可参考以下文档: