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