Dedupeer: Deduplicação de Arquivos Através de Um Algoritmo de Processamento Particionado

Dedupeer: um Algoritmo para Deduplicao de Arquivos
Atravs de Processamento Particionado

Por
Paulo Fernando Almeida Soares

Dissertao de Mestrado
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE, JULHO/2013
Universidade Federal de Pernambuco

Centro de Informtica
Ps-graduao em Cincia da Computao
Paulo Fernando Almeida Soares
Dedupeer: um Algoritmo para Deduplicao de

Arquivos Atravs de Processamento Particionado
Trabalho apresentado ao Programa de Ps-graduao em

Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para
obteno do grau de Mestre em Cincia da Computao.
Orientador: Silvio Romero de Lemos Meira

Co-Orientador: Vinicius Cardoso Garcia
RECIFE, JULHO/2013
Resumo
A deduplicao uma tcnica de compresso de dados sem perda que elimina dados
redundantes tanto intra-file como inter-file, diferente de ferramentas de compresso de
dados como o gzip que s eliminam a redundncia intra-file. A deduplicao reduz a
necessidade de armazenamento atravs da eliminao de blocos de dados redundantes.
Na deduplicao, todos os blocos de dados que esto duplicados em um sistema de
armazenamento podem ser reduzidos uma nica cpia, esses blocos desalocados pela
deduplicao so transformados em referncia para o que foi mantido no sistema.
Tcnicas de deduplicao comearam a ser estudadas para sistemas de armazenamento
comerciais em meados de 2004. Hoje, os principais sistemas de armazenamento de
dados usam deduplicao, mas os algoritmos implementados e as tcnicas utilizadas
no so detalhadas publicamente. Existem alguns trabalhos acadmicos focados na
implementao de algoritmos de deduplicao, mas eles so raros e no so voltados para
a sua utilizao em sistemas de armazenamento existentes. O principal objetivo deste
trabalho criar um algoritmo para deduplicao de arquivos no cliente de forma remota,
atravs de processamento particionado e utilizando comparao por fingerprints. Este
algoritmo foi incorporado em um componente de software com interface interopervel
para facilitar a utilizao em qualquer sistema de armazenamento de dados e benefici-los
com economia de armazenamento, e na transferncia de dados no caso dos sistemas de
armazenamento distribudos.
Alm do componente de software, foi desenvolvido tambm um sistema de armazenamento com gerenciamento de dados baseado no Apache Cassandra, o que o torna capaz
de ser distribudo, com o objetivo de validar o algoritmo de deduplicao. A integrao do
componente de software com o sistema de armazenamento foi implementada e avaliada
neste trabalho.
Palavras-chave: Deduplicao, compresso de dados, economia de armazenamento,
sistemas de armazenamento de dados
iii
Abstract
The deduplication is a technique of lossless data compress that eliminates redundant

data as intra-file as inter-file, different tools to data compression like gzip only eliminates
the redundancy intra-file. The deduplication reduces storage needs through eliminating
redundant blocks. In the deduplication, all data blocks or files that are duplicates in a
storage system are reduced to a solely copy, and the unallocated data are transformed in
reference to the data content maintained in the system.
Deduplication techniques began to be studied in mid-2004. Today, the main storage
systems use deduplication, but the algorithms implemented and the techniques used are
not detailed. There are researches focused in the implementation of algorithms, but they
are rare and the main goal not is the integration with the existing systems. The main
aim of this research is to create an algorithm to deduplication of files on the source with
remote data, through of the partitioned processing and using of fingerprint comparisons.
This algorithm was integrated in a software component with interoperable interface to
facilite the using in any storage system and benefit them with storage economy,and in the
data transfer when the system was distributed.
Besides the software component was developed also a storage system with data
management made with the Apache Cassandra, which make it able to be distributed
with the goal to validate the deduplication algorithm. The integration of the software
component with the storage system was implemented and evaluated in this research.
Keywords: Deduplication, data compression, storage economy, storage systems
iv
Sumrio
Lista de Figuras
viii
Lista de Tabelas
xi
1
3
4
4
5
5
6
Introduo
1.1 Motivao . . . . . . .
1.2 Definio do problema
1.3 Resultados esperados .
1.4 Escopo negativo . . . .
1.5 Contribuies . . . . .
1.6 Sumrio . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Trabalhos relacionados
7
2.1 Sistemas de armazenamento de dados com foco em deduplicao . . . .
7
2.1.1 Distributed Duplicate Detection in Post-Process Data De-duplication 8
2.1.2 Design of an exact data deduplication cluster . . . . . . . . . .
8
2.1.3 -Dedup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.4 Dropbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.5 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Deduplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Localizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Cliente (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Servidor (target) . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Momento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Benefcios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Sumrio do captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
O Dedupeer File Storage

3.1 Introduo . . . . . . . . . . . . . . . .
3.1.1 Escopo . . . . . . . . . . . . .
3.2 O sistema de armazenamento distribudo
3.2.1 Modelo de dados . . . . . . . .
3.3 Viso de componentes e conectores . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
18
19
19
25
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
27
27
27
29
29
30
30
31
31
31
31
32
32
33
33
Componente para deduplicao em sistemas de armazenamento de dados

4.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Interoperabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Interoperabilidade de comunicao atravs do Thrift . . . . . .
4.2.2 Comparao com o Protocols Buffer . . . . . . . . . . . . . . .
Protocols Buffer . . . . . . . . . . . . . . . . . . . . . . . . .
Comparao de desempenho . . . . . . . . . . . . . . . . . . .
4.2.3 Comparao por hash (fingerprints) . . . . . . . . . . . . . . .
Vantagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Sumrio do captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
34
35
35
37
37
38
38
40
41
Os algoritmos
5.1 Fundamentos . . . . . . .
5.1.1 O algoritmo Rsync
Rolling checksum
5.1.2 Fingerprinting . .
5.2 Detalhando os algoritmos .
42
42
42
43
44
45
3.4
3.5
O componente Dedupeer File Storage . . . . . . . .

O componente Dedupeer . . . . . . . . . . . . . . .
Decises de projeto e consideraes . . . . . . . . . . . . .
3.4.1 Tamanho do chunk . . . . . . . . . . . . . . . . . .
3.4.2 Cassandra para gerenciamento do armazenamento .
Tolerncia falhas . . . . . . . . . . . . . . . . . .
Recuperao de falhas . . . . . . . . . . . . . . . .
Consistncia . . . . . . . . . . . . . . . . . . . . .
Disponibilidade . . . . . . . . . . . . . . . . . . . .
Empacotamento de requisies . . . . . . . . . . . .
3.4.3 Alternativa para o gerenciamento de armazenamento
Facilidade de instalao e manuteno . . . . . . . .
Clusters pequenos . . . . . . . . . . . . . . . . . .
3.4.4 Escalabilidade . . . . . . . . . . . . . . . . . . . .
O que escalabilidade? . . . . . . . . . . . . . . . .
Escalabilidade com o Cassandra . . . . . . . . . . .
Sumrio do captulo . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
5.2.1
5.3
6
Algoritmo para deduplicao com carga completa do arquivo na

memria . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Algoritmo com deduplicao particionada . . . . . . . . . . . .
Sumrio do captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anlise de desempenho e compresso

6.1 Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Anlise de desempenho utilizando o cdigo fonte do Kernel do Linux
Operao de armazenamento . . . . . . . . . . . . . . . . . .
Operao de deduplicao . . . . . . . . . . . . . . . . . . .
Operao de deduplicao + armazenamento . . . . . . . . .
Operao de reidratao . . . . . . . . . . . . . . . . . . . .
6.2.1 Mapa de chunks deduplicados . . . . . . . . . . . . . . . . .
6.3 Anlise de economia utilizando mquinas virtuais . . . . . . . . . . .
6.4 O Ustore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Sumrio do captulo . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
50
56
.
.
.
.
.
.
.
.
.
.
57
57
59
59
62
64
66
68
69
71
71
Concluso
7.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
73
Referncias Bibliogrficas
75
A Apndice
A.1 Arquivo de definio dos servios Thrift . . . . . . . . . . . . . . . . .
A.2 Resultados da avaliao dos arquivos do cdigo fonte do Kernel do Linux
A.3 Grficos dos tempos emparelhados por tamanho de chunk para a operao
de armazenamento . . . . . . . . . . . . . . . . . . . . . . . . . . . .
de deduplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
de deduplicao + armazenamento . . . . . . . . . . . . . . . . . . . .
de reidratao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
80
81
Appendices
80
84
86
89
91
vii
Lista de Figuras
1.1
2.1
2.2
Aumento da demanda e reduo do custo de hardware de armazenamento

[20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Armazenamento dos super-chunks nos ns [43]. . . . . . . . . . . . . .

Exemplo da economia de espao oferecida em um sistema de armazenamento com 20% de alterao nos dados. . . . . . . . . . . . . . . . . .
10
Diagrama de componentes de alto nvel da biblioteca do Dedupeer . . .

Modelo de dados do sistema distribudo desenvolvido com o Cassandra
Viso de componentes e conectores do DeFS integrado com a biblioteca
do Dedupeer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
24
4.1
4.2
Desempenho na serializao dos dados [2] . . . . . . . . . . . . . . . .

Desempenho na desserializao dos dados [2] . . . . . . . . . . . . . .
38
39
5.1
5.2
5.3
Funcionamento do algoritmo 1. . . . . . . . . . . . . . . . . . . . . . .
Funcionamento do algoritmo 2 . . . . . . . . . . . . . . . . . . . . . .
Vantagem da utilizao da carga extra de dados . . . . . . . . . . . . .
47
51
55
6.1
Tempo em milissegundos para as execues da operao de armazenamento utilizando MD5 . . . . . . . . . . . . . . . . . . . . . . . . . .

Tempo em milissegundos para as execues da operao de armazenamento utilizando SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . .
Tempo em milissegundos para as execues da operao de armazenamento, separadas por tamanho de chunk . . . . . . . . . . . . . . . . .
Tempo em milissegundos das execues da operao de deduplicao,
separadas por tamanho de chunk, utilizando SHA-1 . . . . . . . . . . .
Tempo em milissegundos das execues da operao de deduplicao,
separadas por tamanho de chunk, utilizando MD5 . . . . . . . . . . . .
Tempo em milissegundos das execues da operao de deduplicao +
armazenamento, separadas por tamanho de chunk, utilizando SHA-1 . .
Tempo em milissegundos das execues da operao de deduplicao +
armazenamento, separadas por tamanho de chunk, utilizando MD5 . . .
Tempo em milissegundos das execues da operao de reidratao,
separadas por tamanho de chunk, utilizando SHA-1 . . . . . . . . . . .
3.1
3.2
3.3
6.2
6.3
6.4
6.5
6.6
6.7
6.8
16
26
60
60
61
63
63
65
66
67
viii
6.9
Tempo em milissegundos das execues da operao de reidratao,

separadas por tamanho de chunk, utilizando MD5 . . . . . . . . . . . .
6.10 Mapa de chunks deduplicados da verso 3.10-rc7 do cdigo-fonte do
Kernel do Linux processado com os chunks da verso 3.9.8, para chunks
com tamanho 128, 64, 32, 16 e 8KB . . . . . . . . . . . . . . . . . . .
6.11 Tamanho em megabytes ocupado pelo arquivo no sistema, com a porcentagem de economia alcanada . . . . . . . . . . . . . . . . . . . . . .
6.12 Mapa de chunks deduplicados da mquina virtual Linux 12.10 atualizada
processada com os chunks da mesma mquina virtual sem atualizao,
para chunks com tamanho 128, 64, 32, 16 e 8KB . . . . . . . . . . . .
A.1 Tempo emparelhado para a operao de armazenamento com chunks de
128KB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64KB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32KB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16KB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8KB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6 Tempo emparelhado para a operao de deduplicao com chunks de
128KB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7 Tempo emparelhado para a operao de deduplicao com chunks de 64KB
A.11 Tempo emparelhado para a operao de deduplicao + armazenamento
com chunks de 128KB . . . . . . . . . . . . . . . . . . . . . . . . . .
com chunks de 64KB . . . . . . . . . . . . . . . . . . . . . . . . . . .
com chunks de 32KB . . . . . . . . . . . . . . . . . . . . . . . . . . .
com chunks de 16KB . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
68
70
70
84
84
85
85
86
86
87
87
88
88
89
89
90
90
ix

com chunks de 8KB . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.16 Tempo emparelhado para a operao de reidratao com chunks de 128KB
91
91
92
92
93
93
Lista de Tabelas
3.1
Fora do consistncia baseada nos nveis das operaes [8] . . . . . . .
30
6.1
6.2
p-values para os dados capturados na operao de armazenamento . . .

Quantidade de chunks criados . . . . . . . . . . . . . . . . . . . . . .
62
69
xi
1
Introduo
Com o aumento da capacidade das unidades de armazenamento, aumentou tambm a

demanda por sua utilizao. Em 2000, a estimativa da indstria era de um aumento anual
entre 50% a 100% dessa demanda [24], estimativa essa que se consolidou. Nos ltimos
anos esse aumento atingiu um valor anual de mais de 50% [20].
A Figura 1.1 mostra dois grficos com informaes sobre demanda e preo do
armazenamento entre os anos de 2006 e 2011. Um deles demonstra o forte crescimento
da demanda por armazenamento nas empresas, e o segundo, exibe a queda de 20% ao
ano no preo por Gigabytes.
Figura 1.1 Aumento da demanda e reduo do custo de hardware de armazenamento [20]
A indstria de TI passou a apostar em sistemas de armazenamento de dados distribudo

nos ltimos anos. Empresas como Amazon1 , Google2 , Microsoft3 e Salesforce4 comearam a investir em centros de armazenamentos de dados na nuvem (Cloud Storages),
espalhados pelo mundo, com garantia de redundncia e tolerncia falhas [44].
Com esse aumento da demanda por armazenamento, a utilizao de tcnicas de
compresso de dados se torna um fator chave para reduo dos custos. A compresso
de dados uma tcnica que codifica informaes, usando uma quantidade menor de
dados que a original, para economizar espao de armazenamento. As tcnicas mais
conhecidas de compresso de dados funcionam apenas com a compresso intra-file, ou
seja, utilizando no processamento apenas os bytes do arquivo a ser comprimido, como
exemplo, pode ser citado o formato de arquivo zip [31], que um tipo de compresso
sem perda. E tambm existe a compresso intra-file com perda de dados, que o caso
dos famosos formatos de arquivos jpg e mp3, o qual reduz a qualidade da foto e imagem,
respectivamente, para obter uma reduo no espao necessrio para armazenar o arquivo
[33].
A deduplicao um tcnica de compresso sem perda que elimina dados redundantes
tanto intra-file quanto inter-file, o que possibilita utilizar dados remotos para ajudar na
compresso dos dados. Com a popularizao dos sistemas de armazenamento distribudo
em nuvem, a deduplicao ajudar muito na economia de espao de armazenamento, j
que ela pode utilizar informaes em diferentes arquivo e entidades para economizar o
espao utilizado no sistema. A deduplicao de dados um tcnica de compresso que
armazena uma nica cpia de dados redundantes, eliminando as outras do sistema de
armazenamento. Ela pode ser feita em nvel de arquivo completo ou de chunks, os quais
so blocos de dados pertencentes ao arquivo.
Muitos sistemas de backup atuais escolhem fazer o armazenamento dos arquivos em
fitas magnticas por serem mais baratas que os discos rgidos. A fita magntica tem
a desvantagem de ter o acesso apenas sequencial dos dados, enquanto que no disco o
acesso pode ser randmico. Com a utilizao das fitas, a deduplicao dos dados se torna
eficientemente invivel pela falta de capacidade em acesso randmico. Por esse fator, a
deduplicao est tornando um diferencial na escolha dos discos rgidos como dispositivo
de armazenamento dos backups, a vantagem do preo das fitas em relao aos discos
contornada pelo fato de que com os discos rgidos a deduplicao pode ser feita e como
1 http://aws.amazon.com/pt/s3/
2 http://www.google.com/enterprise/cloud/storage/
3 http://www.windowsazure.com
4 http://www.salesforce.com
1.1. MOTIVAO
consequncia o espao de armazenamento economizado [19].

A utilizao de deduplicao de dados em sistemas de armazenamento em nuvem d
uma grande vantagem empresa que fornece o servio. Com a utilizao da deduplicao,
a empresa poder vender para os cliente mais espao de armazenamento do que ela poderia
fornecer em um sistema sem deduplicao, j que a deduplicao diminui a quantidade de
bytes armazenados por aqruivos no sistema, principalmente quando o mesmo arquivo em
diferentes verses salvo ou quando o mesmo arquivo enviado para o sistema, mesmo
que por usurios distintos.
Uma forma de aumentar os blocos de dados redundantes em sistemas de armazenamento que possua arquivos com partes idnticas, atravs da rediviso dos chunks
baseado no contedo, e a partir disso, aumentar a quantidade de blocos de dados idnticos.
Para que esse procedimento seja executado preciso uma comparao byte byte entre
os arquivos, tarefa essa que demanda muito processamento e utilizao de E/S (entrada
e sada). Esse processo torna-se mais vivel com a distribuio do processamento dos
dados para a redefinio dos novos pontos de cortes dos chunks e utilizao de algoritmos
de hashing para identificar a redundncia de dados.
1.1
Motivao
Os principais sistemas distribudos de deduplicao de dados so feitos para serem

executados em clusters [5] [11] [19] [45] ou em ns simples, alguns deles usam framework
para processamento distribudo de dados [21], como Hadoop por exemplo, mas h uma
falta de pesquisa envolvendo sistemas de deduplicao para ambientes de armazenamento
de dados construdos com arquitetura peer-to-peer sobre computadores pessoais para
armazenar esses dados.
Baseado nisso, esse trabalho prope o desenvolvimento de um componente de software para deduplicao de dados que pode ser integrado com qualquer sistema de armazenamento de dados que tenha sido implementado em uma das linguagens suportadas
pelo Thrift. O componente ser integrado a um sistema comercial de armazenamento de
dados que foi construdo em uma arquitetura peer-to-peer.
A deduplicao traz vrios benefcios para o sistema que a utiliza, entre eles:
Reduo no espao necessrio para armazenar arquivos. Isso ajuda um sistema
de armazenamento ser considerado dentro dos padres da green storage, o qual
ser melhor detalhado no Captulo 4. Com a reduo do espao necessrio para
1.2. DEFINIO DO PROBLEMA
armazenar os arquivos, um sistema de armazenamento pode ser vendido com mais

espao do que ele possui fisicamente.
Reduo da quantidade de bytes trafegados, para o caso de sistemas distribudo,
pois com a deduplicao feita na fonte os dados redundantes no so enviados.
Maior facilidade no gerenciamento de replicao de chunks, j que a deduplicao
reduz a quantidade deles.
1.2
Definio do problema
Algoritmos detalhados para deduplicao utilizando processamento de forma particionada so escassos. Existe tambm uma falta de componentes de softwares interoperveis
para deduplicao que possam ser integrados aos sistemas de armazenamento de dados
existentes.
1.3
Resultados esperados
Esta pesquisa tem como principal objetivo desenvolver um algoritmo para deduplicao de dados, que faa processamento particionado e que seja interopervel e de fcil
integrao com os sistemas existentes. Este algoritmo dever ser disponibilizado como
um componente de software, com uma interface de comunicao multilinguagem, para
executar a deduplicao exata dos dados em sistemas de armazenamento. Ele dever ser
integrado ao sistema de armazenamento que ser desenvolvido como parte da pesquisa e
com um sistema distribudo de armazenamento de dados comercial.
Com o algoritmo a ser desenvolvido nesta pesquisa deve resolver os trs benefcios
citados na Motivao proporcionados pela deduplicao e com o mnimo de alterao
no sistema de armazenamento para integr-lo, isso porque o algoritmo ser feito tendo a
interoperabilidade e modificabilidade mnima para integrao como alguns dos principais
requisitos.
O algoritmo deve ser disponibilizado atravs de uma biblioteca com uma interface
Thrift, que vai receber os valores de hash dos chunks e o arquivo a ser deduplicado, e
retornar o arquivo deduplicado como um mapa dos chunks e das referncias aos chunks
redundantes.
O algoritmo deve fazer a busca por redundncia baseada em contedo, independente
da quantidade de bytes alterados, removidos ou adicionado entre duas verses de um
1.4. ESCOPO NEGATIVO
arquivo ou entre arquivos distintos. O algoritmo ser capaz de identificar as redundncias

se a sequncia de bytes no modificados for no mnimo do tamanho padro do chunk.
1.4
Escopo negativo
Deduplicao atravs de chunks maiores que 128KB esto fora do escopo da pesquisa,
pelo fato da deteco de redundncia diminuir com o aumento do tamanho do chunk e este
ser o tamanho padro do Ustore, o sistema comercial de backup de dados onde o Dedupeer
ser implantado. Tambm foi definido como limite mnimo de tamanho de chunk 8KB.
Apesar de conseguir uma maior ganho de reduo de espao com chunks menores, o
tempo para processamento e a quantidade de chunks gerados comea a degradar muito o
desempenho do sistema.
O Dedupeer File Storage ser desenvolvido utilizando o Cassandra5 , que um banco
de dados distribudo que utiliza arquitetura P2P, mas est fora de escopo o teste do sistema
de forma distribuda. Todos os testes sero feitos localmente, j que sero suficientes para
avaliar o algoritmo de deduplicao.
Os testes do algoritmo funcionando com deduplicao no alvo, tanto post-processing,
que a deduplicao feita depois que os dados so armazenados, como inline, que a
deduplicao onde os dados so processados no momento em que chegam no alvo e antes
de serem armazenados, esto fora do escopo do trabalho.
Por serem os algoritmo de hashing mais comuns em processamentos de deduplicao
de dados, os testes s sero feitos com MD5 e SHA-1.
1.5
Contribuies
As principais contribuies desta pesquisa sero:

O algoritmo para deduplicao de dados com processamento particionado encapsulado em um componente de software interopervel. Essa forma de processamento
torna possvel fazer a deduplicao de arquivos muito maiores do que a memria
principal, j que a configurao do tamanho da carga dos bytes para a memria,
independente do tamanho do arquivo, ser configurvel no algoritmo.
O sistema de armazenamento de dados distribudo, com cdigo-fonte aberto, administrvel atravs de interface grfica e com gerenciamento de armazenamento
5 http://cassandra.apache.org/
1.6. SUMRIO
delegado para um banco de dados no-relacional construdo em uma arquitetura

peer-to-peer com topologia de anel.
A otimizao da descoberta de redundncia de dados atravs da carga extra de
dados no processamento particionado, possibilitando a diminuio da perda de
identificao por causa da quebra do arquivo.
1.6
Sumrio
Neste captulo foi apresentada uma introduo sobre o crescimento da demanda por
sistemas de armazenamento de dados e a importncia da deduplicao para a economia
de espao nos tempos onde os sistemas de cloud storage esto sendo cada vez mais
utilizados.
Este trabalho est dividido em sete Captulos e um Apndice.
No Captulo 2 sero descritos como funcionam alguns sistemas de armazenamento de
dados que utilizam deduplicao. Em seguida ser feita uma introduo sobre quais so
os tipos de deduplicao existentes e quais os benefcios que ela pode trazer.
No Captulo 3 ser detalhada a arquitetura do Dedupeer File Storage, que o sistema
de armazenamento de arquivos desenvolvido neste trabalho, e sero discutidas algumas
decises de projeto relacionadas construo desse sistema.
No Captulo 4 ser detalhado o funcionamento do componente de software que
disponibilizar o algoritmo de deduplicao como um servio. Ser discutida a interoperabilidade do componente e quais poderiam ser as alternativas biblioteca que foi
escolhida, tambm ser tratado sobre a utilizao da comparao por hash e quais so as
suas vantagens e desvantagens.
O Captulo 5 detalhar os dois algoritmos de deduplicao desenvolvidos na pesquisa,
tanto o algoritmo mais simples como o algoritmo de processamento particionado, que a
principal contribuio deste trabalho. Sero apresentados os fundamentos do algoritmo
desenvolvido para identificao de redundncia entre arquivos remotos, os quais serviram
de base para os algoritmos desenvolvidos. Sero detalhados tambm os pseudocdigos
de alto nvel dos dois algoritmos criados.
O Captulo 6 apresentar os testes de desempenho e compresso executados para
demonstrar a eficincia do algoritmo de deduplicao e o sistema de armazenamento de
dados desenvolvidos.
E o Captulo 7 apresentar as concluses sobre o trabalho e algumas propsotas para
trabalhos futuros.
2
Trabalhos relacionados
Neste captulo, os conceitos e tcnicas fundamentais sobre os assuntos relevantes

para o entendimento dessa pesquisa sero discutidos. Sero discutidos os principais
trabalhos relacionados sistemas de armazenamento de dados com foco em deduplicao,
os quais sero detalhados afim de identificar conceitos e tcnicas que aprimorem o
desenvolvimento do projeto Dedupeer, o qual dividido em dois, o no Dedupeer File
Storage e componente de software que implementa o algoritmo deduplicao chamado
de Dedupeer.
Primeiramente vai ser feito um estudo com alguns dos sistemas de armazenamento
de dados que utilizam deduplicao para identificar as tcnicas e os conceitos, e com
isso, analisar quais as que melhor serviro de base para o desenvolvimento do Dedupeer
File Storage, que ser o sistema de armazenamento de arquivos a ser desenvolvido com
finalidade de validar a integrao do componente para deduplicao de dados. A anlise
feita nesses sistemas servir para que uma melhor estratgia para o processamento da
deduplicao seja implementada no Dedupeer, com base nos princpios desejados para a
execuo do mesmo.
pequeno o nmero de sistemas de armazenamento que declaram a utilizao de
deduplicao, e ainda menor os que detalham esse processo. Ser apresentado o conceito
de deduplicao de dados e quais so os seus tipos.
2.1
Sistemas de armazenamento de dados com foco em

deduplicao
Nesta seo sero descritos alguns dos sistemas pesquisados que tm como objetivo
armazenamento de dados e que tm como um dos focos principais a deduplicao. Os
2.1. SISTEMAS DE ARMAZENAMENTO DE DADOS COM FOCO EM

DEDUPLICAO
trabalhos acadmicos sero apresentados por ordem de ano de publicao.
2.1.1
Distributed Duplicate Detection in Post-Process Data De-duplication
Devido ao desafio cada vez mais comum em armazenar e gerenciar o crescente

volume de dados gerados nos dias atuais, conhecido como Big Data[18], importante
pensar em arquiteturas escalveis para que os sistemas consigam dar suporte a essa
grande quantidade de dados. Uma proposta de um sistema escalvel para dar suporte
deduplicao para grande volume de dados foi descrita em [21]. Diferente das pesquisas
mais comuns para escalabilidade de sistemas de deduplicao, que geralmente tm o
foco na otimizao dos algoritmos de deduplicao e em formas de deduplicao de
mais alto nvel, como arquivos e objetos. [21] tem o trabalho direcionado para o projeto
arquitetural do sistema e usa deduplicao em nvel de bloco, que apesar de ter vantagens
de velocidade, em contrapartida tem problemas no gerenciamento da enorme quantidade
de blocos a serem gerenciados.
O projeto descrito em [21] foi projetado para funcionar de forma otimizada em
ambientes de cluster, o qual um conjunto de computadores interligados atravs de um
sistema distribudo com uma finalidade em comum. Suas rotina de deduplicao offline
de dados so executadas nesses cluster externos, isso feito para que o processamento da
deduplicao no dispute os recursos com as outras rotinas do sistema. Para a execuo
das tarefas foi usado o Apache Hadoop, que um framework para computao distribuda
baseado em Map/Reduce, o qual ajudou a aumentar a capacidade de escalabilidade do
projeto.
Todo o processo para deduplicao dos dados feito aps o armazenamento no
sistema, o que tm como desvantagem a necessidade do dado ser todo transferido para o
destino, para que depois seja analisado para eliminao de blocos duplicados. Com isso,
no existe a economia de banda que obtida com a deduplicao feita no cliente.
2.1.2
Design of an exact data deduplication cluster
Em [19], explicado sobre o funcionamento de um sistema que executa em cluster e

utiliza um tipo de deduplicao que eles chamam de "exact deduplication", que recebe
esse nome pelo fato do sistema conseguir detectar todos os chunks duplicados. Os
sistemas com exact deduplication geralmente possuem chunks com tamanho entre 4KB
e 16 KB. Sistemas que utilizam chunks grandes perdem muitas vezes a deteco da
redundncia, j a utilizao de chunks muito pequenos, apesar de aumentar a chance de

DEDUPLICAO
deduplicao, torna o sistema menos eficiente por causa da alta sobrecarga ocasionada
pela alta quantidade deles.
O HYDRAstor, descrito em [11], utiliza uma granularidade alta nos chunks (64KB)
para a deduplicao. Ele no faz o compatilhamento dos dados entre os ns e distribui os
chunks na rede atravs de uma DHT. A escolha da granularidade alta dos chunks para
aumentar o desempenho da deduplicao atravs da reduo do envio de metadados.
O sistema em [19] foi projetado para trafegar a menor quantidade de dados possvel
na deduplicao para aumentar a escalabilidade do mesmo. Basicamente o que trocado
entre as mquinas do cluster so fingerprints. O sistema descrito foi baseado no dedupv1
[26], o qual faz deduplicao em discos de estado slido (SSDs) para evitar gargalos de
leitura e escrita de dados.
Ele dividido nos seguintes componentes: deduplication nodes, shared storage,
interconnect between deduplication nodes, clients and distributed coordination. Os
deduplication nodes so responsveis por grande parte das funes mais importantes para
a deduplicao e gerenciamento dos dados no sistema, neles so feitas as quebras dos
dados em chunks e em seguida o clculo do fingerprint de cada um deles. Eles tambm
retornam os pedidos de chunks para outros ns e so responsveis pela escrita deles no
container de armazenamento.
Cada deduplication node tem acesso s vrias parties em que os discos so divididos pela rede atravs de storage area network (SAN) [39], as quais so redes de alta
velocidade para acesso dados. Cada partio s acessada por um nico n, caso
esse n falhe, a tarefa de gerenciamento da partio passada para outro n, essa
a responsabilidade do componente do sistema que chamado de shared storage. A
distributed coordination delegada para o Zookeeper 1 , um software de cdigo aberto
que integra o projeto Apache 2 e o qual o responsvel pela escolha dos ns mestres
e da deciso de qual deduplication node assumir o controle de determinada partio.
Cada delegao de controle das parties para os ns so armazenadas no Zookeeper e
gerenciada por um n mestre, no caso de uma falha ocorrer nesse mestre, o Zookeeper
eleger outro n para tomar o lugar do que falhou.
2.1.3
-Dedup
O -Dedup, que descrito em [14], um middleware de deduplicao de dados para

data centers e cloud storages. O -Dedup foi criado para otimizar a deduplicao de
1 http://zookeeper.apache.org/
2 http://apache.org

DEDUPLICAO
dados em clusters.
O -Dedup utiliza um conceito chamado de super-chunk, que um agrupamento de
chunks consecutivos. Com os super-chunks so calculados um handprint que ser enviado
para um conjunto de ns, que j possui um ndice de similaridade de todos os handprints
dos super-chunks armazenados nele para aumentar a eficincia e diminuir a consulta ao
disco. Os handprints dos super-chunks semelhantes so enviados para um mesmo n
para aumentar a probabilidade de encontrar chunks idnticos e com isso a eficincia da
deduplicao. Com o handprint, os ns efetuam um clculo para determinar a semelhana
entre ele e os demais que esto armazenados no n. Quando for encontrado o n que
possui um super-chunk mais semelhante ao que vai ser enviado, todos os fingerprints dos
chunks pertencentes ao super-chunk sero enviados para o n selecionado. Com esses
fingerprints o n verificar quais deles j esto armazenados e quais so novos. Depois
dessa identificao, o n pede ao cliente que est fazendo o backup apenas os chunks que
no foram encontrados.
Na Figura 2.1 os super-chunks do arquivo so identificados pelas letras. Eles so
enviados para ns diferentes, j que a escolha do n onde cada um deles ser enviado no
momento do backup depende da similaridade com os que esto armazenados nos ns.
A deduplicao no -Dedup feita nvel de n, logo, podem existir chunks duplicados se eles estiverem armazenados em diferentes ns.
Figura 2.1 Armazenamento dos super-chunks nos ns [43].
A arquitetura do -Dedup possui 3 componentes principais: o Backup Client, o

Deduplication Server Cluster e o Director.
O Backup Client tem como principal funo fazer o backup e o restore dos arquivos.
Ele composto de trs mdulos, um deles Data Partitioning que o responsvel pelo
10

DEDUPLICAO
particionamento do arquivo e agrupamento dos chunks em super-chunks. O clculo dos

fingerprints feito no mdulo Chunk Fingerprinting que uma camada abaixo do Data
Partitioning. O terceiro e ltimo mdulo do Backup Client o Similarity-aware Data
Routing, nesse mdulo que definido o n de deduplicacao para o qual os dados
sero enviados.
Por ser um sistema de deduplicao inline, o qual ser descrito na seo 2.2.2, os
dados so avaliados antes do envio para os ns e s so transferidos os chunks que ainda
no foram armazenados no sistema. Com isso, economizada a banda de transferncia
da rede.
O Deduplication Server Cluster tambm possui trs mdulos: Similarity Index Lookup, Chunk Fingerprinting Cache e Parallel Container Management. Eles so responsveis respectivamente por retornar o ndice de similaridade para o roteamento dos dados,
pelo armazenamento dos fingerprints mais utilizados em um cache para facilitar a busca
por chunks idnticos, e o ltimo o responsvel pelo armazenamento de forma paralela
dos chunks nicos nos containers.
Um outro trabalho similar ao -Dedup, onde os dados so enviados para determinados
ns baseados na similaridade, o Extreme Binning [5].
2.1.4
Dropbox
Apesar de no haver nenhuma declarao explcita na homepage do Dropbox 3 ,

segundo um artigo publicado no site Slight Paranoia, o mais popular sistema de armazenamento de dados em cloud [4] utiliza deduplicao de dados entre arquivos de usurios
distintos [37]. Se dois usurios enviarem o mesmo arquivo para o sistema, o Dropbox s
armazenar um deles nos seus servidores.
Segundo o mesmo artigo, o CTO da empresa declarou que o Dropbox utiliza deduplicao no Forum oficial da empresa, respondendo uma pergunta de um usurio que
questionava o porqu de um arquivo de 750MB ser enviado to rpido. Esse tpico no
est mais hospedado no forum, mas a resposta do CTO para a pergunta "Woah! How did
that 750MB file upload so quickly?"est no Slight Paranoia:
Dropbox tries to be very smart about minimizing the amount of bandwidth
used. If we detect that a file youre trying to upload has already been
uploaded to Dropbox, we dont make you upload it again. Similarly, if you
make a change to a file thats already on Dropbox, youll only have to upload
3 "http://dropbox.com"
11
2.2. DEDUPLICAO
the pieces of the file that changed. This works across all data on Dropbox, not
just your own account. There are no security implications [emphasis added]
- your data is still kept logically separated and not affected by changes that
other users make to their data."
Com a explicao do CTO, fica claro que o Dropbox utiliza deduplicao de dados,
mas o processo de deduplicao usado no Dropbox no detalhado pela empresa.
2.1.5
Concluso
Todos os sistemas de armazenamento estudados utilizam armazenamento de dados

baseado em chunks ou blocos de dados. Pelo fato de todos eles serem sistemas distribudos
para armazenamento de dados, precisam se preocupar com os problemas decorrentes
desse tipo de sistema descritos no trabalho sobre o Dynamo [9], como: robustez e
escalabilidade no balanceamento de carga, deteco de filiao e de falhas, entre outros,
os quais sero melhor descritos na seo 3.4.2. Como esse no o foco principal do
trabalho, para a resoluo desses problemas foi adotado para o Dedupeer File Storage
o banco de dados Cassandra, que funciona em uma rede P2P e j trata todos eles. Com
essa escolha ser possvel dedicar um maior tempo no que realmente interessa no estudo,
que o desenvolvimento do algoritmo de deduplicao.
Os sistemas comerciais, como o Dropbox, no tem seus algoritmos ou processo de
deduplicao detalhados publicamente, e os trabalhos acadmicos no possuem seus
algoritmos ou sistemas de deduplicao facilmente acessveis para utilizao em um
sistema de armazenamento. Esses foram os principais fatos que despertaram o interesse
em desenvolver um algoritmo, com um processo diferente dos descritos, de cdigoaberto e interopervel entre linguagens para ser facilmente integrado aos sistemas de
armazenamento existente.
2.2
Deduplicao
A deduplicao de dados um tcnica de compresso sem perda que elimina dados

redundantes tanto intra-file quanto inter-file, diferente de ferramentas de compresso de
dados como o gzip que s eliminam a redundncia intra-file. A deduplicao reduz a
quantidade de espao necessrio para armazenamento de dados atravs da eliminao
de blocos e/ou arquivos redundantes. Na deduplicao, todos os blocos de dados ou
arquivos que esto duplicados em um sistema de armazenamento so reduzidos uma
12
2.2. DEDUPLICAO
nica cpia, e os dados que foram desalocados so convertidos para uma referncia ao
contedo mantido no sistema.
As tcnicas de compresso de dados referem-se ao trabalho de dois algoritmos. H
o algoritmo de compresso, e o de reconstruo. O algoritmo de compresso pega um
arquivo X e gera uma representao Xc desse arquivo. O algoritmo de reconstruo
responsvel por pegar a representao gerada pelo algoritmo de compresso e transformla no arquivo Y. Baseado no funcionamento do algoritmo de reconstruo, a tcnica pode
ser classificada de dois modos: sem perdas (lossless), quando Y = X; e com perdas (lossy),
permite Y 6= X [33].
2.2.1
Localizao
A deduplicao distribuda pode ser feita tanto na entidade que envia os dados quanto
na que os recebe. Para facilitar, ser utilizado o padro cliente/servidor para explicar
as formas de deduplicao. A entidade que requisita o armazenamento do dado ser
referenciada como Cliente; a entidade de destino dos dados ser referenciada como
Servidor.
Cliente (source)
[25] descreve a deduplicao baseada no cliente como sendo a deduplicao feita
antes do cliente enviar seus dados para o servidor. O cliente faz o clculo e obtem o valor
do hash de um chunk, chamado de fingerprint, em seguida ele os envia para o servidor
de metadados, que faz a comparao com os fingertprints que esto armazenados para
poder identificar provveis dados redundantes no sistema. Ao receber as informaes, o
cliente executa uma busca de conjuntos de bytes redundantes e remove esses dados antes
de enviar o arquivo atravs da rede.
Esse tipo de deduplicao tem como vantagem a reduo da quantidade de dados trafegados na rede e reduo da sobrecarga de processamento no servidor. Em contrapartida,
h um consumo maior de CPU e I/O no cliente, pelo fato dele ser o executor da tarefa de
deteco de dados redundantes.
Um ponto crtico desta tcnica a capacidade que o cliente tem de identificar blocos
de arquivos armazenados no sistema e que so idnticos aos seus. O cliente precisa
saber os bytes dos blocos dos arquivos cujo fingerprint igual ao do seu para fazer a
comparao e verificar se os dados so realmente idnticos, j que mais de um bloco de
mesmo tamanho pode ter um fingerprint igual mesmo tendo contedos diferentes. Apesar
13
2.2. DEDUPLICAO
da probabilidade disso ocorrer ser quase zero, preciso garantir a integridade dos dados
armazenados pelos usurio, o que torna importante essa verificao byte a byte.
Servidor (target)
Considerada nessa categoria toda deduplicao que processada na entidade que
recebe os dados para armazenamento. Nela esto os appliances para armazenamento, storage arrays, peers de recebimento de dados em sistemas de armazenamento construdos
com arquitetura peer-to-peer, entre outros.
A deduplicao feita no servidor pode acontecer em dois momentos: inline e postprocessing. Eles sero descritos no prximo tpico.
Uma desvantagem dessa abordagem a centralizao do processamento para identificao de dados redundantes no servidor, o que pode ocasionar a sobrecarregar do
mesmo.
2.2.2
Momento
A deduplicao pode ser de dois momentos: Inline deduplication ou Post-process

deduplication [13].
Inline deduplication: os dados so examinados no momento em que chegam, antes
da escrita no sistema de armazenamento. Esse processamento antes da escrita pode
tornar o servidor um gargalo.
Post-process deduplication: a deduplicao feita depois que os dados so armazenados, em intervalos de tempo regulares ou quando um certo limite definido
alcanado. Esse tipo de deduplicao a melhor para ser utilizada em sistemas onde
a velocidade de recebimento de dados um fator crtico, j que o processamento
pode deixar pra ser feito quando o servidor estiver ocioso.
2.2.3
Algoritmo
Os algortimos para fazer a deduplicao so categorizados em trs tipos, segundo

[25]: Whole File Hashing, Sub File Hashing e Delta Encoding.
Whole File Hashing: aplicada alguma funo de hashing como o SHA1 [28] ou o
MD5[32] no arquivo todo, esse valor comparado com a base de armazenamento
de arquivos armazenados no sistema, caso algum outro arquivo possua o hash com
14
2.2. DEDUPLICAO
o mesmo valor, feita uma comparao byte a byte para ter certeza que os arquivos
so idnticos, se forem, um dos arquivos removido do sistema e o usurio ao qual
o arquivo apagado pertencia ter um referncia para o arquivo que idntico ao
seu.
Sub File Hashing: nessa categoria, o arquivo dividido em pedaos que podem
ser de tamanhos iguais, chamado de Fixed Block Hashing (FBH), ou variveis,
chamado de Variable Block Hashing (VBH). No algoritmo FBH, o arquivo todo
dividido em blocos de tamanho fixo, em seguida, aplicada alguma funo de hash
nos blocos para obteno dos fingerprints. O VBH utiliza o Rabin Fingerprinting
[30], a ideia de computar o fingerprint de cada blocos para apenas transferir os que
tm fingerprint diferente dos blocos que esto no computador de destino, com isso
possvel reduzir os dados trafegados na transferncia de arquivos que possuem
partes comuns aos arquivos do outro lado, mas esta tcnica tem um ponto que
precisa ser tratado. Quando qualquer dado inserido ou removido de um arquivo,
todos os fingerprints dos blocos subsequentes sero modificados se o algoritmo
utiliza blocos de tamanho fixo. O Rabin Fingerprinting utiliza uma janela deslizante
(rolling checksum e utiliza uma tcnica para subdividir os blocos que tenham maior
probabilidade de serem iguais a outros.
Delta Encoding/Compression (DE): com o Delta Encoding gerado um arquivo
conhecido como patch que um arquivo que tem informaes das diferenas
entre dois arquivos. Um algoritmo usado para identificar quais partes devem ser
copiadas e substituidas em um arquivo e quais partes devem ser inseridas para que
seja possvel remontar o arquivo apenas com as informaes das diferenas.
2.2.4
Benefcios
Um exemplo do benefcio que pode-se obter com a deduplicao foi apresentado pela
IBM. A IBM representou ganho de economia com um sistema de deduplicao baseado
em alteraes de 20% do contedo dos arquivos atravs da Figura 2.2 [17]. A Figura
mostra um backup inicial de 7TB de dados, e em uma semana o backup dos dados chegou
a 79TB de dados. Em um sistema de armazenamento sem a deduplicao, todos os 49TB
de dados seriam ocupados, mesmo se a alterao nos dados for de 20%, mas se esse
sistema usa deduplicao, possvel armazenar todo o contedo no sistema utilizando
apenas 8,45TB fsico no disco. Ainda no exemplo, em 30 dias seria necessrio 210TB de
disco para armazenamento em um sistema sem deduplicao, e de apenas 26,2TB para
15
2.3. SUMRIO DO CAPTULO
armazenar os mesmos dados em um sistema com deduplicao. grande o ganho de

economia que pode ser atingido com a utilizao de deduplicao.
Figura 2.2 Exemplo da economia de espao oferecida em um sistema de armazenamento com

20% de alterao nos dados.
2.3
Sumrio do captulo
Neste captulo, foi feita a descrio de alguns dos sistemas de armazenamento de

dados, que utilizam deduplicao e fornecem detalhes sobre como ela feita. Alguns dos
problemas enfrentados por esses sistemas, que no tm relao direta com a deduplicao,
s com o armazenamento distribudo, ser atribudo ao Cassandra, que vai ser usado
como base para o gerenciamento dos dados do Dedupeer File Storage, fazendo com que
o foco principal do trabalho, que o algoritmo de deduplicao, tenha um maior tempo
para ser dedicado na pesquisa.
A utilizao de chunks para o processo de deduplicao, apesar de ser bvio, foi
confirmado como base em todos os sistemas que fornecem esse servio. Neste captulo
16
tambm foi feita uma introduo sobre o que deduplicao e quais so os seus tipos.
No prximo captulo, ser feito um aprofundamento no desenvolvimento do Dedupeer
File Storage, o modelo de dados utilizado, algumas decises de projetos que foram
tomadas e ser detalhada a viso de componentes e conectores do mesmo.
17
3
O Dedupeer File Storage
3.1
Introduo
O Projeto Dedupeer composto pela biblioteca homnima e pelo Dedupeer File

Storage (DeFS), que foi desenvolvido para facilitar os testes e avaliao dos algoritmos
implementados para a deduplicao, que a principal contribuio deste trabalho.
Para representar de forma simples a comunicao entre o componente, o sistema
de arquivos e o sistema de armazenamento que adicionar o componente, foi usado o
diagrama de componentes 3.1. Observando a interao entre os artefatos que compem
todo o sistema para deduplicao, percebe-se que o acesso aos arquivos abstrado pelo
Dedupeer. De uma forma transparente para o sistema de armazenamento o Dedupeer
ler, quebrar, e processar os bytes do arquivo especificado, levando em considerao os
parmetros passados pelo sistema atravs da interface de comunicao Thrift 1 . O Thrift
ser melhor detalhado na seo 4.2.1.
O DeFS foi desenvolvido para ocupar o lugar no diagrama que pertence aos sistemas
de armazenamento de dados. Com a arquitetura planejada dessa forma, fica fcil fazer a
integrao do algoritmo em muitos sistemas. O Thrift d suporte comunicao entre
diversas linguagens, o que aumenta a quantidade de sistemas que podem ser integrados
ao Dedupeer.
3.1.1
Escopo
O Dedupeer File Storage um sistema de armazenamento de dados, que pode ser

usado de forma distribuda, com capacidade de armazenamento e recuperao de arquivos.
1 http://thrift.apache.org/
18
3.2. O SISTEMA DE ARMAZENAMENTO DISTRIBUDO
Figura 3.1 Diagrama de componentes de alto nvel da biblioteca do Dedupeer
Apesar de poder ser usado de forma distribuda, como escopo deste trabalho s ser
considerado a utilizao dele em uma mquina simples.
3.2
O sistema de armazenamento distribudo
Para facilitar os testes e a validao dos algoritmos, foi desenvolvido um sistema de

armazenamento que tem como base o banco de dados no relacional desenvolvido dentro
do Facebook, e hoje projeto incubado no Apache Foundation, chamado Cassandra2 . O
Cassandra foi desenvolvido com o objetivo de ser escalvel e altamente disponvel.
Para mais informaes sobre a escolha do banco de dados para ser usado como base
do sistema de armazenamento, ele descrito em detalhes na seo 3.4.2.
3.2.1
Modelo de dados
Pelo fato do Cassandra ser um banco de dados NoSQL, tambm conhecido como
banco de dados no relacional, o seu modelo de dados totalmente diferente dos utilizados
nos bancos relacionais, os quais possuem tabelas com colunas, cada registro na tabela
adicionado em uma nova linha, com toda linha tendo que ter a mesma quantidade de
colunas das outras e etc. Como a maioria das pessoas est acostumada com essa forma
de organizao de um banco de dados, ser feita uma breve apresentao do modelo de
dados utilizado no Cassandra, para facilitar o entendimento sobre as escolhas de projeto
para a modelagem do sistema de armazenamento.
2 http://cassandra.apache.org/
19
No modelo de dados do Cassandra existe uma flexibilidade muito grande sobre como
estruturar os dados. A forma mais simples de dado que se pode armazenar uma lista
ou array. Com a adio de uma nova dimenso possvel transformar essa lista em um
Map e deixar os dados mais organizados. Essa nova dimenso pode servir para nomear
os dados da dimenso citada primeiramente, o que torna o modelo um pouco parecido
com a estrutura utilizada no relacional. Abaixo tem um exemplo de um registro simples
no modelo de dados do Cassandra [16].
"Paulo Fernando":
"email": "paulo@paulofernando.net.br",
"idade": "25"
Essa esttutura tem como chave o valor "Paulo Fernando". A primeira dimenso,
citada acima, seria os valores que representam os nomes das colunas "email"e "idade".
A considerao desses valores como nome de coluna apenas organizacional, pois eles
no precisam ser necessariamente uma string, o valor armazenado em qualquer uma das
dimenses pode ser at dados binrios com limite de 2 GB, mas para melhor estruturao
a maioria dos bancos usam esse valor como uma string ou um long para representar
um identificador para o valor da segunda dimenso, que est sendo representada no
exemplo pelos valores "paulo@paulofernando.net.br"e "25". Todos esses valores juntos
representam uma linha, e a reunio das linhas recebe o nome de famlia de colunas. As
famlias de colunas so associadas a um keyspace, que um container de famlia de
colunas, e que seria o equivalente a um banco de dados no modelo relacional. Cada
instncia do Cassandra pode ter vrios keyspaces.
Alm da coluna normal, representada pelos pares dos valores no exemplo acima,
como por exemplo, "idade": "25", existe tambm a chamada super coluna, que um tipo
especial de coluna que possui uma estrutura mais complexa, onde existe um campo que
usado como identificao e uma agregao lgica de colunas simples. O exemplo abaixo,
demonstra como seria um conjunto de dados representado por uma super coluna.
"Paulo Fernando":
"endereo"
"rua": "Rua ABC",
"nmero": "123"
"informaes pessoais"
20
"email": "paulo@paulofernando.net.br",
"idade": "25"
O Cassandra, quando utiliza super colunas, funciona como uma hastable de 5 dimenses [Keyspace] [ColumnFamily] [Key] [SuperColumn] [SubColumn] [16]. Para acessar
a "idade"de "Paulo Fernando", por exemplo, o caminho seria [Keyspace] [ColumnFamily]
["Paulo Fernando"] ["informaes pessoais"] ["idade"], onde Keyspace e ColumnFamily
teriam que ser previamente criadas no Cassandra para que esses dados pudessem ser
armazenados dentro da ColumnFamily.
Toda a estrutura que foi definida para o sistema de armazenamento desenvolvido est
representado na Figura 3.2. A escolha da estrutura utilizada ser discutida a seguir.
Foram definidas duas famlias de super colunas para armazenar e organizar os dados
dos arquivos: UserFiles, Chunk; e um famlia de colunas para agilizar o processo de
identificao do arquivo: Files.
Na famlia de super colunas UserFiles, a chave representada pelo nome do usurio.
O nome da super coluna definido como sendo o nome do arquivo, no caso do exemplo
o arquivo se chama "lorem.txt". Foram definidas seis subcolunas para essa famlia:
file id
Armazena o identificador nico do arquivo no sistema.
size
Armazena o tamanho do arquivo em bytes.
chunks
Armazena a quantidade de chunks em que o arquivo foi dividido.
with content
Armazena a quantidade de chunk que possui contedo
without content
Armazena a quantidade de chunks que no possui contedo. Este valor representa a
quantidade de chunks que so referncias chunks que esto duplicados no sistema.
A criao das colunas with content e without content foi uma deciso para aumentar o
desempenho evitando ter que consultar todos os chunks do arquivo para identificar quais
deles so referncias e quais armazenam o contedo. A criao de apenas um dos dois
resolveria o problema, mas nesse caso, para a identificao do outro valor seria necessrio
21
a consulta da quantidade total de chunks, ento foi tomada a deciso de j armazenar o

valor calculado.
Na famlia de super colunas chamada Chunk a chave que identifica a linha o
identificador nico do arquivo, localizado na coluna com nome file id na famlia de super
colunas UserFiles. Cada linha representa as informaes de todos os chunks pertencentes
ao arquivo referenciado. Cada arquivo s tem uma linha nessa famlia de super colunas.
As subcolunas dessa famlia so detalhadas abaixo.
md5
Armazena o valor do fingerprint representado por um valor do clculo de uma
funo SHA-1 sobre os dados do chunk atual.
hash32
Armazena o valor do fingerprint representado por o resultado do clculo de uma
hash de 32 bits sobre os dados do chunk.
index
Armazena a posio do incio do chunk dentro do arquivo completo. Por exemplo,
se ele for o primeiro segmento do arquivo, esse valor ser 0, se ele for o segundo
segmento do arquivo e o primeiro segmento tiver 512 bytes de tamanho, esse valor
ser 512.
length
Armazena a quantidade de bytes que o chunk possui.
content
Armazena o contedo binrio que se inicia na posio index e vai at a posio
index + length dentro do arquivo. Armazena a quantidade de bytes que o chunk
possui.
pfile
Armazena o identificador do arquivo ao qual o segmento referenciado pertence.
pchunk
Armazena o identificador do segmento ao qual foi identificado que o conjunto de
dados idntico. Em outras palavras, adiciona uma referncia ao segmento que
possui o contedo que no foi armazenado no sistema por ser duplicado.
22
Percebe-se a flexibilidade da utilizao do Cassandra nessa famlia de colunas, na

mesma famlia de colunas so armazenados dois tipo estruturais de dados, um para
representar um segmento com contedo binrio e outro para representar uma referncia
para um outro segmento j armazenado no sistema. Para uma melhor visualizao dessa
famlia de super colunas, elas sero detalhada na Figura 3.2.
A famlia de colunas chamada Files bem simples, ela apenas uma atalho de
consulta para o identificador de um arquivo de um determinado usurio baseado no nome
desse arquivo. A chave dessa famlia de colunas o nome do usurio. Ela possui apenas
uma coluna que tem o nome do arquivo do usurio e o id desse arquivo.
23
Figura 3.2 Modelo de dados do sistema distribudo desenvolvido com o Cassandra
24
3.3. VISO DE COMPONENTES E CONECTORES
3.3
Viso de componentes e conectores
Nesta seo ser descrito o funcionamento em tempo de execuo do Dedupeer Project, que engloba DeFS integrado com o Dedupeer. A viso de componentes e conectores
do Dedupeer Project pode ser vista na Figura 3.3. Existem 3 grandes componentes no
sistema: O DeFS, o Dedupeer e Cassandra, os quais sero descritos a seguir:
DeFS
O Dedupeer File Storage o sistema distribudo de armazenamento de dados que
foi desenvolvido na pesquisa para que os algoritmos de deduplicao propostos
pudessem ser testados com maior facilidade. O DeFS foi descrito na seo 3.2.
Dedupeer
O Dedupeer a biblioteca onde os algoritmos propostos foram implementados.
Ele possui uma interface Thrift para interoperabilidade de comunicao entre
linguagens de programao distintas, para facilitar a integrao do mesmo com
a maioria dos sistemas de armazenamento existentes. O componente Dedupeer
ser descrito no captulo 4, e o funcionamento dos algoritmos do Dedupeer sero
descritos no captulo 5.
Cassandra
O Cassandra um banco de dados distribudo que foi usado como base do sistema
de armanzenamento DeFS. Mais informaes sobre o Cassandra na seo 3.4.2.
O componente Dedupeer File Storage

O componente GUI o que apresenta a interface com o usurio atravs de uma janela
com componentes grficos. Esse componente ainda possui os renderizadores dos campos
da tabela de listagem dos arquivos e o frame de configurao dos parmetros que ficam
armazenados no arquivo. Ele tem ligao com as filas de backup (BackupQueue) e de
restore (RestoreQueue) dos arquivos, as quais so incrementadas com novos itens atravs
da interao do usurio. Os componentes para gerenciamento das filas de backup e
restore (tambm conhecido como reidratao no contexto de deduplicao) funcionam
com uma LinkedBlockingQueue como base, que uma fila com propriedade FIFO
(first-in-first-out).
O componente StoredFile o item usado tanto na fila de backup como na de reidratao, esse o componente central do DeFS. Ele responsvel pelo gerenciamento do
25
3.3. VISO DE COMPONENTES E CONECTORES
Figura 3.3 Viso de componentes e conectores do DeFS integrado com a biblioteca do Dedupeer
processo de backup, reidratao e clculo de economia de espao. Tem ligao com o

Dedupeer atravs do ThriftClient e indireta com o Cassandra atravs do componente de
gerenciamento de dados que foram agrupados em DaoOperations. O ThriftClient, como
o nome j diz, um cliente Thrift para fazer a comunicao com a biblioteca Dedupeer.
O Componente Chunking usado para quebrar o arquivo em chunks para que sejam
enviados para o Cassandra. Ele usado apenas quando no requisitada a utilizao
da biblioteca do Dedupeer, j que na deduplicao o Dedupeer j retorna todas as
informaes sobre os chunks do arquivo, no sendo necessrio nesse caso a diviso dos
chunks atravs do componente Chunking.
O componente Dedupeer
O componente Dedupeer possui apenas dois componente internos, o ThriftServer e o
DeduplicationImpl. O ThriftServer o servidor que fica esperando por comunicaes
dos clientes Thrift, ele que roda o servio que espera pelos parmetros necessrios
26
3.4. DECISES DE PROJETO E CONSIDERAES
para o processamento da deduplicao, processamento esse que executado dentro do

DeduplicationImpl, o qual retorna a estrutura gerada atravs do processamento para o
ThriftServer para que este o envie de volta ao ThriftClient.
3.4
Decises de projeto e consideraes
Nesta seo sero discutidas as principais escolhas de tecnologias ou conceitos feitas

na construo do Dedupeer File Storage e o motivo dessas escolhas. A tecnologia que foi
escolhida ser detalhada e as vantagens da sua escolha sero destacadas.
3.4.1
Tamanho do chunk
A definio do tamanho padro do chunk muito importante e no pode ser feita sem
um estudo sobre as consequncias da escolha. Esse valor impacta tanto no desempenho
do sistema como no raio de compresso mdio que pode ser obtido na deduplicao.
Quanto menor for o tamanho de um segmento, maior ser o raio de compresso pelo fato
de haver uma maior probabilidade de encontrar outros segmentos idnticos, j que um
menor conjunto de bytes precisar ser igual. Em contrapartida, com segmentos pequenos
ser preciso processar uma maior quantidade deles, e a depender da implementao,
acessar o disco mais vezes, o que degrada o desempenho do sistema. E como cada chunk
requer uma mesma quantidade de metadados, independente do seu tamanho, ter chunks
pequenos ocasiona um maior espao necessrio para armazenamento.
Um projeto deve possuir o menor segmento possvel, contanto que ele no degrade o
desempenho do sistema ponto de ficar abaixo das especificaes requeridas. O trabalho
[46] afirma que depois dos testes executados para medir o tamanho ideal, eles encontraram
o valor de 8 KB [46], que o mesmo valor encontrado pelos criadores do Venti [29].
O trabalho [19] relata que o tamanho do chunk para um sistema de deduplicao exata
(exact deduplication), deve estar entre 4KB e 16 KB [19].
Esses valores sero levados em conta aps o teste de desempenho que ser feito para
identificar a melhor combinao de tamanho de chunk e algoritmo de hashing no Captulo
6.
3.4.2
Cassandra para gerenciamento do armazenamento
Muitos dos desafios enfrentados quanto ao desenvolvimento de um sistema de armazenamento distribudo so delegados para serem resolvidos atravs do gerenciamento
27
executado pelo Cassandra. Alguns desses desafios so citados no artigo sobre o Dynamo,
entre eles, robustez e escalabilidade no balanceamento de carga, deteco de filiao e
de falhas, recuperao de falhas, concorrncia e agendamento de tarefas (jobs), e empacotamento de requisies [9]. Alm desses, existem outros desafios como, garantia de
disponibilidade e consistncia dos arquivos, replicao dos dados e tamanho e quantidade
das mensagens trafegadas. Nesta seo ser discutida a forma como o Cassandra resolve
todos esses problemas.
O Cassandra foi desenvolvido em uma arquitetura peer-to-peer, tambm conhecida
como P2P, que uma das arquiteturas comuns existentes na internet, alm dela, a outra
arquitetura a CLiente/Servidor. Na arquitetura Cliente/Servidor, existe no mnimo duas
entidades, uma que requisita um recurso e outra que atende a essa requisio, nessa
arquitetura os ns agem de uma forma ou de outra, nunca as duas ao mesmo tempo. Na
arquitetura P2P as entidades se comportam tanto como clientes quanto como servidores,
consumindo e oferecendo recursos na rede.
O trabalho [36] define P2P como uma rede na qual os ns compartilham parte dos
seus recursos de hardware, entre eles, processamento, capacidade de armazenamento,
impressora, entre outros. Esses recursos compartilhados so essenciais para os servios e
contedos oferecidos pela rede, como, por exemplo, compartilhamento de arquivos.
A arquitetura P2P dividida em dois tipos, as chamadas arquitetura P2P pura e hbrida.
[36] define a arquitetura P2P pura se ela est classificada dentro definio anterior e,
alm disso, se qualquer n da rede puder ser removido sem que a rede sofra qualquer
perda. O mesmo trabalho define que uma arquitetura P2P dita hbrida quando ela est
classificada na primeira definio de P2P e, alm disso, uma entidade central necessria
para fornecer parte do servio que a rede se dispe a oferecer [36].
No Cassandra, a arquitetura P2P usada foi a pura. Todo n no Cassandra idntico
aos outros, no existe n mestre e nem n escravo. Com essa estrutura, a escalabilidade
horizontal se torna mais fcil, j que s preciso adicionar um novo n no cluster para
que ele se integre e se organize dentro da rede, para isso, ele possui um tempo para
aprender como est a topologia do anel (a rede do Cassandra funciona como um anel).
Depois da descoberta de como a rede est topologicamente estruturada o n comea a
receber como qualquer outro que integra rede.
O Cassandra utiliza o prprio sistema para armazenar as informaes de configuraes
dele. Todas essas informaes so armazenadas dentro do Keyspace chamado system.
Entre essas informaes esto o token do n, o nome do cluster, definies de schema,
entre outras. Esse Keyspace no pode ser modificado pelo usurio.
28
Tolerncia falhas
O Cassandra usa o gossip protocol[22] para a deteco de falhas. Periodicamente,
uma mensagem enviada para um outro n, quando o n recebe a mensagem ele responde
com um Ack, quando a mensagem recebida pelo n que a iniciou, ele responde com
um Ack2. Com a utilizao desse protocolo possvel identificar os ns que pararam de
funcionar. O Cassandra ainda usa um algoritmo que ao invs de apenas informar se um
sistema ou no confivel, ele retorna uma valor que o nvel de suspeita, esse algoritmo
chamado de Phi Accrual Failure Detection [10]. O Cassandra possui um mtodo que
ajuda na deciso se um n est morto ou no, baseado no valor do nvel de suspeita, com
assinatura interpret(InetAddress), onde InetAddress representa o endereo do n.
Recuperao de falhas
Todo sistema que utiliza gossip protocol deve ter um mecanismo para tratar os
problemas decorrentes da sua utilizao, o principal deles chamado de anty-entropy e
um mecanismo para sincronizao de rplicas, que assegura que os valores das rplicas
armazenados nos ns estejam atualizados com a verso mais recente. Durante a fase
de compactao, os ns fazem a requisio das rvores Merkle dos vizinhos para poder
comparar com a sua rvore e assim poder identificar possveis valores desatualizados.
A rvore Merkle funciona como um snapshot da famlia de colunas atual, ela uma
rvore que possui os valores dos hashes dos dados armazenados nas famlias de colunas,
esses valores so comparados com os do n requisitante, se caso for encontrado algum
valor diferente, feito o reparo nos dados atualizando-os para a verso mais recente [36].
Anti-entropy tambm usado no Dynamo [9], mas o Cassandra faz um uso diferente, na
implementao do Cassandra existe uma rvore Merkle para cada famlia de colunas. O
algoritmo de anti-entropy executado depois de cada atualizao no banco de dados.
As operaes de escrita no Cassandra so feitas primeiramente em um log que
chamado de commit log. Este mecanismo tem como finalidade possibilitar a recuperao
de uma escrita mal sucedida. A escrita s marcada como feita quando a operao salva
no commit log, com ele possvel recuperar uma falha na escrita feita em memria. Aps
a escrita no commit log o dado salvo em uma estrutura de dados alocada na memria
que chamada de Memtable. O Memtable s ter os dados salvos no disco quando ele
atingir um limite de objetos armazenados. A estrutura aonde os dados so salvos no disco
chamada de SSTable.
29
Write.ANY
Write.ONE
Write.QUORUM
Write.ALL
Read.ONE
Weak
Weak
Weak
Strong
Read.QUORUM
Weak
Weak
Strong
Strong
Read.ALL
Weak
Strong
Strong
Strong
Tabela 3.1 Fora do consistncia baseada nos nveis das operaes [8]
Consistncia
A consistncia dos dados que so armazenados no Cassandra tem o seu nvel definido
pelo usurio. A consistncia pode ser usada como valor ONE (consistncia fraca), nesse
nvel de consistncia o Cassandra pode retornar o dado encontrado no primeiro n
consultado sem verificar se aquele o valor mais recente. No caso de existir muitos
clientes na rede, recomendvel ter um nvel de consistncia no mnimo QUORUM,
que um nvel no qual o Cassandra precisa ler de vrios ns antes de retornar o valor,
o que assegura que o sistema encontrar o valor do dado mais recente. No nvel de
consistncia ALL, o Cassandra consulta os dados armazenados em todos os ns antes de
retornar o valor. Se uma das consistncias fortes forem utilizadas (QUORUM ou ALL), a
recuperao de falhas, conhecida como read-repair executa antes do dado ser retornado.
O CAP Theorem descreve um sistema distribudo com relao trs aspectos: consistncia, disponibilidade e tolerncia partio. O teorema diz que impossvel que um
sistema distribudo possua os trs aspectos ao mesmo tempo, sempre um desses aspectos
tem que ser sacrificado. O Cassandra tem flexibilidade e permite que o usurio escolha
os aspectos do CAP Theorem que esto no sistema. A tabela 3.1 mostra qual o nvel de
consistncia do Cassandra a depender das escolhas do usurio [8].
O quorum o nmero de ns que deve ser consultado para se chegar a um consenso
sobre a validade do dado (pode ser ANY, ONE, QUORUM ou ALL). Se o valor do
quorum for ONE, o dado s ser armazenado em um nico n, o que vai torn-lo
sempre consistente, mas em contrapartida, ele nunca ser replicado, o que diminui a
disponibilidade do mesmo.
Disponibilidade
O Cassandra possui um mecanismo para disponibilidade de escrita mesmo quando o
n que receberia a mensagem tem uma falha de hardware, ou qualquer outra que o impea
de receber a mensagem, esse mecanismo chamado de hinted handoff. Quando um n
tenta enviar uma mensagem para um outro que no pode ser alcanado por alguma falha,
30
o n remetente grava a mensagem em uma rea do keyspace system para que quando o n
onde a mensagem deveria ser escrita voltar, ela possa ser enviada e persistida.
Empacotamento de requisies
A troca de mensagens entre os ns feita atravs de um servio. As mensagens
que chegam so encaminhadas para um pool de threads, o qual responsvel pelo
gerenciamento delas. Em seguida, analisado se a mensagem do tipo streaming, que
uma forma eficiente utilizada pelo Cassandra para fazer a transferncia de SSTable entre
os ns, ou se uma mensagem serializada padro, e a partir disso determinado para
qual manipulador ela ser atribuda.
3.4.3
Alternativa para o gerenciamento de armazenamento
Foram analisados alguns pontos para a escolha entre o Cassandra e o HBase para ser
usado no Dedupeer File Storage. Os pontos considerados crticos para a escolha e que
fizeram com que o Cassandra fosse escolhido foram: facilidade de instalao/manuteno
e funcionamento em pequenos clusters. Esses foram os pontos considerados mais importantes pelo fato do objetivo ser a criao de um sistema para armazenamento de arquivos
que funcionasse tanto como um sistema de armazenamento stand-alone como um sistema
de armazenamento distribudo, e que fosse fcil de manter e instalar.
Facilidade de instalao e manuteno
O HBase mais complexo para ser gerenciado pelo fato de ter sido desenvolvido para
dar suporte ao Hadoop, logo ele mais complicado de ser gerenciado j que por padro
ele est integrado com o Hadoop, HDFS e Zookeeper3 . O Cassandra no tem por padro
essa ligao com outros sistemas, ele mais fcil de instalar e manter que o HBase.
Clusters pequenos
Segundo o site oficial do HBase4 , ele no adequado para ser usado em um cluster
com menos de 5 DataNodes, o que inviabilizaria a possibilidade da utilizao do Dedupeer
File Storage em um computador stand-alone. Esta foi uma funcionalidade colocada como
prioritria no projeto, pois ela til para conseguir a economia de espao proporcionada
3 http://whynosql.com/cassandra-vs-hbase/.
Acessado em abril de 2013

Acessado em abril de 2013
4 http://hbase.apache.org/book/architecture.html.
31
pela deduplicao em computadores, sem que para isso precise criar um sistema de
armazenamento distribudo.
O HBase precisa de mais ns porque ele dependente do HDFS, e o HDFS utiliza
uma replicao de blocos de 3 cpias.
3.4.4
Escalabilidade
Primeiramente, o conceito do que escalabilidade ser descrito, antes da apresentao das vantagens que a escolha do Cassandra para gerenciamento do sistema de
armazenamento oferece para a escalabilidade.
O que escalabilidade?
Construir arquitetura de sistema para dar suporte milhes de usurios um dos
maiores desafios enfrentados pela indstria de software. Esse desafio fica mais complexo
quando a arquitetura projetada para escalar e se adaptar quantidade de usurios sem
precisar ter que reprojet-la.
Quando se fala em escalabilidade, uma quantidade prxima a 100% dos engenheiros
de software s conseguem enxergar sistemas que escalam para mais usurio (scale up),
mas escalabilidade tambm est relacionado capacidade do sistema em escalar para
suportar menos usurios (scale down), ou seja, ele deve ser capaz de reduzir a quantidade
de recursos alocados quando a demanda de usurios diminuir [34].
Existem dois tipos de escalabilidade de sistemas: horizontal (scale up) e vertical
(scale out). Escalabilidade vertical a capacidade de adicionar recursos a um n do
sistema e ele se adequar nova configurao. Escalabilidade horizontal a capacidade
do sistema se adequar adio de novos ns.
Quando um sistema precisa escalar horizontalmente (scale up), um forte sinal de
que a demanda por ele est crescendo, esse fator um indcio de que o lucro da empresa
tambm est crescendo junto. Quando isso acontece, e a arquitetura do sistema foi
pobremente planejada para escalar horizontalmente, a empresa pode investir parte dos
lucros obtidos com a quantidade de usurio para solucionar o problema de escalabilidade,
mesmo que no seja pela melhor forma. O maior problema que quando essa demanda cai
bruscamente, os lucros da empresa com o sistema geralmente tambm caem, e a empresa
tenta ao mximo reduzir os custos. Percebe-se que se a arquitetura no planejada para
scale down, a perda de dinheiro com a reduo de cliente pode se tornar maior, j que a
quantidade de recursos alocados para o sistema se tornam ociosos por ter sido reservado
32
para atender a uma quantidade de usurios muito maior do que a real.

Escalabilidade com o Cassandra
Com a escolha de um banco de dados NoSQL, distribudo, e alto gerencivel, a
questo da escalabilidade um outro ponto que o Dedupeer File Storage no precisar se
preocupar, j que todo o gerenciamento feito pelo cluster de Cassandras.
3.5
Sumrio do captulo
Este captulo apresentou o Dedupeer File Storage, que foi sistema de armazenamento
de arquivos desenvolvido para auxiliar a pesquisa, e que pode ser usado tanto um sistema
de armazenamento local como um sistema de armazenamento distribudo. Ele integrado
atravs da interface Thrift com o componente para deduplicao de arquivos, o qual ser
descrito em detalhes no prximo captulo.
Foi discutido o modelo de dados utilizado, a viso de componentes e conectores do
sistema integrado com o componente para deduplicao e as principais decises de projeto,
como a escolha do Cassandra para gerenciamento dos dados. Os benefcios relacionados
utilizao do Cassandra tambm foram detalhados, o qual ficou responsvel por tratar
os problemas comuns enfrentados na criao de sistemas de armazenamento distribudos.
O Prximo captulo apresentar o componente para deduplicao de arquivos e
detalhar as principais decises de projeto no seu desenvolvimento.
33
4
Componente para deduplicao em
sistemas de armazenamento de dados
4.1
Introduo
O desenvolvimento do Dedupeer foi planejado para que os algoritmos desenvolvidos

pudessem ser usados pela comunidade de forma fcil. O Dedupeer foi projetado para
que as escolhas de configuraes fossem feitas atravs de parmetros da interface de
servio, entre essas configuraes esto o tamanho do chunk e o algoritmo de hashing.
O Dedupeer tambm foi desenvolvido para que pudesse ser usado por qualquer sistema
de armazenamento que tenha como objetivo obter um ganho na economia de espao
utilizado, o que traz benefcios tanto para o fornecedor, por ter mais espao para oferecer,
quanto para o meio ambiente.
O chamado Green Storage Initiative(GSI) 1 liderado pelo SNIA (Storage Networking
Industry Association) em parceria com empresas como Dell, EMC, HP, IBM, Oracle,
NetAPP, Seagate, entre outras. Na GSI so discutidas tcnicas que diminuam o impacto
do uso de sistemas de armazenamento ao meio ambiente. Das discusses sobre uso
eficiente dos sistemas de armazenamento, a EPA liberou um documento de especificao
para discusso pblica, onde deduplicao de dados considerada umas das tecnologias
da green storage [12], veja na citao abaixo.
"EPA understands that there are many software-based approaches to improving the energy efficiency of storage products. The benefits of virtualization,
data deduplication, and other software-based data management techniques
are well documented. These software solutions, perhaps even more so than
1 http://www.snia.org/forums/green
34
4.2. INTEROPERABILIDADE
the hardware itself, are heavily customized for specific customers and applications. Achieving maximum efficiency gains is highly dependent upon
proper software architecture, implementation, operation, and maintenance
by individual users."
Nas sees seguintes sero detalhadas as decises de projeto que foram tomadas, assim
como uma tcnica utilizada para tornar o processamento da deduplicao temporalmente
vivel.
4.2
Interoperabilidade
Engenharia de Software baseada em componentes desperta muito interesse devido

a reusabilidade do software. O seu objetivo reduzir o custo e o esforo no desenvolvimento, enquanto prover flexibilidade, confiabilidade e reusabilidade, pelo fato do
componente j ter sido validado e testado antes da integrao [41].
Um dos principais conceitos chave para a criao de componentes de software reusveis a interoperabilidade. A Interoperabilidade foi definida por [41] como a habilidade
de duas ou mais entidades se comunicar ou cooperar, apesar das diferenas na linguagem
de implementao, ambiente de execuo, ou modelo de abstrao. Existem dois nveis
de interoperabilidade: assinatura e semntica. A primeira baseada na assinatura das
operaes que o componente disponibiliza para interao, como por exemplo, nome de
mtodos, tipos dos parmetros e valores de retorno. A interoperabilidade semntica tenta
garantir que a troca de dados entre os componentes faa sentido, mas pelo fato desse nvel
de interoperabilidade englobar todos os aspectos semnticos, ele considerado muito
complexo, o que direcionou a maioria dos trabalhos sobre esse nvel para uma de suas
reas, relacionada s questes comportamentais dos componentes [41].
O Dedupeer foi desenvolvido com o nvel de interoperabilidade de assinatura, a qual
definida e disponibilizada atravs do Thrift, que ser detalhado na seo seguinte.
4.2.1
Interoperabilidade de comunicao atravs do Thrift
O Thrift foi um projeto que surgiu dentro do Facebook e hoje gerenciado pela Apache Software Foundation2 . Ele possui uma ferramenta de gerao de cdigo para facilitar
o desenvolvimento da criao dos servios em diversas linguagens de programao. O
principal objetivo do Thrift fornecer a capacidade de comunicao entre linguagens de
2 http://thrift.apache.org/
35
programao distintas. O Thrift permite que os desenvolvedores definam tipos de dados

e servios em um arquivo de linguagem neutra e gera toda a estrutura necessria, tanto
para o servidor como para o cliente RPC (remote procedure call) [3].
O Thrift tem flexibilidade para a criao de estruturas de dados, alm de tambm dar
suporte aos principais tipos, independente da linguagem utilizada. Como tipo base, o
Thrift possui os seguintes:
bool Um valor booleano, true ou false.
byte Um byte assinado.
i16 Um inteiro assinado de 16 bits.
double Um nmero de ponto flutuante de 64 bits.
string Um conjunto de caracteres.
Alm desses tipos de dados mais simples, existem estruturas de dados mais complexas
que podem ser usados para a comunicao entre linguagens com o Thirft. Para isso, ele
faz as converses entre as estruturas definidas nessas linguagens. As 3 estruturas de dados
que podem ser usados no Thrift so:
list<type> Um lista ordenada de elementos. Essa estrutura traduzida em um ArrayList
em Java ou em array nativo nas linguagens de script.
set<type> Um conjunto no ordenado de elementos nicos. Traduzido para HashSet em
Java.
map<type1,type2> Um mapa chave/valor. Em Java ele traduzido para um HashMap.
Ainda relacionado utilizao de estruturas mais complexas, pode-se criar estruturas
equivalente objetos para serem transferidas atravs do Thrift, os quais so chamados
structs. Dentro de um structs pode-se adicionar quantos tipos forem necessrios, os quais
podem ser opcionais ou obrigatrios. Quando um campo configurado como obrigatrio,
o construtor do objeto receber o campo como parmetro, caso o campo seja configurado
como opcional, o objeto ter um mtodo que poder ser usado para adicionar um valor ao
campo e ele no ser um dos parmetros do construtor.
36
O Thrift possui o conceito de servios, os quais so definidos no mesmo arquivo que

os tipos. Com a gerao automtica do cdigo atravs do compilador do Thrift, toda a
estrutura necessria para que o servio funcione criada, tanto a parte cliente como a
parte servidora, s preciso implementar o algoritmo que funcionar dentro do servio.
Os servios so definidos no Thrift da seguinte forma:
service <name> {
<returntype> <name>(<arguments>)
[throws (<exceptions>)]
...
}
A escolha do Thrift para o projeto ser discutida a seguir.
4.2.2
Comparao com o Protocols Buffer
Nesta seo ser discutida a escolha do Apache Thrift como opo para a serializao
dos dados trocados entre o sistema de armazenamento e o Dedupeer. O Thrift ser
comparado com um outro mecanismo parecido com ele e que tambm muito utilizado
nos sistemas atuais, o Protocols Buffer.
Protocols Buffer
O Protocols Buffer foi desenvolvido na Google e utilizado internamente em quase
todos os seus protocolos RPC [23]. Segundo o Developer Guide [1], o Protocols Buffer
uma forma extensvel de serializao de dados estruturados que possui linguagem neutra,
e tem a finalidade de ser usado em protocolos de comunicao, armazenamento de dados,
entre outras.
O Protocols Buffer possui uma boa documentao, diferente do Thrift onde a documentao bem reduzida. Ele d suporte apenas 3 linguagens: C++, Java, Python.
Isso acaba limitando a integrao com sistemas desenvolvidos em outras linguagens. O
Thrift suporta as seguintes linguagens: As3, C Glib, C++, CSharp, D, Delphi, Erlang,
Go, Haskell, Java, Java Me, Javascript, Node.js, Objective-c, OCaml, Perl, PHP, Python,
Ruby e Smalltalk, o que d uma maior interoperabilidade para o componente.
Quanto quantidade de tipos suportados, ele tambm possui uma quantidade inferior
ao Thrift. O Protocols Buffer d suporte aos tipos: bool, 32/64-bit integers, float,
37
double, string, sequncia de byte e o "repeated"que funciona como uma lista. O Thrift
d suporte aos tipos: bool, byte, 16/32/64-bit integers, double, string, sequncia de
bytes, map<t1,t2>, list<t>, set<t>. Como no Dedupeer a estrutura de dados trafegada
necessitava da utilizao de um map, a facilidade de implementao dessa estrutura no
Thrift foi um dos motivos para decidir por ele quando comparado ao Protocols Buffer.
Na seo 4.2.2, ser discutido mais sobre o Protocols Buffer.
Comparao de desempenho
O Protocols Buffer leva vantagem no desempenho em relao ao Thrift, mas o peso
dessa vantagem no influenciou na deciso de escolha, devido ao fato de que o suporte a
mais linguagens e a possibilidade de utilizao de estruturas de dados como Map foram
considerados mais importantes para o projeto do que a diferena entre o desempenho das
ferramentas, por isso o Thrift continuou como escolhido.
Nas Figuras 4.1 e 4.2, so apresentados resultados de um teste de desempenho feito
com algumas bibliotecas de serializao. Percebe-se que o Protocols Buffer, chamado
de protobuf, tem um melhor desempenho que o Thrift. Na serializao dos dados, o
Protocols Buffer teve um desempenho aproximadamente 50% mais rpido que o do Thrift.
Na desserializao, o Protocols Buffer foi aproximadamente 31% mais rpido.
Figura 4.1 Desempenho na serializao dos dados [2]
4.2.3
Comparao por hash (fingerprints)
Uma funo hash mapeia um conjunto de dados de tamanho varivel para um resultado
com tamanho fixo. Como o valor no qual o conjunto de dados mapeado tem um tamanho
menor do que o conjunto de entrada, existe uma possibilidade de dois ou mais conjuntos
38
Figura 4.2 Desempenho na desserializao dos dados [2]
de dados distintos terem um valor de hash igual. Quando o mesmo hash obtido de
conjunto de dados diferentes, dito que houve uma coliso de hashes [15].
Comparar a igualdade entre arquivos ou entre blocos de dados atravs do resultado
de uma funo hash aplicada aos seus contedos, um forma eficiente de verificar se os
contedos so diferentes com probabilidade de erro igual a zero. Muitos sistemas utilizam
a comparao para identificar igualdade em contedos tambm, como por exemplo, o
rsync[40] e o Venti[29]. Apesar da utilizao dessa tcnica em vrios grandes projetos, a
comparao de igualdade entre contedos atravs de uma funo hash aplicada ele tem
probabilidade de encontrar um falso positivo.
O clculo de uma funo hash muito eficiente. O clculo do SHA1 de 160 bits
em um bloco de 8KB, utilizando um computador Pentium 3 de 700Mhz, feito em 130
microssegundos, o que d a mdia de 60MB/s [29].
Comparar todos os bytes de dois blocos de dados para identificar se os mesmos so
iguais, uma tarefa muito custosa. O custo computacional para fazer uma comparao de
blocos de dados com 128 KB cada um menor, se ao invs de comparar todos os 128 KB
de contedo fizer a comparao apenas dos valores de hash dos dois, que se for obtido
atravs de uma funo MD5 de 128 bits, por exemplo, ter um valor de representao
com 32 dgitos hexadecimais. A comparao de 128 KB de dados substituda por uma
simples comparao entre 16 bytes.
Fazer a comparao de todos os bytes de um segmento para identificao de igualdade
chamado de comparao byte a byte. Esse mtodo de determinao de igualdade de
segmentos totalmente confivel, mas em contrapartida, extremamente custoso. Apesar
da comparao por hashes ter a probabilidade de dar um falso positivo para um segmentos
de dados com contedos diferentes, o principal argumento dos defensores dessa tcnica
39
que a probabilidade de ocorrer um erro no hardware que armazena o dado muito maior
do que a probabilidade desse falso positivo acontecer. Quando um dado corrompido,
quase certo que esse erro seja causado por falha de hardware, como erros no detectados
na memria principal, na transferncia pela rede, nos dispositivos de armazenamento
ou qualquer outro componente de hardware, do que por uma coliso de hashes. Por
este motivo, foi definido que o mtodo de identificao de segmentos iguais utilizado no
projeto seria atravs da comparao por hashes.
Para assegurar que os dados so realmente idnticos, algumas empresas, como a
NetAPP, fazem a anlise bit a bit dos chunks, que pode ser uma alternativa, mas geralmente
usada como complemento da comparao por fingerprints para confirmar se os dados
so iguais, e assim evitar o problema que pode ser causado pela coliso de hashes.
A probabilidade de ocorrer uma coliso de hashes pode ser estimada atravs dessa
funo matemtica:
P = 1 (1 2b )n
, com n representando o nmero de blocos de entrada e b representando o nmero de bits
no valor do hash de sada.
Considerando um sistema que usa blocos de 8 KB com fingerprints calculados com
SHA1 de 160 bits e que possua 1 exabyte (1018 bytes) de dados armazenados, o que
d um quantidade de aproximadamente 1014 blocos, a probabilidade de uma coliso de
hashes ocorrer neste cenrio ainda extremamente baixa, essa probabilidade menor
que 1020 [29].
Vantagem
A comparao bit a bit, apesar de ser uma tcnica na qual se pode ter uma certeza
absoluta sobre a igualdade de dois conjunto de dados, ela possui desvantagens. Alm de
ser uma tcnica muito custosa, j que todos os bits precisam ser comparados, um a um,
ela elimina toda a vantagem da anlise remota de chunks, que a utilizada no Dedupeer.
Por isso, ela no foi implementada para garantir o positivo na comparao entre chunks.
A utilizao do SHA-1 para a identificao de igualdade de conjunto de dados foi
usado porque apesar da possibilidade de coliso, ele permite a possibilidade de analisar
a igualdade de dois conjuntos de dados sem t-los em um mesmo computador, o que
possibilita o processamento remoto. Outro ponto positivo para a escolha do SHA-1, o
fato de at hoje no ter registros de coliso de hashes com ele [35].
Se for utilizado SHA-256, a probabilidade de coliso ainda menor, segundo [27]
a probabilidade de uma coliso em um conjunto de 1024 exabytes de dados em um
40
sistema de deduplicao, com um tamanho de chunk de 4KB e utilizando o SHA-256

para calcular os fingerprints, menor que 1042 .
4.3
Sumrio do captulo
Neste captulo foram discutidas algumas das principais decises de projeto para a
criao do Dedupeer como um componente interopervel, com facilidade de adaptao
com sistemas de armazenamento na maioria das linguagens populares. Tambm foi
explicada a tcnica de anlise de fingerprints, usada para a identificao de conjunto de
dados idnticos, que usada pelos algoritmos de deduplicao em geral, e as vantagens e
problemas que podem ocorrer com a utilizao dessa tcnica. Tambm foi apresentada
uma alterativa para identificao de conjuntos de dados iguais, que no caso do projeto
proposto, no vivel ser aplicada.
No prximo captulo sero detalhados os dois algoritmos implementados, entre eles,
o que utilizado no core do componente Dedupeer.
41
5
Os algoritmos
Dois algoritmos foram desenvolvidos para fazer a deduplicao no projeto, um mais

simples, que carrega todo o arquivo a ser deduplicado para a memria em uma nica vez,
e um segundo, que faz a carga particionada do arquivo. O segundo algoritmo permite que
o processamento do arquivo seja feito de forma particionada, com a carga do bytes para a
memria de forma parcial.
Este captulo dividido em duas partes, na primeira feita a fundamentao base
para o desenvolvimento dos algoritmos, e a segunda descrito o funcionamento de cada
um dos dois algoritmos, tanto uma explicao de alto nvel como uma mais aprofundada
na implementao.
5.1
Fundamentos
Nesta Seo, sero explicados os dois principais conceitos utilizados para tornar o
desempenho do processamento da deduplicao vivel, o rolling checksum e o fingerprinting. Uma breve introduo sobre o percursor da anlise de igualdade entre arquivos de
forma remota tambm ser discutido.
5.1.1
O algoritmo Rsync
O algoritmo Rsync foi desenvolvido para otimizao de transferncia de arquivos entre

computadores e foi utilizado primeiramente na ferramenta de mesmo nome, desenvolvido
por Andrew Tridgell and Paul Mackerras [40].
Suponha que dois computadores tenham verses diferentes de um mesmo arquivo, e
que o objetivo seja atualizar o arquivo mais antigo para a verso mais recente, ao invs de
enviar o arquivo todo e substituir a verso mais antiga, pode-se calcular e enviar para o
42
5.1. FUNDAMENTOS
outro lado apenas a os bytes diferentes entre esses arquivos. A identificao da diferena
entre arquivos pode ser feita de vrias formas, a maioria dos algoritmos usa a abordagem
de anlise de dois arquivos localmente para a identificao da redundncia de conjunto
de bytes entre eles, criando a partir do processamento um arquivo da diferena, que
chamada de patch. O Rsync usa uma abordagem diferente, ele faz a identificao da
diferena entre os arquivos de forma remota, com isso ele identifica as partes do arquivo
que precisam ser enviadas para o outro computador e quais partes precisam ser apenas
referenciadas, evitando assim a transferncia do arquivo todo para o destino.
O algoritmo Rsync funciona da seguinte maneira [40]:
O computador quebra o arquivo B em chunks de tamanho fixo S, no sobrepostos,
sendo que o ltimo chunk pode ter um tamanho menor que S;
Para cada chunk calculado dois fingerprints, um fraco "rolling" de 32 bits, e um
mais forte de 128 bits;
envia um lista com os fingerprints para o computador ;
primeiro faz a busca no arquivo A com um rolling checksum, comparando o
fingerprint obtido com o de 32 bits enviado por . Caso encontre alguma parte do
arquivo que o valor calculado seja idntico a algum fingerprint enviado por ,
feito um clculo no mesmo bloco de dados para obter o fingerprint de 128 bits, que
comparado lista recebida;
envia para as instrues necessrias para montar o arquivo idntico ao A,
definindo quais chunks de B podem ser aproveitados e enviando os dados de A que
no esto em B.
Rolling checksum
O rolling checksum foi usado nos dois algoritmos implementados no projeto. Ele
um tipo de checksum que tem a propriedade de ser calculado de forma pouco custosa
quando o clculo do checksum da janela anterior j tiver sido feito, por exemplo, se o
checksum do bloco de bytes Xk ... Xl j for conhecido, obter o do bloco Xk+1 ... Xl+1
mais rpido [40]. Para a identificao dos dados duplicados, o Rsync usa o rolling
checksum.
A no utilizao de uma tcnica como esta, torna extremamente invivel a identificao de partes iguais dentro de um arquivo, at mesmo em arquivos que sejam backups
43
5.1. FUNDAMENTOS
sucessivos e que possuam apenas uma pequena parte diferente. O problema que qualquer alterao, seja ela uma adio, uma remoo ou qualquer outra mudana, desloca
o contedo do arquivo, isso causa uma alterao em cadeia em todos os segmentos dos
chunks posteriores, que recebero os bytes de um vizinho e fornecer bytes para o vizinho
que o sucede.
5.1.2
Fingerprinting
Fingerprints uma outra tcnica que foi aplicada como base nos dois algoritmos
desenvolvidos, eles so valores que identificam uma sequncia especfica de dados. A sua
principal propriedade a identificao da diferena entre conjuntos de dados, independente de formato, que possuam o mesmo tamanho. Ele usado tambm para identificar
igualdade entre conjuntos de dados, pelo fato da probabilidade dos valores serem idnticos, quando os conjuntos de dados so diferentes, ser quase zero. O fingerprint o
resultado do clculo de uma funo hash aplicada em um conjunto de dados. Na maioria
das vezes os fingerprints so calculados a partir das funes hash MD5 ou SHA1 por
serem funes com baixa probabilidade de coliso. [14]
Para
um esquema de fingerprinting um conjunto de funo
n um melhor entendimento,
o
k
F = f : {0, 1} , onde representa o conjunto de todos os segmentos possveis
e k o tamanho do fingerprint. Se for escolhido um conjunto S de n seguimentos
distintos, e for escolhido f F uniforme e randomicamente, ento
f (A) 6= f (B) = A 6= B
P( f (A) = f (B)|A 6= B) = muitobaixa
[7].
Blocos de dados de mesmo tamanho podem ter um fingerprint igual mesmo tendo
contedos diferentes. Segundo Jeff Bonwick, lder no desenvolvimento do ZFS, a
probabilidade de coliso de hashes entre dados no idnticos com a utilizao de uma
funo hash SHA256 de aproximadamente
2256 = 1077
[6].
Mesmo os fingerprints sendo uma representao muito reduzida de um segmento de
dados, preciso ter cautela com a quantidade deles que so carregados para a memria
44
5.2. DETALHANDO OS ALGORITMOS
de uma s vez. Considerando o tamanho padro dos segmentos como 8 KB de tamanho,

sendo representado por um fingerprint de 160 bits, um arquivo de 8 TB teria um conjunto
de fingerprints com tamanho de 20 GB [46].
5.2
Detalhando os algoritmos
O Dedupeer possui dois algoritmos para fazer a deduplicao de um arquivo. O

primeiro, e mais simples, foi desenvolvido com base no princpio de comparao de
conjunto sequencial de bytes do Rsync.
O segundo, e mais complexo algoritmo, foi desenvolvido com uma forma de comparao diferente do primero para possibilitar indentificaes de sequncias de dados idnticas,
sem a necessidade do arquivo estar totalmente carregado na memria principal. Nas
prximas Subsees os dois algoritmos desenvolvidos sero descritos detalhadamente,
tanto o funcionamento como as decises de implementao.
5.2.1
Algoritmo para deduplicao com carga completa do arquivo

na memria
Esse algoritmo foi o primeiro a ser desenvolvido. Ele foi baseado na forma de identificao de igualdade de conjuntos sequenciais de bytes do Rsync, no qual informado um
valor de um funo de hash aplicada um chunk e esse valor comparado com os valores
de hash obtidos a partir da execuo da funo de rolling hash aplicada ao arquivo em
que se deseja encontrar as partes duplicadas.
Ser feita uma explicao do funcionamento do algoritmo utilizando um diagrama
de atividade simples em conjunto com abstraes da estrutura de dados em caixas, e
em seguida, o algoritmo ser explicado mais profundamente, com discusso sobre a
implementao, utilizando pseudocdigo de alto nvel para isso.
No cenrio de exemplo para fundamentar a explicao, existem dois arquivos de
uma mesma msica, um deles possui alguns bytes no incio a mais do que o outro.
Suponha que esses bytes so informaes de metadados inexistentes no segundo arquivo.
A msica que no possui esses metadados a mais, est armazenada em um sistemas de
armazenamento de dados distribudo, que possui as informaes sobre cada chunk desse
arquivo, como o valor do hash de 32 bits e do SHA-1. O cenrio mostra o processamento
que feito pelo algoritmo antes da msica ser enviada para o sistema de armazenamento
distribudo. Sem um algoritmo de deduplicao integrado ao sistema de armazenamento,
45
esse novo arquivo seria totalmente copiado para ele, e no caso do sistema possuir um
algoritmo de deduplicao apenas para arquivos completos, ele tambm no conseguiria
a compresso dos dados nesse caso, j que apesar da maior parte do contedo dos dois
arquivos serem idnticos, esse tipo de algoritmo no consegue identificar igualdade de
partes do arquivo.
Antes de enviar o novo arquivo para o sistema de armazenamento, o processamento
para identificar partes do arquivo que so iguais a um dos chunks j armazenados feita.
Para isso, o algoritmo exige, atravs da implementao da sua interface de comunicao,
que o sistema fornea as informaes essenciais para fazer o processamento da deduplicao, como as informaes dos valores dos fingerprints dos chunks. O algoritmo ento
carrega o arquivo completo para a memria principal para poder fazer a anlise dos bytes.
A varivel windowsIndex indica a posio inicial da janela do rolling checksum no
arquivo. Essa janela tem o tamanho definido atravs de um parmetro que passado pelo
sistema de armazenamento e que tem como objetivo informar o tamanho padro do chunk
armazenado no sistema.
A comparao inicia-se com a procura pelo primeiro chunk da lista passada para o
algoritmo atravs da interface. Como descrito na seo sobre o Rsync, o contedo do
chunk no necessrio para a identificao de uma sequncia de bytes idntica, para
isso, s necessrio o conhecimento dos valores dos fingerprints. Primeiramente, o valor
do hash fraco desse chunk procurado no contedo do arquivo em memria. O hash
fraco tambm calculado no conjunto inicial de bytes do arquivo em memria, que tem
o seu incio indicado a partir na posio apontada pelo windowsIndex, e vai at o final
da janela. Esses dois valores so comparados, se eles forem diferentes, o byte inicial
da janela incrementado em 1 (windowsIndex++) e o clculo do rolling hash feito
em cima do valor do hash da janela anterior. Esse procedimento executado at que
os valores dos hashes sejam iguais ou o fim do arquivo seja alcanado. No exemplo
demonstrado na 5.1, quando o incio da janela estiver no terceiro byte, o clculo do
hash ser idntico ao procurado. Quando esses valores so iguais, feito um clculo
do SHA-1 no conjunto de bytes que est dentro da janela, e o valor comparado com
o SHA-1 do chunk armazenado no sistema. Se esses valores forem diferentes, significa
que a comparao dos hashes fracos deu um falso positivo e o procedimento de busca
segue com o incremento do incio da janela, caso contrrio, considerado que o contedo
que est dentro da janela igual ao do chunk armazenado no sistema, e uma indicao
de referncia criada, para que os bytes no sejam enviados para o sistema. O incio
da janela salta para a posio aps o ltimo byte do chunk encontrado, e a busca pelo
46
prximo comea a partir desse ponto.
Figura 5.1 Funcionamento do algoritmo 1.
A anlise do pseudocdigo de alto nvel do algoritmo vai ser feita a seguir. O

algoritmo implementado em Java est disponvel na pgina do projeto no Github1 .
Como o algoritmo foi desenvolvido para ser uma interface Thrift 4.2.1, ele precisa
receber algumas variveis que sero informadas pelo sistema de armazenamento. A
estrutura esperada com as informaes dos chunks basicamente, o hash de 32 bits, o
SHA-1 e o ID de cada um deles, para um maior ganho de desempenho eles precisam
estar ordenados, baseado no fato de que a probabilidade de que o chunk posterior seja
duplicado se o anterior for grande. Vale ressaltar que nem todos os chunks armazenados
no sistemna precisam ser passados para o algoritmo, recomendvel que somente os
pertencentes arquivos que tem probabilidade de serem similares sejam informados,
como por exemplo, os arquivos que so do mesmo tipo e que possuam um nome similar
com o que vai ser processado procura de partes duplicadas.
1 https://github.com/paulofernando/dedupeer
47
O outro parmetro esperado uma string representando o caminho absoluto para o

arquivo no sistema de arquivos local, para que o algoritmo possa ler os seus bytes e fazer
o processamento com esses dados. Um objeto map<position,Chunk> retornado, onde
position referente posio do byte inicial do conjunto sequencial de dados que formam
o chunk, e o valor no map referente informaes sobre o chunk, como, o identificador
do chunk que est armazenado no sistema distribudo e que foi encontrado como duplicado, ou, no caso de no ter encontrado nenhum idntico, as informaes armazenadas
so as necessrias para que o sistema consiga identificar o conjunto sequencial que no
est duplicado, como posio inicial e final dentro do arquivo, e os valores calculados dos
hashes desse novo chunk, para que o dados dele sejam enviados para armazenamento.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
input: informaes dos chunks armazenados e path do arquivo para ser deduplicado
output: apontador para os chunks duplicados no arquivo informado
for i = 0 to amountChunks do
index searchDeduplication(modFile, chunk[i].hash32)
if index <> -1 then
if window.sha1 = chunk[i].sha1 then
chunkRe f erences < index, chunkIn f o >
end if
end if
end for
index 0
bu f f er allocate(de f aultChunkSize)
while index < modFile.length do
if chunkReferences contains index then
if buffer position > 0 then
chunkRe f erences < index, newChunkIn f o >
bu f f er.clear()
end if
index index + newChunk.length
else
if buffer is full then
bu f f er.clear()
else
bu f f er.put(nextByteInT heWindow)
48

26:
27:
28:
29:
30:
31:
32:
33:
34:
index index + 1
end if
end if
end while
if buffer position > 0 then
bu f f er.clear()
end if
returnchunkRe f erences
Na linha 3, o algoritmo executa uma iterao com todas as informaes dos chunks
recebidas do sistema de armazenamento para serem procurados no arquivo passado como
parmetro, arquivo esse previamente carregado na varivel modFile. A varivel index que
aparece pela primeira vez na linha 4, representa a posio incial do chunk duplicado no
arquivo local, essa identificao feita atravs do mtodo searchDeduplication, que nada
mais do que um mtodo que utiliza o rolling checksum para identificar um conjunto
de dados com o mesmo hash fraco do chunk atual da iterao. Quando o valor do
index for diferente de -1, ser porque o mtodo encontrou um conjunto de dados que
possui o mesmo valor de hash fraco do chunk atual da iterao, mas como j explicado
anteriormente, o hash fraco s uma estratgia para economizar clculos de um SHA-1,
pois ele muito mais rpido de ser calculado, mas em contrapartida, a probabilidade de
coliso alta, logo, para termos uma probabilidade de quase 100% que os dados so
idnticos, feita uma comparao com o SHA-1. No caso dos valores do SHA-1 serem
iguais, considerado que os chunks tambm so iguais, apesar de existir uma mnima
probabilidade de no serem. Essa problemtica discutida na seo 4.2.3.
A partir da linha 12 o algoritmo funcionar com o objetivo de identificar as partes do
arquivos que no esto duplicados, e adicionar os mesmo na varivel que ser retornada
para o sistema de armazenamento, qual conter as referncias para os chunks que esto
no sistema, identificao essa que foi executada entre as linhas 3 e 10 do algoritmo. Nessa
linha, a varivel buffer criada com o tamanho de bytes igual ao padro do sistema. O
buffer serve para armazenar os bytes iniciais que so descartados da janela toda vez que o
conjunto Xk ...Xl de bytes, que o contedo dentro dela, no tenha seu fingerprint no map
passado pelo sistema de armazenamento. Como o prximo conjunto a ser procurado o
Xk+1 ... Xl+1 , o primeiro byte que estava no conjunto de dados anterior descartado da
nova verificao, com isso ele entra no buffer para se tornar parte de um novo chunk.
Na linha 14, verificado se o conjunto de dados com incio na posio atual do ndice
49
foi encontrado duplicado no sistema na busca feita anteriormente, caso a condio seja
verdadeira, verificado se o buffer possui algum dado, casa haja, criado um novo chunk
com esses bytes alocados nele e a posio do ndice incrementada com o tamanho
padro do chunk. Se a condio da linha 14 resultar em falso, feito um teste se o buffer
ainda pode receber dados, se ele j estiver cheio, criado um novo chunk com esses
dados e em seguida feita uma limpeza no buffer. Se o buffer no tiver atingido o limite
mximo de alocao, o byte atual armazenado nele e a posio do ndice incrementado
em 1, que foi a quantidade de bytes adicionados.
A linha 30 necessria, porque o final do arquivo pode ser atingido antes do buffer
estar totalmente cheio, a linha 31 cria o chunk final com o contedo armazenado no buffer
e o coloca na estrutura que vai ser retornada para o sistema de armazenamento na linha
34.
5.2.2
Algoritmo com deduplicao particionada
Para que o Dedupeer fosse capaz de fazer deduplicao de arquivos sem um limite
de tamanho, foi desenvolvido um segundo algoritmo que tem como princpio base a
capacidade de processar esse tipo de arquivo, para isso, ele utiliza uma tcnica de
particionamento em tamanhos que seja possvel a alocao na memria principal.
Como na descrio do algoritmo anterior, ser feita uma explicao de alto nvel com
o mesmo cenrio do primeiro algoritmo descrito em 5.2.1, em seguida, o algoritmo ser
detalhadamente explicado atravs do pseudocdigo. Esse algoritmo implementado em
Java tambm pode ser encontrada na pgina do projeto no Github.
O processamento feito antes do envio do arquivo, para identificar as partes iguais com
os chunks no sistema, exige que as informaes dos chunks estejam estruturadas de uma
forma diferente do primeiro algoritmo. Como entrada, a interface espera por informaes
dos chunks que esto armazenados no sistema para que o algoritmo os procure no arquivo
a ser deduplicado, como no anterior, mas a estrutura de dados definida que organiza
essas informaes um map<weakHash,map<strongHash,chunkIDs, pois existe uma
probabilidade real de que dois chunks com contedo diferente tenham o mesmo valor
de um hash de 32 bits, que conhecido como coliso de hash. Foi criado um outro
map interno que armazena os SHA-1 como chave, para que as informaes de chunks de
mesmo hash fraco no sejam perdidas por sobrescrita de valor no map e tem como valor
um objeto que possui dois IDs, o do chunk e o do arquivo. A interface tambm espera
o caminho absoluto do arquivo a ser deduplicado, e um parmetro que a quantidade
mxima de bytes do arquivo que pode ser carregada para a memria por vez.
50
Figura 5.2 Funcionamento do algoritmo 2
Primeiramente, o algoritmo recebe o map com as informaes dos chunks armazenados no sistema. Em seguida, a quantidade de bytes mxima informada pelo sistema como
parmetro da interface Thrift carrega para a memria principal, ou o arquivo completo,
se ele for menor que a quantidade mxima de bytes que pode ser carregada por vez. Veja
a 5.2.
Diferente do primeiro algoritmo, este utiliza uma estratgia de comparao diferente
do Rsync, e que o torna capaz de fazer o processamento de arquivos em partes. O Rsync
procura um determinado conjunto de dados que tenha um fingerprint especfico, e pra isso
ele precisa percorrer o arquivo at que o encontre, ou at que alcance o final do mesmo.
O algoritmo para deduplicao particionada aproveita o complexidade temporal (tempo
de execuo) da estrutura de map (hashtable), a qual O(1), e ao invs de percorrer o
contedo de um arquivo procura de um fingerprint, ele calcula o fingerprint dos dados
na janela do arquivo em memria e em seguida faz uma busca no map, ou seja, diferente
do Rsync a comparao feita de forma inversa.
Se o hash de 32 bits dos dados dentro da janela estiver na estrutura de map, feito
o clculo do SHA-1 dos mesmo dados e essa valor procurado dentro do map interno
51
que o valor da chave de hash 32 bits encontrada. Se o hash de 32 bits ou o SHA-1

no forem encontrados, feito um teste para saber se a quantidade de dados restante na
parte carregada para a memria menor que o tamanho padro do chunk, se for menor,
criado um chunk com o contedo do buffer e outro com o contedo restante, e uma outra
parte do arquivo carregado para a memria. Isso feito porque para calcular o valor do
hash de 32 bits da funo de rolling checksum, necessrio ter uma quantidade de dados
com o tamanho padro exato do chunk do sistema. Se o tamanho restante for maior, o
processamento segue normalmente, com a janela sendo incrementada em 1 byte por vez.
A seguir vai ser feita uma explicao mais aprofundada sobre o algoritmo atravs
da anlise do pseudocdigo de alto nvel. O input j foi descrito acima, e o output
o mesmo do primeiro algoritmo, uma referncia para os chunks duplicados dentro do
arquivo e as informaes sobre os novos chunks.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
input: informaes dos chunks armazenados, path do arquivo para ser deduplicado e
quantidade de bytes para carregar para a memria por vez
output: apontador para os chunks duplicados no arquivo informado
o f f set 0
validate(bytesToLoadByTime)
divideInTime f ileLength/bytesToLoadByTime
bu f f er allocate(de f aultChunkSize)
for i = 0 to divideInTime do
localIndex 0
partO f File getNextBlockO f File(o f f set)
currentChunk getNextChunkPartO f File(localIndex)
while localIndex < partOfFile.length do
if partOfFile.length - localIndex + moreBytesToLoad = defaultChunkSize then
partO f File getNextBlockO f File(o f f set)
o f f set o f f set + moreBytesToLoad
end if
if chunk[i].hash32 contains window.hash32 then
if currentChunk = null then
end if
if chunk[i].sha1 contains window.sha1 then
if buffer has data then
52

23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
newChunk createNewChunk(bu f f er)

chunkRe f erences < globalIndexnewChunk.length, newChunk.in f o >
bu f f er.clear()
end if
chunkRe f erences < globalIndex, re f erenceToT heChunk >
globalIndex globalIndex + currentChunk.length
localIndex localIndex + currentChunk.length
end if
end if
if not duplicate then
currentChunk null
if buffer is full then
newChunk createNewChunk(bu f f er)
chunkRe f erences < globalIndex bu f f er.position, newChunk.in f o >
bu f f er.clear()
else
if partOfFile.length - (localIndex + defaultChunkSize) > 0 then
bu f f er.put(partO f File[localIndex])
globalIndex globalIndex + 1
localIndex localIndex + 1
else
newChunk createNewChunk(partO f File, localIndexbu f f er.position)
46:
chunkRe f erences < globalIndexbu f f er.position, newChunk.in f o >
47:
localIndex localIndex + newChunk.length bu f f er.position

globalIndex globalIndex + newChunk.length bu f f er.position
bu f f er.clear()
if localIndex < partOfFile.length then
newChunk createNewChunk(partO f File, localIndex)
chunkRe f erences < globalIndex, newChunk.in f o >
bu f f er.clear()
48:
49:
50:
51:
52:
53:
53

54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
localIndex localIndex + newChunk.length

globalIndex globalIndex + newChunk.length
end if
end if
end if
end if
end while
o f f set o f f set + bytesToLoadByTime
end for
returnchunkRe f erences
O mtodo validate, chamado na linha 4, verifica se o valor passado pelo sistema para
informar a quantidade de bytes para ser carregado por vez na memria maior que o
tamanho do arquivo, se esse valor for maior, ele configurado com o tamanho do arquivo,
caso contrrio, feita uma aproximao para o mltiplo do tamanho padro do chunk que
seja mais prximo do valor informado, para que a probabilidade de um chunk que possua
um idntico armazenado no sistema no seja dividido entre duas cargas diferentes para a
memria, fato que se ocorresse, impossibilitaria o algoritmo de identificar a igualdade. A
linha 5 calcula a quantidade de cargas que precisaro ser feitas para a memria, valor este
utilizado como quantidade de iteraes que a estrutura de repetio da linha 7 executar.
O mtodo getNextBlockOfFile, utilizado na linha 9, retorna um array de bytes do
arquivo que ser deduplicado a partir da posio definida como parmetro, esse array de
bytes o contedo que carregado para a memria por iterao. A partir desse array,
criado o primeiro chunk do arquivo que est na memria para anlise de duplicata.
Na linha 11 iniciada a iterao na parte do arquivo carregada em memria para
anlise. A condicional da linha 12 uma estratgia para no perder a identificao de
um chunk duplicado quando este est no final da parte do arquivo que foi carregado
para a memria, e tiver sido encontrado grande parte da carga como idntica de outro
arquivo j no sistema. Basicamente, esta parte do algoritmo serve para deixar o ltimo
chunk da carga com o tamanho padro do sistema, e assim, possibilitar a identificao de
igualdade. Observando o exemplo da 5.3, percebe-se que sem a carga extra de bytes, o
chunk representado pelos 4 hexadecimais 7C CE 72 A4, mesmo sendo duplicado, no
ser identificado como tal pelo algoritmo sem a carga extra de dados.
Este parece ser um problema pequeno, mas no . Supondo que todo contedo das
cargas posteriores do arquivo j estejam armazenadas no sistema por fazer parte de uma
verso anterior do mesmo arquivo, sem a carga extra de bytes, ser deixado de deduplicar
54
Figura 5.3 Vantagem da utilizao da carga extra de dados
um chunk por carga, pois parte dele estar no final de uma carga e a outra estar no
comea da posterior. Essa parte que ficar no comeo da outra carga, sempre deixar
o ltimo chunk sem todos os bytes necessrios para a identificao da deduplicao na
mesma carga, acarretando assim uma perda de deduplicao para cada iterao frente.
Na linha 17 verificado se o map possui uma chave com o hash fraco calculado
da janela atual. A linha 18 para evitar recarga de bytes na memria. Em seguida
verificado se o map que est como valor da chave encontrada possui o SHA-1 que
representa os bytes dentro da janela, se esse valor for encontrado, verificado se o buffer
est com algum dado, se sim, esses dados so transformados em um novo chunk e na
linha 27 a referncia do chunk duplicado salva na estrutura.
Na linha 35 feita uma verificao para saber se o buffer est cheio, caso esteja, todo
o seu contedo transformado em um nico chunk e o mesmo esvaziado para poder
receber os bytes iniciais da janela quando a mesma estiver em uma posio em que o
conjunto de bytes dentro dela no seja encontrado armazenado no sistema.
Se o buffer ainda possuir espao vazio, verificado se o restante do contedo carregado
para a memria que ainda no foi processado maior que o tamanho padro do chunk,
caso seja, o byte inicial da janela adicionado ao buffer, j que no foi encontrado o
fingerprint do contedo da janela nos dados passados pelo sistema, e o ndice do incio
da janela incrementado em 1. Se a quantidade de bytes no processados for menor que
o tamanho padro, criado um chunk com os dados dentro do buffer e um outro com o
restante dos bytes.
55
Por fim, na linha 61 o offset para a carga dos dados no arquivo local incrementado
com a quantidade de bytes que foram carregados na ltima vez. E na 63 onde est
localizado o comando de retorno da varivel com todos os novos chunks e referncias aos
j armazenados, que juntos formam o arquivo local.
5.3
Sumrio do captulo
Neste captulo, inicialmente foi feita uma introduo sobre o funcionamento do Rsync,
que um algoritmo para otimizar a transferncia de arquivos entre computadores remotos
e que serve como base de grande parte dos algoritmos de deduplicao de arquivos. Em
seguida, foram discutidos os principais conceitos por trs da eficincia da deduplicao,
o rolling checksum e o fingerprinting.
Depois da introduo dos conceitos fundamentais para o desenvolvimento dos dois
algoritmos que foram implementados no projeto, foi feita uma anlise bem detalhada
do funcionamento do primeiro deles, que o algoritmo para deduplicao com carga
completa do arquivo na memria, o qual utiliza uma tcnica muito similar ao Rsync. Foi
apresentado um diagrama sobre o algoritmo, e o seu funcionamento explicado. Depois da
apresentao do funcionamento, o pseudocdigo de alto nvel do algoritmo foi explicado
em detalhes.
Por fim, foi feita a explicao do segundo algoritmo desenvolvido, o algoritmo com
deduplicao particionada, o qual seguiu a mesma estrutura da primeira explicao.
Primeiro, foi feita uma anlise detalhada do funcionamento do algoritmo atravs de um
diagrama, e depois, apresentado e explicado o pseudocdigo de alto nvel.
No captulo a seguir, ser apresentada uma analise de desempenho, tanto de tempo
como de compresso, para o algoritmo com deduplicao particionada que foi apresentado
neste Captulo.
56
6
Anlise de desempenho e compresso
Neste captulo demonstrada uma anlise do desempenho do Dedupeer integrado com

o Dedupeer File Storage. Ser feita uma anlise para identificao do melhor algoritmo de
hashing para o sistema e um estudo sobre as taxas de compresso alcanadas dentro de um
conjunto de tamanho de chunks para identificar a eficincia da economia proporcionada
pelo algoritmo de deduplicao desenvolvido.
Sero feitas avaliaes no tempo de armazenamento, deduplicao, deduplicao
juntamente com o armazenamento, e reidratao, que a remontagem do arquivo original
atravs dos chunks armazenados e deduplicados.
6.1
Datasets
Para comparar sistemas de deduplicao de dados diferentes preciso possuir o

mesmo conjunto de dados, pois a recriao de datasets a partir da mesma porcentagem
de modificao no funcionam com deduplicao. As modificaes precisam estar
exatamente localizada na mesma posio ou a avaliao ser falha, logo, os arquivos
testados devem ser os mesmos.
O trabalho [38] trata justamente sobre quais datasets devem ser usados para fazer
avaliaes em sistemas de deduplicao de dados. Nele foram analisados 33 artigos sobre
deduplicao publicados entre os anos de 2000 e 2011 nas mais relevantes conferncias
sobre storage do mundo, entre elas: Usenix ATC, Usenix FAST, SYSTOR e IEEE MSST.
Foi feita uma categorizao dos 120 datasets utilizados nesses artigos, os quais
ficaram divididos em:
1. Datasets privados, no acessvel para qualquer indivduo;
2. Datasets pblicos mas difceis de serem reproduzidos;
57
6.1. DATASETS
3. Datasets criados sinteticamente;

4. Datasets pblicos facilmente reproduzvel.
Dos 33 artigos avaliados, 29 deles utilizaram pelo menos um dataset privado, logo no
pode ser feita uma comparao entre os sistemas analisados nesses artigos e outro que no
possa ser avaliado com esses dados privados. Os 4 restantes utilizam conjuntos de dados
sinteticamente criados os quais no podem ser reproduzidos pois algumas informaes
sobre a sua criao foram omitidos.
Baseado na categorizao citada acima, os datasets so: 64 privados (53%), 17 so
pblicos e difceis de reproduzir (14%), 11 so sintetizados com detalhes da sua gerao
omitidos (9%). O que d um total de 76% de datasets inutilizveis para comparao
entre sistemas. Os 24% que so pblicos so considerados muito pequenos para uma
comparao ou so arquivos de mquinas virtuais de tipos muito variados.
Os dados utilizados nas anlises de desempenho do Dedupeer e do Dedupeer File
Storage foram arquivos de mquinas virtuais e de cdigo-fonte armazenados em um
arquivo tar. Para a anlise do tempo gasto nas principais operaes foram utilizadas as
seguintes verses do Kernel do Linux, os quais podem ser encontrados nesse endereo:
https://www.kernel.org/.
1. stable: 3.9.8 datado de 27 de junho de 2013 (Latest Stable Kernel).
2. mainline: 3.10-rc7 datado de 22 de junho de 2013
A verso 3.9.8 (stable) foi utilizada como base para a deduplicao da verso 3.10-rc7
(mainline).
Para a avaliao da taxa de compresso alcanada com o algoritmo desenvolvido,
foran utilizados dados com modificaes de contedo mais complexas e maiores dos que
as obtidas com o Kernel do Linux. Para essa avaliao foram utilizadas duas imagens de
mquinas virtuais com Ubuntu 10.12 instalados. Em uma delas o Ubuntu foi instalado
sem atualizaes, essa a mquina virtual que ser usada como arquivo base para
deduplicao.
A segunda mquina virtual a primeira mquina com uma atualizao. O sistema
operacional da mquina virtual foi atualizado com todas as atualizaes disponveis at o
dia 2 de junho de 2013 s 13:17. 356 arquivos foram baixados, totalizando 330,3MB de
dados, os quais aps a instalao ocuparam 1350MB a mais do que a mquina virtual
antes da atualizao.
A escolha de dados pblicos e de fcil acesso possibilitar futuras comparaes com
trabalhos relacionados.
58
6.2. ANLISE DE DESEMPENHO UTILIZANDO O CDIGO FONTE DO KERNEL DO

LINUX
6.2
Anlise de desempenho utilizando o cdigo fonte do

Kernel do Linux
Esta primeira anlise ser focada no desempenho para deduplicao do Dedupeer, e

do armazenamento e reidratao do Dedupeer File Storage. Foram feitas 14 execues
de cada uma das principais operaes, armazenamento, deduplicao, deduplicao +
armazenamento e reidratao, cada uma delas para 128KB, 64KB, 32KB, 16KB e 8KB.
Esses valores foram escolhidos por serem as potncias de dois prximas ao tamanho
recomendado por alguns sistemas de deduplicao, 8KB e 16KB, e o tamanho utilizado
no Ustore, o sistema onde o Dedupeer foi implantado, que 128KB.
O computador utilizado para a execuo da anlise de desempenho foi um Windows
7 Profissional com Service Pack 1 de 32 bits com processador Intel Core 2 Quad Q6600
2.40GHz e 3,24GB de memria RAM DDR2.
Para a operao de armazenamento foi enviado um arquivo .tar com todo o cdigofonte do Kernel do Linux na verso 3.9.8 e o tempo at a concluso da operaao foi
registrado. A utilizao do formato tar muito importante para fazer a deduplicao dos
arquivos pois nenhuma compresso aplicada aos arquivos que so armazenados nele,
diferente do zip por exemplo, que modifica o contedo dos arquivos e isso degrada a
taxa de compresso obtida com a deduplicao pelo fato do contedo dos arquivos serem
transformados, o que impossibilita a descoberta de conjunto de dados idnticos.
Foi registrado tambm o tempo do incio da operao de deduplicao at o trmino,
e tambm o tempo do incio da deduplicao at o trmino do armazenamento do arquivo
deduplicado. Para essas operaes foi utilizado o arquivo .tar com todo o cdigo fonte
do Kernel do Linux na verso posterior 3.9.8 que estava disponvel no site, que foi a
verso 3.10-rc7.
Por ltimo, foi registrado o tempo gasto para fazer a reidratao do arquivo deduplicado. Todos os dados capturados na avaliao esto disponibilizados no formato do
Mathematica 91 no apndice A.2.
Operao de armazenamento
As Figuras 6.1 e 6.2 mostraro todos os tempos em milissegundos capturados das 14
execues da operao de armazenamento do Dedupeer File Storage para os algoritmos
de hashing MD5 e SHA-1 para cada tamanho de chunk analisado, os quais foram para
1 http://www.wolfram.com/mathematica/
59

LINUX
todas as operaes: 128KB, 64KB, 32KB, 16KB e 8KB. Os dados foram plotados no
grficos na mesma ordem em que foram capturados.
Figura 6.1 Tempo em milissegundos para as execues da operao de armazenamento utilizando

MD5
Figura 6.2 Tempo em milissegundos para as execues da operao de armazenamento utilizando

SHA-1
Para uma melhor comparao entre o tempo gasto no armazenamento, o grfico

na Figura 6.3 mostrar o emparelhamento dos dados ordenados entre os algoritmo de
60

LINUX
hashing usados para cada tamanho de chunk separado. A partir dos grficos, percebe-se
que os tempos para cada operao de armazenamento so similares independente do
algoritmo de hashing utilizado.
Para uma melhor visualizao, a comparao do tempo para cada tamanho de chunk
separado est no apndice A.3.
Figura 6.3 Tempo em milissegundos para as execues da operao de armazenamento, separadas

por tamanho de chunk
A seguir ser feito um teste estatstico para descobrir se a utilizao do SHA-1 tem
o mesmo desempenho do MD5. Como explicado anteriormente, o MD5 utilizado em
alguns dos sistemas que fazem deduplicao de dados, e que apesar da probabilidade de
coliso de hashes existir tanto no MD5 como no SHA-1, j se tem registro de coliso de
hashes com MD5 mas ainda nenhum registro desse problema com o SHA-1. Se os dois
algoritmos tiverem um desempenho similar ou se o desempenho do SHA-1 for inferior ao
MD5 mas no ponto de anular a vantagem da falta de registro com coliso de hashes,
no h motivos para no escolher o SHA-1 como algoritmo de hashing padro para o
Dedupeer File Storage.
Todos os valores de p podem ser encontrados na Tabela 6.1, esse o valor utilizado
para identificar se os dados capturados seguem a curva normal, e com isso saber qual
mtodo estatstico utilizar. Todos os valores vo ser exibidos na tabela para caso algum
61

LINUX
p-values
MD5
SHA-1
128KB
0,674511
0,903653
64KB
0,621354
0,868695
32KB
0,198659
0,258855
16KB
0,0330624
0,44823
8KB
0,293449
0,0219761
Tabela 6.1 p-values para os dados capturados na operao de armazenamento
queira fazer teste com outro tamanho de chunk.

Na Tabela 6.1 sero mostrados os valores de p dos dados da operao de armazenamento. O intervalo de confiana adotado para os testes foi de 95% ou seja, caso o valor de
p seja maior que o nvel de significncia, que 0,05, o T-Test pode ser selecionado, caso
contrrio, a anlise ser feita atravs de um teste no-paramtrico, j que o tamanho da
amostra inferior 40 e o T-Test s deve ser feito com dados no normais se a amostra
tiver tamanho superiores 40.
Para analisar qual o algoritmo se comporta melhor na operao de armazenamento,
vai ser feito um T-Test emparelhado com as amostras coletadas com 32KB, pois todos os
dados so normais, o que torna a anlise mais fcil. Como hiptese nula, ser considerado
que a mdia de tempo gasto para duas amostras so iguais, e como hiptese alternativa
ser considerado que a mdia de tempo gasto para a operao de armazenamento com
MD5 maior do que com SHA-1.
H0 : 0 1 = 0 vs. H1 : 0 > 1
Aplicando o T-Test emparelhado, resultou em um p-value 0,695936. Como o p-value
maior do que 0,05, no devemos rejeitar a hiptese nula, logo, no podemos afirmar
que a mdia de tempo com MD5 maior do que com SHA-1.
Operao de deduplicao
Os dados obtidos a partir das 14 execues de deduplicao esto plotados nos
Grficos 6.4 e 6.4. Com a anlise desses dados possvel avaliar apenas o desempenho do
algoritmo de deduplicao desenvolvido e utilizado no Dedupeeer File Storage, pois os
dados registrados nessas execues foram o tempo necessrio para o algoritmo buscar os
chunks dentro do arquivo a ser enviado para armazenamento. Logo, os valores plotados
nesse grfico se referem ao tempo entre o incio e o fim da deduplicao apenas, o qual
engloba os seguintes passos: a busca da informaes dos chunks a serem procurando
como duplicados dentro do arquivo, a montagem da estrutura de dados para comunicao
com a biblioteca atravs do Thrift, a procura dos chunks dentro do arquivo pela biblioteca
Dedupeer, a criao da estrutura de dados com o mapeamento dos chunks e das referncias
62

LINUX
aos chunks duplicados, e o retorno da estrutura atravs do Thrift para o Dedupeer File
Storage.
Figura 6.4 Tempo em milissegundos das execues da operao de deduplicao, separadas por
tamanho de chunk, utilizando SHA-1
Figura 6.5 Tempo em milissegundos das execues da operao de deduplicao, separadas por
tamanho de chunk, utilizando MD5
Da mesma forma que na operao anterior, a comparao do tempo para cada tamanho
de chunk est no apndice, na seo A.4.
Analisando os dados obtidos das execues de deduplicao, percebe-se que o algoritmo de deduplicao utilizando o SHA-1 obteve um desempenho superior ao mesmo
63

LINUX
algoritmo utilizando MD5. A mdia de tempo foi bem significativa, para 128KB o SHA-1
obteve uma mdia de 36553 milissegundos para executar a operao, enquanto que com
MD5 o tempo mdio foi de 133255 milissegundos. Com chunks de 8KB de tamanho a
diferena entre as mdias foi menor, o tempo para o MD5 (227582 ms) foi menos de duas
vezes maior do que o do SHA-1 (118409 ms).
Apesar da mdia do tempo ser significativamente maior utilizando MD5 em relao ao
SHA-1, preciso fazer a anlise estatstica para confirmar se com esses dados possvel
saber qual o algoritmo de hashing torna a deduplicao mais eficiente.
Para analisar qual o algoritmo se comporta melhor na operao de deduplicao, o
T-Test emparelhado foi feito para as amostras de 16KB.
Da mesma forma que o teste anterior, como hiptese nula ser considerado que a
mdia de tempo gasto para deduplicao igual entre as amostras, e como hipteses
alternativa ser considerado que a mdia de tempo com MD5 maior do que com SHA-1.
H0 : 0 1 = 0 vs. H1 : 0 > 1
Ao aplicar o T-Test emparelhado, o p-value foi 1,03839x1010 . Como o p-value
menor do que 0,05, devemos rejeitar a hiptese nula e aceitar a alternativa. Como a
hiptese alternativa deve ser aceita, concludo que a mdia de tempo gasta com MD5
para deduplicao realmente maior do que o tempo gasto com SHA-1, ou seja, para a
operao de deduplicao o SHA-1 foi mais eficiente que o MD5.
Operao de deduplicao + armazenamento
Nesta seo ser mostrado os dados da operao de deduplicao somada com a
operao de armazenamento, que representa a operao completa de deduplicao de um
arquivo no sistema de armazenamento.
Nesta operao, os dados capturados tambm apontam uma vantagem significativa
para o SHA-1, esses dados podem ser vistos plotados em grficos separados por algoritmo
de hashing nas Figuras 6.6 e 6.7. A mdia do tempo calculado para o SHA-1 utilizando
chunks de 128KB foi 36552.9 milissegundos, enquanto a mdio do MD5 para 128KB foi
249779 milissegundos, ou seja, com o SHA-1 a operao foi em mdia 6,8 vezes mais
rpida que com MD5. Para chunks de 8KB o SHA-1 teve mdia de 118409 milissegundos,
e o MD5 de 1213682 milissegundos. Com chunks de 8KB o SHA-1 foi em mdia 10,2
vezes mais rpido.
Os grficos emparelhados dessa operao separados por tamanho de chunk tambm
esto no Apndice, especificamente nessa seo A.5.
64

LINUX
A hiptese nula foi definida como a mdia de tempo gasto para deduplicao +
armazenamento sendo igual tanto para o MD5 como SHA-1, e como hiptese alternativa
considerando que o tempo com MD5 diferente com SHA-1.
H0 : 0 1 = 0 vs. H1 : 0 6= 1
Como no tem duas amostras normais para serem comparadas, nesse caso ser feita a
anlise a partir do Wilcoxon signed-rank test. O p-value resultante foi 0,00109705, com
isso a hipteses nula deve ser rejeitada e conclumos que o tempo mdio entre eles foi
diferente.
Figura 6.6 Tempo em milissegundos das execues da operao de deduplicao + armazenamento, separadas por tamanho de chunk, utilizando SHA-1
65

LINUX
Figura 6.7 Tempo em milissegundos das execues da operao de deduplicao + armazenamento, separadas por tamanho de chunk, utilizando MD5
Operao de reidratao
Para a operao de reidratao tambm foram feitas 14 execues para cada um dos
algoritmos de hashing SHA-1 e MD5.
Nas operaes de deduplicao os resultados foram diferentes das duas operaes
anteriores, nesta operao o algoritmo de MD5 foi mais rpido do que o SHA-1. Comparando as mdias do maior e menor tamanho de chunk testado, para o chunk de 128KB o
tempo mdio de execuo da operao de reidratao com MD5 foi de 43087 milissegundos, enquanto o tempo mdio do SHA-1 foi 68590,6 milissegundos. Para o chunk de 8KB
o MD5 foi pouco mais de 5 vezes mais rpido, tendo mdia de 226346 milissegundos
contra 1166748 milissegundos do SHA-1. Todos os dados das execues dessa operao
podem ser vistos nas Figuras 6.8 e 6.9, e os dados emparelhados por tamanho de chunk
esto no Apndice A.6.
66

LINUX
Figura 6.8 Tempo em milissegundos das execues da operao de reidratao, separadas por
tamanho de chunk, utilizando SHA-1
Figura 6.9 Tempo em milissegundos das execues da operao de reidratao, separadas por
tamanho de chunk, utilizando MD5
Para avaliar qual o melhor algoritmo para essa operao, foi definido o teste de
hiptese, onde a hiptese nula diz que a mdia de tempo gasto para a reidratao com
MD5 igual com SHA-1, e como hipteses alternativa que a mdia de tempo com MD5
menor do que com SHA-1.
H0 : 0 1 = 0 vs. H1 : 0 < 1
67

LINUX
Aplicando o T-Test emparelhado, o p-value foi 6,34527x101017 . Como o p-value

menor do que 0,05, devemos rejeitar a hiptese nula e aceitar a alternativa. Logo, como
previsto, concludo que a mdia de tempo gasto com MD5 para reidratao menor do
que o tempo gasto com SHA-1, ou seja, para a operao de reidratao o MD5 foi mais
eficiente que o SHA-1.
6.2.1
Mapa de chunks deduplicados
Foi desenvolvida uma funcionalidade no Dedupeer File Storage que exibe, em uma
barra horizontal, as reas do arquivo que foram economizadas com a deduplicao
aplicada nele. A barra possui duas cores, a azul representa as reas do arquivo onde o
seu contedo binrio foi salvo no sistema de armazenamento pelo fato de no ter sido
encontrado partes duplicadas j armazenadas, e a rea pintada de cinza representa as
partes do arquivo que foram economizadas no armazenamento, os dados pertencentes
essas reas foram encontrados como j presentes nos chunks armazenados no sistema e
s as referncias eles foram salvas.
Figura 6.10 Mapa de chunks deduplicados da verso 3.10-rc7 do cdigo-fonte do Kernel do

Linux processado com os chunks da verso 3.9.8, para chunks com tamanho 128, 64, 32, 16 e
8KB
Este mapa apresentado pode ocultar algumas reas, pois como as reas pintadas so
proporcionais e a quantidade de chunks do arquivo deduplicado e apresentado na Figura
6.10 foi de 66318 na verso de 8KB, chunks deduplicados de forma isoladas podem no
ser exibidos pois a rea ocupada por eles pode no ser suficiente para que seja exibida na
barra de modificaes.
Como esperado, a deduplicao com chunk de 128KB foi a que menos economizou
espao, j que para que um chunk fosse identificado como duplicado, seria necessrio
encontrar uma sequncia de dados binrios com tamanho de 128KB que pertencesse
verso de 3.9.8.
Para a verso de 128KB o arquivo foi dividido em 4025 chunks dos quais 119 foram
deduplicados, o que d uma economia de aproximadamente 3%. Para 64KB foram
68
6.3. ANLISE DE ECONOMIA UTILIZANDO MQUINAS VIRTUAIS
Chunks
128KB
64KB
32KB
16KB
8KB
VDI armazenado
24337
48674
97347
194694
389387
VDI atualizado deduplicado

35571
71280
142498
284218
566985
VDI atualizado armazenado

35137
70274
140547
281094
562187
Tabela 6.2 Quantidade de chunks criados
criados 8088 chunks dos quais 528 foram deduplicados, resultando em um total de 6,5%
de economia. Com 32KB o arquivo foi dividido em 16351 pedaos dos quais 2378 foram
deduplicados, mais de 11% do total. Para 16KB, o arquivo foi dividido em 32995 partes
das quais 8870 foram deduplicados, resultando em 25% de economia. E por fim, pra
chunks de 8KB, dos 66318 partes, 27989 foram deduplicados, o que acarretou em uma
economia de 41%.
Como os arquivos de cdigo-fonte so pequenos, geralmente menores do que os
tamanhos de chunk adotados, qualquer modificao em um deles faz com que nenhuma
parte do mesmo seja deduplicada, por isso, a deduplicao desse tipo de arquivo no
to eficiente.
6.3
Anlise de economia utilizando mquinas virtuais
Essa segunda anlise foi basicamente para avaliar a economiza que pode ser alcanada
atravs do algoritmo com a deduplicao de mquinas. Foram utilizados dois arquivos
.vdi (Virtual Disk Image), um deles com o Ubuntu verso 10.12 sem qualquer alterao e
o segundo com o mesmo sistema operacional s que com uma atualizao, como descrito
na seo 6.1.
Primeiramente, o arquivo vdi sem a atualizao do Linux, arquivo esse com tamanho
3.189.854.208 bytes, foi enviado para o Dedupeer File Storage. Em seguida, foi feita a
deduplicao do arquivo vdi com o Linux atualizado, de tamanho 4.605.431.808 bytes,
tendo como base o arquivo subido anteriormente. Esses passos foram executados para 5
tamanho diferentes de chunk: 128KB, 64KB, 32KB, 16KB e 8 KB. Para questes comparativas, o arquivo Linux atualizado tambm foi armazenado no sistema sem deduplicao.
A quantidade de chunks geradas com essas trs execues sero exibidas na tabela 6.2.
O fato da quantidade de chunks ser diferente entre a deduplicao e o armazenamento
do mesmo arquivo, se d porque com a deduplicao podem ser criados vrios chunks
com tamanho inferior ao tamanho padro, enquanto que no armazenamento, o nico
69
6.3. ANLISE DE ECONOMIA UTILIZANDO MQUINAS VIRTUAIS
chunk que pode ter um tamanho inferior ao padro o ltimo.

O grfico de barras abaixo mostra a quantidade de dados armazenados no sistema
tanto para o arquivo sem deduplicao, como para o arquivo deduplicado com chunks de
tamanhos variados. A economia alcanada foi de 55% para chunks de 128KB, 60% para
64KB, 63% para 32KB, 66% para 16KB e 69% para 8KB. A quantidade de bytes armazenados para cada um deles foi respectivamente: 4.605.431.808 bytes (sem economia),
2.072.762.428, 1.878.494.141, 1.710.946.626, 1.574.787.731, 1.447.578.619.
Levando em considerao que o arquivo utilizado como base para a deduplicao
tinha 3.189.854.208 bytes, e que a diferena entre ele e o arquivo que foi deduplicado de
1.415.577.600 bytes, a economia alcanada em relao quantidade de dados comparados
de: 79,397% para 128KB, 85,488% para 64KB, 90,740% para 32KB, 95,731% para
16KB e 98,997% para 8KB.
Figura 6.11 Tamanho em megabytes ocupado pelo arquivo no sistema, com a porcentagem de
economia alcanada
O mapa de modificaes para cada um dos tamanhos de chunk analisados pode ser
visto na Figura 6.11. Da mesma forma que o apresentado anteriormente, a cor azul
representa as reas do arquivo onde o seu contedo binrio foi salvo no sistema e a cinza
representa as reas onde os chunks foram deduplicados.
Figura 6.12 Mapa de chunks deduplicados da mquina virtual Linux 12.10 atualizada processada
com os chunks da mesma mquina virtual sem atualizao, para chunks com tamanho 128, 64, 32,
16 e 8KB
70
6.4. O USTORE
6.4
O Ustore
O Ustore2 tem como propsito a realizao de backups de dados em nuvens privadas.

As empresas podem usar parte da rea de armazenamento do disco que est ociosa nos
seus computadores para criar um nuvem de dados interna e ter maior controle sobre seus
dados.
Ele tem como principal objetivo o backup distribudo de dados e construdo em
uma arquitetura peer-to-peer (P2P) hbrida, que so redes peer-to-peer que possuem
entidades centrais [36]. Como a ideia principal do sistema a comunicao direta entre
os computadores, essa arquitetura foi escolhida. Para obter um melhor desempenho,
optou-se pela utilizao de servidores, o que fez com que a arquitetura peer-to-peer
tornar-se hbrida.
A comunicao entre as entidades que compem o sistema feita atravs da plataforma JXTA, que um conjunto de protocolos utilizado para criar uma rede peer-to-peer
[42].
Na verso 1.7 do Ustore o Dedupeer foi adicionado para fazer a deduplicao dos
arquivos versionados dos usurios. Para cada nova verso de um arquivo que sincronizado no sistema, o processo de deduplicao executado antes dos dados serem enviados
para os peers, o que economiza tanto a banda de rede como o espao ocupado nos peers.
Outra vantagem que o Dedupeer adiciona ao Ustore a possibilidade de ser oferecido
mais espao do que o sistema possui fisicamente, j que os chunks deduplicados no tm
seus dados salvos, apenas as referncia para os chunks que j esto armazenamentos.
6.5
Sumrio do captulo
Neste captulo foram analisados dois testes, um de desempenho e outro de taxa de

compresso para mquinas virtuais. No teste de desempenho concluiu-se que para a
operao de armazenamento no se pode afirmar se o tempo mdio da operao com
MD5 diferente do tempo com SHA-1. Para deduplicao, o sistema com SHA-1 foi
mais eficiente que com MD5. Para deduplicao + armazenamento foi confirmado que o
tempo mdio com SHA-1 e MD5 so diferentes, e a observao visual no grfico fica
claro que o SHA-1 mais eficiente nesse caso tambm. E por ltimo, na operao de
reidratao, o sistema com MD5 foi mais eficiente que com SHA-1.
2 "http://usto.re"
71
Para a segunda avaliao, foi analisada a taxa de compresso obtida para duas mquinas virtuais Linux, e como esperado, a taxa de compresso foi maior para chunks
menores.
E por ltimo, a partir das anlises em todas as operaes, o SHA-1 por ter sido melhor
comprovadamente em 2 delas, e por ter a vantagem de no possuir colises de hashes
comprovadas, vai ser definido como padro para o Dedupeer File Storage.
72
7
Concluso
Nesta pesquisa foi desenvolvido um algoritmo para deduplicao exata de dados,

interopervel, com processamento particionado em cargas de bytes para a memria
principal. O algoritmo foi encapsulado em um componente de software com interface
Thrift, que uma biblioteca de serializao com linguagem neutra e suporte diversas
linguagens de programao, para facilitar a integrao com sistemas de armazenamento
existentes. O algoritmo foi desenvolvido com uma funcionalidade de otimizao de
descoberta de redundncia de dados atravs da carga extra de dados no processamento
particionado, o que aumenta a preciso da identificao de redundncia mesmo com a
quebra do arquivo para ser processado.
Para a avaliao do algoritmo foi desenvolvido o Dedupeer File Storage, um sistema
de armazenamento de dados com as mesmas caractersticas dos principais sistemas de
armazenamento distribudos, utilizando a quebra dos arquivos salvos em vrias partes
menores, as quais so chamadas de chunks. O gerenciamento de replicao, tolerncia
falha, entre outros problemas comuns enfrentados por esses sistemas so delegados ao
Cassandra, que a base de gerenciamento do sistema de armazenamento desenvolvido.
O Dedupeer File Storage possui uma interface grfica com o usurio qual possibilita
o gerenciamento dos arquivos armazenados, atravs de funcionalidades como backup,
deduplicao, reidratao, clculo de economia, renderizao de mapa de chunks e
referncias do arquivo e painel de configuraes bsicas, como tamanho padro de chunk
e quantidade de chunks carregados pra memria.
7.1
Trabalhos futuros
A fim de promover a utilizao do algoritmo de deduplicao particionada ou o sistema de armazenamento de dados desenvolvidos, h algumas possibilidades de trabalhos
73
7.1. TRABALHOS FUTUROS
futuros, os quais esto listados abaixo:

Criar um buffer do mapa dos chunks processados na deduplicao em disco, para
que no haja estouro de memria pelo fato do mapa de chunks ficar maior que
o espao reservado para a memria heap do Java, o que possibilitar fazer a
deduplicao de arquivo de qualquer tamanho.
Comparar os ganhos de desempenho trazidos pela deduplicao particionada em
relao um algoritmo de deduplicao com carga completa do arquivo para a
memria.
Fazer a anlise do impacto de utilizar o Dedupeer File Storage em uma rede P2P
com vrios ns, j que o Cassandra d suporte nativo isso e o Dedupeer File
Storage funciona com o Cassandra sendo o gerenciador dos dados armazenados.
Modificar o Dedupeer File Storage para dar suporte distribuio de tarefas de
deduplicao entre os ns da rede P2P criada a partir da sugesto acima, possibilitando a deduplicao de um mesmo arquivo em vrios ns, o que aumentaria
a velocidade para concluso da tarefa. Teoricamente o algoritmo j d suporte
isso, mas o sistema de armazenamento precisa fornecer a distribuio do arquivo
base para deduplicao entre os ns que faro o processamento, e tambm fazer a
coordenao dos ns da deduplicao distribuda.
Utilizar o algoritmo como base para o desenvolvimento de um software de compresso de dados atravs de deduplicao, mantendo as informaes necessrias para
a reidratao dos dados no mesmo arquivo, com funcionamento independente do
sistema de arquivos presente no computador onde o software ser executando. Ele
teria um funcionamento parecido com o de softwares como o WinRar, 7zip, WinZip,
entre outros, mas com a possibilidade de obter maiores ganhos de economia entre
verses de um arquivo.
Analisar ganho de desempenho e economia no Ustore, comparando o sistema com
a utilizao do Dedupeer como componente de deduplicao e sem ele.
74
Referncias Bibliogrficas
[1] Developer guide: Overview. Tech. rep., Google.

[2] Jvm serializer wiki. Tech. rep.
[3] AGARWAL , A., S LEE , M., AND K WIATKOWSKI , M. Thrift: Scalable crosslanguage services implementation. Tech. rep., Facebook, 4 2007.
[4] A LAN , H. Most popular cloud storage provider: Dropbox. Lifehacker.
[5] B HAGWAT, D., E SHGHI , K., L ONG , D. D. E., AND L ILLIBRIDGE , M. Extreme
binning: Scalable, parallel deduplication for chunk-based file backup. In MASCOTS
(2009), IEEE, pp. 19.
[6] B ONWICK.
Zfs deduplication.
Tech. rep., 2009.
"Disponvel
em https://blogs.oracle.com/bonwick/entry/zfs_dedup. Acessado em: Agosto/2012".
[7] B RODER , A. Z. Some applications of rabins fingerprinting method. In Sequences
II: Methods in Communications, Security, and Computer Science (1993), SpringerVerlag, pp. 143152.
[8] C APRIOLO , E. Cassandra High Performance Cookbook. Packt Publishing, Limited,
2011.
[9] D E C ANDIA , G., H ASTORUN , D., JAMPANI , M., K AKULAPATI , G., L AKSHMAN ,
A., P ILCHIN , A., S IVASUBRAMANIAN , S., VOSSHALL , P., AND VOGELS , W.
Dynamo: amazons highly available key-value store. ACM SIGOPS Operating
Systems Review 41, 6 (2007), 205220.
[10] D FAGO , X., U RBN , P., H AYASHIBARA , N., AND K ATAYAMA , T. The ? accrual
failure detector. In RR IS-RR-2004-010, Japan Advanced Institute of Science and
Technology (2004), pp. 6678.
[11] D UBNICKI , C., G RYZ , L., H ELDT, L., K ACZMARCZYK , M., K ILIAN , W., S TR ZELCZAK , P., S ZCZEPKOWSKI , J., U NGUREANU , C., AND W ELNICKI , M. Hydrastor: A scalable secondary storage. In FAST (2009), M. I. Seltzer and R. Wheeler,
Eds., USENIX, pp. 197210.
75
REFERNCIAS BIBLIOGRFICAS
[12] F LOYER , D. Epa energy star enterprise storage draft specification june 4 2009.
Tech. rep., 2009. "Disponvel em http://wikibon.org/wiki/v/EPA_
Energy_Star_Enterprise_Storage_Draft_Specification_
June_4_2009. Acessado em: Abril/2013".
[13] F REEMAN , L. Evolution of the Storage Brain: A history of transformative events,
with a glimpse into the future of data storage. CreateSpace, 2010.
[14] F U , Y., J IANG , H., AND X IAO , N. A scalable inline cluster deduplication framework for big data protection. In Proceedings of the 13th International Middleware
Conference (New York, NY, USA, 2012), Middleware 12, Springer-Verlag New
York, Inc., pp. 354373.
[15] H ENSON , V. An analysis of compare-by-hash. In Proceedings of the 9th conference on Hot Topics in Operating Systems - Volume 9 (Berkeley, CA, USA, 2003),
HOTOS03, USENIX Association, pp. 33.
[16] H EWITT, E. Cassandra: The Definitive Guide. OReilly Media, 2010.
[17] IBM. Ibm protectier deduplication solutions. Tech. rep.
[18] I NSTITUTE , M. G. Big data: The next frontier for innovation, competition, and
productivity. Tech. rep.
[19] K AISER , J., M EISTER , D., B RINKMANN , A., AND E FFERT, S. Design of an exact
data deduplication cluster. In MSST (2012), pp. 112.
[20] K APLAN , J. M., ROY, R., AND S RINIVASARAGHAVAN , R.
Meeting the demand for data storage.
Tech. rep., 2008.
"Disponvel em
https://www.mckinseyquarterly.com/Meeting_the_demand_
for_data_storage_2153#. Acessado em: Fevereivo/2012".
[21] K ATHPAL , A., J OHN , M., AND M AKKAR , G. Distributed Duplicate Detection in
Post-Process Data De-duplication. In High Performance Computing 2011 (2011).
[22] K EMPE , D., K LEINBERG , J., AND D EMERS , A. Spatial gossip and resource
location protocols. ACM Press, pp. 163172.
[23] K ENTON. Protocol buffers. Tech. rep., Google.
76
[24] L ONGORIA , G. Resolving data storage demands with sans. Tech. rep., 2000.
"Disponvel em ftp1.us.dell.com/app/1q00san.pdf. Acessado em: Fevereivo/2012".
[25] M ANDAGERE , N., Z HOU , P., S MITH , M. A., AND U TTAMCHANDANI , S. Demystifying data deduplication. In Middleware (Companion) (2008), F. Douglis, Ed.,
ACM, pp. 1217.
[26] M EISTER , D., AND B RINKMANN , A. dedupv1: Improving deduplication throughput using solid state drives (ssd). In Proceedings of the 2010 IEEE 26th Symposium
on Mass Storage Systems and Technologies (MSST) (Washington, DC, USA, 2010),
MSST 10, IEEE Computer Society, pp. 16.
[27] M EISTER , D., K AISER , J., B RINKMANN , A., C ORTES , T., K UHN , M., AND
K UNKEL , J. A study on data deduplication in hpc storage systems. In Proceedings
of the International Conference on High Performance Computing, Networking,
Storage and Analysis (Los Alamitos, CA, USA, 2012), SC 12, IEEE Computer
Society Press, pp. 7:17:11.
[28]
T ECHNOLOGY, R. I. Sha1 description. Rochester Institute of Technology.

"Acessado em: Julho/2013".
OF
[29] Q UINLAN , S., AND D ORWARD , S. Awarded best paper! - venti: A new approach
to archival data storage. In Proceedings of the 1st USENIX Conference on File and
Storage Technologies (Berkeley, CA, USA, 2002), FAST 02, USENIX Association.
[30] R ABIN , M. Fingerprinting by Random Polynomials. Center for Research in
Computing Technology: Center for Research in Computing Technology. Center for
Research in Computing Techn., Aiken Computation Laboratory, Univ., 1981.
[31] RARLAB. Zip file format. "Acessado em: Julho/2013".
[32] R IVEST, R. L. What is the md5 hash? "Acessado em: Julho/2013".
[33] S AYOOD , K. Introduction to Data Compression, second ed. Morgan Kaufmann
Publishers, San Francisco, CA, USA, 2000.
[34] S CHLOSSNAGLE , T. Scalable Internet Architectures. Sams, 2006.
[35] S CHNEIER , B. When will we see collisions for sha-1? Tech. rep.
77
[36] S CHOLLMEIER , R. A definition of peer-to-peer networking for the classification

of peer-to-peer architectures and applications. In Peer-to-Peer Computing, 2001.
Proceedings. First International Conference on (2001), IEEE, pp. 101102.
[37] S OGHOIAN , C. How dropbox sacrifices user privacy for cost savings. Slight
Paranoia. "Acessado em: Julho/2013".
[38] TARASOV, V., M UDRANKIT, A., B UIK , W., S HILANE , P., K UENNING , G., AND
Z ADOK , E. Generating realistic datasets for deduplication analysis. In Proceedings
of the 2012 USENIX conference on Annual Technical Conference (Berkeley, CA,
USA, 2012), USENIX ATC12, USENIX Association, pp. 2424.
[39] TARASOV, V., M UDRANKIT, A., B UIK , W., S HILANE , P., K UENNING , G., AND
Z ADOK , E. Introduction to storage area networks and system networking. IBM.
[40] T RIDGELL , A., AND M ACKERRAS , P. The rsync algorithm. "Disponvel em http://cs.anu.edu.au/techreports/1996/TR-CS-96-05.
pdf. Acessado em: Agosto/2012".
[41] VALLECILLO , A., H ERNANDEZ , J., AND T ROYA , J. M. Component interoperability. In ECOOP 99 Reader, number 1743 in LNCS (2000), Springer-Verlag,
pp. 121.
[42] V ERSTRYNGE , J. Practical JXTA II: Cracking the P2P puzzle. DawningStreams,
2010.
[43] W EI D ONG , F RED D OUGLIS , K. L. H. P. S. R. P. S. Tradeoffs in scalable data
routing for deduplication clusters. Tech. rep.
[44] W U , J., P ING , L., G E , X., WANG , Y., AND F U , J. Cloud storage as the infrastructure of cloud computing. In Proceedings of the 2010 International Conference on
Intelligent Computing and Cognitive Informatics (Washington, DC, USA, 2010),
ICICCI 10, IEEE Computer Society, pp. 380383.
[45] YANG , T., J IANG , H., F ENG , D., N IU , Z., Z HOU , K., AND WAN , Y. Debar: A
scalable high-performance de-duplication storage system for backup and archiving.
In IPDPS (2010), IEEE, pp. 112.
[46] Z HU , B., L I , K., AND PATTERSON , H. Avoiding the disk bottleneck in the data
domain deduplication file system. In Proceedings of the 6th USENIX Conference
78
on File and Storage Technologies (Berkeley, CA, USA, 2008), FAST08, USENIX
Association, pp. 18:118:14.
79
A
Apndice
A.1
Arquivo de definio dos servios Thrift
namespace java com.dedupeer.thrift

typedef i32 int
typedef i32 weakHash
typedef i64 position
typedef string strongHash
typedef string chunkID
struct ChunkIDs {
1: optional string fileID,
2: required string chunkID,
}
typedef map<weakHash,map<strongHash,ChunkIDs hashesToCompare
struct Chunk {
1: required string fileID,
2: required string chunkNumber,
3: required string index,
4: required string length,
5: optional string strongHash,
6: optional string weakHash,
7: optional string pfile,
8: optional string pchunk,
9: optional string destination
10: optional binary content
}
80
A.2. RESULTADOS DA AVALIAO DOS ARQUIVOS DO CDIGO FONTE DO

KERNEL DO LINUX
service DeduplicationService { map<position,Chunk> deduplicate(1:hashesToCompare

chunksInfo, 2:string pathOfFile, 3:int chunkSizeInBytes, 4:int bytesToLoadByTime),
}
A.2
Resultados da avaliao dos arquivos do cdigo fonte

do Kernel do Linux
Nesta seo esto todas as atribuies de vetores com o tempo em milisegundos das
14 execues para cada tamanho de chunk e algoritmo de hashing utilizadas no Wolfram
Mathematica 9 para a gerao dos grficos. O nome das variveis j so auto explicativos:
operao + algoritmo de hashing + tamanho do chunk.
storeMd5128 = {116890, 128522, 161175, 127015, 182025, 138390, 163266, 164578,
174934, 172479, 264644, 163050, 196002, 199964}
dedupMd5128 = {152626, 121048, 116854, 147668, 107600, 169585, 137500,
128414, 109421, 120321, 152501, 136377, 150033, 115625}
dedupStoreMd5128 = {302343, 266764, 205891, 235066, 181023, 390554, 284572,
225852, 240909, 146712, 257380, 257291, 283357, 219191}
rehydMd5128 = {43120, 39682, 24423, 27270, 32202, 38042, 31570, 29929, 32843,
33967, 74339, 78179, 54132, 63520}
storeMd564 = {224443, 229646, 263209, 287779, 201734, 190391, 146932, 213240,
170712, 243824, 362548, 307237, 209613, 245140}
dedupMd564 = {174321, 147211, 139559, 133334, 120627, 124088, 139953, 119768,
130386, 129988, 138782, 163945, 130047, 166978}
dedupStoreMd564 = {630062, 545441, 520411, 223001, 291992, 231066, 452831,
246117, 335005, 339177, 341458, 306297, 312459, 451774}
rehydMd564 = {44016, 44776, 53259, 42332, 39908, 42605, 51627, 45562, 42655,
49344, 43065, 43992, 39501, 54063}
storeMd532 = {287477, 294028, 200850, 377811, 259185, 230927, 247576, 207965,
249530, 208838, 455668, 270963, 320549, 277556}
dedupMd532 = {145037, 157748, 170891, 132478, 138431, 131754, 133539, 130283,
154380, 150167, 148359, 148353, 166233, 138308}
dedupStoreMd532 = {577638, 412407, 317166, 292932, 259089, 330367, 316198,
365495, 837278, 506792, 602081, 561788, 601541, 354776}
rehydMd532 = {51287, 46370, 46104, 49237, 44773, 47537, 58604, 58947, 57708,
64215, 66442, 55603, 60782, 59282}
81

KERNEL DO LINUX
storeMd516 = {562270, 454941, 424759, 502178, 381864, 412521, 407050, 405793,

473307, 386267, 593349, 421730, 375943, 376105}
dedupMd516 = {188752, 185564, 161651, 193435, 162934, 172242, 163898, 155829,
155889, 188695, 175961, 203188, 202666, 167698}
dedupStoreMd516 = {622743, 629450, 513485, 713067, 639438, 603385, 388159,
337782, 1436801, 831398, 565027, 1698535, 957346, 289319}
rehydMd516 = {86674, 82294, 81711, 84303, 98120, 85317, 85441, 85200, 115681,
121885, 92514, 101977, 105959, 112096}
storeMd58 = {964520, 706285, 701453, 776959, 652153, 626387, 729390, 649180,
647969, 740110, 810059, 638516, 664015, 685365}
dedupMd58 = {262806, 222173, 222521, 213340, 226187, 213091, 211391, 215724,
206816, 208526, 290567, 217865, 255022, 220123}
dedupStoreMd58 = {1233607, 1147788, 950798, 1352302, 992080, 1149349, 1455682,
1091442, 1296342, 1088684, 978422, 1409732, 1212028, 1633295}
rehydMd58 = {211929, 209033, 219621, 214522, 213657, 228344, 208617, 203970,
217254, 211841, 260067, 218043, 235251, 316691}
storeSha1128 = {97349, 109037, 178196, 131649, 222211, 164740, 156184, 175117,
201404, 241228, 186827, 199992, 211887, 171740}
storeSha1128 = {97349, 109037, 178196, 131649, 222211, 164740, 156184, 175117,
201404, 241228, 186827, 199992, 211887, 171740}
dedupSha1128 = {63519, 31808, 31076, 62923, 28399, 39641, 30170, 32386, 27387,
28872, 45208, 28240, 33598, 28513}
dedupStoreSha1128 = {106842, 40104, 38955, 71471, 37059, 48198, 38517, 40062,
35608, 36583, 53701, 36477, 41966, 36642}
rehydSha1128 = {80398, 66018, 74281, 73583, 77102, 79250, 71369, 74586, 61423,
54298, 70373, 54420, 63678, 59489}
storeSha164 = {227047, 246043, 220085, 246523, 258685, 343073, 273425, 163953,
180418, 168436, 241606, 197194, 149808, 340464}
dedupSha164 = {44627, 55439, 37672, 36791, 37862, 45950, 37520, 42662, 36343,
36836, 90213, 37043, 36457, 34334}
dedupStoreSha164 = {60352, 71177, 53407, 52170, 53417, 60901, 51731, 56645,
49782, 50206, 105105, 51850, 51185, 49028}
rehydSha164 = {113640, 121360, 115431, 116551, 120308, 121186, 118612, 119106,
119012, 126016, 120365, 121915, 115323, 122687}
storeSha132 = {342456, 307489, 444142, 271943, 241923, 278932, 234001, 291040,
82

KERNEL DO LINUX
247489, 419230, 310343, 235232, 248579, 230177}

dedupSha132 = {88725, 94374, 83564, 75430, 53590, 42292, 42023, 42247, 42377,
45404, 59797, 52593, 48748, 50663}
dedupStoreSha132 = {311124, 668717, 668684, 318272, 83442, 72593, 71620,
71011, 69193, 71844, 90368, 80840, 76438, 78293}
rehydSha132 = {284121, 283260, 275700, 281079, 280853, 277080, 279279, 271631,
280641, 288302, 224400, 210995, 216494, 227920}
storeSha116 = {562142, 463576, 444615, 530067, 454989, 442680, 441273, 492828,
448203, 426066, 415538, 294142, 544621, 352227}
dedupSha116 = {93354, 78566, 82060, 84914, 87426, 77438, 79562, 82759, 82814,
77072, 86109, 61880, 72285, 68897}
dedupStoreSha116 = {153686, 137637, 380842, 143149, 146810, 134846, 134432,
134202, 134325, 222198, 140885, 116085, 127409, 124290}
rehydSha116 = {555020, 546197, 551883, 577015, 560025, 561874, 569340, 583346,
586910, 439744, 546468, 553587, 573509, 561451}
storeSha18 = {821022, 698555, 790524, 714050, 699568, 718900, 687966, 724312,
936965, 1007309, 675155, 624304, 564328, 626949}
dedupSha18 = {125576, 117776, 118081, 121136, 122290, 114841, 114762, 114715,
125726, 129404, 122153, 104723, 110433, 116113}
dedupStoreSha18 = {256510, 244094, 248895, 664530, 239424, 265320, 231658,
235930, 237475, 416532, 229066, 212203, 217454, 223275}
rehydSha18 = {1124600, 1107152, 1122944, 1178347, 1130081, 1135656, 1129751,
1150545, 1189838, 1162052, 1145106, 1253311, 1251508, 1253582}
83
A.3. GRFICOS DOS TEMPOS EMPARELHADOS POR TAMANHO DE CHUNK

PARA A OPERAO DE ARMAZENAMENTO
A.3
Grficos dos tempos emparelhados por tamanho de

chunk para a operao de armazenamento
Figura A.1 Tempo emparelhado para a operao de armazenamento com chunks de 128KB
84

PARA A OPERAO DE ARMAZENAMENTO
85

PARA A OPERAO DE DEDUPLICAO
A.4

chunk para a operao de deduplicao
Figura A.6 Tempo emparelhado para a operao de deduplicao com chunks de 128KB
86

87

88

PARA A OPERAO DE DEDUPLICAO + ARMAZENAMENTO
A.5

chunk para a operao de deduplicao + armazenamento
Figura A.11 Tempo emparelhado para a operao de deduplicao + armazenamento com chunks
de 128KB
de 64KB
89

PARA A OPERAO DE DEDUPLICAO + ARMAZENAMENTO
de 32KB
de 16KB
90

PARA A OPERAO DE REIDRATAO
de 8KB
A.6

chunk para a operao de reidratao
Figura A.16 Tempo emparelhado para a operao de reidratao com chunks de 128KB
91

92

93

Dedupeer: Deduplicação de Arquivos Através de Um Algoritmo de Processamento Particionado

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dedupeer: Deduplicação de Arquivos Através de Um Algoritmo de Processamento Particionado

Uploaded by

Copyright:

Available Formats

Dedupeer: um Algoritmo para Deduplicao de Arquivos

Atravs de Processamento Particionado

Paulo Fernando Almeida Soares

Universidade Federal de Pernambuco

Universidade Federal de Pernambuco

Paulo Fernando Almeida Soares

Dedupeer: um Algoritmo para Deduplicao de

Trabalho apresentado ao Programa de Ps-graduao em

Orientador: Silvio Romero de Lemos Meira

The deduplication is a technique of lossless data compress that eliminates redundant

O Dedupeer File Storage

Componente para deduplicao em sistemas de armazenamento de dados

O componente Dedupeer File Storage . . . . . . . .

Algoritmo para deduplicao com carga completa do arquivo na

Anlise de desempenho e compresso

Aumento da demanda e reduo do custo de hardware de armazenamento

Armazenamento dos super-chunks nos ns [43]. . . . . . . . . . . . . .

Diagrama de componentes de alto nvel da biblioteca do Dedupeer . . .

Desempenho na serializao dos dados [2] . . . . . . . . . . . . . . . .

Tempo em milissegundos para as execues da operao de armazenamento utilizando MD5 . . . . . . . . . . . . . . . . . . . . . . . . . .

Tempo em milissegundos das execues da operao de reidratao,

A.15 Tempo emparelhado para a operao de deduplicao + armazenamento

Fora do consistncia baseada nos nveis das operaes [8] . . . . . . .

p-values para os dados capturados na operao de armazenamento . . .

Com o aumento da capacidade das unidades de armazenamento, aumentou tambm a

Figura 1.1 Aumento da demanda e reduo do custo de hardware de armazenamento [20]

A indstria de TI passou a apostar em sistemas de armazenamento de dados distribudo

consequncia o espao de armazenamento economizado [19].

Os principais sistemas distribudos de deduplicao de dados so feitos para serem

1.2. DEFINIO DO PROBLEMA

armazenar os arquivos, um sistema de armazenamento pode ser vendido com mais

1.4. ESCOPO NEGATIVO

arquivo ou entre arquivos distintos. O algoritmo ser capaz de identificar as redundncias

As principais contribuies desta pesquisa sero:

delegado para um banco de dados no-relacional construdo em uma arquitetura

Neste captulo, os conceitos e tcnicas fundamentais sobre os assuntos relevantes

Sistemas de armazenamento de dados com foco em

2.1. SISTEMAS DE ARMAZENAMENTO DE DADOS COM FOCO EM

trabalhos acadmicos sero apresentados por ordem de ano de publicao.

Distributed Duplicate Detection in Post-Process Data De-duplication

Devido ao desafio cada vez mais comum em armazenar e gerenciar o crescente

Design of an exact data deduplication cluster

Em [19], explicado sobre o funcionamento de um sistema que executa em cluster e

2.1. SISTEMAS DE ARMAZENAMENTO DE DADOS COM FOCO EM

O -Dedup, que descrito em [14], um middleware de deduplicao de dados para

2.1. SISTEMAS DE ARMAZENAMENTO DE DADOS COM FOCO EM

Figura 2.1 Armazenamento dos super-chunks nos ns [43].

A arquitetura do -Dedup possui 3 componentes principais: o Backup Client, o

2.1. SISTEMAS DE ARMAZENAMENTO DE DADOS COM FOCO EM

particionamento do arquivo e agrupamento dos chunks em super-chunks. O clculo dos

Apesar de no haver nenhuma declarao explcita na homepage do Dropbox 3 ,

Todos os sistemas de armazenamento estudados utilizam armazenamento de dados

A deduplicao de dados um tcnica de compresso sem perda que elimina dados

A deduplicao pode ser de dois momentos: Inline deduplication ou Post-process

Os algortimos para fazer a deduplicao so categorizados em trs tipos, segundo

2.3. SUMRIO DO CAPTULO

armazenar os mesmos dados em um sistema com deduplicao. grande o ganho de

Figura 2.2 Exemplo da economia de espao oferecida em um sistema de armazenamento com

Neste captulo, foi feita a descrio de alguns dos sistemas de armazenamento de

2.3. SUMRIO DO CAPTULO

O Projeto Dedupeer composto pela biblioteca homnima e pelo Dedupeer File

O Dedupeer File Storage um sistema de armazenamento de dados, que pode ser

3.2. O SISTEMA DE ARMAZENAMENTO DISTRIBUDO