みなさん、こんにちは、
セキュリティの問題のため、ODSIドライバーを使用してOsiSoft PIをJMPに接続することを望まないというお客様からのご連絡を最近いただきました。 接続する他のオプションは、Web APIとOLEDBです。 誰かがPIデータベースに出くわしたのか、そして顧客が接続に何を使用しているのかと思っていました。 ODBCはまだ標準ですか、またはこれから別の傾向がありますか？
ハドリー、
OsiPIに接続する方法はいくつかあります。 ODBCはよく使用されますが、（少なくとも将来的にはRESTまたはOLE DBに）傾向が見られると思います。一部のユーザーは、Pythonなどを使用してJMPJSLから「プログラムの実行」を介してODBCを使用しています。 しかし、後者はもっと必要です
その他の考慮事項（これは2018年のサポートケースからのものであるため、OSI PI側で現在から更新や変更が行われている可能性があります：
The query in JMP (3rd party) takes more than 10 minutes (for 720000 events) to deliver the data, if I execute the same query in PI SQL Commander it also takes a long time to get the result displayed but not so long as in JMP. If I execute the statement a second time in the Commander it is much more faster than the first call. Why? Caching?
Yes - the ODBC takes longer than OLEDB queries, this is expected.
This is becasue the chain in the architecture and ecery point takes some time: PI ODBC -> SQL DAS -> PI OLEDB -> PI Data Archive
PI SQL Commander can be understood as PI OLEDB Enterprise. While 3rd party SAS JMP as PI ODBC.
Yes caching is also taking place. This is also correct. PI OLEDB or PI ODBC does not have its own cache with query results, but the pi data archive has read cache
2)
The query delivers around 720000 events. What is the normal rate events/sec using PI ODBC?
720 000 events depend on the location of pi data archive. Running the command locally is faster, remotly it takes more time. Also the archived data and the way of stored data in pi data archvie is important (how is the data stored internally within the archives - out-of-order, records, how many archives are covering the period (3 months), etc.)
On of the important remark: the issue is that this kind of queries (IN condition) are executed in a sequential way, in else the interpolation is made for one tag first, subsequently for the second, third and so on..
testing results:
so far.....??? need to quantify (testing)
Are there some possibilities to get some information what the ‘bottleneck’ is or is PI ODBC the wrong tool to get data for so much PI points for this long time range?
bottleneck -> PI DataArchive read cache (disk read performance)
したがって、データベースのセットアップ方法と場所が最も重要です。 実際の数値やこのスレッドを共有しないでください（現在は最新ではない可能性があるため）。ただし、調査結果の一部を抽出して、顧客に「どこを見ればよいか」のヒントを少なくとも提供することをお勧めします。
注：使用するOSI PIパッケージについては、いくつかの違いがあります。たとえば、PI OLEDB Enterpriseでは、OLEDB接続を介してPI DataArchiveからAssetFramework要素/属性、Piイベントフレーム、時系列データにアクセスできます。 典型的なPIは現在（afaik）ではありません
