Logotipo Rox Partner colorido
  • ROX Partner
    • Sobre Nós
    • Experts
  • Serviços
    • Banco de Dados
      • Consultoria
      • DBA Remoto 24×7
      • Migração
      • Gestão 24×7
      • DOC 24X7
    • Analytics
      • Construção de Datalake
      • Migração de Plataformas
      • Engenharia de Dados
      • Inteligência Artificial
      • DOC 24×7
      • Squads de Analytics
    • Infraestrutura
      • Consultoria
      • Sustentação
      • Virtualização
      • Segurança
      • DOC 24×7
    • Cloud
      • Migração on-premise
      • Cloud Híbrida
      • Cloud Pública
      • Custo Cloud
      • DOC 24×7
  • Soluções
    • Banco de Dados
      • Oracle
      • Microsoft SQL Server
      • IBM DB2
      • MySQL
      • PostGreSQL
      • MongoDB
      • Progress
      • Elastic
      • Apache Solr
      • Apache HBase
      • Apache Cassandra
    • Analytics
      • Hadoop
      • AWS RedShift
      • Azure SQL Datawarehouse
      • Google BigQuery
    • Cloud
      • Microsoft Azure
      • Google Cloud
      • Oracle Cloud
    • Infraestrutura
      • Dell
      • Aruba
      • Oracle Enterprise Linux
      • VMWare
      • VEEAM
      • Fortinet
  • Parcerias
  • Recursos
    • ServiceDesk
    • Rox Mon
    • White Paper
    • Webinar
    • Podcast
  • Blog
Fale com a gente
Logotipo Rox Partner colorido
  • ROX Partner
    • Sobre Nós
    • Experts
  • Serviços
    • Banco de Dados
      • Consultoria
      • DBA Remoto 24×7
      • Migração
      • Gestão 24×7
      • DOC 24X7
    • Analytics
      • Construção de Datalake
      • Migração de Plataformas
      • Engenharia de Dados
      • Inteligência Artificial
      • DOC 24×7
      • Squads de Analytics
    • Infraestrutura
      • Consultoria
      • Sustentação
      • Virtualização
      • Segurança
      • DOC 24×7
    • Cloud
      • Migração on-premise
      • Cloud Híbrida
      • Cloud Pública
      • Custo Cloud
      • DOC 24×7
  • Soluções
    • Banco de Dados
      • Oracle
      • Microsoft SQL Server
      • IBM DB2
      • MySQL
      • PostGreSQL
      • MongoDB
      • Progress
      • Elastic
      • Apache Solr
      • Apache HBase
      • Apache Cassandra
    • Analytics
      • Hadoop
      • AWS RedShift
      • Azure SQL Datawarehouse
      • Google BigQuery
    • Cloud
      • Microsoft Azure
      • Google Cloud
      • Oracle Cloud
    • Infraestrutura
      • Dell
      • Aruba
      • Oracle Enterprise Linux
      • VMWare
      • VEEAM
      • Fortinet
  • Parcerias
  • Recursos
    • ServiceDesk
    • Rox Mon
    • White Paper
    • Webinar
    • Podcast
  • Blog
Fale com a gente
Rox Partner
  • ROX Partner
    • Sobre Nós
    • Experts
  • Serviços
    • Banco de Dados
      • Consultoria
      • DBA Remoto 24×7
      • Migração
      • Gestão 24×7
      • DOC 24X7
    • Analytics
      • Construção de Datalake
      • Migração de Plataformas
      • Engenharia de Dados
      • Inteligência Artificial
      • DOC 24×7
      • Squads de Analytics
    • Infraestrutura
      • Consultoria
      • Sustentação
      • Virtualização
      • Segurança
      • DOC 24×7
    • Cloud
      • Migração on-premise
      • Cloud Híbrida
      • Cloud Pública
      • Custo Cloud
      • DOC 24×7
  • Soluções
    • Banco de Dados
      • Oracle
      • Microsoft SQL Server
      • IBM DB2
      • MySQL
      • PostGreSQL
      • MongoDB
      • Progress
      • Elastic
      • Apache Solr
      • Apache HBase
      • Apache Cassandra
    • Analytics
      • Hadoop
      • AWS RedShift
      • Azure SQL Datawarehouse
      • Google BigQuery
    • Cloud
      • Microsoft Azure
      • Google Cloud
      • Oracle Cloud
    • Infraestrutura
      • Dell
      • Aruba
      • Oracle Enterprise Linux
      • VMWare
      • VEEAM
      • Fortinet
  • Parcerias
  • Recursos
    • ServiceDesk
    • Rox Mon
    • White Paper
    • Webinar
    • Podcast
  • Blog
  • ROX Partner
    • Sobre Nós
    • Experts
  • Serviços
    • Banco de Dados
      • Consultoria
      • DBA Remoto 24×7
      • Migração
      • Gestão 24×7
      • DOC 24X7
    • Analytics
      • Construção de Datalake
      • Migração de Plataformas
      • Engenharia de Dados
      • Inteligência Artificial
      • DOC 24×7
      • Squads de Analytics
    • Infraestrutura
      • Consultoria
      • Sustentação
      • Virtualização
      • Segurança
      • DOC 24×7
    • Cloud
      • Migração on-premise
      • Cloud Híbrida
      • Cloud Pública
      • Custo Cloud
      • DOC 24×7
  • Soluções
    • Banco de Dados
      • Oracle
      • Microsoft SQL Server
      • IBM DB2
      • MySQL
      • PostGreSQL
      • MongoDB
      • Progress
      • Elastic
      • Apache Solr
      • Apache HBase
      • Apache Cassandra
    • Analytics
      • Hadoop
      • AWS RedShift
      • Azure SQL Datawarehouse
      • Google BigQuery
    • Cloud
      • Microsoft Azure
      • Google Cloud
      • Oracle Cloud
    • Infraestrutura
      • Dell
      • Aruba
      • Oracle Enterprise Linux
      • VMWare
      • VEEAM
      • Fortinet
  • Parcerias
  • Recursos
    • ServiceDesk
    • Rox Mon
    • White Paper
    • Webinar
    • Podcast
  • Blog

Category: banco de dados

16 de dezembro de 2022
Analyticsappsbanco de dadosCloud

Confira 6 Tecnologias utilizadas na Copa do Mundo do Catar 2022

A cada quatro anos, o mundo inteiro se reúne na festa do futebol. Questões políticas e culturais à parte, a edição da Copa do Mundo do Catar 2022 trouxe novidades incríveis quanto aos sistemas tecnológicos usados tanto no jogo como fora dele. 

E é a respeito deles que vamos abordar neste artigo. Confira!  

Quais as tecnologias utilizadas na Copa do Mundo do Catar 2022?  

 Em cada jogo do mundial estão sendo utilizados os seguintes recursos tecnológicos: 

  • Sensores na bola e trave para detecção de cruzamento da linha de gol; 
  • Um sistema semiautomático de detecção de impedimento; 
  • Novas capacidades do Árbitro Assistente de Vídeo (o famoso VAR);  
  • Um aplicativo de informações em tempo real para o torcedor 
  • Um grande sistema de coleta de dados que permite a geração de gráficos e a análise da partida quase em tempo real. 

Agora, você vai conhecer, em detalhes, 6 das principais tecnologias e inovações que a Copa do Mundo do Catar apresentou neste ano.  

 

Sistema de linha de gol atualizado

O sistema de linha de gol foi implementado na Copa de 2014. São utilizadas 14 câmeras de alta velocidade, sendo 7 para cada gol. Com as imagens de pelo menos 3 dessas câmeras, o sistema pode determinar a posição da bola com precisão, mesmo com a interferência dos jogadores ou do goleiro. Também pode indicar se ocorreu ou não o cruzamento da linha do gol.  Quando a bola cruza a linha do gol, o árbitro do jogo recebe, em um dos seus relógios, um sinal visual e vibratório indicando o gol. 

Além do aviso ao árbitro, o sistema também cria uma animação em 3D da posição da bola em relação com o gol. Na sequência, envia essa informação de forma imediata para as transmissoras de TV e para as telas que estão no estádio.  

Sistema semiautomático de Impedimento

O sistema semiautomático de impedimento é uma ferramenta de suporte para ajudar os árbitros que atuam no sistema de vídeo e os árbitros em campo a tomarem decisões de impedimento mais precisas e rápidas. 

Composto por 12 câmeras de rastreamento montadas sob o teto do estádio, as câmeras estão dedicadas a rastrear a posição da bola e os 29 pontos do corpo de cada um dos jogadores. Isso ocorre 50 vezes por segundo, sendo possível calcular a posição exata do jogador no campo. 

Os 29 pontos de dados coletados incluem ombros, cotovelos, mãos, quadril, joelhos, tornozelos, pés e cabeça de cada jogador, ou seja, todos os membros e extremidades relevantes para a marcação de impedimento.  

Como parte do sistema de detecção, a bola possui um sensor chamado de unidade de medição inercial (IMU). Esse sensor, posicionado no centro da bola, envia os dados do seu movimento para a sala de operações de vídeo, 500 vezes por segundo. Desse modo, permite uma detecção muito precisa do momento em que a bola foi chutada. 

Combinando os dados de rastreamento dos jogadores, e da bola, e com ajuda da inteligência artificial, sempre que ela é recebida por um atacante que estava em posição de impedimento , no momento em que foi chutada por um companheiro da equipe, a nova tecnologia dispara um alerta de impedimento para os árbitros de vídeo. Antes de informar o árbitro em campo, os árbitros de vídeo validam a decisão proposta, verificando, de forma manual, o ponto de chute selecionado e a linha de impedimento, ambos criados automaticamente, com base nas posições calculadas dos membros dos jogadores.  

Depois que a decisão é confirmada pelo árbitro em campo, os mesmos pontos de dados posicionais usados ​​para a tomada de decisão servem para gerar uma animação 3D, que detalha perfeitamente a posição dos membros dos jogadores quando a bola foi chutada. Essa animação 3D é exibida nas telas gigantes do estádio e também é disponibilizada para as transmissoras de TV. 

Sistema de linha de gol e impedimento copa do Catar 2022 

Novas Capacidades no Vídeo Assistant Referee (VAR)

O Árbitro Aassistente de vídeo ou VAR, foi usado pela primeira vez na Copa de 2018 e conta com o acesso às 42 câmeras usadas nas transmissões dos jogos, localizadas ao redor de todo o estádio. A maioria das câmeras são usadas para determinar a intensidade de uma falta, mas existem oito delas que são do tipo super câmera lenta, e quatro do tipo ultra câmera lenta que são usadas, normalmente, para mostrar as faltas com detalhe. 

Além das câmeras da transmissão, o VAR tem acesso às imagens geradas pelo sistema semiautomático de impedimento.  

Na sala de operação de vídeo (Vídeo Operation Room – VOR), uma equipe de quatro árbitros verifica os incidentes do jogo: o Árbitro Assistente de Vídeo (VAR) e três assistentes do VAR (AVAR1, AVAR2 e AVAR3). 

O VAR é responsável por liderar a equipe VAR e se comunicar com o árbitro em campo. Ele é responsável por observar a câmera principal no monitor superior e verificar todos os incidentes.  

O AVAR1 concentra-se na câmera principal e mantém o VAR informado caso algum incidente tenha sido verificado ou revisado. 

O AVAR2 concentra-se no sistema semiautomático de impedimento para acelerar o processo de verificação e revisão do VAR. 

O AVAR3 se concentra na transmissão de TV e auxilia o VAR na avaliação de incidentes. 

O sistema inclui um monitor perto da área técnica, onde o árbitro em campo pode revisar os vídeos enviados pelo VAR e realizar a tomada de decisão. 

A informação do processo de verificação pelo VAR, assim como o motivo da verificação, a etapa da verificação e o resultado são informados automaticamente, tanto ao público nas telas do estádio quanto às emissoras de TV.   

VAR Copa do Catar 2022

 

Football Data Ecosysistem

Durante o jogo, todas as ações no campo são registradas — todos os passes, chutes, substituições, decisões dos árbitros, ataques, defesas, faltas, aceleração, distância percorrida. 

O processamento de dados, ao vivo, permite garantir a maior qualidade e riqueza de dados possíveis em apenas alguns segundos, a partir do momento em que a ação ocorre no campo de jogo. Para isso, o processo de coleta de dados é dividido em várias etapas operacionais, criando diferentes camadas de dados.  

Analistas experientes, conhecidos como “speakers” ou locutores, estão no estádio e concentram toda a sua atenção no que está acontecendo no campo de jogo e passam essas informações para uma pessoa conhecida como “escritor”, que insere as informações no sistema.  

Além do locutor e do escritor, até dois observadores ao vivo são usados ​​para verificar os dados e coletar uma segunda camada de dados com informações adicionais. Enquanto as informações mais importantes e relevantes são captadas diretamente pelo locutor, os dois observadores, ao vivo, agregam valor a esses eventos no mais alto nível de coleta de dados.  

Para coletar os dados posicionais (coordenadas X e Y) de todos os jogadores, dos árbitros e da bola, o sistema de rastreamento óptico captura a posição do jogador várias vezes por segundo. Esses dados não apenas refletem a posição do jogador, mas também podem ser usados ​​para calcular velocidade, distância e direção do jogo. Essas métricas permitem que os analistas esportivos tenham insights mais profundos e consigam otimizar o desempenho físico dos jogadores e o desempenho tático da equipe. 

Os dados coletados são disponibilizados às equipes participantes, aos treinadores, aos jogadores e a mídia envolvida na Copa do Mundo, numa plataforma dedicada para análise de dados e vídeos.  

Football Ecosystem catar 2022

 Fifa Player App

O FIFA Player App permite que cada um dos jogadores acesse seus dados individuais de desempenho logo após cada partida. Os dados coletados incluem: 

Métricas de desempenho físico – coletadas pelo sistema de câmeras de rastreamento localizadas ao redor do estádio. As métricas incluem distância percorrida em vários limites de velocidade, número de ações acima de 25 km/h e velocidade máxima, tudo exibido em mapas de calor posicionais. 

Métricas de dados de futebol – são calculadas usando os dados de eventos capturados por uma equipe de analistas de desempenho de futebol da FIFA e combinados com dados de rastreamento dos jogadores, incluem eventos como lances de ataque, defesa, passes etc. 

Esses dados são sincronizados com as imagens da partida para permitir que os jogadores assistam a todos os momentos-chave de seu próprio desempenho com máximo detalhe, usando diferentes ângulos de câmera. 

Além disso, várias fotografias de ação são registradas durante os principais momentos de cada partida e disponibilizadas para cada jogador individualmente. 

fifa app catar 2022

Al Rihla: A bola mais tecnológica do mundo

A bola oficial da copa, a Al Rihla (A jornada, em português), possui dentro dela um dispositivo que pesa 14 gramas e que contém 2 sensores diferentes que operam simultaneamente:  

Um sensor de banda ultralarga (UWB): um tipo de tecnologia superior ao GPS ou bluetooth para dados posicionais precisos, além de poder transmitir dados em tempo real para rastrear constantemente a posição da bola. 

Uma unidade de medição inercial (IMU): um sensor com 9 eixos, giroscópio e acelerômetro, destinado a detectar movimentos sutis da bola no espaço. 

A bola transmite os dados dos sensores 400 vezes por segundo a um sistema de posicionamento local (Local Positioning System – LPS) conformado por 24 antenas ao redor do campo. Mediante triangulação, o sistema permite estabelecer a posição da bola dentro do campo com precisão menor a 10 cm. 

Com a informação transmitida, o sistema calcula métricas como velocidade da bola, longitude do passe, força do chute etc. e reconhece também, se é um toque, um passe ou um chute ao gol. 

Todos os dados capturados pelo sistema de posicionamento da bola e as métricas geradas a partir deles, são integrados ao ecossistema de dados da FIFA.  

Os dados estão presentes em todo lugar, e na copa do mundo não é diferente. É necessária uma infraestrutura robusta e eficiente para coletar e analisar toda a informação gerada em cada um dos jogos.  

a bola mais tecnologica do mundo

 

Mais sobre a Copa do Catar 2022

O Catar é um pequeno país localizado na península Arábica, Doha. Nasceu como um pequeno povoado de pescadores que se dedicavam ao cultivo de pérolas e a extração de tintas para tecidos a partir de caracóis marinhos. Hoje, o Catar é um dos países mais poderosos e ricos do mundo, graças à exportação de gás natural. 

Mas, viver no Catar não é simples. As temperaturas ultrapassam 40°C no verão, fazendo com que a Copa fosse alterada para o final do ano de 2022, quando as temperaturas normalmente desérticas são mais amenas. Dentre as inovações desta edição, destacam-se, também, as tecnologias implementadas na construção dos estádios. A principal delas foi, sem dúvida, o sistema de ventilação dos estádios.  

 

Tecnologia aplicada em megaeventos e também no seu negócio: Conheça a Rox Partner 

Já imaginou ter todos os dados da sua empresa em um quadro de fácil visualização, ou contar com relatórios inteligentes sobre cada ação feita pelo seu cliente? Ainda mais, poder controlar os seus equipamentos de forma remota e precisa? 

A Rox Partner possui um time focado em Analytics e Inteligência Artificial e está pronto para atender as demandas do seu negócio, seja ela de monitoramento, de controle ou de correção nos processos. Invista em IA, e descubra como podemos transformar a sua empresa por meio de dados. Fale com nossos especialistas!  

Learn More

Edgar Bermudez
27 de outubro de 2022
banco de dadosCloud

Ambiente Multi-cloud: O que é e por que precisamos de vários ambientes em nuvem?

Adam Ronthal, analista de gerenciamento de dados, comentou no evento do Gartner, ocorrido neste ano na Flórida, que: “A base de dados e análises é a nuvem!”

“Os negócios digitais exigem um sistema totalmente configurável.”

Mas o que é um ambiente Multi-cloud?

Quando se utiliza mais que uma plataforma de nuvem (duas ou mais plataformas públicas), cada uma com uma aplicação ou serviço específico, temos um ambiente Multi-cloud.

Esse ambiente pode ser composto de nuvens públicas, privadas ou edge computer. Conforme as necessidades da empresa, são combinadas operações locais com aplicações e serviços realizados em diversos provedores de nuvem pública.

Quais são os tipos e as diferenças entre as clouds?

Cloud Privada

Cloud (nuvem) privada é um tipo de arquitetura de computação em nuvem local. Essas nuvens, geralmente, são dedicadas a um grupo ou a um usuário, fazendo com que seja personalizável e seguro, porém o custo inicial acaba sendo mais alto.

As nuvens privadas são construídas e usadas exclusivamente por apenas uma única empresa, fornecendo processamento virtual adicional e recursos de armazenamento.

Cloud Pública

Com a cloud pública, os serviços são realizados por meio de um provedor terceirizado (como AWS da Amazon, GCP da Google, AZURE da Microsoft, Huawei Cloud etc.), com recursos altamente escaláveis e flexíveis, atendendo várias empresas/organizações simultaneamente.

Para a nuvem pública, o custo possui uma taxa previamente combinada e todos os recursos ou armazenamentos são gerenciados e protegidos pelo servidor.

As principais vantagens são a escalabilidade, disponibilidade e personalização sob demanda.

Nuvem híbrida

É um subconjunto de Multi-cloud, combinando especificamente um modelo de nuvem privada e pública.

Edge Computer

Traduzido como computação de borda, refere-se a manter, processar e analisar os dados na localidade onde estão. Isso faz com que se tenha alta escalabilidade, quase em tempo real, para análises e respostas. É um padrão de computação distribuída onde aproxima a computação e o armazenamento dos dados de sua fonte. A ideia é que, com essa proximidade, tenha-se respostas mais rápidas e uma economia em largura de banda. É considerada uma arquitetura e não uma tecnologia específica.

Multi-cloud e Nuvem Híbrida: não são iguais?

Apesar do conceito de ambos ser semelhante, não são iguais. No conceito literal, nuvem híbrida também é um modelo Multi-cloud. Porém, o contrário nem sempre se aplica. Uma Multi-cloud pode ser composta por um sistema híbrido (com informações em privada e pública) que se comunica, podem ser compostas de um sistema onde exista nuvens individuais que não se conversam. A diferença primordial é que, em uma implementação Multi-cloud, geralmente existirão duas ou mais nuvens públicas, o que não ocorre em uma implementação de nuvem híbrida.

A arquitetura de Multi-cloud oferece acesso a vários modelos de serviço. Já a nuvem híbrida permite que os operadores realizem uma única tarefa utilizando recursos de apenas duas nuvens distintas. 

Em 2018, Gartner previu que 70% das empresas implementariam uma estratégia Multi-cloud até o final de 2019. Esse número aumentou consideravelmente, já que ocorreu uma grande conscientização na sua utilização, aumento da variedade de provedores em nuvem, maior concorrência e variedade de ferramentas.

Quais são as vantagens em se utilizar ambiente Multi-cloud?

A ideia é procurar obter vantagem competitiva na economia digital moderna. Além disso, facilitar migrações, ter agilidade e a visibilidade necessária para garantir um gerenciamento contínuo de inventário, segurança, migração e mudanças.

Alguns pontos importantes a serem considerados para estar presente em várias nuvens diferentes:

Mobilidade, flexibilidade e escalabilidade

Não estar engessado a um único provedor facilita a mudança de uma nuvem para outra, provê a melhor estabilidade e oportunidade de negociações sobre custos. Possibilita, também, o melhor aproveitamento de cada provedor e liberdade para migração. É possível utilizar armazenamento sob demanda, para isso é importante que os servidores trabalhem juntos, permitindo que seja possível investir em qualquer nível de capacidade, segurança e proteção com base nas necessidades de cada segmento de dados. Isso evita danos e perdas de dados ou tempo de inatividade por falha de componente. Proporciona alta escalabilidade, pela possibilidade de escolha para qual região de data center de provedores de IaaS, será provisionado o projeto.

Adequação

Para cada atividade, é possível verificar o tipo de custo que cada provedor disponibiliza, podendo adequar uma atividade específica ao provedor que possui melhor tarifa. Também é possível utilizar a estratégia de Multi-cloud para cada tarefa individualmente. Isso faz com que os times de TI, administradores e de negócios alinhem-se com o provedor que melhor atenda cada atividade.

Quais são os desafios em se utilizar Multi-cloud?

Diferentes ferramentas e falta de capacitação.

Qualquer tipo de migração exige uma nova capacitação. Quando existe uma mudança de processos e procedimentos, como uma migração para Multi-cloud, é necessário que os profissionais tenham que aprender técnicas a serem aplicadas em várias nuvens. Podem ser ferramentas caras e criar diversos módulos de armazenamento, adicionando mais complexidade a uma infraestrutura já complexa.

 

Compartilhamento de dados e segurança

É possível encontrar dificuldades em sincronização e compartilhamento de dados, apresentar maturidade diferente de provedores e problemas com diferenças de API. Também é imprescindível que a segurança seja constantemente analisada para acompanhar as mudanças de software e infraestrutura.

Porém, quanto à segurança, esta não deve ser mais vista como uma barreira para a adoção de serviços em Multi-cloud. Na nuvem pública, existe uma infraestrutura programática de IaaS (IaaS – Infrastructure as a Service) que coloca a segurança como uma responsabilidade compartilhada. Isso quer dizer que o provedor da nuvem se responsabiliza pela segurança “da nuvem” e o usuário fica responsável pela segurança “na nuvem”. Para garantir a conformidade na nuvem e eliminar o máximo de erro humano, que geralmente é o responsável por facilitar os ataques cibernéticos, é interessante que todo o processo seja automatizado se possível.

Quando devo realizar a migração para uma Multi-cloud?

Essa decisão depende de muitos fatores e discussões. Envolve diversos tipos de áreas, pessoas e existem muitos pontos de vista e interesses diferentes. Ao migrar para a nuvem pública, as organizações devem explorar suas opções em termos de Software como Serviço (SaaS – Software as a Service), Plataforma como Serviço (PaaS – Platform as a Service) e infraestrutura como Serviço (IaaS – Infrastructure as a Service). A organização deve entender as diferenças entre as opções, incluindo recursos técnicos, financeiros e operacionais.

Vença seus maiores desafios empresariais com uma combinação de nossas soluções em Cloud

A Rox Partner é uma empresa de soluções em dados com experiência em migração, construções de ambientes e muitos outros serviços de cloud.

Entre em contato com a gente e descubra como as nossas soluções podem ajudar o seu negócio.

Learn More

Thais Naberezny
20 de setembro de 2022
banco de dados

O que é ETL e por que é importante a sua utilização?

O mundo de administração de dados está evoluindo rapidamente e, para as organizações, essas informações se tornaram um bem ainda mais valioso no auxílio ao processo de decisão. É nesse contexto que ocorre o processo de ETL.   

Em um breve passado, não havia menção para o termo ETL, apesar de muitas organizações já utilizarem esse processo. Hoje, termos como Data Warehouse (DW), Data Lake e Big Data fazem parte do vocabulário comum das empresas. E não é por menos, o gerenciamento de dados traz grandes oportunidades para o desenvolvimento das organizações, possibilitando conhecer a sua empresa, seus clientes e seu potencial.  

Para isso, é necessário fazer com que os seus dados brutos sejam organizados no processo de ETL, de modo a fornecer insights acionáveis ​​aos tomadores de decisão. 

O que é ETL?

A sigla ETL vem do inglês Extration, Transformation, Loading (extração, transformação e carga) e refere-se a um conjunto de processos para a utilização de Data Warehouse, um banco de dados que permite análises avançadas. O ETL visa trabalhar toda a parte de extração de dados de fontes externas, realizar a transformação desses dados para atender as necessidades de negócio e efetivar a carga desses dados para dentro do Data Warehouse.

O Data Warehouse é um ambiente destinado ao armazenamento de dados para acionamento em qualquer momento. Em qualquer iniciativa de DW, aplicar o processo de ETL é fundamental e deve ter escalabilidade, ser de fácil manutenção e ter um planejamento cuidadoso para não comprometer os sistemas transacionais (ou Online Transaction Processing – OLTP) das empresas. 

A importância do processo de ETL está também relacionada com a sua versatilidade, podendo ser aplicado em bancos de dados simples, como o SQL, e em bancos mais complexos, como uma nuvem de Big Data.

O ETL é comumente utilizado em Data Warehouse para ambiente de BI, mas é possível fazer uso de suas ferramentas em qualquer tipo de trabalho de importação, exportação e transformação para outro ambiente de banco de dados ou para outras necessidades de negócios.

Os projetos de Data Warehouse costumam consolidar dados das mais diferentes fontes, sendo mais comum serem em banco de dados relacionais ou flat files (arquivos simples). Os sistemas de ETL devem ser capazes de se comunicar com as mais diferentes bases de dados e ler os mais diversos tipos de formatos de arquivos.

O processo de ETL permite definir a qualidade e a forma com que os dados serão manipulados para que se tenha uma informação compreensível e confiável. Também serve para traçar uma estratégia de usabilidade ao estabelecer regras para a manipulação, padronizando e garantindo o aproveitamento dessas informações.

Como funciona o processo de ETL?

O processo de ETL funciona em 3 etapas:  

  1. Extração; 
  2. Transformação; 
  3. Carregamento. 

Confira, a seguir, as características de cada uma dessas etapas.

Primeira fase: Extração

Fase destinada à extração de dados SQL. É o momento em que é realizada a análise preliminar através da organização dos dados, convertendo-os em um formato único, com a finalidade de padronização.

Segunda fase: Transformação 

É o momento em que ocorre a adaptação e a limpeza das informações, reunindo somente o que efetivamente será aproveitado para análise. Nessa etapa são criados os filtros, de modo que as informações sejam agrupadas conforme critérios específicos para futuras análises.

Terceira fase: Carregamento

Nesta fase do processo é onde os dados organizados são transferidos para um novo repositório. A tabela é duplicada com a informação tratada e corrigida para impedir novos fluxos de desvio de informação. 

Necessariamente, o ETL não é executado em um único ambiente de tratamento informacional, podendo haver diversas aplicações para todo o processo.

Uma ação muito importante é analisar a janela de operação do ETL, pois não é a qualquer momento que ele deverá ser executado. Deve-se analisar o seu período de execução e definir o alcance dos dados que o ETL irá abranger, para que se tenha sucesso no processo.

Onde usar o processo de ETL?

O processo de ETL geralmente é usado em:  

  • Armazenamento de dados; 
  • Machine learning e inteligência artificial; 
  • Integração de dados de marketing; 
  • Integração de dados de Internet das Coisas (IoT, na sigla em inglês);
  • Réplica de banco de dados;
  • Migração para nuvem. 

Confira abaixo. 

Armazenamento de dados

Geralmente usado para mover os dados para um banco de dados em que várias origens são combinadas para análise.

Machine learning e inteligência artificial

No aprendizado de máquina, o sistema aprende usando técnicas de inteligência artificial e o ETL atua para mover os dados para um local único com finalidade exclusiva para o machine learning.

Integração de dados de marketing

O ETL atua na coleta e preparo dos dados, envolve mover todos os seus dados de marketing, como clientes, redes sociais e dados de análise da web.

Integração de dados de Internet das Coisas (IoT, na sigla em inglês)

Uma rede de objetos cotidianos físicos, capaz de reunir e de transmitir dados. O ETL ajuda a mover os dados de várias origens de IoT para um único lugar onde você pode analisá-los.

Réplica do banco de dados

O intuito é realizar uma cópia dos dados para a nuvem, pegando os dados dos seus bancos de origem (como Oracle, Cloud SQL para MySQL, Microsoft SQL Server, Cloud SQL para PostgreSQL, MongoDB, etc). Isso pode ser uma operação única ou um processo contínuo à medida que seus dados são atualizados, e o ETL pode ser usado para replicar os dados.

Migração para a nuvem

Usa-se o processo de ETL para executar as migrações dos dados para nuvem.

ETL uma ótima solução para seu negócio!

Conforme vimos, o processo de ETL possibilita a unificação dos dados, permitindo a implementação de uma estratégia de BI para utilização futura. Identificar padrões por meio dos dados é fundamental, pois resulta na compreensão de comportamentos que viabilizam as decisões do negócio.

Implementação de ETL, Rox Partner

Dúvidas para implementar o ETL ou sobre qual ferramenta utilizar nesse processo ou, ainda, se houver qualquer necessidade analítica, a Rox possui todo o suporte necessário! 

 

Conheça mais sobre as soluções que a Rox oferece e trabalhe os dados a seu favor!  

 

Aproveite e obtenha mais conhecimentos em nosso blog!

Learn More

Thais Naberezny
19 de agosto de 2022
banco de dados

dbt como ferramenta aceleradora da Jornada Data Driven

Algumas empresas possuem repositórios de dados centralizados (Data Warehouse e Data Lakes) que precisam ser trabalhados para gerarem valor. Nesse cenário, para revolucionar a Jornada Data Driven, é importante possuir uma ferramenta que se conecte a esses repositórios de dados e dê poder aos próprios usuários da área de negócio, analistas e engenheiros para gerar suas próprias transformações de dados, regras de negócios e insights valiosos. E uma das áreas que mais podem gerar valor com o uso de dados é a área de negócios. Em razão disso, surgiu a ferramenta dbt.

O que é dbt em dados?

dbt é uma ferramenta que facilita a transformação de dados. Dentro de um pipeline de dados, sempre é realizado um ETL ou ELT (extrair, transformar e carregar – na sigla em inglês). O dbt se concentra no “T” – transformação. Ele permite que qualquer pessoa com conhecimento em SQL crie fluxos de trabalhos de organização e transformações de dados, bem como seus fluxos de trabalho analíticos; tudo isso de forma colaborativa e seguindo as boas práticas de desenvolvimento de software como modularidade, portabilidade, CI/CD, testes e documentação.

Como surgiu o dbt em dados?

O dbt surgiu em 2016, em uma época quando existiam menos ferramentas em todas as etapas de dados. Mas foi criada para resolver essa dor latente que são a falta de unidade e o problema nas orquestrações de execuções SQL. 

Com o surgimento do Redshift, Big Query, Azure Sinapse, Snowflake e entre outros bancos de dados para Data Warehouse em Cloud e distribuídos, os Projetos de Analytics passaram a ser mais ágeis para serem construídos (antes um projeto poderia levar meses e até anos para ser processado) e mais acessíveis (financeiramente falando). Dessa forma, mais empresas conseguiram o acesso a esse ambiente analítico. Assim, o ecossistema, como um todo, foi beneficiado com essa evolução. Com isso, várias ferramentas apareceram para se conectar com esses Data Warehouse, entre eles o dbt. 

Um dos criadores do dbt, Tristan Handy, fazia parte da empresa RJ Metrics (que foi vendida para a Magento). Nesse contexto, há muito tempo, existiam pessoas envolvidas com analytics, preocupadas e conhecedoras de todo o ecossistema. 

O dbt suporta diversas ferramentas como motor de processamento SQL, entre elas, temos o Snowflake, Teradata, Amazon Athena, prestoDB e entre outras. Algumas das conexões para motores de processamento SQLs foram criadas pelos próprios desenvolvedores do dbt, mas, em sua grande maioria, foi uma contribuição da comunidade. Isso é um ponto muito forte do dbt, que é uma ferramenta Open Source e com um grande apoio da comunidade de desenvolvedores.

Princípios do dbt

O dbt trabalha com alguns princípios básicos, sendo eles: SQL para Desenvolvimento Rápido, Controle de Versão, Trabalho Colaborativo, CI/CD, Teste, Documentação e Linhagem de Dados. Vamos, agora, falar de cada um desses pontos: 

SQL para Desenvolvimento Rápido

O dbt é uma ferramenta que permite escrever em SQL combinado com uma linguagem de templates chamada Jinja, que possibilita que o código SQL seja reutilizável, modular, com blocos lógicos, condições e entre diversas outras facilidades. 

Além disso, é possível escrever os modelos SQL modulares com instruções SELECT e a função ref() – para referenciar outros modelos de dados já existentes no seu projeto dbt; nesse aspecto, sem se preocupar com o gerenciamento de dependência, já que o dbt lida com esta tarefa.  

Também é possível substituir operações DDL/DML padrão por instruções SQL SELECT simples que inferem dependências, criam tabelas, exibições e executam modelos em ordem.

Controle de versão, CI/CD e Trabalho Colaborativo

Com o dbt é possível implementar um pipeline de dados em SQL com segurança usando ambientes de desenvolvimento. O controle de versão habilitado para Git permite a colaboração e um retorno aos estados anteriores, em caso de falha e erros nos deploys. 

Outra característica interessante é o processo de observabilidade em fluxos de trabalho de transformação com agendamento, registro e alertas no aplicativo web do dbt. Neste ambiente, pode-se criar políticas de proteção, garantindo que os dados se movam por meio de processos governados, incluindo ambientes de desenvolvimento, com estágios de desenvolvimento e produção gerados por cada execução de CI.

Testes

O dbt permite testes de regressão automatizados para que seja possível garantir que os módulos SQL estejam realizando as transformações corretamente; além disso, garante que os dados de origem e os dados de resultado estejam no formato desejado.  

dbt oferece dois tipos de teste, os Testes de Esquema e os Testes de Dados: 

  • Testes de Esquema: declarações, como valores únicos, não nulos, aceitos e relacionados que são adicionados a arquivos .yml no modelo a ser testado. 
  • Testes de Dados: consultas SQL personalizadas que podem ser encontradas no diretório test. Os testes personalizados e pré-empacotados do dbt ajudam os desenvolvedores a criar uma “rastreabilidade” de suposições validadas para colaboradores de dados. 

Documentação

Os recursos de documentação do dbt oferecem a capacidade de definir modelos de dados e suas colunas em um arquivo yaml de “source”, facilitando o acompanhamento das principais definições de dados. 

É possível visualizar a documentação em uma interface web amigável,  por meio de um catálogo de dados, com definições, dependências e a linhagem de dados de todo o ecossistema dbt.

Linhagem

Na visualização do Lineage dos dados do dbt, é possível saber exatamente de onde os dados saíram e para onde eles foram. É possível visualizar a linhagem de dados não somente em termos de entidades de base de dados, mas também em termos de modelos, dependências e processamentos. O dbt possui também o conceito de “Exposures”, em que é possível dizer que determinado dado está disponível, tudo isso em uma visualização em dashboard no Metabase.

Como o dbt funciona?

Existem dois arquivos principais no dbt, o arquivo profiles.yml e dbt_project.yml. Esses são arquivos exclusivos dessa ferramenta de transformação e fornecem muito poder, permitindo que você personalize o seu ambiente conforme a sua necessidade.  

Os modelos de projetos são definidos no arquivo dbt_project.yml. É  por meio desse arquivo que o dbt sabe que um diretório é um projeto dbt. Ele também contém informações importantes que informam ao dbt como operar em seu projeto. 

O arquivo profiles.yml permite selecionar credenciais exclusivas de suas fontes e destinos de dados. Nestes arquivos, são descritos os perfis de banco de dados que serão conectados, com informações como: no profiles.yml. 

Além desses arquivos, existem algumas características bem definidas na ferramenta dbt, sendo elas: 

  • Projeto; 
  • Modelo;
  • Comandos.  

Como o dbt funciona?

Existem dois arquivos principais no dbt, o arquivo profiles.yml e dbt_project.yml. Esses são arquivos exclusivos dessa ferramenta de transformação e fornecem muito poder, permitindo que você personalize o seu ambiente conforme a sua necessidade.  

Os modelos de projetos são definidos no arquivo dbt_project.yml. É  por meio desse arquivo que o dbt sabe que um diretório é um projeto dbt. Ele também contém informações importantes que informam ao dbt como operar em seu projeto. 

O arquivo profiles.yml permite selecionar credenciais exclusivas de suas fontes e destinos de dados. Nestes arquivos, são descritos os perfis de banco de dados que serão conectados, com informações como: no profiles.yml. 

Além desses arquivos, existem algumas características bem definidas na ferramenta dbt, sendo elas: 

  • Projeto; 
  • Modelo;
  • Comandos.  

Projeto

Um projeto dbt é um diretório que contém arquivos .sql e .yml . Os arquivos mínimos necessários são: 

  • Um arquivo de projeto chamado dbt_project.yml  – esse arquivo contém configurações de um projeto dbt; 
  • Modelo(s) arquivos .sql  – modelo em dbt é simplesmente um único arquivo .sql contendo uma única instrução SELECT . 

Modelo

Um modelo dbt é basicamente um arquivo .sql com uma instrução SELECT. O modelo denominado “.sql” contém instruções SQL SELECT, que em tempo de execução serão aplicadas aos motores de processamento SQL – Data Warehouse com Snowflake, Redsfift, Big Query etc. ou framework de processamento SQL, como Spar, prestoDB, AWS Athena e entre outros. 

O modelo também define o esquema de nossas tabelas de origem em source e o esquema das visualizações a serem criadas em models.

Comandos

Os comandos dbt começam com dbt e podem ser executados usando uma das seguintes maneiras: 

  • dbt Cloud – a seção de comando na parte inferior do painel dbt Cloud; 
  • dbt CLI. 

Alguns comandos só podem ser usados ​​em dbt CLI como dbt init.

O que o dbt não é

  • Ferramenta de extração de dados: Como premissa, os dados já devem estar na Data Warehouse, no Data Lake, para que consiga transformar os dados com o dbt. 
  • Ferramenta de ETL/ELT:  Só atende a camada T de transformação. 
  • Orquestrador de fluxos de trabalho: Apesar de, internamente, orquestrar toda a execução dos arquivos SQL, ele trabalha somente com os arquivos dele próprio, ou seja, não consegue orquestrar fluxo de trabalho de linguagens diferentes. 
  • Ferramenta de migração de dados. 
  • Engine de processamento de dados: Ele orquestra a execução dos próprios arquivos em SQL e deixa para que o Data Warehouse se encarregue de processar essas consultas.

dbt e os próximos passos

O dbt oferece uma experiência única para engenheiros e analistas de dados, pois usa instruções SQL SELECT simples para realizar transformações pesadas de maneira limpa e econômica. Seus módulos têm execução competitivamente mais rápida e são fáceis de modificar e testar. A integração do dbt com os modelos e templates, juntamente com a sua capacidade de controle de versão e realização de testes automatizados, torna o processo de transformação de dados mais robusto e seguro. Esta é uma excelente ferramenta de transformação e processamento de dados, empoderando qualquer pessoa na Jornada Data Driven, desde que se sinta confortável com a linguagem SQL.  

No próximo post da nossa série sobre dbt, faremos um tutorial de exemplo, criando modelos, templates, testes e colocando nosso dbt em produção. 

Aproveite e conheça mais em nosso blog!  

Learn More

Luan Pinto
4 de agosto de 2022
banco de dados

Escalando aplicações com MongoDB

MongoDB é hoje um dos 5 bancos de dados mais famosos do mundo, mas você já teve curiosidade de saber o porquê dessa fama tão grande?  

Saiba isso e muito mais sobre MongoDB neste artigo.

O que é MongoDB?

MongoDB é um NoSQL baseado em documentos. Esses documentos possuem uma estrutura de dados no formato JSON. Esse tipo de estrutura é muito conhecido por toda comunidade de desenvolvimento de software. JSON é um formato baseado em JavaScript, que é hoje a linguagem de programação mais famosa do mundo. Atualmente, um desenvolvedor JavaScript pode ser totalmente full stack, usando front-end em JavaScript com seu framework predileto, back-end em Node.JS e banco de dados baseados em MongoDB, uma combinação perfeita. Além disso, existem milhares de bibliotecas para outras linguagens de programação que facilitam o trabalho tanto com JSON como com o MongoDB. 

Por fim, uma das coisas que faz com que o MongoDB seja tão famoso é sua facilidade e sua curva de conhecimento suave.

Mongo DB é uma ferramenta Open Source

Já pensou em ter um banco de dados quase 100 vezes mais rápido do que o principal e mais caro banco de dados do mercado? E sem gastar um centavo com licenciamento? É isso que o MongoDB te oferece! Ele é um NoSQL extremamente fácil de se trabalhar e é Open Source (código aberto) sob a licença GNU AGPL3. Essa licença lhe permite usar seu aplicativo comercial distribuído como serviço, sem precisar compartilhar o código. Desta forma, todo mundo que quer usar o MongoDB em um serviço comercial está amparado pela sua licença.

Mongo DB é Escalável, Altamente Disponível e Flexível

Uma das aplicações mais comuns que vemos no uso do MongoDB é em arquitetura de microsserviço. É muito rápido e simples subir uma instância única de MongoDB para atender o seu serviço. Na outra ponta, também é muito comum vermos grandes clusters de MongoDB com dezenas de máquinas rodando simultaneamente em empresas. Isto porque o MongoDB é altamente escalável e extremamente disponível. Com o MongoDB, você pode começar pequeno e quando necessário, aumentar sua capacidade rapidamente, atendendo a real demanda da sua aplicação. 

MongoDB e Cloud Computing uma combinação perfeita

Hoje, todos os principais provedores de cloud oferecem a você serviços de MongoDB gerenciado. Isso significa que você pode provisionar o seu MongoDB como serviço, sem se preocupar com o gerenciamento do seu cluster de Mongo. Existe ainda a possibilidade de utilizar o MongoDB Atlas, que é o serviço provisionado pela própria Mongo, empresa responsável pelo desenvolvimento do banco.

Muitas outras features

MongoDB possui diversas features muito legais, que nem todos os NoSQL possuem. Uma delas, por exemplo, é o suporte a transações ACID sobre múltiplos documentos de forma simultânea. Ele possui também a capacidade de realização de queries sobre qualquer campo do documento, inclusive campos em arrays e estrutura alinhadas. Ainda possui features de indexações, como a indexação secundária, que pode tornar suas queries muito mais rápidas e eficientes. Ele também suporta nativamente agregações e ordenação em queries.  

Para você que é desenvolvedor, diversos pacotes em sua linguagem favorita são disponibilizados pela comunidade. Um exemplo disso é que você pode escolher trabalhar diretamente com JSON dentro do Mongo ou pode usar o seu ORM favorito. 

Diversas outras features são oferecidas pelo MongoDB, mas eu gostaria de citar mais uma apenas, o GridFS. Essa feature possibilita você armazenar documentos extremamente grandes. Por deafult, você pode armazenar documentos de até 16MB no MongoDB, mas, caso precise de ainda maiores, o GridFS pode ser muito útil para você.

Conte com a Rox para suportar o seu MongoDB e foque no desenvolvimento do seu aplicativo

Apesar da sua grande popularidade, ainda não é tão comum encontrar no mercado profissionais como DBAs especializados em MongoDB. Essa é uma demanda cada vez mais comum em grandes projetos, principalmente quando é necessário aumentar a escala do seu cluster MongoDB, aplicar boas práticas, melhorar particionamento, sharding, replicas sets e entre outras características do seu cluster de MongoDB para aprimorar ainda mais o desempenho do seu banco de dados. Pensando nisso, a Rox desenvolveu um time especializado na manutenção, suporte e melhorias em MongoDB, seja on-primese ou na sua cloud favorita. Somos especializados em todo o ciclo de vida de dados e temos, além dos melhores DBAs em MongoDB, uma equipe completa especializada em infra-estrutura, cloud computing, DevOps, e banco de dados em geral. Com a Rox você pode focar no desenvolvimento das suas aplicações e ficar tranquilo com o suporte, manutenção e melhoria do seu ambiente de banco de dados NoSQL com MongoDB graças aos nossos especialistas. Não deixe de conversar conosco. 

Quer saber como podemos te ajudar? Clique aqui! 

Learn More

Luan Pinto
10 de maio de 2022
banco de dados

Como ativar e configurar um Replica Set no seu servidor com MongoDB

Quando se trabalha com alto volume de dados, uma das maiores preocupações é na possibilidade de algum problema, ou na armazenagem ou na transferência, causar a perda deles. Por isso, é necessário montar um sistema com a redundância em mente. Ou seja, os servidores precisam realizar cópias do arquivo principal, o qual sempre estará em comunicação com as partes replicantes. No caso em que o dado principal não estiver disponível, a cópia pode ser usada, garantindo a integridade do que é armazenado.

De fato, há diversas variantes que os Data Centers precisam se atentar, como software, hardware, questões de rede elétrica, temperatura da sala dos servidores e assim por diante. Porém o passo primordial é conseguir fazer com que o processo de replicação de dados esteja efetivamente operacional no sistema da empresa. Por isso, montamos um tutorial de como você pode configurar este mecanismo utilizando o software open source MongoDB.

Tutorial: Configurando o seu Replica Set

Em termos técnicos, vamos ensinar como converter uma instância Standalone em Replica Set, mantendo dois Nodes: um principal e um secundário. Meus servidores já estão com o MongoDB instalado e o principal já possui alguns Databases (dbs) criados. Focaremos em converter o MongoDB principal em Replica Set e em adicionar o Node secundário na replicação.

Para isso, temos dois servidores que vamos chamar de mongodb01 (Primário) e mongodb02 (Secundário).

Versão do sistema operacional: CentOS 8

Versão do MongoDB: 5.0.8

Primeiro passo é criar uma chave no servidor primário e compartilhar com o secundário.

openssl rand -base64 756 > /home/mongodb/keyFile/mongo-key
chmod 400 /home/mongodb/keyFile/mongo-key
scp /home/mongodb/keyFile/mongo-key root@xxx.xxx.xx.x:/home/mongodb/keyFile/

Lembrando que o diretório no qual será criada a chave deve ser feito previamente, tanto no servidor principal, quanto no secundário.

mkdir -p /home/mongodb/keyFile/

Após isso, precisamos colocar a chave nos arquivos de configuração do MongoDB primário e secundário.

Abaixo o arquivo de configuração que estou utilizando:

# mongod.conf
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# Where and how to store data.
storage:
dbPath: /var/lib/mongo
journal:
enabled: true
# engine:
# wiredTiger:
# how the process runs
processManagement:
fork: true # fork and run in background
pidFilePath: /var/run/mongodb/mongod.pid # location of pidfile
timeZoneInfo: /usr/share/zoneinfo
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,192.168.15.6 # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses or, alternatively, use the net.bindIpAll setting.
security:
authorization: enabled
keyFile: /home/mongodb/keyFile/mongo-key
#transitionToAuth: true
#operationProfiling:
#replication:
# replSetName: replicaset01
#sharding:
## Enterprise-Only Options
#auditLog:
#snmp:

IMPORTANTE: Para que nossa replicação funcione, não podemos esquecer dos seguintes parâmetros:

bindip: com o ip da máquina local, no exemplo da minha instância primária ficou bindIp: 127.0.0.1,192.168.15.6.

authorization: enabled = Habilitar a autenticação obrigatória no MongoDB, assim não sendo possível conectar sem passar usuário e senha.

keyFile: /home/mongodb/keyFile/mongo-key = Nossa chave de autenticação

replSetName: replicaset01 = O nome da nossa replicação, manter comentado com um # por enquanto.

Após configurar no MongoDB primário e secundário, vamos criar um usuário admin no nosso MongoDB primário, pois, como ativamos a opção de autenticação, será necessário a criação deste.

use admin
db.createUser(
{
user: ‘admin’,
pwd: ‘admin’,
roles: [ { role: ‘root’, db: ‘admin’ } ] }

No meu caso, criei o usuário “admin” com senha “admin” na role “root” dentro do db “admin”.

IMPORTANTE: Lembrando que meu ambiente é de teste. Na realidade, configurar um usuário e uma senha com maior complexidade.

Após isso, realizar o reinício da instância.

Para conectar, passar usuário e senha e o authenticationDatabase.

mongo -u “admin” -p “admin” –authenticationDatabase “admin”

Listar os bancos para validar se está tudo certo com o acesso.

show dbs

Validei que o acesso está funcionando no meu caso.

Agora que a mágica acontece! Vamos converter nossa instância do servidor mongodb01 em Replica Set. No arquivo de configuração, descomentaremos as linhas replication: e replSetName: replicaset01 e realizar o reinício da instância.

Conectado com o usuário admin, execute:

rs.initiate()

Pronto, já temos um primário.

Agora, vamos validar os membros do Replica Set.

rs.status().members

E validar também a configuração do Replica Set.

rs.config()

Neste momento, adicionaremos o secundário.

rs.add(“IP da máquina réplica”)

Neste caso, você pode adicionar o IP e a porta da seguinte maneira:

rs.add(“IP da máquina réplica:porta”)

Vamos validar os membros do Replica Set.

Observe que a replicação já adicionou meu secundário, porém apresenta uma mensagem de falha de conexão. Isso ocorreu pois ainda tenho que descomentar os parâmetros de chave e replicação na instância mongodb02 e reiniciá-la.

Após isto, a replicação conectou nos dois Nodes.

Não temos mais o erro. Agora vamos validar se replicou os dbs do primário para o secundário.

Observe que, no secundário, eu executei o rs.slaveOk() (que está sendo substituído pelo rs.secondaryOk()), já que, por se tratar de um secundário, não conseguimos executar os mesmos comandos que na instância primária, a não ser que você mesmo execute.

Nossa replicação já está funcionando, mas, dessa forma, podemos ter chaveamento entre primário e secundário. No meu caso, eu quero manter o mongodb01 como primário e o mongodb02 como secundário. Sendo assim, vamos executar os seguintes comandos no primário.

cfg = rs.conf()
cfg.members[0].priority = 1
cfg.members[1].priority = 0.5
cfg.members[0].votes = 1
rs.reconfig(cfg,{force: true})

Com isso, nossa replicação está configurada com sucesso. Você pode testar o sincronismo criando dbs.

Aqui executei o comando para criação do db que no exemplo chamei de roxdb.

use roxdb
db.user.insert({nome: “MySQL”, tipo: “banco de dados”})

E está feito! Espero que tenham gostado e contem para gente como foi sua experiência configurando seu Replica Set.

Learn More

Rodrigo Rabaço
30 de março de 2022
banco de dados

Tipos de Backup e Recuperação de Banco de Dados no SQL Server

Nos dias atuais, uma das maiores riquezas de uma empresa ou negócio, seja de  pequeno, médio ou grande porte, é a informação. Entender como um negócio funciona, ter as informações corretas e saber como elas se relacionam é algo fundamental para o sucesso nas tomadas de decisão.

Com a necessidade de armazenar uma quantidade grande de dados, e poder acessá-los de forma mais dinâmica, o tempo se encarregou de transferir essas informações de simples papéis para locais mais seguros e eficientes: um

banco de dados.

O conceito de banco de dados cresceu muito ao longo dos anos e a forma de se trabalhar com ele se aprimora dia após dia. Um banco de dados é um ambiente que permite armazenar dados de forma mais organizada e estruturada, gerando conjuntos de arquivos. Ele permite que, além de armazenar informações, possamos alterar, atualizar, consultar, apagar e até mesmo inserir novos dados com mais agilidade e praticidade.

Contudo, quanto maior a manipulação desses dados, maior o risco de acabar cometendo erros ou até mesmo danificar a integridade de um banco. Por isso, existe uma maneira de evitar esses riscos, recuperando dados importantes, informações alteradas, apagadas acidentalmente ou por conta de qualquer outra falha.

Essa forma é chamada de backup.

O que é backup e qual sua importância?

O backup é um termo que vem originalmente do inglês e que significa cópia de segurança. Como seu significado sugere, é um método utilizado para gerar a cópia de segurança dos dados (informações) de um dispositivo de armazenamento (celulares, tablets, computadores etc.) ou sistemas (aplicativos, softwares, jogos etc.).

Neste caso, o backup é utilizado para restaurar um banco em um determinado estado ou antes de algum ponto de falha. Pensamos no seguinte cenário: sua empresa armazena diversas informações sobre funcionários, usuários, renda, gastos, produtos e outros elementos importantes em um banco de dados.

Agora, imagine que por algum descuido, alguém acaba apagando essas informações ou apaga a tabela inteira que armazenava dados sobre seus funcionários. Ou pior, por um motivo qualquer, alguém apaga o banco de dados inteiro, e todas as informações da sua empresa que estavam armazenadas nele simplesmente não “existem” mais.

É justamente essa a importância de sempre ter um backup do banco de dados. Em cenários de desastre e recuperação de um banco, o backup é uma parte crucial. Com ele, conseguimos trazer essas informações de volta em um estado anterior ao ponto de falha. Sem ele, não conseguimos recuperar as informações.

Quais os tipos de backup de um Banco de Dados?

Trazendo o conceito de backup para o lado do banco de dados, pode-se dizer que temos diferentes tipos de backup que podem atender diferentes cenários. Basicamente, todos possuem o mesmo propósito de recuperar o banco em um determinado estado.

Contudo, a depender do cenário, precisamos recuperar o banco de dados em um ponto extremamente específico. Por isso, nós temos 3 tipos distintos de backup com o SQL Server. São eles: 

  • Backup full 
  • Backup log
  • Backup diferencial. 

A diferença entre eles é o modo com que o backup é feito, o tempo de realização do processo e a maneira como acontecerá a restauração dos dados que fizeram backup.

Backup Full

O backup full ou backup completo, é o backup de todo o banco de dados (configurações, atributos, objetos, páginas de dados, procedures etc.). Esse tipo de backup é o mais utilizado e recomendado para ambientes com criticidade alta. Isso porque, ao fazer o backup do banco inteiro, conseguimos aumentar a taxa de sucesso ao recuperar um banco e suas informações. É extremamente recomendado que um banco possua um backup full.

Como fazer um backup full?

Bom, aposto que de tanto ouvir falar, você quer aprender a realizar um backup full. Na verdade, o procedimento é simples. Contudo, é necessário sempre ter atenção no momento de realizar o procedimento. O primeiro passo é localizar o banco que desejamos fazer o backup.

  1. Dentro do seu ambiente SQL Server, clique com o botão direito em cima do banco de dados > Tarefas > Fazer Backup
  2. Será aberto uma janela parecida com essa:
  3. Em vermelho – Banco de dados: Neste campo, informamos o nome do banco que será feito o backup.Em verde – Tipo de Backup: Neste campo, informamos o tipo de backup que desejamos realizar. Como neste caso iremos realizar o backup full, podemos deixar da forma que está selecionado em “completo”.Em azul – Diretório: Neste campo, informamos o local em que queremos armazenar nosso arquivo de backup. Por padrão, o SQL armazena no diretório Program Files\Microsoft SQL Server\MSSQL15.InstanceName\MSSQL\Backup, mas você pode alterar para onde desejar.
  4. Feito isso, basta clicar em “OK” e o backup do banco será feito. Para saber se foi concluído com sucesso, basta verificar se essa mensagem de sucesso apareceu:
  5. Por fim, podemos acessar o local em que alocamos o backup e verificar se o arquivo .bak foi gerado com sucesso. Note que foi gerado, e agora o banco db_sistema possui um backup full.

Backup Log

O backup log faz o backup apenas do log de transações do banco de dados. Esse backup grava só o que é obtido pelo LSN (Log Transaction Number). Neste tipo de backup, conseguimos minimizar nossa exposição à perda de trabalho. Além disso, realizando o backup log, conseguimos truncar o log de transações, o que consequentemente impede que o log do banco fique cheio e o banco não faça mais transações, além de recuperar o espaço em disco.

Diferente do backup full, o backup log deve seguir algumas particularidades simples. Como:

  • Só conseguimos fazer o backup log de um banco, se ele possuir um backup full
  • Para fazer o backup log, é necessário que o banco de dados possua o parâmetro Recovery Model como Caso esteja em SIMPLE, não conseguimos fazer o backup log.

O backup log também é extremamente recomendado para ambientes com criticidade alta. Em geral, sua frequência depende de alguns fatores, como: a importância dos dados, o tamanho do banco e a quantidade de transações que ocorrem no banco.

Como fazer um backup log?

O procedimento para realizar o backup log também é extremamente simples. Basta que o banco atenda as particularidades mencionadas anteriormente.

  1. Para fazermos o backup, temos que selecionar com o botão direito o nome do banco de dados > Tarefas > Fazer Backup
  2. Será aberta a mesma janela do backup full. Contudo, nesse caso, iremos realizar algumas alterações, ficando dessa forma:
  3. Em azul – Banco de dados: Neste campo, informamos o nome do banco que será feito o backup.
    Em verde – Tipo de Backup: Neste campo, informamos o tipo de backup que desejamos realizar. Como neste caso iremos realizar o backup log, portanto, iremos selecionar “Log de Transações”
    Em vermelho – Diretório: Neste campo, informamos o local em que queremos armazenar nosso arquivo de backup. Assim como no backup full, iremos armazenar em Program Files\Microsoft SQL Server\MSSQL15.InstanceName\MSSQL\Backup.

IMPORTANTE: Diferente do backup full, a extensão usada para o backup log é a .trn. Assim como exemplo da imagem acima, sublinhado em vermelho.

Backup Diferencial

Dentre os três backups apresentados, o backup diferencial é o que menos é usado. Porém, isso não significa que ele não seja importante e, da mesma forma que os outros, é usado outro cenário. Seu nome já nos dá uma dica de qual é o seu propósito e como ele funciona.

O backup diferencial faz o backup do banco desde o último backup full executado. Isso é chamado de base do diferencial.

Para ficar mais simples de entender, podemos usar a imagem abaixo:

Todo o contorno da linha preta (incluindo as partes em vermelho e verde) – É o nosso banco de dados.

Parte vermelha – É o backup full. Assim como mostrado na imagem abaixo, efetuamos o backup do banco db_sistema no dia 04 de fevereiro de 2022 às 23:57 horas.

Parte verde – É o backup diferencial, que pega a diferença entre o último backup full realizado e o estado recente do banco de dados.

 

Ou seja, o backup diferencial tende a ser mais rápido, isso porque ele não faz o backup do banco de dados inteiro, somente da diferença.

Então, imagine que vamos rodar o backup diferencial às 10:00 horas do dia 05 de fevereiro de 2022. Ele vai fazer o backup do que foi alterado após às 23:57 horas do dia 04 de fevereiro de 2022 até às 10:00 horas do dia 05 de fevereiro de 2022.

Recuperação de Banco de dados

Partindo do pressuposto que o seu banco de dados está com os backups full e log, ou até mesmo o diferencial, em dia, não há motivos para se preocupar exceto um, que pode lhe causar uma imensa dor de cabeça e atrapalhar o fluxo do seu negócio.

Como dito anteriormente, o banco de dados está suscetível a erros ou até mesmo situações em que são inseridos, alterados e/ou apagados determinados dados de forma equivocada. Felizmente, o seu banco está com os backups em dia. Então, fique feliz, pois há salvação e é extremamente possível recuperá-lo antes do erro ou ponto de falha, perdendo a menor quantidade de dados possível.

Nesta parte do artigo, vamos aprender como recuperar os backups do banco de dados, conseguindo reverter alguns desastres e erros.

Recuperação de um backup full

Primeiro, é importante ressaltar que, uma vez que o banco e seus dados foram comprometidos, o mesmo terá que ser sobrescrito, ou seja, revertido para um estado anterior.

Para os exemplos, iremos utilizar o AdventureWorks2019 que é gratuito e disponibilizado pela Microsoft para fins de testes e aprendizados.  Conseguimos baixar o arquivo .bak no seguinte link: Bancos de dados de exemplo do AdventureWorks – SQL Server | Microsoft Docs

Para restaurar um backup full, você deve seguir os seguintes passos:

  1. Na sua instância SQL Server, clique com o botão direito em Bancos de dados > Restaurar Banco de Dados
  2. Será aberta a seguinte tela.Note que não há nenhum arquivo de backup escolhido. Para escolher o arquivo, basta selecionarmos os componentes marcados em vermelho, conforme as imagens abaixo:

  3. Nesta tela, temos que ter atenção em alguns pontos:
    • Primeiro: É importante informar no campo “Local do Arquivo de Backup” (linha azul) o diretório em que está armazenado o arquivo .bak do banco de dados que você está tentando restaurar. Sem isso, o SQL não saberá qual arquivo será restaurado e o restore falhará. No meu caso, baixei o arquivo do banco AdventureWorks e coloquei no diretório padrão de backups do SQL, mas o local onde irá armazená-lo fica a seu critério.
    • Segundo: Selecionar o arquivo de backup que deseja restaurar (linha vermelha). Para nosso exemplo, iremos selecionar o bak;
    • Terceiro: Concluído os dois passos anteriores, podemos clicar em “OK” (linha verde) e OK novamente na próxima tela;
  1. Feito isso, você deve receber a tela da seguinte maneira. Note que ele reconheceu o dispositivo em que estamos pegando o arquivo de backup (C:\Program Files\Microsoft SQL Server\MSSQL15.CARLOSMENDES\MSSQL\Backup\AdventureWorks2019.bak), o nome do banco de dados (AdventureWorks) e a data na qual foi feito o backup (segunda-feira, 15 de junho de 2020 às 20:26:36).
  2. Caso quisessemos, poderíamos alterar o nome do banco de dados e restaurá-lo com outro nome, mas nesse caso não será necessário.
  3. Por fim, basta clicar em “OK” e você deve receber a seguinte mensagem de sucesso, conforme a imagem abaixo:
  4. Agora, conseguimos ver que o banco está em nossa instância SQL foi recuperado com êxito.
    Obs.: Caso não apareça o banco, basta clicar com o botão direito em Banco de dados > Atualizar (Refresh) e ele deverá aparecer.

Recuperação de um backup log

Como falamos antes, a recuperação de um banco de dados visa, acima de tudo, voltar o banco ao estado antes da falha ou do erro que aconteceu. Acontece que, dependendo do tamanho do banco de dados e de quando foi feito o último backup full, a perda de dados pode ser gigante. Para entender melhor, vamos montar o cenário, aplicando com a prática.

Supondo que meu banco restaurado há pouco, AdventureWorks, seja meu banco de produção, extremamente crítico, com diversas transações e processos em execução. Eu faço o backup full dele diariamente, durante a madrugada, pois o banco é grande e demora para concluir o backup. Então, eu executo o backup full do meu banco de dados às 02:00 horas.

Imagine que este banco está recebendo conexões e processos normalmente. Em um dado momento, preciso que seja criada a tabela “funcionário”. Sendo assim, executo a DDL de criação da tabela e começo a popular a mesma, conforme o exemplo abaixo:

Após isso, iremos executar o backup log do banco de dados.

 

Agora, iremos dropar a tabela criada anteriormente, com o comando DROP TABLE. Note que ao executar o comando select na tabela “funcionário”, recebemos o erro do Database Engine informando que a tabela não existe no banco.

Ou seja, tínhamos criado uma tabela chamada “funcionário” e populamos ela com dados. Mas, após o drop, ela não existe mais. Você pode até estar pensando: “Ok, só precisamos restaurar o backup full do banco de dados”. Contudo, a tabela “funcionario” foi criada após o backup full. Se restaurássemos, não teríamos a tabela de volta.

Por sorte, fomos precavidos e rodamos o backup log após a criação da tabela e, com ele, conseguimos restaurar o banco de dados até o momento em que o drop table ocorreu. Primeiro, temos que ter em mente que, para restaurar um backup log, devemos primeiro restaurar o último backup full que foi executado, e após isso, aplicar os arquivos de log até o momento em que a tabela foi apagada. Então vamos lá!

Vamos restaurar um backup full, da mesma forma que restauramos o banco AdventureWorks2019, mas dessa vez, ao invés de fazermos via tela gráfica, faremos via script. Isso porque nesse caso, como iremos restaurar um log por cima, precisamos nos atentar em alguns pontos e adicionar alguns comandos.

  1. Seguindo o passo a passo para recuperar um backup full, antes de clicar em “OK”, vamos clicar em Script > Janela do Editor de Nova Consulta
  2. Com isso, teremos o seguinte script:

    Segue script:
    USE
    [master]
    ALTER DATABASE [AdventureWorks2019] SET SINGLE_USER WITH ROLLBACK IMMEDIATE /* –> Estamos alterando o banco de dados para usuário único, fazendo com que asconexões abertas com o banco que será restaurado sejam encerradas, e as transações em andamento sejam revertidas; */
    RESTORE DATABASE [AdventureWorks2019] /* –> Comando para restaurar o banco de dados (Informa o banco de dados que vamos restaurar — banco destino); */
    FROM  DISK = N’Backup Path’ /* –> Informa qual é o backup que está sendo resturado; */
    WITH  FILE = 1, /* –>  Informa a partir de qual datafile será realizado o restore (Quando = 1, significa que será usado o datafile primário (primary) — .MDF); */
    NOUNLOAD,
    NORECOVERY, /* –> Permite que mais sequências de backup sejam restauradas; */
    REPLACE, /* –> Significa que o banco de dados será sobrescrevido; */
    STATS = 5 /* –> Porcentagem de progresso que será informada durante o restore (Quando = 5, significa que o SQL mostrará a porcentagem de progresso do restore de 5 em 5); */
    GO
  3. Vale lembrar que é extremamente importante colocar a opção Isso porque ela vai permitir que posteriormente, consigamos restaurar o backup log após o backup full.
    1. Como vimos acima, o restore foi executado com sucesso. Sendo assim, o banco de dados que estamos recuperando, AdventureWorks2019, deverá ficar com o status “Restoring” (Restaurando). Dessa forma:
    2. Muito bem, agora temos que restaurar o backup log. Para fazermos isso, temos que clicar com o botão direito em Tarefas > Restaurar > Log de Transações

    3. Com isso, você deverá ver a seguinte tela. Para escolhermos o arquivo de log que vamos restaurar, devemos marcar o checkbox “Do dispositivo:” e clicar no quadrado marcado em vermelho e depois em “Adicionar” como mostra as imagens abaixo:

     

  4. Assim como na recuperação do backup full, temos que escolher o arquivo que iremos restaurar. Mas dessa vez, iremos escolher o backup log que fizemos anteriormente, logo após criarmos a tabela “funcionario”. Após selecionado clique em “OK” e depois em “OK” novamente.

    1. Feito isso, clicaremos em Script > Ação do Script para a Nova Janela de Consulta
    2. Assim, o script deverá aparecer em uma nova janela de edição de query:

      Note que foi aberto em uma sessão diferente. É importante que você copie e cole o script na mesma sessão em que você rodou o restore do backup full. Desta vez, sem a opção norecovery. Isso porque queríamos resgatar apenas este backup log. Contudo, quando for restaurado mais de um backup log, sempre deverá ter a opção norecovery, deixando apenas o último arquivo que será restaurado sem essa opção. Dessa forma, o Database Engine entende que não há mais sequências de backup para serem restauradas, e que o banco pode enfim entrar em uso.
    3. Por fim, quando executado com sucesso, deverá receber algo como isto:
    4. Se você verificar o banco de dados AdventureWorks2019, ele não está mais com o status “Restoring” (Restaurando), estando finalmente online novamente.
    5. Agora, chegou o momento de verificarmos se a tabela “funcionario” que havia sido excluída, está de volta, executando o seguinte script:

      USE
      AdventureWorks2019
      GO
      SELECT *FROM FUNCIONARIO
    6. Podemos notar que a tabela está no banco de dados novamente e com os registros que foram inseridos logo após sua criação.

      Assim, podemos ver a importância de sempre estar com o backup full e log em dia. Isso porque, quando esses eventos de desastre no banco de dados surgirem, será possível recuperar o que foi perdido de forma mais assertiva e pontual. Mesmo tendo suas particularidades, todos os tipos de backup (full, log e diferencial) possuem o mesmo objetivo e ajudam a garantir a segurança das informações em caso de comprometimento da integridade do banco de dados. Além disso, também vimos que é possível recuperar estes backups, retornando o estado do banco no momento específico antes de algum erro cometido. Por isso, mantenha sempre seu ambiente SQL Server com os backups em dia, para que em caso de falhas ou outros problemas que interfiram no seu banco de dados, a margem de perda de dados seja a menor possível.

     

Learn More

Carlos Mendes
4 de março de 2022
banco de dados

Entenda o ciclo de vida de uma Query no SQL Server: Parte 2

Anteriormente, no último artigo, nós havíamos percorrido “todo” caminho de uma Query, da sua execução à entrega ao solicitante. Mas, será que algo além acontece nos bastidores? A resposta é, como quase sempre será, sim!

Neste artigo, vamos nos aprofundar no Storage Engine, Buffer Pool, Access Methods e Transaction Log. Pegue o café e venha desvendar mais uma etapa sobre a execução de processos DDL e DML.

Storage Engine – Access Methods

Como falamos anteriormente, nesta etapa há diferenças entre processos DDL e DML. Vamos começar pela primeira: DDL é uma abreviação de Data Definition Language (Linguagem de Definição de Dados), ou seja, uma linguagem que cria ou modifica estrutura de objetos no banco de dados. Um exemplo rápido são comandos do tipo CREATE, ALTER E DROP.

Neste caso, quando o procedimento chega no Query Executor há uma interação com o Storage Engine através do Access Methods, que é quem fornece as estruturas de armazenamento dos dados e índices, bem como a interface pela qual os dados são recuperados e modificados. Ele é responsável por armazenar operações de linha, índice, alocação de páginas e versionamento. Apesar de conter todo o código da operação, ele não executa, pois, neste ponto ele passa a requisição ao Buffer Manager.

Storage Engine – Buffer manager

Você se lembra que, no primeiro artigo, comentamos que na etapa do Command Parser, o SQL analisa se há um plano de execução pronto para aquela requisição? Pois esta é justamente uma das funções do Buffer Manager:

Ele é responsável por gerenciar o Buffer Pool, ou seja, ele cuida de toda parte de recebimento, armazenagem e entrega de dados. Se você precisar ler algumas linhas de uma página de dados, ele verificará se esta página já está na cache de memória e, caso não esteja, ele buscará esta página no disco, armazenará na cache e só então devolve o resultado ao Access Methods. É nesta última etapa que acontece o famoso Wait_Type PAGEIOLATCH, que representa o tempo  necessário para ler uma página do disco e guardar em memória.

Ele também é responsável por gerenciar funções de I/O de disco para trazer páginas de dados e índices para a cache de memória e compartilhar com os usuários, além de assegurar que o Transaction Log seja escrito antes que cada alteração de banco seja executada, garantindo que essas informações guardadas no Transaction Log tenham uma ordem específica e deixando claro quais blocos de registro devem ser processados em caso de falha de sistema, independentemente de quando ou onde houve a falha.

Storage Engine – Data Cache

Bom, já sabemos que existe Buffer Pool e que quem “gerencia” essa casinha é o Buffer Manager. Contudo, neste Pool não existe apenas a Plan Cache (aliás, esta é a menor parte), existe também o Data Cache e nós vamos falar um pouco mais sobre ele agora.

O Data Cache é a partição do Buffer Pool que ocupa mais espaço. É nele que todas (sim, todas) as páginas de dados são lidas a partir do disco antes de serem usadas. E quando eu digo disco, são os datafiles dos bancos. O tempo que as páginas permanecem em cache é determinado por uma política LRU, para a qual precisamos abrir um parênteses: LRU-K (Last Recently Used) é um algoritmo que mantém “fresco na memória” uma página que é referenciada K vezes.

Cada página de dados possui em seu cabeçalho detalhes das duas últimas vezes em que a página foi acessada e é feita uma varredura periódica para determinar se essa página deve ou não continuar em Cache. Essa varredura também é efetuada pelo Buffer Manager. Sempre que uma varredura é feita, um contador é colocado na página e é incrementado toda vez que a página não é acessada por um determinado período de tempo e quando o SQL Server precisa liberar espaço em cache. Então, as páginas com o contador mais baixo são retiradas da Cache. Um tempo recomendado para que todo esse processo deva ocorrer é de 1000s.

Storage Engine – Transaction Manager / Transaction Log

Agora vamos falar sobre comandos do tipo DML. DML é uma abreviação de Data Modification Language (Linguagem de modificação de Dados). Esta é uma linguagem que resgata, guarda, modifica, insere, deleta e atualiza dados no banco de dados. Exemplo disso são comandos do tipo SELECT, UPDATE, INSERT, DELETE e etc.

O que difere os processos de DML dos processos de DDL, é que, no DML, em paralelo atua também o Transaction Manager. Quando o Buffer Manager recebe uma requisição de alteração, ela encaminha antes ao Transaction Manager para que este guarde um log desta transação para que só então guarde as páginas em cache.

O Transaction Manager possui dois componentes para garantir a consistência da requisição: O Lock Manager e o Log Manager. O Lock Manager gerencia a concorrência de dados através de locks e o Log Manager armazena de fato o log da transação no logfile. Esse tipo de processo é chamado de WAL (Write-ahead Logging).

Mas, neste processo, ainda falta alguém. De maneira análoga, o Buffer Manager está para o Buffer Pool assim como o Transaction Manager está para o Transaction Log! O Transaction Log, utiliza o logfile através dos VLF’s (Virtual Log Files) para armazenar e ordenar esses dados “recuperáveis”. Essa arquitetura é relativamente simples e a receita que o SQL Server usa é basicamente o seguinte:

 

  • Se o próximo crescimento for menor que 1/8 do tamanho físico do log atual, crie 1 VLF que abranja o tamanho do crescimento (começando com SQL Server 2014 (12.x))
  • Se o próximo crescimento for maior que 1/8 do tamanho atual do log, use o método pré-2014:
  • Se o crescimento for menor que 64 MB, crie 4 VLFs que abranjam o tamanho do crescimento (por exemplo, para um crescimento de 1 MB, crie quatro VLFs de 256 KB)
  • Se o crescimento for de 64 MB a 1 GB, crie 8 VLFs que abranjam o tamanho do crescimento (por exemplo, para um crescimento de 512 MB, crie oito VLFs de 64 MB)
  • Se o crescimento for maior que 1 GB, crie 16 VLFs que abranjam o tamanho do crescimento (por exemplo, para um crescimento de 8 GB, crie dezesseis VLFs de 512 MB)

E com isso, finalizamos mais um artigo. Os métodos de Recovery (recuperação) serão abordados em outra ocasião, pois é um processo um tanto quanto extenso.

Então, fique atento ao Blog da Rox, pois em breve será publicada a parte 3 deste conteúdo superinteressante.

Até a próxima e se inscreva em nossa newsletter!

Learn More

Igor Paixão
2 de fevereiro de 2022
banco de dados

Entenda o ciclo de vida de uma Query no SQL Server: Parte 1

Tão importante quanto ter um modelo de troubleshooting desenhado, é entender o que levou a acontecer o incidente. Muito se pode entender do problema, olhando todos os pontos da execução da requisição, e esse é o intuito deste artigo: explorar todo o ciclo de vida de uma query. Entre a solicitação do usuário e a entrega do resultado, muita coisa acontece no SQL Server e é o que veremos a seguir.

Protocol Layer

Tudo começa quando um usuário envia uma solicitação via SNI( SQL Server Network Interface) ao banco de dados a partir de uma query, e aqui vamos utilizar o exemplo de uma instrução do tipo SELECT. Esta solicitação é encaminhada ao SBGD através de um protocolo denominado TDS (Tabular Data Stream) que fica responsável por “desembrulhar” este pacote no client e analisar o que está sendo solicitado. Este mesmo protocolo é o responsável por retornar o resultado ao solicitante ao fim da execução.

Relational Engine – Command Parser

O próximo componente é o Command Parser e é onde a “mágica” começa. Nesta camada, o SQL lida com eventos de T-SQL, analisando sua sintaxe e devolvendo caso haja quaisquer erros de volta à camada do solicitante. Com a sintaxe validada, o próximo passo é criar um plano de execução ou reaproveitar um plano ja existente no Plan Cache. Neste caso é criado uma hash do T-SQL para verificar nesta partição do Buffer Pool se há um plano adequado. se houver, a instrução é designada diretamente ao Query Executor, e falaremos mais sobre ele logo abaixo.

Relational Engine – Query Optimizer

“Beleza, mas e se não houver um plano adequado para a solicitação?”, Neste caso o CMD Parser gerará uma árvore de consulta baseado no T-SQL e enviará à camada do Query Optimizer. Esta camada é uma das mais complexas e “misteriosas” do SQL Server. ele avalia a árvore baseando-se em custos e o objetivo é encontrar o plano mais eficiente, ou seja, um plano que terá o menor custo de execução. Em um plano, cada operador tem um custo de linha de base, que é então multiplicado pelo tamanho da linha e pelo número estimado de linhas para obter o custo desse operador — e o custo do plano é o custo total de todos os operadores. Este “Custo” é apenas um número arbitrário utilizado para representar o custo de recurso do plano em questão.

Esta otimização ocorre em 3 fases e são elas:

  • Fase 0 — Durante esta fase, o otimizador analisa os NESTED LOOP JOINS e não considerará operadores de paralelismo. O otimizador vai parar aqui se o custo do plano que encontrou for < 0.2. Um plano gerado nesta fase é conhecido como um processo de transação, ou TRIVIAL PLAN (Plano Trivial).
  • Fase 1 — A Fase 1 usa um subconjunto das possíveis regras de otimização e procura padrões comuns para os quais já possui um plano. O otimizador vai parar aqui se o custo do plano que encontrou for < 1.0. Planos gerados nesta fase são chamados de QUICK PLAN (planos rápidos).
  • Fase 2 — Esta fase final é onde o otimizador puxa todas as paradas e é capaz de usar todas as suas regras de otimização. Ele também olha para o paralelismo e as visualizações indexadas (se você estiver executando a Enterprise Edition) – FULL PLAN (otimização TOTAL).

Relational Engine – Query Executor

E assim chegamos ao Query Executor. Este componente é o responsável por de fato executar a query, trabalhando por cada etapa do plano e devolvendo o resultado ao usuário. Nesta parte do ciclo, há uma interação com o mecanismo de armazenamento para recuperar ou modificar dados. E nesta parte há diferenças entre instruções DML e DDL. Iremos explorar esta diferença no próximo artigo com mais detalhes.

 

Com isso, chegamos ao fim deste artigo. Espero que tenham gostado e nos vemos no próximo capitulo.

Learn More

Igor Paixão
10 de dezembro de 2021
banco de dadosCloud

Conheça o Delta Lake

O mundo de dados está em constante evolução e, por vezes, alguns conceitos já estabelecidos – como por exemplo, o armazenamento em nuvem e Data Warehouses – precisam ser revistos com a chegada de novas tecnologias. O Delta Lake é exatamente um desses casos. Mas, afinal, o que é o Data Lake e quais são suas vantagens? Confira essas informações e muito mais neste artigo! 

 

O que é Delta Lake?

Criado pelo time da Databricks, Delta Lake é um projeto opensource para armazenamento de arquivos, baseado no formato delta, persistidos no HDFS ou em Data Lakes (AWS, Azure, GCP), utilizando o Spark como motor de transformação e persistência. Esse formato trará algumas vantagens que veremos a seguir no artigo, como transações ACID e versionamento dos dados. 

 

Como funciona o Armazenamento no

Delta Lake?

Embora à primeira vista o “delta” se pareça um novo formato de armazenamento, de fato, ele nada mais é do que uma mescla de armazenamento físico em Parquet (compressão Snappy) -que é um formato colunar muito utilizado no mundo dos dados – junto à uma camada adicional de metadados/logs transacionais. Aqui cabem duas observações importantes: 

  1. Os metadados/logs são persistidos no mesmo diretório da tabela Delta que está sendo manipulada, portanto não é necessário nenhuma infraestrutura adicional para armazenar esses arquivos. Abaixo vemos um exemplo da estrutura do diretório de uma tabela chamada my_table, particionada pelo campo date:
  2.  Essa camada de logs (_delta_log) irá registrar todas as alterações realizadas na tabela, salvando o histórico de transformações em arquivos json/parquet e mantendo sempre a versão mais recente das alterações como padrão, porém permitindo acessar versões anteriores da tabela também.Com base nesses arquivos que o Delta nos permite viajar no tempo, pois nos permite acessar versões antigas da tabela para consultar ou até restaurar a tabela inteira para uma versão anterior.

Quais as Vantagens do Delta Lake?

Listamos aqui algumas grandes vantagens que o Delta Lake nos traz:

  • Transações ACID (atomicidade, consistência, isolamento e durabilidade) para as tabelas
  • Escalabilidade: por se utilizar de Data Lakes nativos da Cloud, ela permite escalabilidade de petabytes
  • Viagem no tempo e auditoria dos registros: possível ver versões antigas da tabela e também os registros da sessão que  a modificou
  • Reforço e evolução dos schemas da tabela
  • Suporte à operações de Updates, Merges e Deletes
  • Funciona tanto para jobs batch quanto para streaming
  • Estratégia eficaz para múltiplas leituras e escritas concorrentes nas tabelas Delta 
  • APIs de fácil acesso, podendo ser utilizado em Python, SQL ou Scala por meio do Spark
  • Permite remover arquivos antigos com o comando VACUUM

Utilização do Delta Lake

A utilização do formato delta é bem simples e está disponível por meio das APIs do Spark em Python (Pyspark), SQL e Scala. Abaixo alguns exemplos simples de como é possível utilizar o formato com SQL:

  • Criar tabela
CREATE TABLE tabela
date DATE
id INTEGER)
USING DELTA
PARTITION BY date
LOCATION "/delta"
  • Ver detalhes da tabela
DESCRIBE DETAIL tabela;
  • Ver histórico da tabela (últimas 5 versões)
DESCRIBE HISTORY tabela LIMIT 5;
  • Apagar versões históricas da tabela (maiores de 200 horas)
VACUUM tabela RETAIN 200 hours
  • Viajando no tempo (versão antiga número 4)
SELECT * FROM tabela VERSION AS OF 4
  • Operações DML

São permitidos comandos INSERT, UPDATE, MERGE e DELETE   Todas as possibilidades de Delta Lake para os times de dados!  Conforme visto, a tecnologia do Delta Lake e seu formato delta trazem inúmeros benefícios para os times de dados que já fazem utilização do Spark ou que gostariam de começar a utilizá-lo. Embora tenha sido desenvolvido pelo Databricks, o Delta Lake é open source e pode ser utilizado em diversos outros tipos de aplicações Spark como o EMR (AWS), Dataproc (Google Cloud), Kubernetes e On-premises.  A possibilidade de ter tabelas ACID em seu Delta Lake permitiu a criação de um novo conceito no mundo de dados, o Data Lakehouse, que se propõe a ser a fusão do Data Lake com o tradicional Data Warehouse (que será tema de um próximo artigo, fique ligado!).  Esperamos que esse artigo tenha ajudado a entender melhor os conceitos do Delta Lake e como ele pode ajudá-lo em seus projetos. Caso tenha interesse em implementar um projeto ou saber mais, entre em contato com nossos Roxperts , ficaremos felizes em ajudá-lo!

Learn More

Rox Partner
  • 1
  • 2
  • 3
Posts recentes
  • O que é Data Literacy? A importancia da Alfabetização de Dados Para sua empresa
  • Confira 6 Tecnologias utilizadas na Copa do Mundo do Catar 2022
  • Privacidade e Anonimato em Cidades Inteligentes
  • Ambiente Multi-cloud: O que é e por que precisamos de vários ambientes em nuvem?
  • Rox Partner e Conta Simples, uma parceria que deu sucesso! Confira esse case de Analytics
Soluções

Categorias
  • Analytics (5)
  • apps (1)
  • banco de dados (21)
  • blog (1)
  • business (2)
  • Cloud (4)
  • Infraestrutura (4)
  • Privacidade (1)
Tags
app Armazenamento de arquivos backup diferencial backup full backup log banco de dados bigdata cloud database data driven data engineering Delta Lake DML engenharia de dados etl ingestion mobile monitoramento mydumper nifi optane retenção script Spark SQL sqlserver sql server Storage Engine streamsets wallet

White Papers

Baixe Aqui
Localização
Av. Dr. Chucri Zaidan, 1550
Conjunto 2105
CEP 04711-130
São Paulo - Brasil
Contato
   contato@roxpartner.com
   +55 11 4040-8250
Newsletter

    Copyright © 2022 ROX Partners by lab212. All Rights Reserved

    @media only screen and (max-width: 768px){ #softlab_spacer_63d2ef3b0fb4d .spacing_size{ display: none; } #softlab_spacer_63d2ef3b0fb4d .spacing_size-tablet{ display: block; } }@media only screen and (max-width: 480px){ #softlab_spacer_63d2ef3b0fb4d .spacing_size{ display: none; } #softlab_spacer_63d2ef3b0fb4d .spacing_size-mobile{ display: block; } }
    Usamos cookies em nosso site para oferecer uma experiência mais relevante, lembrando suas preferências e visitas repetidas. Ao clicar em “Aceitar Tudo”, você concorda com o uso de TODOS os cookies. No entanto, você pode acessar as "Configurações de Cookies" para fornecer um consentimento controlado. Para mais detalhes acesse nossa Política de Privacidade.
    CONFIGURAÇÕES DE COOKIESACEITAR TODOS
    Política de Privacidade & Cookies

    Privacidade & Cookies

    Este site usa cookies para melhorar sua experiência de navegação. Destes, os cookies categorizados como Necessários são armazenados no seu navegador, pois são essenciais para o funcionamento de funções básicas do site. Também usamos cookies de terceiros que nos ajudam a analisar e entender como você usa este site e esses cookies serão armazenados no seu navegador apenas com o seu consentimento. Você também tem a opção de desativar esses cookies, mas a desativação de alguns deles pode afetar sua experiência de navegação.
    Necessário
    Sempre ativado
    Os cookies necessários são absolutamente essenciais para o bom funcionamento do site. Esses cookies garantem funcionalidades básicas e recursos de segurança do site, anonimamente.
    CookieDuraçãoDescrição
    _GRECAPTCHA5 meses e 27 diasEste cookie é definido pelo serviço de recaptcha do Google para identificar bots para proteger o site contra ataques de spam maliciosos.
    cookielawinfo-checkbox-advertisement1 anoEste cookie é usado para registrar o consentimento do usuário para os cookies na categoria "Anúncio", caso existam.
    cookielawinfo-checkbox-analytics11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Analytics", caso existam.
    cookielawinfo-checkbox-functional11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Funcionais", caso existam.
    cookielawinfo-checkbox-necessary11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Necessário", caso existam.
    cookielawinfo-checkbox-others11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Outros", caso existam.
    cookielawinfo-checkbox-performance11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Performance", caso existam.
    viewed_cookie_policy11 mesesO cookie é usado para armazenar se o usuário consentiu ou não o uso de cookies. Ele não armazena nenhum dado pessoal.
    Analytics
    Os cookies analíticos são usados para entender como os visitantes interagem com o site. Esses cookies ajudam a fornecer informações sobre métricas de número de visitantes, taxa de rejeição, origem de tráfego, etc.
    CookieDuraçãoDescrição
    _ga2 anosO cookie _ga, instalado pelo Google Analytics, armazena informações anonimamente e atribui um número gerado aleatoriamente para reconhecer visitantes únicos.
    _ga_4RLBM0693H2 anosEste cookie é instalado pelo Google Analytics.
    _gat_gtag_UA_172713136_11 minutoDefinido pelo Google para distinguir usuários.
    _gid1 diaInstalado pelo Google Analytics, o cookie _gid armazena informações sobre como os visitantes usam um site, além de criar um relatório de análise de desempenho. Alguns dos dados coletados incluem o número de visitantes, sua fonte e as páginas que eles visitam anonimamente.
    _rdtrk9 anos 10 meses 14 dias 11 horas e 3 minutosUtilizado pelo RD Station para manter uma lista de todas as páginas que um visitante acessou dentro do domínio.
    CONSENTIMENTO2 anosO YouTube define esse cookie por meio de vídeos do youtube incorporados e registra dados estatísticos anônimos.
    rdtrk1 anoUtilizado pelo RD Station para manter uma lista de todas as páginas que um visitante acessou dentro do domínio.
    UID2 anosA Scorecard Research define esse cookie para pesquisa de comportamento do navegador.
    Anúncio
    Os cookies de publicidade são usados para fornecer aos visitantes anúncios e campanhas de marketing relevantes. Esses cookies coletam informações para fornecer anúncios personalizados.
    CookieDuraçãoDescrição
    VISITOR_INFO1_LIVE5 meses e 27 diasUm cookie definido pelo YouTube para medir a largura de banda que determina se o usuário obtém a interface do player nova ou antiga.
    YSCsessãoO cookie YSC é definido pelo Youtube e é usado para rastrear as visualizações de vídeos incorporados nas páginas do Youtube.
    yt-remote-connected-devicesnão expiraO YouTube define esse cookie para armazenar as preferências de vídeo do usuário usando o vídeo incorporado do YouTube.
    yt-remote-device-idnão expiraO YouTube define esse cookie para armazenar as preferências de vídeo do usuário usando o vídeo incorporado do YouTube.
    Outros
    São cookies não categorizados, aqueles que estão sendo analisados e ainda não foram classificados em uma categoria específica.
    CookieDuraçãoDescrição
    __trf.src1 anoUtilizado pelo RD Station, esse cookie guarda a referência da origem da visita do usuário ao site.
    SALVAR E ACEITAR
    Desenvolvido por CookieYes Logo
    Preencha os campos abaixo para realizar o download