Performance metrics will greatly depend on factors such as network latency, web server load, security overhead, etc. I encourage you to check out previous discussions related to the topic here:
- Performance of PI Web Services versus PI to PI Interface in pull configuration
- PITimeSeries Performance Metrics
With that said, I believe your data rate is achievable. However, let me check internally whether we have any performance metrics, and whether alternative architecture will be more appropriate in this case. Please allow me get back to you for more information.
Thanks for letting me get back to you. I have discussed your case with the product manager and some developers internally. Since performance greatly varies based on the above-mentioned factors, we would like to find out more information about your environment and application. If you'd like, we are happy to arrange a phone call with you. Just let me know by commenting on this forum or messaging me directly. Thanks!
Some other ideas to consider:
- PI Web API. The bulk calls in the latest version should allow the required performance. And the REST interface is easy to integrate. I would prefer this over the heavy SOAP of the PI Web Services.
- Long term option: Project CAST is designed to push data from PI to analytics platforms (SAP HANA, Microsoft Machine Learning, etc.). Not sure if this is sufficient for near-realtime though.
- Bad option, although most powerful: create a custom solution using AFSDK.
PI OLEDB Enterprise, while it should be able to reach the throughput, my experience is that it is difficult to keep latency down to make it near-realtime.
Does Teradata only have a SOAP adapter but not a REST one? If not, take a look at PI Web API as Roger has pointed out. Our current development process are focused on PI Web API rather than PI Web Services.
I looked at some performance metrics on PI Web Services, the data rate you specified is definitely achievable across local network. However, your environment involves remote PI Data Archives across WAN, and the performance is a little more difficult to predict. One thing you could do is to put a PI Web Services installation on each site and make SOAP calls from the central office. This would distribute the work among all sites. The alternative is to put the PI Web Services installation in the central location. This would mean PI SDK communication between the central warehouse and the various sites. We tend to be “chatty” over the wire at that level which has been a problem in wide-area deployments before.