AW: refactor cluster discussion
Hi all, yes, sorry fort he confusion. The Benchmark was something from the outside and I found its okay to share it here as mayn people from the community can read everything and evaluate if its done “properly” and stuff. Best Julian Von: Willem Jiang Datum: Donnerstag, 25. November 2021 um 01:15 An: dev Betreff: Re: refactor cluster discussion Oh，I think IoTDBers are still following the rule of having a disucssion in English. I just had a quick look at the thread and found out Julian just provides some links of RPC benchmarks which were written in Chinese. Even though there was a discussion meeting in Chinese, XiangDong wrote the minutes in English. https://cwiki.apache.org/confluence/display/IOTDB/%5BChinese%5Diotdb+cluster+discussion+2021.11 Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Nov 25, 2021 at 3:36 AM Giorgio Zoppi wrote: > > Hello IOTDBers, > it's important for us US/EU people to have all in English..it's a > communication/learning thing. > BR, > Giorgio. > > Il giorno mar 23 nov 2021 alle ore 10:54 Xiangdong Huang > ha scritto: > > > Hi, > > > > yes you raise up another existing topic: whether and how to decouple > > and smoothly change to another RPC framework? > > > > Besides, I wonder how do you find these Chinese materials... > > > > Best, > > > > --- > > Xiangdong Huang > > School of Software, Tsinghua University > > > > 黄向东 > > 清华大学 软件学院 > > > > Julian Feinauer 于2021年11月23日周二 下午4:53写道： > > > > > > Hey Xiangdong, > > > > > > that makes totally sense and its good that we „can“ always do CP but > > switch more towards AP if wanted. > > > Regarding RPC I just found this interesting benchmark (you may be better > > able to read everything…): > > > > > > https://github.com/eisig/rpc-benchmark > > > https://www.jianshu.com/p/cdd94d0853c3 > > > > > > Best > > > Julian > > > > > > Von: Xiangdong Huang > > > Datum: Dienstag, 23. November 2021 um 09:46 > > > An: dev > > > Betreff: Re: refactor cluster discussion > > > Hi Julian, > > > > > > Well, in my view, it is AP by default, and can switch to CP (but for > > > some operations, it only supports CP). > > > 1. As we used cache for reducing RPC, it is AP. But if we mandatorily > > > requires check whether the cache is the latest, then it is CP but has > > > a larger latency. > > > 2. For some un-frequent operations (e.g., delete timeseries, delete > > > storage group), we use CP, and requires all nodes to execute the > > > operations successfully. > > > > > > For RPC times, yes the less, the better. If some RPC requests can not > > > be avoid, then the other way is reduce the message size of the request > > > and response. > > > > > > Best, > > > --- > > > Xiangdong Huang > > > School of Software, Tsinghua University > > > > > > 黄向东 > > > 清华大学 软件学院 > > > > > > Julian Feinauer 于2021年11月23日周二 下午4:14写道： > > > > > > > > > > > Hi Community, > > > > > > > > I really like the discussions here and although I do not find enough > > time (and language skills in Chinese) to participate in the meetups I think > > we are on a very good way. > > > > > > > > While reading through the docs provided I just quickly had two > > thoughts that I wanted to share here > > > > > > > > > > > > * Regarding the CAP Theorem, where do we (want to) place > > ourselves? The current cluster module is, from my understanding CP but many > > MPP Databases rather go for AP (I think). I am not sure whats the best > > approach for timeseries and perhaps theres even the chance to switch > > between both modes in certain scenarios (people usually call it something > > like almost certainly consistent or something.. but math is clear, you are > > either CP or AP nothing in between) > > > > * If we do have a lot of communication over sockets we should > > perhaps re-evaluate our RPC mechanism. I know that it’s a razors edge > > between “preliminary optimization” and doing “the right”. But I think it > > would be good to reconsider or check a bit on how much time we loose on RPC > > because that’s a latency we always have to pay and probably multiple times > > during a single call depending on the situation > > > > > > > > If that’s already well discussed and written in the documents than > > please excuse me missing it. > > > > > > > > Best! > > > > Julian > > > > > > > > Von: Xiangdong Huang > > > > Datum: Montag, 22. November 2021 um 03:04 > > > > An: dev > > > > Betreff: refactor cluster discussion > > > > Hi all, > > > > > > > > In the brainstorming last week [1], we tried to introduce a more clear > > > > code decoupling design, which embraced MPP architecture, and shrinked > > > > the raft protocol only into a small scope in the codebase (then it is > > > > easy to replace the implementation of raft, and even replace raft to > > > > other replica mechanism). > > > > > > > > Some detailed discussion is on [2], and welcome to supply the doc. > > > > > > > > [1] > >
AW: refactor cluster discussion
Hey Xiangdong, that makes totally sense and its good that we „can“ always do CP but switch more towards AP if wanted. Regarding RPC I just found this interesting benchmark (you may be better able to read everything…): https://github.com/eisig/rpc-benchmark https://www.jianshu.com/p/cdd94d0853c3 Best Julian Von: Xiangdong Huang Datum: Dienstag, 23. November 2021 um 09:46 An: dev Betreff: Re: refactor cluster discussion Hi Julian, Well, in my view, it is AP by default, and can switch to CP (but for some operations, it only supports CP). 1. As we used cache for reducing RPC, it is AP. But if we mandatorily requires check whether the cache is the latest, then it is CP but has a larger latency. 2. For some un-frequent operations (e.g., delete timeseries, delete storage group), we use CP, and requires all nodes to execute the operations successfully. For RPC times, yes the less, the better. If some RPC requests can not be avoid, then the other way is reduce the message size of the request and response. Best, --- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Julian Feinauer 于2021年11月23日周二 下午4:14写道： > > Hi Community, > > I really like the discussions here and although I do not find enough time > (and language skills in Chinese) to participate in the meetups I think we are > on a very good way. > > While reading through the docs provided I just quickly had two thoughts that > I wanted to share here > > > * Regarding the CAP Theorem, where do we (want to) place ourselves? The > current cluster module is, from my understanding CP but many MPP Databases > rather go for AP (I think). I am not sure whats the best approach for > timeseries and perhaps theres even the chance to switch between both modes in > certain scenarios (people usually call it something like almost certainly > consistent or something.. but math is clear, you are either CP or AP nothing > in between) > * If we do have a lot of communication over sockets we should perhaps > re-evaluate our RPC mechanism. I know that it’s a razors edge between > “preliminary optimization” and doing “the right”. But I think it would be > good to reconsider or check a bit on how much time we loose on RPC because > that’s a latency we always have to pay and probably multiple times during a > single call depending on the situation > > If that’s already well discussed and written in the documents than please > excuse me missing it. > > Best! > Julian > > Von: Xiangdong Huang > Datum: Montag, 22. November 2021 um 03:04 > An: dev > Betreff: refactor cluster discussion > Hi all, > > In the brainstorming last week [1], we tried to introduce a more clear > code decoupling design, which embraced MPP architecture, and shrinked > the raft protocol only into a small scope in the codebase (then it is > easy to replace the implementation of raft, and even replace raft to > other replica mechanism). > > Some detailed discussion is on [2], and welcome to supply the doc. > > [1] > https://cwiki.apache.org/confluence/display/IOTDB/%5BChinese%5Diotdb+cluster+discussion+2021.11 > > [2] > https://cwiki.apache.org/confluence/display/IOTDB/refactor-2021-MPP-decoupling > > Best, > --- > Xiangdong Huang > School of Software, Tsinghua University > > 黄向东 > 清华大学 软件学院
AW: refactor cluster discussion
Hi Community, I really like the discussions here and although I do not find enough time (and language skills in Chinese) to participate in the meetups I think we are on a very good way. While reading through the docs provided I just quickly had two thoughts that I wanted to share here * Regarding the CAP Theorem, where do we (want to) place ourselves? The current cluster module is, from my understanding CP but many MPP Databases rather go for AP (I think). I am not sure whats the best approach for timeseries and perhaps theres even the chance to switch between both modes in certain scenarios (people usually call it something like almost certainly consistent or something.. but math is clear, you are either CP or AP nothing in between) * If we do have a lot of communication over sockets we should perhaps re-evaluate our RPC mechanism. I know that it’s a razors edge between “preliminary optimization” and doing “the right”. But I think it would be good to reconsider or check a bit on how much time we loose on RPC because that’s a latency we always have to pay and probably multiple times during a single call depending on the situation If that’s already well discussed and written in the documents than please excuse me missing it. Best! Julian Von: Xiangdong Huang Datum: Montag, 22. November 2021 um 03:04 An: dev Betreff: refactor cluster discussion Hi all, In the brainstorming last week [1], we tried to introduce a more clear code decoupling design, which embraced MPP architecture, and shrinked the raft protocol only into a small scope in the codebase (then it is easy to replace the implementation of raft, and even replace raft to other replica mechanism). Some detailed discussion is on [2], and welcome to supply the doc. [1] https://cwiki.apache.org/confluence/display/IOTDB/%5BChinese%5Diotdb+cluster+discussion+2021.11 [2] https://cwiki.apache.org/confluence/display/IOTDB/refactor-2021-MPP-decoupling Best, --- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院
