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 <[email protected]> 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 <[email protected]> 于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 <[email protected]> > > Datum: Dienstag, 23. November 2021 um 09:46 > > An: dev <[email protected]> > > 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 <[email protected]> 于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 <[email protected]> > > > Datum: Montag, 22. November 2021 um 03:04 > > > An: dev <[email protected]> > > > 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.
