Tabla en memoria y cada tanto actualizar DB

[jars]

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:

Código Delphi [-]

type
  TPos = packed record
    PosNumber: Word;
    AgentId: string[10];
    AgentName: string[30];
    State: Byte;               
    ChatState: TChatState;
    PosFlags: set of TPosFlag;
    SkillSet: TSkillSet;           
    SkillsDistribution: TSkillsDist;
    CurrentCallSkill: Byte;         
    IMRSessions: string[250];    
    CurrentStateTime: Word;     
    PosIdleTime: Word;             
    PosLockedTime: Word;        
    PosLockedAnswTime: Word; 
    ......
end;

// tamaño total 230.000

procedure TRecord2BlobForm.btnUpdClick(Sender: TObject);
var
  i: Integer;
  s, zip: TMemoryStream;
begin
  Q.SQL.Add('INSERT INTO SESSION_DATA VALUES(:ID, ATA)');
  Q.Prepare;

  Sched.StartTransaction;
  for i := 0 to 999 do
    with Pos[i] do
    begin
      s   := TMemoryStream.Create;
      zip := TMemoryStream.Create;

      try
        s.Write(Pos[i], SizeOf(TPos));
        s.Position := 0;
        ZCompressStream(s, zip, zcMax);
        Q.ParamByName('ID').Value := i;
        Q.ParamByName('DATA').LoadFromStream(zip, ftBlob) ;
        Q.ExecSQL;
      finally
        FreeAndNil(s);
        FreeAndNil(zip);
      end;
      if i mod 50 = 0 then
      begin
        Sched.Commit;
        Sched.StartTransaction;
      end;
    end;
  if Sched.InTransaction then Sched.Commit;
end;

Espero me haberme hecho entender.
Gracias.

[mamcx]

Empezado por jars

Lo que quiero comprimir no es ni zip ni jpg es un registro como este (una parte):

Lo que te dice casimiro es muy cierto. Ahora, el porque no te esta funcionando el uso normal es porque en el esquema relacional basico es facil comparar los valores en cada celda (y es "economico" hacer comparacion entre antes y despues para valores estandar), pero el uso de BLOBs hace que un minimo cambio haga que toda esa fila tenga que actualizarse.

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.

[mamcx]

Empezado por jars

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.

Con esta información entonces es muy claro que hacer: Que es lo que permite en una BD que la información sobreviva a accidentes y que se procese esto de forma correcta? Transacciones? NOPE: Log de transacciones!

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

Código SQL [-]
TimeStamp Action Data
10:51 - UPDATE - AgentName = "A", State = 1, ...
10:52 - UPDATE - AgentName = "B", State = 2, ...

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