Hi,
If some users break the limitation，the sync module does not check this
scenario and will not guarantee the correctness. In that case, the cost is too
high if we check for that scenario. Under the existing merge policy, after the
merge process the time range order of the device of the tsfils under the
sequence folder is broken, only the time range order of the timeseries is
guaranteed. So when loading a new tsfile, it is hard to determine whether the
time interval of a tsfile overlaps the data interval of an existing file only
through TsFileResource. If there has overlap, we need to compare the time range
of the chunk with that of that file with an overlapping time range of the
device. In this way, the overhead will increase a lot.
So I don't recommend checking the scenario under the existing merge policy,
which will increase a lot of overhead.
Best Regards,
—————————————————
Tianan Li
School of Software, Tsinghua University
李天安
清华大学 软件学院
> 2019年10月23日 下午5:21，Xiangdong Huang <saint...@gmail.com> 写道：
>
> Hi,
>
>> there is no device overlap between the data synchronized by multiple
> senders. Otherwise, the application scenario of the sync module is not
> satisfied.
>
> So my question is, if some user break the limitation, what will happen? Do
> you have some checks for reject the scenario? or do we need to do the
> check?
>
> Best,
> -----------------------------------
> Xiangdong Huang
> School of Software, Tsinghua University
>
> 黄向东
> 清华大学 软件学院
>
>
> 李天安 <lt...@mails.tsinghua.edu.cn> 于2019年10月23日周三 上午4:55写道：
>
>> Hi,
>>
>> With the sync module test completed, this feature will be online
>> soon, so I think it is necessary to describe the scene of using the sync
>> function here.
>>
>> In the case of a factory application, there are usually multiple
>> sub-factories and multiple general(main) factories. Each sub-factory uses
>> an IoTDB instance to collect data, and then synchronize the data to the
>> general factory for backup or analysis. A general factory can receive data
>> from multiple sub-factories and a sub-factory can also synchronize data to
>> multiple general factories. In this scenario, each IoTDB instance manages
>> different devices.
>>
>> In the sync module, each sub-factory is a sender, a general factory
>> is a receiver, and senders periodically synchronizes the data to receivers.
>> In the above application scenario, the data of one device can only be
>> collected by one sender, so there is no device overlap between the data
>> synchronized by multiple senders. Otherwise, the application scenario of
>> the sync module is not satisfied.
>>
>> If you have any idea of the sync application scenario, welcome to
>> discuss it here.
>>
>>
>> Best Regards,
>> —————————————————
>> Tianan Li
>> School of Software, Tsinghua University
>>
>> 李天安
>> 清华大学 软件学院
>>
>>
>
