Bonjour à tous,
Récemment, un client nous a dit qu'il préférerait ne pas utiliser le pilote ODBC pour connecter OsiSoft PI à JMP en raison d'un problème de sécurité.Les autres options de connexion sont l'API Web et OLEDB.Je me demandais simplement si quelqu'un avait rencontré des bases de données PI et ce que leurs clients utilisent pour se connecter.ODBC est-il toujours la norme, ou y a-t-il une tendance à s'éloigner de cela vers autre chose ?
Hadley,
il existe plusieurs façons de se connecter à Osi PI. ODBC est souvent utilisé mais je pense que la tendance ira (au moins à l'avenir vers REST ou OLE DB), certains l'utilisent également via "Run Program" de JMP JSL en utilisant par exemple Python. Mais ce dernier a besoin de plus
Quelques autres choses à considérer (cela provient d'un cas de support que nous avons eu en 2018, il peut donc y avoir eu des mises à jour et des changements depuis maintenant du côté d'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)
Il est donc très important de savoir comment la base de données est configurée et où. Veuillez ne pas partager les chiffres réels ou ce fil de discussion (car il pourrait ne plus être d'actualité), mais vous voudrez peut-être extraire certaines des conclusions pour fournir au moins quelques indices sur "où regarder" au client.
Remarque : assurez-vous du package OSI PI qu'ils utilisent, il y a quelques différences dans ce qu'ils offrent, par exemple PI OLEDB Enterprise permet l'accès aux éléments/attributs Asset Framework, aux cadres d'événements Pi et aux données de séries temporelles de PI Data Archive via une connexion OLEDB. Le PI typique actuellement pas (autant que je sache)
