AWS Blu Age Blusam - AWS Modernización de mainframe

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

AWS Blu Age Blusam

En los sistemas mainframe (denominados «antiguos» en el siguiente tema), los datos empresariales suelen almacenarse mediante VSAM el método de acceso al almacenamiento virtual. Los datos se almacenan en «registros» (matrices de bytes) que pertenecen a un «conjunto de datos».

Hay cuatro organizaciones de conjuntos de datos:

  • KSDS: Conjuntos de datos secuenciados por claves: los registros se indexan mediante una clave principal (no se permiten claves duplicadas) y, opcionalmente, mediante claves «alternativas» adicionales. Todos los valores clave son subconjuntos de la matriz de bytes del registro y cada clave está definida por:

    • un desplazamiento (basado en 0, siendo 0 el inicio del contenido de la matriz de bytes del registro, medido en bytes)

    • una longitud (expresada en bytes)

    • si tolera valores duplicados o no

  • ESDS: Conjuntos de datos secuenciados por entradas: se accede a los registros principalmente de forma secuencial (según su orden de inserción en el conjunto de datos), pero se puede acceder a ellos mediante claves alternativas adicionales;

  • RRDS: Conjuntos de datos de registros relativos: se accede a los registros mediante «saltos», utilizando números de registro relativos; los saltos se pueden realizar hacia adelante o hacia atrás;

  • LDS: Conjuntos de datos lineales: no hay registros allí, simplemente un flujo de bytes, organizados en páginas. Se utiliza principalmente para fines internos en plataformas heredadas.

Al modernizar las aplicaciones heredadas, utilizando el enfoque de refactorización de AWS Blu Age, las aplicaciones modernizadas ya no están diseñadas para acceder a los datos VSAM almacenados, sino que preservan la lógica de acceso a los datos. El componente Blusam es la respuesta: permite importar datos de las exportaciones de conjuntos de VSAM datos antiguos, proporciona una aplicación modernizada API para manipularlos, junto con una aplicación web dedicada a la administración. Consulte AWS Consola de administración Blu Age Blusam.

nota

Blusam solo admite, y. KSDS ESDS RRDS

El Blusam API permite conservar la lógica de acceso a los datos (lecturas secuenciales, aleatorias y relativas; insertar, actualizar y eliminar registros), mientras que la arquitectura de componentes, que se basa en una combinación de estrategias de almacenamiento en caché y almacenamiento RDBMS basado, permite operaciones de E/S de alto rendimiento con recursos limitados.

La infraestructura de Blusam

Blusam se basa en ella RDBMS para el almacenamiento de conjuntos de datos, tanto para los datos de registros sin procesar como para los índices de claves (cuando corresponda). La opción favorita es usar el SQL motor postgre, especialmente Amazon Aurora. Los ejemplos e ilustraciones de este tema se basan en este motor.

Otros RDBMS motores compatibles son:

  • Oracle

  • SQLServidor Microsoft

Nota

  • Para los entornos gestionados de modernización de AWS mainframe, solo el SQL motor Aurora postgre es elegible. Se pueden elegir otros RDBMS motores al utilizar AWS Blu Age Runtime en la EC2 implementación de Amazon.

  • Al iniciar el servidor, el motor de ejecución de Blusam comprueba la presencia de algunas tablas técnicas obligatorias y las crea si no se encuentran. En consecuencia, la función utilizada en la configuración para acceder a la base de datos de Blusam debe tener los derechos para crear, actualizar y eliminar las tablas de la base de datos (tanto las filas como las propias definiciones de las tablas). Para obtener información sobre cómo deshabilitar Blusam, consulte. Configuración de Blusam

Almacenamiento en caché

Además del almacenamiento en sí, Blusam funciona más rápido cuando se combina con una implementación de caché.

Actualmente se admiten dos motores de caché EhCache y Redis, cada uno con su propio caso de uso:

  • EhCache : caché local volátil integrada e independiente

    • NOTapta para la implementación de un entorno gestionado de modernización de AWS mainframe.

    • Suele utilizarse cuando se utiliza un único nodo, como un único servidor Apache Tomcat, para ejecutar las aplicaciones modernizadas. Por ejemplo, el nodo puede estar dedicado a alojar tareas de trabajos por lotes.

    • Volátil: la instancia de EhCache caché es volátil; su contenido se perderá al cerrar el servidor.

    • Embebido: el servidor EhCache y el servidor comparten el mismo espacio de JVM memoria (esto debe tenerse en cuenta a la hora de definir las especificaciones de la máquina de alojamiento).

  • Redis: caché persistente compartida

    • Apto para la implementación de un entorno gestionado de modernización de AWS mainframe.

    • Normalmente se usa en situaciones con varios nodos, en particular cuando varios servidores están detrás de un balanceador de carga. El contenido de la caché se comparte entre todos los nodos.

    • El Redis es persistente y no está vinculado a los ciclos de vida de los nodos. Se ejecuta en su propia máquina o servicio dedicado (por ejemplo, Amazon ElastiCache). La memoria caché es remota para todos los nodos.

Bloqueo

Para gestionar el acceso simultáneo a conjuntos de datos y registros, Blusam utiliza un sistema de bloqueo configurable. El bloqueo se puede aplicar a ambos niveles: conjuntos de datos y registros:

  • Bloquear un conjunto de datos con fines de escritura impedirá que todos los demás clientes realicen operaciones de escritura en él, en cualquier nivel (conjunto de datos o registro).

  • Si se bloquea en el nivel de registro para la escritura, se impedirá que otros clientes realicen operaciones de escritura únicamente en el registro en cuestión.

La configuración del sistema de bloqueo Blusam debe realizarse de acuerdo con la configuración de la memoria caché:

  • Si EhCache se elige como implementación de caché, no se requiere ninguna configuración de bloqueo adicional, ya que se debe usar el sistema de bloqueo en memoria predeterminado.

  • Si se elige Redis como implementación de caché, se requiere una configuración de bloqueo basada en Redis para permitir el acceso simultáneo desde varios nodos. La caché de Redis utilizada para los bloqueos no tiene por qué ser la misma que la que se utiliza para los conjuntos de datos. Para obtener información sobre la configuración de un sistema de bloqueo basado en Redis, consulte. Configuración de Blusam

Aspectos intrínsecos de Blusam y migración de datos desde versiones antiguas

Almacenamiento de conjuntos de datos: registros e índices

Cada conjunto de datos heredado, cuando se importe a Blusam, se almacenará en una tabla dedicada; cada fila de la tabla representa un registro que consta de dos columnas:

  • La columna de ID numérica, de tipo entero grande, es la clave principal de la tabla y se utiliza para almacenar la dirección de bytes relativa (RBA) del registro. RBARepresenta el desplazamiento en bytes desde el inicio del conjunto de datos y comienza en 0.

  • La columna de registro de matriz de bytes, que se utiliza para almacenar el contenido del registro sin procesar.

Consulte, por ejemplo, el contenido de un conjunto de KSDS datos utilizado en la CardDemo aplicación:

SQL query result showing KSDS data set with id and record bytes columns for CardDemo application.
  • Este conjunto de datos en particular tiene registros de longitud fija, cuya longitud es de 300 bytes (por lo tanto, la colección de identificadores es múltiplo de 300).

  • De forma predeterminada, la pgAdmin herramienta utilizada para consultar las SQL bases de datos de Postgre no muestra el contenido de las columnas de la matriz de bytes, sino que imprime una etiqueta [datos binarios].

  • El contenido del registro sin procesar coincide con el conjunto de datos sin procesar exportado desde el sistema anterior, sin ninguna conversión. En concreto, no se realiza ninguna conversión del conjunto de caracteres, lo que implica que las partes alfanuméricas del registro deberán decodificarse mediante aplicaciones modernizadas que utilicen el juego de caracteres heredado, muy probablemente una variante. EBCDIC

En cuanto a los índices de claves y metadatos del conjunto de datos: cada conjunto de datos está asociado a dos filas de la tabla nombrada. metadata Esta es la convención de nomenclatura predeterminada. Para obtener información sobre cómo personalizarlo, consulteConfiguración de Blusam.

Table showing two rows of metadata with names and IDs for AWS M2 CARDDEMO ACCTDATA VSAM KSDS datasets.
  • La primera fila tiene el nombre del conjunto de datos como valor de la columna de nombres. La columna de metadatos es una columna binaria que contiene una serialización binaria de los metadatos generales del conjunto de datos dado. Para obtener más información, consulte Atributos de metadatos generales del conjunto de datos.

  • La segunda fila tiene el nombre del conjunto de datos con el sufijo __internal' como valor de la columna de nombres. El contenido binario de la columna de metadatos depende del «peso» del conjunto de datos.

    • Para conjuntos de datos pequeños y medianos, el contenido es una serialización comprimida de:

      • definición de las claves utilizadas por el conjunto de datos; la definición de clave principal (paraKSDS) y definiciones de clave alternativas, si corresponde (para/) KSDS ESDS

      • los índices clave, si procede (KSDS/ESDScon definiciones de clave alternativas): se utilizan para la navegación indexada de registros; el índice clave asigna un valor clave al RBA de un registro;

      • mapa de longitud de registros: se utiliza para la navegación secuencial o relativa de los registros;

    • En el caso de conjuntos de datos grandes o muy grandes, el contenido es una serialización comprimida de:

      • definición de las claves utilizadas por el conjunto de datos; la definición de clave principal (paraKSDS) y definiciones de claves alternativas, si corresponde (para/) KSDS ESDS

Además, los índices de conjuntos de datos grandes o muy grandes (si corresponde) se almacenan mediante un mecanismo de paginación; las serializaciones binarias de las páginas de índice se almacenan como filas de una tabla dedicada (una tabla por clave de conjunto de datos). Cada página de índices se almacena en una fila con las siguientes columnas:

  • id: identificador técnico de la página de índices (clave numérica principal);

  • firstkey: valor binario del primer valor clave (el más bajo) almacenado en la página de índices;

  • lastkey: valor binario del último valor clave (el más alto) almacenado en la página de índices;

  • metadatos: serialización comprimida binaria de la página de índices (mapeo de los valores clave a los registros). RBAs

Database table showing columns for id, firstkey, lastkey, and metadata with sample rows.

El nombre de la tabla es una concatenación del nombre del conjunto de datos y el nombre interno de la clave, que contiene información sobre la clave, como el desplazamiento de la clave, si la clave acepta duplicados (si se establece en verdadero para permitir los duplicados) y la longitud de la clave. Por ejemplo, considere un conjunto de datos denominado "AWS_ LARGE _KSDS" que tiene las dos claves definidas siguientes:

  • clave principal [desplazamiento: 0, duplicados: falso, longitud: 18]

  • clave alternativa [offset: 3, duplicados: true, longitud: 6]

En este caso, las tablas siguientes almacenan los índices relacionados con las dos claves.

Two tables showing index storage for large_ksds_0f18 and large_ksds_3f6 keys.

Optimización del rendimiento de E/S mediante un mecanismo de escritura trasera

Para optimizar el rendimiento de las operaciones de inserción, actualización y eliminación, el motor Blusam se basa en un mecanismo de escritura trasera configurable. El mecanismo se basa en un conjunto de subprocesos dedicados que se ocupan de las operaciones de persistencia mediante consultas de actualización masiva, a fin de maximizar el rendimiento de E/S en el almacenamiento de Blusam.

El motor Blusam recopila todas las operaciones de actualización realizadas en los registros por las aplicaciones y crea lotes de registros que se envían para su tratamiento en los subprocesos dedicados. Luego, los lotes se conservan en el almacenamiento de Blusam, mediante consultas de actualización masivas, lo que evita el uso de operaciones de persistencia atómica y garantiza el mejor uso posible del ancho de banda de la red.

El mecanismo utiliza un retraso configurable (el valor predeterminado es de un segundo) y un tamaño de lote configurable (el valor predeterminado es de 10000 registros). Las consultas de persistencia de la compilación se ejecutan en cuanto se cumple la primera de las dos condiciones siguientes:

  • El retraso configurado ha transcurrido y el lote no está vacío

  • El número de registros del lote a tratar alcanza el límite configurado

Para obtener información sobre cómo configurar el mecanismo de escritura trasera, consulte. Propiedades opcionales

Escoger el esquema de almacenamiento adecuado

Como se muestra en la sección anterior, la forma en que se almacenan los conjuntos de datos depende de su «peso». Pero, ¿qué se considera pequeño, mediano o grande para un conjunto de datos? ¿Cuándo elegir la estrategia de almacenamiento paginado en lugar de la normal?

La respuesta a esa pregunta depende de lo siguiente.

  • La cantidad de memoria disponible en cada uno de los servidores que alojan las aplicaciones modernizadas que utilizarán esos conjuntos de datos.

  • La cantidad de memoria disponible en la infraestructura de caché (si existe).

Cuando se utiliza un esquema de almacenamiento de índices no paginados, las colecciones completas de índices clave y tamaños de registros se cargarán en la memoria del servidor en el momento de abrir el conjunto de datos, para cada conjunto de datos. Además, si se trata del almacenamiento en caché, es posible que todos los registros del conjunto de datos estén precargados en la memoria caché con el método habitual, lo que podría provocar el agotamiento de los recursos de memoria en la infraestructura de caché.

Según el número de claves definidas, la longitud de los valores clave, el número de registros y el número de conjuntos de datos abiertos al mismo tiempo, se puede evaluar aproximadamente la cantidad de memoria consumida para los casos de uso conocidos.

Para obtener más información, consulte Estimación de la huella de memoria de un conjunto de datos determinado.

Migración a Blusam

Una vez que se ha seleccionado el esquema de almacenamiento adecuado para un conjunto de datos determinado, el almacenamiento de Blusam debe rellenarse mediante la migración de los conjuntos de datos heredados.

Para lograrlo, hay que utilizar exportaciones binarias sin procesar de los conjuntos de datos heredados, sin que se utilice ninguna conversión de conjuntos de caracteres durante el proceso de exportación. Al transferir las exportaciones de conjuntos de datos desde el sistema anterior, asegúrese de no dañar el formato binario. Por ejemplo, aplique el modo binario cuando lo utiliceFTP.

Las exportaciones binarias sin procesar contienen solo los registros. El mecanismo de importación no necesita exportar las claves/índices, ya que el mecanismo de importación vuelve a calcular todas las claves/índices sobre la marcha.

Una vez disponible la exportación binaria de un conjunto de datos, existen varias opciones para migrarlo a Blusam:

En el entorno AWS gestionado de modernización de mainframe:

o

o

  • Utilice un script genial para importar conjuntos de datos, utilizando servicios de carga dedicados.

Nota

Por ahora, la importación de objetos grandes KSDS y grandes ESDS en entornos gestionados por la modernización de mainframe solo es posible con scripts groovy.

En AWS Blu Age Runtime en AmazonEC2:

o

  • Utilice un script genial para importar conjuntos de datos, utilizando servicios de carga dedicados.

Importe conjuntos de datos mediante scripts de Groovy

Esta sección le ayudará a escribir scripts geniales para importar conjuntos de datos heredados a Blusam.

Comienza con algunas importaciones obligatorias:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager import com.netfective.bluage.gapwalk.bluesam.metadata.Key; import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry import java.util.ArrayList; //used for alternate keys if any

Después de eso, para cada conjunto de datos que se va a importar, el código se basa en el patrón dado:

  1. crear o borrar un objeto de mapa

  2. rellene el mapa con las propiedades requeridas (esto varía según el tipo de conjunto de datos; consulte más abajo para obtener más información)

  3. recupere el servicio de carga adecuado para usarlo como conjunto de datos en el registro de servicios

  4. ejecuta el servicio usando el mapa como argumento

Hay 5 implementaciones de servicios que se pueden recuperar del registro de servicios mediante los siguientes identificadores:

  • "BluesamKSDSFileLoader": para tamaños pequeños/medianos KSDS

  • "BluesamESDSFileLoader"para tamaño pequeño/mediano ESDS

  • "BluesamRRDSFileLoader": para RRDS

  • "BluesamLargeKSDSFileLoader": para grandes KSDS

  • "BluesamLargeESDSFileLoader": para grandes ESDS

Elegir la versión normal o la versión grande del servicio paraKSDS/ESDSdepende del tamaño de los conjuntos de datos y de la estrategia de almacenamiento que se quiera aplicar. Para obtener información sobre cómo elegir la estrategia de almacenamiento adecuada, consulteEscoger el esquema de almacenamiento adecuado.

Para poder importar correctamente el conjunto de datos a Blusam, se deben proporcionar las propiedades adecuadas al servicio de carga.

Propiedades comunes:

  • Obligatorio (para todo tipo de conjuntos de datos)

    • "bluesamManager": el valor esperado es applicationContext.getBean(BluesamManager.class)

    • "datasetName": nombre del conjunto de datos, en forma de cadena

    • "inFilePath": ruta a la exportación del conjunto de datos heredado, en forma de cadena

    • "recordLength«: la longitud de registro fija o 0 para un conjunto de datos de longitud de registro variable, como un número entero

  • Opcional

    • No se admite para conjuntos de datos de gran tamaño:

      • "isAppend": un indicador booleano que indica que la importación se está realizando en modo de anexión (anexando registros a un conjunto de datos blusam existente).

      • "useCompression": un indicador booleano que indica que la compresión se utilizará para almacenar metadatos.

    • Solo para conjuntos de datos de gran tamaño:

      • "indexingPageSizeInMb": el tamaño en megabytes de cada página de índice, para cada una de las claves del conjunto de datos, expresado como un entero estrictamente positivo

Propiedades que dependen del tipo de conjunto de datos:

  • KSDS/GrandeKSDS:

    • mandatory

      • "primaryKey": la definición de clave principal, mediante una llamada al com.netfective.bluage.gapwalk.bluesam.metadata.Key constructor.

    • opcional:

      • "alternateKeys": una lista (java.util.List) de definiciones clave alternativas, creada mediante llamadas com.netfective.bluage.gapwalk.bluesam.metadata.Key al constructor.

  • ESDS/GrandeESDS:

    • opcional:

      • "alternateKeys": una lista (java.util.List) de definiciones clave alternativas, creada mediante llamadas com.netfective.bluage.gapwalk.bluesam.metadata.Key al constructor.

  • RRDS:

    • ninguno.

Llamadas al constructor clave:

  • new Key(int offset, int length): crea un objeto clave, con los atributos clave determinados (desplazamiento y longitud) y no se permiten duplicados. Esta variante debe usarse para definir una clave principal.

  • new Key(boolean allowDuplicates, int offset, int length): crea un objeto clave, con los atributos clave determinados (desplazamiento y longitud) y los duplicados, lo que permite marcarlo.

Los siguientes ejemplos de Groovy ilustran varios escenarios de carga.

Cargando una tecla grandeKSDS, con dos teclas alternativas:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager import com.netfective.bluage.gapwalk.bluesam.metadata.Key; import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry import java.util.ArrayList; // Loading a large KSDS into Blusam def map = [:] map.put("bluesamManager", applicationContext.getBean(BluesamManager.class)); map.put("datasetName", "largeKsdsSample"); map.put("inFilePath", "/work/samples/largeKsdsSampleExport"); map.put("recordLength", 49); map.put("primaryKey", new Key(0, 18)); ArrayList altKeys = [new Key(true, 10, 8), new Key(false, 0, 9)] map.put("alternateKeys", altKeys); map.put("indexingPageSizeInMb", 25); def service = ServiceRegistry.getService("BluesamLargeKSDSFileLoader"); service.runService(map);

Cargar un registro de longitud variableESDS, sin claves alternativas:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager import com.netfective.bluage.gapwalk.bluesam.metadata.Key; import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry // Loading an ESDS into Blusam def map = [:] map.put("bluesamManager", applicationContext.getBean(BluesamManager.class)); map.put("datasetName", "esdsSample"); map.put("inFilePath", "/work/samples/esdsSampleExport"); map.put("recordLength", 0); def service = ServiceRegistry.getService("BluesamESDSFileLoader"); service.runService(map);

Las exportaciones de conjuntos de datos de longitud de registro variable contendrán la información obligatoria sobre el descriptor de registros Word (RDW) para permitir la división de los registros en el momento de la lectura.

Cargar un registro de longitud fija: RRDS

import com.netfective.bluage.gapwalk.bluesam.BluesamManager import com.netfective.bluage.gapwalk.bluesam.metadata.Key; import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry // Loading a RRDS into Blusam def map = [:] map.put("bluesamManager", applicationContext.getBean(BluesamManager.class)); map.put("datasetName", "rrdsSample"); map.put("inFilePath", "/work/samples/rrdsSampleExport"); map.put("recordLength", 180); def service = ServiceRegistry.getService("BluesamRRDSFileLoader"); service.runService(map);

Además, se puede utilizar una entrada de configuración (que se establecerá en el archivo de configuración application-main.yml) para ajustar el proceso de importación:

  • bluesam.fileLoading.commitInterval: un entero estrictamente positivo, que define el intervalo de confirmación para el mecanismo de importación normal de//. ESDS KSDS RRDS No se aplica a las importaciones de conjuntos de datos de gran tamaño. El valor predeterminado es 100000.

Configuración de Blusam

La configuración de Blusam se realiza en el archivo de configuración application-main.yml (o en el archivo de configuración application-bac.yml para el despliegue independiente de la aplicación de la consola de administración de Blusam -- --). BAC

Blusam debe configurarse en dos aspectos:

  • Configuración del acceso al almacenamiento y a las cachés de Blusam

  • Configuración del motor Blusam

Configuración de acceso al almacenamiento y a las cachés de Blusam

Para obtener información sobre cómo configurar el acceso al almacenamiento y las cachés de Blusam mediante administradores de secretos o fuentes de datos, consulte. Configurar la configuración de AWS Blu Age Runtime

Nota

En cuanto al acceso al almacenamiento de Blusam, las credenciales utilizadas apuntarán a un rol de conexión, con los privilegios correspondientes. Para que el motor Blusam pueda funcionar como se espera, la función de conexión debe tener los siguientes privilegios:

  • conectarse a la base de datos

  • crear/eliminar/alterar/truncar tablas y vistas

  • seleccionar/insertar/eliminar/ actualizar filas en tablas y vistas

  • ejecutar funciones o procedimientos

Configuración del motor Blusam

Desactivar la compatibilidad con Blusam

En primer lugar, mencionemos que es posible deshabilitar por completo el soporte para Blusam, configurando la propiedad en. bluesam.disabled true Al iniciar la aplicación, aparecerá un mensaje informativo en los registros del servidor para recordar que Blusam está deshabilitando:

BLUESAM is disabled. No operations allowed.

En ese caso, no será necesario realizar ninguna configuración adicional sobre Blusam y cualquier intento de utilizar las funciones relacionadas con Blusam (ya sea mediante programación o mediante REST llamadas) provocará una interrupción en la ejecución del código Java, junto con un mensaje explicativo relevante UnsupportedOperationException en el que se indicará que Blusam está deshabilitado.

Propiedades del motor Blusam

Las propiedades de configuración del motor Blusam se reagrupan bajo el prefijo de clave bluesam:

Propiedades obligatorias

  • cache: se valorarán con la implementación de caché elegida. Los valores válidos son:

    • ehcache: Para el uso local de ehcache embebido. Consulte las restricciones de casos de uso relacionadas más arriba.

    • redis: Para el uso de la caché de Redis remota compartida. Esta es la opción preferida para el caso de uso gestionado de la modernización de AWS mainframes.

    • none: Para deshabilitar el almacenamiento en caché

  • persistence: se valorará con el motor de almacenamiento elegido. Los valores válidos son:

    • pgsql(para el SQL motor Postge: versión mínima 10.0; versión recomendada >= 14.0)

    • oracle(para el motor Oracle: versión mínima 19c)

    • mssql(para el motor de SQL servidor: la versión mínima requerida es SQL Server 2019)

  • referencia de la fuente de datos: <persistence engine>.dataSource apuntará a la dataSource definición de la conexión al almacenamiento de Blusam, definida en otra parte del archivo de configuración. Por lo general, se le da un nombre. bluesamDs

Nota

Siempre que se utilice Redis como mecanismo de caché, ya sea para datos o bloqueos (ver más abajo), se debe configurar el acceso a las instancias de Redis. Para obtener más información, consulte Propiedades de caché de Redis disponibles en AWS Blu Age Runtime.

Propiedades opcionales

Bloqueos de Blusam: las propiedades llevan el prefijo locks

  • cache: el único valor utilizable es redis para especificar que se utilizará el mecanismo de bloqueo basado en Redis (que también se utilizará cuando la caché de almacenamiento de Blusam también esté basada en Redis). Si falta la propiedad o no está establecida en ellaredis, se utilizará en su lugar el mecanismo de bloqueo en memoria predeterminado.

  • lockTimeOut: un valor entero largo positivo, que indica el tiempo de espera expresado en milisegundos antes de que un intento de bloquear un elemento ya bloqueado se marque como fallido. El valor predeterminado es. 500

  • locksDeadTime: un valor entero largo positivo, que representa el tiempo máximo, expresado en milisegundos, que una aplicación puede mantener un bloqueo. Los bloqueos se marcan automáticamente como vencidos y se liberan una vez transcurrido ese tiempo. El valor predeterminado es; 1000

  • locksCheck: una cadena, utilizada para definir la estrategia de control de bloqueos utilizada por el administrador de cerraduras blusam actual, sobre la eliminación de cerraduras caducadas. Debe seleccionarse entre los siguientes valores:

    • off: no se realiza ninguna comprobación. Se desaconseja, ya que podrían producirse bloqueos.

    • reboot: las comprobaciones se realizan en el momento del reinicio o del inicio de la aplicación. Todos los bloqueos caducados se liberan en ese momento. Esta es la opción predeterminada.

    • timeout: las comprobaciones se realizan al reiniciar o iniciar la aplicación, o cuando se agota el tiempo de espera durante un intento de bloquear un conjunto de datos. Los bloqueos caducados se liberan inmediatamente.

Mecanismo de escritura oculta: las propiedades llevan el prefijo de la clave: write-behind

  • enabled: true (valor predeterminado y recomendado) ofalse, para activar o desactivar el mecanismo de escritura oculta. La desactivación del mecanismo afectará en gran medida al rendimiento de la escritura, por lo que no se recomienda.

  • maxDelay: una duración máxima para que se activen los subprocesos. El valor predeterminado es "1s" (un segundo). Mantener el valor predeterminado suele ser una buena idea, a menos que condiciones específicas exijan ajustar este valor. En cualquier caso, el valor debe mantenerse bajo (menos de 3 segundos). El formato de la cadena de retardo <time unit> es: <integer value><optional whitespace><time unit> donde debe seleccionarse entre los siguientes valores:

    • "ns": nanosegundos

    • "µs": microsegundos

    • "ms": milisegundos

    • "s": segundos

  • threads: el número de hilos dedicados a la escritura oculta. El valor predeterminado es. 5 Debe ajustar este valor de acuerdo con la potencia de cálculo del host que ejecuta el motor Blusam. No es relevante utilizar un valor mucho más alto, con la esperanza de aumentar el rendimiento, ya que el factor limitante será la RDBMS capacidad de almacenamiento para gestionar numerosas consultas por lotes simultáneas. Los valores recomendados suelen oscilar entre 4 y 8.

  • batchSize: un entero positivo que representa el número máximo de registros de un lote que se enviarán a un subproceso para su tratamiento masivo. Su valor debe estar comprendido entre 1 y 32767. El valor predeterminado es. 10000 Usarlo 1 como valor va en contra del propósito del mecanismo, que consiste en evitar el uso de consultas de actualización atómica; el valor mínimo adecuado a utilizar es aproximadamente. 1000

EhCache Ajuste de precisión integrado: las propiedades llevan el prefijo de la clave: ehcache

  • resource-pool:

    • size: tamaño de memoria asignado a la caché integrada, expresado en forma de cadena. El valor predeterminado es "1024MB" (1 gigabyte). Debe ajustarse en función de la memoria disponible de la máquina que aloja el motor Blusam y del tamaño de los conjuntos de datos que utiliza la aplicación. El formato de la cadena de tamaño es: <integer value><optional whitespace><memory unit> donde <memory-unit> debe seleccionarse entre los siguientes valores:

      • B: bytes

      • KB: kilobytes

      • MB: megabytes

      • GB: gigabytes

      • TB: terabytes

    • heap: true ofalse, para indicar si la memoria caché consumirá memoria de JVM pila o no. El valor predeterminado es true (la opción más rápida para el rendimiento de la caché, pero el almacenamiento en caché consume memoria de la memoria JVM en pilaRAM). Si se establece esta propiedad en, false se cambiará a la memoria Off-Heap, que será más lenta debido a los intercambios necesarios con la pila. JVM

Ejemplo de fragmento de configuración:

dataSource: bluesamDs: driver-class-name: org.postgresql.Driver ... ... bluesam: locks: lockTimeOut: 700 cache: ehcache persistence: pgsql ehcache: resource-pool: size: 8GB write-behind: enabled: true threads: 8 batchsize: 5000 pgsql: dataSource : bluesamDs

Consola de administración de Blusam

La consola de administración de Blusam (BAC) es una aplicación web que se utiliza para administrar el almacenamiento de Blusam. Para obtener información acerca de, consulte. BAC AWS Consola de administración Blu Age Blusam

Apéndice

Atributos de metadatos generales del conjunto de datos

Lista de atributos de serialización de metadatos de conjuntos de datos generales:

  • nombre (del conjunto de datos)

  • tipo (KSDS, Large KSDSESDS, Large ESDS oRRDS)

  • indicador de calentamiento de la memoria caché (indica si el conjunto de datos debe cargarse previamente en la memoria caché al iniciar el servidor o no)

  • indicador de uso de la compresión (si se deben almacenar los registros en formato comprimido o sin procesar)

  • fecha de creación

  • fecha de última modificación

  • indicador de registro de longitud fija (independientemente de que los registros del conjunto de datos tengan todos la misma longitud o no)

  • longitud de registro: solo es significativa para registros de longitud fija

  • tamaño de página (se utiliza para personalizar las consultas sql paginadas que se utilizan para precargar la caché cuando es necesario)

  • tamaño (tamaño del conjunto de datos, longitud acumulada de los registros)

  • último desplazamiento (es decir, RBA del último registro añadido al conjunto de datos)

  • siguiente desplazamiento (siguiente desplazamiento disponible para añadir un nuevo registro al conjunto de datos)

  • si es significativa, definición de las claves utilizadas por el conjunto de datos; cada clave se define por su tipo (principal o parte de la colección de claves alternativas) y tres atributos:

    • desplazamiento: posición en el registro del byte inicial del valor clave;

    • longitud: longitud en bytes del valor clave. Por lo tanto, el valor clave es la matriz de bytes, que es el subconjunto del registro que comienza key offset y termina en la posición; key offset + length - 1

    • indicador de duplicados permitido: si la clave acepta duplicados o no (establézcalo en true para permitir duplicados).

Estimación de la huella de memoria de un conjunto de datos determinado

En el caso de conjuntos de datos pequeños o medianos, los metadatos (tamaños e índices de varias claves) se cargarán completamente en la memoria. La asignación de los recursos adecuados a la máquina que aloja el servidor utilizado para ejecutar las aplicaciones modernizadas requiere determinar el consumo de memoria que provocan los conjuntos de datos de Blusam, en particular en lo que respecta a los metadatos. En esta sección se ofrecen respuestas prácticas a los operadores interesados.

Las fórmulas indicadas solo se aplican a los conjuntos de datos pequeños y medianos de Blusam, y no utilizan la estrategia de almacenamiento «grande».

Metadatos del conjunto de datos de Blusam

En el caso de un conjunto de datos de Blusam, los metadatos se dividen en dos partes:

  • metadatos principales: contienen información global sobre el conjunto de datos. El espacio de memoria que ocupan estos metadatos puede considerarse insignificante en comparación con los metadatos internos.

  • metadatos internos: contienen información sobre el tamaño de los registros y los índices clave; cuando un conjunto de datos no está vacío, esto es lo que consume memoria cuando se carga en el servidor de aplicaciones que aloja las aplicaciones modernizadas. En las siguientes secciones se detalla cómo crece la memoria consumida con el número de registros.

Cálculo de la huella interna de metadatos

Mapa de tamaños de registros

En primer lugar, los metadatos internos almacenan un mapa para almacenar el tamaño de cada registro (como un número entero) dada su RBA dirección relativa en bytes, almacenada como un número largo.

El espacio de memoria de esa estructura de datos es, en bytes: 80 * number of records

Esto se aplica a todos los tipos de conjuntos de datos.

Índices

En cuanto a los índices de la clave principal KSDS o de las claves alternativas de ambos ESDSKSDS, el cálculo del tamaño depende de dos factores:

  • el número de registros del conjunto de datos;

  • el tamaño de la clave, en bytes.

El siguiente gráfico muestra el tamaño del índice de clave por registro (eje y) en función del tamaño de la clave (eje x).

Graph showing step-wise increase in index size per record as key size increases.

La fórmula correspondiente para evaluar la huella de un índice clave determinado de un conjunto de datos es:

index footprint = number of records * ( 83 + 8 (key length / 8))

donde «/» representa la división de enteros.

Ejemplos:

  • conjunto de datos 1:

    • número de registros = 459 996

    • longitud de clave = 15, por lo tanto (longitud de clave/8) = 1

    • huella de índice = 459 996 * (83 + (8*1)) = 41 859 636 bytes (= 39 MB aproximadamente)

  • conjunto de datos 2:

    • número de registros = 13 095 783

    • longitud de clave = 18, por lo tanto (longitud de clave/8) = 2

    • huella de índice = 13 095 783 * (83 + (8*2)) = 1 296 482 517 bytes (= 1,2 GB aproximadamente)

La huella total de un conjunto de datos determinado es la suma de todas las huellas de todos los índices clave y la huella del mapa de tamaños de registros.

Por ejemplo, tomando el ejemplo del conjunto de datos 2, que tiene una sola clave, la huella global es:

  • Mapa de tamaños de registros: 13 095 783 * 80 = 1 047 662 640 bytes

  • Índices clave: 1 296 482 517 bytes (véase más arriba)

  • Tamaño total = 2 344 145 157 bytes (= 2,18 GB aproximadamente)