Ciao a tutti,
Recentemente un cliente ci ha detto che preferirebbe non utilizzare il driver ODBC per connettere OsiSoft PI a JMP a causa di un problema di sicurezza. Altre opzioni per la connessione sono API Web e OLEDB. Mi stavo solo chiedendo se qualcuno si è imbattuto in database PI e cosa usano i loro clienti per connettersi. ODBC è ancora lo standard o c'è una tendenza che si allontana da questo verso qualcos'altro?
Hadley,
ci sono diversi modi per connettersi a Osi PI. ODBC è spesso usato ma credo che la tendenza andrà (almeno in futuro a REST o OLE DB), alcuni lo stanno usando anche tramite "Run Program" da JMP JSL usando ad esempio Python. Ma quest'ultimo ha bisogno di più
Alcune altre cose da considerare (questo proviene da un caso di supporto che abbiamo avuto nel 2018, quindi potrebbero esserci stati aggiornamenti e modifiche da ora sul lato di 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)
Quindi è molto importante come è configurato il database e dove. Si prega di non condividere i numeri effettivi o questo thread (poiché potrebbe non essere più aggiornato), tuttavia si potrebbe voler estrarre alcuni dei risultati per fornire almeno alcuni suggerimenti su "dove guardare" al cliente.
Nota: assicurati di quale pacchetto OSI PI utilizzano, ci sono alcune differenze in ciò che offrono, ad esempio PI OLEDB Enterprise consente l'accesso a elementi / attributi di Asset Framework, frame di eventi Pi e dati delle serie temporali dall'archivio dati PI tramite una connessione OLEDB. Il tipico PI attualmente non (afaik)
