PVFS-Store - Um repositório chave-valor com garantia de localidade

PVFS-Store - Um reposit´orio chave-valor com garantia de localidade

Ricardo M. Maeda¹

Orientadora: Carmem Satie Hara¹

1PPGInf - Programa de P´os-Graduac¸˜ao em Inform´atica Departamento de Inform´atica – Universidade Federal do Paran´a

Caixa Postal 19.081 – 81.531-990 – Curitiba – PR – Brasil

{rmmaeda, carmem}@inf.ufpr.br N´ıvel: Mestrado

Ingresso no programa: Marc¸o/2013 Previs˜ao de conclus˜ao: Marc¸o/2015 Etapas conclu´ıdas: Cr´editos em disciplinas

Resumo. H´a uma demanda crescente por soluc¸˜oes distribu´ıdas de armazena- mento, que preservem a localidade dos dados nos servidores espalhados ge- ograficamente. Grande parte das soluc¸˜oes NoSQL distribu´ıdas s˜ao baseadas em uma DHT e possuem pouco ou nenhum controle sobre a colocac¸˜ao dos da- dos. A garantia da localizac¸˜ao ´e importante para permitir que as informac¸˜oes sejam posicionadas pr´oximas `as aplicac¸˜oes consumidoras e agrupadas seman- ticamente para acessos otimizados. Este trabalho prop˜oe o PVFS-Store, um sistema de armazenamento distribu´ıdo baseado no modelo chave-valor, cujo objetivo ´e permitir o controle da localidade dos dados pela aplicac¸˜ao.

Palavras-chaves. Armazenamento distribu´ıdo em nuvem, sistemas de arquivos distribu´ıdos, reposit´orio chave-valor, NoSQL, proximidade dos dados, locali- dade dos dados

paper:66

1. Introduc¸˜ao

O crescimento vertiginoso no volume de dados manipulados atualmente vem trazendo desafios consider´aveis no desenvolvimento de soluc¸˜oes escal´aveis e globalmente dis- tribu´ıdas. Estima-se que at´e 2020 a quantidade de informac¸˜ao digital passar´a de 130 exabytes (c´alculo estimado em 2005) para 40.000 exabytes gerados por ano. Aproxima- damente 40% desta informac¸˜ao ser´a armazenada na nuvem¹. Manter a escalabilidade e a consistˆencia dos dados distribu´ıdos globalmente s˜ao desafios crescentes e acompanhados pela comunidade cient´ıfica.

Implementac¸˜oes tradicionais de bases de dados distribu´ıdas estudadas nas ´ultimas d´ecadas n˜ao apresentaram escalabilidade aceit´avel. Isso se deve em grande parte aos impactos em desempenho causados pelos custos da sincronizac¸˜ao e tratamento de fa- lhas. Tais implementac¸˜oes acabaram n˜ao sendo utilizadas amplamente na ind´ustria [Agrawal et al. 2010], o que resultou no aparecimento de soluc¸˜oes projetadas para es- calar horizontalmente e prover operac¸˜oes simples de leitura/escrita. Estas novas soluc¸˜oes s˜ao referenciadas como bases de dados NoSQL (Not Only SQL).

A maior parte destas soluc¸˜oes NoSQL optou pelo armazenamento baseado em DHT (Distributed Hash Table) [Wehrle et al. 2005]) como mecanismo de distribuic¸˜ao e localizac¸˜ao dos dados pelo fato de proverem escalabilidade, tolerˆancia a falhas e alta disponibilidade. A distribuic¸˜ao ´e fundamentada atrav´es de uma func¸˜ao de espalhamento, o que torna o controle da localidade dos dados pela aplicac¸˜ao muito baixo ou praticamente nulo. Em sistemas distribu´ıdos geograficamente a proximidade das informac¸˜oes com as aplicac¸˜oes usu´arias ´e fator essencial para evitar a alta latˆencia de redes WAN (Wide Area Network) [Corbett et al. 2013].

Devido `a DHT ser desenvolvida para dar suporte a consultas de correspondˆencia exata da chave, ao efetuar buscas baseadas em intervalos ou conjunto de valores, m´ultiplos servidores acabam sendo acessados. M´etodos de indexac¸˜ao sobre a DHT foram propostos [Tang et al. 2010], por´em o intuito destas abordagens ´e possibilitar buscas por intervalo e n˜ao diminuir o acesso a m´ultiplos servidores. Outra alternativa ´e a adoc¸˜ao de func¸˜oes de espalhamento que mantˆem a ordem lexicogr´afica das chaves como encontrado no Scala- ris².

Uma outra consequˆencia da adoc¸˜ao de uma DHT ´e o fato da alocac¸˜ao dos dados ser realizada de maneira aleat´oria. Isto faz com que a aproximac¸˜ao de dados afins n˜ao seja considerada. O agrupamento de dados relacionados j´a ´e explorado nos SGBDs relacionais tradicionais, atrav´es de ´ındices cluster e particionamento por intervalos para aproximac¸˜ao f´ısica dos blocos de dados. Em sistemas distribu´ıdos globalmente, o mesmo conceito de agrupar informac¸˜oes semanticamente pr´oximas em um mesmo servidor tamb´em ´e ben´efica. Quando as informac¸˜oes acessadas em conjunto s˜ao agrupadas, a quantidade de servidores envolvidos na operac¸˜ao ´e minimizada, evitando transac¸˜oes distribu´ıdas com protocolos de alto custo computacional [Shute et al. 2013].

Permitir o controle sobre a localidade dos dados ´e, portanto, essencial para a es- calabilidade e desempenho da soluc¸˜ao em ambientes distribu´ıdos geograficamente. O objetivo deste trabalho ´e implementar um reposit´orio distribu´ıdo baseado em um modelo

1http://idcdocserv.com/1414

2https://code.google.com/p/scalaris

chave-valor, cuja localidade seja garantida e controlada pela aplicac¸˜ao. A ideia prim´aria

´e avaliar os benef´ıcios do agrupamento de informac¸˜oes correlatas em um mesmo servidor e da proximidade dos dados com a aplicac¸˜ao consumidora.

Este trabalho est´a organizado da seguinte maneira: o cap´ıtulo 2 aborda os traba- lhos relacionados, o cap´ıtulo 3 descreve a proposta de implementac¸˜ao deste trabalho e por fim o cap´ıtulo 4 apresenta as considerac¸˜oes finais.

2. Trabalhos Relacionados

Entre os sistemas de armazenamento distribu´ıdo presentes na literatura e relacionados com este trabalho, existem os sistemas de arquivos distribu´ıdos, as bases de dados relaci- onais distribu´ıdas e os sistemas NoSQL. Uma importante caracter´ıstica destas soluc¸˜oes ´e a forma como os dados s˜ao dispersos. Em geral, elas utilizam uma distribuic¸˜ao homogˆenea e uniforme dos dados.

Os sistemas de arquivos distribu´ıdos apresentam uma estrutura n˜ao centralizada e os dados s˜ao dispersos em um conjunto de servidores, que comp˜oem o sistema de arma- zenamento, aumentando consideravelmente a capacidade computacional da soluc¸˜ao. Os clientes e aplicac¸˜oes usu´arias n˜ao possuem acesso direto `a estrutura de disco subjacente e a interac¸˜ao ´e realizada atrav´es de um protocolo pr´e-estabelecido. A dispers˜ao dos arqui- vos ´e transparente e ´e encargo da soluc¸˜ao distribu´ıda localizar o arquivo e transport´a-lo at´e a aplicac¸˜ao que solicitou a informac¸˜ao.

Soluc¸˜oes de c´odigo aberto como HDFS (Hadoop Distributed File System) [Shvachko et al. 2010], Ceph [Weil et al. 2006] e PVFS [Ross et al. 2000], ou pro- priet´ario como GFS (Google File System) [Ghemawat et al. 2003] n˜ao s˜ao em essˆencia estruturados para dar ciˆencia `a aplicac¸˜ao sobre onde o arquivo ou um fragmento dele ser´a armazenado. O HDFS e o GFS n˜ao implementam meios efetivos de alocac¸˜ao dos arquivos. Eles dividem os arquivos em fragmentos e estes s˜ao alocados em servidores com maior disponibilidade de recursos (menor carga no caso do HDFS ou menor uso de armazenamento no caso do GFS). O Ceph ´e um sistema de armazenamento distribu´ıdo baseado em objetos, que s˜ao espalhados por uma func¸˜ao de dispers˜ao sobre um n´umero de identificac¸˜ao associado a cada objeto. Este sistema provˆe uma flexibilidade maior, quando comparado `as outras soluc¸˜oes, pois o administrador pode definir pol´ıticas de colocac¸˜ao dos objetos na estrutura do sistema distribu´ıdo (por exemplo, discos, servidores,datacen- ters, etc). O PVFS ´e proposto para fragmentac¸˜ao dos arquivos e distribuic¸˜ao uniforme dos fragmentos para desempenho. Ele possui uma forma efetiva de garantia da colocac¸˜ao do arquivo em determinado servidor. Esta colocac¸˜ao ´e definida atrav´es da interface do PVFS, na qual ´e poss´ıvel especificar o nome do servidor no momento da criac¸˜ao do arquivo. Isto motivou a sua utilizac¸˜ao como reposit´orio de armazenamento, para estudo deste trabalho de mestrado.

Para os sistemas NoSQL, o modelo de armazenamento chave-valor ´e en- contrado nas soluc¸˜oes MemcacheDB³ e Amazon DynamoDB⁴. Elas utilizam DHT como mecanismo de dispers˜ao e o fato da colocac¸˜ao das informac¸˜oes conside- rar uma func¸˜ao de espalhamento (hash), o posicionamento dos dados em de- terminado servidor n˜ao ´e garantido. Outros sistemas baseados em chave-valor,

3http://memcachedb.org

4http://aws.amazon.com/dynamodb

com noc¸˜oes de localidade para distribuic¸˜ao dos dados, s˜ao explorados nos traba- lhos [Ribas et al. 2011, Arnaut et al. 2011, Schroeder et al. 2012] e est˜ao presentes em soluc¸˜oes comerciais envolvendo servidores espalhados geograficamente, como Cassan- dra [Lakshman and Malik 2010] e Spanner [Corbett et al. 2013]. A localidade dos dados nestes reposit´orios distribu´ıdos tem sido proposta com o intuito de permitir a proximi- dade das aplicac¸˜oes com seus dados, e minimizar as requisic¸˜oes e controle de acesso quando m´ultiplos servidores s˜ao necess´arios para atender uma consulta do usu´ario. Es- tas soluc¸˜oes, que adotaram noc¸˜oes de localidade na distribuic¸˜ao dos dados, s˜ao basea- das em um modelo, em que a aplicac¸˜ao utiliza a ordem lexicogr´afica das chaves para organizac¸˜ao das informac¸˜oes. Ao utiliz´a-las para armazenamento sobre um sistema DHT com distribuic¸˜ao baseada em intervalo, a criac¸˜ao das chaves com prefixos comuns permite

`a aplicac¸˜ao o agrupamento dos dados em servidores pr´oximos ou no mesmo servidor.

Por´em n˜ao h´a garantias de que chaves similares necessariamente ser˜ao alocadas em um

´unico servidor.

As soluc¸˜oes existentes n˜ao proveem garantias de localidade na alocac¸˜ao das informac¸˜oes. As soluc¸˜oes que mais se aproximam em atender este requisito distribuem os dados agrupando pela ordem lexicogr´afica das chaves. Esta abordagem obriga a aplicac¸˜ao a modificar ou adequar as chaves, adicionando prefixos a elas para possibilitar seus agru- pamentos e, apesar de as aproximarem, n˜ao h´a garantias na localidade delas no mesmo servidor. A ausˆencia de uma soluc¸˜ao distribu´ıda com suporte a localidade dos dados mo- tivou a proposta do PVFS-Store, apresentado a seguir.

3. PVFS-Store

PVFS-Store ´e uma proposta de implementac¸˜ao de reposit´orio de dados distribu´ıdo, cujo armazenamento possui como base o modelo chave-valor. Este modelo ´e utilizado como estrutura de armazenamento f´ısico para grande parte das soluc¸˜oes NoSQL citadas na sec¸˜ao 2 devido a sua flexibilidade, simplicidade e escalabilidade.

O PVFS-Store permite a alocac¸˜ao de um conjunto de pares chave-valor agrupados em uma ´unica estrutura, cuja localidade ´e ministrada de maneira controlada e orientada pela aplicac¸˜ao usu´aria do sistema. Esta estrutura ´e denominadabuckete ela representa a unidade b´asica de armazenamento e transferˆencia da soluc¸˜ao.

3.1. Modelo

A arquitetura do sistema satisfaz a separac¸˜ao em n´ıveis dos SGBDs tradicionais. A ca- mada f´ısica descreve as estruturas f´ısicas do banco de dados e ´e implementada sobre o reposit´orio distribu´ıdo, PVFS-Store. A camada l´ogica abstrai os detalhes f´ısicos de arma- zenamento. Ela se concentra em descrever como os dados s˜ao estruturados e como eles s˜ao apresentados para a aplicac¸˜ao. Para garantir a compatibilidade com outras soluc¸˜oes NoSQL, o modelo chave-valor ´e adotado nesta camada.

Uma aplicac¸˜ao sobre o PVFS-Store consegue acessar este reposit´orio, atrav´es de uma interface de manipulac¸˜ao dos atributos chave-valor. Ela inclui al´em destes atributos, alterac¸˜oes e adic¸˜oes de m´etodos para prover suporte aobuckete ao servidor:

• create bucket(bucket, servidor): criac¸˜ao e inicializac¸˜ao dobucketem umservidor do reposit´orio.

• drop bucket(bucket): remoc¸˜ao dobucketjuntamente com as chaves.

• put pair(chave, valor, bucket): inclus˜ao de um parchave-valoraobucket.

• get pair(chave): obtenc¸˜ao de um valor a partir de umachave.

• rem pair(chave): exclus˜ao de um par chave-valor a partir dachave.

Tais instruc¸˜oes s˜ao similares `as encontradas nos sistemas DHT, com uma impor- tante diferenc¸a de que a localidade dos registros ´e controlada pela aplicac¸˜ao, atrav´es dos m´etodos de criac¸˜ao de um bucket e inclus˜ao de um par chave-valor. Al´em disso, uma interface e reposit´orio adicionais ser˜ao desenvolvidos para armazenar as informac¸˜oes do metadado.

• put md(chave, bucket): inclus˜ao no metadado dachavee dobucket, onde ela ser´a inserida. Este m´etodo ser´a chamado toda vez que a func¸˜aoput pairfor executada.

• get md(chave): obtenc¸˜ao dobucket, onde est´a localizada achave. Ele ser´a execu- tado nas chamadas `a func¸˜aoget pair.

• rem md(chave): exclus˜ao dachavedo metadado. Sempre que um par chave-valor for removido atrav´es dorem pairesta instruc¸˜ao ser´a executada.

A disposic¸˜ao do PVFS-Store em relac¸˜ao `a aplicac¸˜ao e ao sistema distribu´ıdo pode ser visualizado na figura 1. Entre a aplicac¸˜ao e a interface do PVFS-Store as informac¸˜oes sobre bucket, chave e valor s˜ao utilizadas na interac¸˜ao com o reposit´orio de dados. J´a a comunicac¸˜ao do PVFS-Store com o PVFS utiliza uma API do sistema de arquivos dis- tribu´ıdo e possui como unidade obucket.

Figura 1. Arquitetura do PVFS-Store

Na implementac¸˜ao do PVFS-Store, umbucket ´e fisicamente um arquivo no sis- tema de arquivos PVFS. Todo bucket est´a associado a um servidor, necess´ario para a colocac¸˜ao deste arquivo na soluc¸˜ao distribu´ıda.

As informac¸˜oes sobrebucketse servidores s˜ao armazenadas em uma estrutura de dados compondo o metadado do PVFS-Store. O metadado ´e respons´avel pela associac¸˜ao de uma chave ao bucket e ao servidor, nos quais ela est´a armazenada. A dispers˜ao e localizac¸˜ao dos dados s˜ao controladas pela aplicac¸˜ao atrav´es deste metadado, ao inv´es de uma DHT.

Cada bucket possui no cabec¸alho meta-informac¸˜oes, como n´umero m´aximo de chaves, um mapa de bits para controle do espac¸o livre e uma estrutura de tamanho fixo contendo as chaves existentes no bucket. Os valores associados `as chaves s˜ao salvos justapostos, no corpo dobucket, ap´os o cabec¸alho.

O PVFS-Store est´a sendo desenvolvido sobre o sistema de arquivos distribu´ıdos PVFS.

3.2. Estudo de Caso

Para avaliac¸˜ao do PVFS-Store como um reposit´orio distribu´ıdo ser´a implementado um m´odulo de armazenamento customizado do MySQL⁵ (MySQL Custom Storage Engine), que utiliza o PVFS-Store como armazenamento f´ısico. A escolha do MySQL se deve `a sua arquitetura modular, na qual ´e poss´ıvel acoplar m´odulos de armazenamento de maneira transparente para a aplicac¸˜ao.

Como base deste estudo de caso ser˜ao utilizadas abordagens semelhantes `as exis- tentes em [Ribas et al. 2011] e [Chang et al. 2008] para mapeamento das relac¸˜oes em pares chave-valor. O m´odulo de armazenamento MySQL sobre o PVFS-Store ser´a res- pons´avel por este mapeamento. Todas as operac¸˜oes existentes na base de dados relacional dever˜ao ser convertidas para instruc¸˜oes do reposit´orio chave-valor. Desta forma, tuplas dever˜ao ser mapeadas para chave-valor no momento de uma operac¸˜ao de inserc¸˜ao e de forma inversa ao obtˆe-las.

Outras aplicac¸˜oes sobre o PVFS-Store podem ser desenvolvidas. O modelo pro- posto de chave-valor com garantia de localidade (por meio debuckets) permite utiliz´a-lo como reposit´orio de uma aplicac¸˜ao NoSQL ou at´e implementac¸˜oes mais complexas de SGBD sobre ele, que adotem fragmentac¸˜oes horizontais (por linhas) ou verticais (por colunas).

Como validac¸˜ao da proposta deste trabalho e realizac¸˜ao de experimentos, a soluc¸˜ao ser´a comparada a um armazenamento sobre uma DHT, cuja distribuic¸˜ao ´e uni- forme e homogˆenea.

4. Considerac¸˜oes Finais

Este trabalho prop˜oe o desenvolvimento de uma soluc¸˜ao distribu´ıda armazenada sobre um reposit´orio chave-valor e um metadado para localizac¸˜ao das chaves nos respectivosbuc- kets. Esta soluc¸˜ao pretende avaliar os impactos do controle da localidade dos dados em um ambiente distribu´ıdo e compar´a-la com uma abordagem que n˜ao leva em considerac¸˜ao a localidade. O PVFS-Store possibilita `a aplicac¸˜ao a alocac¸˜ao exata em um determinado servidor das tuplas no reposit´orio distribu´ıdo. As soluc¸˜oes atuais possuem pouco ou ne- nhum controle sobre a colocac¸˜ao das informac¸˜oes nos servidores e implementam meca- nismos de distribuic¸˜ao uniforme dos dados ou baseados em ordenac¸˜ao lexicogr´afica.

Com a abordagem proposta ´e poss´ıvel otimizar aplicac¸˜oes distribu´ıdas global- mente, aproximando os dados das aplicac¸˜oes usu´arias. O agrupamento das informac¸˜oes semanticamente relacionadas evita o acesso a m´ultiplos servidores e ajuda a diminuir a incidˆencia de transac¸˜oes distribu´ıdas.

Portanto, ´e esperado que a distribuic¸˜ao controlada pela aplicac¸˜ao traga benef´ıcios em uma rede distribu´ıda geograficamente. O reposit´orio PVFS-Store e seu metadado est˜ao sendo implementados sobre um ambiente em nuvem. Para a validac¸˜ao da proposta ser´a desenvolvido um m´odulo de armazenamento MySQL sobre o PVFS-Store.

5http://www.mysql.com

O principal desafio na implementac¸˜ao deste trabalho ´e o desenvolvimento de um metadado descentralizado. Al´em disso, a especificac¸˜ao de uma interface chave-valor com suporte a localidade dos dados e o seu desenvolvimento sobre um reposit´orio distribu´ıdo s˜ao desafios importantes na implementac¸˜ao desta soluc¸˜ao.

Referˆencias

Agrawal, D., El Abbadi, A., Antony, S., and Das, S. (2010). Data management challenges in cloud computing infrastructures. InDatabases in Networked Information Systems.

Arnaut, D. E., Schroeder, R., and Hara, C. S. (2011). Phoenix: A relational storage component for the cloud. In Cloud Computing (CLOUD), 2011 IEEE International Conference on.

Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., Chandra, T., Fikes, A., and Gruber, R. E. (2008). Bigtable: A distributed storage system for structured data.

Corbett, J. C., Dean, J., Epstein, M., Fikes, A., Frost, C., Furman, J., Ghemawat, S., Gubarev, A., Heiser, C., Hochschild, P., et al. (2013). Spanner: Google’s globally distributed database.

Ghemawat, S., Gobioff, H., and Leung, S.-T. (2003). The google file system. InACM SIGOPS Operating Systems Review.

Lakshman, A. and Malik, P. (2010). Cassandra: a decentralized structured storage system.

Ribas, E. A., Uba, R., Reinaldo, A. P., et al. (2011). Layering a dbms on a dht-based storage engine.

Ross, R. B., Thakur, R., et al. (2000). Pvfs: A parallel file system for linux clusters. Inin Proceedings of the 4th Annual Linux Showcase and Conference.

Schroeder, R., dos Santos Mello, R., and Hara, C. S. (2012). Affinitybased xml fragmen- tation. InWebDB.

Shute, J., Vingralek, R., Samwel, B., Handy, B., Whipkey, C., Rollins, E., Oancea, M., Littlefield, K., Menestrina, D., Ellner, S., et al. (2013). F1: A distributed sql database that scales.

Shvachko, K., Kuang, H., Radia, S., and Chansler, R. (2010). The hadoop distributed file system. In Mass Storage Systems and Technologies (MSST), 2010 IEEE 26th Sympo- sium on.

Tang, Y., Zhou, S., and Xu, J. (2010). Light: a query-efficient yet low-maintenance indexing scheme over dhts. Knowledge and Data Engineering, IEEE Transactions on, 22(1):59–75.

Wehrle, K., G¨otz, S., and Rieche, S. (2005). 7. distributed hash tables. InPeer-to-Peer systems and applications.

Weil, S. A., Brandt, S. A., Miller, E. L., Long, D. D. E., and Maltzahn, C. (2006). Ceph:

A scalable, high-performance distributed file system. In Proceedings of the 7th Sym- posium on Operating Systems Design and Implementation.