CloudWise-Lukemiao commented on PR #6190: URL: https://github.com/apache/nifi/pull/6190#issuecomment-1181217095
> Thanks for the contribution @CloudWise-Lukemiao! > > The implementation appears to use both the JDBC and Native Java library for interacting with IoTDB. JDBC access is already possible using existing components and leveraging the `DBCPConnnectionPool` or `HikariCPConnectionPool` services. > > The [IoTDB documentation for JDBC](https://iotdb.apache.org/UserGuide/Master/API/Programming-JDBC.html) notes that using JDBC is not recommended for high throughput, so there could be value in new NiFi components that leverage the [Java Native API](https://iotdb.apache.org/UserGuide/Master/API/Programming-Java-Native-API.html). > > With that background, the `PutIoTDB` processor includes a direct dependency on JSON input, which is problematic in terms of flexibility. It would be much better to evaluate an approach that leverages record-oriented processing using NiFi Record Reader services. It may also be useful to create a Controller Service that provides reusable IoTDB Sessions, which could support multiple processors. > > If you are willing to work through more of these details, discussing the options and general design on the associate Jira issue would be a great next step. > Thanks for the contribution @CloudWise-Lukemiao! > > The implementation appears to use both the JDBC and Native Java library for interacting with IoTDB. JDBC access is already possible using existing components and leveraging the `DBCPConnnectionPool` or `HikariCPConnectionPool` services. > > The [IoTDB documentation for JDBC](https://iotdb.apache.org/UserGuide/Master/API/Programming-JDBC.html) notes that using JDBC is not recommended for high throughput, so there could be value in new NiFi components that leverage the [Java Native API](https://iotdb.apache.org/UserGuide/Master/API/Programming-Java-Native-API.html). > > With that background, the `PutIoTDB` processor includes a direct dependency on JSON input, which is problematic in terms of flexibility. It would be much better to evaluate an approach that leverages record-oriented processing using NiFi Record Reader services. It may also be useful to create a Controller Service that provides reusable IoTDB Sessions, which could support multiple processors. > > If you are willing to work through more of these details, discussing the options and general design on the associate Jira issue would be a great next step. Thanks for pointing out the problem. Next, I will change the query interface mode of JDBC to the session mode of iotdb, and I will remove the JDBC insertion mode. I hope to discuss the options and general design on the associate JIRA issue would be a great next step -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
