有人试过OB 最大支持的数据量吗？

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.x
【问题描述】
有人试过OB 最大支持数据量级别不？我记得以前有听人说过单个observer 最大支持到100TB 级别的数据量，但是没有这么大的环境测试，如果超过100TB的话会有啥风险不？有人测试过吗？

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

1 个赞
#3

根据文档库中的信息，OceanBase 数据库在设计上支持非常大的数据量。具体参考以下信息：

  1. 单集群最大数据量
    根据文档标题为“OceanBase 数据库概述 → OceanBase 数据库概述 → 核心特性 → 水平扩展”的内容，OceanBase 支持的单集群最大数据量超过 3PB（参见文档片段 2 和片段 3）。这表明 OceanBase 在理论上能够处理远超 100TB 的数据量。

  2. 单表行数支持
    同样在上述文档中提到，OceanBase 支持的最大单表行数可达 万亿级，这意味着即使单表的数据量非常大，OceanBase 也能有效管理。

  3. 水平扩展能力
    OceanBase 的分布式架构允许通过增加节点实现透明水平扩展（参见文档片段 8：“集群级别的扩容和缩容”）。因此，即使单个节点的数据量接近上限，也可以通过添加更多节点来继续扩展存储能力。

  4. 关于单个 Observer 的限制
    虽然没有明确提到单个 Observer 的具体数据量上限，但结合其支持的单集群最大数据量（超过 3PB）以及分布式架构的特点，可以推测单个 Observer 的实际数据量上限会受到硬件资源（如磁盘容量、内存等）的影响。如果单个 Observer 的数据量超过一定规模（例如 100TB），可能会面临以下潜在风险：

    • 性能下降：随着数据量增大，查询性能可能会受到影响，尤其是在未优化的场景下。
    • 维护复杂度增加：大规模数据需要更精细的运维管理，例如备份、恢复、分区管理等。
    • 硬件瓶颈：单个 Observer 的磁盘 I/O、网络带宽等可能成为瓶颈。

  5. 测试与实践建议
    如果您计划测试超过 100TB 的数据量，建议从以下几个方面入手：

    • 硬件配置：确保单个 Observer 的磁盘容量、内存和 CPU 资源充足。
    • 分区策略：合理设计分区表，避免单一分区过大。
    • 监控与调优：使用 OCP 或其他工具监控性能指标，及时发现并解决潜在问题。

综上所述，OceanBase 在设计上支持远超 100TB 的数据量，但实际应用中需要根据硬件资源和业务需求进行优化和调整。如果超过 100TB，主要的风险在于性能和维护复杂度的提升，而非功能上的限制。

检索到的文档如下:

  1. 事务控制概述
  2. OceanBase 数据库概述
  3. OceanBase 概述
  4. 产品 FAQ
  5. 使用限制
  6. 高可用架构概述
  7. 集群级别的扩容和缩容
  8. 数据库内存上限
  9. audit_log_max_size
#4

扯淡

#5

过于忧虑了。
即使单个节点你真的准备了 100TB 的存储，实际上也不这么用。
你想，如果这个节点故障了要重建，那不得要很久。

OB 是分布式数据库，分布式的特点通俗一点说有几点：

  • 人多力量大。一个节点干不了的事情多个节点一起干
  • 风险分散。超大的库表，可以分散到多个 节点存储

所以如果业务数据量非常大到 100TB+ ，这个 OB 集群不大可能是 1-1-1 的，应该是 N-N-N，N >=3 。
然后另外一个问题，OB 集群存储容量最大能多大呢？理论值不说，TPCC 1500+ 台机器(每个节点的数据文件大小 3982G） ,数据量应该超出了所有客户业务 OB 集群的数据量。

2 个赞
#6

“听人说”不如查官方文档~

#7

官方文档没有这个介绍，这个是之前听OB 的人有提过一嘴，但是他们也有人说没问题，可以支持上，所以超过具体有啥现象不清楚

#8

您的问题可能存在误解，实际上据我所知，OceanBase 官方文档中并未明确列出单个 Observer 的最大数据量限制以及超过该限制后的具体现象。不过，根据 OceanBase 的设计原理和分布式架构特点，可以推测以下可能的现象：

  1. 性能下降
    当单个 Observer 的数据量超过一定规模（例如 100TB），可能会导致以下性能问题：

    • 查询响应时间变长，尤其是涉及全表扫描或复杂 JOIN 操作的查询。
    • 写入性能下降，因为磁盘 I/O 和内存资源可能成为瓶颈。
    • 分区管理效率降低，尤其是在未优化的分区策略下。

  2. 资源耗尽风险

    • 磁盘空间不足：如果数据量持续增长而未及时扩展存储容量，可能会导致磁盘空间耗尽。
    • 内存压力增大：OceanBase 在运行过程中需要使用大量内存来缓存数据和执行查询计划。数据量过大可能导致内存不足，进而影响性能。
    • 网络带宽占用增加：大规模数据的读写操作会显著增加网络流量，可能导致网络拥塞。

  3. 运维复杂度提升

    • 备份和恢复时间延长：随着数据量的增长，备份和恢复操作所需的时间也会显著增加。
    • 故障恢复难度加大：在发生节点故障时，数据重分布和副本重建的过程可能会更加耗时。
    • 监控和调优难度增加：需要更精细的监控策略和调优手段来应对大规模数据带来的挑战。

  4. 潜在的系统行为变化

    • 事务超时风险：对于大规模数据的操作（如批量插入、更新或删除），事务可能更容易达到超时限制（参见文档片段 4：“关于超时时间”）。
    • 落盘频率增加：当内存不足以容纳中间结果时，SQL 算子可能会频繁将中间结果落盘，从而导致性能进一步下降（参见文档片段 2：“ERROR 4080 (HY013) : exceed memory limit”）。

建议

如果您计划测试超过 100TB 的数据量，建议从以下几个方面入手：

  • 硬件配置：确保单个 Observer 的磁盘容量、内存和 CPU 资源充足。
  • 分区策略：合理设计分区表，避免单一分区过大。
  • 监控与调优：使用 OCP 或其他工具监控性能指标，及时发现并解决潜在问题。
  • 水平扩展：通过添加更多节点来分担负载，避免单个 Observer 承担过大的数据量。

总结来说，虽然官方文档中没有明确说明超过 100TB 后的具体现象，但根据 OceanBase 的设计原理和实际应用经验，可以推测主要的风险在于性能下降、资源耗尽和运维复杂度提升。

检索到的文档如下:

  1. ob-operator
  2. 4000 ~ 4499
  3. ob_max_read_stale_time
  4. 在您开始前
  5. standby_fetch_log_bandwidth_limit
  6. V$OB_UNITS
  7. obdiag
  8. user_iort_up_percentage
  9. balancer_timeout_check_interval

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#9

OceanBase 概述-V4.3.5-OceanBase 数据库文档-分布式数据库使用文档

水平扩展

实现透明水平扩展，支持业务快速的扩容缩容，同时通过准内存处理架构实现高性能。支持集群节点超过数千个，单集群最大数据量超过 3PB，最大单表行数达万亿级。

超过数据量确实没有具体现象，超过3pb是我没有接触过的量级 :joy:

#10

:joy:这个我知道，多个节点堆PB级别的数据量，但是如果有一种场景，客户有三台大规格机器，盘很多，每台设置成一个zone，不考虑加机器的场景下，存入数据预计是每个observer 会存入200TB 多，

单个observer 最大承载的数据量是多少？超过的话会除了性能下降的情况，还有其他比如写不了数据之类的限制不？多个observer 承载PB级别，把压力分散开了确实是没问题，但是如果只是1-1-1 的模式，不知道极限是多少，以及极限后是否有其他异常情况

1 个赞
#11

这个确实是一个建议，但是有些场景比较奇葩，就是只有1-1-1的模式，机器资源和性能都非常高，而且盘给的很大，比如每台服务器上存储容量可以达到200TB 多，在不想加observer 的情况下，容纳100TB数据，就是不知道极限是多少，如果达到极限的话，除了性能下降外，还有其他比如数据写不进还是一些奇奇怪怪的问题？

#12

这个问题其实很少见，大部分都是采用多个observer 来容纳更多的数据量，从而提升集群的数据处理级别，而且测试资源需要比较大，很多时候都没有这类的测试，所以上社区看看有没有小伙伴有类似的场景，如果没有的话那就算了，感谢各位的回复

#13

恩。典型业务场景。 理论探讨一下，不一定对。

100TB 的单机容量，估计只有 SATA SSD 能撑得起这么大的容量（SATA HDD 就不建议，太慢了）。SATA SSD 单盘容量也有20T 的，用10块然后做 RAID 10 ，也能提供 100T 的存储容量。
坏盘时，直接替换坏盘，RAID 卡会自己补数据。对 OB 读写性能影响也会有一点。不过这样的集群也只能是 OLAP 场景了，不指望性能很快了。
最大的风险是 RAID 卡坏了，那样 OB 节点大概率会 HANG住 。搞不好这个节点要重建，那时间也是相当的长。

其他潜在的挑战就是 合并了。默认渐进合并策略（大表变更合并时默认每次1%）对这种大容量数据合并是个优化。但可以预计合并时间还是有可能会非常的长。如果超出 24小时的周期，又影响了下一次合并。合并周期拉长，中间版本的数据量会很大，因此业务数据即使只有100TB ，数据文件的容量大小估计不得少于150TB，要预留充分的缓冲空间，以避免遭遇数据文件满的问题。合并策略就要修改为外部脚本控制合并，不用 OB 自带的合并策略。这样也许每周7天合并3-4 次。

合并有影响，备份自然也难免。这么大容量的数据库，传统数仓可能就选择放弃备份了。OB 还是建议有备份，每周一次备份吧 。备份时间如果很长 避免跟下次合并时间重叠。日志实时备份就不要了。那个量可能更恐怖。

100TB 的数据应该是很多表，避免单个表很大。单个表超过1TB 不知道会怎么样，看其他客户案例分享了。这种大表肯定很多，DDL 又是个挑战。DDL 最好是能一次性成功，并且尽量是无锁变更DDL，这样不会阻塞其他的数据导入或ETL任务等等。

2 个赞
#14

了解，感谢老师的回答