commit 15416a7f8afabd2ecc9cc18d2e435db2c5b9d772 from: amb date: Thu Apr 23 21:08:05 2026 UTC Finish the literature review commit - 7f7a202666ee49b804c649dd467840a69c6423ba commit + 15416a7f8afabd2ecc9cc18d2e435db2c5b9d772 blob - 27416bf5c052f8a54f40e630c8d331994caa868a blob + 94db969a0ffbb3f37da149e1299cd270141eedbe Binary files main.pdf and main.pdf differ blob - 155b88bf01628b77e1318f4d00d5b6e288d8b9fd blob + 84158f433830564e1dc07ee92cacfd6ec28c2fea --- main.tex +++ main.tex @@ -60,19 +60,18 @@ \pagestyle{simple} \chapter{INTRODUÇÃO} -Na introdução, recomenda-se apresentar o tema do trabalho, contextualizar sua relevância e justificativa, destacar as lacunas de pesquisa existentes, expor o problema de pesquisa e os objetivos do estudo. +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 (SGBD), a exemplo do MariaDB, são comumente implantados com binários generalistas e configurações subotimizadas (carente de citação). A partir deste cenário generalista, observa-se uma frequente subutilização crônica dos recursos de hardware e a 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. 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}). -Submetido a cargas de trabalho de alta concorrência, o sistema sofre com degradação de desempenho e aumento de latência (carente de citação). Este comportamento induz as organizações ao superprovisionamento de infraestrutura (escalabilidade vertical), uma estratégia que mitiga temporariamente o sintoma, mas não resolve a ineficiência estrutural da camada de software, acarretando a elevação injustificada dos custos operacionais (carente de citação). +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 de ineficiência reflete-se diretamente no contexto de uma empresa de pequeno porte do setor de \textit{Software as a Service} (SaaS) analisada neste estudo. A organização possui um sistema em produção que, diante do crescimento da base de usuários, vem apresentando gargalos de performance no acesso aos dados. A atual infraestrutura da empresa opera sobre um sistema operacional de uso geral com sistemas de arquivos em suas configurações padrão, somado a binários pré-compilados genéricos do SGBD. +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. -Essa ausência de adequação em múltiplas camadas resulta em picos de latência durante os horários de maior acesso e forçando a empresa a considerar \textit{upgrades} onerosos de hardware em nuvem para sustentar a operação. - -Diante da problemática de gargalos de desempenho e do alto custo de superprovisionamento em ambientes de banco de dados, formula-se a seguinte questão de pesquisa que guiará este trabalho: 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 de processamento e nos custos operacionais de uma aplicação SaaS de pequeno porte? -\postextual +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 @@ -80,7 +79,7 @@ infraestrutura, englobando a refatoração de consulta 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 -(downscaling) de uma aplicação SaaS de pequeno porte. +(\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: @@ -99,13 +98,48 @@ Para o alcance do objetivo geral proposto, definem-se \section{JUSTIFICATIVA} -A adoção do modelo de computação em nuvem (\textit{Cloud Computing}) democratizou o acesso à infraestrutura para empresas do setor de \textit{Software as a Service} (SaaS). Contudo, o modelo de precificação baseado em consumo (\textit{pay-as-you-go}) transformou a ineficiência da camada de \textit{software} em um dreno financeiro. Segundo \citeonline{CHAVE_DA_CITACAO}, as organizações desperdiçam uma parcela significativa de seus orçamentos de nuvem devido ao provisionamento ocioso e à má configuração de recursos. Diante de gargalos de desempenho em sistemas gerenciadores de bancos de dados, a prática mercadológica mais comum tem sido o superprovisionamento, negligenciando o fato de que a ineficiência estrutural consumirá os novos recursos rapidamente. Nesse cenário, justificar o investimento em otimização de infraestrutura torna-se uma questão de sobrevivência e sustentabilidade financeira para empresas de pequeno porte. +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 das distribuições Linux criou um padrão de implantação de infraestrutura baseado em binários genéricos, projetados para máxima compatibilidade em detrimento da performance. Embora a literatura e o mercado abordem exaustivamente o ajuste fino de SGBDs no nível lógico das consultas \cite{CHAVE_DA_CITACAO}, o impacto prático de descer as camadas da infraestrutura ainda é subutilizado em aplicações de pequeno porte. Substituir ecossistemas de propósito geral por ambientes rigorosamente compilados para a arquitetura de \textit{hardware} hospedeira, aliados ao uso de sistemas de arquivos otimizados para I/O como XFS ou ZFS, representa uma recuperação da eficiência computacional perdida para a generalização do \textit{software}. A pesquisa justifica-se por provar que a otimização de baixo nível extrai um desempenho que o \textit{hardware} já possui, mas que o \textit{software} padrão restringe. +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. -Por fim, a relevância prática deste trabalho reside na sua capacidade de demonstrar a viabilidade técnica do \textit{downscaling}. Ao provar empírica e cientificamente que um servidor de menor capacidade técnica e, consequentemente, de menor custo pode entregar uma vazão de processamento igual ou superior a um servidor mais robusto e mal configurado, esta pesquisa fornecerá um roteiro de boas práticas valioso. Tais achados são críticos para organizações SaaS onde as margens de lucro são sensíveis e os altos custos operacionais de infraestrutura representam um risco à continuidade do negócio \cite{CHAVE_DA_CITACAO}. +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. -% Referências bibliográficas +\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. + +\postextual \bibliography{ref} \end{document} blob - 18568c20417b7d2ee1d88571823df505753b5f24 blob + 0e548223f4d8ed3165274d9a31fb3ccc7395e346 --- ref.bib +++ ref.bib @@ -1,15 +1,129 @@ -@manual{abnt14724, - organization = {Associa{\c{c}}\~ao Brasileira de Normas T\'ecnicas}, - title = {NBR 14724: Informa{\c{c}}\~ao e documenta{\c{c}}\~ao --- Trabalhos acad\^emicos --- Apresenta{\c{c}}\~ao}, - address = {Rio de Janeiro}, - year = {2011}, - subtitle = {Informa{\c{c}}\~ao e documenta{\c{c}}\~ao} +@article{do2008turbocharging, + title={Turbocharging DBMS buffer pool using SSDs}, + author={Do, Jaeyoung and DeWitt, David J and Patel, Jignesh M and others}, + journal={Proceedings of the 2008 ACM SIGMOD}, + year={2008} } -@manual{abnt6023, - organization = {Associa{\c{c}}\~ao Brasileira de Normas T\'ecnicas}, - title = {NBR 6023: Informa{\c{c}}\~ao e documenta{\c{c}}\~ao --- Refer\^encias --- Elabora{\c{c}}\~ao}, - address = {Rio de Janeiro}, - year = {2018}, - subtitle = {Informa{\c{c}}\~ao e documenta{\c{c}}\~ao} +@book{silberschatz2019, + title={Database System Concepts}, + author={Silberschatz, Abraham and Korth, Henry F and Sudarshan, S}, + year={2019}, + publisher={McGraw-Hill Education} } + +@book{elmasri2011, + title={Fundamentals of Database Systems}, + author={Elmasri, Ramez and Navathe, Shamkant B}, + year={2011}, + publisher={Pearson Education} +} + +@article{drepper2007, + title={What every programmer should know about memory}, + author={Drepper, Ulrich}, + journal={Red Hat, Inc}, + year={2007} +} + +@article{hellwig2009, + title={XFS: The world's most scalable file system}, + author={Hellwig, Christoph}, + journal={Linux Symposium}, + year={2009} +} + +@book{schwartz2012, + title={High Performance MySQL: Optimization, Backups, and Replication}, + author={Schwartz, Baron and Zaitsev, Peter and Tkachenko, Vadim and Zawodny, Jeremy}, + year={2012}, + publisher={O'Reilly Media}, + edition={3rd} +} + +@inproceedings{mathur2007, + title={The new ext4 filesystem: current status and future plans}, + author={Mathur, Avantika and Cao, Mingming and Bhattacharya, Suparna and Dilger, Andreas and Joshi, Alex and Lilfschits, Mikhail and Mishra, Amit}, + booktitle={Proceedings of the Linux Symposium}, + volume={2}, + pages={77--88}, + year={2007} +} + +@article{rodeh2008, + title={B-trees, shadowing, and clones}, + author={Rodeh, Ohad}, + journal={ACM Transactions on Storage (TOS)}, + volume={3}, + number={4}, + pages={1--27}, + year={2008}, + publisher={ACM} +} + +@article{bonwick2003, + title={ZFS: The last word in file systems}, + author={Bonwick, Jeff and Moore, Bill}, + journal={Sun Microsystems}, + year={2003} +} + +@article{armbrust2010, + title={A view of cloud computing}, + author={Armbrust, Michael and Fox, Armando and Griffith, Rean and Joseph, Anthony D and Katz, Randy and Konwinski, Andy and Lee, Gunho and Patterson, David and Rabkin, Ariel and Stoica, Ion and Zaharia, Matei}, + journal={Communications of the ACM}, + volume={53}, + number={4}, + pages={50--58}, + year={2010}, + publisher={ACM} +} + +@inproceedings{vanaken2017, + title={Automatic Database Management System Tuning Through Large-scale Machine Learning}, + author={Van Aken, Dana and Pavlo, Andrew and Gordon, Geoffrey J and Zhang, Bohan}, + booktitle={Proceedings of the 2017 ACM International Conference on Management of Data}, + pages={1009--1024}, + year={2017}, + organization={ACM} +} + +@article{taipalus2023, + title={Database management system performance comparisons: A systematic literature review}, + author={Taipalus, Toni}, + journal={Journal of Systems and Software}, + volume={208}, + pages={111872}, + year={2023}, + publisher={Elsevier} +} + +@article{vanaken2021, + title={An inquiry into machine learning-based automatic configuration tuning services on real-world database management systems}, + author={Van Aken, Dana and Yang, Dongsheng and Brillard, Sebastien and Fiorino, Ari and Zhang, Bohan and Bilien, Christian and Pavlo, Andrew}, + journal={Proceedings of the VLDB Endowment}, + volume={14}, + number={9}, + pages={1440--1453}, + year={2021} +} + +@article{herodotou2020, + title={A Survey on Automatic Parameter Tuning for Big Data Processing Systems}, + author={Herodotou, Herodotos and Chen, Yuxing and Lu, Jiaheng}, + journal={ACM Computing Surveys}, + volume={53}, + number={3}, + pages={1--36}, + year={2020}, + publisher={ACM} +} + +@inproceedings{aghayev2019, + title={File systems unfit as distributed storage backends: Lessons learned from building the Ceph storage backend on top of local file systems}, + author={Aghayev, Abutalib and Weil, Sage A and Kuchnik, Michael and Nelson, Mark and Ganger, Gregory R and Amvrosiadis, George}, + booktitle={Proceedings of the 27th ACM Symposium on Operating Systems Principles}, + pages={75--89}, + year={2019}, + organization={ACM} +}