¿base de datos en tiempo real?

[Casimiro Noteví]

Empezado por garcesjuan

Una base de datos en tiempo real (BDTR) es aquella que es usada en sistemas en tiempo real, por ejemplo aplicaciones de supervisión de automatas, más conocidos como sistemas SCADA.

Hay diferentes BD en tiempo real, una de las más conocidas es IndustrialSQLServer que es la BD de Wonderware, sistema SCADA de la compañía homonima. Este IndustrialSQLServer no es más que una versión modificada (mejorada) de SQLServer de Microsoft. La mejora consiste en que la BD puede seguir el ritmo del sistema SCADA, por ejemplo grabar miles de registros por segundo.

Un ejemplo sencillo es: normalmente en las aplicaciones SCADA hay modulos que muestran curbas de tendencias (Trends) dichas curbas son muestreos periódicos del valor de una o varias variables (temperaturas, presiones, volumenes, etc...), dichos valores deben ser grabados en la BD, el problema con una BD "normal", es que no es capaz de asegurar la escritura de estos valores, ya que como dije antes pueden ser cientos o miles y con frecuencias de muestreo muy altas (algunos milisegundos).

Generalmente los sistemas SCADA implementan sus propias BDTR, en el caso de Wonderware, éste optó por trabajar de la mano de Microsoft, Otra empresa llamada ArcInformatique produce un sistema SCADA llamado PCVue, dicho sistema usa una BDTR propietaria, es decir que solo ellos conocen su estructura y como trabajar con ella.
Chau.

Y pregunto, por curiosidad, ¿acaso Wonderware (herencia de microsoft) no es propietaria y se conoce su estructura?

[dape]

Muchas gracias por la información Garcesjuan, sólo una cuestión más, digamos que alguién quiere desarrollar un sistema de tiempo real, no sé tal vez un sistema para la ubicación de un avión o cualquier otro móvil (vi algo así en cable alguna vez) ¿el diseño de la basa de datos se hace de la misma manera que para una BD "normal"?

Sobre los links, pues, lo siento Neftalí, la verdad es que no los recuerdo es más no hize bookmark de ninguno.

Saludos y gracias desde Tacna - Perú

David

[jachguate]

Empezado por dape

Muchas gracias por la información Garcesjuan, sólo una cuestión más, digamos que alguién quiere desarrollar un sistema de tiempo real, no sé tal vez un sistema para la ubicación de un avión o cualquier otro móvil (vi algo así en cable alguna vez) ¿el diseño de la basa de datos se hace de la misma manera que para una BD "normal"?

Creo que el asunto va orientado principalmente a poder procesar grandes cantidades de entrada y almacenarlas en la base de datos. Por ejemplo, una pc conectada a una o varias máquinas que están enviando miles de registros por segundo. Oracle, por ejemplo, puede configurarse para que el rendimiento en el procesamiento de las entradas sea máximo, aún a costa de perder información en caso de un fallo de electricidad o hardware, dado que en este tipo de aplicaciones puede resultar mas importante no interrumpir el flujo de la información hacia dentro de la base de datos.

Si la estructura la diseñarás igual o diferente de una base de datos "normal", pues depende principalmente de las características/prestaciones del motor de base de datos que uses, y claro, siempre has de tener en cuenta la alta demanda que tendrá el sistema.

Si se trata mas bien de tener información en tiempo real, sin que la cantidad a procesar sea abrumadora, creo que podes usar un motor cualquiera, con hardware decente, y teniendo un diseño bien logrado para este objetivo.

Por ejemplo, firebird, sobre un buen servidor con seguridad aceptará varios miles de registros por segundo sin dar problemas.

Saludos.

[garcesjuan]

Empezado por dape

Muchas gracias por la información Garcesjuan, sólo una cuestión más, digamos que alguién quiere desarrollar un sistema de tiempo real, no sé tal vez un sistema para la ubicación de un avión o cualquier otro móvil (vi algo así en cable alguna vez) ¿el diseño de la basa de datos se hace de la misma manera que para una BD "normal"?
David

Si, si se utiliza algo como IndustrialSQLServer.

En el caso nuestro que usamos Interbase, tenemos tablas muy sencillas, no hay relaciones muy complicadas, ni triggers de verificación en la escritura, ni procedimientos dentro de la BD.

Un ejemplo de tabla de TREND es este, Solo 4 campos:

LineNumber: integer;
VariableId: integer;
Value: float;
TimeStamp: DateTime;

La tabla VARIABLES:

VariableId: integer;
Name: String[64];
Type: Smalint;

Y solo hay un trigger que inicia la supreción de todos los registros de la variable X en la tabla TREND cuando se borra dicha variable en la tabla VARIABLES.

Chau.

[garcesjuan]

Empezado por Casimiro Notevi

Y pregunto, por curiosidad, ¿acaso Wonderware (herencia de microsoft) no es propietaria y se conoce su estructura?

De pronto no fui muy claro, pero no, a lo que me refiero con BDTR propietaria es que son BD no comerciales, es decir, que no se pueden encontrar como productos separados para la venta, caso que no ocurre con IndustrialSQLServer, se puede comprar una licencia separada de IndustrialSQLServer, claro que los de Wonderware harán todo lo posible por venderte el resto del sistema SCADA.

Chau.

Nota: En mi empresa usamos Interbase y Firebird. Es cierto lo que dice jachguate, si se configuran bien pueden seguir el ritmo del sistem SCADA. Lo malo de Interbase/firebird es el sistema de registros multigeneracionales que hace aumentar el tamaño de las BD de forma bastante importante, esto implica que hay que hacer con cierta frecuencia un backup y un restore de las bases de datos para "limpiarlas".

[Casimiro Noteví]

Empezado por garcesjuan

De pronto no fui muy claro, pero no, a lo que me refiero con BDTR propietaria es que son BD no comerciales, es decir, que no se pueden encontrar como productos separados para la venta, caso que no ocurre con IndustrialSQLServer, se puede comprar una licencia separada de IndustrialSQLServer, claro que los de Wonderware harán todo lo posible por venderte el resto del sistema SCADA.

Chau.

Nota: En mi empresa usamos Interbase y Firebird. Es cierto lo que dice jachguate, si se configuran bien pueden seguir el ritmo del sistem SCADA. Lo malo de Interbase/firebird es el sistema de registros multigeneracionales que hace aumentar el tamaño de las BD de forma bastante importante, esto implica que hay que hacer con cierta frecuencia un backup y un restore de las bases de datos para "limpiarlas".

En nuestros clientes con más movimientos tenemos puesto un script que se ejecuta todas las noches cuando no hay nadie trabajando y hace una copia de seguridad y luego un backup/restore para mantenerlas limpias. Así todas los días trabajan con una base de datos limpita y reluciente

[jachguate]

Empezado por Casimiro Notevi

En nuestros clientes con más movimientos tenemos puesto un script que se ejecuta todas las noches cuando no hay nadie trabajando y hace una copia de seguridad y luego un backup/restore para mantenerlas limpias. Así todas los días trabajan con una base de datos limpita y reluciente

Claro, pero tu aplicación no es 24/7... muchas aplicaciones "en tiempo real" si lo serán...

[Casimiro Noteví]

Empezado por jachguate

Claro, pero tu aplicación no es 24/7... muchas aplicaciones "en tiempo real" si lo serán...

Tienes razón, estos clientes no trabajan por las noches.

En este caso puede que lo único que queda es deshabilitar el sweep automático y ejecutarlo a una hora en la que la base de datos esté más "relajada" de trabajo.