Hola a todos,
Recientemente, un cliente nos dijo que preferiría no usar el controlador ODBC para conectar OsiSoft PI a JMP debido a un problema de seguridad. Otras opciones para conectarse son Web API y OLEDB. Me preguntaba si alguien se ha encontrado con bases de datos de PI y qué están usando sus clientes para conectarse. ¿ODBC sigue siendo el estándar o hay una tendencia a alejarse de esto hacia algo más?
Hadley,
Hay varias formas de conectarse a Osi PI. ODBC se usa a menudo, pero creo que la tendencia irá (al menos en el futuro a REST u OLE DB), algunos lo están usando también a través de "Ejecutar programa" desde JMP JSL usando, por ejemplo, Python. Pero este último necesita más
Algunas otras cosas a considerar (esto es de un caso de soporte que tuvimos en 2018, por lo que puede haber actualizaciones y cambios desde ahora en el lado de 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)
Por eso es más importante cómo se configura la base de datos y dónde. No comparta los números reales o este hilo (ya que puede que ya no esté actualizado), sin embargo, es posible que desee extraer algunos de los hallazgos para proporcionar al menos algunos indicios de "dónde buscar" al cliente.
Nota: asegúrese de qué paquete OSI PI utilizan, existen algunas diferencias en lo que ofrecen, por ejemplo, PI OLEDB Enterprise permite el acceso a elementos / atributos de Asset Framework, Pi Event Frames y datos de series temporales desde PI Data Archive a través de una conexión OLEDB. El PI típico actualmente no (afaik)
