Hallo an alle,
Kürzlich teilte uns ein Kunde mit, dass er aus Sicherheitsgründen lieber nicht den ODBC-Treiber für die Verbindung von OsiSoft PI mit JMP verwenden möchte.Weitere Verbindungsoptionen sind Web API und OLEDB.Ich habe mich nur gefragt, ob jemand auf PI-Datenbanken gestoßen ist und weiß, was ihre Kunden für die Verbindung verwenden.Ist ODBC immer noch der Standard oder gibt es einen Trend weg davon hin zu etwas anderem?
Hadley,
Es gibt mehrere Möglichkeiten, eine Verbindung zu Osi PI herzustellen. ODBC wird häufig verwendet, aber ich glaube, dass die Tendenz (zumindest in der Zukunft) zu REST oder OLE DB gehen wird. Einige verwenden es auch über „Programm ausführen“ von JMP JSL, beispielsweise mit Python. Aber Letzteres braucht mehr
Einige andere Dinge, die Sie berücksichtigen sollten (dies stammt aus einem Support-Fall, den wir im Jahr 2018 hatten, es kann also sein, dass es seither Aktualisierungen und Änderungen auf Seiten von OSI PI gegeben hat:
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)
Daher ist es am wichtigsten, wie und wo die Datenbank eingerichtet wird. Bitte geben Sie die tatsächlichen Zahlen oder diesen Thread nicht weiter (da er möglicherweise nicht mehr aktuell ist). Möglicherweise möchten Sie jedoch einige der Ergebnisse extrahieren, um dem Kunden zumindest einige Hinweise zu geben, „wo er nachschauen sollte“.
Hinweis: Stellen Sie sicher, welches OSI-PI-Paket sie verwenden. Es gibt einige Unterschiede in ihren Angeboten, z. B. ermöglicht PI OLEDB Enterprise den Zugriff auf Asset Framework-Elemente/-Attribute, Pi-Ereignisrahmen und Zeitreihendaten aus dem PI Data Archive über eine OLEDB-Verbindung. Der typische PI derzeit nicht (afaik)
