有关这个,
疑问二: 这个限制读写速率假如设置为500mb/s真的能提高compact读写速率吗?(默认是30mb/s), 修改后那么自动和手动的compact都是按照这速度吗???
疑问三: 开启自动的compact后, 还有必要手动执行compact吗?
疑问四: 这个手动的submit job compact只是正对当前spacs吗?
疑问五: drop 操作会删除数据, 那么自动compact和手动compact后都会真正的从磁盘删除数据吗? 我试了手动的compact确实是从磁盘删除了
额外疑问, int和double和范围一样吗??? 还有没有比int更大的整型数据类型呢?
疑问一: 改这个配置的话, 一定要修改成从本地配置文件读取吗?
wey: 不是所有的配置都做成了可以从meta去集中配置（local config 的反面:false)，这里需要local false，然后通过文件或者启动参数配置。
疑问二: 这个限制读写速率假如设置为500mb/s真的能提高compact读写速率吗?(默认是30mb/s), 修改后那么自动和手动的compact都是按照这速度吗???
wey: 这里是上限，是同时影响自动和手动的 compaction
疑问三: 开启自动的compact后, 还有必要手动执行compact吗?
wey: 自动不是全量的，手动的全量 compaction 是更耗时的操作，但是它会让数据的混乱程度更小。定期手动全量 compaction 的收益是提升读写性能、代价是比自动增量更费时。
疑问四: 这个手动的submit job compact只是正对当前spacs吗?
wey: 是的，这个 job 需要在 Use Space 之后。
疑问五: drop 操作会删除数据, 那么自动compact和手动compact后都会真正的从磁盘删除数据吗? 我试了手动的compact确实是从磁盘删除了
wey: @critical27 可以帮忙回复一下么？ drop之后下一次auto compact 一定会删除么？
额外疑问, int和double和范围一样吗??? 还有没有比int更大的整型数据类型呢?
wey: double range 可以参考 IEEE-754
int 现在是最大的整形，还没有更大的哈
如果有需求超过int64，可以考虑存到两个 int 里，自己读写时候去做偏移处理
其实我一直没懂这从meta获取配置的说法, wey老师你看下我理解的对不对哈: /usr/local/nebula/etc这个路径下有meta, graph, storage三个目录中都有各自配置文件, 默认的话, graph和strage都是从nebula-metad.conf这个配置文件获取配置数据; 如果设置了local_config=true了, 那就是graph,storage会去 /usr/local/nebula/etc目录下的graph和storage目录下从各自的配置文件:nebula-graphd.conf nebula-storaged.conf获取配置了? 我理解的对吗???
rocksdb_db_options配置中也有个rete_limit配置, 这个和compact的rate_limit不是一回事吧?
关于三种不同进程在不同的配置的部分是正确的，对 true 的 理解也对哈。
这里通过 meta 管理的配置是所有配置的真子集，它的范围是 /usr/local/nebula/share/resources/gflags.json 里的哈。
local_config=flase 意味着 gflags 里的配置将忽略 conf 里的，反之将忽略 meta 之中集中集中管理的。
和 dev 同学确认了下，这两个是一个，都是只限制 compaction 的rate
对了, 忘了问, rete_limit单位都是mb/s吗? 这个很重要
MB per second, B 应该是 Byte
是Byte，通常描述数据在网络（协议）上传输时使用bit，当数据通过数据（协议）传输时使用Byte
不管是啥, 我都没办法提高速度了, 默认是0不限制, … 
疑问一: 改这个配置的话, 一定要修改成从本地配置文件读取吗?
这个配置的意义在于启用配置文件
疑问二: 这个限制读写速率假如设置为500mb/s真的能提高compact读写速率吗?(默认是30mb/s), 修改后那么自动和手动的compact都是按照这速度吗???
compact速率与系统性能有关，这个设置是为了避免compact影响nebula graph的整体性能而做的一个配置项，本身不是一个优化性能的选项。如果你对compact速度有一定要求，需要先释放这里的限制。
疑问三: 开启自动的compact后, 还有必要手动执行compact吗?
开启自动compact后，通常没必要手动跑compact，等自动回收就行
疑问四: 这个手动的submit job compact只是正对当前spacs吗?
是的，因为你在执行这个命令的时候，已经在某个space下了。 自然无法管理其他的space
疑问五: drop 操作会删除数据, 那么自动compact和手动compact后都会真正的从磁盘删除数据吗? 我试了手动的compact确实是从磁盘删除了
compact后会真正的删除数据，你的测试结果是正确的。自动和手动的结果没区别，只是如何触发compact的区别而已。
额外疑问, int和double和范围一样吗??? 还有没有比int更大的整型数据类型呢?
不一样，详情见文档 https://docs.nebula-graph.com.cn/2.0.1/3.ngql-guide/3.data-types/1.numeric/#int
感谢再次回复, 其他我没问题, 就是这个我因为之前关了自动compact导入200亿数据,途中报错了, 报错信息是 Too many open files…就是打开句柄太多了, 我看了一下最大的是storage, 990W+ 最终导致我啥也干不了了, 一直报错(手动compact也这个错误); 第二次重新新开始个集群开着自动compact才能一直导入成功, 根据我现有的经验, 我理解自动的compact是回收的慢, 手动的能快速回收大量资源句柄, 举个例子, 我80亿数据导入刚刚完成, 句柄已经300W了, 然后我立马执行全量compact, 句柄能马上回收到30W+
最终目的, 其实我们机器还是很强的, 就想让在做compact和stats的时候让快点, 下面是我自己百度配置的一些rocksdb参数, 希望能导入数据速度快点, 望指正
该主题在最后一个回复创建后7天后自动关闭。不再允许新的回复。
