Hi Felix, yes, I see, this, indeed would feature the C. As we are usually very "edge" focused we do not care that much about the P as we have no or very few replications, so no big danger of splits. But it is questionable in this situation whether one wants ot use the Server or sticks to the tsfile API directly.
Generally speaking I think the discussion on how to distribute these values. One possibility is (as stated by XuYi) could be to have a master-slave approach, where the master keeps all the data and clients have the replicas. In this scenario, consistency could be modelled fairly easy, with different modes (weak, strong). Another approach could be to distribute all reads / writes according to a "token ring" as Cassandra does it based on a device id or so. I guess it really depends on the use cases where one or the other makes sense, so I like the discussion to get a good overview about the use cases and scenarios to find the best solution. Julian Am 31.03.19, 20:46 schrieb "Felix Cheung" <[email protected]>: The use case I’m thinking about for time series data is a bit sensitive for data loss. Suppose for transaction records. I think I’d generally agree on A in CAP too. But is it going to be eventual consistency? Or it could split brain and lose data? ________________________________ From: Julian Feinauer <[email protected]> Sent: Sunday, March 31, 2019 11:34 AM To: [email protected] Subject: Re: IoTDB supports distributed version Hi Felix, could you elaborate a bit on your use cases? I am a bit unsure about the consistency, so it would be interesting to hear where you see the important points. Thanks! Julian Am 31.03.19, 20:25 schrieb "Felix Cheung" <[email protected]>: 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 > >
