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 <ericpa...@hotmail.com> 于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，“songbing...@iie.ac.cn”<songbing...@iie.ac.cn> 写入: > > 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 > > >
