commit - 7f7a202666ee49b804c649dd467840a69c6423ba
commit + 15416a7f8afabd2ecc9cc18d2e435db2c5b9d772
blob - 27416bf5c052f8a54f40e630c8d331994caa868a
blob + 94db969a0ffbb3f37da149e1299cd270141eedbe
Binary files main.pdf and main.pdf differ
blob - 155b88bf01628b77e1318f4d00d5b6e288d8b9fd
blob + 84158f433830564e1dc07ee92cacfd6ec28c2fea
--- main.tex
+++ main.tex
\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
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:
\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
-@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}
+}
