Desmistificando as Funções: DBRE, DBA e Cientista de Dados

Olá,

À medida que o mundo da tecnologia da informação continua a evoluir, novas funções e especializações surgem para atender às demandas complexas do gerenciamento de dados. Três papéis cruciais que frequentemente geram confusão são os de Database Reliability Engineer (DBRE), Database Administrator (DBA) e Cientista de Dados. Vamos explorar suas diferenças e compreender como esses profissionais contribuem para o ecossistema de dados.

 

 

Database Reliability Engineer (DBRE): A Ponte Entre Desenvolvimento e Operações

O DBRE é um profissional que se concentra na confiabilidade e eficiência dos bancos de dados. Sua função é garantir que os sistemas de gerenciamento de banco de dados (DBMS) estejam sempre disponíveis, resilientes e otimizados. Eles atuam como uma ponte entre desenvolvedores e equipes de operações, garantindo que as aplicações se integrem harmoniosamente aos bancos de dados sejam eles banco de dados relacionais ou NOSQL.

Principais responsabilidades do DBRE:
 

• Garantir Alta Disponibilidade: Os DBREs trabalham para minimizar o tempo de inatividade do sistema, implementando estratégias como replicação de dados e failover automático.

• Desempenho Otimizado: Monitoram o desempenho do banco de dados, identificando gargalos e otimizando consultas para melhorar a eficiência.

• Automação e Escalonamento: Automatizam tarefas repetitivas e garantem que os bancos de dados possam lidar com cargas crescentes de dados sem comprometer a performance.
  

Database Administrator (DBA): Guardião dos Dados e Estruturas do Banco de Dados

Enquanto o DBRE se concentra na confiabilidade, o DBA é o guardião dos dados e da estrutura do banco de dados. Eles desempenham um papel vital na criação, manutenção e otimização de esquemas de banco de dados, garantindo a integridade e segurança dos dados armazenados.

Principais responsabilidades do DBA:

• Design de Banco de Dados: Planejam e implementam a estrutura do banco de dados, considerando requisitos de desempenho, escalabilidade e segurança.
  

• Segurança e Integridade: Implementam políticas de segurança, controle de acesso e garantem a integridade dos dados por meio de backups e recuperação.
  

• Manutenção e Otimização: Realizam tarefas de manutenção, como índices de reorganização e estatísticas de atualização para otimizar o desempenho do banco de dados.
  

Cientista de Dados: Transformando Dados em Insights Estratégicos

Os Cientistas de Dados são responsáveis por extrair insights valiosos a partir de conjuntos de dados. Envolvem-se em análise estatística, machine learning e modelagem preditiva para ajudar as organizações a tomar decisões informadas.

Principais responsabilidades do Cientista de Dados:

• Análise Exploratória de Dados: Exploram grandes conjuntos de dados para identificar padrões, tendências e relações que podem ser usados para tomada de decisões.
  

• Desenvolvimento de Modelos Preditivos: Utilizam algoritmos de machine learning para criar modelos que preveem comportamentos futuros com base em dados históricos.
  

• Comunicação de Resultados: Traduzem resultados complexos em insights compreensíveis, facilitando a tomada de decisões por parte da equipe de gestão. 
  

 

Em resumo, enquanto o DBRE e o DBA garantem a integridade, confiabilidade e eficiência dos bancos de dados, o Cientista de Dados utiliza esses dados para gerar valor estratégico. Juntos, esses profissionais formam uma equipe essencial para o gerenciamento eficaz de dados em um ambiente tecnológico em constante evolução.

Breve Introdução ao Elasticsearch

Olá,

O ElasticSearch é um mecanismo de busca e análise distribuído de código aberto, que permite realizar pesquisas em tempo real em grandes conjuntos de dados. Ele é construído sobre o Apache Lucene e permite que os usuários realizem pesquisas de texto completo, análise de dados e métricas. Ele é construído sobre o Apache Lucene, um mecanismo de pesquisa de código aberto e é projetado para ser altamente escalável e distribuído, permitindo que os usuários executem pesquisas em grandes conjuntos de dados em tempo real.

O ElasticSearch é composto por um cluster de nós, com cada nó armazenando e indexando dados. Ele usa o conceito de shards, que são partições dos dados, que são distribuídas pelos nós no cluster.

Uma shard é basicamente um fragmento de um índice que contém uma parte dos dados indexados e os documentos associados a esses dados. Cada shard é um índice separado, com seu próprio conjunto de documentos e metadados. Os shards são distribuídos entre os nós do cluster, permitindo que a pesquisa seja distribuída e escalável.

Existem dois tipos de shards no Elasticsearch: shards primárias e réplicas de shards. Uma shard primária é a shard que contém a fonte de dados e os documentos associados. Cada documento é armazenado em uma shard primária. As réplicas de shard são cópias de uma shard primária e são usadas para garantir a disponibilidade e a recuperação de desastres. A configuração do número de shards e réplicas em um índice é importante para o desempenho e escalabilidade do cluster. É importante equilibrar o número de shards e réplicas com a capacidade de hardware do cluster. Configurar um número excessivo de shards pode afetar o desempenho do cluster, pois cada shard consome recursos de hardware e pode aumentar o tempo de recuperação de desastres.

Um cluster de Elasticsearch consiste em vários nós que trabalham juntos para armazenar e pesquisar dados. Como exemplo, dois tipos de nós no Elasticsearch são o master node e o data node. De modo bem simples, na imagem abaixo irei chamar os data nodes de Slave Nodes.

O master node é responsável por gerenciar o cluster e coordenar as atividades de todos os outros nós do cluster. Ele é responsável por atribuir shards primárias a nós de dados disponíveis, monitorar a saúde do cluster e gerenciar a configuração do cluster. O master node é crucial para garantir a disponibilidade e a integridade dos dados no cluster.

Os data nodes são os nós que armazenam e manipulam os dados. Eles são responsáveis por indexar, armazenar e recuperar os dados. Eles também gerenciam as réplicas de shards que são distribuídas em todo o cluster. Os data nodes são otimizados para armazenamento e processamento de dados e são responsáveis por executar operações de pesquisa e análise em grande escala.

É importante entender a diferença entre os nós de dados e os nós de master no Elasticsearch. Os nós de dados são responsáveis pelo armazenamento e processamento dos dados, enquanto os nós de master gerenciam o cluster e atribuem as shards primárias a nós de dados disponíveis. A separação dessas funções ajuda a garantir que o cluster possa lidar com grandes volumes de dados e mantém a integridade dos dados.

Em um cluster típico de Elasticsearch, é comum ter vários nós de dados e no mínimo três nós de master. Há casos também em clusters pequenos onde os nós são master e data ao mesmo tempo. Ter vários nós de dados permite que o cluster lide com grandes volumes de dados e forneça alta disponibilidade de dados. Ter três nós de master fornece redundância e ajuda a evitar pontos únicos de falha no gerenciamento do cluster.

Para garantir o bom desempenho e escalabilidade de um cluster Elasticsearch, existem algumas práticas recomendadas que podem ser seguidas:

• Distribua os nós do cluster: É importante ter vários nós distribuídos em diferentes servidores físicos ou virtuais, de preferência em diferentes zonas de disponibilidade, para garantir a alta disponibilidade e resiliência do cluster.
  

• Configure as réplicas adequadamente: Configure as réplicas do cluster para garantir que os dados sejam distribuídos em diferentes nós para garantir a resiliência e a alta disponibilidade do cluster. O número de réplicas deve ser baseado na quantidade de dados, a carga do cluster e o requisito de tempo de recuperação.

• Monitoramento regular: Monitore o cluster regularmente para garantir o bom desempenho, identificar gargalos e otimizar a configuração. Monitoramento regular pode ajudar a identificar problemas antes que eles afetem a disponibilidade do cluster.
  

• Otimização de configuração: Configure o Elasticsearch adequadamente com base na carga de trabalho e nos recursos do hardware disponíveis. É importante otimizar as configurações de JVM, número de shards e réplicas, cache e segmentos para garantir o desempenho ideal do cluster.
  

• Gerenciamento de índices: Divida os dados em índices separados para gerenciamento eficiente e use a rotação de índices para melhorar o desempenho do Elasticsearch. Além disso, elimine índices desnecessários para liberar recursos do cluster.
  

• Backup regular: É importante fazer backup regular dos dados do Elasticsearch para garantir a recuperação de dados em caso de falha do cluster. Faça backup dos dados em locais diferentes para garantir a segurança dos dados. O backup é realizado através de snapshots.
  

• Segurança: Configure a segurança do Elasticsearch para garantir que os dados do cluster estejam seguros e não acessíveis a pessoas não autorizadas.
  

Seguindo essas práticas recomendadas, você pode garantir que seu cluster Elasticsearch tenha desempenho ideal, seja escalável e tenha alta disponibilidade. Além disso, é importante manter-se atualizado sobre as atualizações e recursos do Elasticsearch e implementar essas práticas recomendadas de forma consistente para garantir o sucesso do seu cluster.

MongoDB - Benchmark de Performance (ARM x X86)

Olá,

No artigo de Agosto/2022 eu realizei um benchmark de performance entre as versões do MongoDB. Neste artigo irei realizar uma comparação de performance do MongoDB nas arquiteturas ARM e X86 nas instâncias EC2 da AWS.

Como introdução, vale a pena salientar que a arquitetura de processadores é um assunto importante para entender a diferença entre diferentes tipos de dispositivos, especialmente quando se trata de escolher entre dispositivos móveis, como smartphones e tablets, e computadores desktop ou portáteis. As duas arquiteturas mais comuns são a ARM (Advanced RISC Machines) e a x86, que são usadas em dispositivos diferentes com objetivos diferentes.

A arquitetura ARM é amplamente utilizada em dispositivos móveis, como smartphones e tablets. É uma arquitetura de processadores RISC (Reduced Instruction Set Computing), o que significa que ela usa menos instruções do que outras arquiteturas, como x86. Isso permite que os processadores ARM sejam mais eficientes em termos de consumo de energia e, consequentemente, permitem que os dispositivos móveis tenham uma vida útil de bateria mais longa. Além disso, os processadores ARM são geralmente mais baratos e mais leves do que os processadores x86.

A arquitetura x86, por outro lado, é amplamente utilizada em computadores desktop e portáteis. É uma arquitetura de processadores CISC (Complex Instruction Set Computing), o que significa que ela usa mais instruções do que a arquitetura ARM. Isso significa que os processadores x86 são geralmente mais poderosos do que os processadores ARM, mas também são mais consumidores de energia. Além disso, os processadores x86 geralmente são mais caros e mais pesados do que os processadores ARM.

A performance em servidores de banco de dados é importante para garantir que as aplicações que dependem desses bancos de dados funcionem de maneira eficiente e rápida. Aqui estão alguns exemplos de como a arquitetura de processador pode afetar a performance em servidores de banco de dados:

•  Taxa de transferência de dados: Em servidores de banco de dados, é importante que as informações sejam transferidas rapidamente de um lugar para outro. A arquitetura x86 tem uma largura de banda de dados mais ampla do que a arquitetura ARM, o que significa que os servidores de banco de dados baseados em x86 podem transferir dados mais rapidamente.

•  Processamento de dados: Em servidores de banco de dados, é importante que as informações sejam processadas rapidamente. A arquitetura x86 tem uma capacidade de processamento de dados mais robusta do que a arquitetura ARM, o que significa que os servidores de banco de dados baseados em x86 podem processar dados mais rapidamente.

•  Escalabilidade: Em servidores de banco de dados, é importante que eles possam ser escalados para acompanhar o crescimento do banco de dados. A arquitetura x86 tem uma escalabilidade mais alta do que a arquitetura ARM, o que significa que os servidores de banco de dados baseados em x86 podem ser escalados de maneira mais eficiente para acompanhar o crescimento do banco de dados.

•  Consumo de energia: Em servidores de banco de dados, é importante que eles sejam eficientes em termos de energia. A arquitetura ARM tem um consumo de energia mais baixo do que a arquitetura x86, o que significa que os servidores de banco de dados baseados em ARM são mais eficientes em termos de energia.

Em resumo, a escolha da arquitetura de processador para um servidor de banco de dados dependerá do equilíbrio entre taxa de transferência de dados, processamento de dados, escalabilidade e consumo de energia. Se a prioridade for o processamento de dados rápido, a arquitetura x86 é uma boa escolha. Se a prioridade for a eficiência energética, a arquitetura ARM é uma boa escolha.

A Amazon Web Services (AWS) oferece servidores EC2 com duas arquiteturas diferentes: ARM e x86. Aqui estão alguns exemplos de uso dessas arquiteturas para bancos de dados:

Arquitetura ARM:

A EC2 A1 e M6g oferece processadores ARM-based Graviton2, que são projetados especificamente para a nuvem e têm uma arquitetura de baixo consumo de energia. Isso significa que as instâncias A1 são mais econômicas em termos de custo por hora de operação em comparação com as instâncias x86. Além disso, as instâncias A1 são otimizadas para carregar altas cargas de trabalho de I/O, o que as torna ideais para bancos de dados NoSQL que exigem alta escalabilidade horizontal.

Entretanto, é importante lembrar que a compatibilidade de software é uma questão importante a se considerar ao escolher a arquitetura ARM. Alguns softwares, como os bancos de dados relacionais, podem não ser compatíveis com a arquitetura ARM e, portanto, exigirão ajustes adicionais para funcionar corretamente.

Arquitetura x86:

A EC2 M5, R5 e M6i oferece processadores Intel Xeon Scalable, que são amplamente utilizados em aplicações empresariais e de nuvem. Isso significa que a compatibilidade de software é geralmente mais ampla em comparação com a arquitetura ARM.

Além disso, as instâncias R5 são projetadas para fornecer recursos adicionais, como CPU, memória e armazenamento, para lidar com operações complexas de consulta e processamento de dados. Isso as torna ideais para bancos de dados relacionais que exigem alta performance de processamento. No entanto, é importante lembrar que as instâncias x86 tendem a ser mais caras em termos de custo por hora de operação em comparação com as instâncias ARM. Além disso, as instâncias x86 podem consumir mais energia em comparação com as instâncias ARM, o que pode afetar a eficiência energética da sua solução de banco de dados.

Em resumo, a escolha entre a arquitetura ARM e x86 para seu banco de dados na AWS dependerá de suas necessidades específicas em termos de desempenho, custo e compatibilidade de software.

Segue abaixo o comparativo de performance utilizando o MongoDB nas instâncias M6i.xlarge (X86) e M6g.xlarge (ARM) na qual foram executadas operações no MongoDB durante 4 horas ininterruptas.

 

 

MongoDB - Benchmark de Performance (3.2 a 6.0)

Olá,

O propósito deste artigo é mostrar os resultados de um benchmark (não oficial) realizado por mim comparando a performance de leitura e escrita de versões do MongoDB desde a versão 3.2 até a versão 6.0 que é a última disponível na data deste artigo. Foram utilizados os patch mais recentes disponíveis na data deste artigo de cada versão community do MongoDB para Linux x64 conforme a seguir:

• 3.2 (3.2.22)
• 3.4 (3.4.24)
• 3.6 (3.6.23)
• 4.0 (4.0.28)
• 4.2 (4.2.21)
• 4.4 (4.4.15)
• 5.0 (5.0.9)
• 6.0 (6.0.0)

O hardware utilizado contém a seguinte configuração:

• Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
• 4 CPUs 
• 16GB RAM

Segue o comando abaixo que foi utilizado para realizar o teste de performance para cada versão do MongoDB. O utilitário usado se encontra disponível em POCDriver.

java -jar /home/mongodb/POCDriver-master/bin/POCDriver.jar -k 20 -i 10 -u 10 -b 20 -r 10 -t 5 -d 3600

-k Fetch a single document using its primary key
-i add a new document
-u increment an integer field in a random document
-b what size to use for operation batches
-r fetch a range of 10 documents
-t how many threads to run on the client and thus how many connections
-d how long to run the loader for (seconds)

Ao final de 3600 segundos de execução (1 hora) para cada versão do MongoDB, os resultados foram computados em uma planilha. Vale a pena salientar que foram realizadas 3 execuções em cada versão do MongoDB e calculada a média dos resultados das 3 execuções. Cada resultado compõe-se das operações abaixo

• inserts per second
• keyqueries per second
• updates per second
• rangequeries per second 

Segue exemplo de um resultado que foi extraído para ser computado em uma planilha.

After 3600 seconds, 76738832 new documents inserted - collection has 76738832 in total
21316 inserts per second on average
13198 keyqueries per second on average
26182 updates per second on average
3767 rangequeries per second on average

Por fim, segue o resultado das execuções e o comparativo de performance de leituras e escritas entre as versões.

MongoDB - GROUP BY usando o $group (aggregation)

Olá,

Sabemos que em uma instrução SQL podemos utilizar o operador de agregação GROUP BY que é utilizado em conjunto com a cláusula SELECT para agrupar registros semelhantes em uma tabela. A seleção é feita de acordo os critérios definidos na cláusula WHERE, caso ela seja utilizada, e conforme o campo indicado para o agrupamento no comando GROUP BY. Sobre o resultado obtido, podemos aplicar diversas funções como:

• Somatória dos valores de uma coluna: SUM()
• Quantidade de registros que atenda a um critério: COUNT()
• Cálculo da média ponderada: AVG()
• Identificar os menores valores: MIN()
• Identificar os maiores valores: MAX()

No MongoDB também podemos utilizar tais funções de agregação e o objetivo deste artigo será o de demonstrar a sintaxe do comando. Para exemplificar, usando um banco de dados relacional, teremos o seguinte cenário.

SQL> create table t1 (uf varchar2(2));

Tabela criada.

SQL> insert into t1 values ('MG');

1 linha criada.

SQL> insert into t1 values ('MG');

1 linha criada.

SQL> insert into t1 values ('MG');

1 linha criada.

SQL> insert into t1 values ('MG');

1 linha criada.

SQL> insert into t1 values ('MG');

1 linha criada.

SQL> insert into t1 values ('SP');

1 linha criada.

SQL> insert into t1 values ('SP');

1 linha criada.

SQL> insert into t1 values ('SP');

1 linha criada.

SQL> insert into t1 values ('RJ');

1 linha criada.

SQL> insert into t1 values ('RJ');

1 linha criada.

SQL> commit;

Commit concluído.

 

Após inserir os registros como mostrado acima, para agrupar todas as unidades federativas de forma a mostrar a quantidade total de cada uma na tabela T1, executaremos a seguinte instrução SQL. 

 

SQL> select uf,count(*) qtd from t1 group by uf;

UF        QTD
-- ----------
RJ          2
SP          3
MG          5

Agora irei criar o mesmo cenário no MongoDB.

> use db01
switched to db db01
> db.t1.insertMany([
...    { uf: "MG" },
...    { uf: "MG" },
...    { uf: "MG" },
...    { uf: "MG" },
...    { uf: "MG" },
...    { uf: "SP" },
...    { uf: "SP" },
...    { uf: "SP" },
...    { uf: "RJ" },
...    { uf: "RJ" }
... ]);
{
        "acknowledged" : true,
        "insertedIds" : [
                ObjectId("624f3981426338c36f74d687"),
                ObjectId("624f3981426338c36f74d688"),
                ObjectId("624f3981426338c36f74d689"),
                ObjectId("624f3981426338c36f74d68a"),
                ObjectId("624f3981426338c36f74d68b"),
                ObjectId("624f3981426338c36f74d68c"),
                ObjectId("624f3981426338c36f74d68d"),
                ObjectId("624f3981426338c36f74d68e"),
                ObjectId("624f3981426338c36f74d68f"),
                ObjectId("624f3981426338c36f74d690")
        ]
}

 

Após inserir os documentos como mostrado acima, para agrupar todas as unidades federativas de forma a mostrar a quantidade total de cada uma presente na collection T1, executaremos a seguinte instrução. 

 

> db.getCollection("t1").aggregate([{"$group" : {_id: "$uf" , count:{$sum:1}}}]);
{ "_id" : "RJ", "count" : 2 }
{ "_id" : "SP", "count" : 3 }
{ "_id" : "MG", "count" : 5 }

MongoDB - Replica Set Animation

Olá,

Quando configuramos o MongoDB para funcionar em replica set, temos que ter no mínimo 3 membros: PSS (PRIMARY, SECONDARY, SECONDARY) ou PSA (PRIMARY, SECONDARY, ARBITER). Fiz uma pequena animação onde demonstro o que acontece quando em uma replica set quando um FAIL OVER automático ocorre (quando o PRIMARY fica indisponível) e suas consequências quando estamos utilizando a replicação assíncrona que, segundo a documentação, podem ocorrer ROLLBACKS de algumas instruções que foram gravadas no PRIMARY mas ainda não foram enviadas para o membro SECONDARY. No MongoDB o membro SECONDARY buscas as instruções gravavas no oplog do membro PRIMARY de forma a manter ambos membros sincronizados. Demonstro também o que acontece quando o comando stepDown() é manualmente digitidado no membro PRIMARY. Vale a pena salientar que mostro tanto os membros com (priority > 0), ou seja, qualquer um deles pode ser tornar PRIMARY no qual temos como benefício uma alta disponibilidade, quanto (priority = 0) o que significa que um membro não pode ser tornar PRIMARY no qual não teremos alta disponibilidade, mas em contrapartida não haverá perda de dados. 

 

 

Oracle Client 21c disponível para download

Olá,

O Oracle Client 21c já está disponível para download para as plataformas Linux.