Hola:

La migración de datos a menudo suena como una simple “tarea de mover datos de A a B” hasta que te pones a ello. En realidad, es un proceso complejo que combina planificación, validación, pruebas y precisión técnica.

A lo largo de varios proyectos en los que gestioné la migración de datos a un HIS que funciona sobre IRIS (TrakCare), me di cuenta de que el éxito proviene de una mezcla de disciplina y automatización.

Aquí tenéis algunos puntos que quiero destacar.

1. Empezad con un formato de datos definido.

Antes incluso de abrir vuestro primer archivo, aseguraos de que todos, especialmente los proveedores de datos, entienden claramente el formato exacto de datos que esperáis. Definir plantillas desde el principio evita idas y venidas innecesarias y retrabajos más adelante.

Aunque los formatos Excel o CSV son comunes, personalmente considero que usar un archivo de texto delimitado por tabuladores (.txt) para la carga de datos es lo mejor. Es ligero, consistente y evita problemas con comas dentro de los campos de texto.

PatID   DOB Gender  AdmDate
10001   2000-01-02  M   2025-10-01
10002   1998-01-05  F   2025-10-05
10005   1980-08-23  M   2025-10-15

Aseguraos de que los formatos de fecha que aparecen en el archivo son correctos y constantes en todo el documento, porque normalmente todos estos archivos se convierten desde un Excel y un usuario básico de Excel puede cometer errores al daros los formatos de fecha incorrectos. Los formatos de fecha erróneos pueden desesperaros al convertirlos a horolog.

Embeddedpy-bridge: Un kit de herramientas para Embedded Python

Visión general

Embedded Python es un cambio radical para InterSystems IRIS, ya que ofrece acceso al vasto ecosistema de Python directamente dentro de la base de datos. Sin embargo, salvar la brecha entre ObjectScript y Python a veces puede parecer bastante complicado.

Para hacer que esta transición sea fluida, podéis usar embeddedpy-bridge

La versión 2025.3 de la plataforma de datos InterSystems IRIS, InterSystems IRIS for Health y HealthShare Health Connect ya está disponible de forma general. Esta es una versión de entrega continua o CD  (Continuous Delivery).

Aspectos destacados de la versión:

• Secure Wallet: Un nuevo marco cifrado para gestionar datos sensibles, basado en la base de datos IRISSECURITY, que mejora la seguridad del sistema y el control de acceso.

Hola comunidad,

Quería compartir mi experiencia trabajando en proyectos con grandes volúmenes de datos. A lo largo de los años, he tenido la oportunidad de manejar enormes cantidades de datos de pacientes, datos de aseguradoras y registros transaccionales mientras trabajaba en la industria hospitalaria. He tenido la oportunidad de crear informes muy extensos que requerían usar lógicas avanzadas para obtener datos de múltiples tablas, cuyos índices no me ayudaban a escribir un código eficiente.

Esto es lo que he aprendido sobre cómo gestionar grandes volúmenes de datos de manera eficiente.

Elegir el método de acceso a datos adecuado

Como todos sabemos en esta comunidad, IRIS ofrece múltiples formas de acceder a los datos. Elegir el método correcto dependerá de lo que necesitemos.

• Acceso directo a los Globales: el más rápido para operaciones masivas de lectura/escritura. Por ejemplo, si tengo que recorrer índices y obtener datos de pacientes, puedo iterar sobre los globales para procesar millones de registros. Esto ahorra mucho tiempo.

Set ToDate=+H
Set FromDate=+$H-1 For  Set FromDate=$O(^PatientD("Date",FromDate)) Quit:FromDate>ToDate  Do
. Set PatId="" For  Set PatId=$Order(^PatientD("Date",FromDate,PatID)) Quit:PatId=""  Do
. . Write $Get(^PatientD("Date",FromDate,PatID)),!

• Uso de SQL: útil para requisitos de generación de informes o análisis, aunque más lento para conjuntos de datos muy grandes.

Algo que he aprendido a lo largo de los años es que, por muy pulida que esté vuestra lógica de aplicación, el rendimiento de la base de datos acabará haciendo o deshaciendo la experiencia de usuario. Trabajando con InterSystems IRIS, recientemente me topé con esto de primera mano. Un cliente nuestro estaba construyendo un panel de informes que funcionaba a la perfección en las pruebas, pero cuando el conjunto de datos de producción creció hasta millones de registros, los tiempos de respuesta se arrastraban.

A primera vista, parecía un problema de hardware.

InterSystems ha estado a la vanguardia de la tecnología de bases de datos desde su creación, siendo pionera en innovaciones que superan constantemente a competidores como Oracle, IBM y Microsoft. Al centrarse en un diseño eficiente del núcleo y adoptar un enfoque sin concesiones en el rendimiento de los datos, InterSystems se ha hecho un hueco en las aplicaciones de misión crítica, garantizando fiabilidad, velocidad y escalabilidad.

Desde la introducción de Embedded Python siempre ha estado la duda sobre su rendimiento respecto a ObjectScript y en más de una ocasión lo he comentado con @Guillaume Rongier , pues bien, aprovechando que estaba haciendo una pequeña aplicación para capturar los datos de los concursos públicos en España y poder realizar búsquedas utilizando las capacidades de VectorSearch he visto la oportunidad de realizar una pequeña prueba.

Motivación

Empecé a programar en 2015, cuando estaba haciendo la carrera de informática. No conocía ObjectScript hasta que empecé en mi nuevo trabajo hace cuatro meses. ObjectScript en realidad no es un lenguaje de programación joven. Comparado con C++, Java y Python, la comunidad no es tan activa, pero queremos hacer que este espacio sea más dinámico, ¿verdad?  

Me he dado cuenta de que a algunos de mis compañeros les cuesta entender las relaciones entre clases en estos proyectos tan enormes. No hay ninguna herramienta moderna y fácil de usar para crear diagramas de clases en ObjectScript.

Si eres administrador de sistemas y/o de base de datos y trabajas con InterSystems IRIS, este curso te puede ayudar a mantener tus instancias bien configuradas y con rendimiento óptimo. 

Con el curso de Fundamentos de Administración aprenderás la información esencial y necesaria para configurar la plataforma de datos de InterSystems, realizar tareas de mantenimiento como copias de seguridad, monitorización, resolución de problemas y control de acceso de usuario.

En nuestro portal de formación puedes consultar todos los cursos oficiales programados. 

El auge de los proyectos de Big Data, las analíticas en tiempo real con herramientas self-service, los servicios de consultas en línea y las redes sociales, entre otros, han habilitado escenarios para consultas masivas y de alto rendimiento. En respuesta a este desafío, se creó la tecnología MPP (procesamiento masivamente paralelo) y rápidamente se consolidó. Entre las opciones de MPP de código abierto, Presto (https://prestodb.io/) es la más conocida. Surgió en Facebook y se utilizó para análisis de datos, pero luego se convirtió en código abierto.

Recientemente hemos puesto a disposición una nueva versión de InterSystems IRIS en el Programa de Acceso Anticipado a Vector Search (o búsqueda vectorial), que utiliza el índice ANN (Aproximate Nearest Network) basado en el algoritmo de indexación Hierarchical Navigable Small World (HNSW). Esta incorporación permite realizar búsquedas aproximadas de vecinos-más-cercanos (nearest-neighbours) de manera mucho más eficiente, sobre grandes conjuntos de datos vectoriales, mejorando drásticamente el rendimiento de las consultas y la escalabilidad.

InterSystems IRIS 2024 ha introducido recientemente los tipos de vectores. Esta adición os permite trabajar con búsquedas por vectores, habilitando búsquedas eficientes de similitud, agrupación y una amplia gama de otras aplicaciones. En este artículo, profundizaremos en las complejidades de los tipos de vectores, exploraremos sus aplicaciones y os proporcionaremos ejemplos prácticos para guiar vuestra implementación.

En su esencia, un tipo de vector es una colección estructurada de valores numéricos dispuestos en un orden predefinido.

Entonces, si estáis siguiendo desde la publicación anterior o si os incorporáis ahora, pasemos al mundo de las aplicaciones eBPF y echemos un vistazo a Parca. Este se basa en nuestra breve investigación sobre cuellos de botella en el rendimiento utilizando eBPF, pero añade una aplicación revolucionaria sobre vuestro clúster para monitorizar todas vuestras cargas de trabajo de IRIS de forma continua, ¡a nivel de todo el clúster!

Perfilado continuo con Parca, cargas de trabajo IRIS en todo el clúster

Asistí a la Cloud Native Security Con en Seattle con la plena intención de aprovechar el día de OTEL, para luego profundizar en el tema de la seguridad aplicada a las cargas de trabajo nativas en la nube en los días siguientes, culminando con el CTF como ejercicio profesional. Esto fue felizmente interrumpido por un nuevo entendimiento de eBPF, lo cual supuso una mejora muy necesaria para mis pantallas, carrera, cargas de trabajo y actitud, gracias a nuevos enfoques para resolver problemas relacionados con las cargas de trabajo.

Así que llegué a la "fiesta" de eBPF y desde entonces he estado asistiendo a clínica tras clínica sobre el tema. Aquí me gustaría "desempaquetar" eBPF como una solución técnica, mapeada directamente a lo que hacemos en la práctica (aunque no siempre coincida del todo), y recorrer eBPF a través de mis experimentos en el soporte de las cargas de trabajo de InterSystems IRIS, particularmente en Kubernetes, pero sin excluir las cargas de trabajo independientes.

Pasos de eBee con eBPF y Cargas de Trabajo de InterSystems IRIS

Hacía mucho tiempo que no escribía un post de actualización en IoP (Interoperabilidad en Python).

¿Qué hay de nuevo desde el lanzamiento de la interfaz de línea de comandos de IoP?

Dos nuevas grandes características se han añadido a IoP:

• Rebranding: el módulo grongier.pex fue renombrado a iop para reflejar el nuevo nombre del proyecto.
• Soporte asíncrono**: IoP ahora soporta funciones asíncronas y corrutinas.

Rebranding

El módulo grongier.pex ha sido renombrado a iop para reflejar el nuevo nombre del proyecto.

El módulo grongier.

Un cliente preguntó recientemente si IRIS soporta OpenTelemetry, dado que estaban buscando medir el tiempo que los servicios SOAP implementados por IRIS tardan en completarse, y  el cliente ya tenía varias otras tecnologías que soportan OpenTelemetry para el seguimiento de procesos.

Si bien, a día de hoy, InterSystems IRIS (IRIS) no soporta de forma nativa OpenTelemetry, es justo decir que la plataforma de datos IRIS tiene varias maneras de capturar, registrar y analizar el rendimiento de una instancia en ejecución.

Parece que fue ayer cuando hicimos un pequeño proyecto en Java para probar el rendimiento de IRIS, PostgreSQL y MySQL (podéis revisar el artículo que escribimos allá por Junio al final de este artículo). Si recordáis IRIS se mostró superior a PostgreSQL y claramente superior a MySQL en las inserciones, no habiendo gran diferencia en las consultas.

Poco después @Dmitry Maslennikov me dijo "¿Por qué no pruebas desde un proyecto en Python?" pues bien, aquí está la versión en Python de las pruebas que realizamos mediante las conexiones JDBC previamente.

Continuando con la serie de análisis de rendimiento, en este artículo voy a mostrar un método para dimensionar los requisitos de memoria compartida para aplicaciones de base de datos que se ejecutan en plataformas de datos de InterSystems, incluyendo los Global y Routine Buffers, gmheap y locksize. También daré algunos consejos de rendimiento que se deberían tener en cuenta al configurar servidores y al virtualizar aplicaciones de Iris. Como siempre, cuando hablo de Iris o Caché , me refiero a toda la plataforma de datos. Este artículo tiene algunos años pero mantiene su esencia, por lo que me referiré a Iris o Caché indistintamente ya que la teoría es exáctamente igual para todos los productos con kernel Caché/Iris. 

YASPE es el sucesor de YAPE (Yet Another pButtons Extractor). YASPE ha sido escrito desde cero con muchos cambios internos para facilitar el mantenimiento y añadir mejoras.

Funcionalidades de YASPE:

• Analizar y representar gráficamente los archivos de InterSystems Caché pButtons e InterSystems IRIS SystemPerformance para un rápido análisis de rendimiento de las métricas de IRIS y del Sistema Operativo.
• Facilitar un análisis profundo, creando gráficos tanto ad-hoc como combinando métricas de IRIS y del Sistema Operativo con la opción "Pretty Performance".
• La opción "System Overview" te ahorra tener que buscar en los archivos SystemPerformance detalles del sistema u opciones de configuración comunes.

YASPE está escrito en Python y está disponible en GitHub como código fuente o para contenedores Docker en:

• https://github.com/murrayo/yaspe

¡Hola desarrolladores! Quería compartir hoy un ejemplo muy interesante por parte de Tani Frankel. Se trata de una aplicación sencilla sobre la utilidad SystemPerfomance.

Repasando nuestra documentación sobre la rutina de monitorización ^SystemPerformance (conocida como ^pButtons en versiones anteriores a IRIS), un cliente me dijo «Entiendo todo esto pero ojalá fuese más simple, más sencillo para definir perfiles y gestionarlos, etc.».

Entonces pensé que sería interesante como ejercicio facilitar una pequeña interfaz para hacer esas tareas más sencillas.

El primer paso era envolver en una API basada en clases la rutina actual de ^SystemPerformance.

Hace varios años, estaba enseñando los conocimientos básicos de nuestro framework %UnitTest durante la clase de Fundamentos de Caché (ahora llamada Developing Using InterSystems Objects and SQL). Un alumno preguntó si era posible recoger estadísticas de rendimiento mientras se ejecutan pruebas unitarias. Unas semanas más tarde, añadí un código adicional a los ejemplos de %UnitTest para responder a esa pregunta. Ahora lo comparto con la Comunidad.

Al igual que los servidores hardware, los servidores virtuales en nubes públicas y privadas pueden generar cuellos de botella en los recursos, según aumentan las cargas de trabajo. Si utilizas y administras instancias de InterSystems IRIS implementadas en nubes públicas o privadas, es posible que te hayas encontrado la situación en la que para solucionar problemas de rendimiento o de otro tipo se requiere aumentar la capacidad del servidor de una instancia (es decir, escalar verticalmente).

Un motivo frecuente es la memoria insuficiente.

Me gustaría compartir algunas funciones de almacenamiento que también existen en Caché y que son prácticamente desconocidas y en su mayoría no se utilizan. Por supuesto, están disponibles en IRIS y son más relevantes con arquitecturas de almacenamiento extensas y distribuidas.

Aunque la integridad de las bases de datos Caché e InterSystems IRIS está completamente protegida de las consecuencias de un fallo de sistema, los dispositivos de almacenamiento físico sí que pueden fallar, corrompiendo los datos que almacenan.

Por esa razón, muchos sitios optan por realizar chequeos o verificaciones periódicas de integridad de bases de datos, sobre todo en coordinación con las copias de seguridad, para validar que se pueda confiar en una determinada copia de seguridad en caso de que ocurra algún desastre.

Siguiendo la serie de artículos de mi compañero Murray vamos a centrarnos en el artículo donde analizamos la CPU.

Un cliente me pidió que le aconsejara sobre el siguiente escenario: sus servidores de producción se están acercando al final de su vida útil y es el momento de actualizar el hardware. También están pensando en consolidar los servidores por medio de la virtualización y quieren ajustar la capacidad, ya sea con servidores de hardware dedicado o virtualizados.

Hoy analizaremos la CPU. En artículos posteriores explicaré el enfoque para dimensionar correctamente otros "grupos alimenticios de hardware": la memoria y las Entradas/Salidas.

La cobertura del código y su optmización del rendimiento ya han surgido muchas veces, así que la mayoría de vosotors seguro que ya conocéis la herramienta SYS.MONLBL.

A menudo, un enfoque visual para revisar el código es mucho más intuitivo que los números puros. Este es principalmente el objetivo de esta serie de artículos. Esta vez vamos a hacer una pequeña excursión lejos de Python y sus herramientas, y vamos a explorar la generación de mapas de calor de los informes ^%SYS.MONLBL.

Al trabajar desde casa durante estos "días de coronavirus", me faltan recursos.

• no tengo ninguna máquina Linux disponible
• espacio en disco limitado

Además, Docker Desktop (en Windows10) bloqueó de alguna manera los scripts de Durable %SYS como se describe aquí.
Investigando el caso, descubrí que se almacenaban muchos más datos de los que realmente necesitaba.
Así que diseñé mi durabilidad personalizada.

En el artículo anterior creamos un gráfico simple con los datos de un solo archivo. Ahora bien, como todos sabemos, a veces tenemos diferentes archivos de datos para analizar y correlacionar. Así que en este artículo vamos a cargar datos adicionales de perfmon y aprenderemos a representarlos en el mismo gráfico.

Como podemos querer utilizar en informes o en una página web nuestros gráficos generados, también revisaremos formas de exportar los gráficos generados.