fx408

初步做了一些分析，任务管理调度器可能需要具备以下能力： 1. 节点级总并发控制 2. 不同的任务类型需要有独立的总并发控制：降采用和分级存储一般是老的shard，任务可以慢一些，要给compaction和merge留资源 3. shard 粒度，调度器生命周期跟随 shard 4. 表粒度调度控制能力： - 按任务优先级调度，高优先级任务进入时，终止低优先级任务运行，并暂停低优先级任务调度 - 支持表粒度暂停、重启任务

insert cpu,host=server-01,region=west_cn value=75.3 Do not add double quotes. Double quotes are also considered part of the data

The second feature is under development https://github.com/openGemini/openGemini/issues/452

目的是什么呢？网络隔离还是容灾，或者其他需求？

实时删除数据的代价过大，可以使用标记删除 在查询时，对查询条件做重写，加入时间范围过滤或重写过滤条件 在后台compaction任务运行时删除数据或等待过期策略执行

> > 实时删除数据的代价过大，可以使用标记删除 > > 在查询时，对查询条件做重写，加入时间范围过滤或重写过滤条件 > > 在后台compaction任务运行时删除数据或等待过期策略执行 > > 如果加标记，会不会影响到现有的数据格式，导致前后版本不兼容的问题？ 将标记删除的信息存放在 meta 节点（需要评估meta元数据是否存在兼容性问题， 或使用其他方式存储），磁盘上的文件不需要修改

``` type Field struct { Key string NumValue float64 StrValue string Type int32 } ``` 数据解析过程导致的精度丢失 浮点型和整型数据，在解析的过程中，都是采用 双精度浮点型float64 来存储 对于太大的数，将出现精度丢失的现象 修改建议： 1. 使用string 存储 2. 改为毫秒存储 3. 若该字段和时间戳相同，是否可以直接使用时间戳代替 4. @xiangyu5632...

##### 一种大批量数据导入流程: - 客户端按指定的格式组织数据，批量提交到sql 节点 - sql 节点校验数据无误后，按规则分割数据，转发到store 节点 - store 节点 跳过 写wal 和 写memtable 流程，直接生成TSSP文件 ##### 客户端数据结构： - SeriesKey 是时间线，按时间线分块组织数据 - Meta 是元数据，包含列名称，列类型等 - Block按照 TSSP 文件中的 ChunkData...

初步简单测试，通过火焰图分析，使用新协议后，单机版写入性能可提升 30%+ #### 客户端数据编码 - 客户端使用内核 record.Record 进行数据组织，按 db+rp+measurement 粒度划分，发挥批处理能力 - tag 和 field 分表使用 Record 进行存储，但要求行对齐 - 服务端会对 tag 和 field 按字典序排序，influx.Row 的结构会对每行数据进行排序，而 Record 结构是一批数据排序一次，大幅降低排序开销 ``` type Batch struct...

#### 工作拆解： 1. 数据结构设计(完成) 2. 客户端协议编码 - Record 结构不使用 protobuf 模型，避免额外转换的开销 - 使用 内核已有的方法 进行编解码 `record.Record.Marshal`, `record.Record.Unmarshal` 3. 客户端并发模型设计和编码 - 尽量发挥批处理能力，降低QPS - 例如：固定N行一个批次，最大M个并发？ 4. GRPC 客户端和服务端代码编写 - 需要支持TLS双向认证 5. 服务端对接数据写入流程...