Introdução

Tenho certeza de que a maioria de vocês está familiarizada com a utilidade %SYS.MONLBL, que é crucial ao analisar gargalos de desempenho de código. Ela permite que você selecione várias rotinas que deseja monitorar em tempo de execução e também especifique qual(is) processo(s) você quer observar. MAS, e se você não souber exatamente qual processo executaria seu código? Isso é verdade para muitos aplicativos baseados na web (CSP/REST) hoje. Você quer minimizar a utilização de recursos em seu sistema de produção que precisa de análise.

Olá, desenvolvedores!

Este será um artigo bem curto, pois em abril de 2025, com o Lovable e outras ferramentas Prompt-to-UI, tornou-se possível construir o frontend com prompting. Até mesmo para pessoas como eu, que não estão nem um pouco familiarizadas com as técnicas modernas de UI.

Bem, eu conheço pelo menos as palavras javascript, typescript e ReactJS, então, neste artigo bem curto, construiremos a UI ReactJS para o servidor InterSystems FHIR com Lovable.ai.

Vamos lá!

Ao trabalhar com InterSystems IRIS, desenvolvedores e arquitetos de banco de dados frequentemente enfrentam uma decisão crítica: usar Dynamic SQL ou Embedded SQL para consultar e atualizar dados. Ambos os métodos têm seus pontos fortes e casos de uso únicos, mas entender suas implicações de desempenho é essencial para fazer a escolha certa. O tempo de resposta, uma métrica chave na avaliação do desempenho de aplicações, pode variar significativamente dependendo da abordagem SQL utilizada. Dynamic SQL oferece flexibilidade, pois as consultas podem ser construídas e executadas em tempo de execução, tornando-o ideal para cenários com necessidades de consulta imprevisíveis ou altamente variáveis. Por outro lado, Embedded SQL enfatiza a estabilidade e a eficiência ao integrar código SQL diretamente na lógica da aplicação, oferecendo tempos de resposta otimizados para padrões de consulta predefinidos.

Neste artigo, explorarei os tempos de resposta ao usar esses dois tipos de SQL e como eles dependem de diferentes estruturas de classe e do uso de parâmetros. Para fazer isso, usarei as seguintes classes do diagrama:

Migrar de Oracle, MSSQL ou outros sistemas de banco de dados puramente relacionais para um InterSystems IRIS multimodel é uma decisão estratégica que requer planejamento e execução cuidadosos. Embora essa transição ofereça benefícios significativos, incluindo desempenho aprimorado, escalabilidade e suporte para arquiteturas modernas, ela também apresenta desafios. Neste artigo, destacarei algumas das considerações relacionadas à codificação para garantir uma migração bem-sucedida. Deixarei tudo o que está conectado a uma migração real de estruturas e dados fora do escopo deste artigo.

Primeiramente, ao considerar migrar para um sistema de banco de dados diferente, você precisa entender sua lógica de negócios, seja ela do lado da aplicação (servidor de aplicação) ou do servidor de banco de dados. Basicamente, onde você tem suas instruções SQL que potencialmente precisará reescrever?

Já faz um tempo desde que a nova interface de usuário para Produções e DTL foi publicada como uma prévia e eu gostaria de saber suas opiniões sobre ela.

AVISO: Esta é uma opinião pessoal, totalmente pessoal e não relacionada com a InterSystems Corporation.

Vou começar com a tela de Interoperabilidade:

Tela de Produção:

O estilo é sóbrio e sem adornos, seguindo a linha do design de serviços de nuvem, eu gosto.

Tenho um novo projeto para armazenar informações de respostas REST em um banco de dados IRIS. Precisarei sincronizar informações de pelo menos duas dúzias de endpoints REST separados, o que significa criar quase essa quantidade de classes ObjectScript para armazenar os resultados desses endpoints.

Há treze anos, obtive dois diplomas de graduação em engenharia elétrica e matemática, e logo em seguida comecei a trabalhar em tempo integral na InterSystems, sem usar nenhuma das duas. Uma das minhas experiências acadêmicas mais memoráveis e perturbadoras foi em Estatística II. Em uma prova, eu estava resolvendo um problema de intervalo de confiança moderadamente difícil. O tempo estava acabando, então (sendo um engenheiro) escrevi a integral definida na folha de prova, digitei-a na minha calculadora gráfica, escrevi uma seta com "calculadora" sobre ela e depois escrevi o resultado.

Introdução

O desempenho do banco de dados tornou-se um fator crítico de sucesso em um ambiente de aplicações moderno. Portanto, identificar e otimizar as consultas SQL que consomem mais recursos é essencial para garantir uma experiência de usuário fluida e manter a estabilidade da aplicação.

Este artigo explorará uma abordagem rápida para analisar as estatísticas de execução de consultas SQL em uma instância InterSystems IRIS para identificar áreas de otimização dentro de uma macro-aplicação.

Em vez de focar no monitoramento em tempo real, configuraremos um sistema que coleta e analisa estatísticas pré-calculadas pelo IRIS uma vez por hora. Essa abordagem, embora não permita o monitoramento instantâneo, oferece um excelente compromisso entre a riqueza de dados disponíveis e a simplicidade de implementação.

Usaremos o Grafana para visualização e análise de dados, o InfluxDB para armazenamento de séries temporais e o Telegraf para coleta de métricas. Essas ferramentas, reconhecidas por seu poder e flexibilidade, nos permitirão obter uma visão clara e explorável.

Mais especificamente, detalharemos a configuração do Telegraf para recuperar estatísticas. Também configuraremos a integração com o InfluxDB para armazenamento e análise de dados, e criaremos dashboards personalizados no Grafana. Isso nos ajudará a identificar rapidamente as consultas que exigem atenção especial.

Para facilitar a orquestração e o deploy desses vários componentes, empregaremos o Docker.