commit 3ac7e2e75695d15571158174baa3bb91e96f6622 from: amb date: Thu Jun 25 01:56:42 2026 UTC slides, resumo commit - 28821ef6c51f82ec6c383a266cc3564273929893 commit + 3ac7e2e75695d15571158174baa3bb91e96f6622 blob - b3c617a55bf292cde351a492779ce54ed5c1b6c7 blob + d7715ad746d6096b51a93f954c324bbbd7d6cbd6 Binary files main.pdf and main.pdf differ blob - /dev/null blob + 97366e8dc477999699764a016c0a3d34e87becca (mode 644) Binary files /dev/null and MariaDBEnteprise-Profile-GuidedOptimization-20150401_0.pdf differ blob - 882a6669cbdc93247da63f3429689bdf9c7afda8 blob + cbc4c3caf09c6f3cab1df8da7b44c9c2f93df4d9 --- main.tex +++ main.tex @@ -3,7 +3,7 @@ oneside, % Capítulos começam em página ímpar a4paper, % Tamanho do papel english, % Idioma adicional para hifenização - brazil % O último idioma é o principal do documento + brazilian % O último idioma é o principal do documento ]{abntex2} % --- Pacotes Básicos --- @@ -40,16 +40,16 @@ } \begin{document} -\selectlanguage{brazil} +\selectlanguage{brazilian} \frenchspacing \imprimircapa \imprimirfolhaderosto \begin{resumo} - O resumo deve apresentar, de forma clara e objetiva, o objetivo da pesquisa, o método utilizado, os principais resultados e as conclusões. Deve ser escrito em um único parágrafo, com frases concisas, sem enumeração de tópicos ou citações. + Este trabalho investiga como técnicas de otimização aplicadas ao MariaDB, em múltiplas camadas da infraestrutura de dados, podem melhorar o desempenho e reduzir custos operacionais em ambientes de produção. A pesquisa será conduzida como estudo de caso único, com coleta de métricas antes e depois de intervenções na camada de banco de dados, no sistema de arquivos e na compilação customizada do MariaDB. A análise será quantitativa, com comparação de latência, vazão de processamento, consumo de recursos e custo estimado de infraestrutura. A avaliação utilizará base anonimizada ou massa equivalente e uma carga de trabalho representativa derivada de um ambiente real de produção. Como resultado esperado, busca-se identificar combinações de otimização tecnicamente viáveis capazes de sustentar a carga analisada com menor capacidade computacional, preservando a estabilidade e a qualidade do serviço. - \textbf{Palavras-chave}: infraestrutura; otimização; banco de dados. + \textbf{Palavras-chave}: MariaDB; otimização; desempenho; custos operacionais; estudo de caso. \end{resumo} \pdfbookmark[0]{\contentsname}{toc} @@ -60,32 +60,31 @@ \pagestyle{simple} \chapter{INTRODUÇÃO} -Bancos de dados relacionais estão no núcleo de praticamente toda aplicação web. No setor de \textit{Software as a Service} (SaaS), onde a infraestrutura é faturada por consumo, a eficiência com que o sistema gerenciador de banco de dados (SGBD) utiliza CPU, memória e disco reflete-se nos custos operacionais da empresa. O MariaDB, \textit{fork} comunitário do MySQL mantido pela MariaDB Corporation e pela comunidade, é um dos SGBDs mais empregados nesse cenário. A maioria das implantações, no entanto, utiliza binários pré-compilados distribuídos pelos repositórios das distribuições Linux, com configurações-padrão pensadas para compatibilidade ampla em vez de desempenho. Van Aken et al.~\cite{vanaken2017} demonstram que a configuração de um SGBD é um problema de alta complexidade e que os valores-padrão raramente são adequados para a carga de trabalho real, o que leva a um desperdício de processamento e memória que poderia ser evitado. +Bancos de dados relacionais sustentam grande parte dos sistemas transacionais contemporâneos. Em ambientes de produção, especialmente quando a infraestrutura é contratada sob demanda, a eficiência com que o sistema gerenciador de banco de dados (SGBD) utiliza CPU, memória e disco influencia diretamente o desempenho da aplicação e o custo operacional associado. O MariaDB, \textit{fork} comunitário do MySQL mantido pela MariaDB Corporation e pela comunidade, é um dos SGBDs mais empregados nesse contexto. A maioria das implantações, no entanto, utiliza binários pré-compilados distribuídos pelos repositórios das distribuições Linux, com configurações-padrão pensadas para compatibilidade ampla em vez de desempenho. \citeonline{vanaken2017} demonstram que a configuração de um SGBD é um problema de alta complexidade e que os valores-padrão raramente são adequados para a carga de trabalho real, o que leva a um desperdício de processamento e memória que poderia ser evitado. -Este trabalho investiga o impacto da otimização em múltiplas camadas de infraestrutura sobre o desempenho de uma aplicação SaaS de pequeno porte, abrangendo o ajuste de parâmetros do SGBD, a refatoração de consultas SQL, a comparação entre sistemas de arquivos e a compilação customizada do código-fonte do MariaDB. A premissa é que a aplicação combinada dessas técnicas permite reduzir a infraestrutura contratada (\textit{downscaling}) sem perda de desempenho. +Apesar da relevância prática do tema, intervenções de otimização em MariaDB costumam ser analisadas de forma isolada. Ajustes em consultas SQL, parâmetros internos do SGBD, sistema de arquivos e características do binário afetam o comportamento do banco de maneiras distintas, mas nem sempre são avaliados em conjunto sob uma mesma carga de trabalho. Nesse contexto, este trabalho propõe analisar como essas camadas se relacionam em um ambiente controlado, com base em uma carga representativa derivada de uso real, de modo a avaliar ganhos de desempenho, eficiência no consumo de recursos e a viabilidade de redução (\textit{downscaling}) da infraestrutura necessária. \section{PROBLEMA DE PESQUISA} -Sistemas gerenciadores de bancos de dados relacionais como o MariaDB costumam ser implantados com binários generalistas e configurações que pouco se ajustam ao hardware ou à carga de trabalho específica do ambiente. Van Aken et al.~\cite{vanaken2017} destacam que a busca manual por boas configurações de SGBD exige conhecimento especializado e tempo, o que leva a maioria das implantações a operar com valores-padrão conservadores. Como consequência, observa-se uma subutilização crônica de CPU e memória e uma saturação prematura da vazão de processamento (\textit{throughput}). +Sistemas gerenciadores de bancos de dados relacionais como o MariaDB costumam ser implantados com binários generalistas e configurações que pouco se ajustam ao hardware ou à carga de trabalho específica do ambiente. \citeonline{vanaken2017} destacam que a busca manual por boas configurações de SGBD exige conhecimento especializado e tempo, o que leva a maioria das implantações a operar com valores-padrão conservadores. Como consequência, observa-se uma subutilização crônica de CPU e memória e uma saturação prematura da vazão de processamento (\textit{throughput}). -Sob cargas de trabalho com alta concorrência, o sistema degrada: a latência aumenta e o \textit{throughput} cai. Silberschatz et al.~\cite{silberschatz2019} explicam que esse comportamento está ligado à forma como o SGBD gerencia o tráfego entre memória e disco; quando os buffers são mal dimensionados, o acesso ao disco se torna o gargalo. A resposta mais comum no mercado é o superprovisionamento, ou seja, a alocação de mais recursos de hardware (escalabilidade vertical). Trata-se de uma correção pontual: o novo hardware é consumido pela mesma ineficiência de antes, e os custos operacionais crescem de forma proporcional. +Sob cargas de trabalho com alta concorrência, o sistema degrada: a latência aumenta e o \textit{throughput} cai. \citeonline{silberschatz2019} explicam que esse comportamento está ligado à forma como o SGBD gerencia o tráfego entre memória e disco; quando os buffers são mal dimensionados, o acesso ao disco se torna o gargalo. A resposta mais comum no mercado é o superprovisionamento, ou seja, a alocação de mais recursos de hardware (escalabilidade vertical). Trata-se de uma correção pontual: o novo hardware é consumido pela mesma ineficiência de antes, e os custos operacionais crescem de forma proporcional. -Esse cenário manifesta-se na prática numa empresa de pequeno porte do setor SaaS acompanhada neste estudo. A organização mantém um sistema em produção que, com o crescimento da base de usuários, passou a apresentar gargalos de desempenho no acesso aos dados. A infraestrutura atual opera com sistema operacional de uso geral, sistema de arquivos na configuração padrão e binários pré-compilados do MariaDB obtidos via gerenciador de pacotes. A ausência de ajuste em qualquer uma dessas camadas contribui para picos de latência nos horários de pico e pressionou a empresa a considerar \textit{upgrades} de hardware em nuvem para sustentar a operação. +Esse problema manifesta-se com frequência em ambientes reais de produção, nos quais o crescimento do volume de dados, do número de usuários e do nível de concorrência expõe gargalos no acesso aos dados. Em muitas implantações, a infraestrutura opera com sistema operacional de uso geral, sistema de arquivos na configuração padrão e binários pré-compilados do MariaDB obtidos via gerenciador de pacotes. A ausência de ajuste coordenado nessas camadas contribui para picos de latência e pressiona a ampliação da infraestrutura antes que alternativas de otimização sejam devidamente avaliadas. -Diante desse quadro, formula-se a seguinte questão de pesquisa: quais são os impactos da otimização em múltiplas camadas de infraestrutura, englobando sistema operacional, sistema de arquivos, compilação customizada de binários e parâmetros do SGBD, no desempenho e nos custos operacionais de uma aplicação SaaS de pequeno porte? +Diante desse quadro, formula-se a seguinte questão de pesquisa: quais são os impactos da otimização em múltiplas camadas de infraestrutura, englobando refatoração de consultas, parâmetros do SGBD, sistema de arquivos e compilação customizada de binários, no desempenho e nos custos operacionais de um ambiente transacional de pequeno porte? \section{OBJETIVOS} \subsection{Objetivo Geral} Avaliar o impacto da aplicação de técnicas de otimização em múltiplas camadas de infraestrutura, englobando a refatoração de consultas, ajustes de parâmetros do -SGBD, escolha do sistema de arquivos, escolha do sistema operacional e -compilação customizada do código-fonte, visando maximizar a vazão de +SGBD, escolha do sistema de arquivos e compilação customizada do código-fonte, visando maximizar a vazão de processamento, minimizar a latência e viabilizar a redução de custos operacionais -(\textit{downscaling}) de uma aplicação SaaS de pequeno porte. +por meio do \textit{downscaling} da infraestrutura. \subsection{Objetivos Específicos} Para o alcance do objetivo geral proposto, definem-se os seguintes objetivos específicos: \begin{alineas} - \item diagnosticar o cenário atual (\textit{baseline}) da infraestrutura de banco de dados da empresa, aferindo métricas de consumo de recursos, latência e \textit{throughput} sob a carga de trabalho existente; + \item diagnosticar o cenário atual (\textit{baseline}) da infraestrutura de banco de dados sob estudo, aferindo métricas de consumo de recursos, latência e \textit{throughput} sob a carga de trabalho existente; \item aplicar técnicas de otimização na camada de banco de dados, compreendendo a refatoração de consultas lentas e o ajuste fino (\textit{tuning}) de parâmetros do SGBD; @@ -93,95 +92,95 @@ Para o alcance do objetivo geral proposto, definem-se \item aferir a diferença de performance e consumo de recursos entre a utilização de binários genéricos do SGBD e binários compilados especificamente para a arquitetura de \textit{hardware} do servidor; - \item analisar os resultados obtidos nos diferentes cenários de teste para determinar a viabilidade técnica e financeira de realizar o \textit{downscaling} da infraestrutura sem comprometer os requisitos de desempenho da aplicação. + \item analisar os resultados obtidos nos diferentes cenários de teste para determinar a viabilidade técnica e financeira de realizar o \textit{downscaling} da infraestrutura sem comprometer os requisitos de desempenho do ambiente analisado. \end{alineas} \section{JUSTIFICATIVA} -A computação em nuvem tornou acessível a empresas de qualquer porte o mesmo tipo de infraestrutura antes restrita a grandes corporações. No modelo de precificação por consumo (\textit{pay-as-you-go}), porém, cada recurso provisionado sem necessidade transforma-se em custo recorrente. Armbrust et al.~\cite{armbrust2010} argumentam que a elasticidade da nuvem é economicamente vantajosa apenas quando os recursos são utilizados de forma eficiente; caso contrário, o custo por hora de instâncias ociosas ou subutilizadas supera rapidamente os ganhos obtidos com a escalabilidade. Schwartz et al.~\cite{schwartz2012} observam que a ineficiência na camada de software do banco de dados é uma das principais fontes desse desperdício: o SGBD consome mais CPU e memória do que precisaria se estivesse devidamente configurado, o que eleva o dimensionamento mínimo necessário para manter a aplicação estável. Quando o desempenho degrada, a reação típica é aumentar o plano da instância em nuvem, sem investigar se o problema está na configuração do banco. +A computação em nuvem tornou acessível a empresas de qualquer porte o mesmo tipo de infraestrutura antes restrita a grandes corporações. No modelo de precificação por consumo (\textit{pay-as-you-go}), porém, cada recurso provisionado sem necessidade transforma-se em custo recorrente. \citeonline{armbrust2010} argumentam que a elasticidade da nuvem é economicamente vantajosa apenas quando os recursos são utilizados de forma eficiente; caso contrário, o custo por hora de instâncias ociosas ou subutilizadas supera rapidamente os ganhos obtidos com a escalabilidade. \citeonline{schwartz2012} observam que a ineficiência na camada de software do banco de dados é uma das principais fontes desse desperdício: o SGBD consome mais CPU e memória do que precisaria se estivesse devidamente configurado, o que eleva o dimensionamento mínimo necessário para manter a aplicação estável. Quando o desempenho degrada, a reação típica é aumentar o plano da instância em nuvem, sem investigar se o problema está na configuração do banco. -Do ponto de vista tecnológico, a comodidade dos repositórios de pacotes das distribuições Linux consolidou um padrão de implantação baseado em binários genéricos, compilados para máxima compatibilidade em detrimento do desempenho. A literatura e a comunidade de banco de dados abordam com frequência o ajuste fino no nível lógico, como a criação de índices e a reescrita de consultas~\cite{elmasri2011}. Van Aken et al.~\cite{vanaken2021} confirmam que mesmo as ferramentas automáticas de configuração de SGBD se concentram quase exclusivamente em parâmetros internos do banco (como tamanho de cache e estratégia de flush), deixando de lado as camadas subjacentes. O impacto de descer até a camada do sistema de arquivos ou recompilar o SGBD para a arquitetura do servidor ainda é pouco explorado fora de ambientes de alta performance. Para empresas de pequeno porte, esse conhecimento costuma estar simplesmente ausente. +Do ponto de vista tecnológico, a comodidade dos repositórios de pacotes das distribuições Linux consolidou um padrão de implantação baseado em binários genéricos, compilados para máxima compatibilidade em detrimento do desempenho. A literatura e a comunidade de banco de dados abordam com frequência o ajuste fino no nível lógico, como a criação de índices e a reescrita de consultas~\cite{elmasri2011}. \citeonline{vanaken2021} confirmam que mesmo as ferramentas automáticas de configuração de SGBD se concentram quase exclusivamente em parâmetros internos do banco (como tamanho de cache e estratégia de flush), deixando de lado as camadas subjacentes. O impacto de descer até a camada do sistema de arquivos ou recompilar o SGBD para a arquitetura do servidor ainda é pouco explorado fora de ambientes de alta performance. Para empresas de pequeno porte, esse conhecimento costuma estar simplesmente ausente. -A relevância prática deste trabalho está em demonstrar, com dados, que um servidor de menor capacidade pode entregar desempenho igual ou superior ao de uma máquina mais robusta caso o software esteja adequadamente otimizado. Para organizações SaaS de pequeno porte, cujas margens são sensíveis a variações nos custos de infraestrutura, o \textit{downscaling} viabilizado pela otimização pode representar a diferença entre operar com folga ou operar no limite. +A relevância prática deste trabalho está em demonstrar, com dados, que um servidor de menor capacidade pode entregar desempenho igual ou superior ao de uma máquina mais robusta caso o software esteja adequadamente otimizado. Em ambientes transacionais de pequeno porte, cujos custos de infraestrutura são sensíveis ao uso ineficiente de recursos, o \textit{downscaling} viabilizado pela otimização pode representar ganho econômico sem perda de qualidade de serviço. \chapter{REFERENCIAL TEÓRICO} \label{cap:referencial_teorico} \section{ARQUITETURA DO SGBD E O MOTOR INNODB} -O MariaDB é um sistema gerenciador de banco de dados relacional (SGBDR) derivado do MySQL, criado como \textit{fork} comunitário em 2009 após a aquisição do MySQL pela Oracle. Como todo SGBDR que pretende ser utilizado em ambientes de produção, o MariaDB deve garantir as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) para assegurar a integridade das transações mesmo em caso de falhas \cite{silberschatz2019}. Taipalus~\cite{taipalus2023}, em revisão sistemática da literatura sobre desempenho de SGBDs, observa que as diferenças de performance entre sistemas como MySQL, MariaDB e PostgreSQL frequentemente se devem menos ao motor em si e mais à forma como cada um é configurado e implantado. +O MariaDB é um sistema gerenciador de banco de dados relacional (SGBDR) derivado do MySQL, criado como \textit{fork} comunitário em 2009 após a aquisição do MySQL pela Oracle. Como todo SGBDR que pretende ser utilizado em ambientes de produção, o MariaDB deve garantir as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) para assegurar a integridade das transações mesmo em caso de falhas \cite{silberschatz2019}. \citeonline{taipalus2023}, em revisão sistemática da literatura sobre desempenho de SGBDs, observa que as diferenças de performance entre sistemas como MySQL, MariaDB e PostgreSQL frequentemente se devem menos ao motor em si e mais à forma como cada um é configurado e implantado. -O motor de armazenamento padrão do MariaDB desde a versão 10.2 é o InnoDB. O InnoDB organiza os dados em tablespaces e mantém, em memória RAM, um cache chamado \textit{Buffer Pool}, onde armazena cópias de páginas de dados e índices acessados com frequência. Do et al.~\cite{do2008turbocharging} demonstraram que a eficiência do \textit{Buffer Pool} está diretamente ligada ao \textit{throughput} do sistema, sobretudo em cenários de alta concorrência. Quando o tamanho do cache é insuficiente para a carga de trabalho, o motor passa a buscar dados no disco com mais frequência, o que eleva a latência e reduz a vazão de processamento. Schwartz et al.~\cite{schwartz2012} vão além e afirmam que a correta configuração dos componentes de memória do InnoDB é o fator isolado com maior impacto no desempenho de cargas OLTP (\textit{Online Transaction Processing}). +O motor de armazenamento padrão do MariaDB desde a versão 10.2 é o InnoDB. O InnoDB organiza os dados em tablespaces e mantém, em memória RAM, um cache chamado \textit{Buffer Pool}, onde armazena cópias de páginas de dados e índices acessados com frequência. \citeonline{do2008turbocharging} demonstraram que a eficiência do \textit{Buffer Pool} está diretamente ligada ao \textit{throughput} do sistema, sobretudo em cenários de alta concorrência. Quando o tamanho do cache é insuficiente para a carga de trabalho, o motor passa a buscar dados no disco com mais frequência, o que eleva a latência e reduz a vazão de processamento. \citeonline{schwartz2012} vão além e afirmam que a correta configuração dos componentes de memória do InnoDB é o fator isolado com maior impacto no desempenho de cargas OLTP (\textit{Online Transaction Processing}). Além do \textit{Buffer Pool}, o InnoDB utiliza um \textit{Log Buffer} para acumular alterações antes de gravá-las nos arquivos de log em disco, e um \textit{Change Buffer} para cache de modificações pendentes em índices secundários. O funcionamento conjunto desses três mecanismos determina, na prática, o quanto o banco de dados consegue absorver requisições sem recorrer ao acesso direto ao armazenamento persistente. \section{OTIMIZAÇÃO LÓGICA E AJUSTE DE PARÂMETROS (\textit{TUNING})} -O ajuste de parâmetros do SGBD (geralmente chamado de \textit{tuning}) consiste em adaptar as configurações-padrão do sistema à carga de trabalho real e ao hardware disponível. Herodotou et al.~\cite{herodotou2020}, em survey sobre ajuste automático de parâmetros, destacam que a configuração manual de SGBDs é um problema reconhecidamente difícil: o espaço de busca é grande, os parâmetros interagem entre si de forma não trivial e o impacto de cada ajuste depende da carga de trabalho. Elmasri e Navathe~\cite{elmasri2011} observam que o desempenho de um banco de dados pode melhorar de forma considerável apenas com a escolha adequada de índices, o particionamento de tabelas e o ajuste de parâmetros de memória, sem necessidade de investir em hardware novo. +O ajuste de parâmetros do SGBD (geralmente chamado de \textit{tuning}) consiste em adaptar as configurações-padrão do sistema à carga de trabalho real e ao hardware disponível. \citeonline{herodotou2020}, em survey sobre ajuste automático de parâmetros, destacam que a configuração manual de SGBDs é um problema reconhecidamente difícil: o espaço de busca é grande, os parâmetros interagem entre si de forma não trivial e o impacto de cada ajuste depende da carga de trabalho. \citeonline{elmasri2011} observam que o desempenho de um banco de dados pode melhorar de forma considerável apenas com a escolha adequada de índices, o particionamento de tabelas e o ajuste de parâmetros de memória, sem necessidade de investir em hardware novo. No MariaDB, dois parâmetros merecem destaque. O primeiro é \texttt{innodb\_buffer\_pool\_size}, que define a porção de RAM dedicada ao cache de dados e índices. Em servidores dedicados ao banco de dados, a recomendação usual é reservar entre 50\% e 80\% da memória total para esse parâmetro~\cite{schwartz2012}. O segundo é \texttt{innodb\_flush\_log\_at\_trx\_commit}, que controla a frequência com que o log de transações é gravado em disco. O valor padrão (1) garante durabilidade completa a cada transação, mas implica uma chamada \texttt{fsync()} por \textit{commit}, o que se torna um gargalo em cargas com volume elevado de escritas. Ao alterar o valor para 2, o log é gravado no buffer do sistema operacional a cada transação e descarregado para o disco aproximadamente uma vez por segundo, reduzindo a latência ao custo de uma pequena janela de risco de perda de dados em caso de falha de energia. -A refatoração de consultas SQL complementa o ajuste de parâmetros. Consultas mal estruturadas ou que não aproveitam os índices disponíveis sobrecarregam a CPU e geram volume desnecessário de I/O. Segundo Schwartz et al.~\cite{schwartz2012}, a otimização no nível lógico das consultas costuma ser uma das intervenções com melhor custo-benefício, justamente porque não exige mudanças na infraestrutura. +A refatoração de consultas SQL complementa o ajuste de parâmetros. Consultas mal estruturadas ou que não aproveitam os índices disponíveis sobrecarregam a CPU e geram volume desnecessário de I/O. Segundo \citeonline{schwartz2012}, a otimização no nível lógico das consultas costuma ser uma das intervenções com melhor custo-benefício, justamente porque não exige mudanças na infraestrutura. \section{SISTEMAS DE ARQUIVOS E DESEMPENHO DE I/O} -Entre o SGBD e o dispositivo de armazenamento físico está o sistema de arquivos, encarregado de organizar, alocar e recuperar os dados gravados em disco. Embora essa camada seja frequentemente negligenciada em implantações de pequeno porte, a escolha do sistema de arquivos pode ter impacto mensurável na latência e na vazão do banco de dados, especialmente sob cargas com muita escrita sequencial ou aleatória. Aghayev et al.~\cite{aghayev2019}, ao analisar o comportamento do Ceph sobre diferentes sistemas de arquivos locais, constataram que as diferenças de desempenho entre EXT4 e XFS em cargas intensivas de I/O são significativas o bastante para comprometer a vazão de todo o sistema de armazenamento distribuído. +Entre o SGBD e o dispositivo de armazenamento físico está o sistema de arquivos, encarregado de organizar, alocar e recuperar os dados gravados em disco. Embora essa camada seja frequentemente negligenciada em implantações de pequeno porte, a escolha do sistema de arquivos pode ter impacto mensurável na latência e na vazão do banco de dados, especialmente sob cargas com muita escrita sequencial ou aleatória. \citeonline{aghayev2019}, ao analisar o comportamento do Ceph sobre diferentes sistemas de arquivos locais, constataram que as diferenças de desempenho entre EXT4 e XFS em cargas intensivas de I/O são significativas o bastante para comprometer a vazão de todo o sistema de armazenamento distribuído. -O EXT4 é o sistema de arquivos padrão na maioria das distribuições Linux. Suporta volumes de até 1~EiB e foi projetado com foco em robustez e compatibilidade retroativa com o EXT3~\cite{mathur2007}. Utiliza um mecanismo de \textit{journaling} em modo \textit{ordered} por padrão, que registra os metadados no jornal antes de gravar os dados efetivos. Apesar de estável e amplamente testado, o EXT4 utiliza uma estrutura centralizada de alocação de blocos que, conforme observam Mathur et al.~\cite{mathur2007}, pode gerar contenção em operações concorrentes de escrita. +O EXT4 é o sistema de arquivos padrão na maioria das distribuições Linux. Suporta volumes de até 1~EiB e foi projetado com foco em robustez e compatibilidade retroativa com o EXT3~\cite{mathur2007}. Utiliza um mecanismo de \textit{journaling} em modo \textit{ordered} por padrão, que registra os metadados no jornal antes de gravar os dados efetivos. Apesar de estável e amplamente testado, o EXT4 utiliza uma estrutura centralizada de alocação de blocos que, conforme observam \citeonline{mathur2007}, pode gerar contenção em operações concorrentes de escrita. -O XFS, originalmente desenvolvido pela Silicon Graphics na década de 1990 e hoje mantido pela comunidade do kernel Linux, foi concebido para operar com arquivos e volumes de grande porte. Seu esquema de alocação baseado em extensões (\textit{extents}) e sua capacidade de realizar I/O paralelo o tornam adequado para cargas de trabalho com acesso simultâneo de múltiplos processos~\cite{hellwig2009}. Segundo Hellwig, o XFS escala melhor que o EXT4 em servidores com muitos núcleos de CPU, pois distribui a gestão de metadados entre as unidades de alocação em vez de centralizá-la. +O XFS, originalmente desenvolvido pela Silicon Graphics na década de 1990 e hoje mantido pela comunidade do kernel Linux, foi concebido para operar com arquivos e volumes de grande porte. Seu esquema de alocação baseado em extensões (\textit{extents}) e sua capacidade de realizar I/O paralelo o tornam adequado para cargas de trabalho com acesso simultâneo de múltiplos processos~\cite{hellwig2009}. Segundo \citeonline{hellwig2009}, o XFS escala melhor que o EXT4 em servidores com muitos núcleos de CPU, pois distribui a gestão de metadados entre as unidades de alocação em vez de centralizá-la. -Já o ZFS, criado pela Sun Microsystems, adota uma arquitetura diferente: unifica o sistema de arquivos e o gerenciador de volumes numa camada única. Dentre seus recursos estão compressão transparente, checksums de dados e metadados, e \textit{snapshots} instantâneos~\cite{rodeh2008}. A arquitetura é descrita por Bonwick e Moore~\cite{bonwick2003} como \textit{copy-on-write}, o que garante consistência em caso de falha, porém adiciona um alto custo em operações de escrita. Há ainda uma questão prática relevante para bancos de dados: o ZFS mantém seu próprio cache em memória, o ARC (\textit{Adaptive Replacement Cache}), que pode competir com o \textit{Buffer Pool} do InnoDB caso os limites de cada um não sejam planejados em conjunto. +Já o ZFS, criado pela Sun Microsystems, adota uma arquitetura diferente: unifica o sistema de arquivos e o gerenciador de volumes numa camada única. Dentre seus recursos estão compressão transparente, checksums de dados e metadados, e \textit{snapshots} instantâneos~\cite{rodeh2008}. A arquitetura é descrita por \citeonline{bonwick2003} como \textit{copy-on-write}, o que garante consistência em caso de falha, porém adiciona um alto custo em operações de escrita. Há ainda uma questão prática relevante para bancos de dados: o ZFS mantém seu próprio cache em memória, o ARC (\textit{Adaptive Replacement Cache}), que pode competir com o \textit{Buffer Pool} do InnoDB caso os limites de cada um não sejam planejados em conjunto. \section{COMPILAÇÃO CUSTOMIZADA} -As distribuições Linux costumam distribuir o MariaDB em binários compilados com opções conservadoras, de modo a funcionar em qualquer processador x86-64. Isso significa que instruções específicas presentes em processadores recentes (como as extensões AVX2, AVX-512 e SSE) acabam não sendo utilizadas. Drepper~\cite{drepper2007} detalha como o custo dessa abstração não é desprezível: a forma como o compilador organiza o acesso à memória, o alinhamento dos dados e o aproveitamento dos caches da CPU afeta diretamente o desempenho do programa resultante. +As distribuições Linux costumam distribuir o MariaDB em binários compilados com opções conservadoras, de modo a funcionar em qualquer processador x86-64. Isso significa que instruções específicas presentes em processadores recentes (como as extensões AVX2, AVX-512 e SSE) acabam não sendo utilizadas. \citeonline{drepper2007} detalha como o custo dessa abstração não é desprezível: a forma como o compilador organiza o acesso à memória, o alinhamento dos dados e o aproveitamento dos caches da CPU afeta diretamente o desempenho do programa resultante. -Ao compilar o MariaDB a partir do código-fonte com a flag \texttt{-march=native} no GCC, o binário passa a ser gerado especificamente para a microarquitetura do processador hospedeiro. Isso permite ao compilador emitir instruções vetoriais e organizar o código de modo a explorar melhor a hierarquia de caches (L1, L2 e L3). Drepper~\cite{drepper2007} mostra que o uso correto da localidade de cache pode reduzir o tempo de execução de certas operações em até uma ordem de grandeza, sem exigir nenhum investimento em hardware adicional. +Ao compilar o MariaDB a partir do código-fonte com a flag \texttt{-march=native} no GCC, o binário passa a ser gerado especificamente para a microarquitetura do processador hospedeiro. Isso permite ao compilador emitir instruções vetoriais e organizar o código de modo a explorar melhor a hierarquia de caches (L1, L2 e L3). \citeonline{drepper2007} mostra que o uso correto da localidade de cache pode reduzir o tempo de execução de certas operações em até uma ordem de grandeza, sem exigir nenhum investimento em hardware adicional. \chapter{METODOLOGIA CIENTÍFICA} \label{cap:metodologia_cientifica} -Este trabalho caracteriza-se como uma pesquisa aplicada, pois busca resolver um problema concreto de desempenho e custo em uma aplicação SaaS de pequeno porte. Quanto aos objetivos, assume caráter exploratório e descritivo: exploratório por investigar a combinação de técnicas de otimização em diferentes camadas da infraestrutura, e descritivo por registrar, comparar e interpretar métricas de desempenho obtidas antes e depois das intervenções. Quanto à abordagem, a pesquisa é predominantemente quantitativa, uma vez que a avaliação será baseada em indicadores mensuráveis, como latência, vazão de processamento, uso de CPU, consumo de memória e volume de I/O em disco. +Do ponto de vista metodológico, este trabalho configura-se como estudo de caso único, de caráter exploratório e descritivo, com abordagem predominantemente quantitativa. O foco está na análise contextualizada de um ambiente real de produção que utiliza MariaDB, com coleta sistemática de indicadores de desempenho, consumo de recursos e custo, de modo a documentar e interpretar os efeitos observados em cada intervenção técnica. -O procedimento técnico adotado será um estudo de caso com delineamento experimental. O estudo de caso ocorrerá sobre o ambiente de banco de dados de uma empresa de pequeno porte do setor SaaS, cujo sistema utiliza MariaDB como SGBD relacional. O delineamento experimental será empregado para comparar cenários controlados de execução, nos quais uma ou mais camadas da infraestrutura serão alteradas e medidas em relação a um cenário inicial de referência (\textit{baseline}). +Não se trata de pesquisa experimental em sentido estrito, pois não haverá grupo de controle independente nem distribuição aleatória de tratamentos. O controle analítico será feito por comparação intracaso: o cenário inicial (\textit{baseline}) servirá de referência para os cenários subsequentes, permitindo rastrear o efeito de cada intervenção técnica sobre desempenho, estabilidade e custo operacional. \section{AMBIENTE DE ESTUDO} -O ambiente de estudo será composto por uma instância isolada da aplicação e do banco de dados, construída para reproduzir as principais características do ambiente de produção sem expor a operação real da empresa a riscos. A base de dados utilizada nos testes será uma cópia controlada da base real ou uma massa equivalente, preservando volume, cardinalidade das tabelas, distribuição de registros e padrões de relacionamento. Quando houver dados sensíveis, estes deverão ser anonimizados antes da execução dos experimentos. +O ambiente de estudo será composto por uma instância isolada da aplicação e do banco de dados, construída para reproduzir as principais características do ambiente de produção de origem sem expor dados ou detalhes operacionais sensíveis. A base de dados utilizada nos testes será uma cópia controlada da base real ou uma massa equivalente, preservando volume, cardinalidade das tabelas, distribuição de registros e padrões de relacionamento. Quando houver dados sensíveis, estes deverão ser anonimizados antes da execução dos experimentos. Para garantir comparabilidade entre os testes, serão registrados os principais elementos do ambiente: versão do MariaDB, versão do sistema operacional, kernel, quantidade de CPU, memória RAM, tipo de armazenamento, sistema de arquivos, parâmetros de montagem, configuração do SGBD e características da carga de trabalho. Alterações nesses elementos ocorrerão apenas quando fizerem parte do cenário avaliado. -\section{DELINEAMENTO DOS EXPERIMENTOS} +\section{ESTRATÉGIA DE COMPARAÇÃO E ISOLAMENTO DAS VARIÁVEIS} -Os experimentos serão organizados em etapas sucessivas. A primeira etapa consistirá na medição do cenário atual, utilizando a configuração existente da aplicação, do sistema operacional, do sistema de arquivos e dos binários do MariaDB. Essa medição formará o \textit{baseline} contra o qual os demais resultados serão comparados. +A pesquisa não adotará grupo de controle independente, pois o objetivo não é comparar organizações distintas ou amostras aleatorizadas, mas compreender, no mesmo ambiente estudado, o efeito de intervenções técnicas sucessivas sobre o desempenho do banco de dados. Por isso, o controle metodológico será realizado por comparação intracaso: o cenário inicial (\textit{baseline}) será a referência para todos os demais cenários analisados. -Na sequência, serão avaliados cenários de otimização lógica, ajuste de parâmetros do SGBD, comparação entre sistemas de arquivos e compilação customizada do MariaDB. Sempre que possível, os testes alterarão apenas uma camada por vez, de modo a reduzir interferências e permitir a identificação do impacto específico de cada intervenção. Ao final, será testado um cenário consolidado, reunindo as otimizações que apresentarem melhor relação entre desempenho, estabilidade e custo. +Para isolar as variáveis de interesse, cada cenário modificará apenas um fator técnico por vez. As variáveis independentes serão agrupadas em quatro eixos: consulta/indexação, parâmetros do SGBD, sistema de arquivos e tipo de binário do MariaDB. Como variáveis de controle, manter-se-ão constantes hardware, versão do sistema operacional e do kernel, versão do MariaDB, volume e estrutura da base, perfil de carga, duração das medições e instrumentos de coleta. Somente após a avaliação isolada de cada eixo será executado um cenário consolidado, reunindo as otimizações que apresentarem melhor resultado conjunto. -As etapas experimentais serão as seguintes: +\section{PROCEDIMENTOS DO ESTUDO DE CASO} -\begin{alineas} - \item medir o \textit{baseline} da infraestrutura atual, coletando métricas de desempenho e consumo de recursos sob carga representativa; +O estudo de caso será organizado em etapas sucessivas, com registro das condições de execução, das mudanças aplicadas e das métricas observadas em cada cenário. Cada etapa corresponderá diretamente a um objetivo específico da pesquisa, explicitando como ele será alcançado e como será avaliado. - \item identificar consultas SQL de maior custo por meio de logs, métricas do SGBD e comportamento observado na aplicação; +\subsection{Procedimentos por objetivo específico} - \item aplicar refatorações em consultas e ajustes de índices, medindo o impacto dessas mudanças sobre latência e \textit{throughput}; +\textbf{Diagnosticar o cenário atual (\textit{baseline}) da infraestrutura.} Inicialmente, será reproduzida uma carga de trabalho representativa da aplicação no ambiente isolado de estudo. Serão coletadas métricas de latência, \textit{throughput}, uso de CPU, memória RAM, \textit{swap}, IOPS, tempo de espera por I/O e indicadores internos do MariaDB. Esse objetivo será considerado atendido quando houver uma linha de base documentada, repetível e estável, obtida sob as mesmas condições de carga e infraestrutura. - \item ajustar parâmetros do MariaDB, com foco em memória, persistência de logs, concorrência e comportamento do InnoDB; +\textbf{Aplicar técnicas de otimização na camada de banco de dados.} Serão identificadas consultas SQL de maior custo por meio de logs de consultas lentas, planos de execução, métricas do SGBD e comportamento observado na aplicação. Em seguida, serão testadas refatorações de consultas, ajustes de índices e alterações de parâmetros do MariaDB em cenários separados, para evitar mistura de efeitos. A avaliação será feita pela comparação com o \textit{baseline}, observando redução de latência, ganho de \textit{throughput}, diminuição do consumo de recursos e ausência de regressões de estabilidade. - \item comparar o desempenho do banco de dados sobre diferentes sistemas de arquivos, especialmente EXT4, XFS e ZFS, mantendo constantes a carga de trabalho e os demais componentes do ambiente; +\textbf{Comparar o desempenho entre sistemas de arquivos.} O banco de dados será executado em ambientes equivalentes com EXT4, XFS e ZFS, alterando-se apenas o sistema de arquivos e seus parâmetros de montagem quando necessário. A mesma base, a mesma carga de trabalho, a mesma versão do MariaDB e o mesmo hardware serão mantidos. A avaliação considerará latência, \textit{throughput}, IOPS, tempo de espera por I/O, uso de CPU e comportamento do InnoDB em cada cenário. - \item compilar o MariaDB a partir do código-fonte com opções voltadas à arquitetura do servidor e comparar os resultados com os binários genéricos distribuídos pelos repositórios da distribuição Linux; +\textbf{Aferir a diferença entre binários genéricos e compilados especificamente para o servidor.} Será utilizada a mesma versão do código-fonte do MariaDB para gerar um binário compilado com opções voltadas à arquitetura do processador hospedeiro, comparando-o aos binários genéricos distribuídos pelos repositórios da distribuição Linux. Os testes serão executados sob a mesma carga e na mesma infraestrutura. A avaliação será feita por meio da variação percentual das métricas de desempenho e consumo de recursos em relação ao \textit{baseline} e ao cenário equivalente com binário genérico. - \item executar um teste de \textit{downscaling}, reduzindo os recursos da infraestrutura e verificando se a configuração otimizada mantém desempenho igual ou superior ao cenário inicial. -\end{alineas} +\textbf{Analisar a viabilidade técnica e financeira do \textit{downscaling}.} As otimizações que se mostrarem vantajosas nas etapas anteriores serão combinadas em um cenário consolidado. Sobre esse cenário, serão realizados testes de redução gradual de recursos computacionais, comparando seu desempenho com o \textit{baseline} original. Esse objetivo será considerado atendido se a configuração reduzida mantiver desempenho igual ou superior ao cenário inicial dentro dos critérios definidos para latência, \textit{throughput}, estabilidade e custo. -\section{CARGA DE TRABALHO E COLETA DE DADOS} +\section{CARGA DE TRABALHO, CONTROLE DAS VARIÁVEIS E COLETA DE DADOS} -A carga de trabalho utilizada nos testes deverá representar o uso real da aplicação. Para isso, serão consideradas as consultas mais frequentes, as consultas mais lentas, a proporção entre operações de leitura e escrita e o nível de concorrência observado no ambiente da empresa. O mesmo perfil de carga será aplicado em todos os cenários experimentais, permitindo a comparação direta dos resultados. +A carga de trabalho utilizada nos testes deverá representar o uso real da aplicação. Para isso, serão consideradas as consultas mais frequentes, as consultas mais lentas, a proporção entre operações de leitura e escrita e o nível de concorrência observado no ambiente de origem. O mesmo perfil de carga será aplicado em todos os cenários do estudo, permitindo comparação direta dos resultados. -Antes de cada medição, o ambiente será preparado para reduzir variações externas, incluindo reinicialização controlada dos serviços quando necessário, verificação da integridade da base e aplicação das mesmas condições iniciais de teste. Cada cenário deverá passar por um período de aquecimento, para estabilização de caches e conexões, seguido por um período de medição. As execuções serão repetidas para reduzir o efeito de flutuações ocasionais, e os resultados serão consolidados por meio de estatísticas como média, mediana e desvio-padrão. +Antes de cada medição, o ambiente será preparado para reduzir variações externas, incluindo reinicialização controlada dos serviços quando necessário, verificação da integridade da base e aplicação das mesmas condições iniciais de teste. Cada cenário deverá passar por um período de aquecimento, para estabilização de caches e conexões, seguido por um período de medição. Para reduzir o efeito de flutuações ocasionais, cada cenário será executado no mínimo três vezes sob as mesmas condições. Os resultados serão consolidados por estatísticas descritivas, com cálculo de média, mediana, desvio-padrão e percentis. +As variáveis independentes do estudo serão os fatores de intervenção técnica (consulta/indexação, parâmetros do SGBD, sistema de arquivos e tipo de binário). As variáveis dependentes serão as métricas de desempenho, consumo e custo. Como variáveis de controle, manter-se-ão constantes hardware, versão do kernel, versão do MariaDB, volume da base, perfil de carga, duração das medições e instrumentos de coleta. + As principais métricas coletadas serão: \begin{alineas} @@ -200,12 +199,37 @@ As principais métricas coletadas serão: \section{ANÁLISE DOS RESULTADOS} -A análise dos resultados será realizada por comparação percentual em relação ao \textit{baseline}. Para cada cenário, serão observadas as variações de latência, \textit{throughput}, consumo de recursos e custo estimado. Uma otimização será considerada tecnicamente vantajosa quando reduzir latência ou consumo de recursos sem comprometer a estabilidade do sistema e sem degradar a vazão de processamento. +A análise dos resultados será comparativa e descritiva, tomando o \textit{baseline} como referência central. Para cada cenário, serão calculadas as variações absolutas e percentuais das métricas coletadas, com observação conjunta de média, mediana, desvio-padrão e percentis de latência. A interpretação não se apoiará em um único indicador isolado: uma intervenção só será considerada benéfica se o comportamento favorável se repetir nas execuções do mesmo cenário e se não houver deterioração relevante em outras métricas críticas. -O critério central de avaliação será a viabilidade do \textit{downscaling}. Assim, além de identificar o cenário com maior desempenho absoluto, o estudo buscará determinar se a combinação das otimizações permite operar em uma infraestrutura menor mantendo níveis de desempenho equivalentes ou superiores ao ambiente inicial. Caso esse resultado seja alcançado, será calculada a economia potencial com base na diferença de custo entre a infraestrutura original e a infraestrutura otimizada. +Uma otimização será considerada tecnicamente vantajosa quando, em comparação com o \textit{baseline}, reduzir a latência mediana e o percentil 95 ou o consumo de recursos, sem queda relevante de \textit{throughput} e sem aumento perceptível de erros, \textit{timeouts} ou instabilidade operacional. O critério central de avaliação continuará sendo a viabilidade do \textit{downscaling}. Assim, além de identificar o cenário com maior desempenho absoluto, o estudo buscará determinar se a combinação das otimizações permite operar em uma infraestrutura menor mantendo desempenho equivalente ou superior ao ambiente inicial dentro desses critérios. Caso esse resultado seja alcançado, será calculada a economia potencial com base na diferença de custo entre a infraestrutura original e a infraestrutura otimizada. -Por fim, serão discutidas as limitações do estudo, especialmente aquelas relacionadas à especificidade da aplicação analisada, ao perfil da carga de trabalho, ao hardware disponível e ao fato de que resultados obtidos em um ambiente SaaS de pequeno porte podem não se repetir integralmente em sistemas com outras características. Ainda assim, o método proposto permitirá avaliar de forma objetiva o impacto prático das otimizações em múltiplas camadas e sua contribuição para a redução de custos operacionais. +Por fim, serão discutidas as limitações do estudo, especialmente aquelas relacionadas à especificidade da aplicação analisada, ao perfil da carga de trabalho, ao hardware disponível e ao fato de que resultados obtidos em um ambiente transacional de pequeno porte podem não se repetir integralmente em sistemas com outras características. Ainda assim, o método proposto permitirá avaliar de forma objetiva o impacto prático das otimizações em múltiplas camadas e sua contribuição para a redução de custos operacionais. +\section{ALINHAMENTO ENTRE OBJETIVOS ESPECÍFICOS E AVALIAÇÃO} + +Para assegurar que todos os objetivos específicos sejam contemplados metodologicamente, a Tabela~\ref{tab:objetivos-metodos} relaciona cada objetivo ao respectivo procedimento e critério de avaliação. + +\begin{table}[htb] + \caption{Relação entre objetivos específicos, procedimentos e avaliação} + \label{tab:objetivos-metodos} + \begin{tabular}{|p{0.30\textwidth}|p{0.34\textwidth}|p{0.28\textwidth}|} + \hline + \textbf{Objetivo específico} & \textbf{Como será atingido} & \textbf{Como será avaliado} \\ + \hline + Diagnosticar o \textit{baseline} da infraestrutura & Coleta inicial padronizada de métricas sob carga representativa & Linha de base validada por repetição e estabilidade das medições \\ + \hline + Aplicar otimização na camada de banco de dados & Identificação de consultas lentas, ajuste de índices e \textit{tuning} em cenários separados & Variação de latência, \textit{throughput}, uso de CPU/RAM e métricas internas do InnoDB \\ + \hline + Comparar sistemas de arquivos (EXT4, XFS, ZFS) & Execução da mesma carga em ambientes equivalentes, alterando apenas o sistema de arquivos & Diferença percentual em latência, IOPS, tempo de espera de I/O e vazão \\ + \hline + Comparar binários genéricos e compilados & Compilação customizada do MariaDB para a arquitetura do servidor e execução de testes equivalentes & Ganho/perda de desempenho e consumo de recursos por cenário \\ + \hline + Analisar viabilidade técnica e financeira do \textit{downscaling} & Consolidação das melhores otimizações e redução gradual de recursos computacionais & Manutenção dos critérios de desempenho com menor custo mensal estimado \\ + \hline + \end{tabular} + \fonte{Elaboração do autor (2026).} +\end{table} + \postextual \bibliography{ref} blob - /dev/null blob + 8de38747ba4d1451781a11228e7533ebcfcc2835 (mode 644) --- /dev/null +++ main. @@ -0,0 +1,376 @@ + + INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E +TECNOLOGIA DE SANTA CATARINA +CÂMPUS CAÇADOR + + + + +ANDRÉ MAZZOTTI BERTACHINI + + + + +OTIMIZAÇÃO MULTICAMADAS NO MARIADB + + + + + + + + + + + + + + + + + +CAÇADOR +2026 +André Mazzotti Bertachini + + + + + +OTIMIZAÇÃO MULTICAMADAS NO MARIADB + + + + + + +Monografia apresentada ao curso de Sistemas de Informação do Instituto Federal de Santa Catarina, para obtenção do título de bacharel em 2026. + + + +Orientador: Prof. Dr. Cristiano Mesquita Garcia +Co-orientador: Prof. Dr. Paulo Roberto Cordova + + + + + + + + + + + + + +Caçador +2026 +André Mazzotti Bertachini + + + +OTIMIZAÇÃO MULTICAMADAS NO MARIADB + + + +Monografia apresentada ao curso de Sistemas de Informação do Instituto Federal de Santa Catarina, para obtenção do título de bacharel em 2026. + + + + + + +Caçador, XX de XXXXXX de XXXX. + + + +__________________________________________ +Dr. [xxxxx] +Instituição de origem + + +__________________________________________ +M.e [xxxxx] +Instituição de origem + + +__________________________________________ +Dra. [xxxxx] +Instituição de origem + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Texto de dedicatória opcional. Se incluída, insira uma dedicatória de forma breve, prestando homenagem ou dedicando seu trabalho. + + +AGRADECIMENTOS + + +Insira aqui o texto com os agradecimentos dirigidos àqueles que contribuíram de maneira relevante à elaboração do trabalho. + + + + + +RESUMO + +Este trabalho investiga como técnicas de otimização aplicadas ao MariaDB, em múltiplas camadas da infraestrutura de dados, podem melhorar desempenho e reduzir custos operacionais em ambientes de produção. O estudo será conduzido como estudo de caso único, com coleta de métricas antes e depois das intervenções planejadas na camada de banco de dados (refatoração de consultas, ajuste de parâmetros), no sistema de arquivos e no processo de compilação do MariaDB. A análise será quantitativa, com comparação de latência, vazão de processamento, consumo de recursos e custo estimado de infraestrutura. A avaliação utilizará uma base anonimizada e uma carga de trabalho representativa derivada de um ambiente real de produção. Como resultado esperado, busca-se identificar combinações de otimização tecnicamente viáveis para sustentar a carga analisada com menor capacidade computacional, aumentando a eficiência e preservando a estabilidade e a qualidade do serviço. +Palavras-chave: MariaDB; Otimização; Desempenho; Infraestrutura. + + + +ABSTRACT + +This work investigates how optimization techniques applied to MariaDB, across multiple layers of the data infrastructure, can improve performance and reduce operational costs in production environments. The study will be conducted as a single case study, collecting metrics before and after planned interventions in the database layer (query refactoring, parameter adjustment), the file system, and the MariaDB compilation process. The analysis will be quantitative, comparing latency, processing throughput, resource consumption, and estimated infrastructure cost. The evaluation will use an anonymized database and a representative workload derived from a real production environment. The expected result is the identification of technically feasible optimization combinations to support the analyzed workload with lower computational capacity, increasing efficiency while preserving stability and service quality. + +Keywords: MariaDB; Optimization; Performance; Infrastructure. + + + +SUMÁRIO + +1 INTRODUÇÃO 15 +1.1 PROBLEMA DE PESQUISA 15 +2 DESENVOLVIMENTO DO TRABALHO 18 +2.1 MODELO PARA SEÇÃO SECUNDÁRIA (SE HOUVER) 20 +2.1.1 Modelo para seção terciária (se houver) 22 +2.1.1.1 Modelo para seção quaternária (se houver) 22 +2.1.1.1.1 Modelo para seção quinária (se houver) 23 +3 CONFIGURANDO AS SEÇÕES 24 +3.1 ALTERANDO ESTILOS NO GOOGLE DOCS 24 +3.2 ATUALIZANDO SUMÁRIO 25 +3.2.1 Conferindo formatação do sumário 25 +4 SEÇÃO PRIMÁRIA 27 +4.1 MODELO PARA SEÇÃO SECUNDÁRIA (SE HOUVER) 27 +4.1.1 Modelo para seção terciária (se houver) 27 +4.1.1.1 Modelo para seção quaternária (se houver) 27 +4.1.1.1.1 Modelo para seção quinária (se houver) 27 +5 CONSIDERAÇÕES FINAIS 28 +DECLARAÇÃO DE USO DE INTELIGÊNCIA ARTIFICIAL 29 +REFERÊNCIAS 30 +APÊNDICE A – MODELO DE APÊNDICE (OPCIONAL) 31 +ANEXO A – MODELO DE ANEXO (OPCIONAL) 32 + + + + + + +1 INTRODUÇÃO + +Bancos de dados relacionais sustentam grande parte das aplicações web modernas. Em ambientes de produção, a eficiência com que o sistema gerenciador de banco de dados (SGBD) utiliza CPU (Central Processing Unit), memória e disco influencia diretamente no desempenho da aplicação e no custo operacional associado. O MariaDB, fork comunitário do MySQL, é um dos SGBDs mais empregados nesse contexto: no ranking DB-Engines de junho de 2026, ocupa a 13ª posição geral e a 9ª entre os SGBDs relacionais (DB-ENGINES, 2026). A maioria das implantações, no entanto, utiliza binários pré-compilados distribuídos pelos repositórios das distribuições Linux, com configurações padrão que visam ampla compatibilidade e sacrificam desempenho. Van Aken et al. (2017) demonstram que a configuração de um SGBD é um problema de alta complexidade e que os valores padrão raramente são adequados para a carga de trabalho real, o que leva a um desperdício de processamento e memória que poderia ser evitado. +Este trabalho investiga o impacto de técnicas de otimização aplicadas ao MariaDB em múltiplas camadas de infraestrutura, abrangendo o ajuste de parâmetros do SGBD, a refatoração de consultas SQL (Structured Query Language), a comparação entre sistemas de arquivos e a compilação customizada do código fonte. A análise será realizada em ambiente controlado, com base em uma carga de trabalho derivada de um contexto real, buscando avaliar ganhos de desempenho, eficiência no consumo de recursos e viabilidade da redução de infraestrutura (downscaling) necessária. + + + +1.1 PROBLEMA DE PESQUISA +Sistemas gerenciadores de bancos de dados relacionais (SGBD) como o MariaDB costumam ser implantados com binários generalistas que pouco se ajustam ao hardware ou à carga de trabalho específica do ambiente. Aken et al. (2017) destacam que a busca manual por boas configurações de SGBD exige conhecimento especializado e tempo, o que leva a maioria das implantações a operar com valores conservadores. Como consequência, configurações inadequadas podem levar ao uso ineficiente de recursos como CPU, memória e I/O, além de limitar a vazão de processamento em cargas concorrentes. Zhao, Zhou e Li (2023) destacam que o ajuste de parâmetros dos SGBDs é um fator central para o desempenho, pois estes parâmetros influenciam diretamente o comportamento do sistema e a utilização dos recursos disponíveis. + Sob carga de trabalho de alta concorrência a performance do sistema se degrada prematuramente, a latência aumenta e o throughput cai. Silberschatz, Korth e Sudarshan (2019) explicam que esse comportamento está ligado a forma como o SGBD gerencia o tráfego entre memória e disco, quando os buffers são mal dimensionados, o acesso ao disco torna-se o gargalo. Em ambientes de produção, uma resposta comum para esse problema é o aumento da capacidade de hardware (escalabilidade vertical), prática conhecida como superprovisionamento. No entanto, conforme apontam Armbrust et al. (2010), o superprovisionamento é um modelo economicamente ineficiente, pois os recursos ociosos geram um aumento proporcional dos custos operacionais. Portanto, no contexto de otimização de SGBDs, adicionar mais hardware é uma correção que trata apenas os sintomas do problema subjacente, o novo hardware continuará operando sob as mesmas ineficiências. + Este problema manifesta-se com frequência em ambientes reais de produção, nos quais o crescimento do volume de dados, do número de usuários e do nível de concorrência expõe gargalos no acesso aos dados. Em muitas implantações, por praticidade de instalação e manutenção, o MariaDB é executado a partir de binários pré-compilados fornecidos pelos repositórios do sistema operacional. Embora essa abordagem garanta estabilidade e ampla compatibilidade, tais binários são compilados com opções genéricas de arquitetura para suportar uma vasta gama de processadores. Consequentemente, deixam de explorar otimizações específicas do hardware, como instruções vetoriais, alinhamento restrito de memória e uso eficiente da hierarquia de caches (Drepper, 2007; Cieslewicz; Roos, 2008). A ausência de ajuste nessas camadas pressiona a ampliação da infraestrutura antes que alternativas de otimização sejam devidamente avaliadas. + Diante deste quadro, formula-se a seguinte questão de pesquisa: “Quais são os impactos da otimização em múltiplas camadas de infraestrutura, englobando refatoração de consultas, parâmetros do SGBD, sistema de arquivos e compilação customizada de binários, no desempenho e nos custos operacionais de um ambiente transacional de pequeno porte?”. +1.2 OBJETIVOS +1.2.1 Objetivo Geral +Avaliar o impacto da aplicação de técnicas de otimização em múltiplas camadas de infraestrutura, englobando a refatoração de consultas, ajustes de parâmetros do SGBD, escolha do sistema de arquivos e compilação customizada do código-fonte, visando maximizar a vazão de processamento, minimizar a latência e viabilizar a redução de custos operacionais por meio do downscaling da infraestrutura. + +1.2.2 Objetivos Específicos +Para o alcance do objetivo geral proposto, definem-se os seguintes objetivos específicos: +Diagnosticar o cenário atual (baseline) da infraestrutura de banco de dados sob estudo, aferindo métricas de consumo de recursos, latência e throughput sob a carga de trabalho existente; +Aplicar técnicas de otimização na camada de banco de dados, compreendendo a refatoração de consultas lentas e o ajuste fino (tuning) de parâmetros do SGBD; +Comparar o desempenho do banco de dados operando sobre diferentes sistemas de arquivos, como EXT4, XFS, BTRFS, ZFS; +Aferir a diferença de desempenho e consumo de recursos entre a utilização de binários genéricos do SGBD e binários compilados especificamente para a arquitetura de hardware do servidor; +Analisar os resultados obtidos nos diferentes cenários de teste para determinar a viabilidade técnica e financeira de realizar o downscaling da infraestrutura sem comprometer os requisitos de desempenho do ambiente analisado. + +1.3 Justificativa +A computação em nuvem tornou acessível à empresas de qualquer porte o mesmo tipo de infraestrutura antes restrita a grandes corporações. No modelo de precificação por consumo (pay-as-you-go), porém, cada recurso provisionado sem necessidade transforma-se em recorrente custo operacional. Armbrust et al. (2010) argumentam que a elasticidade da nuvem é economicamente vantajosa apenas quando os recursos são utilizados de forma eficiente. Caso contrário, o custo por hora de instâncias ociosas ou subutilizadas supera rapidamente os ganhos obtidos com a escalabilidade. Schwartz et al. (2012) observam que a ineficiência na camada de software do banco de dados é uma das principais fontes desse desperdício: o SGBD consome mais CPU e memória do que precisaria se estivesse devidamente configurado, o que eleva o dimensionamento mínimo necessário para manter a aplicação estável. + Do ponto de vista tecnológico, a praticidade oferecida pelos repositórios de pacotes das distribuições Linux consolidou um padrão de implantação baseado em binários genéricos, compilados para maximizar a compatibilidade em detrimento do desempenho. Na literatura e na prática de administração de banco de dados, predominam discussões sobre otimização no nível lógico, como a criação de índices e reescrita de consultas (Elmasri; Navathe, 2011). Mesmo as ferramentas automáticas de configuração de SGBDs concentram-se, em geral, em parâmetros internos do banco, como tamanho de cache e estratégias de flush, deixando em segundo plano as camadas subjacentes (Van Aken et al., 2021). Nesse contexto, o impacto de intervenções no sistema de arquivos ou da recompilação do SGBD para a arquitetura específica do servidor permanece pouco explorada fora de ambientes de alta performance, e em organizações de pequeno porte, esse tipo de conhecimento técnico muitas vezes está ausente. + A relevância prática deste trabalho está em demonstrar, com dados, que um servidor de menor capacidade pode entregar desempenho igual ou superior ao de uma máquina mais robusta caso o software esteja adequadamente otimizado. Em ambientes transacionais de pequeno porte, cujos custos de infraestrutura são sensíveis ao uso ineficiente de recursos, o downscaling viabilizado pela otimização pode representar ganho econômico sem perdas na qualidade do serviço. +2 REFERENCIAL TEÓRICO + +2.1 Bancos de Dados Relacionais + Bancos de dados relacionais organizam os dados em relações, usualmente representadas por tabelas compostas por linhas e colunas. Cada linha representa uma ocorrência ou registro, enquanto as colunas representam os atributos armazenados. A associação entre tabelas é normalmente realizada por meio de chaves primárias e chaves estrangeiras, permitindo a representação de vínculos entre as entidades e preservando a integridade referencial dos dados (Elmasri; Navathe, 2011). + O acesso e a manipulação dos dados em bancos relacionais são realizados, em geral, por meio da linguagem SQL (Structured Query Language), utilizada para definição de estruturas, consulta, inserção, atualização e remoção de dados. Em ambientes transacionais, esses sistemas devem garantir propriedades como atomicidade, consistência, isolamento e durabilidade (ACID). Essas propriedades asseguram que as transações sejam executadas de forma confiável, preservando a integridade dos dados mesmo diante de falhas, concorrência ou interrupções no sistema (Silberschatz; Korth; Sudarshan, 2019). + O desempenho de um sistema gerenciador de banco de dados relacional não depende apenas da estrutura lógica dos dados, mas também da forma como o SGBD executa consultas, gerencia índices, controla transações, utiliza memória e realiza operações de entrada e saída em disco. Por isso, em aplicações transacionais, a configuração inadequada do banco de dados pode aumentar a latência, reduzir a vazão de processamento e elevar o consumo de recursos computacionais. + +2.2 Arquitetura do MariaDB + O MariaDB é um sistema gerenciador de banco de dados (SGBD) relacional derivado do MySQL, criado como fork comunitário do MySQL em 2009, após a aquisição do mesmo pela Oracle. Sua arquitetura é modular e permite o uso de diferentes motores de armazenamento, responsáveis por aspectos como organização dos dados, persistência, controle de concorrência e recuperação de falhas. Taipalus (2023), em revisão sistemática da literatura sobre desempenho de SGBDs, observa que as diferenças de desempenho entre sistemas como MySQL, MariaDB e PostgreSQL se devem menos à arquitetura do motor em si e mais à forma como cada um é configurado e implementado. + O motor de armazenamento padrão do MariaDB desde a versão 10.2 é o InnoDB. O InnoDB organiza os dados em tablespaces e mantém, em memória RAM, um cache chamado Buffer Pool, onde armazena cópias de páginas de dados e índices acessados com frequência. Do et al. (2008) demonstraram que a eficiência do Buffer Pool está diretamente ligada à capacidade de throughput do sistema, sobretudo em cenários de alta concorrência. Quando o tamanho do cache é insuficiente para a carga de trabalho, o motor passa a buscar dados no disco com mais frequência, o que eleva a latência e reduz a vazão de processamento. Schwartz et al. (2012) vão além e afirmam que a correta configuração dos componentes de memória do InnoDB é o fator isolado com maior impacto no desempenho de cargas de trabalho, especialmente as OLTP (Online Transaction Processing). + Além do Buffer Pool, o InnoDB utiliza um Log Buffer para acumular as alterações antes de gravá-las nos arquivos de log em disco, e um Change Buffer para cache de modificações pendentes. O funcionamento conjunto destes três mecanismos de caching determina, na prática, o quanto o banco de dados consegue absorver de requisições sem recorrer ao acesso direto ao armazenamento persistente. + +2.3 Otimização lógica e ajuste de parâmetros + O ajuste de parâmetros do SGBD (geralmente chamado de tuning) consiste em adaptar as configurações do sistema à carga de trabalho real e ao hardware disponível. Van Aken et al. (2017; 2021) destacam que a configuração manual de parâmetros é uma tarefa complexa pois envolve grande número de parâmetros, interações não triviais entre eles e efeitos que variam conforme a carga de trabalho. Mesmo assim, Elmasri e Navathe (2011) observam que o desempenho de um banco de dados pode melhorar de forma considerável apenas com a implementação adequada de índices, com o particionamento de tabelas e com o ajuste de parâmetros relacionados aos mecanismos de cache, sem necessidade de aumentar o poder computacional. + No MariaDB, dois parâmetros ilustram bem o impacto do ajuste fino no desempenho do InnoDB. O primeiro é o innodb_buffer_pool_size, que define a porção de memória RAM dedicada ao cache de dados e índices. Em servidores dedicados exclusivamente ao SGBD é comum configurar esse parâmetro com uma porcentagem elevada da memória RAM disponível, frequentemente entre 50% e 80%, a depender da carga de trabalho e das demais necessidades de memória do sistema (Schwartz et al., 2012). O segundo é o innodb_flush_log_at_trx_commit, que controla a frequência com a qual o redo log é gravado e sincronizado em disco. No valor padrão 1, cada commit envolve gravação e sincronização, o que garante durabilidade mas eleva o custo de I/O (Input/Output) em cargas de trabalho com muitas escritas. No valor 2, o log é gravado no cache do sistema operacional e sincronizado com o disco aproximadamente uma vez por segundo, o que pode reduzir o overhead de escrita ao custo de uma pequena janela de risco de perda de dados em caso de falha do sistema operacional ou queda de energia. +A refatoração de consultas SQL complementa o ajuste de parâmetros. Consultas mal estruturadas ou que não aproveitam os índices disponíveis sobrecarregam a CPU e geram um volume desnecessário de I/O. A otimização no nível lógico das consultas costuma ser uma das intervenções com o melhor custo benefício, justamente por não exigir mudanças na infraestrutura (Schwartz et al., 2012). + +2.4 Sistemas de arquivos e desempenho de I/O + Entre o SGDB e o dispositivo de armazenamento físico está o sistema de arquivos, encarregado de organizar, alocar e recuperar os dados gravados em disco. Embora essa camada seja frequentemente negligenciada, a escolha do sistema de arquivos pode ter impacto mensurável na latência e na vazão do banco de dados, especialmente sob cargas com muita escrita sequencial ou aleatória. Aghayev et al. (2019), ao analisar o comportamento de um sistema de armazenamento distribuído sobre diferentes sistemas de arquivos locais, constataram que as diferenças de desempenho entre EXT4 e XFS em cargas intensivas de I/O são significativas o bastante para comprometer a vazão de toda a infraestrutura. + O EXT4 é amplamente utilizado nas distribuições Linux, suporta volumes de até 1 EiB (exbibyte) e foi projetado com foco em robustez e compatibilidade retroativa com o EXT3. Utiliza um mecanismo de journaling por padrão, que registra os metadados antes de gravar os dados efetivamente e apesar de estável e amplamente testado, sua estrutura centralizada de alocação de blocos pode gerar contenção em operações concorrentes de escrita (Mathur et al., 2007). +O XFS, originalmente desenvolvido pela Silicon Graphics na década de 1990 e hoje mantido pela comunidade do kernel Linux, foi concebido para operar com arquivos e volumes de grande porte, utiliza um esquema de alocação baseado em extents, isto é, intervalos contíguos de blocos de armazenamentos tratados como uma única entidade, que reduz metadados e favorece operações sequenciais de leitura e escrita. Sua capacidade de realizar I/O paralelo o tornam adequado para cargas de trabalho com acesso simultâneo de múltiplos processos. Por conta disso, o XFS escala melhor que o EXT4 em servidores com muitos núcleos de CPU, comuns em ambientes de alta concorrência, pois distribui a gestão das tarefas entre as unidades de alocação em vez de centralizá-las (Hellwig, 2009). +O ZFS, criado pela Sun Microsystems, adota uma arquitetura diferente: unifica o sistema de arquivos e o gerenciador de volumes numa camada única. Dentre os seus recursos estão compressão transparente, checksums de dados e metadados e snapshots instantâneos. A arquitetura é baseada em copy-on-write, o que garante consistência em caso de falha, adicionando porém um elevado custo para operações de escrita (Bonwick; Moore, 2003). Há ainda uma questão relevante para um SGBD: o ZFS mantém seu próprio cache em memória, o ARC (Adaptive Replacement Cache), que pode competir com o Buffer Pool do InnoDB caso os limites de cada um não sejam planejados em conjunto. + O BTRFS, desenvolvido originalmente pela Oracle e integrado ao kernel Linux, é um sistema de arquivos moderno baseado em árvores B, com suporte nativo a snapshots, checksums, compressão transparente e gerenciamento integrado de volumes. Assim como o ZFS, utiliza uma estratégia de copy-on-write, na qual alterações não sobrescrevem diretamente os blocos existentes, mas são gravadas em novos locais antes da atualização dos metadados. Embora esse modelo favoreça consistência e recuperação, pode acabar introduzindo problemas em cargas de escrita intensiva, como as de banco de dados transacionais (Rodeh; Bacik; Mason, 2013). + +2.5 Compilação customizada +As distribuições Linux costumam disponibilizar o MariaDB em binários compilados com opções conservadoras, de modo que possam funcionar em diferentes processadores dentro de uma mesma arquitetura. Essa estratégia favorece compatibilidade e facilidade de distribuição, mas limita o uso de recursos específicos presentes em processadores mais recentes, como extensões SSE, AVX2 e AVX-512. O custo dessa generalização não é desprezível, a forma como o compilador organiza instruções, acessos à memória, alinhamento de dados e uso dos caches da CPU pode influenciar diretamente o desempenho do programa resultante (Drepper, 2007). + Ao compilar o MariaDB a partir do código-fonte, torna-se possível gerar binários específicos para a microarquitetura do processador utilizado no servidor. Essa customização pode permitir o uso de instruções específicas da CPU, melhor organização dos blocos de código e aproveitamento mais eficiente da hierarquia de caches L1, L2 e L3. Em sistemas de banco de dados, esse aspecto é relevante porque parte significativa do desempenho depende não apenas das consultas SQL ou dos parâmetros do SGBD, mas também da eficiência com que o binário executa as operações internas repetitivas, como gerenciamento de transações, leitura de páginas, controle de concorrência e processamento de índices. +Na prática, essa customização ocorre por meio de opções do compilador utilizadas durante o processo de compilação. No GCC (Gnu Compiler Collection) e Clang, opções como -O2 e -O3 controlam o nível geral de otimização aplicado ao binário. A opção -O2 é mais conservadora e costuma priorizar um equilíbrio entre desempenho, tamanho do binário e estabilidade das otimizações, enquanto o -O3 é mais agressivo, inclui todas as otimizações do -O2 e ativa flags relacionadas a expansão de funções e otimizações adicionais em laços de repetição (Free Software Foundation, 2026). De forma semelhante, a documentação do Clang descreve o -O3 como um nível que, além do -O2 pode habilitar otimizações mais custosas ou gerar binários maiores na tentativa de aumentar o desempenho (LLVM Project, 2026) +Entretanto, níveis mais agressivos nem sempre resultam em melhor desempenho, pois determinadas otimizações do compilador podem aumentar o tamanho do binário, pressionando o cache de instruções. Além disso, existem flags específicas para auxiliar o compilador quanto a arquitetura alvo da compilação, -march pode ser utilizado para habilitar instruções específicas do processador, limitando a portabilidade, e -mtune que permite ajustar a geração de código para determinada arquitetura sem comprometer necessariamente a portabilidade. Assim, a escolha das flags de compilação deve ser tratada como uma variável experimental, a ser validada com a carga de trabalho real do sistema. + + + + + +Outra técnica relacionada a este tipo de otimização é a Profile Guided Optimization (PGO). Nessa abordagem, o programa é inicialmente compilado com instrumentação, executado com uma carga de trabalho representativa e, em seguida, recompilado utilizando informações coletadas durante a execução. Com isso, o compilador passa a conhecer quais trechos de código são mais utilizados e pode reorganizar o binário para favorecer os caminhos de execução mais frequentes. Nielsen (2014), ao investigar o desempenho single-threaded do MariaDB, observou que falhas no cache de instruções eram um gargalo relevante e relatou ganho de 44% em um teste read-only com sysbench ao recompilar o binário com PGO. +Gráfico 1 - Comparação de queries por segundo (QPS) com e sem PGO no MariaDB + +Fonte: Elaborado pelo autor com base em Nielsen (2014) + +Resultados semelhantes também foram apresentados em um benchmark da MariaDB Corporation com MariaDB Enterprise Cluster. Schwenke e Johansson (2015) compararam binários padrão com binários compilados com PGO em cenários de OLTP usando sysbench, observando ganhos consistentes de desempenho sem regressões nos casos testados. Nos três cenários avaliados, ambos os nós em leitura, um nó em leitura e outro em leitura/escrita, e ambos os nós em leitura/escrita os ganhos ficaram em torno de 13% a 15% na conclusão do estudo. Esses resultados indicam que a compilação customizada pode ser uma camada relevante de otimização, especialmente quando combinada com uma carga de trabalho conhecida e repetível. +Gráfico 2 - Ganho médio de desempenho com PGO em cenários OLTP no MariaDB Enterprise Cluster + +Fonte: Elaborado pelo autor com base em Schwenke e Johansson (2015) + + +Entretanto esse tipo de otimização também apresenta limitações. Binários compilados para uma microarquitetura específica podem perder portabilidade, não sendo adequados para execução em servidores com processadores diferentes. No caso do PGO, os resultados dependem diretamente da qualidade da carga utilizada durante a etapa de profiling. Se essa carga não representar o uso real do sistema, o binário otimizado pode favorecer apenas caminhos de execução específicos e não reproduzir os mesmos ganhos em produção. Por outro lado, essa limitação pode ser mitigada quando o profiling acontece com uma carga de trabalho derivada da própria aplicação, utilizando consultas reais, proporções semelhantes entre leitura e escrita, transações þípicas e níveis de concorrência próximos aos observados no ambiente de produção. Nesse cenário, o compilador passa a otimizar o MariaDB com base nos caminhos internos frequentemente percorridos pela carga real, aumentando a aderência entre o processo de otimização e o comportamento efetivo do sistema. +3 METODOLOGIA CIENTÍFICA + +Do ponto de vista metodológico, este trabalho configura-se como um estudo de caso único, de caráter exploratório e descritivo, com abordagem predominantemente quantitativa. O foco está na análise contextualizada de um ambiente real de produção que utiliza MariaDB, com coleta sistemática de indicadores de desempenho, consumo de recursos e custo, de modo a documentar e interpretar os efeitos observados em cada intervenção técnica. + +3.1 Ambiente de Estudo + O ambiente de estudo será composto por uma instância isolada da aplicação e do banco de dados, construída para reproduzir as principais características do ambiente de produção de origem sem expor dados ou detalhes operacionais sensíveis. A base de dados utilizada nos testes será uma cópia controlada da base real, preservando volume, cardinalidade das tabelas, distribuição de registros e padrões de relacionamento. Quando houver dados sensíveis, estes deverão ser anonimizados antes da execução dos experimentos. + Para garantir comparabilidade entre os testes, serão registrados os principais elementos do ambiente: versão do MariaDB, versão do sistema operacional, kernel, quantidade de CPU, memória RAM, tipo de armazenamento, sistema de arquivos, configuração do SGBD e características da carga de trabalho. Alterações nesses elementos ocorrerão apenas quando fizerem parte do cenário avaliado. + +3.2 Estratégia de comparação e isolamento das variáveis + A pesquisa adotará uma estratégia de comparação entre cenários experimentais , tomando como referência um cenário de controle. Esse cenário de controle corresponderá ao ambiente base, isto é, à aplicação e ao banco de dados em sua configuração original, sem as intervenções de otimização propostas. Esse baseline será utilizado como referência para avaliar os efeitos das alterações aplicadas nos demais cenários + Para isolar as variáveis de interesse, cada cenário modificará apenas um fator técnico por vez. As variáveis independentes serão agrupadas em quatro eixos: consulta/indexação, parâmetros do SGBD, sistema de arquivos e tipo de binário do MariaDB. Como variáveis de controle, manter-se-ão constantes hardware, versão do sistema operacional e do kernel, versão do MariaDB, volume e estrutura da base, perfil de carga, duração das medições e instrumentos de coleta. Somente após a avaliação isolada de cada eixo será executado um cenário consolidado, reunindo as otimizações que apresentarem melhor resultado conjunto. + +3.3 Procedimentos do estudo de caso + O estudo de caso será organizado em etapas sucessivas, com registro das condições de execução, das mudanças aplicadas e das métricas observadas em cada cenário. Cada etapa corresponderá diretamente a um objetivo específico da pesquisa, explicitando como ele será alcançado e como será avaliado. + +3.3.1 Procedimentos por objetivo específico. + Diagnosticar o cenário atual (baseline) da infraestrutura. Inicialmente, será reproduzida uma carga de trabalho representativa da aplicação no ambiente isolado de estudo. Serão coletadas métricas de latência, throughput, uso de CPU, memória RAM, IOPS, tempo de espera por I/O e indicadores internos do MariaDB. Esse objetivo será considerado atendido quando houver uma linha de base documentada, repetível e estável, obtida sob as mesmas condições de carga e infraestrutura. + Aplicar técnicas de otimização na camada de banco de dados. Serão identificadas consultas SQL de maior custo por meio de logs de consultas lentas, planos de execução, métricas do SGBD e comportamento observado na aplicação. Em seguida, serão testadas refatorações de consultas, ajustes de índices e alterações de parâmetros do MariaDB em cenários separados, para evitar mistura de efeitos. A avaliação será feita pela comparação com o baseline, observando redução de latência, ganho de throughput, diminuição do consumo de recursos e ausência de regressões de estabilidade. + Comparar o desempenho entre sistemas de arquivos. O banco de dados será executado em ambientes equivalentes com EXT4, XFS e ZFS, alterando-se apenas o sistema de arquivos e seus parâmetros de montagem quando necessário. A mesma base, a mesma carga de trabalho, a mesma versão do MariaDB e o mesmo hardware serão mantidos. A avaliação considerará latência, throughput, IOPS, tempo de espera por I/O, uso de CPU e comportamento do InnoDB em cada cenário. + Aferir a diferença entre binários genéricos e compilados especificamente +para o servidor. Será utilizada a mesma versão do código-fonte do MariaDB para gerar um binário compilado com opções voltadas à arquitetura do processador target, comparando-o aos binários genéricos distribuídos pelos repositórios da distribuição Linux. Os testes serão executados sob a mesma carga e na mesma infraestrutura. A avaliação será feita por meio da variação percentual das métricas de desempenho e consumo de recursos em relação ao baseline e ao cenário equivalente com binário genérico. + Analisar a viabilidade técnica e financeira do downscaling. As otimizações +que se mostraram vantajosas nas etapas anteriores serão combinadas em um cenário consolidado. Sobre esse cenário, serão realizados testes de redução gradual de recursos computacionais, comparando seu desempenho com o baseline original. Esse objetivo será considerado atendido se a configuração reduzida mantiver desempenho igual ou superior ao cenário inicial dentro dos critérios definidos para latência, throughput, estabilidade e custo. + +3.4 Carga de trabalho, controle das variáveis e coleta dos dados + A carga de trabalho utilizada nos testes deverá representar o uso real da aplicação. Para isso, serão consideradas as consultas mais frequentes, as consultas mais lentas, a proporção entre operações de leitura e escrita e o nível de concorrência observado no ambiente. O mesmo perfil de carga será aplicado em todos os cenários do estudo, permitindo comparação direta dos resultados. +Antes de cada medição, o ambiente será preparado para reduzir variações externas, incluindo reinicialização controlada dos serviços quando necessário, verificação da integridade da base e aplicação das mesmas condições iniciais de teste. Cada cenário deverá passar por um período de aquecimento, para estabilização de caches e conexões, seguido por um período de medição. Para reduzir o efeito de flutuações ocasionais, cada cenário será executado no mínimo três vezes sob as mesmas condições. Os resultados serão consolidados por estatísticas descritivas, com cálculo de média, mediana, desvio-padrão e percentuais. +As variáveis independentes do estudo corresponderão aos eixos de intervenção técnica analisados em cada cenário: refatoração de consultas e indexação, ajuste de parâmetros do SGBD, sistema de arquivos e tipo de binário utilizado no MariaDB. As variáveis dependentes serão as medidas observadas de desempenho, consumo de recursos e custo operacional. Como variáveis de controle, permanecerão constantes o hardware empregado, a versão do kernel, a versão do MariaDB, o volume e a estrutura da base de dados, o perfil de carga, a duração das medições e os instrumentos de coleta. As principais métricas coletadas serão: + +latência média, mediana e percentis de resposta das operações avaliadas; +throughput, expresso em requisições ou transações processadas por unidade de tempo; +utilização de CPU, memória RAM e swap; +volume de leitura e escrita em disco, IOPS e tempo de espera por I/O; +indicadores internos do MariaDB, como uso do Buffer Pool, número de consultas lentas, ocorrência de bloqueios e taxa de acerto de cache; +custo estimado da infraestrutura necessária para sustentar cada cenário avaliado. + +3.5 Análise dos resultados + A análise dos resultados será comparativa e descritiva, tomando o baseline como referência central. Para cada cenário, serão calculadas as variações absolutas e percentuais das métricas coletadas, com observação conjunta de média, mediana, desvio-padrão e percentis de latência. A interpretação não se apoiará em um único indicador isolado: uma intervenção só será considerada benéfica se o comportamento favorável se repetir nas execuções do mesmo cenário e se não houver deterioração relevante em outras métricas. +Uma otimização será considerada técnicamente vantajosa quando, em comparação com o baseline, reduzir a latência mediana e o percentual 95 ou o consumo de recursos, sem queda relevante de throughput e sem aumento perceptível de erros, timeouts ou instabilidade operacional. O critério central de avaliação continuará sendo a viabilidade do downscaling. Assim, além de identificar o cenário com maior desempenho absoluto, o estudo buscará determinar se a combinação das otimizações permite operar em uma infraestrutura menor mantendo desempenho equivalente ou superior ao ambiente inicial dentro desses critérios. +Caso esse resultado seja alcançado, será calculada a economia potencial com base na diferença de custo entre a infraestrutura original e a infraestrutura otimizada. +Por fim, serão discutidas as limitações do estudo, especialmente aquelas relacionadas à especificidade da aplicação analisada, ao perfil da carga de trabalho, ao hardware disponível e ao fato de que resultados obtidos em um ambiente transacional de pequeno porte podem não se repetir integralmente em sistemas com outras características. Ainda assim, o método proposto permitirá avaliar de forma objetiva o impacto prático das otimizações em múltiplas camadas e sua contribuição para a redução de custos operacionais. + + + + + + + + + + + + + + + + + + + + + + + + + +DECLARAÇÃO DE USO DE INTELIGÊNCIA ARTIFICIAL + + +REFERÊNCIAS + +AGHAYEV, A. et al. File systems unfit as distributed storage backends: lessons learned from building the Ceph storage backend on top of local file systems. In: PROCEEDINGS OF THE 27TH ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES. [S.l.]: ACM, 2019. p. 75-89. + +ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, v. 53, n. 4, p. 50-58, 2010. + +BONWICK, J.; MOORE, B. ZFS: the last word in file systems. Sun Microsystems, 2003. + +DO, J. et al. Turbocharging DBMS buffer pool using SSDs. Proceedings of the 2008 ACM SIGMOD, 2008. + +DREPPER, U. What every programmer should know about memory. Red Hat, Inc., 2007. + +ELMASRI, R.; NAVATHE, S. B. Fundamentals of Database Systems. [S.l.]: Pearson Education, 2011. + +HELLWIG, C. XFS: the world's most scalable file system. Linux Symposium, 2009. + +MATHUR, A. et al. The new ext4 filesystem: current status and future plans. In: PROCEEDINGS OF THE LINUX SYMPOSIUM. [S.l.: s.n.], 2007. v. 2, p. 77-88. + +SCHWARTZ, B. et al. High Performance MySQL: optimization, backups, and replication. 3. ed. [S.l.]: O'Reilly Media, 2012. + +SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Database System Concepts. [S.l.]: McGraw-Hill Education, 2019. + +TAIPALUS, T. Database management system performance comparisons: a systematic literature review. Journal of Systems and Software, v. 208, p. 111872, 2023. + +VAN AKEN, D. et al. Automatic database management system tuning through large-scale machine learning. In: PROCEEDINGS OF THE 2017 ACM INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA. [S.l.]: ACM, 2017. p. 1009-1024. + +VAN AKEN, D. et al. An inquiry into machine learning-based automatic configuration tuning services on real-world database management systems. Proceedings of the VLDB Endowment, v. 14, n. 9, p. 1440-1453, 2021. + +DB-ENGINES. DB-Engines Ranking. 2026. Disponível em: https://db-engines.com/en/ranking. Acesso em: 11 jun. 2026. +ZHAO, X.; ZHOU, X.; LI, G. Automatic Database Knob Tuning: A Survey. IEEE Transactions on Knowledge and Data Engineering, v. 35, n. 12, p. 12470-12490, 2023. DOI: 10.1109/TKDE.2023.3266893 + +CIESLEWICZ, J.; ROSS, K. A. Database optimizations for modern hardware. Proceedings of the IEEE, v. 96, n. 5, p. 863-878, 2008. DOI: 10.1109/JPROC.2008.917744. + +RODEH, O.; BACIK, J.; MASON, C. BTRFS: The Linux B-tree filesystem. ACM Transactions on Storage, v. 9, n. 3, p. 1-32, 2013. + +NIELSEN, Kristian. 40% better single-threaded performance in MariaDB. LiveJournal, 20 jan. 2014. Disponível em: https://kristiannielsen.livejournal.com/17676.html. Acesso em: 14 jun. 2026. + +SCHWENKE, Axel; JOHANSSON, Rasmus. MariaDB Enterprise Cluster Profile-Guided Optimization (PGO) Benchmark. MariaDB Corporation, 2015. Disponível em: https://mariadb.com/files/MariaDBEnteprise-Profile-GuidedOptimization-20150401_0.pdf. Acesso em: 14 jun. 2026. + +Free Software Foundation. Optimize options. In: Using the GNU Compiler Collection (GCC). 2026a. Disponível em: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html. Acesso em: 15 jun. 2026. + +LLVM Project. clang - the Clang C, C++, and Objective-C compiler. Clang documentation, 2026. Disponível em: https://clang.llvm.org/docs/CommandGuide/clang.html. Acesso em: 15 jun. 2026. + + + + + blob - /dev/null blob + 8c054d8d674ed53f91f8ace0bb79debb3ce93597 (mode 644) --- /dev/null +++ main.bak0 @@ -0,0 +1,239 @@ +\documentclass[ + 12pt, % Entire doc font size + oneside, % Capítulos começam em página ímpar + a4paper, % Tamanho do papel + english, % Idioma adicional para hifenização + brazil % O último idioma é o principal do documento +]{abntex2} + +% --- Pacotes Básicos --- +\usepackage{helvet} +\usepackage[T1]{fontenc} +\usepackage[utf8]{inputenc} +\usepackage{indentfirst} +\usepackage{color} +\usepackage{graphicx} +\usepackage{microtype} + +\usepackage[alf]{abntex2cite} + +\titulo{OTIMIZAÇÃO MULTICAMADAS NO MARIADB} +\autor{ANDRÉ MAZZOTTI BERTACHINI} +\local{CAÇADOR} +\data{2026} +\orientador{Prof. Dr. Cristiano Mesquita Garcia} +\coorientador{Prof. Dr. Paulo Roberto Cordova} +\instituicao{INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DE SANTA CATARINA \par CÂMPUS CAÇADOR} +\tipotrabalho{Monografia} + +\definecolor{blue}{RGB}{41,5,195} +\hypersetup{ + pdftitle={\@title}, + pdfauthor={\@author}, + pdfsubject={\imprimirpreambulo}, + pdfcreator={LaTeX with abnTeX2}, + pdfkeywords={MariaDB}{Infraestrutura}{Downscaling}{abntex2}, + colorlinks=true, + linkcolor=blue, + citecolor=blue, + urlcolor=blue +} + +\begin{document} +\selectlanguage{brazil} +\frenchspacing + +\imprimircapa +\imprimirfolhaderosto + +\begin{resumo} +Este trabalho investiga, em uma aplicação SaaS de pequeno porte, como otimizações em múltiplas camadas da infraestrutura de dados podem melhorar desempenho e reduzir custos operacionais. O estudo será conduzido por meio de estudo de caso único, com coleta de métricas antes e depois de intervenções planejadas na camada de banco de dados (refatoração de consultas e ajuste de parâmetros), no sistema de arquivos e no processo de compilação do MariaDB. A análise será quantitativa, com comparação de latência, vazão de processamento, consumo de recursos e custo estimado de infraestrutura em cenários comparáveis. Como resultado esperado, busca-se identificar combinações de otimização tecnicamente viáveis para sustentar a carga da aplicação com menor capacidade computacional, preservando estabilidade e qualidade de serviço. + + \textbf{Palavras-chave}: MariaDB; otimização; desempenho; custos operacionais; estudo de caso. +\end{resumo} + +\pdfbookmark[0]{\contentsname}{toc} +\tableofcontents* +\cleardoublepage + +\textual +\pagestyle{simple} + +\chapter{INTRODUÇÃO} +Bancos de dados relacionais estão no núcleo de praticamente toda aplicação web. No setor de \textit{Software as a Service} (SaaS), onde a infraestrutura é faturada por consumo, a eficiência com que o sistema gerenciador de banco de dados (SGBD) utiliza CPU, memória e disco reflete-se nos custos operacionais da empresa. O MariaDB, \textit{fork} comunitário do MySQL mantido pela MariaDB Corporation e pela comunidade, é um dos SGBDs mais empregados nesse cenário. A maioria das implantações, no entanto, utiliza binários pré-compilados distribuídos pelos repositórios das distribuições Linux, com configurações-padrão pensadas para compatibilidade ampla em vez de desempenho. Van Aken et al.~\cite{vanaken2017} demonstram que a configuração de um SGBD é um problema de alta complexidade e que os valores-padrão raramente são adequados para a carga de trabalho real, o que leva a um desperdício de processamento e memória que poderia ser evitado. + +Este trabalho investiga o impacto da otimização em múltiplas camadas de infraestrutura sobre o desempenho de uma aplicação SaaS de pequeno porte, abrangendo o ajuste de parâmetros do SGBD, a refatoração de consultas SQL, a comparação entre sistemas de arquivos e a compilação customizada do código-fonte do MariaDB. A premissa é que a aplicação combinada dessas técnicas permite reduzir a infraestrutura contratada (\textit{downscaling}) sem perda de desempenho. + +\section{PROBLEMA DE PESQUISA} +Sistemas gerenciadores de bancos de dados relacionais como o MariaDB costumam ser implantados com binários generalistas e configurações que pouco se ajustam ao hardware ou à carga de trabalho específica do ambiente. Van Aken et al.~\cite{vanaken2017} destacam que a busca manual por boas configurações de SGBD exige conhecimento especializado e tempo, o que leva a maioria das implantações a operar com valores-padrão conservadores. Como consequência, observa-se uma subutilização crônica de CPU e memória e uma saturação prematura da vazão de processamento (\textit{throughput}). + +Sob cargas de trabalho com alta concorrência, o sistema degrada: a latência aumenta e o \textit{throughput} cai. Silberschatz et al.~\cite{silberschatz2019} explicam que esse comportamento está ligado à forma como o SGBD gerencia o tráfego entre memória e disco; quando os buffers são mal dimensionados, o acesso ao disco se torna o gargalo. A resposta mais comum no mercado é o superprovisionamento, ou seja, a alocação de mais recursos de hardware (escalabilidade vertical). Trata-se de uma correção pontual: o novo hardware é consumido pela mesma ineficiência de antes, e os custos operacionais crescem de forma proporcional. + +Esse cenário manifesta-se na prática numa empresa de pequeno porte do setor SaaS acompanhada neste estudo. A organização mantém um sistema em produção que, com o crescimento da base de usuários, passou a apresentar gargalos de desempenho no acesso aos dados. A infraestrutura atual opera com sistema operacional de uso geral, sistema de arquivos na configuração padrão e binários pré-compilados do MariaDB obtidos via gerenciador de pacotes. A ausência de ajuste em qualquer uma dessas camadas contribui para picos de latência nos horários de pico e pressionou a empresa a considerar \textit{upgrades} de hardware em nuvem para sustentar a operação. + +Diante desse quadro, formula-se a seguinte questão de pesquisa: quais são os impactos da otimização em múltiplas camadas de infraestrutura, englobando sistema operacional, sistema de arquivos, compilação customizada de binários e parâmetros do SGBD, no desempenho e nos custos operacionais de uma aplicação SaaS de pequeno porte? +\section{OBJETIVOS} +\subsection{Objetivo Geral} +Avaliar o impacto da aplicação de técnicas de otimização em múltiplas camadas de +infraestrutura, englobando a refatoração de consultas, ajustes de parâmetros do +SGBD, escolha do sistema de arquivos, escolha do sistema operacional e +compilação customizada do código-fonte, visando maximizar a vazão de +processamento, minimizar a latência e viabilizar a redução de custos operacionais +(\textit{downscaling}) de uma aplicação SaaS de pequeno porte. +\subsection{Objetivos Específicos} + +Para o alcance do objetivo geral proposto, definem-se os seguintes objetivos específicos: + +\begin{alineas} + \item diagnosticar o cenário atual (\textit{baseline}) da infraestrutura de banco de dados da empresa, aferindo métricas de consumo de recursos, latência e \textit{throughput} sob a carga de trabalho existente; + + \item aplicar técnicas de otimização na camada de banco de dados, compreendendo a refatoração de consultas lentas e o ajuste fino (\textit{tuning}) de parâmetros do SGBD; + + \item comparar o desempenho do banco de dados operando sobre diferentes sistemas de arquivos, como EXT4, XFS e ZFS; + + \item aferir a diferença de performance e consumo de recursos entre a utilização de binários genéricos do SGBD e binários compilados especificamente para a arquitetura de \textit{hardware} do servidor; + + \item analisar os resultados obtidos nos diferentes cenários de teste para determinar a viabilidade técnica e financeira de realizar o \textit{downscaling} da infraestrutura sem comprometer os requisitos de desempenho da aplicação. +\end{alineas} + +\section{JUSTIFICATIVA} + +A computação em nuvem tornou acessível a empresas de qualquer porte o mesmo tipo de infraestrutura antes restrita a grandes corporações. No modelo de precificação por consumo (\textit{pay-as-you-go}), porém, cada recurso provisionado sem necessidade transforma-se em custo recorrente. Armbrust et al.~\cite{armbrust2010} argumentam que a elasticidade da nuvem é economicamente vantajosa apenas quando os recursos são utilizados de forma eficiente; caso contrário, o custo por hora de instâncias ociosas ou subutilizadas supera rapidamente os ganhos obtidos com a escalabilidade. Schwartz et al.~\cite{schwartz2012} observam que a ineficiência na camada de software do banco de dados é uma das principais fontes desse desperdício: o SGBD consome mais CPU e memória do que precisaria se estivesse devidamente configurado, o que eleva o dimensionamento mínimo necessário para manter a aplicação estável. Quando o desempenho degrada, a reação típica é aumentar o plano da instância em nuvem, sem investigar se o problema está na configuração do banco. + +Do ponto de vista tecnológico, a comodidade dos repositórios de pacotes das distribuições Linux consolidou um padrão de implantação baseado em binários genéricos, compilados para máxima compatibilidade em detrimento do desempenho. A literatura e a comunidade de banco de dados abordam com frequência o ajuste fino no nível lógico, como a criação de índices e a reescrita de consultas~\cite{elmasri2011}. Van Aken et al.~\cite{vanaken2021} confirmam que mesmo as ferramentas automáticas de configuração de SGBD se concentram quase exclusivamente em parâmetros internos do banco (como tamanho de cache e estratégia de flush), deixando de lado as camadas subjacentes. O impacto de descer até a camada do sistema de arquivos ou recompilar o SGBD para a arquitetura do servidor ainda é pouco explorado fora de ambientes de alta performance. Para empresas de pequeno porte, esse conhecimento costuma estar simplesmente ausente. + +A relevância prática deste trabalho está em demonstrar, com dados, que um servidor de menor capacidade pode entregar desempenho igual ou superior ao de uma máquina mais robusta caso o software esteja adequadamente otimizado. Para organizações SaaS de pequeno porte, cujas margens são sensíveis a variações nos custos de infraestrutura, o \textit{downscaling} viabilizado pela otimização pode representar a diferença entre operar com folga ou operar no limite. + +\chapter{REFERENCIAL TEÓRICO} +\label{cap:referencial_teorico} + +\section{ARQUITETURA DO SGBD E O MOTOR INNODB} + +O MariaDB é um sistema gerenciador de banco de dados relacional (SGBDR) derivado do MySQL, criado como \textit{fork} comunitário em 2009 após a aquisição do MySQL pela Oracle. Como todo SGBDR que pretende ser utilizado em ambientes de produção, o MariaDB deve garantir as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) para assegurar a integridade das transações mesmo em caso de falhas \cite{silberschatz2019}. Taipalus~\cite{taipalus2023}, em revisão sistemática da literatura sobre desempenho de SGBDs, observa que as diferenças de performance entre sistemas como MySQL, MariaDB e PostgreSQL frequentemente se devem menos ao motor em si e mais à forma como cada um é configurado e implantado. + +O motor de armazenamento padrão do MariaDB desde a versão 10.2 é o InnoDB. O InnoDB organiza os dados em tablespaces e mantém, em memória RAM, um cache chamado \textit{Buffer Pool}, onde armazena cópias de páginas de dados e índices acessados com frequência. Do et al.~\cite{do2008turbocharging} demonstraram que a eficiência do \textit{Buffer Pool} está diretamente ligada ao \textit{throughput} do sistema, sobretudo em cenários de alta concorrência. Quando o tamanho do cache é insuficiente para a carga de trabalho, o motor passa a buscar dados no disco com mais frequência, o que eleva a latência e reduz a vazão de processamento. Schwartz et al.~\cite{schwartz2012} vão além e afirmam que a correta configuração dos componentes de memória do InnoDB é o fator isolado com maior impacto no desempenho de cargas OLTP (\textit{Online Transaction Processing}). + +Além do \textit{Buffer Pool}, o InnoDB utiliza um \textit{Log Buffer} para acumular alterações antes de gravá-las nos arquivos de log em disco, e um \textit{Change Buffer} para cache de modificações pendentes em índices secundários. O funcionamento conjunto desses três mecanismos determina, na prática, o quanto o banco de dados consegue absorver requisições sem recorrer ao acesso direto ao armazenamento persistente. + +\section{OTIMIZAÇÃO LÓGICA E AJUSTE DE PARÂMETROS (\textit{TUNING})} + +O ajuste de parâmetros do SGBD (geralmente chamado de \textit{tuning}) consiste em adaptar as configurações-padrão do sistema à carga de trabalho real e ao hardware disponível. Herodotou et al.~\cite{herodotou2020}, em survey sobre ajuste automático de parâmetros, destacam que a configuração manual de SGBDs é um problema reconhecidamente difícil: o espaço de busca é grande, os parâmetros interagem entre si de forma não trivial e o impacto de cada ajuste depende da carga de trabalho. Elmasri e Navathe~\cite{elmasri2011} observam que o desempenho de um banco de dados pode melhorar de forma considerável apenas com a escolha adequada de índices, o particionamento de tabelas e o ajuste de parâmetros de memória, sem necessidade de investir em hardware novo. + +No MariaDB, dois parâmetros merecem destaque. O primeiro é \texttt{innodb\_buffer\_pool\_size}, que define a porção de RAM dedicada ao cache de dados e índices. Em servidores dedicados ao banco de dados, a recomendação usual é reservar entre 50\% e 80\% da memória total para esse parâmetro~\cite{schwartz2012}. O segundo é \texttt{innodb\_flush\_log\_at\_trx\_commit}, que controla a frequência com que o log de transações é gravado em disco. O valor padrão (1) garante durabilidade completa a cada transação, mas implica uma chamada \texttt{fsync()} por \textit{commit}, o que se torna um gargalo em cargas com volume elevado de escritas. Ao alterar o valor para 2, o log é gravado no buffer do sistema operacional a cada transação e descarregado para o disco aproximadamente uma vez por segundo, reduzindo a latência ao custo de uma pequena janela de risco de perda de dados em caso de falha de energia. + +A refatoração de consultas SQL complementa o ajuste de parâmetros. Consultas mal estruturadas ou que não aproveitam os índices disponíveis sobrecarregam a CPU e geram volume desnecessário de I/O. Segundo Schwartz et al.~\cite{schwartz2012}, a otimização no nível lógico das consultas costuma ser uma das intervenções com melhor custo-benefício, justamente porque não exige mudanças na infraestrutura. + +\section{SISTEMAS DE ARQUIVOS E DESEMPENHO DE I/O} + +Entre o SGBD e o dispositivo de armazenamento físico está o sistema de arquivos, encarregado de organizar, alocar e recuperar os dados gravados em disco. Embora essa camada seja frequentemente negligenciada em implantações de pequeno porte, a escolha do sistema de arquivos pode ter impacto mensurável na latência e na vazão do banco de dados, especialmente sob cargas com muita escrita sequencial ou aleatória. Aghayev et al.~\cite{aghayev2019}, ao analisar o comportamento do Ceph sobre diferentes sistemas de arquivos locais, constataram que as diferenças de desempenho entre EXT4 e XFS em cargas intensivas de I/O são significativas o bastante para comprometer a vazão de todo o sistema de armazenamento distribuído. + +O EXT4 é o sistema de arquivos padrão na maioria das distribuições Linux. Suporta volumes de até 1~EiB e foi projetado com foco em robustez e compatibilidade retroativa com o EXT3~\cite{mathur2007}. Utiliza um mecanismo de \textit{journaling} em modo \textit{ordered} por padrão, que registra os metadados no jornal antes de gravar os dados efetivos. Apesar de estável e amplamente testado, o EXT4 utiliza uma estrutura centralizada de alocação de blocos que, conforme observam Mathur et al.~\cite{mathur2007}, pode gerar contenção em operações concorrentes de escrita. + +O XFS, originalmente desenvolvido pela Silicon Graphics na década de 1990 e hoje mantido pela comunidade do kernel Linux, foi concebido para operar com arquivos e volumes de grande porte. Seu esquema de alocação baseado em extensões (\textit{extents}) e sua capacidade de realizar I/O paralelo o tornam adequado para cargas de trabalho com acesso simultâneo de múltiplos processos~\cite{hellwig2009}. Segundo Hellwig, o XFS escala melhor que o EXT4 em servidores com muitos núcleos de CPU, pois distribui a gestão de metadados entre as unidades de alocação em vez de centralizá-la. + +Já o ZFS, criado pela Sun Microsystems, adota uma arquitetura diferente: unifica o sistema de arquivos e o gerenciador de volumes numa camada única. Dentre seus recursos estão compressão transparente, checksums de dados e metadados, e \textit{snapshots} instantâneos~\cite{rodeh2008}. A arquitetura é descrita por Bonwick e Moore~\cite{bonwick2003} como \textit{copy-on-write}, o que garante consistência em caso de falha, porém adiciona um alto custo em operações de escrita. Há ainda uma questão prática relevante para bancos de dados: o ZFS mantém seu próprio cache em memória, o ARC (\textit{Adaptive Replacement Cache}), que pode competir com o \textit{Buffer Pool} do InnoDB caso os limites de cada um não sejam planejados em conjunto. + +\section{COMPILAÇÃO CUSTOMIZADA} + +As distribuições Linux costumam distribuir o MariaDB em binários compilados com opções conservadoras, de modo a funcionar em qualquer processador x86-64. Isso significa que instruções específicas presentes em processadores recentes (como as extensões AVX2, AVX-512 e SSE) acabam não sendo utilizadas. Drepper~\cite{drepper2007} detalha como o custo dessa abstração não é desprezível: a forma como o compilador organiza o acesso à memória, o alinhamento dos dados e o aproveitamento dos caches da CPU afeta diretamente o desempenho do programa resultante. + +Ao compilar o MariaDB a partir do código-fonte com a flag \texttt{-march=native} no GCC, o binário passa a ser gerado especificamente para a microarquitetura do processador hospedeiro. Isso permite ao compilador emitir instruções vetoriais e organizar o código de modo a explorar melhor a hierarquia de caches (L1, L2 e L3). Drepper~\cite{drepper2007} mostra que o uso correto da localidade de cache pode reduzir o tempo de execução de certas operações em até uma ordem de grandeza, sem exigir nenhum investimento em hardware adicional. + +\chapter{METODOLOGIA CIENTÍFICA} +\label{cap:metodologia_cientifica} + +Este trabalho caracteriza-se como pesquisa aplicada, por buscar solução para um problema concreto de desempenho e custo em um ambiente real de produção. Quanto aos objetivos, enquadra-se como pesquisa exploratória e descritiva: exploratória por investigar alternativas de otimização em diferentes camadas técnicas, e descritiva por documentar e interpretar os efeitos observados em cada intervenção. Quanto à abordagem, é predominantemente quantitativa, pois utiliza indicadores mensuráveis de desempenho e consumo de recursos para fundamentar a análise. + +Quanto ao procedimento técnico, a pesquisa será conduzida como estudo de caso único em uma empresa de pequeno porte do setor SaaS que utiliza MariaDB. Não se trata de experimento com grupo controle; a comparação será intracasos, com referência no cenário inicial (\textit{baseline}) e observação sistemática dos cenários subsequentes. O foco metodológico está na análise contextualizada do caso, com rastreabilidade das mudanças realizadas e seus efeitos sobre desempenho, estabilidade e custo operacional. + +\section{AMBIENTE DE ESTUDO} + +O ambiente de estudo será composto por uma instância isolada da aplicação e do banco de dados, construída para reproduzir as principais características do ambiente de produção sem expor a operação real da empresa a riscos. A base de dados utilizada nos testes será uma cópia controlada da base real ou uma massa equivalente, preservando volume, cardinalidade das tabelas, distribuição de registros e padrões de relacionamento. Quando houver dados sensíveis, estes deverão ser anonimizados antes da execução dos experimentos. + +Para garantir comparabilidade entre os testes, serão registrados os principais elementos do ambiente: versão do MariaDB, versão do sistema operacional, kernel, quantidade de CPU, memória RAM, tipo de armazenamento, sistema de arquivos, parâmetros de montagem, configuração do SGBD e características da carga de trabalho. Alterações nesses elementos ocorrerão apenas quando fizerem parte do cenário avaliado. + +\section{PROCEDIMENTOS DO ESTUDO DE CASO} + +O estudo de caso será organizado em etapas sucessivas. A primeira etapa consistirá na caracterização e medição do cenário atual, utilizando a configuração existente da aplicação, do sistema operacional, do sistema de arquivos e dos binários do MariaDB. Essa medição formará o \textit{baseline} contra o qual os demais cenários serão comparados. + +Na sequência, serão avaliados cenários de otimização lógica, ajuste de parâmetros do SGBD, comparação entre sistemas de arquivos e compilação customizada do MariaDB. Para isolar variáveis, cada cenário modificará apenas um fator técnico por vez, mantendo constantes carga de trabalho, massa de dados, hardware, versão de software e janela de observação. Ao final, será avaliado um cenário consolidado, reunindo as otimizações com melhor relação entre desempenho, estabilidade e custo. + +As etapas do estudo serão as seguintes: + +\begin{alineas} + \item medir o \textit{baseline} da infraestrutura atual, coletando métricas de desempenho e consumo de recursos sob carga representativa; + + \item identificar consultas SQL de maior custo por meio de logs, métricas do SGBD e comportamento observado na aplicação; + + \item aplicar refatorações em consultas e ajustes de índices, medindo o impacto dessas mudanças sobre latência e \textit{throughput}; + + \item ajustar parâmetros do MariaDB, com foco em memória, persistência de logs, concorrência e comportamento do InnoDB; + + \item comparar o desempenho do banco de dados sobre diferentes sistemas de arquivos, especialmente EXT4, XFS e ZFS, mantendo constantes a carga de trabalho e os demais componentes do ambiente; + + \item compilar o MariaDB a partir do código-fonte com opções voltadas à arquitetura do servidor e comparar os resultados com os binários genéricos distribuídos pelos repositórios da distribuição Linux; + + \item executar um teste de \textit{downscaling}, reduzindo os recursos da infraestrutura e verificando se a configuração otimizada mantém desempenho igual ou superior ao cenário inicial. +\end{alineas} + +\section{CARGA DE TRABALHO, CONTROLE DAS VARIÁVEIS E COLETA DE DADOS} + +A carga de trabalho utilizada nos testes deverá representar o uso real da aplicação. Para isso, serão consideradas as consultas mais frequentes, as consultas mais lentas, a proporção entre operações de leitura e escrita e o nível de concorrência observado no ambiente da empresa. O mesmo perfil de carga será aplicado em todos os cenários do estudo, permitindo comparação direta dos resultados. + +Antes de cada medição, o ambiente será preparado para reduzir variações externas, incluindo reinicialização controlada dos serviços quando necessário, verificação da integridade da base e aplicação das mesmas condições iniciais de teste. Cada cenário deverá passar por um período de aquecimento, para estabilização de caches e conexões, seguido por um período de medição. As execuções serão repetidas para reduzir o efeito de flutuações ocasionais, e os resultados serão consolidados por estatísticas descritivas (média, mediana, desvio-padrão e percentis). + +As variáveis independentes do estudo serão os fatores de intervenção técnica (consulta/indexação, parâmetros do SGBD, sistema de arquivos e tipo de binário). As variáveis dependentes serão as métricas de desempenho, consumo e custo. Como variáveis de controle, manter-se-ão constantes hardware, versão do kernel, versão do MariaDB, volume da base, perfil de carga, duração das medições e instrumentos de coleta. + +As principais métricas coletadas serão: + +\begin{alineas} + \item latência média, mediana e percentis de resposta das operações avaliadas; + + \item \textit{throughput}, expresso em requisições ou transações processadas por unidade de tempo; + + \item uso de CPU, memória RAM e \textit{swap}; + + \item volume de leitura e escrita em disco, IOPS e tempo de espera por I/O; + + \item indicadores internos do MariaDB, como uso do \textit{Buffer Pool}, consultas lentas, bloqueios e taxa de acerto de cache; + + \item custo estimado da infraestrutura necessária para sustentar cada cenário. +\end{alineas} + +\section{ANÁLISE DOS RESULTADOS} + +A análise dos resultados será realizada por comparação percentual em relação ao \textit{baseline}. Para cada cenário, serão observadas as variações de latência, \textit{throughput}, consumo de recursos e custo estimado. Uma otimização será considerada tecnicamente vantajosa quando reduzir latência ou consumo de recursos sem comprometer a estabilidade do sistema e sem degradar a vazão de processamento. + +O critério central de avaliação será a viabilidade do \textit{downscaling}. Assim, além de identificar o cenário com maior desempenho absoluto, o estudo buscará determinar se a combinação das otimizações permite operar em uma infraestrutura menor mantendo níveis de desempenho equivalentes ou superiores ao ambiente inicial. Caso esse resultado seja alcançado, será calculada a economia potencial com base na diferença de custo entre a infraestrutura original e a infraestrutura otimizada. + +Por fim, serão discutidas as limitações do estudo, especialmente aquelas relacionadas à especificidade da aplicação analisada, ao perfil da carga de trabalho, ao hardware disponível e ao fato de que resultados obtidos em um ambiente SaaS de pequeno porte podem não se repetir integralmente em sistemas com outras características. Ainda assim, o método proposto permitirá avaliar de forma objetiva o impacto prático das otimizações em múltiplas camadas e sua contribuição para a redução de custos operacionais. + +\section{ALINHAMENTO ENTRE OBJETIVOS ESPECÍFICOS E AVALIAÇÃO} + +Para assegurar que todos os objetivos específicos sejam contemplados metodologicamente, o Quadro~\ref{quad:objetivos-metodos} relaciona cada objetivo ao respectivo procedimento e critério de avaliação. + +\begin{quadro}[htb] +\caption{Relação entre objetivos específicos, procedimentos e avaliação} +\label{quad:objetivos-metodos} +\begin{tabular}{|p{0.30\textwidth}|p{0.34\textwidth}|p{0.28\textwidth}|} +\hline +\textbf{Objetivo específico} & \textbf{Como será atingido} & \textbf{Como será avaliado} \\ +\hline +Diagnosticar o \textit{baseline} da infraestrutura & Coleta inicial padronizada de métricas sob carga representativa & Linha de base validada por repetição e estabilidade das medições \\ +\hline +Aplicar otimização na camada de banco de dados & Refatoração de consultas lentas, ajuste de índices e \textit{tuning} de parâmetros do MariaDB & Variação de latência, \textit{throughput}, uso de CPU/RAM e métricas internas do InnoDB \\ +\hline +Comparar sistemas de arquivos (EXT4, XFS, ZFS) & Execução da mesma carga em ambientes equivalentes, alterando apenas o sistema de arquivos & Diferença percentual em latência, IOPS, tempo de espera de I/O e vazão \\ +\hline +Comparar binários genéricos e compilados & Compilação customizada do MariaDB para a arquitetura do servidor e execução de testes equivalentes & Ganho/perda de desempenho e consumo de recursos por cenário \\ +\hline +Analisar viabilidade técnica e financeira do \textit{downscaling} & Consolidação das melhores otimizações e teste com redução de recursos computacionais & Manutenção de desempenho mínimo com menor custo mensal estimado \\ +\hline +\end{tabular} +\fonte{Elaboração do autor (2026).} +\end{quadro} + +\postextual +\bibliography{ref} + +\end{document} blob - /dev/null blob + 055a413f6d72e303bd5dcdabc0cfa343f7cad1b3 (mode 644) --- /dev/null +++ main.bak1 @@ -0,0 +1,239 @@ +\documentclass[ + 12pt, % Entire doc font size + oneside, % Capítulos começam em página ímpar + a4paper, % Tamanho do papel + english, % Idioma adicional para hifenização + brazil % O último idioma é o principal do documento +]{abntex2} + +% --- Pacotes Básicos --- +\usepackage{helvet} +\usepackage[T1]{fontenc} +\usepackage[utf8]{inputenc} +\usepackage{indentfirst} +\usepackage{color} +\usepackage{graphicx} +\usepackage{microtype} + +\usepackage[alf]{abntex2cite} + +\titulo{OTIMIZAÇÃO MULTICAMADAS NO MARIADB} +\autor{ANDRÉ MAZZOTTI BERTACHINI} +\local{CAÇADOR} +\data{2026} +\orientador{Prof. Dr. Cristiano Mesquita Garcia} +\coorientador{Prof. Dr. Paulo Roberto Cordova} +\instituicao{INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DE SANTA CATARINA \par CÂMPUS CAÇADOR} +\tipotrabalho{Monografia} + +\definecolor{blue}{RGB}{41,5,195} +\hypersetup{ + pdftitle={\@title}, + pdfauthor={\@author}, + pdfsubject={\imprimirpreambulo}, + pdfcreator={LaTeX with abnTeX2}, + pdfkeywords={MariaDB}{Infraestrutura}{Downscaling}{abntex2}, + colorlinks=true, + linkcolor=blue, + citecolor=blue, + urlcolor=blue +} + +\begin{document} +\selectlanguage{brazil} +\frenchspacing + +\imprimircapa +\imprimirfolhaderosto + +\begin{resumo} + Este trabalho investiga, em uma aplicação SaaS de pequeno porte, como otimizações em múltiplas camadas da infraestrutura de dados podem melhorar desempenho e reduzir custos operacionais. O estudo será conduzido por meio de estudo de caso único, com coleta de métricas antes e depois de intervenções planejadas na camada de banco de dados (refatoração de consultas e ajuste de parâmetros), no sistema de arquivos e no processo de compilação do MariaDB. A análise será quantitativa, com comparação de latência, vazão de processamento, consumo de recursos e custo estimado de infraestrutura em cenários comparáveis. Como resultado esperado, busca-se identificar combinações de otimização tecnicamente viáveis para sustentar a carga da aplicação com menor capacidade computacional, preservando estabilidade e qualidade de serviço. + + \textbf{Palavras-chave}: MariaDB; otimização; desempenho; custos operacionais; estudo de caso. +\end{resumo} + +\pdfbookmark[0]{\contentsname}{toc} +\tableofcontents* +\cleardoublepage + +\textual +\pagestyle{simple} + +\chapter{INTRODUÇÃO} +Bancos de dados relacionais estão no núcleo de praticamente toda aplicação web. No setor de \textit{Software as a Service} (SaaS), onde a infraestrutura é faturada por consumo, a eficiência com que o sistema gerenciador de banco de dados (SGBD) utiliza CPU, memória e disco reflete-se nos custos operacionais da empresa. O MariaDB, \textit{fork} comunitário do MySQL mantido pela MariaDB Corporation e pela comunidade, é um dos SGBDs mais empregados nesse cenário. A maioria das implantações, no entanto, utiliza binários pré-compilados distribuídos pelos repositórios das distribuições Linux, com configurações-padrão pensadas para compatibilidade ampla em vez de desempenho. Van Aken et al.~\cite{vanaken2017} demonstram que a configuração de um SGBD é um problema de alta complexidade e que os valores-padrão raramente são adequados para a carga de trabalho real, o que leva a um desperdício de processamento e memória que poderia ser evitado. + +Este trabalho investiga o impacto da otimização em múltiplas camadas de infraestrutura sobre o desempenho de uma aplicação SaaS de pequeno porte, abrangendo o ajuste de parâmetros do SGBD, a refatoração de consultas SQL, a comparação entre sistemas de arquivos e a compilação customizada do código-fonte do MariaDB. A premissa é que a aplicação combinada dessas técnicas permite reduzir a infraestrutura contratada (\textit{downscaling}) sem perda de desempenho. + +\section{PROBLEMA DE PESQUISA} +Sistemas gerenciadores de bancos de dados relacionais como o MariaDB costumam ser implantados com binários generalistas e configurações que pouco se ajustam ao hardware ou à carga de trabalho específica do ambiente. Van Aken et al.~\cite{vanaken2017} destacam que a busca manual por boas configurações de SGBD exige conhecimento especializado e tempo, o que leva a maioria das implantações a operar com valores-padrão conservadores. Como consequência, observa-se uma subutilização crônica de CPU e memória e uma saturação prematura da vazão de processamento (\textit{throughput}). + +Sob cargas de trabalho com alta concorrência, o sistema degrada: a latência aumenta e o \textit{throughput} cai. Silberschatz et al.~\cite{silberschatz2019} explicam que esse comportamento está ligado à forma como o SGBD gerencia o tráfego entre memória e disco; quando os buffers são mal dimensionados, o acesso ao disco se torna o gargalo. A resposta mais comum no mercado é o superprovisionamento, ou seja, a alocação de mais recursos de hardware (escalabilidade vertical). Trata-se de uma correção pontual: o novo hardware é consumido pela mesma ineficiência de antes, e os custos operacionais crescem de forma proporcional. + +Esse cenário manifesta-se na prática numa empresa de pequeno porte do setor SaaS acompanhada neste estudo. A organização mantém um sistema em produção que, com o crescimento da base de usuários, passou a apresentar gargalos de desempenho no acesso aos dados. A infraestrutura atual opera com sistema operacional de uso geral, sistema de arquivos na configuração padrão e binários pré-compilados do MariaDB obtidos via gerenciador de pacotes. A ausência de ajuste em qualquer uma dessas camadas contribui para picos de latência nos horários de pico e pressionou a empresa a considerar \textit{upgrades} de hardware em nuvem para sustentar a operação. + +Diante desse quadro, formula-se a seguinte questão de pesquisa: quais são os impactos da otimização em múltiplas camadas de infraestrutura, englobando sistema operacional, sistema de arquivos, compilação customizada de binários e parâmetros do SGBD, no desempenho e nos custos operacionais de uma aplicação SaaS de pequeno porte? +\section{OBJETIVOS} +\subsection{Objetivo Geral} +Avaliar o impacto da aplicação de técnicas de otimização em múltiplas camadas de +infraestrutura, englobando a refatoração de consultas, ajustes de parâmetros do +SGBD, escolha do sistema de arquivos, escolha do sistema operacional e +compilação customizada do código-fonte, visando maximizar a vazão de +processamento, minimizar a latência e viabilizar a redução de custos operacionais +(\textit{downscaling}) de uma aplicação SaaS de pequeno porte. +\subsection{Objetivos Específicos} + +Para o alcance do objetivo geral proposto, definem-se os seguintes objetivos específicos: + +\begin{alineas} + \item diagnosticar o cenário atual (\textit{baseline}) da infraestrutura de banco de dados da empresa, aferindo métricas de consumo de recursos, latência e \textit{throughput} sob a carga de trabalho existente; + + \item aplicar técnicas de otimização na camada de banco de dados, compreendendo a refatoração de consultas lentas e o ajuste fino (\textit{tuning}) de parâmetros do SGBD; + + \item comparar o desempenho do banco de dados operando sobre diferentes sistemas de arquivos, como EXT4, XFS e ZFS; + + \item aferir a diferença de performance e consumo de recursos entre a utilização de binários genéricos do SGBD e binários compilados especificamente para a arquitetura de \textit{hardware} do servidor; + + \item analisar os resultados obtidos nos diferentes cenários de teste para determinar a viabilidade técnica e financeira de realizar o \textit{downscaling} da infraestrutura sem comprometer os requisitos de desempenho da aplicação. +\end{alineas} + +\section{JUSTIFICATIVA} + +A computação em nuvem tornou acessível a empresas de qualquer porte o mesmo tipo de infraestrutura antes restrita a grandes corporações. No modelo de precificação por consumo (\textit{pay-as-you-go}), porém, cada recurso provisionado sem necessidade transforma-se em custo recorrente. Armbrust et al.~\cite{armbrust2010} argumentam que a elasticidade da nuvem é economicamente vantajosa apenas quando os recursos são utilizados de forma eficiente; caso contrário, o custo por hora de instâncias ociosas ou subutilizadas supera rapidamente os ganhos obtidos com a escalabilidade. Schwartz et al.~\cite{schwartz2012} observam que a ineficiência na camada de software do banco de dados é uma das principais fontes desse desperdício: o SGBD consome mais CPU e memória do que precisaria se estivesse devidamente configurado, o que eleva o dimensionamento mínimo necessário para manter a aplicação estável. Quando o desempenho degrada, a reação típica é aumentar o plano da instância em nuvem, sem investigar se o problema está na configuração do banco. + +Do ponto de vista tecnológico, a comodidade dos repositórios de pacotes das distribuições Linux consolidou um padrão de implantação baseado em binários genéricos, compilados para máxima compatibilidade em detrimento do desempenho. A literatura e a comunidade de banco de dados abordam com frequência o ajuste fino no nível lógico, como a criação de índices e a reescrita de consultas~\cite{elmasri2011}. Van Aken et al.~\cite{vanaken2021} confirmam que mesmo as ferramentas automáticas de configuração de SGBD se concentram quase exclusivamente em parâmetros internos do banco (como tamanho de cache e estratégia de flush), deixando de lado as camadas subjacentes. O impacto de descer até a camada do sistema de arquivos ou recompilar o SGBD para a arquitetura do servidor ainda é pouco explorado fora de ambientes de alta performance. Para empresas de pequeno porte, esse conhecimento costuma estar simplesmente ausente. + +A relevância prática deste trabalho está em demonstrar, com dados, que um servidor de menor capacidade pode entregar desempenho igual ou superior ao de uma máquina mais robusta caso o software esteja adequadamente otimizado. Para organizações SaaS de pequeno porte, cujas margens são sensíveis a variações nos custos de infraestrutura, o \textit{downscaling} viabilizado pela otimização pode representar a diferença entre operar com folga ou operar no limite. + +\chapter{REFERENCIAL TEÓRICO} +\label{cap:referencial_teorico} + +\section{ARQUITETURA DO SGBD E O MOTOR INNODB} + +O MariaDB é um sistema gerenciador de banco de dados relacional (SGBDR) derivado do MySQL, criado como \textit{fork} comunitário em 2009 após a aquisição do MySQL pela Oracle. Como todo SGBDR que pretende ser utilizado em ambientes de produção, o MariaDB deve garantir as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) para assegurar a integridade das transações mesmo em caso de falhas \cite{silberschatz2019}. Taipalus~\cite{taipalus2023}, em revisão sistemática da literatura sobre desempenho de SGBDs, observa que as diferenças de performance entre sistemas como MySQL, MariaDB e PostgreSQL frequentemente se devem menos ao motor em si e mais à forma como cada um é configurado e implantado. + +O motor de armazenamento padrão do MariaDB desde a versão 10.2 é o InnoDB. O InnoDB organiza os dados em tablespaces e mantém, em memória RAM, um cache chamado \textit{Buffer Pool}, onde armazena cópias de páginas de dados e índices acessados com frequência. Do et al.~\cite{do2008turbocharging} demonstraram que a eficiência do \textit{Buffer Pool} está diretamente ligada ao \textit{throughput} do sistema, sobretudo em cenários de alta concorrência. Quando o tamanho do cache é insuficiente para a carga de trabalho, o motor passa a buscar dados no disco com mais frequência, o que eleva a latência e reduz a vazão de processamento. Schwartz et al.~\cite{schwartz2012} vão além e afirmam que a correta configuração dos componentes de memória do InnoDB é o fator isolado com maior impacto no desempenho de cargas OLTP (\textit{Online Transaction Processing}). + +Além do \textit{Buffer Pool}, o InnoDB utiliza um \textit{Log Buffer} para acumular alterações antes de gravá-las nos arquivos de log em disco, e um \textit{Change Buffer} para cache de modificações pendentes em índices secundários. O funcionamento conjunto desses três mecanismos determina, na prática, o quanto o banco de dados consegue absorver requisições sem recorrer ao acesso direto ao armazenamento persistente. + +\section{OTIMIZAÇÃO LÓGICA E AJUSTE DE PARÂMETROS (\textit{TUNING})} + +O ajuste de parâmetros do SGBD (geralmente chamado de \textit{tuning}) consiste em adaptar as configurações-padrão do sistema à carga de trabalho real e ao hardware disponível. Herodotou et al.~\cite{herodotou2020}, em survey sobre ajuste automático de parâmetros, destacam que a configuração manual de SGBDs é um problema reconhecidamente difícil: o espaço de busca é grande, os parâmetros interagem entre si de forma não trivial e o impacto de cada ajuste depende da carga de trabalho. Elmasri e Navathe~\cite{elmasri2011} observam que o desempenho de um banco de dados pode melhorar de forma considerável apenas com a escolha adequada de índices, o particionamento de tabelas e o ajuste de parâmetros de memória, sem necessidade de investir em hardware novo. + +No MariaDB, dois parâmetros merecem destaque. O primeiro é \texttt{innodb\_buffer\_pool\_size}, que define a porção de RAM dedicada ao cache de dados e índices. Em servidores dedicados ao banco de dados, a recomendação usual é reservar entre 50\% e 80\% da memória total para esse parâmetro~\cite{schwartz2012}. O segundo é \texttt{innodb\_flush\_log\_at\_trx\_commit}, que controla a frequência com que o log de transações é gravado em disco. O valor padrão (1) garante durabilidade completa a cada transação, mas implica uma chamada \texttt{fsync()} por \textit{commit}, o que se torna um gargalo em cargas com volume elevado de escritas. Ao alterar o valor para 2, o log é gravado no buffer do sistema operacional a cada transação e descarregado para o disco aproximadamente uma vez por segundo, reduzindo a latência ao custo de uma pequena janela de risco de perda de dados em caso de falha de energia. + +A refatoração de consultas SQL complementa o ajuste de parâmetros. Consultas mal estruturadas ou que não aproveitam os índices disponíveis sobrecarregam a CPU e geram volume desnecessário de I/O. Segundo Schwartz et al.~\cite{schwartz2012}, a otimização no nível lógico das consultas costuma ser uma das intervenções com melhor custo-benefício, justamente porque não exige mudanças na infraestrutura. + +\section{SISTEMAS DE ARQUIVOS E DESEMPENHO DE I/O} + +Entre o SGBD e o dispositivo de armazenamento físico está o sistema de arquivos, encarregado de organizar, alocar e recuperar os dados gravados em disco. Embora essa camada seja frequentemente negligenciada em implantações de pequeno porte, a escolha do sistema de arquivos pode ter impacto mensurável na latência e na vazão do banco de dados, especialmente sob cargas com muita escrita sequencial ou aleatória. Aghayev et al.~\cite{aghayev2019}, ao analisar o comportamento do Ceph sobre diferentes sistemas de arquivos locais, constataram que as diferenças de desempenho entre EXT4 e XFS em cargas intensivas de I/O são significativas o bastante para comprometer a vazão de todo o sistema de armazenamento distribuído. + +O EXT4 é o sistema de arquivos padrão na maioria das distribuições Linux. Suporta volumes de até 1~EiB e foi projetado com foco em robustez e compatibilidade retroativa com o EXT3~\cite{mathur2007}. Utiliza um mecanismo de \textit{journaling} em modo \textit{ordered} por padrão, que registra os metadados no jornal antes de gravar os dados efetivos. Apesar de estável e amplamente testado, o EXT4 utiliza uma estrutura centralizada de alocação de blocos que, conforme observam Mathur et al.~\cite{mathur2007}, pode gerar contenção em operações concorrentes de escrita. + +O XFS, originalmente desenvolvido pela Silicon Graphics na década de 1990 e hoje mantido pela comunidade do kernel Linux, foi concebido para operar com arquivos e volumes de grande porte. Seu esquema de alocação baseado em extensões (\textit{extents}) e sua capacidade de realizar I/O paralelo o tornam adequado para cargas de trabalho com acesso simultâneo de múltiplos processos~\cite{hellwig2009}. Segundo Hellwig, o XFS escala melhor que o EXT4 em servidores com muitos núcleos de CPU, pois distribui a gestão de metadados entre as unidades de alocação em vez de centralizá-la. + +Já o ZFS, criado pela Sun Microsystems, adota uma arquitetura diferente: unifica o sistema de arquivos e o gerenciador de volumes numa camada única. Dentre seus recursos estão compressão transparente, checksums de dados e metadados, e \textit{snapshots} instantâneos~\cite{rodeh2008}. A arquitetura é descrita por Bonwick e Moore~\cite{bonwick2003} como \textit{copy-on-write}, o que garante consistência em caso de falha, porém adiciona um alto custo em operações de escrita. Há ainda uma questão prática relevante para bancos de dados: o ZFS mantém seu próprio cache em memória, o ARC (\textit{Adaptive Replacement Cache}), que pode competir com o \textit{Buffer Pool} do InnoDB caso os limites de cada um não sejam planejados em conjunto. + +\section{COMPILAÇÃO CUSTOMIZADA} + +As distribuições Linux costumam distribuir o MariaDB em binários compilados com opções conservadoras, de modo a funcionar em qualquer processador x86-64. Isso significa que instruções específicas presentes em processadores recentes (como as extensões AVX2, AVX-512 e SSE) acabam não sendo utilizadas. Drepper~\cite{drepper2007} detalha como o custo dessa abstração não é desprezível: a forma como o compilador organiza o acesso à memória, o alinhamento dos dados e o aproveitamento dos caches da CPU afeta diretamente o desempenho do programa resultante. + +Ao compilar o MariaDB a partir do código-fonte com a flag \texttt{-march=native} no GCC, o binário passa a ser gerado especificamente para a microarquitetura do processador hospedeiro. Isso permite ao compilador emitir instruções vetoriais e organizar o código de modo a explorar melhor a hierarquia de caches (L1, L2 e L3). Drepper~\cite{drepper2007} mostra que o uso correto da localidade de cache pode reduzir o tempo de execução de certas operações em até uma ordem de grandeza, sem exigir nenhum investimento em hardware adicional. + +\chapter{METODOLOGIA CIENTÍFICA} +\label{cap:metodologia_cientifica} + +Este trabalho caracteriza-se como pesquisa aplicada, por buscar solução para um problema concreto de desempenho e custo em um ambiente real de produção. Quanto aos objetivos, enquadra-se como pesquisa exploratória e descritiva: exploratória por investigar alternativas de otimização em diferentes camadas técnicas, e descritiva por documentar e interpretar os efeitos observados em cada intervenção. Quanto à abordagem, é predominantemente quantitativa, pois utiliza indicadores mensuráveis de desempenho e consumo de recursos para fundamentar a análise. + +Quanto ao procedimento técnico, a pesquisa será conduzida como estudo de caso único em uma empresa de pequeno porte do setor SaaS que utiliza MariaDB. Não se trata de experimento com grupo controle; a comparação será intracasos, com referência no cenário inicial (\textit{baseline}) e observação sistemática dos cenários subsequentes. O foco metodológico está na análise contextualizada do caso, com rastreabilidade das mudanças realizadas e seus efeitos sobre desempenho, estabilidade e custo operacional. + +\section{AMBIENTE DE ESTUDO} + +O ambiente de estudo será composto por uma instância isolada da aplicação e do banco de dados, construída para reproduzir as principais características do ambiente de produção sem expor a operação real da empresa a riscos. A base de dados utilizada nos testes será uma cópia controlada da base real ou uma massa equivalente, preservando volume, cardinalidade das tabelas, distribuição de registros e padrões de relacionamento. Quando houver dados sensíveis, estes deverão ser anonimizados antes da execução dos experimentos. + +Para garantir comparabilidade entre os testes, serão registrados os principais elementos do ambiente: versão do MariaDB, versão do sistema operacional, kernel, quantidade de CPU, memória RAM, tipo de armazenamento, sistema de arquivos, parâmetros de montagem, configuração do SGBD e características da carga de trabalho. Alterações nesses elementos ocorrerão apenas quando fizerem parte do cenário avaliado. + +\section{PROCEDIMENTOS DO ESTUDO DE CASO} + +O estudo de caso será organizado em etapas sucessivas. A primeira etapa consistirá na caracterização e medição do cenário atual, utilizando a configuração existente da aplicação, do sistema operacional, do sistema de arquivos e dos binários do MariaDB. Essa medição formará o \textit{baseline} contra o qual os demais cenários serão comparados. + +Na sequência, serão avaliados cenários de otimização lógica, ajuste de parâmetros do SGBD, comparação entre sistemas de arquivos e compilação customizada do MariaDB. Para isolar variáveis, cada cenário modificará apenas um fator técnico por vez, mantendo constantes carga de trabalho, massa de dados, hardware, versão de software e janela de observação. Ao final, será avaliado um cenário consolidado, reunindo as otimizações com melhor relação entre desempenho, estabilidade e custo. + +As etapas do estudo serão as seguintes: + +\begin{alineas} + \item medir o \textit{baseline} da infraestrutura atual, coletando métricas de desempenho e consumo de recursos sob carga representativa; + + \item identificar consultas SQL de maior custo por meio de logs, métricas do SGBD e comportamento observado na aplicação; + + \item aplicar refatorações em consultas e ajustes de índices, medindo o impacto dessas mudanças sobre latência e \textit{throughput}; + + \item ajustar parâmetros do MariaDB, com foco em memória, persistência de logs, concorrência e comportamento do InnoDB; + + \item comparar o desempenho do banco de dados sobre diferentes sistemas de arquivos, especialmente EXT4, XFS e ZFS, mantendo constantes a carga de trabalho e os demais componentes do ambiente; + + \item compilar o MariaDB a partir do código-fonte com opções voltadas à arquitetura do servidor e comparar os resultados com os binários genéricos distribuídos pelos repositórios da distribuição Linux; + + \item executar um teste de \textit{downscaling}, reduzindo os recursos da infraestrutura e verificando se a configuração otimizada mantém desempenho igual ou superior ao cenário inicial. +\end{alineas} + +\section{CARGA DE TRABALHO, CONTROLE DAS VARIÁVEIS E COLETA DE DADOS} + +A carga de trabalho utilizada nos testes deverá representar o uso real da aplicação. Para isso, serão consideradas as consultas mais frequentes, as consultas mais lentas, a proporção entre operações de leitura e escrita e o nível de concorrência observado no ambiente da empresa. O mesmo perfil de carga será aplicado em todos os cenários do estudo, permitindo comparação direta dos resultados. + +Antes de cada medição, o ambiente será preparado para reduzir variações externas, incluindo reinicialização controlada dos serviços quando necessário, verificação da integridade da base e aplicação das mesmas condições iniciais de teste. Cada cenário deverá passar por um período de aquecimento, para estabilização de caches e conexões, seguido por um período de medição. As execuções serão repetidas para reduzir o efeito de flutuações ocasionais, e os resultados serão consolidados por estatísticas descritivas (média, mediana, desvio-padrão e percentis). + +As variáveis independentes do estudo serão os fatores de intervenção técnica (consulta/indexação, parâmetros do SGBD, sistema de arquivos e tipo de binário). As variáveis dependentes serão as métricas de desempenho, consumo e custo. Como variáveis de controle, manter-se-ão constantes hardware, versão do kernel, versão do MariaDB, volume da base, perfil de carga, duração das medições e instrumentos de coleta. + +As principais métricas coletadas serão: + +\begin{alineas} + \item latência média, mediana e percentis de resposta das operações avaliadas; + + \item \textit{throughput}, expresso em requisições ou transações processadas por unidade de tempo; + + \item uso de CPU, memória RAM e \textit{swap}; + + \item volume de leitura e escrita em disco, IOPS e tempo de espera por I/O; + + \item indicadores internos do MariaDB, como uso do \textit{Buffer Pool}, consultas lentas, bloqueios e taxa de acerto de cache; + + \item custo estimado da infraestrutura necessária para sustentar cada cenário. +\end{alineas} + +\section{ANÁLISE DOS RESULTADOS} + +A análise dos resultados será realizada por comparação percentual em relação ao \textit{baseline}. Para cada cenário, serão observadas as variações de latência, \textit{throughput}, consumo de recursos e custo estimado. Uma otimização será considerada tecnicamente vantajosa quando reduzir latência ou consumo de recursos sem comprometer a estabilidade do sistema e sem degradar a vazão de processamento. + +O critério central de avaliação será a viabilidade do \textit{downscaling}. Assim, além de identificar o cenário com maior desempenho absoluto, o estudo buscará determinar se a combinação das otimizações permite operar em uma infraestrutura menor mantendo níveis de desempenho equivalentes ou superiores ao ambiente inicial. Caso esse resultado seja alcançado, será calculada a economia potencial com base na diferença de custo entre a infraestrutura original e a infraestrutura otimizada. + +Por fim, serão discutidas as limitações do estudo, especialmente aquelas relacionadas à especificidade da aplicação analisada, ao perfil da carga de trabalho, ao hardware disponível e ao fato de que resultados obtidos em um ambiente SaaS de pequeno porte podem não se repetir integralmente em sistemas com outras características. Ainda assim, o método proposto permitirá avaliar de forma objetiva o impacto prático das otimizações em múltiplas camadas e sua contribuição para a redução de custos operacionais. + +\section{ALINHAMENTO ENTRE OBJETIVOS ESPECÍFICOS E AVALIAÇÃO} + +Para assegurar que todos os objetivos específicos sejam contemplados metodologicamente, a Tabela~\ref{tab:objetivos-metodos} relaciona cada objetivo ao respectivo procedimento e critério de avaliação. + +\begin{table}[htb] +\caption{Relação entre objetivos específicos, procedimentos e avaliação} +\label{quad:objetivos-metodos} +\begin{tabular}{|p{0.30\textwidth}|p{0.34\textwidth}|p{0.28\textwidth}|} + \hline + \textbf{Objetivo específico} & \textbf{Como será atingido} & \textbf{Como será avaliado} \\ + \hline + Diagnosticar o \textit{baseline} da infraestrutura & Coleta inicial padronizada de métricas sob carga representativa & Linha de base validada por repetição e estabilidade das medições \\ + \hline + Aplicar otimização na camada de banco de dados & Refatoração de consultas lentas, ajuste de índices e \textit{tuning} de parâmetros do MariaDB & Variação de latência, \textit{throughput}, uso de CPU/RAM e métricas internas do InnoDB \\ + \hline + Comparar sistemas de arquivos (EXT4, XFS, ZFS) & Execução da mesma carga em ambientes equivalentes, alterando apenas o sistema de arquivos & Diferença percentual em latência, IOPS, tempo de espera de I/O e vazão \\ + \hline + Comparar binários genéricos e compilados & Compilação customizada do MariaDB para a arquitetura do servidor e execução de testes equivalentes & Ganho/perda de desempenho e consumo de recursos por cenário \\ + \hline + Analisar viabilidade técnica e financeira do \textit{downscaling} & Consolidação das melhores otimizações e teste com redução de recursos computacionais & Manutenção de desempenho mínimo com menor custo mensal estimado \\ +\hline +\end{tabular} +\legend{Fonte: elaboração do autor (2026).} +\end{table} + +\postextual +\bibliography{ref} + +\end{document} blob - /dev/null blob + 21fa301e29046c5a77e8a8e43f2c3987f562ecb2 (mode 644) --- /dev/null +++ main.bak2 @@ -0,0 +1,239 @@ +\documentclass[ + 12pt, % Entire doc font size + oneside, % Capítulos começam em página ímpar + a4paper, % Tamanho do papel + english, % Idioma adicional para hifenização + brazil % O último idioma é o principal do documento +]{abntex2} + +% --- Pacotes Básicos --- +\usepackage{helvet} +\usepackage[T1]{fontenc} +\usepackage[utf8]{inputenc} +\usepackage{indentfirst} +\usepackage{color} +\usepackage{graphicx} +\usepackage{microtype} + +\usepackage[alf]{abntex2cite} + +\titulo{OTIMIZAÇÃO MULTICAMADAS NO MARIADB} +\autor{ANDRÉ MAZZOTTI BERTACHINI} +\local{CAÇADOR} +\data{2026} +\orientador{Prof. Dr. Cristiano Mesquita Garcia} +\coorientador{Prof. Dr. Paulo Roberto Cordova} +\instituicao{INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DE SANTA CATARINA \par CÂMPUS CAÇADOR} +\tipotrabalho{Monografia} + +\definecolor{blue}{RGB}{41,5,195} +\hypersetup{ + pdftitle={\@title}, + pdfauthor={\@author}, + pdfsubject={\imprimirpreambulo}, + pdfcreator={LaTeX with abnTeX2}, + pdfkeywords={MariaDB}{Infraestrutura}{Downscaling}{abntex2}, + colorlinks=true, + linkcolor=blue, + citecolor=blue, + urlcolor=blue +} + +\begin{document} +\selectlanguage{brazil} +\frenchspacing + +\imprimircapa +\imprimirfolhaderosto + +\begin{resumo} + Este trabalho investiga, em uma aplicação SaaS de pequeno porte, como otimizações em múltiplas camadas da infraestrutura de dados podem melhorar desempenho e reduzir custos operacionais. O estudo será conduzido por meio de estudo de caso único, com coleta de métricas antes e depois de intervenções planejadas na camada de banco de dados (refatoração de consultas e ajuste de parâmetros), no sistema de arquivos e no processo de compilação do MariaDB. A análise será quantitativa, com comparação de latência, vazão de processamento, consumo de recursos e custo estimado de infraestrutura em cenários comparáveis. Como resultado esperado, busca-se identificar combinações de otimização tecnicamente viáveis para sustentar a carga da aplicação com menor capacidade computacional, preservando estabilidade e qualidade de serviço. + + \textbf{Palavras-chave}: MariaDB; otimização; desempenho; custos operacionais; estudo de caso. +\end{resumo} + +\pdfbookmark[0]{\contentsname}{toc} +\tableofcontents* +\cleardoublepage + +\textual +\pagestyle{simple} + +\chapter{INTRODUÇÃO} +Bancos de dados relacionais estão no núcleo de praticamente toda aplicação web. No setor de \textit{Software as a Service} (SaaS), onde a infraestrutura é faturada por consumo, a eficiência com que o sistema gerenciador de banco de dados (SGBD) utiliza CPU, memória e disco reflete-se nos custos operacionais da empresa. O MariaDB, \textit{fork} comunitário do MySQL mantido pela MariaDB Corporation e pela comunidade, é um dos SGBDs mais empregados nesse cenário. A maioria das implantações, no entanto, utiliza binários pré-compilados distribuídos pelos repositórios das distribuições Linux, com configurações-padrão pensadas para compatibilidade ampla em vez de desempenho. Van Aken et al.~\cite{vanaken2017} demonstram que a configuração de um SGBD é um problema de alta complexidade e que os valores-padrão raramente são adequados para a carga de trabalho real, o que leva a um desperdício de processamento e memória que poderia ser evitado. + +Este trabalho investiga o impacto da otimização em múltiplas camadas de infraestrutura sobre o desempenho de uma aplicação SaaS de pequeno porte, abrangendo o ajuste de parâmetros do SGBD, a refatoração de consultas SQL, a comparação entre sistemas de arquivos e a compilação customizada do código-fonte do MariaDB. A premissa é que a aplicação combinada dessas técnicas permite reduzir a infraestrutura contratada (\textit{downscaling}) sem perda de desempenho. + +\section{PROBLEMA DE PESQUISA} +Sistemas gerenciadores de bancos de dados relacionais como o MariaDB costumam ser implantados com binários generalistas e configurações que pouco se ajustam ao hardware ou à carga de trabalho específica do ambiente. Van Aken et al.~\cite{vanaken2017} destacam que a busca manual por boas configurações de SGBD exige conhecimento especializado e tempo, o que leva a maioria das implantações a operar com valores-padrão conservadores. Como consequência, observa-se uma subutilização crônica de CPU e memória e uma saturação prematura da vazão de processamento (\textit{throughput}). + +Sob cargas de trabalho com alta concorrência, o sistema degrada: a latência aumenta e o \textit{throughput} cai. Silberschatz et al.~\cite{silberschatz2019} explicam que esse comportamento está ligado à forma como o SGBD gerencia o tráfego entre memória e disco; quando os buffers são mal dimensionados, o acesso ao disco se torna o gargalo. A resposta mais comum no mercado é o superprovisionamento, ou seja, a alocação de mais recursos de hardware (escalabilidade vertical). Trata-se de uma correção pontual: o novo hardware é consumido pela mesma ineficiência de antes, e os custos operacionais crescem de forma proporcional. + +Esse cenário manifesta-se na prática numa empresa de pequeno porte do setor SaaS acompanhada neste estudo. A organização mantém um sistema em produção que, com o crescimento da base de usuários, passou a apresentar gargalos de desempenho no acesso aos dados. A infraestrutura atual opera com sistema operacional de uso geral, sistema de arquivos na configuração padrão e binários pré-compilados do MariaDB obtidos via gerenciador de pacotes. A ausência de ajuste em qualquer uma dessas camadas contribui para picos de latência nos horários de pico e pressionou a empresa a considerar \textit{upgrades} de hardware em nuvem para sustentar a operação. + +Diante desse quadro, formula-se a seguinte questão de pesquisa: quais são os impactos da otimização em múltiplas camadas de infraestrutura, englobando sistema operacional, sistema de arquivos, compilação customizada de binários e parâmetros do SGBD, no desempenho e nos custos operacionais de uma aplicação SaaS de pequeno porte? +\section{OBJETIVOS} +\subsection{Objetivo Geral} +Avaliar o impacto da aplicação de técnicas de otimização em múltiplas camadas de +infraestrutura, englobando a refatoração de consultas, ajustes de parâmetros do +SGBD, escolha do sistema de arquivos, escolha do sistema operacional e +compilação customizada do código-fonte, visando maximizar a vazão de +processamento, minimizar a latência e viabilizar a redução de custos operacionais +(\textit{downscaling}) de uma aplicação SaaS de pequeno porte. +\subsection{Objetivos Específicos} + +Para o alcance do objetivo geral proposto, definem-se os seguintes objetivos específicos: + +\begin{alineas} + \item diagnosticar o cenário atual (\textit{baseline}) da infraestrutura de banco de dados da empresa, aferindo métricas de consumo de recursos, latência e \textit{throughput} sob a carga de trabalho existente; + + \item aplicar técnicas de otimização na camada de banco de dados, compreendendo a refatoração de consultas lentas e o ajuste fino (\textit{tuning}) de parâmetros do SGBD; + + \item comparar o desempenho do banco de dados operando sobre diferentes sistemas de arquivos, como EXT4, XFS e ZFS; + + \item aferir a diferença de performance e consumo de recursos entre a utilização de binários genéricos do SGBD e binários compilados especificamente para a arquitetura de \textit{hardware} do servidor; + + \item analisar os resultados obtidos nos diferentes cenários de teste para determinar a viabilidade técnica e financeira de realizar o \textit{downscaling} da infraestrutura sem comprometer os requisitos de desempenho da aplicação. +\end{alineas} + +\section{JUSTIFICATIVA} + +A computação em nuvem tornou acessível a empresas de qualquer porte o mesmo tipo de infraestrutura antes restrita a grandes corporações. No modelo de precificação por consumo (\textit{pay-as-you-go}), porém, cada recurso provisionado sem necessidade transforma-se em custo recorrente. Armbrust et al.~\cite{armbrust2010} argumentam que a elasticidade da nuvem é economicamente vantajosa apenas quando os recursos são utilizados de forma eficiente; caso contrário, o custo por hora de instâncias ociosas ou subutilizadas supera rapidamente os ganhos obtidos com a escalabilidade. Schwartz et al.~\cite{schwartz2012} observam que a ineficiência na camada de software do banco de dados é uma das principais fontes desse desperdício: o SGBD consome mais CPU e memória do que precisaria se estivesse devidamente configurado, o que eleva o dimensionamento mínimo necessário para manter a aplicação estável. Quando o desempenho degrada, a reação típica é aumentar o plano da instância em nuvem, sem investigar se o problema está na configuração do banco. + +Do ponto de vista tecnológico, a comodidade dos repositórios de pacotes das distribuições Linux consolidou um padrão de implantação baseado em binários genéricos, compilados para máxima compatibilidade em detrimento do desempenho. A literatura e a comunidade de banco de dados abordam com frequência o ajuste fino no nível lógico, como a criação de índices e a reescrita de consultas~\cite{elmasri2011}. Van Aken et al.~\cite{vanaken2021} confirmam que mesmo as ferramentas automáticas de configuração de SGBD se concentram quase exclusivamente em parâmetros internos do banco (como tamanho de cache e estratégia de flush), deixando de lado as camadas subjacentes. O impacto de descer até a camada do sistema de arquivos ou recompilar o SGBD para a arquitetura do servidor ainda é pouco explorado fora de ambientes de alta performance. Para empresas de pequeno porte, esse conhecimento costuma estar simplesmente ausente. + +A relevância prática deste trabalho está em demonstrar, com dados, que um servidor de menor capacidade pode entregar desempenho igual ou superior ao de uma máquina mais robusta caso o software esteja adequadamente otimizado. Para organizações SaaS de pequeno porte, cujas margens são sensíveis a variações nos custos de infraestrutura, o \textit{downscaling} viabilizado pela otimização pode representar a diferença entre operar com folga ou operar no limite. + +\chapter{REFERENCIAL TEÓRICO} +\label{cap:referencial_teorico} + +\section{ARQUITETURA DO SGBD E O MOTOR INNODB} + +O MariaDB é um sistema gerenciador de banco de dados relacional (SGBDR) derivado do MySQL, criado como \textit{fork} comunitário em 2009 após a aquisição do MySQL pela Oracle. Como todo SGBDR que pretende ser utilizado em ambientes de produção, o MariaDB deve garantir as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) para assegurar a integridade das transações mesmo em caso de falhas \cite{silberschatz2019}. Taipalus~\cite{taipalus2023}, em revisão sistemática da literatura sobre desempenho de SGBDs, observa que as diferenças de performance entre sistemas como MySQL, MariaDB e PostgreSQL frequentemente se devem menos ao motor em si e mais à forma como cada um é configurado e implantado. + +O motor de armazenamento padrão do MariaDB desde a versão 10.2 é o InnoDB. O InnoDB organiza os dados em tablespaces e mantém, em memória RAM, um cache chamado \textit{Buffer Pool}, onde armazena cópias de páginas de dados e índices acessados com frequência. Do et al.~\cite{do2008turbocharging} demonstraram que a eficiência do \textit{Buffer Pool} está diretamente ligada ao \textit{throughput} do sistema, sobretudo em cenários de alta concorrência. Quando o tamanho do cache é insuficiente para a carga de trabalho, o motor passa a buscar dados no disco com mais frequência, o que eleva a latência e reduz a vazão de processamento. Schwartz et al.~\cite{schwartz2012} vão além e afirmam que a correta configuração dos componentes de memória do InnoDB é o fator isolado com maior impacto no desempenho de cargas OLTP (\textit{Online Transaction Processing}). + +Além do \textit{Buffer Pool}, o InnoDB utiliza um \textit{Log Buffer} para acumular alterações antes de gravá-las nos arquivos de log em disco, e um \textit{Change Buffer} para cache de modificações pendentes em índices secundários. O funcionamento conjunto desses três mecanismos determina, na prática, o quanto o banco de dados consegue absorver requisições sem recorrer ao acesso direto ao armazenamento persistente. + +\section{OTIMIZAÇÃO LÓGICA E AJUSTE DE PARÂMETROS (\textit{TUNING})} + +O ajuste de parâmetros do SGBD (geralmente chamado de \textit{tuning}) consiste em adaptar as configurações-padrão do sistema à carga de trabalho real e ao hardware disponível. Herodotou et al.~\cite{herodotou2020}, em survey sobre ajuste automático de parâmetros, destacam que a configuração manual de SGBDs é um problema reconhecidamente difícil: o espaço de busca é grande, os parâmetros interagem entre si de forma não trivial e o impacto de cada ajuste depende da carga de trabalho. Elmasri e Navathe~\cite{elmasri2011} observam que o desempenho de um banco de dados pode melhorar de forma considerável apenas com a escolha adequada de índices, o particionamento de tabelas e o ajuste de parâmetros de memória, sem necessidade de investir em hardware novo. + +No MariaDB, dois parâmetros merecem destaque. O primeiro é \texttt{innodb\_buffer\_pool\_size}, que define a porção de RAM dedicada ao cache de dados e índices. Em servidores dedicados ao banco de dados, a recomendação usual é reservar entre 50\% e 80\% da memória total para esse parâmetro~\cite{schwartz2012}. O segundo é \texttt{innodb\_flush\_log\_at\_trx\_commit}, que controla a frequência com que o log de transações é gravado em disco. O valor padrão (1) garante durabilidade completa a cada transação, mas implica uma chamada \texttt{fsync()} por \textit{commit}, o que se torna um gargalo em cargas com volume elevado de escritas. Ao alterar o valor para 2, o log é gravado no buffer do sistema operacional a cada transação e descarregado para o disco aproximadamente uma vez por segundo, reduzindo a latência ao custo de uma pequena janela de risco de perda de dados em caso de falha de energia. + +A refatoração de consultas SQL complementa o ajuste de parâmetros. Consultas mal estruturadas ou que não aproveitam os índices disponíveis sobrecarregam a CPU e geram volume desnecessário de I/O. Segundo Schwartz et al.~\cite{schwartz2012}, a otimização no nível lógico das consultas costuma ser uma das intervenções com melhor custo-benefício, justamente porque não exige mudanças na infraestrutura. + +\section{SISTEMAS DE ARQUIVOS E DESEMPENHO DE I/O} + +Entre o SGBD e o dispositivo de armazenamento físico está o sistema de arquivos, encarregado de organizar, alocar e recuperar os dados gravados em disco. Embora essa camada seja frequentemente negligenciada em implantações de pequeno porte, a escolha do sistema de arquivos pode ter impacto mensurável na latência e na vazão do banco de dados, especialmente sob cargas com muita escrita sequencial ou aleatória. Aghayev et al.~\cite{aghayev2019}, ao analisar o comportamento do Ceph sobre diferentes sistemas de arquivos locais, constataram que as diferenças de desempenho entre EXT4 e XFS em cargas intensivas de I/O são significativas o bastante para comprometer a vazão de todo o sistema de armazenamento distribuído. + +O EXT4 é o sistema de arquivos padrão na maioria das distribuições Linux. Suporta volumes de até 1~EiB e foi projetado com foco em robustez e compatibilidade retroativa com o EXT3~\cite{mathur2007}. Utiliza um mecanismo de \textit{journaling} em modo \textit{ordered} por padrão, que registra os metadados no jornal antes de gravar os dados efetivos. Apesar de estável e amplamente testado, o EXT4 utiliza uma estrutura centralizada de alocação de blocos que, conforme observam Mathur et al.~\cite{mathur2007}, pode gerar contenção em operações concorrentes de escrita. + +O XFS, originalmente desenvolvido pela Silicon Graphics na década de 1990 e hoje mantido pela comunidade do kernel Linux, foi concebido para operar com arquivos e volumes de grande porte. Seu esquema de alocação baseado em extensões (\textit{extents}) e sua capacidade de realizar I/O paralelo o tornam adequado para cargas de trabalho com acesso simultâneo de múltiplos processos~\cite{hellwig2009}. Segundo Hellwig, o XFS escala melhor que o EXT4 em servidores com muitos núcleos de CPU, pois distribui a gestão de metadados entre as unidades de alocação em vez de centralizá-la. + +Já o ZFS, criado pela Sun Microsystems, adota uma arquitetura diferente: unifica o sistema de arquivos e o gerenciador de volumes numa camada única. Dentre seus recursos estão compressão transparente, checksums de dados e metadados, e \textit{snapshots} instantâneos~\cite{rodeh2008}. A arquitetura é descrita por Bonwick e Moore~\cite{bonwick2003} como \textit{copy-on-write}, o que garante consistência em caso de falha, porém adiciona um alto custo em operações de escrita. Há ainda uma questão prática relevante para bancos de dados: o ZFS mantém seu próprio cache em memória, o ARC (\textit{Adaptive Replacement Cache}), que pode competir com o \textit{Buffer Pool} do InnoDB caso os limites de cada um não sejam planejados em conjunto. + +\section{COMPILAÇÃO CUSTOMIZADA} + +As distribuições Linux costumam distribuir o MariaDB em binários compilados com opções conservadoras, de modo a funcionar em qualquer processador x86-64. Isso significa que instruções específicas presentes em processadores recentes (como as extensões AVX2, AVX-512 e SSE) acabam não sendo utilizadas. Drepper~\cite{drepper2007} detalha como o custo dessa abstração não é desprezível: a forma como o compilador organiza o acesso à memória, o alinhamento dos dados e o aproveitamento dos caches da CPU afeta diretamente o desempenho do programa resultante. + +Ao compilar o MariaDB a partir do código-fonte com a flag \texttt{-march=native} no GCC, o binário passa a ser gerado especificamente para a microarquitetura do processador hospedeiro. Isso permite ao compilador emitir instruções vetoriais e organizar o código de modo a explorar melhor a hierarquia de caches (L1, L2 e L3). Drepper~\cite{drepper2007} mostra que o uso correto da localidade de cache pode reduzir o tempo de execução de certas operações em até uma ordem de grandeza, sem exigir nenhum investimento em hardware adicional. + +\chapter{METODOLOGIA CIENTÍFICA} +\label{cap:metodologia_cientifica} + +Este trabalho caracteriza-se como pesquisa aplicada, por buscar solução para um problema concreto de desempenho e custo em um ambiente real de produção. Quanto aos objetivos, enquadra-se como pesquisa exploratória e descritiva: exploratória por investigar alternativas de otimização em diferentes camadas técnicas, e descritiva por documentar e interpretar os efeitos observados em cada intervenção. Quanto à abordagem, é predominantemente quantitativa, pois utiliza indicadores mensuráveis de desempenho e consumo de recursos para fundamentar a análise. + +Quanto ao procedimento técnico, a pesquisa será conduzida como estudo de caso único em uma empresa de pequeno porte do setor SaaS que utiliza MariaDB. Não se trata de experimento com grupo controle; a comparação será intracasos, com referência no cenário inicial (\textit{baseline}) e observação sistemática dos cenários subsequentes. O foco metodológico está na análise contextualizada do caso, com rastreabilidade das mudanças realizadas e seus efeitos sobre desempenho, estabilidade e custo operacional. + +\section{AMBIENTE DE ESTUDO} + +O ambiente de estudo será composto por uma instância isolada da aplicação e do banco de dados, construída para reproduzir as principais características do ambiente de produção sem expor a operação real da empresa a riscos. A base de dados utilizada nos testes será uma cópia controlada da base real ou uma massa equivalente, preservando volume, cardinalidade das tabelas, distribuição de registros e padrões de relacionamento. Quando houver dados sensíveis, estes deverão ser anonimizados antes da execução dos experimentos. + +Para garantir comparabilidade entre os testes, serão registrados os principais elementos do ambiente: versão do MariaDB, versão do sistema operacional, kernel, quantidade de CPU, memória RAM, tipo de armazenamento, sistema de arquivos, parâmetros de montagem, configuração do SGBD e características da carga de trabalho. Alterações nesses elementos ocorrerão apenas quando fizerem parte do cenário avaliado. + +\section{PROCEDIMENTOS DO ESTUDO DE CASO} + +O estudo de caso será organizado em etapas sucessivas. A primeira etapa consistirá na caracterização e medição do cenário atual, utilizando a configuração existente da aplicação, do sistema operacional, do sistema de arquivos e dos binários do MariaDB. Essa medição formará o \textit{baseline} contra o qual os demais cenários serão comparados. + +Na sequência, serão avaliados cenários de otimização lógica, ajuste de parâmetros do SGBD, comparação entre sistemas de arquivos e compilação customizada do MariaDB. Para isolar variáveis, cada cenário modificará apenas um fator técnico por vez, mantendo constantes carga de trabalho, massa de dados, hardware, versão de software e janela de observação. Ao final, será avaliado um cenário consolidado, reunindo as otimizações com melhor relação entre desempenho, estabilidade e custo. + +As etapas do estudo serão as seguintes: + +\begin{alineas} + \item medir o \textit{baseline} da infraestrutura atual, coletando métricas de desempenho e consumo de recursos sob carga representativa; + + \item identificar consultas SQL de maior custo por meio de logs, métricas do SGBD e comportamento observado na aplicação; + + \item aplicar refatorações em consultas e ajustes de índices, medindo o impacto dessas mudanças sobre latência e \textit{throughput}; + + \item ajustar parâmetros do MariaDB, com foco em memória, persistência de logs, concorrência e comportamento do InnoDB; + + \item comparar o desempenho do banco de dados sobre diferentes sistemas de arquivos, especialmente EXT4, XFS e ZFS, mantendo constantes a carga de trabalho e os demais componentes do ambiente; + + \item compilar o MariaDB a partir do código-fonte com opções voltadas à arquitetura do servidor e comparar os resultados com os binários genéricos distribuídos pelos repositórios da distribuição Linux; + + \item executar um teste de \textit{downscaling}, reduzindo os recursos da infraestrutura e verificando se a configuração otimizada mantém desempenho igual ou superior ao cenário inicial. +\end{alineas} + +\section{CARGA DE TRABALHO, CONTROLE DAS VARIÁVEIS E COLETA DE DADOS} + +A carga de trabalho utilizada nos testes deverá representar o uso real da aplicação. Para isso, serão consideradas as consultas mais frequentes, as consultas mais lentas, a proporção entre operações de leitura e escrita e o nível de concorrência observado no ambiente da empresa. O mesmo perfil de carga será aplicado em todos os cenários do estudo, permitindo comparação direta dos resultados. + +Antes de cada medição, o ambiente será preparado para reduzir variações externas, incluindo reinicialização controlada dos serviços quando necessário, verificação da integridade da base e aplicação das mesmas condições iniciais de teste. Cada cenário deverá passar por um período de aquecimento, para estabilização de caches e conexões, seguido por um período de medição. As execuções serão repetidas para reduzir o efeito de flutuações ocasionais, e os resultados serão consolidados por estatísticas descritivas (média, mediana, desvio-padrão e percentis). + +As variáveis independentes do estudo serão os fatores de intervenção técnica (consulta/indexação, parâmetros do SGBD, sistema de arquivos e tipo de binário). As variáveis dependentes serão as métricas de desempenho, consumo e custo. Como variáveis de controle, manter-se-ão constantes hardware, versão do kernel, versão do MariaDB, volume da base, perfil de carga, duração das medições e instrumentos de coleta. + +As principais métricas coletadas serão: + +\begin{alineas} + \item latência média, mediana e percentis de resposta das operações avaliadas; + + \item \textit{throughput}, expresso em requisições ou transações processadas por unidade de tempo; + + \item uso de CPU, memória RAM e \textit{swap}; + + \item volume de leitura e escrita em disco, IOPS e tempo de espera por I/O; + + \item indicadores internos do MariaDB, como uso do \textit{Buffer Pool}, consultas lentas, bloqueios e taxa de acerto de cache; + + \item custo estimado da infraestrutura necessária para sustentar cada cenário. +\end{alineas} + +\section{ANÁLISE DOS RESULTADOS} + +A análise dos resultados será realizada por comparação percentual em relação ao \textit{baseline}. Para cada cenário, serão observadas as variações de latência, \textit{throughput}, consumo de recursos e custo estimado. Uma otimização será considerada tecnicamente vantajosa quando reduzir latência ou consumo de recursos sem comprometer a estabilidade do sistema e sem degradar a vazão de processamento. + +O critério central de avaliação será a viabilidade do \textit{downscaling}. Assim, além de identificar o cenário com maior desempenho absoluto, o estudo buscará determinar se a combinação das otimizações permite operar em uma infraestrutura menor mantendo níveis de desempenho equivalentes ou superiores ao ambiente inicial. Caso esse resultado seja alcançado, será calculada a economia potencial com base na diferença de custo entre a infraestrutura original e a infraestrutura otimizada. + +Por fim, serão discutidas as limitações do estudo, especialmente aquelas relacionadas à especificidade da aplicação analisada, ao perfil da carga de trabalho, ao hardware disponível e ao fato de que resultados obtidos em um ambiente SaaS de pequeno porte podem não se repetir integralmente em sistemas com outras características. Ainda assim, o método proposto permitirá avaliar de forma objetiva o impacto prático das otimizações em múltiplas camadas e sua contribuição para a redução de custos operacionais. + +\section{ALINHAMENTO ENTRE OBJETIVOS ESPECÍFICOS E AVALIAÇÃO} + +Para assegurar que todos os objetivos específicos sejam contemplados metodologicamente, a Tabela~\ref{tab:objetivos-metodos} relaciona cada objetivo ao respectivo procedimento e critério de avaliação. + +\begin{table}[htb] + \caption{Relação entre objetivos específicos, procedimentos e avaliação} +\label{tab:objetivos-metodos} + \begin{tabular}{|p{0.30\textwidth}|p{0.34\textwidth}|p{0.28\textwidth}|} + \hline + \textbf{Objetivo específico} & \textbf{Como será atingido} & \textbf{Como será avaliado} \\ + \hline + Diagnosticar o \textit{baseline} da infraestrutura & Coleta inicial padronizada de métricas sob carga representativa & Linha de base validada por repetição e estabilidade das medições \\ + \hline + Aplicar otimização na camada de banco de dados & Refatoração de consultas lentas, ajuste de índices e \textit{tuning} de parâmetros do MariaDB & Variação de latência, \textit{throughput}, uso de CPU/RAM e métricas internas do InnoDB \\ + \hline + Comparar sistemas de arquivos (EXT4, XFS, ZFS) & Execução da mesma carga em ambientes equivalentes, alterando apenas o sistema de arquivos & Diferença percentual em latência, IOPS, tempo de espera de I/O e vazão \\ + \hline + Comparar binários genéricos e compilados & Compilação customizada do MariaDB para a arquitetura do servidor e execução de testes equivalentes & Ganho/perda de desempenho e consumo de recursos por cenário \\ + \hline + Analisar viabilidade técnica e financeira do \textit{downscaling} & Consolidação das melhores otimizações e teste com redução de recursos computacionais & Manutenção de desempenho mínimo com menor custo mensal estimado \\ + \hline + \end{tabular} + \legend{Fonte: elaboração do autor (2026).} +\end{table} + +\postextual +\bibliography{ref} + +\end{document} blob - /dev/null blob + 0d71f08b5918e0fdcc5b0755b16209bff84ef3ec (mode 644) --- /dev/null +++ main.bak3 @@ -0,0 +1,239 @@ +\documentclass[ + 12pt, % Entire doc font size + oneside, % Capítulos começam em página ímpar + a4paper, % Tamanho do papel + english, % Idioma adicional para hifenização + brazil % O último idioma é o principal do documento +]{abntex2} + +% --- Pacotes Básicos --- +\usepackage{helvet} +\usepackage[T1]{fontenc} +\usepackage[utf8]{inputenc} +\usepackage{indentfirst} +\usepackage{color} +\usepackage{graphicx} +\usepackage{microtype} + +\usepackage[alf]{abntex2cite} + +\titulo{OTIMIZAÇÃO MULTICAMADAS NO MARIADB} +\autor{ANDRÉ MAZZOTTI BERTACHINI} +\local{CAÇADOR} +\data{2026} +\orientador{Prof. Dr. Cristiano Mesquita Garcia} +\coorientador{Prof. Dr. Paulo Roberto Cordova} +\instituicao{INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DE SANTA CATARINA \par CÂMPUS CAÇADOR} +\tipotrabalho{Monografia} + +\definecolor{blue}{RGB}{41,5,195} +\hypersetup{ + pdftitle={\@title}, + pdfauthor={\@author}, + pdfsubject={\imprimirpreambulo}, + pdfcreator={LaTeX with abnTeX2}, + pdfkeywords={MariaDB}{Infraestrutura}{Downscaling}{abntex2}, + colorlinks=true, + linkcolor=blue, + citecolor=blue, + urlcolor=blue +} + +\begin{document} +\selectlanguage{brazil} +\frenchspacing + +\imprimircapa +\imprimirfolhaderosto + +\begin{resumo} + Este trabalho investiga, em uma aplicação SaaS de pequeno porte, como otimizações em múltiplas camadas da infraestrutura de dados podem melhorar desempenho e reduzir custos operacionais. O estudo será conduzido por meio de estudo de caso único, com coleta de métricas antes e depois de intervenções planejadas na camada de banco de dados (refatoração de consultas e ajuste de parâmetros), no sistema de arquivos e no processo de compilação do MariaDB. A análise será quantitativa, com comparação de latência, vazão de processamento, consumo de recursos e custo estimado de infraestrutura em cenários comparáveis. Como resultado esperado, busca-se identificar combinações de otimização tecnicamente viáveis para sustentar a carga da aplicação com menor capacidade computacional, preservando estabilidade e qualidade de serviço. + + \textbf{Palavras-chave}: MariaDB; otimização; desempenho; custos operacionais; estudo de caso. +\end{resumo} + +\pdfbookmark[0]{\contentsname}{toc} +\tableofcontents* +\cleardoublepage + +\textual +\pagestyle{simple} + +\chapter{INTRODUÇÃO} +Bancos de dados relacionais estão no núcleo de praticamente toda aplicação web. No setor de \textit{Software as a Service} (SaaS), onde a infraestrutura é faturada por consumo, a eficiência com que o sistema gerenciador de banco de dados (SGBD) utiliza CPU, memória e disco reflete-se nos custos operacionais da empresa. O MariaDB, \textit{fork} comunitário do MySQL mantido pela MariaDB Corporation e pela comunidade, é um dos SGBDs mais empregados nesse cenário. A maioria das implantações, no entanto, utiliza binários pré-compilados distribuídos pelos repositórios das distribuições Linux, com configurações-padrão pensadas para compatibilidade ampla em vez de desempenho. Van Aken et al.~\cite{vanaken2017} demonstram que a configuração de um SGBD é um problema de alta complexidade e que os valores-padrão raramente são adequados para a carga de trabalho real, o que leva a um desperdício de processamento e memória que poderia ser evitado. + +Este trabalho investiga o impacto da otimização em múltiplas camadas de infraestrutura sobre o desempenho de uma aplicação SaaS de pequeno porte, abrangendo o ajuste de parâmetros do SGBD, a refatoração de consultas SQL, a comparação entre sistemas de arquivos e a compilação customizada do código-fonte do MariaDB. A premissa é que a aplicação combinada dessas técnicas permite reduzir a infraestrutura contratada (\textit{downscaling}) sem perda de desempenho. + +\section{PROBLEMA DE PESQUISA} +Sistemas gerenciadores de bancos de dados relacionais como o MariaDB costumam ser implantados com binários generalistas e configurações que pouco se ajustam ao hardware ou à carga de trabalho específica do ambiente. Van Aken et al.~\cite{vanaken2017} destacam que a busca manual por boas configurações de SGBD exige conhecimento especializado e tempo, o que leva a maioria das implantações a operar com valores-padrão conservadores. Como consequência, observa-se uma subutilização crônica de CPU e memória e uma saturação prematura da vazão de processamento (\textit{throughput}). + +Sob cargas de trabalho com alta concorrência, o sistema degrada: a latência aumenta e o \textit{throughput} cai. Silberschatz et al.~\cite{silberschatz2019} explicam que esse comportamento está ligado à forma como o SGBD gerencia o tráfego entre memória e disco; quando os buffers são mal dimensionados, o acesso ao disco se torna o gargalo. A resposta mais comum no mercado é o superprovisionamento, ou seja, a alocação de mais recursos de hardware (escalabilidade vertical). Trata-se de uma correção pontual: o novo hardware é consumido pela mesma ineficiência de antes, e os custos operacionais crescem de forma proporcional. + +Esse cenário manifesta-se na prática numa empresa de pequeno porte do setor SaaS acompanhada neste estudo. A organização mantém um sistema em produção que, com o crescimento da base de usuários, passou a apresentar gargalos de desempenho no acesso aos dados. A infraestrutura atual opera com sistema operacional de uso geral, sistema de arquivos na configuração padrão e binários pré-compilados do MariaDB obtidos via gerenciador de pacotes. A ausência de ajuste em qualquer uma dessas camadas contribui para picos de latência nos horários de pico e pressionou a empresa a considerar \textit{upgrades} de hardware em nuvem para sustentar a operação. + +Diante desse quadro, formula-se a seguinte questão de pesquisa: quais são os impactos da otimização em múltiplas camadas de infraestrutura, englobando sistema operacional, sistema de arquivos, compilação customizada de binários e parâmetros do SGBD, no desempenho e nos custos operacionais de uma aplicação SaaS de pequeno porte? +\section{OBJETIVOS} +\subsection{Objetivo Geral} +Avaliar o impacto da aplicação de técnicas de otimização em múltiplas camadas de +infraestrutura, englobando a refatoração de consultas, ajustes de parâmetros do +SGBD, escolha do sistema de arquivos, escolha do sistema operacional e +compilação customizada do código-fonte, visando maximizar a vazão de +processamento, minimizar a latência e viabilizar a redução de custos operacionais +(\textit{downscaling}) de uma aplicação SaaS de pequeno porte. +\subsection{Objetivos Específicos} + +Para o alcance do objetivo geral proposto, definem-se os seguintes objetivos específicos: + +\begin{alineas} + \item diagnosticar o cenário atual (\textit{baseline}) da infraestrutura de banco de dados da empresa, aferindo métricas de consumo de recursos, latência e \textit{throughput} sob a carga de trabalho existente; + + \item aplicar técnicas de otimização na camada de banco de dados, compreendendo a refatoração de consultas lentas e o ajuste fino (\textit{tuning}) de parâmetros do SGBD; + + \item comparar o desempenho do banco de dados operando sobre diferentes sistemas de arquivos, como EXT4, XFS e ZFS; + + \item aferir a diferença de performance e consumo de recursos entre a utilização de binários genéricos do SGBD e binários compilados especificamente para a arquitetura de \textit{hardware} do servidor; + + \item analisar os resultados obtidos nos diferentes cenários de teste para determinar a viabilidade técnica e financeira de realizar o \textit{downscaling} da infraestrutura sem comprometer os requisitos de desempenho da aplicação. +\end{alineas} + +\section{JUSTIFICATIVA} + +A computação em nuvem tornou acessível a empresas de qualquer porte o mesmo tipo de infraestrutura antes restrita a grandes corporações. No modelo de precificação por consumo (\textit{pay-as-you-go}), porém, cada recurso provisionado sem necessidade transforma-se em custo recorrente. Armbrust et al.~\cite{armbrust2010} argumentam que a elasticidade da nuvem é economicamente vantajosa apenas quando os recursos são utilizados de forma eficiente; caso contrário, o custo por hora de instâncias ociosas ou subutilizadas supera rapidamente os ganhos obtidos com a escalabilidade. Schwartz et al.~\cite{schwartz2012} observam que a ineficiência na camada de software do banco de dados é uma das principais fontes desse desperdício: o SGBD consome mais CPU e memória do que precisaria se estivesse devidamente configurado, o que eleva o dimensionamento mínimo necessário para manter a aplicação estável. Quando o desempenho degrada, a reação típica é aumentar o plano da instância em nuvem, sem investigar se o problema está na configuração do banco. + +Do ponto de vista tecnológico, a comodidade dos repositórios de pacotes das distribuições Linux consolidou um padrão de implantação baseado em binários genéricos, compilados para máxima compatibilidade em detrimento do desempenho. A literatura e a comunidade de banco de dados abordam com frequência o ajuste fino no nível lógico, como a criação de índices e a reescrita de consultas~\cite{elmasri2011}. Van Aken et al.~\cite{vanaken2021} confirmam que mesmo as ferramentas automáticas de configuração de SGBD se concentram quase exclusivamente em parâmetros internos do banco (como tamanho de cache e estratégia de flush), deixando de lado as camadas subjacentes. O impacto de descer até a camada do sistema de arquivos ou recompilar o SGBD para a arquitetura do servidor ainda é pouco explorado fora de ambientes de alta performance. Para empresas de pequeno porte, esse conhecimento costuma estar simplesmente ausente. + +A relevância prática deste trabalho está em demonstrar, com dados, que um servidor de menor capacidade pode entregar desempenho igual ou superior ao de uma máquina mais robusta caso o software esteja adequadamente otimizado. Para organizações SaaS de pequeno porte, cujas margens são sensíveis a variações nos custos de infraestrutura, o \textit{downscaling} viabilizado pela otimização pode representar a diferença entre operar com folga ou operar no limite. + +\chapter{REFERENCIAL TEÓRICO} +\label{cap:referencial_teorico} + +\section{ARQUITETURA DO SGBD E O MOTOR INNODB} + +O MariaDB é um sistema gerenciador de banco de dados relacional (SGBDR) derivado do MySQL, criado como \textit{fork} comunitário em 2009 após a aquisição do MySQL pela Oracle. Como todo SGBDR que pretende ser utilizado em ambientes de produção, o MariaDB deve garantir as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) para assegurar a integridade das transações mesmo em caso de falhas \cite{silberschatz2019}. Taipalus~\cite{taipalus2023}, em revisão sistemática da literatura sobre desempenho de SGBDs, observa que as diferenças de performance entre sistemas como MySQL, MariaDB e PostgreSQL frequentemente se devem menos ao motor em si e mais à forma como cada um é configurado e implantado. + +O motor de armazenamento padrão do MariaDB desde a versão 10.2 é o InnoDB. O InnoDB organiza os dados em tablespaces e mantém, em memória RAM, um cache chamado \textit{Buffer Pool}, onde armazena cópias de páginas de dados e índices acessados com frequência. Do et al.~\cite{do2008turbocharging} demonstraram que a eficiência do \textit{Buffer Pool} está diretamente ligada ao \textit{throughput} do sistema, sobretudo em cenários de alta concorrência. Quando o tamanho do cache é insuficiente para a carga de trabalho, o motor passa a buscar dados no disco com mais frequência, o que eleva a latência e reduz a vazão de processamento. Schwartz et al.~\cite{schwartz2012} vão além e afirmam que a correta configuração dos componentes de memória do InnoDB é o fator isolado com maior impacto no desempenho de cargas OLTP (\textit{Online Transaction Processing}). + +Além do \textit{Buffer Pool}, o InnoDB utiliza um \textit{Log Buffer} para acumular alterações antes de gravá-las nos arquivos de log em disco, e um \textit{Change Buffer} para cache de modificações pendentes em índices secundários. O funcionamento conjunto desses três mecanismos determina, na prática, o quanto o banco de dados consegue absorver requisições sem recorrer ao acesso direto ao armazenamento persistente. + +\section{OTIMIZAÇÃO LÓGICA E AJUSTE DE PARÂMETROS (\textit{TUNING})} + +O ajuste de parâmetros do SGBD (geralmente chamado de \textit{tuning}) consiste em adaptar as configurações-padrão do sistema à carga de trabalho real e ao hardware disponível. Herodotou et al.~\cite{herodotou2020}, em survey sobre ajuste automático de parâmetros, destacam que a configuração manual de SGBDs é um problema reconhecidamente difícil: o espaço de busca é grande, os parâmetros interagem entre si de forma não trivial e o impacto de cada ajuste depende da carga de trabalho. Elmasri e Navathe~\cite{elmasri2011} observam que o desempenho de um banco de dados pode melhorar de forma considerável apenas com a escolha adequada de índices, o particionamento de tabelas e o ajuste de parâmetros de memória, sem necessidade de investir em hardware novo. + +No MariaDB, dois parâmetros merecem destaque. O primeiro é \texttt{innodb\_buffer\_pool\_size}, que define a porção de RAM dedicada ao cache de dados e índices. Em servidores dedicados ao banco de dados, a recomendação usual é reservar entre 50\% e 80\% da memória total para esse parâmetro~\cite{schwartz2012}. O segundo é \texttt{innodb\_flush\_log\_at\_trx\_commit}, que controla a frequência com que o log de transações é gravado em disco. O valor padrão (1) garante durabilidade completa a cada transação, mas implica uma chamada \texttt{fsync()} por \textit{commit}, o que se torna um gargalo em cargas com volume elevado de escritas. Ao alterar o valor para 2, o log é gravado no buffer do sistema operacional a cada transação e descarregado para o disco aproximadamente uma vez por segundo, reduzindo a latência ao custo de uma pequena janela de risco de perda de dados em caso de falha de energia. + +A refatoração de consultas SQL complementa o ajuste de parâmetros. Consultas mal estruturadas ou que não aproveitam os índices disponíveis sobrecarregam a CPU e geram volume desnecessário de I/O. Segundo Schwartz et al.~\cite{schwartz2012}, a otimização no nível lógico das consultas costuma ser uma das intervenções com melhor custo-benefício, justamente porque não exige mudanças na infraestrutura. + +\section{SISTEMAS DE ARQUIVOS E DESEMPENHO DE I/O} + +Entre o SGBD e o dispositivo de armazenamento físico está o sistema de arquivos, encarregado de organizar, alocar e recuperar os dados gravados em disco. Embora essa camada seja frequentemente negligenciada em implantações de pequeno porte, a escolha do sistema de arquivos pode ter impacto mensurável na latência e na vazão do banco de dados, especialmente sob cargas com muita escrita sequencial ou aleatória. Aghayev et al.~\cite{aghayev2019}, ao analisar o comportamento do Ceph sobre diferentes sistemas de arquivos locais, constataram que as diferenças de desempenho entre EXT4 e XFS em cargas intensivas de I/O são significativas o bastante para comprometer a vazão de todo o sistema de armazenamento distribuído. + +O EXT4 é o sistema de arquivos padrão na maioria das distribuições Linux. Suporta volumes de até 1~EiB e foi projetado com foco em robustez e compatibilidade retroativa com o EXT3~\cite{mathur2007}. Utiliza um mecanismo de \textit{journaling} em modo \textit{ordered} por padrão, que registra os metadados no jornal antes de gravar os dados efetivos. Apesar de estável e amplamente testado, o EXT4 utiliza uma estrutura centralizada de alocação de blocos que, conforme observam Mathur et al.~\cite{mathur2007}, pode gerar contenção em operações concorrentes de escrita. + +O XFS, originalmente desenvolvido pela Silicon Graphics na década de 1990 e hoje mantido pela comunidade do kernel Linux, foi concebido para operar com arquivos e volumes de grande porte. Seu esquema de alocação baseado em extensões (\textit{extents}) e sua capacidade de realizar I/O paralelo o tornam adequado para cargas de trabalho com acesso simultâneo de múltiplos processos~\cite{hellwig2009}. Segundo Hellwig, o XFS escala melhor que o EXT4 em servidores com muitos núcleos de CPU, pois distribui a gestão de metadados entre as unidades de alocação em vez de centralizá-la. + +Já o ZFS, criado pela Sun Microsystems, adota uma arquitetura diferente: unifica o sistema de arquivos e o gerenciador de volumes numa camada única. Dentre seus recursos estão compressão transparente, checksums de dados e metadados, e \textit{snapshots} instantâneos~\cite{rodeh2008}. A arquitetura é descrita por Bonwick e Moore~\cite{bonwick2003} como \textit{copy-on-write}, o que garante consistência em caso de falha, porém adiciona um alto custo em operações de escrita. Há ainda uma questão prática relevante para bancos de dados: o ZFS mantém seu próprio cache em memória, o ARC (\textit{Adaptive Replacement Cache}), que pode competir com o \textit{Buffer Pool} do InnoDB caso os limites de cada um não sejam planejados em conjunto. + +\section{COMPILAÇÃO CUSTOMIZADA} + +As distribuições Linux costumam distribuir o MariaDB em binários compilados com opções conservadoras, de modo a funcionar em qualquer processador x86-64. Isso significa que instruções específicas presentes em processadores recentes (como as extensões AVX2, AVX-512 e SSE) acabam não sendo utilizadas. Drepper~\cite{drepper2007} detalha como o custo dessa abstração não é desprezível: a forma como o compilador organiza o acesso à memória, o alinhamento dos dados e o aproveitamento dos caches da CPU afeta diretamente o desempenho do programa resultante. + +Ao compilar o MariaDB a partir do código-fonte com a flag \texttt{-march=native} no GCC, o binário passa a ser gerado especificamente para a microarquitetura do processador hospedeiro. Isso permite ao compilador emitir instruções vetoriais e organizar o código de modo a explorar melhor a hierarquia de caches (L1, L2 e L3). Drepper~\cite{drepper2007} mostra que o uso correto da localidade de cache pode reduzir o tempo de execução de certas operações em até uma ordem de grandeza, sem exigir nenhum investimento em hardware adicional. + +\chapter{METODOLOGIA CIENTÍFICA} +\label{cap:metodologia_cientifica} + +Este trabalho caracteriza-se como pesquisa aplicada, por buscar solução para um problema concreto de desempenho e custo em um ambiente real de produção. Quanto aos objetivos, enquadra-se como pesquisa exploratória e descritiva: exploratória por investigar alternativas de otimização em diferentes camadas técnicas, e descritiva por documentar e interpretar os efeitos observados em cada intervenção. Quanto à abordagem, é predominantemente quantitativa, pois utiliza indicadores mensuráveis de desempenho e consumo de recursos para fundamentar a análise. + +Quanto ao procedimento técnico, a pesquisa será conduzida como estudo de caso único em uma empresa de pequeno porte do setor SaaS que utiliza MariaDB. Não se trata de experimento com grupo controle; a comparação será intracasos, com referência no cenário inicial (\textit{baseline}) e observação sistemática dos cenários subsequentes. O foco metodológico está na análise contextualizada do caso, com rastreabilidade das mudanças realizadas e seus efeitos sobre desempenho, estabilidade e custo operacional. + +\section{AMBIENTE DE ESTUDO} + +O ambiente de estudo será composto por uma instância isolada da aplicação e do banco de dados, construída para reproduzir as principais características do ambiente de produção sem expor a operação real da empresa a riscos. A base de dados utilizada nos testes será uma cópia controlada da base real ou uma massa equivalente, preservando volume, cardinalidade das tabelas, distribuição de registros e padrões de relacionamento. Quando houver dados sensíveis, estes deverão ser anonimizados antes da execução dos experimentos. + +Para garantir comparabilidade entre os testes, serão registrados os principais elementos do ambiente: versão do MariaDB, versão do sistema operacional, kernel, quantidade de CPU, memória RAM, tipo de armazenamento, sistema de arquivos, parâmetros de montagem, configuração do SGBD e características da carga de trabalho. Alterações nesses elementos ocorrerão apenas quando fizerem parte do cenário avaliado. + +\section{PROCEDIMENTOS DO ESTUDO DE CASO} + +O estudo de caso será organizado em etapas sucessivas. A primeira etapa consistirá na caracterização e medição do cenário atual, utilizando a configuração existente da aplicação, do sistema operacional, do sistema de arquivos e dos binários do MariaDB. Essa medição formará o \textit{baseline} contra o qual os demais cenários serão comparados. + +Na sequência, serão avaliados cenários de otimização lógica, ajuste de parâmetros do SGBD, comparação entre sistemas de arquivos e compilação customizada do MariaDB. Para isolar variáveis, cada cenário modificará apenas um fator técnico por vez, mantendo constantes carga de trabalho, massa de dados, hardware, versão de software e janela de observação. Ao final, será avaliado um cenário consolidado, reunindo as otimizações com melhor relação entre desempenho, estabilidade e custo. + +As etapas do estudo serão as seguintes: + +\begin{alineas} + \item medir o \textit{baseline} da infraestrutura atual, coletando métricas de desempenho e consumo de recursos sob carga representativa; + + \item identificar consultas SQL de maior custo por meio de logs, métricas do SGBD e comportamento observado na aplicação; + + \item aplicar refatorações em consultas e ajustes de índices, medindo o impacto dessas mudanças sobre latência e \textit{throughput}; + + \item ajustar parâmetros do MariaDB, com foco em memória, persistência de logs, concorrência e comportamento do InnoDB; + + \item comparar o desempenho do banco de dados sobre diferentes sistemas de arquivos, especialmente EXT4, XFS e ZFS, mantendo constantes a carga de trabalho e os demais componentes do ambiente; + + \item compilar o MariaDB a partir do código-fonte com opções voltadas à arquitetura do servidor e comparar os resultados com os binários genéricos distribuídos pelos repositórios da distribuição Linux; + + \item executar um teste de \textit{downscaling}, reduzindo os recursos da infraestrutura e verificando se a configuração otimizada mantém desempenho igual ou superior ao cenário inicial. +\end{alineas} + +\section{CARGA DE TRABALHO, CONTROLE DAS VARIÁVEIS E COLETA DE DADOS} + +A carga de trabalho utilizada nos testes deverá representar o uso real da aplicação. Para isso, serão consideradas as consultas mais frequentes, as consultas mais lentas, a proporção entre operações de leitura e escrita e o nível de concorrência observado no ambiente da empresa. O mesmo perfil de carga será aplicado em todos os cenários do estudo, permitindo comparação direta dos resultados. + +Antes de cada medição, o ambiente será preparado para reduzir variações externas, incluindo reinicialização controlada dos serviços quando necessário, verificação da integridade da base e aplicação das mesmas condições iniciais de teste. Cada cenário deverá passar por um período de aquecimento, para estabilização de caches e conexões, seguido por um período de medição. As execuções serão repetidas para reduzir o efeito de flutuações ocasionais, e os resultados serão consolidados por estatísticas descritivas (média, mediana, desvio-padrão e percentis). + +As variáveis independentes do estudo serão os fatores de intervenção técnica (consulta/indexação, parâmetros do SGBD, sistema de arquivos e tipo de binário). As variáveis dependentes serão as métricas de desempenho, consumo e custo. Como variáveis de controle, manter-se-ão constantes hardware, versão do kernel, versão do MariaDB, volume da base, perfil de carga, duração das medições e instrumentos de coleta. + +As principais métricas coletadas serão: + +\begin{alineas} + \item latência média, mediana e percentis de resposta das operações avaliadas; + + \item \textit{throughput}, expresso em requisições ou transações processadas por unidade de tempo; + + \item uso de CPU, memória RAM e \textit{swap}; + + \item volume de leitura e escrita em disco, IOPS e tempo de espera por I/O; + + \item indicadores internos do MariaDB, como uso do \textit{Buffer Pool}, consultas lentas, bloqueios e taxa de acerto de cache; + + \item custo estimado da infraestrutura necessária para sustentar cada cenário. +\end{alineas} + +\section{ANÁLISE DOS RESULTADOS} + +A análise dos resultados será realizada por comparação percentual em relação ao \textit{baseline}. Para cada cenário, serão observadas as variações de latência, \textit{throughput}, consumo de recursos e custo estimado. Uma otimização será considerada tecnicamente vantajosa quando reduzir latência ou consumo de recursos sem comprometer a estabilidade do sistema e sem degradar a vazão de processamento. + +O critério central de avaliação será a viabilidade do \textit{downscaling}. Assim, além de identificar o cenário com maior desempenho absoluto, o estudo buscará determinar se a combinação das otimizações permite operar em uma infraestrutura menor mantendo níveis de desempenho equivalentes ou superiores ao ambiente inicial. Caso esse resultado seja alcançado, será calculada a economia potencial com base na diferença de custo entre a infraestrutura original e a infraestrutura otimizada. + +Por fim, serão discutidas as limitações do estudo, especialmente aquelas relacionadas à especificidade da aplicação analisada, ao perfil da carga de trabalho, ao hardware disponível e ao fato de que resultados obtidos em um ambiente SaaS de pequeno porte podem não se repetir integralmente em sistemas com outras características. Ainda assim, o método proposto permitirá avaliar de forma objetiva o impacto prático das otimizações em múltiplas camadas e sua contribuição para a redução de custos operacionais. + +\section{ALINHAMENTO ENTRE OBJETIVOS ESPECÍFICOS E AVALIAÇÃO} + +Para assegurar que todos os objetivos específicos sejam contemplados metodologicamente, a Tabela~\ref{tab:objetivos-metodos} relaciona cada objetivo ao respectivo procedimento e critério de avaliação. + +\begin{table}[htb] + \caption{Relação entre objetivos específicos, procedimentos e avaliação} + \label{tab:objetivos-metodos} + \begin{tabular}{|p{0.30\textwidth}|p{0.34\textwidth}|p{0.28\textwidth}|} + \hline + \textbf{Objetivo específico} & \textbf{Como será atingido} & \textbf{Como será avaliado} \\ + \hline + Diagnosticar o \textit{baseline} da infraestrutura & Coleta inicial padronizada de métricas sob carga representativa & Linha de base validada por repetição e estabilidade das medições \\ + \hline + Aplicar otimização na camada de banco de dados & Refatoração de consultas lentas, ajuste de índices e \textit{tuning} de parâmetros do MariaDB & Variação de latência, \textit{throughput}, uso de CPU/RAM e métricas internas do InnoDB \\ + \hline + Comparar sistemas de arquivos (EXT4, XFS, ZFS) & Execução da mesma carga em ambientes equivalentes, alterando apenas o sistema de arquivos & Diferença percentual em latência, IOPS, tempo de espera de I/O e vazão \\ + \hline + Comparar binários genéricos e compilados & Compilação customizada do MariaDB para a arquitetura do servidor e execução de testes equivalentes & Ganho/perda de desempenho e consumo de recursos por cenário \\ + \hline + Analisar viabilidade técnica e financeira do \textit{downscaling} & Consolidação das melhores otimizações e teste com redução de recursos computacionais & Manutenção de desempenho mínimo com menor custo mensal estimado \\ + \hline + \end{tabular} + \fonte{Elaboração do autor (2026).} +\end{table} + +\postextual +\bibliography{ref} + +\end{document} blob - /dev/null blob + 905806b64cca967c332d95b3440b6bc948a13b87 (mode 644) --- /dev/null +++ main.txt @@ -0,0 +1,355 @@ + INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E +TECNOLOGIA DE SANTA CATARINA +CÂMPUS CAÇADOR + + + + +ANDRÉ MAZZOTTI BERTACHINI + + + + +OTIMIZAÇÃO MULTICAMADAS NO MARIADB + + + + + + + + + + + + + + + + + +CAÇADOR +2026 +André Mazzotti Bertachini + + + + + +OTIMIZAÇÃO MULTICAMADAS NO MARIADB + + + + + + +Monografia apresentada ao curso de Sistemas de Informação do Instituto Federal de Santa Catarina, para obtenção do título de bacharel em 2026. + + + +Orientador: Prof. Dr. Cristiano Mesquita Garcia +Co-orientador: Prof. Dr. Paulo Roberto Cordova + + + + + + + + + + + + + +Caçador +2026 +André Mazzotti Bertachini + + + +OTIMIZAÇÃO MULTICAMADAS NO MARIADB + + + +Monografia apresentada ao curso de Sistemas de Informação do Instituto Federal de Santa Catarina, para obtenção do título de bacharel em 2026. + + + + + + +Caçador, 24 de junho de 2026. + + + +__________________________________________ +M.e. Antonio Elizeu da Rocha Neto +Universidade Federal de Lavras + + + + + +__________________________________________ +M.e. Fabiana Mara Rubini +Instituto Federal de Santa Catarina + + + + + +AGRADECIMENTOS + +Agradeço aos meus pais, que, mesmo diante da vida e seus pormenores, me proporcionaram a estrutura necessária para concluir este programa de graduação. + +Agradeço ao meu orientador, Prof. Dr. Cristiano Mesquita Garcia, e ao meu coorientador, Prof. Dr. Paulo Roberto Cordova, pela orientação, paciência e contribuições ao longo da construção deste trabalho. + +Agradeço ao Instituto Federal de Santa Catarina, Câmpus Caçador, pela oportunidade de formação, pelo apoio institucional e pelo conhecimento compartilhado ao longo do curso. + + + + + + + +RESUMO + +Este trabalho investiga o impacto de técnicas de otimização aplicadas ao MariaDB em múltiplas camadas da infraestrutura de dados, com foco no desempenho de um ambiente transacional. A pesquisa caracteriza-se como aplicada, quantitativa e experimental. A metodologia prevê a captura de um perfil de carga derivado de uma aplicação real, incluindo consultas frequentes, consultas lentas, operações de leitura e escrita, concorrência e métricas do SGBD e do sistema operacional. Esse perfil será reproduzido em ambiente controlado sobre uma base anonimizada ou equivalente, permitindo comparar o cenário original, definido como baseline, com cenários otimizados. As intervenções avaliadas incluem ajuste de parâmetros do MariaDB, otimização de consultas e índices, comparação entre sistemas de arquivos e uso de binários customizados compilados para a arquitetura do servidor. A análise será baseada em métricas como vazão, latência, utilização de CPU, memória, operações de entrada e saída em disco e estabilidade operacional. Como resultado esperado, busca-se identificar quais combinações de otimização produzem ganhos mensuráveis de desempenho e melhor aproveitamento dos recursos computacionais, sem comprometer a consistência dos dados ou a estabilidade da aplicação. + +Palavras-chave: MariaDB; Otimização; Desempenho; Infraestrutura. + + + +ABSTRACT + +This work investigates the impact of optimization techniques applied to MariaDB across multiple layers of the data infrastructure, focusing on the performance of a transactional environment. The research is characterized as applied, quantitative, and experimental. The methodology includes capturing a workload profile derived from a real application, including frequent queries, slow queries, read and write operations, concurrency, and metrics from the DBMS and the operating system. This profile will be reproduced in a controlled environment using an anonymized or equivalent database, allowing comparison between the original scenario, defined as the baseline, and optimized scenarios. The evaluated interventions include MariaDB parameter tuning, query and index optimization, comparison between file systems, and the use of custom binaries compiled for the server architecture. The analysis will be based on metrics such as throughput, latency, CPU utilization, memory usage, disk input and output operations, and operational stability. The expected result is to identify which optimization combinations produce measurable performance gains and better use of computational resources without compromising data consistency or application stability. + +Keywords: MariaDB; Optimization; Performance; Infrastructure. + + + +SUMÁRIO + +1 INTRODUÇÃO 15 +1.1 PROBLEMA DE PESQUISA 15 +1.2 OBJETIVOS 17 +1.2.1 Objetivo Geral 17 +1.2.2 Objetivos Específicos 17 +1.3 JUSTIFICATIVA 18 +2 REFERENCIAL TEÓRICO 19 +2.1 BANCOS DE DADOS RELACIONAIS 19 +2.2 ARQUITETURA DO MARIADB 19 +2.3 OTIMIZAÇÃO LÓGICA E AJUSTE DE PARÂMETROS 20 +2.4 SISTEMAS DE ARQUIVOS 21 +2.5 COMPILAÇÃO CUSTOMIZADA 23 +3 METODOLOGIA CIENTÍFICA 27 +3.1 CAPTURA DA CARGA DE TRABALHO 27 +3.2 BASE DE DADOS E AMBIENTE EXPERIMENTAL 28 +3.3 CENÁRIOS EXPERIMENTAIS 29 +3.4 PROCEDIMENTOS PARA EXECUÇÃO DOS TESTES 30 +3.5 MÉTRICAS E ANÁLISE DOS RESULTADOS 31 +3.6 LIMITAÇÕES METODOLÓGICAS 31 +DECLARAÇÃO DE USO DE INTELIGÊNCIA ARTIFICIAL 33 +REFERÊNCIAS 34 + + + + + + +1 INTRODUÇÃO + +Bancos de dados relacionais sustentam grande parte das aplicações web modernas. Em ambientes de produção, a forma como o sistema gerenciador de banco de dados (SGBD) utiliza CPU (Central Processing Unit), memória e disco influencia diretamente o desempenho, a estabilidade e a capacidade de atendimento da aplicação. O MariaDB, fork comunitário do MySQL, é um dos SGBDs empregados nesse contexto: no ranking DB-Engines de junho de 2026, ocupa a 13ª posição geral e a 9ª entre os SGBDs relacionais (DB-ENGINES, 2026). A maioria das instâncias, no entanto, utiliza binários pré-compilados distribuídos pelos repositórios das distribuições Linux, com configurações conservadoras que visam ampla compatibilidade em detrimento do desempenho. Van Aken et al. (2017) demonstram que a configuração de um SGBD é um problema de alta complexidade e que os valores pré-definidos raramente são adequados para a carga de trabalho de um ambiente em produção. Essa inadequação pode resultar em uso pouco eficiente dos recursos computacionais disponíveis. + Este trabalho investiga o impacto de técnicas de otimização aplicadas ao MariaDB em múltiplas camadas de infraestrutura, abrangendo o ajuste de parâmetros do SGBD, a refatoração de consultas SQL (Structured Query Language), a comparação entre sistemas de arquivos e a compilação customizada do código-fonte. A análise será realizada em ambiente controlado, com base em uma carga de trabalho derivada de um contexto real, buscando avaliar ganhos de desempenho, aumento de vazão, redução de latência, melhor uso de recursos computacionais e preservação da estabilidade operacional. + + +1.1 PROBLEMA DE PESQUISA + +Sistemas gerenciadores de bancos de dados relacionais (SGBD), como o MariaDB, costumam ser implantados com binários e configurações generalistas, que nem sempre se ajustam ao hardware disponível ou à carga de trabalho específica do ambiente. Van Aken et al. (2017) destacam que a busca manual por boas configurações de SGBD exige conhecimento especializado e tempo, o que leva muitas implantações a operar com valores conservadores. Como consequência, configurações inadequadas podem levar ao uso ineficiente de CPU, memória e operações de entrada e saída em disco, além de limitar a vazão de processamento em cargas concorrentes. Zhao, Zhou e Li (2023) destacam que o ajuste de parâmetros dos SGBDs é um fator central para o desempenho, pois esses parâmetros influenciam diretamente o comportamento do sistema e a utilização dos recursos disponíveis. + Sob carga de trabalho de alta concorrência, o desempenho do sistema pode se degradar prematuramente: a latência aumenta, a vazão diminui e o banco passa a apresentar maior sensibilidade a gargalos de memória, disco, bloqueios e concorrência interna. Silberschatz, Korth e Sudarshan (2019) explicam que esse comportamento está ligado à forma como o SGBD gerencia o tráfego entre memória e disco. Quando buffers, índices e parâmetros de escrita não estão adequados à carga de trabalho, o acesso ao armazenamento persistente pode se tornar um gargalo relevante. Esse problema manifesta-se com frequência em ambientes reais de produção, nos quais o crescimento do volume de dados, do número de usuários e do nível de concorrência expõe limitações no acesso aos dados. Em muitas implantações, por praticidade de instalação e manutenção, o MariaDB é executado a partir de binários pré-compilados fornecidos pelos repositórios do sistema operacional. Embora essa abordagem garanta estabilidade e ampla compatibilidade, tais binários são compilados com opções genéricas de arquitetura para suportar uma ampla variedade de processadores. Consequentemente, podem deixar de explorar otimizações específicas do hardware, como instruções vetoriais, alinhamento de memória e uso eficiente da hierarquia de caches (Drepper, 2007; Cieslewicz; Ross, 2008). + Diante desse quadro, formula-se a seguinte questão de pesquisa: Quais são os impactos da otimização em múltiplas camadas de infraestrutura, englobando ajuste de parâmetros do SGBD, refatoração de consultas, sistema de arquivos e compilação customizada de binários, no desempenho de um ambiente transacional de pequeno porte? + +1.2 OBJETIVOS + + +1.2.1 Objetivo Geral +Avaliar o impacto da aplicação de técnicas de otimização em múltiplas camadas de infraestrutura do MariaDB, englobando ajuste de parâmetros do SGBD, refatoração de consultas, escolha do sistema de arquivos e compilação customizada do código-fonte, visando aumentar a vazão de processamento, reduzir a latência e preservar a estabilidade operacional. +1.2.2 Objetivos Específicos +Para o alcance do objetivo geral proposto, definem-se os seguintes objetivos específicos: +Diagnosticar o cenário atual (baseline) da infraestrutura de banco de dados sob estudo, aferindo métricas de consumo de recursos, latência e vazão sob a carga de trabalho existente; +Capturar e reproduzir um perfil de carga de trabalho derivado de uma aplicação real, considerando consultas frequentes, consultas lentas, proporção entre leitura e escrita, concorrência e períodos de maior utilização; +Aplicar técnicas de otimização na camada de banco de dados, compreendendo a refatoração de consultas lentas, frequentes ou de maior custo acumulado e o ajuste fino (tuning) de parâmetros do SGBD; +Comparar o desempenho do banco de dados operando sobre diferentes sistemas de arquivos, como EXT4, XFS, BTRFS, ZFS; +Aferir a diferença de desempenho e consumo de recursos entre a utilização de binários genéricos do SGBD e binários compilados especificamente para a arquitetura de hardware do servidor; +Analisar os resultados obtidos nos diferentes cenários de teste, considerando métricas de vazão, latência, consumo de recursos e estabilidade operacional. + + + +1.3 JUSTIFICATIVA +A computação em nuvem tornou acessível a empresas de qualquer porte o mesmo tipo de infraestrutura antes restrita a grandes corporações. No entanto, a facilidade de ampliar recursos computacionais não elimina a necessidade de configurar adequadamente os sistemas que utilizam essa infraestrutura. Em ambientes de bancos de dados, recursos provisionados de maneira inadequada ou utilizados de maneira ineficiente podem mascarar gargalos de desempenho presentes na camada de software. Schwartz et al. (2012) observam que a ineficiência na camada de software do banco de dados pode fazer com que o SGBD consuma mais CPU e memória do que o necessário para determinada carga de trabalho, afetando diretamente a latência, a vazão de processamento e a estabilidade da aplicação. + Do ponto de vista tecnológico, a praticidade oferecida pelos repositórios de pacotes das distribuições Linux consolidou um padrão de implantação baseado em binários genéricos, compilados para maximizar a compatibilidade em detrimento do desempenho. Na literatura e na prática de administração de banco de dados, predominam discussões sobre otimização no nível lógico, como a criação de índices e reescrita de consultas (Elmasri; Navathe, 2011). Mesmo as ferramentas automáticas de configuração de SGBDs concentram-se, em geral, em parâmetros internos do banco, como tamanho de cache e estratégias de flush, deixando em segundo plano as camadas subjacentes (Van Aken et al., 2021). Nesse contexto, o impacto de intervenções no sistema de arquivos ou da recompilação do SGBD para a arquitetura específica do servidor permanece pouco explorada fora de ambientes de alta performance, e em organizações de pequeno porte, esse tipo de conhecimento técnico muitas vezes está ausente. + A relevância prática deste trabalho está em demonstrar, com dados, como diferentes camadas de otimização podem influenciar no desempenho de um ambiente transacional de pequeno porte. Ao avaliar ajustes de parâmetros, refatoração de consultas, sistemas de arquivos e compilação customizada, busca-se identificar combinações capazes de reduzir latência, aumentar vazão, melhorar o uso de CPU, memória e I/O (Input/Output), e preservar a estabilidade operacional do ambiente analisado. +2 REFERENCIAL TEÓRICO + +2.1 BANCOS DE DADOS RELACIONAIS + + Bancos de dados relacionais organizam os dados em relações, usualmente representadas por tabelas compostas por linhas e colunas. Cada linha representa uma ocorrência ou registro, enquanto as colunas representam os atributos armazenados. A associação entre tabelas é normalmente realizada por meio de chaves primárias e chaves estrangeiras, permitindo a representação de vínculos entre as entidades e preservando a integridade referencial dos dados (Elmasri; Navathe, 2011). + O acesso e a manipulação dos dados em bancos relacionais são realizados, em geral, por meio da linguagem SQL (Structured Query Language), utilizada para definição de estruturas, consulta, inserção, atualização e remoção de dados. Em ambientes transacionais, esses sistemas devem garantir propriedades como atomicidade, consistência, isolamento e durabilidade (ACID). Essas propriedades asseguram que as transações sejam executadas de forma confiável, preservando a integridade dos dados mesmo diante de falhas, concorrência ou interrupções no sistema (Silberschatz; Korth; Sudarshan, 2019). + O desempenho de um sistema gerenciador de banco de dados relacional não depende apenas da estrutura lógica dos dados, mas também da forma como o SGBD executa consultas, gerencia índices, controla transações, utiliza memória e realiza operações de entrada e saída em disco. Por isso, em aplicações transacionais, a configuração inadequada do banco de dados pode aumentar a latência, reduzir a vazão de processamento e elevar o consumo de recursos computacionais. + +2.2 ARQUITETURA DO MARIADB + + O MariaDB é um sistema gerenciador de banco de dados (SGBD) relacional derivado do MySQL, criado como fork comunitário do MySQL em 2009, após a aquisição do mesmo pela Oracle. Sua arquitetura é modular e permite o uso de diferentes motores de armazenamento, responsáveis por aspectos como organização dos dados, persistência, controle de concorrência e recuperação de falhas. Taipalus (2023), em revisão sistemática da literatura sobre desempenho de SGBDs, observa que as diferenças de desempenho entre sistemas como MySQL, MariaDB e PostgreSQL se devem menos à arquitetura do motor em si e mais à forma como cada um é configurado e implementado. + O motor de armazenamento padrão do MariaDB desde a versão 10.2 é o InnoDB. O InnoDB organiza os dados em tablespaces e mantém, em memória RAM, um cache chamado Buffer Pool, onde armazena cópias de páginas de dados e índices acessados com frequência. Do et al. (2008) demonstraram que a eficiência do Buffer Pool está diretamente ligada à capacidade de vazão do sistema, sobretudo em cenários de alta concorrência. Quando o tamanho do cache é insuficiente para a carga de trabalho, o motor passa a buscar dados no disco com mais frequência, o que eleva a latência e reduz a vazão de processamento. Schwartz et al. (2012) vão além e afirmam que a correta configuração dos componentes de memória do InnoDB é o fator isolado com maior impacto no desempenho de cargas de trabalho, especialmente as relacionadas a OLTP (Online Transaction Processing). + Além do Buffer Pool, o InnoDB utiliza um Log Buffer para acumular as alterações antes de gravá-las nos arquivos de log em disco, e um Change Buffer para cache de modificações pendentes. O funcionamento conjunto destes três mecanismos de caching determina, na prática, o quanto o banco de dados consegue absorver de requisições sem recorrer ao acesso direto ao armazenamento persistente. + +2.3 OTIMIZAÇÃO LÓGICA E AJUSTE DE PARÂMETROS + + O ajuste de parâmetros do SGBD (geralmente chamado de tuning) consiste em adaptar as configurações do sistema à carga de trabalho e ao hardware disponível. Van Aken et al. (2017; 2021) destacam que a configuração manual de parâmetros é uma tarefa complexa pois envolve grande número de parâmetros, interações não triviais entre eles e efeitos que variam conforme a carga de trabalho. Mesmo assim, Elmasri e Navathe (2011) observam que o desempenho de um banco de dados pode melhorar de forma considerável apenas com a implementação adequada de índices, com o particionamento de tabelas e com o ajuste de parâmetros relacionados aos mecanismos de cache, sem necessidade de aumentar o poder computacional. + No MariaDB, dois parâmetros ilustram bem o impacto das configurações no desempenho do InnoDB. O primeiro é o innodb_buffer_pool_size, que define a porção de memória RAM dedicada ao cache de dados e índices. Em servidores dedicados exclusivamente ao SGBD, é comum configurar esse parâmetro com uma porcentagem elevada da memória RAM disponível, frequentemente entre 50% e 80%, a depender da carga de trabalho e das demais necessidades de memória do sistema (Schwartz et al., 2012). O segundo é o innodb_flush_log_at_trx_commit, que controla a frequência com a qual o redo log é gravado e sincronizado em disco. No valor padrão 1, cada commit envolve gravação e sincronização, o que garante maior durabilidade mas eleva o custo de I/O em cargas de trabalho com muitas escritas. No valor 2, o log é gravado no cache do sistema operacional e sincronizado com o disco aproximadamente uma vez por segundo, o que pode reduzir o overhead de escrita ao custo de uma pequena janela de risco de perda de dados em caso de falha do sistema operacional ou queda de energia. +A refatoração de consultas SQL complementa o ajuste de parâmetros. Consultas mal estruturadas ou que não aproveitam os índices disponíveis sobrecarregam a CPU e geram um volume desnecessário de I/O. A otimização no nível lógico das consultas costuma ser uma das intervenções com menor impacto estrutural, justamente por não exigir mudanças na infraestrutura (Schwartz et al., 2012). + +2.4 SISTEMAS DE ARQUIVOS + + Entre o SGBD e o dispositivo de armazenamento físico está o sistema de arquivos, encarregado de organizar, alocar e recuperar os dados gravados em disco. Embora essa camada seja frequentemente negligenciada, a escolha do sistema de arquivos pode ter impacto mensurável na latência e na vazão do banco de dados, especialmente sob cargas com muita escrita sequencial ou aleatória. Aghayev et al. (2019), ao analisar o comportamento de um sistema de armazenamento distribuído sobre diferentes sistemas de arquivos locais, constataram que as diferenças de desempenho entre EXT4 e XFS em cargas intensivas de I/O são significativas o bastante para comprometer a vazão de toda a infraestrutura. + O EXT4 é amplamente utilizado nas distribuições Linux, suporta volumes de até 1 EiB (exbibyte) e foi projetado com foco em robustez e compatibilidade retroativa com o EXT3. Utiliza um mecanismo de journaling por padrão, que registra metadados antes de gravar os dados efetivamente e apesar de estável e amplamente testado, sua estrutura centralizada de alocação de blocos pode gerar contenção em operações concorrentes de escrita (Mathur et al., 2007). +O XFS, originalmente desenvolvido pela Silicon Graphics na década de 1990 e hoje mantido pela comunidade do kernel Linux, foi concebido para operar com arquivos e volumes de grande porte, utiliza um esquema de alocação baseado em extents, isto é, intervalos contíguos de blocos de armazenamento tratados como uma única entidade, o que reduz metadados e favorece operações sequenciais de leitura e escrita. Sua capacidade de realizar I/O em paralelo o tornam adequado para cargas de trabalho com acesso simultâneo de múltiplos processos. Por conta disso, o XFS escala melhor que o EXT4 em servidores com muitos núcleos de CPU, comuns em ambientes de alta concorrência, pois distribui a gestão das tarefas entre as unidades de alocação em vez de centralizá-las (Hellwig, 2009). +O ZFS, criado pela Sun Microsystems, adota uma arquitetura diferente: unifica o sistema de arquivos e o gerenciador de volumes numa camada única. Dentre os seus recursos estão compressão transparente, checksums de dados e metadados e snapshots instantâneos. A arquitetura é baseada em copy-on-write, o que garante consistência em caso de falha, adicionando porém um elevado custo para operações de escrita (Bonwick; Moore, 2003). Há ainda uma questão relevante para um SGBD: o ZFS mantém seu próprio cache em memória, o ARC (Adaptive Replacement Cache), que pode competir com o Buffer Pool do InnoDB caso os limites de cada um não sejam planejados em conjunto. + O BTRFS, desenvolvido originalmente pela Oracle e integrado ao kernel Linux, é um sistema de arquivos moderno baseado em árvores B, com suporte nativo a snapshots, checksums, compressão transparente e gerenciamento integrado de volumes. Assim como o ZFS, utiliza uma estratégia de copy-on-write, na qual alterações não sobrescrevem diretamente os blocos existentes, mas são gravadas em novos locais antes da atualização dos metadados. Embora esse modelo favoreça consistência e recuperação, pode acabar introduzindo problemas em cargas de escrita intensiva, como as de banco de dados transacionais (Rodeh; Bacik; Mason, 2013). + +2.5 COMPILAÇÃO CUSTOMIZADA + +As distribuições Linux costumam disponibilizar o MariaDB em binários compilados com opções conservadoras, de modo que possam funcionar em diferentes processadores dentro de uma mesma arquitetura. Essa estratégia favorece compatibilidade e facilidade de distribuição, mas limita o uso de recursos específicos presentes em processadores mais recentes, como extensões SSE, AVX2 e AVX-512. O custo dessa generalização não é desprezível, a forma como o compilador organiza instruções, acessos à memória, alinhamento de dados e uso dos caches da CPU pode influenciar diretamente o desempenho do programa resultante (Drepper, 2007). + Ao compilar o MariaDB a partir do código-fonte, torna-se possível gerar binários específicos para a microarquitetura do processador utilizado no servidor. Essa customização pode permitir o uso de instruções específicas da CPU, melhor organização dos blocos de código e aproveitamento mais eficiente da hierarquia de caches L1, L2 e L3. Em sistemas de banco de dados, esse aspecto é relevante porque parte significativa do desempenho depende não apenas das consultas SQL ou dos parâmetros do SGBD, mas também da eficiência com que o binário executa as operações internas repetitivas, como gerenciamento de transações, leitura de páginas, controle de concorrência e processamento de índices. +Na prática, essa customização ocorre por meio de flags do compilador utilizadas durante o processo de compilação. No GCC (GNU Compiler Collection) e Clang, flags como -O2 e -O3 controlam o nível geral de otimização aplicado ao binário. A flag -O2 é mais conservadora e costuma priorizar um equilíbrio entre desempenho, tamanho do binário e estabilidade das otimizações, enquanto o -O3 é mais agressivo, inclui todas as otimizações do -O2 e ativa flags relacionadas à expansão de funções e otimizações adicionais em laços de repetição (Free Software Foundation, 2026). De forma semelhante, a documentação do Clang descreve o -O3 como um nível que, além do -O2 pode habilitar otimizações mais custosas (LLVM Project, 2026). +Entretanto, níveis de otimização mais agressivos nem sempre resultam em melhor desempenho, pois determinadas otimizações do compilador podem aumentar o tamanho do binário, pressionando o cache de instruções. Além disso, existem flags específicas para auxiliar o compilador quanto à arquitetura alvo da compilação, -march pode ser utilizado para habilitar instruções específicas do processador, limitando a portabilidade, e -mtune que permite ajustar a geração de código para determinada arquitetura sem comprometer necessariamente a portabilidade. Assim, a escolha das flags de compilação deve ser tratada como uma variável experimental, a ser validada com a carga de trabalho real do sistema. +Outra técnica relacionada a este tipo de otimização é a Profile-Guided Optimization (PGO). Nessa abordagem, o programa é inicialmente compilado com instrumentação, executado com uma carga de trabalho representativa e, em seguida, recompilado utilizando informações coletadas durante a execução. Com isso, o compilador passa a conhecer quais trechos de código são mais utilizados e pode reorganizar o binário para favorecer os caminhos de execução mais frequentes. Nielsen (2014), ao investigar o desempenho single-threaded do MariaDB, observou que falhas no cache de instruções eram um gargalo relevante e relatou ganho de 44% em um teste read-only com sysbench ao recompilar o binário com PGO. +Gráfico 1 - Comparação de queries por segundo (QPS) com e sem PGO no MariaDB + +Fonte: Elaborado pelo autor com base em Nielsen (2014) + + +Resultados semelhantes também foram apresentados em um benchmark da MariaDB Corporation com MariaDB Enterprise Cluster. Schwenke e Johansson (2015) compararam binários padrão com binários compilados com PGO em cenários de OLTP usando sysbench, observando ganhos consistentes de desempenho sem regressões nos casos testados. Nos três cenários avaliados, ambos os nós em leitura, um nó em leitura e outro em leitura/escrita, e ambos os nós em leitura/escrita os ganhos ficaram em torno de 13% a 15% na conclusão do estudo. Esses resultados indicam que a compilação customizada pode ser uma camada relevante de otimização, especialmente quando combinada com uma carga de trabalho conhecida e repetível. +Gráfico 2 - Ganho médio de desempenho com PGO em cenários OLTP no MariaDB Enterprise Cluster + +Fonte: Elaborado pelo autor com base em Schwenke e Johansson (2015) + + +Entretanto, esse tipo de otimização também apresenta limitações. Binários compilados para uma microarquitetura específica podem perder portabilidade, não sendo adequados para execução em servidores com processadores diferentes. No caso do PGO, os resultados dependem diretamente da qualidade da carga de trabalho utilizada durante a etapa de profiling. Se essa carga não representar o uso real do sistema, o binário otimizado pode favorecer apenas caminhos de execução específicos e não reproduzir os mesmos ganhos em produção. Por outro lado, essa limitação pode ser mitigada quando o profiling acontece com uma carga de trabalho derivada da própria aplicação, utilizando consultas reais, proporções semelhantes entre leitura e escrita, transações típicas e níveis de concorrência próximos aos observados no ambiente de produção. Nesse cenário, o compilador passa a otimizar o MariaDB com base nos caminhos internos frequentemente percorridos pela carga de trabalho real, aumentando a aderência entre o processo de otimização e o comportamento efetivo do sistema. + + +3 METODOLOGIA CIENTÍFICA + +Do ponto de vista metodológico, este trabalho caracteriza-se como uma pesquisa aplicada, de abordagem quantitativa e com delineamento experimental. Conforme Gil (2002), a pesquisa experimental é adequada quando o pesquisador manipula variáveis independentes, controla as condições de observação e verifica os efeitos produzidos sobre variáveis dependentes. Neste trabalho as variáveis independentes correspondem às técnicas de otimização aplicadas ao MariaDB e ao ambiente de execução, enquanto as variáveis dependentes correspondem aos indicadores de desempenho observados, como vazão, latência, utilização de CPU, memória e operações de escrita e leitura em disco. + +3.1 CAPTURA DA CARGA DE TRABALHO + + A carga de trabalho utilizada nos experimentos será derivada de uma aplicação que utiliza MariaDB como SGBD. O objetivo dessa etapa é identificar o comportamento efetivo do banco em produção e transformar esse comportamento em um perfil reproduzível para os testes em ambiente controlado. +Inicialmente serão identificados os períodos de maior utilização do banco de dados, considerando métricas do próprio SGBD (consultas por segundo, número de conexões, etc.) métricas do sistema operacional (uso de CPU, memória, swap, iowait, etc.) e possivelmente métricas da aplicação (requisições por segundo, rotas mais acessadas, etc.) que podem auxiliar nas análises dos momentos em que a carga sobre o SGBD é mais significativa. + Durante a janela de captura, serão coletadas especialmente as consultas executadas pelo SGBD, com atenção especial às consultas mais frequentes, às consultas mais lentas e às consultas com maior custo acumulado para o banco de dados. Também será observada a proporção entre operações de leitura e escrita, o nível de concorrência, e a ocorrência de erros, bloqueios (locks) e timeouts. A captura poderá utilizar recursos nativos do MariaDB, como slow_query_log, performance_schema, SHOW GLOBAL STATUS, SHOW PROCESSLIST, além de ferramentas do próprio sistema operacional e, se necessário, logs ou instrumentação construída temporariamente na camada de aplicação. +As consultas capturadas serão agrupadas por padrão lógico, de modo que consultas estruturalmente equivalentes com parâmetros diferentes não sejam tratadas como consultas distintas. Dados sensíveis eventualmente presentes nos logs, como nomes, documentos, credenciais, identificadores diretos ou parâmetros de negócio, serão removidos ou anonimizados antes da reprodução experimental. +O perfil obtido nessa etapa servirá como referência para os cenários experimentais. Assim, a mesma carga poderá ser aplicada ao ambiente original, definido como baseline, e posteriormente aos cenários otimizados, permitindo comparar o impacto das otimizações. + +3.2 BASE DE DADOS E AMBIENTE EXPERIMENTAL + + Os experimentos serão executados em um ambiente isolado do ambiente de produção, utilizando uma instância do MariaDB e os componentes necessários para a reprodução da carga de trabalho capturada. +A reprodução poderá ocorrer em dois níveis: no nível da aplicação, por meio da execução dos mesmos fluxos funcionais ou endpoints utilizados pelos usuários, preservando regras de negócio, transações, comportamento do pool de conexões e padrões reais de concorrência. No nível SQL, a carga será reproduzida diretamente contra o MariaDB, por meio da execução controlada das consultas e transações capturadas. Essa segunda abordagem permite isolar melhor o desempenho do SGBD e avaliar com maior controle o impacto de otimizações como refatoração de consultas, criação ou ajuste de índices, alteração de parâmetros, troca do sistema de arquivos e uso de binários customizados. A escolha entre os níveis dependerá da viabilidade técnica e do objetivo de cada cenário experimental. Independentemente da abordagem adotada, o mesmo perfil de carga deverá ser aplicado ao baseline e aos cenários otimizados, de modo que os resultados permaneçam comparáveis. + A base de dados utilizada nos testes será uma cópia controlada da base real de produção ou uma base equivalente gerada a partir dela. Essa base deverá preservar, tanto quanto possível, o volume de registros, a cardinalidade das tabelas, a distribuição dos dados e os relacionamentos entre entidades. Dados sensíveis, como nomes, documentos, credenciais, informações pessoais e identificadores diretos, serão removidos ou anonimizados antes da execução dos experimentos, mantendo a consistência referencial necessária para que consultas e transações continuem válidas. + Para garantir a comparabilidade dos resultados, serão registrados os principais elementos do ambiente experimental, incluindo processador, número de núcleos e threads, quantidade de memória RAM, configuração de armazenamento, sistema operacional, versão do kernel, sistema de arquivos, versão do MariaDB, parâmetros do InnoDB e versão da aplicação, quando esta for utilizada na reprodução da carga. Nos cenários envolvendo compilação customizada, também serão registrados o compilador utilizado, as bibliotecas vinculadas e as flags de compilação aplicadas. Esses elementos serão tratados como variáveis de controle. Em cada cenário experimental, apenas a variável relacionada à otimização avaliada deverá ser alterada. Dessa forma, ao comparar diferentes configurações do MariaDB, sistemas de arquivos ou binários compilados, busca-se garantir que as diferenças observadas nos resultados estejam associadas à intervenção testada, e não a outras alterações no ambiente. + +3.3 CENÁRIOS EXPERIMENTAIS + + O primeiro cenário experimental será o baseline, correspondente ao ambiente em sua configuração original. Esse cenário utilizará a base de dados, o perfil de carga e as configurações iniciais do MariaDB antes da aplicação das otimizações. Os resultados obtidos no baseline servirão como referência para comparação com todos os demais cenários. Após a definição do baseline, serão executados cenários nos quais apenas uma variável independente será alterada por vez. Essa separação é necessária para identificar o impacto individual de cada tipo de otimização. Assim, os cenários isolados não serão tratados como etapas cumulativas, mas como comparações diretas contra o baseline, mantendo a mesma base de dados, o mesmo perfil de carga e os mesmos critérios de medição. + O primeiro grupo de intervenções envolverá o ajuste de parâmetros do MariaDB, especialmente configurações relacionadas ao InnoDB, uso de memória, cache, flush de logs, conexões, threads e demais parâmetros que possam influenciar o desempenho sob a carga reproduzida. Essa etapa permitirá avaliar o ganho obtido apenas com a adequação da configuração do SGBD ao ambiente e à carga observada. Ela foi posicionada primeiro por exigir menor intervenção na aplicação e na estrutura lógica das consultas. + O segundo grupo de intervenções envolverá a otimização de consultas e índices, com foco nas consultas identificadas na etapa de captura como mais lentas, mais frequentes ou com maior custo acumulado para o banco de dados. Nessa etapa poderão ser avaliadas alterações como reescrita de consultas SQL, criação, remoção ou ajuste de índices e análise dos planos de execução. O objetivo será verificar o impacto de melhorias na camada lógica de acesso aos dados, mantendo constantes os demais elementos do ambiente. + O terceiro grupo de cenários avaliará o impacto do sistema de arquivos utilizado pelo banco de dados. Quando viável, serão comparados sistemas como EXT4, XFS, BTRFS e ZFS, mantendo constantes o hardware, a versão do MariaDB, a base de dados, o perfil de carga e os parâmetros do SGBD. Essa comparação permitirá observar se a camada de armazenamento influencia a vazão, a latência e o comportamento de operações de leitura e escrita. + O quarto grupo de cenários avaliará o uso de binários customizados do MariaDB. Nesse caso, serão comparados binários genéricos, como os fornecidos pelos repositórios da distribuição, com binários compilados especificamente para a arquitetura do servidor com base no código-fonte. Poderão ser consideradas variações de compilador, flags de otimização e Profile-Guided Optimization (PGO), quando aplicável. + Por fim, será executado um cenário consolidado, reunindo as intervenções que apresentarem melhor resultado individual e que sejam tecnicamente compatíveis entre si. Esse cenário permitirá avaliar o ganho acumulado das otimizações em comparação direta com o baseline, utilizando o mesmo perfil de carga e os mesmos critérios de medição. + +3.4 PROCEDIMENTOS PARA EXECUÇÃO DOS TESTES + +Cada cenário experimental seguirá o mesmo procedimento de execução. Inicialmente, o MariaDB será restaurado para um estado conhecido, garantindo que todos os testes partam das mesmas condições iniciais. Em seguida, serão aplicadas apenas as alterações correspondentes ao cenário avaliado, mantendo constantes as demais variáveis do ambiente. Antes da coleta das métricas, será realizado um período de aquecimento da carga, com o objetivo de estabilizar caches, conexões, estruturas internas do MariaDB e comportamento do sistema operacional. Após esse período, a carga de trabalho será executada durante uma janela fixa de medição, na qual serão coletados os indicadores de desempenho e uso de recursos. +Para reduzir o efeito de variações ocasionais, cada cenário será executado no mínimo três vezes sob as mesmas condições. Quando houver diferença significativa entre execuções repetidas, novas medições deverão ser realizadas ou a causa da variação deverá ser investigada. Os resultados finais de cada cenário serão consolidados a partir das execuções válidas. + +3.5 MÉTRICAS E ANÁLISE DOS RESULTADOS + + As principais métricas analisadas serão vazão, latência e estabilidade operacional. A vazão poderá ser expressa em consultas por segundo (QPS), transações por segundo (TPS) ou requisições processadas por unidade de tempo, conforme a forma de reprodução da carga. A latência será analisada por média, mediana, percentil 95, percentil 99 e valor máximo, pois esses indicadores permitem observar não apenas o comportamento médio, mas também a resposta do sistema sob maior concorrência. Também serão coletadas métricas de uso de recursos do sistema operacional, como utilização de CPU, consumo de memória RAM, uso de swap, operações de leitura e escrita em disco, IOPS, vazão de disco e tempo de espera por I/O. No MariaDB, serão observados indicadores como conexões ativas, threads em execução, consultas lentas, locks, deadlocks, taxa de acerto do InnoDB Buffer Pool, leituras físicas e lógicas de páginas e comportamento de flush. +A análise dos resultados será comparativa, tomando o baseline como referência. Para cada cenário, serão calculadas variações absolutas e percentuais em relação ao ambiente original. Uma intervenção será considerada tecnicamente vantajosa quando produzir ganho consistente em vazão, redução de latência ou aumento da capacidade sustentável do ambiente, sem introduzir erros funcionais, perda de dados ou instabilidade operacional relevante. + +3.6 LIMITAÇÕES METODOLÓGICAS + + Os resultados obtidos serão válidos principalmente para o perfil de carga, volume de dados, versão do MariaDB, hardware, sistema operacional e aplicação utilizados no experimento. Como a carga será derivada de uma aplicação específica, os ganhos observados podem não se repetir integralmente em ambientes com outro modelo de dados, outra distribuição de consultas, outros níveis de concorrência ou padrões diferentes de leitura e escrita. Outra limitação está relacionada à qualidade da captura e da reprodução da carga. Caso o perfil reproduzido não represente adequadamente os momentos de maior uso ou as consultas mais relevantes da aplicação, os resultados poderão favorecer otimizações pouco significativas para o ambiente real. Por isso, a metodologia prevê a identificação prévia dos períodos de maior carga e a utilização do mesmo perfil nos cenários comparados. Por fim, a execução em ambiente isolado e a anonimização dos dados são necessárias para preservar segurança e sigilo, mas podem introduzir pequenas diferenças em relação ao ambiente de produção. Ainda assim, esses cuidados permitem repetir os testes, controlar variáveis e avaliar os efeitos das otimizações sem risco operacional para a aplicação real. + + + + + + + + + + + + + + + + + +DECLARAÇÃO DE USO DE INTELIGÊNCIA ARTIFICIAL + +Declaro que utilizei uma ferramenta de inteligência artificial generativa (Gemini 3.1 Pro) como apoio à organização de ideias, pesquisa de artigos e revisão da redação deste trabalho. O uso do LLM ocorreu exclusivamente como ferramenta auxiliar, sem substituir a análise crítica, a responsabilidade autoral, a definição metodológica e a validação das informações apresentadas. Todo o conteúdo final foi revisado pelo autor, que assume integral responsabilidade por sua precisão, coerência e conformidade acadêmica. + + + + +REFERÊNCIAS + +AGHAYEV, A. et al. File systems unfit as distributed storage backends: lessons learned from building the Ceph storage backend on top of local file systems. In: PROCEEDINGS OF THE 27TH ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES. [S.l.]: ACM, 2019. p. 75-89. + +BONWICK, J.; MOORE, B. ZFS: the last word in file systems. Sun Microsystems, 2003. + +CIESLEWICZ, J.; ROSS, K. A. Database optimizations for modern hardware. Proceedings of the IEEE, v. 96, n. 5, p. 863-878, 2008. DOI: 10.1109/JPROC.2008.917744. + +DB-ENGINES. DB-Engines Ranking. 2026. Disponível em: https://db-engines.com/en/ranking. Acesso em: 11 jun. 2026. + +DO, J. et al. Turbocharging DBMS buffer pool using SSDs. Proceedings of the 2008 ACM SIGMOD, 2008. + +DREPPER, U. What every programmer should know about memory. Red Hat, Inc., 2007. + +ELMASRI, R.; NAVATHE, S. B. Fundamentals of Database Systems. [S.l.]: Pearson Education, 2011. + +FREE SOFTWARE FOUNDATION. Optimize options. In: Using the GNU Compiler Collection (GCC). 2026. Disponível em: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html. Acesso em: 15 jun. 2026. + +HELLWIG, C. XFS: the world's most scalable file system. Linux Symposium, 2009. + +LLVM PROJECT. clang - the Clang C, C++, and Objective-C compiler. Clang documentation, 2026. Disponível em: https://clang.llvm.org/docs/ClangCommandLineReference.html. Acesso em: 15 jun. 2026. + +MATHUR, A. et al. The new ext4 filesystem: current status and future plans. In: PROCEEDINGS OF THE LINUX SYMPOSIUM. [S.l.: s.n.], 2007. v. 2, p. 77-88. + +NIELSEN, Kristian. 40% better single-threaded performance in MariaDB. LiveJournal, 20 jan. 2014. Disponível em: https://kristiannielsen.livejournal.com/17676.html. Acesso em: 14 jun. 2026. + +RODEH, O.; BACIK, J.; MASON, C. BTRFS: The Linux B-tree filesystem. ACM Transactions on Storage, v. 9, n. 3, p. 1-32, 2013. + +SCHWARTZ, B. et al. High Performance MySQL: optimization, backups, and replication. 3. ed. [S.l.]: O'Reilly Media, 2012. + +SCHWENKE, Axel; JOHANSSON, Rasmus. MariaDB Enterprise Cluster Profile-Guided Optimization (PGO) Benchmark. MariaDB Corporation, 2015. Disponível em: https://mariadb.com/files/MariaDBEnteprise-Profile-GuidedOptimization-20150401_0.pdf. Acesso em: 14 jun. 2026. + +SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Database System Concepts. [S.l.]: McGraw-Hill Education, 2019. + +TAIPALUS, T. Database management system performance comparisons: a systematic literature review. Journal of Systems and Software, v. 208, p. 111872, 2023. + +VAN AKEN, D. et al. Automatic database management system tuning through large-scale machine learning. In: PROCEEDINGS OF THE 2017 ACM INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA. [S.l.]: ACM, 2017. p. 1009-1024. + +VAN AKEN, D. et al. An inquiry into machine learning-based automatic configuration tuning services on real-world database management systems. Proceedings of the VLDB Endowment, v. 14, n. 9, p. 1440-1453, 2021. + +ZHAO, X.; ZHOU, X.; LI, G. Automatic Database Knob Tuning: A Survey. IEEE Transactions on Knowledge and Data Engineering, v. 35, n. 12, p. 12470-12490, 2023. DOI: 10.1109/TKDE.2023.3266893 + + + + + + + + blob - /dev/null blob + 6c5e503b99765d992b8f3f49375fccf834911b85 (mode 644) --- /dev/null +++ metodologia.txt @@ -0,0 +1,146 @@ +3 METODOLOGIA + +Do ponto de vista metodológico, este trabalho caracteriza-se como uma pesquisa aplicada, de abordagem quantitativa e com delineamento experimental. Conforme a classificação apresentada por Gil (2002), a pesquisa experimental é adequada quando o pesquisador manipula variáveis independentes, controla as condições de observação e verifica os efeitos produzidos sobre variáveis dependentes. Neste trabalho, as variáveis manipuladas serão as técnicas de otimização aplicadas ao MariaDB e ao ambiente de execução; as variáveis observadas serão indicadores objetivos de desempenho, como vazão, latência, erros, utilização de CPU, memória e entrada/saída em disco. + +A pesquisa não será tratada como estudo de caso, pois o objetivo principal não é narrar ou interpretar um caso organizacional em profundidade, mas testar, em ambiente controlado, o efeito de intervenções técnicas sobre o desempenho de uma aplicação real reproduzida em laboratório. Também não se caracteriza como pesquisa-ação, pois não haverá intervenção colaborativa no ambiente produtivo em uso pela organização. O ambiente de produção servirá como origem da base de dados e da carga de trabalho, mas os experimentos serão executados em uma cópia isolada, de modo a preservar a estabilidade do serviço real e permitir repetição controlada dos testes. + +Por não envolver distribuição aleatória de grupos independentes, o delineamento pode ser descrito como experimental com controle interno por baseline, ou quase-experimental de medidas repetidas. O grupo de controle será o cenário inicial, denominado baseline, composto pela aplicação e pelo MariaDB em sua configuração original, isto é, com o mesmo comportamento observado antes das otimizações. Os grupos experimentais corresponderão aos cenários em que serão aplicadas intervenções específicas, como refatoração de consultas, criação ou ajuste de índices, alteração de parâmetros do SGBD, troca do sistema de arquivos e uso de binários compilados especificamente para a arquitetura do servidor. + +3.1 Contexto real de origem da carga de trabalho + +A carga de trabalho utilizada nos experimentos será derivada de uma aplicação transacional real mantida por uma organização privada de pequeno porte, identificada neste trabalho como Empresa A para preservar sigilo operacional. A Empresa A atua no setor de [informar setor de atuação], está localizada em [cidade/UF] e possui aproximadamente [informar número estimado] funcionários. A aplicação analisada atende aproximadamente [informar número estimado] clientes ou usuários, com média de [informar média] acessos diários e picos de aproximadamente [informar pico] acessos simultâneos ou requisições por minuto. + +Essa descrição tem a finalidade de delimitar o cenário empírico de onde a carga será obtida, sem expor informações sensíveis da organização. O nome da empresa, nomes de clientes, dados pessoais, credenciais, endereços, documentos, valores comerciais e quaisquer identificadores diretos serão omitidos ou anonimizados. Quando necessário, serão apresentados apenas números agregados e aproximados, suficientes para caracterizar o porte do ambiente e justificar a representatividade da carga de trabalho. + +A base de dados usada nos testes será uma cópia controlada da base real de produção ou uma base equivalente gerada a partir dela. Essa base deverá preservar, tanto quanto possível, o volume total de registros, a cardinalidade das tabelas, a distribuição dos dados, os relacionamentos entre entidades e a proporção entre registros ativos, históricos e arquivados. Dados sensíveis deverão ser anonimizados antes de qualquer execução experimental, mantendo consistência referencial para que as consultas e transações continuem válidas. + +3.2 Ambiente experimental + +Os testes serão executados em ambiente isolado da produção, composto por uma instância da aplicação, uma instância do MariaDB e os componentes necessários para reprodução da carga. O isolamento é necessário para permitir repetições, alterar configurações de baixo nível e aplicar otimizações sem afetar usuários reais. Antes do início dos experimentos, serão registrados os principais elementos do ambiente: + +- processador, número de núcleos, threads, frequência base e recursos de microarquitetura relevantes; +- quantidade de memória RAM e configuração de swap; +- tipo de armazenamento, modelo do dispositivo, interface, política de cache e parâmetros de fila; +- sistema operacional, versão do kernel e parâmetros relevantes; +- sistema de arquivos, opções de formatação e opções de montagem; +- versão do MariaDB, motor de armazenamento, configurações do InnoDB e demais parâmetros alterados; +- versão do compilador, flags de compilação e bibliotecas utilizadas nos cenários com binário customizado; +- versão da aplicação e configurações que possam influenciar concorrência, conexões, cache ou pool de threads. + +Esses elementos serão tratados como variáveis de controle. Em cada comparação, apenas a variável independente do cenário avaliado deverá ser alterada. Por exemplo, ao comparar sistemas de arquivos, a mesma base, a mesma carga, o mesmo hardware, a mesma versão do MariaDB e a mesma configuração do SGBD deverão ser mantidos, alterando-se apenas o sistema de arquivos e seus parâmetros diretamente associados. + +3.3 Captura da carga de trabalho + +A carga de trabalho será capturada a partir do uso real da aplicação em produção durante uma janela representativa. A janela de captura deverá incluir períodos de uso normal e períodos de pico; preferencialmente, deverá abranger pelo menos um ciclo completo de operação da organização, como um dia útil completo ou uma semana de uso, conforme a sazonalidade da aplicação. O objetivo da captura não é registrar apenas consultas isoladas, mas reconstruir o perfil de uso do sistema. + +Durante a captura, serão coletados os seguintes elementos: + +- consultas SQL mais frequentes, agrupadas por formato normalizado ou fingerprint; +- consultas SQL mais lentas e consultas com maior custo computacional acumulado; +- proporção entre operações de leitura e escrita; +- volume de transações por unidade de tempo; +- nível de concorrência observado, incluindo conexões simultâneas e requisições simultâneas da aplicação; +- distribuição temporal das requisições, incluindo intervalos entre chamadas e horários de pico; +- parâmetros ou faixas de parâmetros usados nas consultas, com mascaramento de informações sensíveis; +- tempos de resposta observados no banco e, quando possível, na aplicação; +- ocorrência de erros, timeouts, bloqueios, deadlocks e consultas abortadas. + +A captura poderá ser realizada por combinação de fontes, como logs da aplicação, logs de acesso HTTP, slow query log do MariaDB, general log em janela controlada, métricas internas do SGBD, ferramentas de observabilidade já existentes e, se necessário, instrumentação temporária em pontos específicos da aplicação. Quando a captura direta de todas as consultas representar risco operacional ou gerar volume excessivo, será utilizada uma amostragem controlada, desde que preserve a distribuição das operações principais e dos períodos de pico. + +As consultas capturadas serão normalizadas para identificar padrões recorrentes. Valores sensíveis serão removidos, mascarados ou substituídos por valores equivalentes gerados a partir da própria distribuição da base anonimizada. A reprodução deverá preservar a seletividade das consultas, isto é, os parâmetros usados no teste devem produzir quantidades de linhas e planos de execução semelhantes aos observados no ambiente real. + +3.4 Reprodução e ampliação da carga + +A carga capturada será transformada em um roteiro de execução repetível. A reprodução poderá ocorrer em dois níveis. Quando possível, será priorizada a reprodução no nível da aplicação, por meio de chamadas aos mesmos endpoints ou fluxos funcionais usados pelos usuários reais, pois essa abordagem preserva regras de negócio, validações, transações e comportamento do pool de conexões. Quando a reprodução pela aplicação não for viável ou não oferecer controle suficiente, será utilizado replay no nível SQL, com execução das consultas e transações representativas diretamente contra o MariaDB. + +O roteiro de carga deverá preservar: + +- a mistura de operações observada na produção; +- a proporção entre leitura, escrita, atualização e remoção; +- a concorrência entre usuários ou workers; +- a ordem relativa de transações dependentes quando essa ordem for necessária; +- os intervalos médios entre requisições; +- a distribuição de parâmetros e a seletividade das consultas; +- os períodos de aquecimento, pico e estabilização. + +Além da carga equivalente ao uso real, denominada carga 1x, serão executadas cargas ampliadas para identificar o limite de desempenho do ambiente. Essas cargas poderão ser geradas por aumento progressivo da taxa de chegada de requisições, do número de usuários simultâneos ou do número de workers de replay. A ampliação deverá manter a mesma mistura proporcional de operações da carga original. Por exemplo, se a carga real apresentar 80% de leituras e 20% de escritas, as cargas 2x, 4x ou superiores deverão preservar essa proporção, alterando apenas a intensidade. + +Os testes de aumento de carga serão conduzidos até que o sistema atinja saturação. Para este trabalho, considera-se saturação o ponto em que o aumento da concorrência deixa de produzir aumento proporcional de vazão ou passa a gerar degradação acentuada de latência, erros, timeouts, deadlocks, esgotamento de conexões, uso persistente de swap ou espera elevada por I/O. A capacidade máxima sustentável será definida como a maior taxa de QPS ou TPS mantida durante o período de medição sem instabilidade operacional relevante. + +3.5 Cenários experimentais + +O baseline será o primeiro cenário medido. Ele representará o desempenho do ambiente antes das otimizações, usando a configuração atual da aplicação, o binário MariaDB atualmente utilizado, o sistema de arquivos atual e os parâmetros do SGBD em uso. Esse cenário será executado com a carga 1x e com cargas ampliadas até a saturação, produzindo a linha de base de QPS, TPS, latência, erros e uso de recursos. + +Depois do baseline, serão executados cenários experimentais em que cada intervenção será avaliada de forma isolada: + +- otimização de consultas e índices, incluindo reescrita de consultas lentas, eliminação de operações desnecessárias e criação, remoção ou ajuste de índices; +- ajuste de parâmetros do MariaDB, especialmente parâmetros relacionados ao InnoDB, cache, flush, conexões, threads e uso de memória; +- comparação entre sistemas de arquivos, como EXT4, XFS, BTRFS e ZFS, quando suportados pelo ambiente de teste; +- comparação entre binário genérico do MariaDB e binários compilados para o processador alvo, incluindo variações de compilador, flags de arquitetura e Profile Guided Optimization (PGO), quando aplicável. + +Em seguida, será executado um cenário consolidado, reunindo as intervenções que apresentarem melhor resultado individual e que sejam tecnicamente compatíveis entre si. Esse cenário será comparado diretamente com o baseline no mesmo hardware. A pergunta central dessa etapa será: com o hardware X, quantas QPS/TPS o ambiente original sustenta e, com o mesmo hardware X acrescido das otimizações, quantas QPS/TPS o ambiente passa a sustentar? + +O trabalho não terá como objetivo avaliar redução de custo financeiro, economia operacional ou downscaling da infraestrutura. O critério principal será desempenho. Assim, uma otimização poderá ser considerada positiva mesmo que aumente o consumo de CPU, memória ou armazenamento, desde que eleve a vazão, reduza latência ou aumente a capacidade máxima sustentável sem comprometer corretude, consistência dos dados e estabilidade mínima de execução. + +3.6 Procedimento de execução dos testes + +Cada cenário deverá seguir o mesmo procedimento operacional. Inicialmente, a base de dados será restaurada para um estado conhecido. Em seguida, serão aplicadas apenas as configurações correspondentes ao cenário avaliado. Antes da medição, haverá um período de aquecimento para estabilização de cache, conexões e estruturas internas do MariaDB. Após o aquecimento, a carga será executada durante um período fixo de medição. + +Cada cenário será repetido no mínimo três vezes sob as mesmas condições. Quando os resultados apresentarem variação elevada entre repetições, novas execuções deverão ser realizadas ou a causa da variação deverá ser investigada. Sempre que possível, a ordem dos cenários será alternada ou reexecutada para reduzir vieses causados por aquecimento residual, caches do sistema operacional, fragmentação, tarefas de segundo plano ou variações temporais do ambiente. + +Nos cenários envolvendo PGO, a carga usada para gerar o perfil de execução deverá ser representativa da aplicação real. O processo deverá incluir uma etapa de compilação instrumentada, execução da carga de treinamento, coleta dos perfis e recompilação final usando esses perfis. A medição de desempenho do binário final será feita em execução separada da etapa de treinamento, para evitar confundir tempo de profiling com tempo de avaliação. + +3.7 Métricas coletadas + +As métricas principais da pesquisa serão: + +- QPS, isto é, consultas processadas por segundo; +- TPS, isto é, transações processadas por segundo, quando a carga permitir essa medição; +- latência média, mediana, percentil 95, percentil 99 e valor máximo; +- taxa de erros, timeouts, conexões recusadas e transações abortadas; +- capacidade máxima sustentável antes da saturação; +- QPS ou TPS sustentado em cada nível de carga testado; +- latência observada para uma mesma taxa de QPS/TPS em diferentes cenários. + +Também serão coletadas métricas de recursos computacionais: + +- utilização de CPU total e por núcleo; +- tempo de usuário, tempo de sistema, iowait e, quando aplicável, steal time; +- uso de memória RAM, cache do sistema operacional e swap; +- leituras e escritas em disco por segundo; +- throughput de disco em MB/s; +- IOPS de leitura e escrita; +- latência de I/O e tamanho médio das filas de disco; +- uso de rede, quando a carga envolver comunicação entre aplicação e banco em hosts separados. + +No MariaDB, serão observados indicadores internos como: + +- taxa de acerto do InnoDB Buffer Pool; +- leituras físicas e lógicas de páginas; +- páginas sujas e comportamento de flush; +- volume de redo log gerado; +- consultas lentas por período; +- locks, lock waits e deadlocks; +- número de conexões ativas e threads em execução; +- tabelas temporárias em memória e em disco; +- planos de execução das consultas críticas; +- diferenças no comportamento das consultas após alterações de índices ou parâmetros. + +3.8 Análise dos resultados + +A análise será comparativa e quantitativa. Para cada cenário, os resultados serão consolidados por média, mediana, desvio-padrão e percentis, considerando as repetições executadas. Em seguida, serão calculadas variações absolutas e percentuais em relação ao baseline. Os resultados serão apresentados por tabelas e gráficos que relacionem vazão, latência, nível de concorrência e uso de recursos. + +A interpretação não se apoiará em um único indicador. Uma intervenção será considerada tecnicamente vantajosa quando produzir ganho consistente em pelo menos uma métrica principal de desempenho, como aumento de QPS/TPS, redução de latência p95/p99 ou aumento da capacidade máxima sustentável, sem introduzir instabilidade relevante, erros funcionais, perda de dados ou comportamento incompatível com a aplicação. Quando houver conflito entre métricas, a prioridade será dada à capacidade máxima sustentável e à latência em percentis altos, pois esses indicadores representam melhor a experiência sob carga concorrente do que a média isolada. + +Como o foco do trabalho é desempenho sem considerar custo financeiro como critério de decisão, valores monetários não serão utilizados como variável dependente. O consumo de CPU, memória e I/O será analisado para explicar gargalos e limites de saturação, mas não para rejeitar automaticamente uma otimização que demande mais recursos. A pergunta final da análise será qual conjunto de intervenções permite extrair o maior desempenho do hardware testado mantendo a aplicação correta, estável e repetível. + +3.9 Limitações e cuidados metodológicos + +Os resultados obtidos serão válidos principalmente para o perfil de carga, volume de dados, versão do MariaDB, hardware e sistema operacional utilizados no experimento. Como a carga será derivada de uma aplicação real específica, os ganhos observados podem não se repetir integralmente em outros sistemas com distribuição de consultas, concorrência, modelo de dados ou padrões de escrita diferentes. + +Outra limitação está na qualidade da captura e da reprodução da carga. Se a carga reproduzida não representar adequadamente os caminhos mais frequentes e mais custosos da produção, os resultados poderão favorecer otimizações pouco relevantes para o uso real. Por isso, a metodologia prevê a captura de frequência, latência, concorrência, parâmetros e distribuição temporal, além da validação do roteiro de replay contra métricas observadas no ambiente original. + +Por fim, a anonimização dos dados e a execução em ambiente isolado são cuidados necessários para preservar sigilo e segurança. Esses cuidados podem introduzir pequenas diferenças em relação à produção, mas são compensados pela possibilidade de repetir os testes, controlar variáveis e medir os efeitos de cada intervenção sem risco operacional para a organização. + +Referência metodológica: +GIL, Antônio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002. blob - /dev/null blob + be3c7e552b73514e11c3038f9816709839cf4874 (mode 644) --- /dev/null +++ roteiro.md @@ -0,0 +1,534 @@ +# Roteiro de Apresentação — Projeto de TCC + +> **Como usar este roteiro** +> +> - Leia em voz alta marcando o tempo na primeira leitura. +> - Ensaiar **3 vezes** mínimo: uma lendo, uma de cabeça erguido, uma +> cronometrada com o slide aberto. +> - Alvo: **18 minutos** falados (sobram 2 de respiro pra imprevistos). +> - Ritmo-alvo: ~140–150 palavras por minuto. +> - Os trechos entre colchetes `[ ... ]` são **marcações de cena**, não +> para falar. +> - Os trechos em *itálico* são ênfase recomendada (fale mais devagar). + +--- + +## SLIDE 1 — Capa +*Aproximadamente 1 min · ~120 palavras* + +[Mostra o slide de capa. Postura ereta. Olha para a banca antes de falar.] + +> Boa tarde a todos. Sou André Mazzotti Bertachini e apresento meu +> projeto de trabalho de conclusão de curso, intitulado **Otimização +> Multicamadas no MariaDB**. O trabalho é orientado pelo professor +> Doutor Cristiano Mesquita Garcia e co-orientado pelo professor Doutor +> Paulo Roberto Cordova. +> +> A apresentação vai seguir um caminho direto: primeiro o contexto e o +> problema que motivaram o projeto, depois os objetivos e a justificativa, +> uma recapitulação enxuta do referencial teórico, e por fim a +> metodologia — que é onde eu peço mais atenção da banca, porque é a +> parte que define a viabilidade do trabalho. + +[Pausa de 2 segundos. Muda de slide.] + +--- + +## SLIDE 2 — Contexto e Motivação +*Aproximadamente 2 min · ~280 palavras* + +> Antes de falar do problema em si, vale explicar de onde saiu a ideia. +> O MariaDB hoje é um dos sistemas de banco de dados mais usados do +> mundo: no ranking DB-Engines de junho de 2026, aparece em décimo +> terceiro lugar no geral e em nono entre os relacionais. Ou seja, não é +> uma tecnologia de nicho — está em muita produção. +> +> Mas a maioria dessas implantações usa binários pré-compilados, vindos +> dos repositórios da distribuição, com configurações conservadoras. E +> isso tem um preço. +> +> [Olha para a banca.] +> +> Eu trabalho com um banco de dados na empresa em que atuo, e o que me +> chamou atenção foi *quanto recurso esse banco consome além do +> necessário*. Ele roda com configuração padrão, com binário genérico, +> e ainda assim o hardware precisa ser dimensionado com folga. Isso +> custa dinheiro. +> +> Paralelamente, há alguns anos eu uso Gentoo como distribuição pessoal. +> Quem conhece Gentoo sabe que ele é *baseado em compilação a partir do +> código-fonte* — você escolhe as flags, escolhe o alvo da arquitetura, +> e o binário que sobra é específico para a sua máquina. A diferença de +> desempenho entre um binário genérico e um binário ajustado ao hardware +> é visível em várias cargas. +> +> A pergunta que ficou foi: *por que a gente não faz o mesmo com banco +> de dados?* Esse trabalho nasde dessa intersecção — aplicar o +> conhecimento de compilação customizada e de tuning a uma camada, o +> SGBD, que na maioria das implantações ainda opera com valores padrão. + +[Pausa. Muda de slide.] + +--- + +## SLIDE 3 — Problema de Pesquisa +*Aproximadamente 1,5 min · ~200 palavras* + +> O problema, em uma frase, é o seguinte: sistemas relacionais como o +> MariaDB costumam ser implantados com binários e configurações +> generalistas, que não foram pensados para o hardware específico nem +> para a carga específica do ambiente. +> +> [Aponta para os bullets conforme menciona.] +> +> As consequências são conhecidas: uso ineficiente de CPU, memória e +> I/O, vazão limitada em cargas concorrentes, latência crescendo sob +> pressão. E, no caso dos binários genéricos, a gente *não* explora +> instruções específicas do processador — tipo AVX2, AVX-512, alinhamento +> de memória, hierarquia de caches. +> +> A pergunta formal de pesquisa é essa que está no slide: + +[Lê devagar, em tom marcado.] + +> *Quais são os impactos da otimização em múltiplas camadas de +> infraestrutura — ajuste de parâmetros do SGBD, refatoração de +> consultas, sistema de arquivos e compilação customizada — no +> desempenho de um ambiente transacional de pequeno porte?* + +[Pausa de 2 segundos. Deixa a pergunta "pousar".] + +> Esse "múltiplas camadas" é o ponto-chave do trabalho. Não é mais uma +> otimização isolada — é olhar a pilha inteira. + +[Muda de slide.] + +--- + +## SLIDE 4 — Objetivos +*Aproximadamente 1,5 min · ~210 palavras* + +> O objetivo geral é *avaliar o impacto* da aplicação de técnicas de +> otimização em várias camadas do MariaDB, buscando aumentar vazão, +> reduzir latência e preservar estabilidade operacional. Não é só mostrar +> que otimizar funciona — é *quantificar quanto* funciona, por camada. +> +> [Indica os objetivos específicos.] +> +> Os objetivos específicos desdobram isso em passos concretos. O primeiro +> é **diagnosticar o baseline**: medir o ambiente como ele está hoje, em +> vazão, latência e uso de recursos. Sem isso, não tem comparação. +> +> O segundo é **capturar e reproduzir um perfil de carga** derivado de +> uma aplicação real — não um benchmark sintético genérico. +> +> O terceiro e o quarto são as otimizações mais estudadas na literatura: +> **tuning de parâmetros** do SGBD e **refatoração de queries e índices**. +> +> O quinto e o sexto são onde o trabalho diferencia: **comparar sistemas +> de arquivos** e **avaliar binários customizados**. Esses dois grupos é +> que respondem diretamente à minha motivação pessoal. +> +> O último é a **análise dos resultados**, consolidando tudo em termos de +> vazão, latência, recursos e estabilidade. + +[Muda de slide.] + +--- + +## SLIDE 5 — Justificativa +*Aproximadamente 1,5 min · ~200 palavras* + +> A justificativa tem três pontos. +> +> Primeiro: a computação em nuvem tornou a infraestrutura acessível, mas +> *não eliminou* a necessidade de configurar software. Provisionar mais +> CPU e mais memória sem entender o porquê do consumo só mascara o +> problema — e custa caro. Schwartz e colegas, no *High Performance +> MySQL*, mostram que ineficiência na camada do SGBD faz o banco consumir +> mais recursos do que o necessário para uma dada carga. +> +> Segundo: a maior parte da literatura e da prática foca em otimização +> lógica — índices, reescrita de queries. As camadas mais profundas, +> tipo sistema de arquivos e compilação, *quase não aparecem* em +> discussões de pequeno porte. As ferramentas automáticas, tipo +> OtterTune, mexem só em parâmetros internos do SGBD. +> +> Terceiro: a relevância prática. Produzir dados concretos sobre o quanto +> cada camada rende — em um cenário de pequeno porte, com carga real — +> ajuda quem administra banco de dados em condições parecidas a decidir +> onde investir esforço. Não é um estudo teórico; é uma contribuição +> aplicável. + +[Muda de slide.] + +--- + +## SLIDE 6 — Referencial Teórico I — MariaDB e InnoDB +*Aproximadamente 1,5 min · ~200 palavras* + +> Agora uma recapitulação enxuta do referencial teórico. Vou em três +> slides — não tem sentido repetir aqui o que está escrito no texto. +> +> O MariaDB é um *fork comunitário do MySQL*, criado em 2009, depois da +> compra do MySQL pela Oracle. O motor de armazenamento padrão desde a +> versão 10.2 é o **InnoDB**. +> +> O InnoDB tem três componentes principais de memória: +> +> [Aponta cada um no slide.] +> +> O **Buffer Pool**, que é o cache de páginas de dados e índices; o +> **Log Buffer**, que acumula alterações antes de gravar no log em disco; +> e o **Change Buffer**, que cuida de modificações pendentes em índices +> secundários. +> +> Dessas três, a que *realmente* define desempenho é o Buffer Pool. O +> tamanho dele é a variável isolada com maior impacto em OLTP. Se ele é +> pequeno demais pra carga, o motor passa a buscar dados no disco — e aí +> latência sobe e vazão cai. É por isso que o ajuste de memória do InnoDB +> é, segundo Schwartz, *o fator isolado com maior impacto* em cargas +> transacionais. + +[Muda de slide.] + +--- + +## SLIDE 7 — Referencial Teórico II — Tuning e Refatoração +*Aproximadamente 1,5 min · ~200 palavras* + +> A camada seguinte é o tuning — adaptar configurações à carga e ao +> hardware. Dois parâmetros ilustram bem o impacto. +> +> O `innodb_buffer_pool_size` define quanta RAM fica reservada pro cache. +> Em servidor dedicado, é comum configurar entre cinquenta e oitenta por +> cento da memória total, dependendo da carga. +> +> O `innodb_flush_log_at_trx_commit` controla a durabilidade do redo log. +> No valor 1, cada commit grava e sincroniza em disco — mais durável, +> mais caro. No valor 2, o log vai pro cache do sistema operacional e é +> sincronizado uma vez por segundo — mais rápido, com uma pequena janela +> de risco em queda de energia. +> +> A questão é que configurar isso manualmente é *complexo*. Van Aken e +> colegas mostram que existem muitos parâmetros, com interações não +> triviais entre eles — e o efeito de cada um depende da carga. +> +> A refatoração de queries *complementa* o tuning. Uma query mal escrita +> sobrecarrega CPU e gera I/O desnecessário. É uma intervenção de baixo +> impacto estrutural — não mexe na infraestrutura — mas pode render muito. + +[Muda de slide.] + +--- + +## SLIDE 8 — Referencial Teórico III — Sistema de Arquivos e Compilação +*Aproximadamente 2 min · ~280 palavras* + +> Aqui entram as duas camadas que diferenciam o trabalho. +> +> [Indica a coluna de filesystems.] +> +> Entre o SGBD e o disco físico fica o sistema de arquivos. Ele é +> frequentemente negligenciado, mas tem impacto mensurável. Os quatro +> que eu pretendo avaliar cobrem *filosofias diferentes*: +> +> O **EXT4** é o padrão de fato — robusto, amplamente testado, mas com +> estrutura centralizada de alocação, que pode gerar contenção sob +> concorrência. O **XFS** usa *extents*, intervalos contíguos de blocos, +> e faz I/O em paralelo — escala melhor em multicore. O **ZFS** adota +> *copy-on-write*, compressão transparente, checksums, e tem um cache +> próprio, o ARC, que pode competir com o Buffer Pool do InnoDB. O +> **BTRFS** é também copy-on-write, baseado em árvores B, com snapshots +> nativos — mas tem custo elevado em escrita, o que é exatamente o ponto +> sensível pra banco de dados. +> +> [Muda o foco para o lado direito do slide.] +> +> A compilação customizada é a outra camada. Os binários dos repositórios +> são compilados com flags genéricas, pra rodar em qualquer processador +> da família. Compilando a partir do código-fonte, dá pra usar `-O3`, +> `-march=native`, e principalmente **PGO** — *Profile-Guided +> Optimization*. +> +> Os números da literatura são expressivos. Nielsen, em 2014, reportou +> *quarenta e quatro por cento* de ganho de queries por segundo em um +> teste read-only do sysbench, recompilando o MariaDB com PGO. Schwenke e +> Johansson, num benchmark da própria MariaDB Corporation em 2015, +> observaram ganhos consistentes entre *treze e quinze por cento* em +> cenários de OLTP. Não é promessa — é resultado medido. + +[Muda de slide.] + +--- + +## SLIDE 9 — Metodologia I — Caracterização da Pesquisa +*Aproximadamente 1,5 min · ~250 palavras* + +> A partir daqui entra a parte que mais interessa para a banca: a +> metodologia. +> +> Do ponto de vista metodológico, esse trabalho é uma pesquisa +> **aplicada**, **quantitativa** e **experimental**, no sentido clássico +> de Gil (2002). Aplicada porque o objetivo é resolver um problema +> concreto de infraestrutura, não gerar teoria. Quantitativa porque as +> conclusões vão se apoiar em números — vazão, latência, uso de recursos. +> E experimental porque eu manipulo variáveis e meço o efeito. +> +> Pra deixar o desenho claro: as variáveis **independentes** são as +> técnicas de otimização que eu vou ligar e desligar — tuning, +> refatoração de queries, escolha do sistema de arquivos e compilação +> customizada. +> +> As variáveis **dependentes** são o que eu meço para ver o efeito: +> basicamente vazão, latência em vários percentis, e uso de recursos do +> sistema operacional e do próprio MariaDB. +> +> [Pausa. Olha para a banca. Fale mais devagar a próxima frase.] +> +> Mas o ponto que *mais importa* nesse slide — e que sustenta o desenho +> inteiro — são as variáveis **de controle**. Hardware, versão do +> MariaDB, kernel, perfil de carga: tudo isso fica congelado entre +> cenários. Em cada rodada, eu mudo **uma coisa só**. +> +> Sem essa disciplina, *qualquer ganho vira atribuição*: eu nunca +> consigo dizer se foi a otimização que eu fiz ou alguma outra diferença +> que se infiltrou no ambiente. Por isso essa regra: uma variável +> independente por cenário. + +[Muda de slide.] + +--- + +## SLIDE 10 — Metodologia II — Captura da Carga e Ambiente +*Aproximadamente 1,5 min · ~220 palavras* + +> A primeira etapa prática é a **captura da carga**. O objetivo é +> transformar o comportamento real do banco em produção em um perfil +> reproduzível. +> +> Eu vou identificar os períodos de pico — usando métricas do próprio +> SGBD, do sistema operacional e, se viável, da aplicação. Durante essa +> janela, vou coletar as consultas executadas, com atenção especial às +> mais frequentes, às mais lentas e às de maior custo acumulado. Também +> vou observar proporção entre leitura e escrita, nível de concorrência, +> ocorrência de locks e timeouts. +> +> A instrumentação vai usar recursos nativos do MariaDB: `slow_query_log`, +> `performance_schema`, `SHOW GLOBAL STATUS`, `SHOW PROCESSLIST`. +> +> [Pausa curta.] +> +> Um ponto importante: as consultas capturadas serão **agrupadas por +> padrão lógico** — queries estruturalmente equivalentes, só com +> parâmetros diferentes, não serão tratadas como distintas. E todos os +> dados sensíveis — nomes, documentos, credenciais — serão **anonimizados +> antes** da reprodução. +> +> O ambiente experimental é **isolado** do ambiente de produção. Vou +> usar uma cópia controlada da base, preservando volume, cardinalidade e +> distribuição. A reprodução pode ocorrer em dois níveis: no nível da +> aplicação — executando os mesmos fluxos funcionais — ou no nível SQL, +> executando as consultas diretamente contra o MariaDB. A escolha +> depende da viabilidade de cada cenário. + +[Muda de slide.] + +--- + +## SLIDE 11 — Metodologia III — Cenários Experimentais +*Aproximadamente 1,5 min · ~230 palavras* + +> O desenho experimental tem seis blocos. +> +> [Indica o slide à medida que menciona cada bloco.] +> +> O primeiro é o **baseline**, que é o ambiente na configuração original. +> Todo mundo vai ser comparado contra ele. +> +> Em seguida vêm quatro **grupos isolados**, cada um variando uma única +> técnica. O **Grupo 1** é tuning de parâmetros do InnoDB — memória, +> flush, conexões. O **Grupo 2** é refatoração de queries e ajuste de +> índices — olhando especialmente as consultas mais lentas ou mais +> frequentes capturadas na etapa anterior. O **Grupo 3** é a comparação +> entre sistemas de arquivos: EXT4, XFS, BTRFS e ZFS. O **Grupo 4** é a +> compilação customizada — binário genérico contra binário nativo, com +> variação de flags e PGO. +> +> O último é o **cenário consolidado**, que acumula as intervenções que +> deram melhor resultado individual e que forem tecnicamente compatíveis +> entre si. É a resposta pra "o que acontece se eu fizer tudo ao mesmo +> tempo?". +> +> [Pausa. Tom mais marcado.] +> +> É importante deixar claro: os quatro grupos isolados *não são etapas +> cumulativas*. Cada um é uma **comparação direta contra o baseline**. +> Isso é o que permite isolar o efeito de cada técnica. Se eu acumulasse, +> perderia a atribuição. + +[Muda de slide.] + +--- + +## SLIDE 12 — Metodologia IV — Procedimentos e Métricas +*Aproximadamente 1,5 min · ~230 palavras* + +> Cada cenário segue o mesmo procedimento. É uma rotina importante pra +> garantir comparabilidade. +> +> Primeiro eu restauro o MariaDB a um estado conhecido. Depois aplico +> apenas a intervenção daquele cenário. Em seguida vem um **período de +> aquecimento** — pra estabilizar caches, conexões e estruturas internas +> — e só depois vem a janela fixa de medição, quando eu coletor os +> indicadores. +> +> [Tom mais firme.] +> +> Para reduzir variância, cada cenário será executado **no mínimo três +> vezes** sob condições idênticas. Em cenários mais ruidosos — sistemas +> de arquivos e compilação — pretendo fazer cinco. Se houver diferença +> significativa entre execuções repetidas, eu investigo a causa antes de +> seguir. +> +> [Indica as métricas.] +> +> As métricas cobrem três frentes. **Vazão**: queries por segundo e +> transações por segundo. **Latência**: média, mediana, percentil 95, +> percentil 99 e máximo — porque média sozinha esconde a cauda, e em +> concorrência a cauda é o que incomoda. **Recursos**: CPU, memória, +> swap, IOPS, vazão de disco, iowait; e do lado do MariaDB, conexões +> ativas, threads, slow queries, locks, deadlocks, buffer pool hit rate. +> +> A análise é sempre comparativa contra o baseline, em termos absolutos e +> percentuais. + +[Muda de slide.] + +--- + +## SLIDE 13 — Cronograma +*Aproximadamente 1,5 min · ~230 palavras* + +> O cronograma cobre seis meses — de julho a dezembro de 2026 — porque a +> defesa final está prevista para dezembro. +> +> [Percorre a tabela.] +> +> **Julho** é dedicado à captura da carga e à anonimização. **Agosto** é +> a montagem do ambiente experimental e a definição do baseline — é +> quando o trabalho começa a produzir número. +> +> **Setembro** concentra dois grupos: tuning e queries/índices, porque +> são os mais rápidos de iterar. **Outubro** é o grupo de sistemas de +> arquivos — cada um exige refazer o disco, então consome mais tempo. +> **Novembro** é o grupo de compilação customizada e PGO, mais o cenário +> consolidado. +> +> **Dezembro** fica reservado para a redação final e a defesa. +> +> [Pausa. Tom franco, de autocrítica.] +> +> Eu reconheço que é uma janela apertada. Por isso já deixei um **plano +> de mitigação de escopo**: se o tempo apertar, a primeira coisa que +> reduz é o número de variações em G3 — por exemplo, focar só em EXT4 +> contra XFS, que são os mais relevantes pro meu caso. A segunda é +> simplificar G4 — PGO com uma única configuração base, sem explorar +> variações de flags. +> +> O desenho em cenários isolados permite esse corte *sem invalidar o +> restante*. Cada grupo se sustenta sozinho como contribuição. + +[Muda de slide.] + +--- + +## SLIDE 14 — Considerações Finais +*Aproximadamente 1 min · ~150 palavras* + +> Para fechar: o projeto está em fase de aprovação. Os **resultados +> esperados** são três. +> +> Primeiro, **quantificar** o ganho individual de cada camada de +> otimização — não em afirmação genérica, mas em número, contra o +> baseline. +> +> Segundo, **identificar combinações** tecnicamente compatíveis entre as +> camadas — porque nem tudo que funciona isolado funciona junto. +> +> Terceiro, **produzir recomendações aplicáveis** a ambientes +> transacionais de pequeno porte, que é o público que mais sofre com +> configuração padrão e menos acesso tem a conhecimento especializado. +> +> Os próximos passos imediatos são três: a aprovação nesta banca, a +> captura da carga de trabalho na aplicação real, e a montagem do +> ambiente experimental com a definição do baseline. +> +> [Pausa de 2 segundos. Tom mais baixo, mais lento.] +> +> *Obrigado.* Fico à disposição para as perguntas da banca. + +[NÃO diga "obrigado pela atenção" nem "qualquer dúvida estou à +disposição". Já está dito. Silencie e aguarde.] + +--- + +## Considerações gerais de entrega + +**Ritmo** +- Alvo: 18 minutos falados. +- Reserve os 2 minutos finais só para perguntas — não tente encaixar mais + conteúdo. + +**Linguagem corporal** +- Olhe para a banca, não para o slide, ao fazer afirmações fortes + (principalmente na slide 9, 11 e 13). +- Use as mãos para indicar colunas ou itens do slide, mas volte ao + contato visual imediatamente. +- Evite cruzar os braços ou colocar as mãos nos bolsos. + +**Voz** +- Em itálico estão os trechos para *falar mais devagar*. São os pontos + que a banca vai anotar. +- Varie a entonação: narrativa pessoal (slide 2) é mais coloquial; + metodologia (slides 9 a 12) é mais pausada e firme. + +**Transições** +- Não diga "próximo slide". A transição é implícita na fala. Mude o + slide em silêncio e continue falando. + +**Se der branco** +- Respire uma vez. Olhe para o slide. Leia o primeiro bullet em voz + alta. Isso reinicia o raciocínio. +- Ninguém na banca vai perceber que você deu branco se você não disser. + +**Se a banca interromper no meio** +- Pare imediatamente. Ouça a pergunta até o fim. Resposta curta. +- Depois retome de onde parou: "Voltando ao ponto que eu estava + comentando...". + +**Tempo médio por bloco (para autodiagnóstico no ensaio)** +| Bloco | Tempo-alvo | +|--------------------|------------| +| Slides 1–5 | ~7,5 min | +| Slides 6–8 (teoria)| ~5 min | +| Slides 9–12 (metodo)| ~6 min | +| Slides 13–14 | ~2,5 min | +| **Total** | **~21 min** | + +Se passar de 22 minutos no ensaio, corte da teoria, nunca da metodologia. + +--- + +## Checklist final de ensaio + +- [ ] 1ª leitura em voz alta, cronometrando, sem público +- [ ] 2ª leitura de pé, com o slide aberto, marcando onde tropeça +- [ ] 3ª leitura cronometrada, para alguém da família (mesmo que não + entenda o tema — você está treinando fluência, não conteúdo) +- [ ] Conferir nomes e títulos dos orientadores +- [ ] Conferir data real da defesa com a coordenação +- [ ] Preparar uma roupa na véspera +- [ ] PDF de backup em pendrive + no celular + no e-mail +- [ ] Cabo HDMI / adaptador na bolsa na noite anterior +- [ ] Dormir cedo na véspera blob - /dev/null blob + a6054f3fdfef63a82e2998d8666a187f3aa49e37 (mode 644) --- /dev/null +++ slides.md @@ -0,0 +1,364 @@ +# Slides — Projeto de TCC + +> **Como usar:** cada bloco "SLIDE N" abaixo vira UMA slide no Google Slides. +> Copie o título → caixa de título. Copie os bullets → caixa de corpo. +> O bloco "FALAR" é o que você diz (não vai para o slide). +> Tempo-alvo: ~20 min · 14 slides · ~1,4 min/slide. + +--- + +## SLIDE 1 — Capa + +**OTIMIZAÇÃO MULTICAMADAS NO MARIADB** + +André Mazzotti Bertachini + +Orientador: Prof. Dr. Cristiano Mesquita Garcia +Co-orientador: Prof. Dr. Paulo Roberto Cordova + +Instituto Federal de Santa Catarina — Câmpus Caçador +Sistemas de Informação · Junho de 2026 + +**FALAR:** "Boa tarde, sou André Mazzotti Bertachini e apresento meu projeto +de TCC intitulado Otimização Multicamadas no MariaDB, orientado pelo +professor Cristiano e co-orientado pelo professor Cordova." + +--- + +## SLIDE 2 — Contexto e Motivação + +- MariaDB: 13º SGBD no ranking DB-Engines (jun/2026); 9º entre relacionais +- Maioria das implantações usa **binários pré-compilados** com configurações **conservadoras** +- Resultado: hardware subaproveitado, custos elevados, gargalos sob concorrência +- **Motivação prática:** na empresa, o banco consome mais recursos do que o + necessário — configurações padrão, binário genérico +- **Motivação pessoal:** como usuário de Gentoo (distro source-based), vejo + o quanto o ajuste da compilação ao hardware específico pode render +- **Tese:** aplicar conhecimento de tuning + compilação customizada a uma + camada (SGBD) que quase sempre opera com valores padrão + +**FALAR:** Mostre o ângulo pessoal. É o que diferencia seu trabalho. "Eu +quero trazer para o banco de dados algo que faço no Gentoo há anos: compilar +para o hardware certo, com a flag certa, e medir o ganho." + +--- + +## SLIDE 3 — Problema de Pesquisa + +- SGBDs relacionais (como MariaDB) costumam ser implantados com + **binários e configurações generalistas** +- Consequências: + - Uso ineficiente de CPU, memória e I/O + - Vazão limitada em cargas concorrentes + - Latência crescente sob carga + - Binários genéricos não exploram instruções específicas da CPU + (AVX2, AVX-512, alinhamento, caches) + +**Pergunta de pesquisa:** +> *Quais são os impactos da otimização em múltiplas camadas de +> infraestrutura — ajuste de parâmetros do SGBD, refatoração de consultas, +> sistema de arquivos e compilação customizada — no desempenho de um +> ambiente transacional de pequeno porte?* + +**FALAR:** Leia a pergunta verbatim. É o fio condutor de tudo. + +--- + +## SLIDE 4 — Objetivos + +**Objetivo geral** +Avaliar o impacto da aplicação de técnicas de otimização em múltiplas +camadas de infraestrutura do MariaDB, visando aumentar vazão, reduzir +latência e preservar estabilidade operacional. + +**Objetivos específicos** +1. Diagnosticar o **baseline** (vazão, latência, recursos) +2. Capturar e reproduzir perfil de carga derivado de aplicação real +3. Aplicar **tuning** de parâmetros do SGBD +4. Refatorar consultas e ajustar **índices** +5. Comparar **sistemas de arquivos** (EXT4, XFS, BTRFS, ZFS) +6. Avaliar **binários customizados** vs. genéricos +7. Analisar resultados em vazão, latência, recursos e estabilidade + +**FALAR:** Não leia tudo — destaque 1, 2, 6 e 7. Os outros são +autoexplicativos. + +--- + +## SLIDE 5 — Justificativa + +- **Nuvem** tornou infraestrutura acessível, mas **não elimina** a + necessidade de configurar o software +- Ineficiência na camada do SGBD → mais CPU/memória do que o necessário + (Schwartz et al., 2012) +- Maior parte da literatura foca em otimização **lógica** (índices, + queries); camadas mais profundas (FS, compilação) são **pouco exploradas + em pequeno porte** +- Ferramentas automáticas (OtterTune etc.) tratam só parâmetros internos + do SGBD +- **Relevância:** produzir dados concretos sobre o impacto de cada camada + para ambientes transacionais pequenos + +**FALAR:** Conecte com a motivação. "Ninguém discute que índices importam +— mas a camada de compilação e sistema de arquivos fica de fora. É essa +lacuna que este trabalho quer cobrir." + +--- + +## SLIDE 6 — Referencial Teórico I · MariaDB e InnoDB + +- **MariaDB:** fork comunitário do MySQL (2009) +- Motor padrão desde 10.2: **InnoDB** +- Componentes de memória do InnoDB: + - **Buffer Pool** — cache de páginas de dados e índices + - **Log Buffer** — acumula alterações antes do flush + - **Change Buffer** — cache de modificações pendentes +- Configuração de memória do InnoDB = **maior impacto isolado** no + desempenho (Schwartz et al., 2012) +- Buffer Pool insuficiente → mais acesso a disco → latência↑ vazão↓ + (Do et al., 2008) + +**FALAR:** Foque no Buffer Pool. É a única peça que a banca vai cobrar +que você entenda friamente. + +--- + +## SLIDE 7 — Referencial Teórico II · Tuning e Refatoração de Queries + +- **Tuning** = adaptar configurações à carga e ao hardware +- Parâmetros críticos do InnoDB: + - `innodb_buffer_pool_size` — tipicamente 50–80% da RAM em servidor + dedicado + - `innodb_flush_log_at_trx_commit` — durabilidade (1) vs. desempenho (2) +- Configuração manual é **complexa**: muitos parâmetros, interações não + triviais (Van Aken et al., 2017; 2021) +- **Refatoração de SQL** complementa o tuning: + - Consultas mal estruturadas sobrecarregam CPU e geram I/O desnecessário + - Baixo impacto estrutural (não mexe na infra) + +**FALAR:**"Há dois parâmetros que já valem a apresentação inteira: +buffer_pool_size e flush_log_at_trx_commit. São eles que diferenciam uma +instância padrão de uma ajustada." + +--- + +## SLIDE 8 — Referencial Teórico III · Sistema de Arquivos e Compilação + +**Sistemas de arquivos** +- **EXT4** — robusto, compatível, alocação centralizada (contensão sob + concorrência) +- **XFS** — extents, I/O paralelo, escala melhor multicore +- **ZFS** — copy-on-write, compressão, ARC próprio (compete com Buffer + Pool) +- **BTRFS** — copy-on-write, snapshots; custo elevado em escrita + +**Compilação customizada** +- Binários de repositório: `-O2` genérico, sem instruções específicas +- Flags relevantes: `-O2`/`-O3`, `-march=native`, `-mtune` +- **PGO (Profile-Guided Optimization):** + - Nielsen (2014): **+44% QPS** read-only no sysbench + - Schwenke & Johansson (2015): **+13% a +15%** em OLTP + +**FALAR:** Não leia os 4 filesystems — diga só "quatro FS com filosofias +diferentes de journaling e alocação". Reserve o fôlego para o PGO, que é +o coração do seu ângulo pessoal. + +--- + +## SLIDE 9 — Metodologia I · Caracterização da Pesquisa + +- **Aplicada** · **Quantitativa** · **Experimental** (Gil, 2002) +- Variáveis **independentes** (manipuladas): + - Técnicas de otimização (tuning, queries, FS, compilação) +- Variáveis **dependentes** (medidas): + - Vazão (QPS, TPS) + - Latência (média, p95, p99, máxima) + - CPU, memória, swap, I/O, IOPS, iowait + - Estabilidade operacional +- Variáveis **de controle:** hardware, versão do MariaDB, kernel, perfil + de carga — só uma independente é alterada por cenário + +**FALAR:** "A regra de ouro é: cada cenário muda uma coisa só. Sem isso, +qualquer ganho é atribuição." + +--- + +## SLIDE 10 — Metodologia II · Captura da Carga e Ambiente + +**Captura da carga (aplicação real)** +- Identificar períodos de pico (SGBD, SO, aplicação) +- Coletar consultas frequentes, lentas e de maior custo acumulado +- Instrumentação: `slow_query_log`, `performance_schema`, + `SHOW GLOBAL STATUS`, `SHOW PROCESSLIST` +- **Agrupamento por padrão lógico** (não tratar queries equivalentes + como distintas) +- **Anonimização** de dados sensíveis antes da reprodução + +**Ambiente experimental** +- Instância isolada do MariaDB +- Cópia controlada da base de produção (ou equivalente) +- Reprodução em **dois níveis:** aplicação (fluxos reais) e SQL direto + +**FALAR:** Enfatize o isolamento e a anonimização — a banca costuma bater +nesses pontos por questões éticas e de segurança. + +--- + +## SLIDE 11 — Metodologia III · Cenários Experimentais + +- **Baseline:** configuração original — referência para todas as comparações +- **G1 — Tuning:** parâmetros do InnoDB, memória, flush, conexões +- **G2 — Queries e índices:** reescrita, criação/remoção de índices, + análise de planos de execução +- **G3 — Sistemas de arquivos:** EXT4, XFS, BTRFS, ZFS +- **G4 — Compilação customizada:** genérico vs. nativo; variação de flags; + PGO +- **Cenário consolidado:** acumula as intervenções viáveis com melhor + resultado individual + +> Cenários isolados são **comparações diretas** contra o baseline, +> não etapas cumulativas. + +**FALAR:** Repita: isolado contra baseline, consolidado no final. É o +desenho experimental inteiro em uma frase. + +--- + +## SLIDE 12 — Metodologia IV · Procedimentos e Métricas + +**Procedimento por cenário** +1. Restaurar MariaDB a estado conhecido +2. Aplicar apenas a intervenção do cenário +3. **Aquecimento** (estabilizar caches) +4. Janela fixa de medição +5. **No mínimo 3 execuções** sob condições idênticas +6. Investigar variações relevantes + +**Métricas** +- **Vazão:** QPS, TPS +- **Latência:** média, mediana, p95, p99, máx +- **SO:** CPU, memória, swap, IOPS, vazão de disco, iowait +- **MariaDB:** conexões ativas, threads, slow queries, locks, deadlocks, + buffer pool hit rate, leituras físicas/lógicas, flush + +**Análise** comparativa contra baseline (Δ absoluto e percentual) + +**FALAR:**"Pode parecer pouco, mas 3 execuções é o piso — pretendo fazer +5 nos cenários mais ruidosos para reduzir variância." + +--- + +## SLIDE 13 — Cronograma (Jul → Dez 2026) + +| Mês | Atividade | +|---|---| +| Jul | Captura da carga + anonimização | +| Ago | Ambiente experimental + baseline | +| Set | G1 (tuning) + G2 (queries/índices) | +| Out | G3 (sistemas de arquivos) | +| Nov | G4 (compilação customizada + PGO) + cenário consolidado | +| Dez | Redação final + defesa | + +> **Risco identificado:** janela apertada (6 meses). Plano de mitigação: +> se necessário, reduzir variações em G3 (ex.: focar em EXT4 vs. XFS) e +> em G4 (ex.: PGO apenas com uma flag base). + +**FALAR:** Mostre que você sabe que é apertado. Banca valoriza +autocrítica. "Sei que é agressivo — por isso já deixei o plano B de +escopo." + +--- + +## SLIDE 14 — Considerações Finais + +- Projeto em **fase de aprovação** +- **Resultados esperados:** + - Quantificar o ganho individual de cada camada de otimização + - Identificar combinações tecnicamente compatíveis + - Produzir recomendações aplicáveis a ambientes transacionais pequenos +- **Próximos passos imediatos:** + 1. Aprovação do projeto (esta banca) + 2. Captura da carga de trabalho + 3. Montagem do ambiente e definição do baseline + +**Obrigado!** +Aguarda-se perguntas da banca. + +**FALAR:** Não estique. Três bullets, "obrigado", silêncio. Pausa de +2 segundos antes de abrir para perguntas. + +--- + +## REFERÊNCIAS PARA O SLIDE FINAL (se quiser incluir) + +- Schwartz, B. et al. *High Performance MySQL*. 3. ed. O'Reilly, 2012. +- Van Aken, D. et al. Automatic DBMS tuning. *SIGMOD*, 2017. +- Nielsen, K. 40% better single-threaded performance in MariaDB. 2014. +- Schwenke, A.; Johansson, R. MariaDB Enterprise Cluster PGO Benchmark. 2015. +- Silberschatz, A.; Korth, H. F.; Sudarshan, S. *Database System Concepts*. 2019. +- Aghayev, A. et al. File systems unfit as distributed storage backends. *SOSP*, 2019. + +--- + +## APÊNDICE — Perguntas prováveis da banca (prepare respostas) + +> Estas não vão para o slide. São para você treinar antes da defesa. + +1. **"Por que só 3 execuções por cenário?"** + → Piso mínimo; pretendo fazer 5 nos cenários de maior variância (FS, + compilação). Não há teste estatístico formal previsto — reconheço como + limitação. + +2. **"Como você garante que o baseline é comparável aos cenários + otimizados?"** + → Mesma base, mesmo perfil de carga, mesmo hardware, mesmo kernel. + Apenas a variável do cenário muda. + +3. **"PGO precisa de carga representativa. Como você vai garantir isso?"** + → Justamente por isso a captura vem antes (G1–G4 vêm depois). O + profiling vai usar o mesmo perfil reproduzido nos demais cenários. + +4. **"Por que esses 4 filesystems e não outros?"** + → Cobertura de filosofias distintas: journaling clássico (EXT4), + extents paralelos (XFS), copy-on-write com ARC (ZFS), B-tree moderna + (BTRFS). + +5. **"ZFS e BTRFS com copy-on-write não são ruins para banco de dados?"** + → Sim, há custo em escrita. É justamente o que quero **medir** — + quantificar esse custo no meu cenário, não assumir. + +6. **"Isso não é muito amplo para um TCC?"** + → Reconheço o risco. Por isso o desenho em cenários **isolados** permite + cortar grupos sem invalidar o restante. O cronograma já prevê plano de + mitigação de escopo. + +7. **"Você usa IA generativa. Como garantir autoria?"** + → Uso declarado (Gemini 3.1 Pro) como apoio à organização, pesquisa e + revisão. Análise crítica, definição metodológica e validação são + minhas. Conteúdo final revisado integralmente por mim. + +8. **"Qual é a aplicação real que vai fornecer a carga?"** + → [Prepare esta resposta — provavelmente você não pode dar muitos + detalhes, mas diga o setor/tamanho.] + +9. **"Por que MariaDB e não PostgreSQL?"** + → Contexto da empresa usa MariaDB; Taipalus (2023) mostra que + diferenças de desempenho entre SGBDs relacionais modernos dependem + mais de configuração do que de motor. + +10. **"Como vai reportar latência — só média?"** + → Não: média, mediana, p95, p99 e máximo. Média esconde cauda; + percentis mostram comportamento sob concorrência. + +--- + +## Checklist pré-apresentação + +- [ ] Slide 2: confirmar se posso citar a empresa ou se fica anônima +- [ ] Slide 8: gerar Gráficos 1 e 2 (PGO) ou usar imagens originais com + crédito (verificar licença) +- [ ] Slide 13: confirmar data real da defesa com a coordenação +- [ ] Ensaiar cronometrado (alvo 18 min para sobrar 2 de respiro) +- [ ] Preparar 1 slide de backup com a pergunta de pesquisa expandida +- [ ] Levar cabo HDMI / adaptador +- [ ] PDF de backup em pendrive (Google Slides pode falhar)