大家好,
我們最近有一位客戶告訴我們,由於安全問題,他們不願意使用 ODBC 驅動程序將 OsiSoft PI 連接到 JMP。其他連接選項是 Web API 和 OLEDB。我只是想知道是否有人遇到過 PI 數據庫以及他們的客戶使用什麼進行連接。ODBC 是否仍然是標準,或者是否有從這個標準轉向其他標準的趨勢?
哈德利
有幾種方法可以連接到 Osi PI。 ODBC 經常被使用,但我相信這種趨勢會消失(至少在未來會轉向 REST 或 OLE DB),一些人也通過 JMP JSL 的“運行程序”使用它,例如使用 Python。 但後者更需要
其他一些需要考慮的事情(這是我們在 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 Data Archive 訪問資產框架元素/屬性、Pi 事件框架和時間序列數據。 典型的 PI 目前不是 (afaik)