I, on the other hand, would be very interested in the strong consistency option.
(Very cool discussion!) ________________________________ From: Julian Feinauer <[email protected]> Sent: Thursday, March 28, 2019 1:10 AM To: [email protected] Subject: Re: IoTDB supports distributed version Hi, this is a very interesting (and important) question. I think we should really consider what we can skip (from an application perspective) and what to keep. Perhaps a Token Ring architecture like Cassandra uses could also be a good fit, if we hash on the device id or something. At least in the situations and use cases I know (strong) consistency is not soo important. From a CAP perspective, for me, Availability is the only undiscussable necessary thing... for the others... we can discuss : ) Julian PS.: Perhaps it would be beneficial to create a design doc in confluence? Am 28.03.19, 08:57 schrieb "Xiangdong Huang" <[email protected]>: yep, I think the cluster is in P2P mode when they startup. Then a leader election algorithm will change the cluster into the M/S mode (RAFT algorithm is qualified). If the master is down, a new master can be elected and lead the cluster. By the way, we need to consider the cost of keeping strong consistency of data. As time series data in IoT scenario is hard to conflict with each other ( I mean, user1 sends data point (t1, v1) that represents device 1 and sensor 1, meanwhile user2 sends a data point (t2, v2) that represents the same device and sensor and t2=t1). So, supporting multiple consistency level is better for keeping high write performance. Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Julian Feinauer <[email protected]> 于2019年3月28日周四 下午3:21写道： > Hi XuYi, > > I like the idea but I'm unsure if I like the master / slave approach. > We often deal with "Shopfloor" Scenarios where the setup for the Database > is basically "MultiMaster", because we need to sync data one the one hand, > but if a system goes down, everything else should keep working. > Would this be possible with your approach? > Something like leader re-election with Zookeper (or better Curator?). > What exactly are the use cases you have in mind? > > Thanks! > Julian > > Am 28.03.19, 05:32 schrieb "徐毅" <[email protected]>: > > > > > Hi, > > > > > IoTDB only supports stand-alone version now. We plan to develop > distributed version in next two months. > > We initially decided to use the master-slave architecture. The master > node is responsible for processing read and write requests, and the slave > node, which is a copy of master node is responsible for processing > read-only requests. > > In terms of implementation, we currently intend to use the raft > protocol to ensure the data consistency of each replica node. > > I have created an issue on jira at [1]. If you have any suggestion, > please comment on jira or reply to this email. > > [1]. https://issues.apache.org/jira/browse/IOTDB-68 > > > > > Thanks > > XuYi > >
