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 > > 黄向东 > 清华大学 软件学院
