![]() |
![]() |
![]() |
![]() |
![]() |
FTP | ![]() |
![]() |
CCD | ![]() |
![]() |
Buscar | ![]() |
![]() |
Trucos | ![]() |
![]() |
Trabajo | ![]() |
![]() |
Foros | ![]() |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
|||
|
|||
Voy a tratar de hacerme entender.
El programa recolecta información desde otro módulo a un ritmo de 2 veces por segundo, procesa esa información, la vuelca en el registro en cuestion y envía ese registro a distintos puestos via tcp. Esto viene funcionando hace años y bien. La cosa es que ahora se necesita cada tanto tiempo (pej. 1 minuto) bajar ese registro a la BBDD para que en caso de corte de luz o cualquier otro problema, no se pierda la información acumulada hasta el momento. Este programa lleva una estadística diaria y no se puede perder es por eso que se necesita resguardarla en BBDD para que a lo sumo se pierda el último minuto y no todo. El registro tiene un tamaño de 230K (si, es grande), logre comprimirlo y lo deja en aproximadamente 10.5 k. Mi última prueba fue de no manejar una tabla en memoria, directamente tomar el registro, comprimirlo y hacer un comando SQL Insert pero me encuentro que al llegar al registro 359 siempre se cuelga con un Acces violation en una direccion 005a2000 no hay nada ahi. Este es el código que estoy probando:
Espero me haberme hecho entender. Gracias. |
#22
|
||||
|
||||
Cita:
Esa es una de las razones por la que almacenar archivos se recomienda hacerlo por fuera de la tabla. El tema de fondo, es que estas empaquetando un "micro base de datos" dentro de una celda de una fila de una tabla. Si lo comprimes? Si claro, queda mas pequeño y eso es buena para transferencias PERO, es el mismo lio: NO IMPORTA si son archivos o campos o texto: Estas metiendo una BD dentro de un campo. Entiende que al final: Los campos son bytes, y sean archivos u otra cosa tienen una estructura. Al usar un blob estas "rompiendo" la estructura "normal" de una tabla y le estas metiendo algo "desconocido" como un valor. De ahi, que la BD no tiene ni idea de que hacer hasta que no desempaquetas y descifras ese valor. Me sigues? Compresion o tipo de datos no es lo fundamental - de hecho, es tangencial-: Es que pasaste de un mundo a otro y ese otro mundo esta rompiendo con las reglas predecibles. ------ Que hacer? Ayuda que nos des mas info. Pero por la pinta de esto, hay 2 caminos basicos: 1- Convierte ese BLOB en tablas, relaciones y ahora si podra operar todo normal. 2- Separar logica y muy seguramente, fisicamente los datos BLOB de los normales, y aplicas logica extra a ese blob para saber si actualizas o no. Osea, tratas como si ese blob fuera un archivo, y asi como un motor SQL no sabe procesar JPGs, asi en este caso. De esa manera, cambios en los datos basicos no interfieren con el blob y viceversa. Y para actualizar el blob de forma eficiente? Aparte de usar tablas relacionales (que parece muy viable) puede hacer un DIFF para chequear cambios y solo extraer lo necesario y ejecutar un PATCH en el servidor junto con un HASH para certificar que la actualizacion fuer correcta y exitosa. O si el cambio en el blob es muy frequente, usar un LOG manual de transacciones donde describes los pasos aplicados en el cliente, y le haces un MERGE en el servidor. Como con archivos.
__________________
El malabarista. |
#23
|
||||
|
||||
Cita:
Te recomiendo que leas este articulo de gente especializada en ese tema: https://martin.kleppmann.com/2015/03...nside-out.html El punto clave aqui es que necesitas generar un LOG, una estructura que solo sigue hacia adelante (que solo hace "append"), que describe precisamente los datos y cambios ejecutados, en orden cronologico y que luego ejecutas en el servidor esos pasos (asi es como hacen las BD relacionales para procesar lo que hacen). Esto es MUY facil de programar. Necesitas hacer algo asi
Un log es correcto si ejecutando de principio a fin obtienes los valores exactos. Veras que es una correspondendia de 1-1 entre lo que recibes de tus sensores y lo que mandas. Si se cae la conexión o pasa algo, aun si el servidor perdio la "pista" de donde estaba operando, simplemente reseteas todo y re-ejecutas tu log. Ves? Un log es un BACKUP!. Para optimizar puedes decir: Ejecuta LOG desde X a Y y solo procesas lo ultimo. Seria ideal si en cada paso tienes un checksum ( Guardas en cada linea de log un checksum entre esa linea y el anterior: Así siempre se puede garantizar que al aplicar la linea todo ok! aun si estas procesando solo una sección) De tanto en tanto, tienes que compactar el log, ponerle por decirlo así "Saldo inicial" y seguir el proceso. Usando esto se pueden procesar GIGABYTES POR SEGUNDO en un PC ordinario. Es MUY eficiente. Incluso, puedes procesar el log fuera de banda, por multiples programas (unos que reportean, otros que calculan, etc), de forma concurrente sin miedo a nada y asi por el estilo. Leete el articulo que es de lo mejor que ha salido de este tema y es muy explicativo. La programación es muy trivial, ademas, una vez que entiendes como hacerlo ![]()
__________________
El malabarista. Última edición por mamcx fecha: 26-02-2016 a las 01:50:05. |
![]() |
|
|
![]() |
||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Mover datos de tabla en memoria a tabla mysql | webmasterplc | SQL | 0 | 07-04-2014 05:12:33 |
Problema con Stored Procedure para actualizar tabla con datos de otra tabla. | Adrian Murua | MySQL | 4 | 04-02-2012 02:54:49 |
Actualizar tabla con datos de otra tabla mediante UPDATE | Rockin | Firebird e Interbase | 18 | 28-11-2007 19:15:42 |
Como actualizar una tabla cada cierto tiempo | leodenis784 | Conexión con bases de datos | 4 | 01-08-2006 13:58:38 |
Una Transacción por cada Tabla???? | AGAG4 | Conexión con bases de datos | 5 | 22-12-2004 03:24:44 |
![]() |
|