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
Sent: Sunday, March 31, 2019 11:34 AM
To: dev@iotdb.apache.org
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" :
I, on the other hand, would be very interested in the strong consistency option.
(Very cool discussion!)
From: Julian Feinauer
Sent: Thursday, March 28, 2019 1:10 AM
To: dev@iotdb.apache.org
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" :
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 于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 "徐毅" :
>
>
>
>
> 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
>
>
