A maioria dos aplicativos transacionais tem um perfil de leitura/escrita (RW) de 70:30. No entanto, alguns casos especiais têm perfis de IO extremamente altos.

Realizei testes de IO de armazenamento na região da AWS ap-southeast-2 (Sydney) para simular os padrões de IO do banco de dados do IRIS e uma taxa de transferência semelhante a de um aplicativo com uma alta taxa de escrita.

para quem deseja conhecer um produto para controle de fontes desenhado para o InterSystems IRIS não pode perder esta apresentação!!!!!!

https://www.meetup.com/boston-intersystems-developers-meetup/events/2914...

Olá, comunidade,

Este é o terceiro artigo da série sobre a inicialização de instâncias da IRIS com Docker. Desta vez, focaremos no Enterprise Cache Protocol (ECP).

De maneira bastante simplificada, o ECP permite configurar algumas instâncias da IRIS como servidores de aplicação e outras como servidores de dados. As informações técnicas detalhadas podem ser encontradas na documentação oficial.

O objetivo deste artigo é descrever o seguinte:

Da última vez, lançamos uma aplicação IRIS no Google Cloud usando seu serviço GKE.

E, embora criar um cluster manualmente (ou por meio do gcloud) seja fácil, a abordagem de Infraestrutura como Código (IaC) moderna recomenda que a descrição do cluster Kubernetes também seja armazenada no repositório como código. Como escrever este código é determinado pela ferramenta que é usada para IaC.

No caso do Google Cloud, existem várias opções, entre elas o Deployment Manager e o Terraform. As opiniões estão divididas quanto o que é melhor: se você quiser saber mais, leia este tópico no Reddit Opiniões sobre Terraform vs. Deployment Manager? e o artigo no Medium Comparando o GCP Deployment Manager e o Terraform.

Introdução

Com a transformação digital no mundo dos negócios, novos recursos ou funcionalidades nos softwares oferecidos por uma empresa, podem significar vantagem competitiva. No entanto, se o time de TI não estiver preparado com a cultura, metodologia, práticas e ferramentas corretas, pode ser muito difícil garantir a entrega dessas novas funcionalidades a tempo hábil.

Como todos nós sabemos, o InterSystems IRIS possui uma ampla gama de ferramentas para melhorar a escalabilidade dos sistemas de aplicação. Em particular, muito foi feito para facilitar o processamento paralelo de dados, incluindo o uso de paralelismo no processamento de consultas SQL e o recurso mais chamativo do IRIS: o sharding. No entanto, muitos desenvolvimentos maduros que começaram no Caché e foram transportados para o IRIS usam ativamente os recursos de multimodelos deste DBMS, que são entendidos como permitindo a coexistência de diferentes modelos de dados dentro de um único banco de dados. Por exemplo, o banco de dados HIS qMS contém modelos de dados semânticos relacionais (registros médicos eletrônicos), relacionais tradicionais (interação com PACS) e hierárquicos (dados de laboratório e integração com outros sistemas). A maioria dos modelos listados é implementada usando a ferramenta qWORD do SP.ARM (um mini-DBMS que é baseado no acesso direto a globais). Portanto, infelizmente, não é possível usar os novos recursos de processamento de consulta paralela para escalonamento, uma vez que essas consultas não usam o acesso IRIS SQL.

Enquanto isso, conforme o tamanho do banco de dados cresce, a maioria dos problemas inerentes a grandes bancos de dados relacionais tornam-se adequados para os não relacionais. Portanto, esse é o principal motivo pelo qual estamos interessados ​​no processamento paralelo de dados como uma das ferramentas que podem ser usadas para escalonamento.

Neste artigo, gostaria de discutir os aspectos do processamento paralelo de dados com os quais tenho lidado ao longo dos anos ao resolver tarefas que raramente são mencionadas em discussões sobre Big Data. Vou me concentrar na transformação tecnológica de bancos de dados, ou melhor, em tecnologias de transformação de bancos de dados.