I think using long IDs in the distributed mode itself makes things much complicated in the first place.
Tian Jiang On 11/4/2019 19:16，Xiangdong Huang<[email protected]> wrote： Hi, 3. Do we consider add a long id to each path? (is that helpful?) As far as I know, long id isn't helpful... maybe @Yanzhe An could give us more detailed information. 3. Using string Ids does not induce too much overhead as far as I am concerned, not to mention the cost of maintaining the bidirectional index. And, considering about the cluster mode, we need to use Consistent Hashing to partition data and lookup data, right? If so, will an ID be better than a string? Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Tian Jiang <[email protected]> 于2019年11月4日周一 下午7:00写道： 1. Adding some entities may help us manage the metadata, while I don't think mere renaming really helps much. 2. I don't think PTree helps at all. I would suggest remove useless codes as much as possible, unless real situations where it is needed are found. Even so, a careful redesign is probably necessary and current implementation does not seem to survive. 3. Using string Ids does not induce too much overhead as far as I am concerned, not to mention the cost of maintaining the bidirectional index. On 11/4/2019 18:42，Jialin Qiao<[email protected]> wrote： Hi, 1. How about using sg, device, measurement directly in this module? (Or we can provide interface named like these). About the name of "storage group", maybe SeriesGroup or database is better. 2. How do you think about the legacy attributes in the module called pTree (property tree, which is actually like the tag in InfluxDB), remove it? or introduce reverse index? pTree is a good properties, I suggest to reserve it. However, how to use pTree and mTree simultaneously should be well defined by a PM :-) 3. Do we consider add a long id to each path? (is that helpful?) As far as I know, long id isn't helpful... maybe @Yanzhe An could give us more detailed information. Best, -- Jialin Qiao School of Software, Tsinghua University 乔嘉林 清华大学 软件学院 -----原始邮件----- 发件人: "Xiangdong Huang" <[email protected]> 发送时间: 2019-11-04 15:45:45 (星期一) 收件人: [email protected] 抄送: 主题: Re: Working on refactoring metadata package Hi, Well I planed to do that actually, but I find I can not guarantee my developing time.. So it is good to see that you want to do that. Yes we need to discuss about how to refactor. At least there are something to do: 1. How about using sg, device, measurement directly in this module? (Or we can provide interface named like these). 2. How do you think about the legacy attributes in the module called pTree (property tree, which is actually like the tag in InfluxDB), remove it? or introduce reverse index? 3. Do we consider add a long id to each path? (is that helpful?) Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Tian Jiang <[email protected]> 于2019年11月4日周一 上午11:54写道： Greetings, As you may know, the metadata package is the last package that is not refactored compared with other packages. These codes are old and some are poorly organized and may be inefficient. Nevertheless, new bloods are coming in and such codes are uneasy for them to understand. So I plan to refactor the metadata package in order to remove the unused or inefficient codes. I don't have a hard standard or rule. I will just see what I can do. And I will check out a branch "refactor_metadata" for this. You are welcomed to join this job and discuss in this thread what should be refactored and how. Best, Tian Jiang
