T1.1: Determines Database Storage Strategy

Descripción General

Un namespace en InterSystems IRIS sirve como un espacio de trabajo lógico que referencia múltiples bases de datos para diferentes propósitos. Al diseñar la arquitectura de namespace, los desarrolladores deben determinar qué bases de datos incluir basándose en patrones de acceso a datos, requisitos de seguridad y límites de aplicación.

Componentes de Namespace

• Base de Datos Predeterminada para Globales: Requerida para almacenamiento de datos
• Base de Datos Predeterminada para Rutinas: Opcionalmente separada para almacenamiento de código
• Base de Datos Temporal: Puede referenciar IRISTEMP o una base de datos temporal personalizada

Mejores Prácticas para Separación de Bases de Datos

• Aislamiento de Dominio Funcional: Los datos de aplicación deben residir en bases de datos dedicadas separadas de las bases de datos de código, permitiendo programas de copia de seguridad independientes y políticas de seguridad
• Protección de Bases de Datos del Sistema: IRISSYS e IRISLIB proporcionan funcionalidad básica y no deben almacenar datos de aplicación
• Datos de Referencia Compartidos: Cuando múltiples aplicaciones comparten datos de referencia comunes, almacenarlos en una base de datos compartida y mapear en múltiples namespaces
• Bases de Datos Remotas: Usar Enterprise Cache Protocol (ECP) para arquitecturas distribuidas donde servidores de aplicación acceden a datos en servidores de datos remotos
• Consistencia de Entorno: La función "Copiar desde" durante la creación de namespace permite el despliegue rápido de configuraciones de namespace consistentes entre entornos de desarrollo, pruebas y producción

Descripción General

La arquitectura de base de datos debe anticipar el crecimiento de datos para evitar degradación del rendimiento y caídas del sistema. Al crear bases de datos, los administradores configuran tres parámetros críticos de tamaño.

Parámetros Críticos de Tamaño

• Tamaño Inicial: Típicamente comenzando en 1 MB mínimo
• Incremento de Expansión: Predeterminado 12% del tamaño actual o 10 MB, lo que sea mayor
• Tamaño Máximo: Predeterminado ilimitado a menos que se establezca explícitamente

Para crecimiento predecible, establecer un valor de expansión distinto de cero previene expansiones pequeñas frecuentes que pueden fragmentar la base de datos.

Enfoques de Escalamiento Vertical

• Aumentos de Memoria: Mejora la eficiencia del caché de base de datos
• Subsistemas de Disco Más Rápidos: Mejora el rendimiento de I/O
• Núcleos de CPU Adicionales: Soporta más usuarios concurrentes

Sin embargo, el escalamiento vertical tiene límites prácticos basados en máximos de hardware y restricciones de costo.

Opciones de Escalamiento Horizontal

• Enterprise Cache Protocol (ECP): Separa el procesamiento de aplicación del almacenamiento de datos, permitiendo que múltiples servidores de aplicación accedan a servidores de datos centralizados
• Sharding: Particiona datos entre múltiples nodos de datos, habilitando escalabilidad lineal para conjuntos de datos masivos
• Bases de Datos Multivolumen: Crean automáticamente nuevos archivos de volumen cuando el volumen actual alcanza un tamaño de umbral configurado, permitiendo que las bases de datos abarquen múltiples sistemas de archivos o arreglos de almacenamiento sin interrupción de la aplicación

Consideraciones de Nube y Monitoreo

Para aplicaciones con patrones de crecimiento impredecibles, despliegues en la nube con almacenamiento elástico y recursos de cómputo proporcionan flexibilidad para escalar hacia arriba o hacia abajo basado en la demanda real. Monitorear el espacio libre de base de datos, frecuencia de expansión y tiempos de espera de I/O proporciona advertencia temprana de restricciones de capacidad que requieren cambios arquitectónicos.

Descripción General

Los mapeos de globales proporcionan un mecanismo poderoso para estructurar datos entre múltiples bases de datos mientras se mantiene el acceso transparente de la aplicación. Al diseñar la estructura global para mapeo, los desarrolladores deben organizar datos jerárquicamente con separación lógica en el subíndice de nivel superior, habilitando mapeos eficientes a nivel de subíndice.

Ejemplo: Particionamiento Basado en Instalación

Almacenar datos de pacientes por instalación en ^Patient(facilityID, patientID) permite:

• Mapear ^Patient(1) a través de ^Patient(100) a una base de datos
• Mapear ^Patient(101) a través de ^Patient(200) a otra base de datos
• Particionar efectivamente datos por instalación entre bases de datos

Sintaxis de Mapeo de Subíndice

• Rangos Numéricos: (1):(100) mapea rangos de subíndices numéricos
• Rangos Alfabéticos: ("A"):("M") mapea rangos alfabéticos
• Multi-Nivel Complejo: ("B",23,"m"):("E",5) mapea jerarquías de subíndices multi-nivel complejas
• Tokens Especiales: (BEGIN) y (END) representan los primeros y últimos valores de subíndice posibles en orden de colación
• Mapeos con Comodín: ^ABC* mapea todos los globales que comienzan con ABC a una base de datos especificada

Precedencia de Mapeo

Crítico entender es la precedencia de mapeo: los globales mapeados tienen prioridad sobre los globales locales del mismo nombre, potencialmente ocultando datos locales. Por lo tanto, los mapeos deben ser tan específicos como sea posible para evitar conflictos no deseados.

Patrones Arquitectónicos Habilitados por Mapeos

• Archivo de Datos: Mapear rangos de subíndices históricos a bases de datos de archivo
• Multi-Tenencia: Mapear rangos de subíndices específicos de inquilino a bases de datos aisladas
• Particionamiento de Datos: Distribuir globales grandes entre múltiples bases de datos para paralelismo de I/O
• Arquitecturas Distribuidas: Combinar con acceso remoto a bases de datos ECP para ejecutar lógica de aplicación en servidores de aplicación mientras los datos residen en servidores de datos dedicados

Descripción General

El mirroring de base de datos en InterSystems IRIS proporciona alta disponibilidad a través de failover automático entre instancias primaria y de backup, con miembros async opcionales para recuperación ante desastres. Al diseñar bases de datos para entornos en mirror, se aplican varias restricciones y consideraciones arquitectónicas.

Restricciones Clave

• Configuración Explícita: Las bases de datos deben agregarse explícitamente a la configuración de mirror; simplemente existir en un miembro de mirror no habilita mirroring
• Requisito de Journaling: El journaling es obligatorio para bases de datos en mirror porque la sincronización depende de la transmisión de archivos journal del primario a miembros de backup
• Inmutabilidad del Tamaño de Bloque: El tamaño de bloque no puede cambiarse después de la creación de base de datos, por lo que la selección inicial de tamaño de bloque (predeterminado 8KB) debe considerar requisitos a largo plazo
• Estado de Cifrado: El estado de cifrado de una base de datos en mirror no puede cambiarse después de la creación, requiriendo planificación cuidadosa durante la configuración inicial de base de datos

Sincronización de Propiedades

Las propiedades de base de datos en miembros de backup y async se sincronizan automáticamente desde el primario, incluyendo tamaño actual, configuraciones de expansión y tamaño máximo. Esto significa que los ajustes manuales de tamaño en miembros no primarios pueden ser sobrescritos.

Consideraciones de Failover

• Montar Requerido al Inicio: Debe habilitarse para asegurar que la instancia no se convertirá en primaria a menos que todas las bases de datos requeridas se monten exitosamente y completen la recuperación del journal
• Seguridad Basada en Recursos: Las configuraciones deben ser consistentes entre todos los miembros de mirror para mantener el control de acceso durante el failover
• Datos de Stream: Los file streams no se reflejan automáticamente, requiriendo mecanismos de replicación separados si son críticos
• Soporte Multivolumen: Las bases de datos en mirror soportan configuración multivolumen, pero la expansión de volumen ocurre independientemente en cada miembro de mirror basado en su disponibilidad de disco local

La arquitectura de base de datos debe minimizar dependencias en componentes no reflejados para asegurar disponibilidad completa de aplicación después del failover.

Descripción General

Escalar aplicaciones InterSystems IRIS requiere configuración cuidadosa de múltiples parámetros del sistema que interactúan para determinar el rendimiento general y la capacidad.

Configuración de Caché de Base de Datos

• Propósito: El caché de base de datos (pool de buffer global) debe dimensionarse para contener el conjunto de trabajo de la aplicación en memoria, minimizando lecturas de disco físico
• Impacto Subdimensionado: Causa I/O de disco excesivo y mal rendimiento
• Impacto Sobredimensionado: Desperdicia memoria que podría soportar más procesos de aplicación
• Monitoreo: La eficiencia del caché puede monitorearse a través de ratios de aciertos de caché de base de datos, con objetivos típicamente por encima del 95% para cargas de trabajo OLTP

Configuraciones Clave de Memoria

• Tamaño de Tabla de Locks: Determina cuántos locks concurrentes el sistema puede gestionar; aplicaciones con alta concurrencia de transacciones o locks mantenidos por largo tiempo requieren tablas de locks más grandes
• Pool de Buffer de Rutinas: Almacena código de rutinas y clases compilado en memoria; dimensionamiento adecuado reduce sobrecarga de compilación y tiempo de carga de código
• Generic Memory Heap (gmheap): Proporciona memoria compartida para estructuras del sistema; debe dimensionarse basado en el número de procesos concurrentes y conexiones ECP

Ajuste de Arquitectura Distribuida

Para arquitecturas distribuidas usando ECP, los tamaños de buffer de red y pools de conexión deben ajustarse basados en latencia de red y ancho de banda. Los servidores de aplicación cachean datos de servidores de datos; dimensionar cachés de servidor de aplicación basados en patrones de localidad de referencia mejora el rendimiento.

Decisiones de Cluster Sharded

• Nodos de Datos: Número de nodos de datos para particionamiento
• Nodos de Cómputo: Despliegue para separación de carga de trabajo
• Selección de Clave de Shard: Crítico para distribución de datos
• Estrategias de Rebalanceo: Requeridas a medida que los volúmenes de datos crecen

Compromisos de Configuraciones de Journal

• Journaling Sincrónico: Escrituras inmediatas para máxima protección de datos
• Journaling Asincrónico: Escrituras en buffer para mejor rendimiento
• Los sistemas de producción típicamente requieren journaling para protección de datos, mientras que los entornos de desarrollo pueden deshabilitar journaling para máximo rendimiento

Planificación de Capacidad

Los parámetros de configuración deben establecerse a través de planificación de capacidad basada en características esperadas de carga de trabajo (transacciones por segundo, usuarios concurrentes, volumen de datos) y validarse a través de pruebas de rendimiento bajo condiciones de carga realistas.

Descripción General

Las actualizaciones de InterSystems IRIS preservan la arquitectura y datos de base de datos existentes mientras actualizan software del sistema y bases de datos del sistema.

Qué Se Preserva

Durante una actualización in-place usando la propiedad de línea de comandos REINSTALL=ALL, el instalador preserva:

• El archivo de configuración iris.cpf
• Todas las bases de datos de usuario (sus archivos IRIS.DAT)
• Código de aplicación
• Configuraciones de namespace

Las bases de datos del sistema IRISSYS e IRISLIB se actualizan al formato de la nueva versión, lo cual puede involucrar cambios de estructura interna para soportar nuevas características o rendimiento mejorado.

Consideraciones de Arquitectura de Base de Datos

• Compatibilidad de Tamaño de Bloque: Bases de datos creadas con tamaños de bloque no estándar (mayores de 8KB) deben validarse para soporte continuo en la nueva versión
• Configuraciones de Cifrado: Las claves deben preservarse durante actualizaciones, requiriendo coordinación con sistemas de gestión de claves
• Procedimientos de Bases de Datos en Mirror: Típicamente, el miembro de backup se actualiza primero, se permite que se una al mirror, luego el primario tiene failover y se actualiza (enfoque de actualización rolling minimiza tiempo de inactividad)

Compatibilidad de Aplicación

• Uso de API Deprecado: Revisar aplicaciones para funciones ObjectScript deprecadas o sintaxis SQL que aún pueden funcionar pero podrían impactar rendimiento o compatibilidad futura
• Recompilación de Clases: Las definiciones de clases pueden necesitar recompilación después de la actualización para aprovechar nuevas optimizaciones de almacenamiento o implementaciones de índice
• Colación Personalizada: Globales usando colación personalizada deben validarse para compatibilidad

Pruebas y Validación

• Pruebas Pre-Producción: Las pruebas de impacto de actualización deben realizarse primero en entornos no productivos
• Verificaciones de Validación: Verificar que el rendimiento de acceso a base de datos cumple expectativas, la funcionalidad de aplicación permanece intacta, y los procedimientos de copia de seguridad/restauración funcionan correctamente
• Verificaciones de Integridad: Ejecutar utilidades ^INTEGRIT o DBCHECK post-actualización para verificar consistencia de estructura de base de datos
• Planificación de Rollback: Incluir procedimientos de rollback en caso de que surjan problemas de actualización, requiriendo restauración desde copias de seguridad pre-actualización

Descripción General

La seguridad debe integrarse en la arquitectura de base de datos desde el diseño inicial hasta el despliegue operacional.

Control de Acceso Basado en Recursos

• Recursos de Base de Datos: Cada base de datos está asociada con un recurso (nombrado %DB_nombrebasedatos por defecto) que controla permisos de acceso
• Tipos de Permiso: A usuarios y roles se les otorgan permisos (Read, Write o Use) a recursos de base de datos
• Principio de Mínimo Privilegio: Asignar permisos mínimos necesarios a cada rol, y asignar roles a usuarios basados en sus funciones laborales

Cifrado de Base de Datos

• Propósito: Protege datos en reposo del acceso no autorizado si los medios de almacenamiento físico están comprometidos
• Tiempo de Configuración: El cifrado debe habilitarse durante la creación de base de datos; no puede agregarse o removerse después
• Gestión de Claves: Las claves de cifrado deben estar disponibles durante el montaje de base de datos, requiriendo mecanismos seguros de almacenamiento y distribución de claves
• Requisito de Mirroring: Las bases de datos en mirror requieren configuraciones de cifrado consistentes entre todos los miembros de mirror, con gestión de claves coordinada
• Impacto de Rendimiento: Típicamente menos del 5% para la mayoría de cargas de trabajo debido a aceleración por hardware (instrucciones AES-NI)

Seguridad de Datos de Stream

• Almacenamiento Predeterminado: Los streams se almacenan en subdirectorios bajo el directorio de base de datos
• Ubicaciones Personalizadas: Pueden especificarse ubicaciones de stream personalizadas
• Permisos de Sistema de Archivos: Los directorios de streams deben tener permisos apropiados para prevenir acceso no autorizado
• Datos Sensibles: Para datos altamente sensibles, los streams deben almacenarse en sistemas de archivos cifrados o dentro de la base de datos misma

Auditoría y Consideraciones Especiales

• Base de Datos IRISAUDIT: Debe protegerse de modificación por código de aplicación y usuarios; debe estar en almacenamiento físico separado de bases de datos de aplicación
• Montaje Solo Lectura: Previene todas las modificaciones, útil para bases de datos de referencia, datos archivados o bases de datos de reporting
• Seguridad de Red: Abordar protección a nivel de red para bases de datos remotas accedidas vía ECP, incluyendo cifrado TLS y controles de acceso de red

Descripción General

La funcionalidad de interoperabilidad de InterSystems IRIS (producciones, servicios de negocio, operaciones y procesos) introduce consideraciones significativas de arquitectura de base de datos debido a requisitos de persistencia de mensajes.

Implicaciones de Almacenamiento de Mensajes

• Almacenamiento Persistente: Todos los mensajes que fluyen a través de producciones se almacenan persistentemente en la base de datos ENSLIB (o una base de datos con nombre personalizado), habilitando reenvío de mensajes, replay y auditoría
• Crecimiento de Base de Datos: Producciones de alto rendimiento procesando millones de mensajes diariamente pueden generar gigabytes de crecimiento de base de datos
• Planificación de Capacidad: Requiere planificación de capacidad separada para almacenamiento de mensajes distinta del almacenamiento de datos de aplicación

Análisis de Costo-Beneficio

Costos:

• Sobrecarga de rendimiento de persistencia de mensajes (cada mensaje requiere escrituras de base de datos para encabezados, cuerpos y tablas de búsqueda)

Beneficios:

• Entrega de mensajes garantizada
• Reintento automático en fallo
• Rastros de auditoría de mensajes completos

Gestión de Purga

La gestión de purga de mensajes se convierte en una tarea operacional crítica:

• Los programas de purga deben balancear requisitos de retención para cumplimiento y resolución de problemas contra restricciones de tamaño de base de datos
• Las tareas de purga automatizadas deben ejecutarse regularmente para remover mensajes más allá de períodos de retención
• Considerar archivar mensajes críticos a almacenamiento separado antes de la purga

Mejores Prácticas Arquitectónicas

• Aislamiento de Namespace: Desplegar producciones de interoperabilidad en namespaces dedicados separados de namespaces de aplicación
• Separación de Almacenamiento Físico: Para producciones de alto volumen, colocar base de datos de mensajes y base de datos de aplicación en almacenamiento físico separado para paralelismo de I/O
• Escalamiento ECP: Procesamiento de producción en servidores de aplicación con almacenamiento de mensajes en servidores de datos proporciona escalabilidad horizontal

Consideraciones de Seguridad y Mirroring

• Seguridad de Mensajes: Los datos de mensajes pueden contener información sensible requiriendo cifrado y controles de acceso
• Protección de Configuración: La configuración de producción (reglas de enrutamiento, transformaciones, credenciales) debe protegerse de modificación no autorizada
• Compromisos de Mirroring: Considerar si las bases de datos de mensajes deben estar en mirror (para alta disponibilidad) o excluidas (para rendimiento, aceptando pérdida de mensajes durante failover)

Descripción General

La integración de Business Intelligence en InterSystems IRIS usando IntegratedML, consultas SQL o InterSystems IRIS Business Intelligence introduce compromisos arquitectónicos entre capacidades analíticas y rendimiento operacional. Las consultas BI típicamente involucran escaneos de datos grandes, agregaciones y joins complejos que consumen recursos significativos de CPU e I/O.

Almacenamiento de Cubos OLAP

• Datos Pre-Agregados: Los cubos OLAP almacenan datos pre-agregados en globales específicos de cubos, creando requisitos adicionales de almacenamiento de base de datos
• Impacto de Construcción de Cubos: Las construcciones de cubos consultan datos fuente para calcular agregaciones, creando carga sustancial de I/O y consumo de CPU
• Compromisos de Frecuencia de Construcción:
• Sincronización en tiempo real: Datos actuales pero impacta rendimiento operacional
• Construcciones programadas (nocturnas, por hora): Reducido impacto operacional pero datos obsoletos
• Construcciones incrementales: Actualizar solo datos cambiados, reduciendo tiempo de construcción y consumo de recursos

Patrones Arquitectónicos para Integración BI

• Async Mirror para Reporting: Usar miembros async de mirror de recuperación ante desastres como objetivos de reporting solo lectura; permite consultas BI intensivas sin impactar usuarios de producción (requiere aceptación de latencia de datos)
• Bases de Datos de Reporting Dedicadas: Poblar vía procesos ETL para aislamiento completo de BI de sistemas operacionales

Consideraciones de Diseño de Base de Datos

Compromisos de Desnormalización:

• Esquemas Normalizados: Reducen tamaño de base de datos operacional y mantienen consistencia pero requieren joins complejos para consultas BI
• Tablas de Hechos Desnormalizadas: Optimizan rendimiento de consultas BI al costo de aumento de almacenamiento y complejidad de actualización

Consideraciones Adicionales:

• Almacenamiento Columnar: Puede acelerar consultas analíticas almacenando datos de columnas contiguamente pero requiere sobrecarga de almacenamiento adicional
• Balanceo de Índices: Debe balancear necesidades de consultas operacionales contra patrones de consultas BI, potencialmente requiriendo índices específicos de BI que impactan rendimiento de inserción/actualización operacional

Arquitecturas Sharded

Las arquitecturas sharded complican BI: las consultas analíticas pueden necesitar agregar datos entre todos los nodos de shard, requiriendo nodos de cómputo para coordinar consultas distribuidas. La arquitectura de sharding a nivel de namespace proporciona un punto medio, soportando tanto cargas de trabajo transaccionales como analíticas en los mismos datos sin complejidad de sharding completo.