chengshiwen
commented
2 years ago 但是我看代码逻辑好像在一个circle中一个measurement只会存在一个node里面，也就是说如果这个表过于庞大导致没有单独服务器有足够的存储空间去安放这个measurement，那么似乎没有办法可以解决这一问题，无论是rebalance还是其他的命令。请问我的这个理解正确吗？
理解正确，influx-proxy做到了分库，但没有做到分表，在我维护的 InfluxDB Cluster 社区交流群 里，有大佬进一步做了分表的工作（有不少额外开发工作量）
如果真的出现了这种情况，出现了一个过于庞大的表，那么是不是就无法处理了呢？不知道您的influx-cluster能否处理这种情况，将measurement自动拆分，我看说明貌似是可以实现的。
理论上是这样，目前我们在很多生产环境里经过验证后的最佳实践：1、设定保留策略，例如存两年、一年，避免大表出现影响性能；2、真的有这种大表出现，就拆表，例如从业务侧开始拆。influxdb-cluster是根据influxdb enterprise来开发开源的，和influxdb enterprise特性一样，会拆成各个数据分片shard，存到不同节点上，所以是实现了分库分表。
好像代码中也也没有自动判断服务器剩余空间的逻辑，因此有可能出现有的服务器空间小，先被占满的情况
确实没有，这个可以考虑设计下，欢迎开发👏🏻
非常棒的项目！多谢！ 但是我看代码逻辑好像在一个circle中一个measurement只会存在一个node里面，也就是说如果这个表过于庞大导致没有单独服务器有足够的存储空间去安放这个measurement，那么似乎没有办法可以解决这一问题，无论是rebalance还是其他的命令。请问我的这个理解正确吗？ 如果真的出现了这种情况，出现了一个过于庞大的表，那么是不是就无法处理了呢？不知道您的influx-cluster能否处理这种情况，将measurement自动拆分，我看说明貌似是可以实现的。 另外，好像代码中也也没有自动判断服务器剩余空间的逻辑，因此有可能出现有的服务器空间小，先被占满的情况？如果加入剩余空间的判定，优先储存进空间较大的服务器会不会更好一些呢？不知道是不是我没有看仔细，漏掉了相关的空间储存判定代码呢？