ToB企服应用市场:ToB评测及商务社交产业平台

标题: IoTDB 常见题目 Q&A 第二期 [打印本页]

---

作者: 兜兜零元    时间: 2024-12-18 15:12
标题: IoTDB 常见题目 Q&A 第二期
关于 IoTDB 的 Q&A
  IoTDB Q&A 第二期来啦~我们将定期汇总社区讨论频仍的题目，并展开进行具体回答，通过积聚常见题目“小百科”，方便大家使用 IoTDB。
  Q1：集群扩容方法
  

  题目
  题目1：当 IoTDB 集群的存储占用到达多少时，建议增加节点？是等到存储完全满，还是到达一半时就进行扩容？如果集群存储已满，是否需要手动进行数据清算，好比设置 TTL，还是可以直接忽略，只增加节点即可？
  题目2：目前使用三台服务器构建的集群设置了元数据 3 副本和数据 2 副本。如今想要将一年前的数据迁移到其他服务器上以释放空间，这个操作应该如何执行？
  

  方案
  （1）数据清算与扩容建议
  

• 自动数据清算：可以通过设置 TTL 自动清算逾期数据，实现存储空间的自动回收。
  

  

• 扩容机遇：建议根据集群存储资源的使用趋势和业务数据增长预期来决定扩容机遇。一样平常而言，当存储利用率靠近高水位线（例如 70%-80%）时，应考虑扩容以确保服务稳定性，而不是等到存储完全占满。
  

  

• 存储满时处理：若集群存储空间已满，建议优先通过设置 TTL 或其他方式清算无用数据。在此底子上，可以根据需求增加集群节点以提升存储本事。
  

  （2）存储扩展方法
  

• 扩展磁盘：在当前集群负载正常的情况下，可以通过增加磁盘容量来扩展存储资源。IoTDB 支持多盘目次设置，可以灵活扩展存储本事。
  

  （3）汗青数据迁移操作
  

• 数据迁移步骤：对于需要迁移的汗青数据，可以利用 IoTDB 的数据同步功能，将一年前的数据迁移至其他集群或服务器进行备份。
  

  

• 释放存储空间：迁移完成后，在当前集群中通过 TTL 设置清算已迁移的汗青数据，从而释放存储空间。
  

  

• 操作注意事项：在进行数据迁移之前，确保目标服务器或集群具备足够的存储资源，并对迁移的关键步骤进行备份和测试，以确保数据安全和完整性。
  

  Q2：GC 时间过长导致集群卡住
  

  题目
  1. 我们的业务系统在 IoTDB 执行 GC 时遭遇了查询和写入操作的短暂卡顿。别的，IoTDB 在运行一段时间后，老年代内存占用过高，纵然在停止大量写入操作后仅进行查询，内存回收仍旧不力。大约 4 至 5 天后，系统会记录此日志，并在此期间变得卡顿。虽然可以通过定时重启来缓解，但我们想寻求避免重启的解决方案。
  

  系统环境：
  

• Java 版本：openjdk version "1.8.0_222-ea"；
  
• 测点数量：352130；
  
• DataNode MEMORY_SIZE：42G；
  
• 部署方式：单机部署
  

  2. 我们观察到 IoTDB 的 GC 时间过长，是否需要增加内存？当前使用的是 JDK 11 版本。

1. Accumulated GC time within current observation window: 10810 ms；WARN o.a.i.c.s.m.GcTimeAlerter:42 - Gc Time Percentage: 45%

复制代码

3. 在 IoTDB 1.3.2 版本和 JDK 17 环境下，我们的 130 GB 内存数据节点在处理 1.06 亿条时序数据时，GC 操作导致系统挂起。
  

  题目分析
  

• GC 耗时高： 垃圾回收（GC）过程耗时过长，影响了系统性能。
  
• 内存占用高： 系统内存占用过高，导致内存回收不力，影响系统稳定性。
  

  

  解决方案
  1. 增加内存：考虑增加物理内存以缓解内存压力。
  2. 更新数据库：将 IoTDB 更新到最新版本，以利用大概的性能改进。
  3. 更新 JDK 并更换 GC 算法：
  

• 
  
  
  
  • G1：适用于低停顿时间的用户场景。根据当前系统的运行情况网络性能监控信息，动态调整参数，以提供最合适的停顿时间或最大的吞吐量。
    
  
  

  

• 
  
  
  
  • PS：适用于需要高吞吐量的用户场景。
    
  
  

  4. 优化查询操作：避免执行查询操作的查询范围过大。
  5. 关闭最新点缓存：如果没有查询最新点的需求可以关闭最新点缓存（enable_last_cache）以释放内存。
  Q3：如何修改测点类型
  

  题目
  1. 如果在数据插入时未指定属性值的类型，而后期需要将本来推断为 INT32 类型的数据逼迫转换为 TEXT 类型，应如何处理？
  2. 如果字段类型不支持直接修改，是否有其他方案可以实现字段类型的调整？
  3. 如何将装备某个属性的类型从 TEXT 更改为 LONG？
  4. 如何修改已存在数据序列的字段类型，例如将本来为 FLOAT 类型的字段修改为 INT 类型？
  5. 是否可以更改 timeseries 的数据类型，例如将 FLOAT 类型更改为 DOUBLE？
  

  缘故起因
  IoTDB 不支持修改已经创建测点的类型。
  

  方案
  （1）如果不需要旧数据：
  方案一：删除旧序列重新创建新元数据
  删除旧序列，并在创建新元数据时手动指定目标数据类型，然后重新写入数据。
  方案二：修改自动推断计谋设置
  删除旧序列，修改自动推断计谋设置并重启服务，以实现自动创建新的目标类型元数据。
  自动创建模式设置：

1. ####################
2. ### Configurations for creating schema automatically
3. ####################
6. # Whether creating schema automatically is enabled
7. # If true, then create database and timeseries automatically when not exists in insertion
8. # Or else, user need to create database and timeseries before insertion.
9. # effectiveMode: hot_reload
10. # Datatype: boolean
11. enable_auto_create_schema=true
14. # ALL data types: BOOLEAN, INT32, INT64, FLOAT, DOUBLE, TEXT
17. # register time series as which type when receiving boolean string "true" or "false"
18. # effectiveMode: hot_reload
19. # Datatype: TSDataType
20. # Options: BOOLEAN, TEXT
21. boolean_string_infer_type=BOOLEAN
24. # register time series as which type when receiving an integer string and using float or double may lose precision
25. # effectiveMode: hot_reload
26. # Datatype: TSDataType
27. # Options: DOUBLE, FLOAT, INT32, INT64, TEXT
28. integer_string_infer_type=DOUBLE
31. # register time series as which type when receiving a floating number string "6.7"
32. # effectiveMode: hot_reload
33. # Datatype: TSDataType
34. # Options: DOUBLE, FLOAT, TEXT
35. floating_string_infer_type=DOUBLE
38. # register time series as which type when receiving the Literal NaN.
39. # effectiveMode: hot_reload
40. # Datatype: TSDataType
41. # Options: DOUBLE, FLOAT, TEXT
42. nan_string_infer_type=DOUBLE

复制代码

（2）如果需要旧数据：
  1. 使用 Select into + Cast：具体支持的转换规则详见官方文档：内置函数与表达式章节（可点击阅读原文跳转）。

1. # 举例：将DOUBLE类型转成TEXT类型
2. select cast(L1_BidPrice as TEXT) into root.stock.Legacy.0700HK(L1_BidPrice_back) from root.stock.Legacy.0700HK

复制代码

2. 导入导出工具：将数据导出 CSV 文件，修改类型后再重新导入目标类型一致的序列。
  3. 自定义步调：
  

• 
  
  
  
  • TsFile 重写：调用 TsFile 写入 API 重写 TsFile。
    
  • Session 数据重写：查询旧数据，修改为指定类型后再批量写入到新测点。
    
  
  

  Q4：数据备份方案
  

  题目
  1. 管理数万装备，若每天为每个装备创建备份，将产生海量备份文件。是否有除了文件导出之外的其他数据备份方案？
  2. 想要实现整个 IoTDB 文件的备份，有哪些可行的方案？
  3. IoTDB 是否提供了内置的备份和恢复工具？这些工具的使用文档在哪里可以找到？对于需要 24 小时不间断运行的系统，应如何进行数据备份？
  4. 在实验按天导出数据进行备份时，碰到了内存不足的错误。纵然将设置文件中的内存大小从 10G 增加到 12G，题目仍旧存在。
  5. 如果查询本应返回无数据，却也报告内存不足，那么分批备份是否应该基于时间，还是根据测点数量预估内存？
  

  缘故起因及方案
  数据备份方案如下：
  

• 物理备份（全量）：使用本地升级备份工具（通过硬链接对原有数据进行备份），在执行备份之前，要确保系统已经停止运行。
  

1. ./tools/backup.bat
2. ./tools/backup.sh

复制代码

• 逻辑备份：利用 pipe 将数据备份到别的的节点。
  
  
  
  • IoTDB 备份：在 TsFile 文件级别进行备份，备份操作将在 TsFile 刷盘时同步。
    
  • TimechoDB 备份：接纳及时同步与文件同步相结合的方式进行备份。
    
  • 恢复过程：通过反向开 pipe 写回数据，这些数据将被放入乱序区，随后系统将自动进行合并处理。
    
  
  
• 多级存储备份：根据差别的时间范围，接纳多级存储计谋来备份数据。
  
• 元信息和数据周期导出备份：
  
  
  
  • 导出时如果内存不足，则需要调大 DataNode 的内存大概分批导出。
    
  • 导出时会根据测点的数量来进行内存预估。建议按照装备分批导出，不保举按照序列分批导出。
    
  
  

  Q5：错误 - There are no available SchemaRegionGroup RegionGroups currently
  

  现象
  

• 现象1：
  

  

  

• 现象2：系统碰到了一个连续增长的 schema_region 目次题目，导致频仍出现内存溢出（OutOfMemory）错误。在路径 data/datanode/consensus/schema_region 下，系统每分钟都会创建多个以“4747*”为模式的目次。目前有二十多个数据库，每次实验重启数据库时，Java 虚拟机（JVM）就会报告内存不足的错误。
  
  

  

  缘故起因
  

• 自动扩展机制：在默认设置下，每个 DataBase 下的 Region 数量是在既定可控范围内的。默认设置下每个数据库将根据其数据量自动扩展 SchemaRegionGroup 和 DataRegionGroup。每个 DataNode 节点上最少会自动创建 1 个 SchemaRegionGroup ，而每个 DataNode 预期管理的 SchemaRegion 的最大数量为 1。每个 DataNode 节点上最少会创建 2 个 DataRegionGroup，预期管理的 DataRegions 的最大数量为 5。
  
  
  
  
• DataBase 数量与 Region 关系：DataBase 的数量直接关系到 Region 的数量。例如，在 1C3D 的集群中，在 1 个 DataBase 下创建 n*100 个装备/测点，和在 n*100 个 DataBase 下分别创建 1 个测点，所创建的 Region 数量会有显著差别。每个 Region 至少会保留 32 MB 的 WAL Buffer，因此 Region 数量的增加会导致内存开销增大。
  

  

• 合理控制 Region 数量：DataRegion 作为副本组的根本单位，绑定了固定命量的内存和 CPU 线程资源（例如 WAL 的堆外内存、Memtable 的 flush 线程等）。因此，IoTDB 集群需要控制 DataRegion 的数量适中，避免因为 DataRegion 太少导致写入并行度降落、资源利用不充分，或因 DataRegion 太多导致线程数量爆炸、写入性能降落。
  

  

  方案
  

• 低落内存使用量：通过低落各个模块的内存使用量，启动服务删除部分 DataBase 来恢复正常运行。
  

  具体设置参数如下：

1. wal_buffer_size_in_byte=8388608
2. schema_region_ratis_log_appender_buffer_size_max=4194304

复制代码

设置时可根据系统中的 DataRegion 数、SchemaRegion 数进行计算：wal_buffer_size_in_byte * DataRegion 数 + schema_region_ratis_log_appender_buffer_size_max * SchemaRegion 数 < OFF_HEAP_MEMORY * 0.8。

  此中，保留 20% 堆外内存用于各模块中的临时使用。
  

• 调整建模：修改建模方案，只管保证所有的序列创建在一个 DataBase 下，避免 Region 数量过多。
  

  

规上企业应用实例

  能源电力：中核武汉｜国网信通财产集团｜华润电力｜大唐先一｜上海电气国轩｜清安储能｜某储能厂商｜太极股份
  航天航空：中航机载共性｜北邮一号卫星
  钢铁、金属冶炼：宝武钢铁｜中冶赛迪｜中国恩菲
  交通运输：中车四方｜长安汽车｜城建智控｜德国铁路
  智慧工厂与物联：PCB 龙头企业｜博世力士乐｜德国宝马｜北斗智慧物联｜京东｜昆仑数据｜怡养科技｜绍兴安瑞思
  

  

  

  

  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4