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 <giorgio.zo...@gmail.com> 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 <saint...@gmail.com> > 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 <j.feina...@pragmaticminds.de> 于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 <saint...@gmail.com> > > > Datum: Dienstag, 23. November 2021 um 09:46 > > > An: dev <dev@iotdb.apache.org> > > > 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 <j.feina...@pragmaticminds.de> 于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 <saint...@gmail.com> > > > > Datum: Montag, 22. November 2021 um 03:04 > > > > An: dev <dev@iotdb.apache.org> > > > > 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 > > > > > > > > 黄向东 > > > > 清华大学 软件学院 > > > > > -- > Life is a chess game - Anonymous.
