Hi, all This is really a good suggestion. I also think it is necessary to rethink the design of distributed architecture.
The other important thing is if we start from scratch, the project may be relatively large, due to the high voice for the distributed version, and the community has also releases a 0.12 tested distributed version(only suggest tested, not suggest run it in product environment), I think we can first improve the distributed version that can be used in product environment based on the existing version. At the same time, when we are doing integration-test , we should consider the universality of the integration-test design, when we start to develop the next generation distributed architecture, the previously designed integration-test cases can be reused, So what we are doing now is meaningful. Thanks, --------------------------------------- Houliang Qi BONC, Ltd On 11/10/2021 12:35，Junqing Wang<[email protected]> wrote： Agree with Eric Pai. The quality of the cluster version is very important. For now, we should focus more on quality rather than new architecture. Without the quality, the cluster version is hard to use in the production environment. Later I will contribute a PR with an improved IT testing framework that reuses existing IT cases to replay in a cluster environment. And I created a channel #integration-test in slack, everyone is welcome to join the discussion. Eric Pai <[email protected]> 于2021年11月10日周三 上午11:14写道： 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
