I agree that the quality of cluster version of IoTDB is important and should have the high priority, but I think these two things should proceed in parallel. Without a good architecture, there is also no leading competitiveness to meet the challenge of competitor, and it is also impossible to gain good quality based on the inherently inadequate architecture.
Learning from a lot of well-known open source software, they all take into account strategic and operational objectives to keep the competitive power , such as the InfluxDB which have already gone into action, So taking precautions is urgent. I will plan to create a new branch for the next architecture for POC in parallel, welcome to join us to make IoTDB great! 宋秉华 [email protected] From: Eric Pai Date: 2021-11-10 11:14 To: [email protected] Subject: Re: What is the next architecture of IoTDB? Hi, It's nice to plan next generation architecture of IoTDB. However, before we start to design and discuss the refinement and optimization, we should ensure the cluster quality as our expected. In our inner test, by replaying the existed IT cases in a cluster environment, we have found many basic function work abnormally, e.g. ORDER BY DESC query, aggregation query, some filters with wrong serialize/deserialize logic, NPE, and so on. These bugs are easy to reappear but no one has fully tested them, and there's not a framework to ensure that every new feature, or existing feature work well both in cluster and standalone environment. Manual test by contributors is a heavy work with less scenario coverage. Designing new architecture is necessary, but I think the quality assurance may have the high priority than any other things. Good quality assurance make IoTDB to 60/100, and then we can make it to 100/100 by applying any optimizations. 在 2021/11/10 上午10:48，“[email protected]”<[email protected]> 写入: What is the next architecture of IoTDB? As we know，IoTDB cluster version is based on the standalone architecture and almost reused all the basic components of standalone version and just add a multi-raft protocol based on the thrift. With the application spreading, the performance of the cluster version of IoTDB is changllaged for many aspects： the num of nodes in cluster can support, the write and read performance in multi-replicas, the linear ratio of read and write in cluster, the efficiency and smartness of scheduler in cluster based on the dynamic workloads, the joint query between time series data and relational data, the federal cluster query across data centers, AZ and regions and the spatio-temporal data analysis in one DB etc… So, I suggest we should make a blueprint for the next architecture of IoTDB and we can learn the advantage of the InfluxDB. The InfluxDB has designed the next architecture named IOx and use Fusion as the next query engine and adopt parquet as the file format etc. It's time to action, WDYT？ Bruce Song 宋秉华 icloudsong
