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.

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.

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.

Una historia de excelencia técnica

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.

Datos para la 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ónpuedes 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. Sin embargo, desde que Teradata se unió a la

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.

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.

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.

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.

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

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.

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).

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.

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.

Cargando datos de Windows Perfmon

Objetivo

Esta herramienta se usa para generar una Entrada/Salida (E/S) de lectura aleatoria desde dentro de la base de datos. La finalidad de esta herramienta es llevar la mayor cantidad de tareas posibles para conseguir las IOPS objetivo y asegurar que se mantienen tiempos de respuesta de disco aceptables. Los resultados recopilados de las pruebas de E/S variarán de configuración a configuración, de acuerdo con el subsistema de E/S. Antes de ejecutar estas pruebas, asegúrate de que el sistema operativo y la monitorización del nivel de almacenamiento estén configurados para capturar métricas de desempeño de E/S para su posterior análisis.

Una cuestión muy común es cuál es la configuración ideal para el servidor web Apache HTTPD cuando se utiliza con HealthShare. El propósito de este artículo es describir la configuración inicial recomendada del servidor web para cualquier producto HealthShare. 

Como punto de partida, se recomienda la versión 2.4.x (64-bit) de Apache HTTPD. Existen versiones anteriores como la 2.2.x, pero no se recomienda esta versión por rendimiento y escalabilidad de HealthShare.

Nota (junio de 2019): han cambiado muchas cosas para obtener los detalles más recientes, haz clic aquíNota (septiembre de 2018): ha habido grandes cambios desde que esta publicación apareció por primera vez; sugiero que utilices la versión del contenedor en Docker dado que el proyecto y la información para que se ejecute como un contenedor sigue publicada en GitHub, en el mismo lugar, para que puedas descargarlo, ejecutarlo y modificarlo, si lo necesitas.

Cuando trabajo con clientes en revisiones de rendimiento, planificaciones de capacidad y resolución de problemas, con frecuencia tengo que descomprimir y revisar las métricas del sistema operativo y de caché desde pButtons. En vez de lidiar con los archivos html para cortar y pegar secciones que serán graficadas en Excel, hace algún tiempo escribí una publicación sobre una herramienta para descomprimir las métricas de pButtons, escrita con el intérprete de unix, perl y los scripts de awk. Si bien este es un valioso ahorro de tiempo, no es la historia completa…

Hay tres aspectos muy importantes en cualquier conversación sobre el rendimiento de SQL: los Índices, el TuneTable, y el Plan de ejecución. En los PDFs adjuntos a este artículo se incluyen presentaciones antiguas sobre estos temas. En los enlaces a nuestra documentación debajo, se ofrece más información sobre estos y otros asuntos relacionados con el rendimiento de SQL. La formación online también refuerza varios de estos temas. Además, hay varios artículos de la Comunidad de Desarrolladores que están relacionados con el rendimiento de SQL y que mostramos a continuación.

En la última publicación programamos recogidas de métricas de rendimiento usando pButtons, a lo largo de 24 horas. En esta publicación, analizaremos algunas de esas métricas clave que se están recogiendo y cómo se relacionan con el hardware del sistema subyacente. También empezaremos a explorar la relación entre las métricas de Caché (o de cualquiera de las plataformas de datos de InterSystems) y las métricas del sistema. Veremos también cómo usar estas métricas para entender el pulso diario de tu sistema y diagnosticar problemas de rendimiento.