commit - 15416a7f8afabd2ecc9cc18d2e435db2c5b9d772
commit + 28821ef6c51f82ec6c383a266cc3564273929893
blob - 94db969a0ffbb3f37da149e1299cd270141eedbe
blob + b3c617a55bf292cde351a492779ce54ed5c1b6c7
Binary files main.pdf and main.pdf differ
blob - 84158f433830564e1dc07ee92cacfd6ec28c2fea
blob + 882a6669cbdc93247da63f3429689bdf9c7afda8
--- main.tex
+++ main.tex
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 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.
+
+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}).
+
+\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{DELINEAMENTO DOS EXPERIMENTOS}
+
+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.
+
+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.
+
+As etapas experimentais 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 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.
+
+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.
+
+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.
+
\postextual
\bibliography{ref}
