안녕하세요 여러분,
최근 한 고객이 보안 문제로 인해 ODBC 드라이버를 사용하여 OsiSoft PI를 JMP에 연결하는 것을 선호하지 않는다고 말했습니다. 연결할 수있는 다른 옵션은 Web API 및 OLEDB입니다. PI 데이터베이스를 접한 사람이 있는지, 그리고 고객이 연결하는 데 무엇을 사용하는지 궁금합니다. ODBC가 여전히 표준입니까, 아니면 이것에서 다른 경향이 있습니까?
해들리,
Osi PI에 연결하는 방법에는 여러 가지가 있습니다. ODBC가 자주 사용되지만 필자는 경향이 갈 것이라고 믿습니다 (최소한 미래에는 REST 또는 OLE DB로). 일부는 Python을 사용하여 JMP JSL에서 "Run Program"을 통해 사용하기도합니다. 그러나 후자는 더 필요합니다
고려해야 할 몇 가지 다른 사항 (이는 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).
