UNIVERSIDADE ESTATUDAL DE MARINGÁ Programa de Pós-graduação em desenvolvimento de sistemas para web. João Eduardo Rosa da Fonseca

UNIVERSIDADE ESTATUDAL DE MARINGÁ Programa de Pós-graduação em desenvolvimento de sistemas para web João Eduardo Rosa da Fonseca Visão comparativa de gravação de arquivos em sistema de arquivos e em banco de dados utilizando servidor web Maringá 2013

UNIVERSIDADE ESTATUDAL DE MARINGÁ Programa de Pós-graduação em desenvolvimento de sistemas para web João Eduardo Rosa da Fonseca Visão comparativa de gravação de arquivos em sistema de arquivos e em banco de dados utilizando servidor web Trabalho de conclusão do programa de pósgraduação em desenvolvimento de sistemas web da universidade estatual de Maringá para obtenção do título de especialista em desenvolvimento web Orientador: Munif Gebara Junior 2 Maringá 2013

3 A minha família e amigos, Pela ajuda e incentivo durante minha trajetória

AGRADECIMENTOS A todos que contribuíram para a realização deste trabalho, fica expressa aqui a minha gratidão especialmente: Ao professor Munif Gebara Junior, pela orientação, aprendizado e apoio durante todo os momento necessários. Aos meus colegas de classe durante toda trajetória do curso e pelas amizades que permaneceram após o termino da etapa presencial. Aos meus amigos que me apoiaram e me ajudaram de alguma forma após o meu acidente de carro que ocorreu durante a etapa de escrita do presente trabalho, em especial aos senhores Alessandro Willian e Ulter Witte que me receberam em Florianópolis e me ajudaram. Ao mestre e grande amigo Alex Mattos que leu e revisou o presente trabalho por algumas vezes. Ao senhor Edilson Hipolito, o qual eu conheci durante o curso e tive a honra de ser seu padrinho de casamento. Ao metallica e aos discos death magnetic e S&M, pink floyd e aos discos dark side of the moon e pulse, assim como tantas outras bandas que compuseram obras primas que me animaram durante a escrita deste trabalho. A minha família que me apoiou sempre que necessário. A todos que de alguma forma apoiaram para esta construção. 4

Visão comparativa de gravação de arquivos em sistema de arquivos e em banco de dados utilizando servidor web João Eduardo Rosa da Fonseca 1 Resumo O presente trabalho apresenta uma estudo de análise de comparação da gravação de arquivo enviados pela web e armazenado de duas formas diferente, em sistema de arquivo e em banco de dados. Para isso foram escolhidos quatro diferentes banco de dados sendo três no modelo relacional e um do modelo NoSQL, no caso dos modelos relacionais, foram escolhidos banco de dados com licenças do tipo freeware, GPL, Comercial, que são os bancos de dados Postgres, MySql e oracle, já no modelo NoSql foi escolhido o MongoDB. Os resultado obtidos mostram que ambos os métodos de gravação de arquivos possuem suas vantagens e desvantagens. Entre as vantagens apresentadas no caso dos bancos de dados existem a manipulação de partes específicas dos arquivos, sistema de bakcup incremental nativo do próprio gerenciados do banco de dados, melhor performance na inserção e buscas dos dados no caso dos bancos NoSql. Já as desvantagens nos bancos de dados estão no aumento do espaço de armazenamento, perda de performance após a inserção de vários registros na tabela dos bancos relacionais. Já a vantagens na gravação de arquivos no sistema de arquivos são a fácil implementação, o arquivo ser uma cópia fiel ao arquivo de origem sem aumentar o tamanho ou adicionar bytes de controle e a não instalação de um software gerenciador. Já as desvantagens estão presente na hora de realizar backups, comprar diferença de versões de arquivo, gerenciamento e localização de arquivos. Palavra chave: banco de dados NoSql, banco de dados relacional, gravação de dados. 5

LISTA DE FIGURAS LISTA DE TABELAS 6

LISTA DE SIGLAS ASCII American Standard Code for Information Interchange BLOB Binary large object CD Compact disk CLOB Caracter larg object DVD Digital Versatile Disc IBOPE Instituto brasileiro de opinião pública e estatísticas LOB Large object HTTP Hypertext Transfer Protocol NCLOB - National Character Large Object NoSQL Not only SQL ORDBMS object-relational database management system PHP Hypertext Preprocessor SQL Structured Query Language SSD Solid state disk UOL Universo on-line 7

SUMÁRIO 1.INTRODUÇÃO...11 2.DESENVOLVIMENTO...11 2.1.SOBRE CLIENTE/SERVIDORES...11 2.2.SERVIDORES DE ARQUIVO...12 2.3.SERVIDORES DE BANCO DE DADOS...12 2.4.SERVIDORES WEB...12 2.5.SOBRE ARQUIVOS...13 2.6.SOBRE BANCO DE DADOS...13 2.6.1.RELACIONAIS...13 2.6.2.NÃO RELACIONAIS...14 2.7.SOBRE GRAVAÇÃO DE ARQUIVOS...14 2.7.1.GRAVAÇÃO EM FILE SYSTEM...14 2.7.2.GRAVAÇÃO EM BANCO DE DADOS...14 2.7.2.1.ORACLE...15 2.7.2.2.MYSQL...17 2.7.2.3.POSTGRESQL...17 2.7.2.4.MONGODB...17 3.CONSIDERAÇÕES FINAIS...19 3.1.MYSQL...19 8

3.1.1.POSTGRES...21 3.1.2.ORACLE...21 3.1.3.MONGODB...21 4.RESULTADOS...22 5.CONCLUSÃO...25 6.REFERÊNCIAS...26 1. Introdução Segundo reportagem do portal de tecnologia do UOL(Universo on-line) em 1 o de novembro de 2012 com o título de Ibope: internet no Brasil chega a 70,9 milhões de pessoas em casa e no trabalho, exibe dados coletados por pesquisas do IBOPE(Instituto brasileiro de opinião pública e estatísticas) sobre o crescimento de pessoas no Brasil que acessam a internet em casa e no trabalho, no mês de setembro de 2012 esse número atingiu 70,9 milhões de usuários, sendo que crescimento do números de usuários ativos em setembro de 2012 foi 1,4% maior em relação a agosto do mesmo ano e 11% maior que no mesmo período de 2011. (UOL notícias, 2013) Em outra reportagem publicada no portal exame da editora abril em 02 de junho de 2011 com o título: Você sabe o tamanho da internet?, que toma como base os estudo visual networking index realizado pela cisco que afirma que A estimativa é de que, hoje, o trafego da internet produz por hora informações suficientes para ser contidas em 7 milhões de DVDs (Exame.com, 2013). O estudo realizado pela cisco ainda prevê que em 2015 o trafego por hora produza 966 exabytes de informação, o que daria para preencher 28 milhões de DVDs. 9

Essas duas reportagens mostra que popularização da internet por meio de banda larga, e a quantidade de conteúdo produzido na internet mostra que cada vez mais o armazenamento de grande capacidade de dados será necessária. Para esse armazenamento existem diversas técnicas de recebimento, processamento e armazenamento dos dados produzidos. Essas técnicas variam desde a gravação do arquivo em uma pasta do sistema operacional, até do armazenamento dos dados e documentos como registros de banco de dados. 2. Desenvolvimento Inicialmente para entendimento da diferença entre a gravação dos documentos em forma de arquivos, é necessário entender a diferença básica entre as duas forma de armazenamento, a em arquivo de sistema e como registro em banco de dados. A gravação de arquivos em sistema de arquivos(file system) originados de uma requisição web é realizada é chamada de upload. O arquivo é envidado para um servidor web via protocolo http, onde o servidor recebe e armazena o arquivo em uma pasta no seu disco, nesse caso o usual é que no banco de dados fique armazenado o nome do arquivo com o seu caminho físico em disco. (Searchnetworking, 2013) Já no upload e gravação de arquivo em banco de dados, o arquivo é convertido uma cadeia de byte, cada banco de dados tem seu tipo de dado(data type) para armazenar cadeias de bytes, essa cadeia de bytes é enviada para uma coluna no banco de dados(searchnetworking, 2013), dependendo do tamanho do arquivo é possível ser armazenado em um só registo, mas em alguns data types tem limitações de tamanho dos dados, fazendo assim que se use uma estratégia onde 10

arquivo é quebrado em várias cadeias de bytes e essas cadeias são inseridas em vários registros no banco de dados. Quando o usuário requisita o arquivo, é necessário que o registro ou registros sejam recuperado e convertido novamente para arquivo através de um algoritmo. 2.1. Sobre Cliente/servidores Na arquitetura cliente/servidor, o servidor seria o responsável pelo controle e centralização de informações que são compartilhadas e acessadas por computadores em uma rede, os computadores que fazem o acesso ao servidor são nomeados de clientes. segundo Júlio Battisti : É uma arquitetura onde o processamento da informação é dividido em módulos ou processos distintos. Um processo é responsável pela manutenção da informação (Servidor), enquanto que outro é responsável pela obtenção dos dados (Cliente) (BATTISTI, 2001). Assim sendo, a arquitetura de cliente servidor pode ser utilizado tanto na forma de gravação de arquivos via file system, assim como na gravação de arquivos em banco de dados. também é necessário entender que para que a arquitetura de cliente/servidor funcione de forma eficiente, há um componente vital entrer o cliente e o servidor, que é a infraestrutura de rede. Essa infraestrutura de rede influencia diretamente na performance de subira(upload) e descida(download) dos arquivos do servidor para o cliente, assim sendo, uma rede melhor estruturada, com equipamentos de alta velocidade, ou mesmo a utilização de serviços de banda largar no caso da internet fazem com que arquivos sejam enviado e recuperado no servidor de forma mais ágil e rápida. Outra coisa que influencia na velocidade é o poder de processamento do servidor, a quantidade de memória e quantos acessos o servidor está recebendo no instante da recuperação de arquivos. Pois quanto maior o número de acessos, maior é o consumo de memória do servidor e maior é o 11

consumo da banda da rede, tornado assim mais lento o acesso e recuperação do arquivo armazenado no servidor. Segue a ilustração da arquitetura cliente/servidor. Figura - Arquitetura cliente/servidor Fonte :Cliente/Servidor, 2013 Nos próximos capítulos iremos explorar mais a fundo o funcionamento de toda a estrutura da arquitetura cliente/servidor. 2.2. Servidores de arquivo Segundo o site da microsoft sobre servidores de arquivo: O servidor de arquivos fornece um ponto centralizado na rede para armazenamento e compartilhamento de arquivos entre os usuários. Quando desejarem usar um arquivo importante, como um planejamento de projeto, os usuários podem acessá-lo diretamente no servidor de arquivos, em vez de precisarem repassar o arquivo entre cada computador. Se os usuários da rede precisarem acessar os mesmos arquivos 12

e aplicativos acessíveis pela rede, configure o computador como servidor de arquivos. (Microsoft, 2012) Assim sendo, o servidor de arquivo tem um papel fundamental nas empresas, centralizando o compartilhamento de arquivos e sendo uma tentativa de evitar que esses arquivos seja compartilhado com todos a todo momento, assim como evitar que o mesmo arquivo tenha cópias de diferentes versões. Com a evolução das redes de dados, dispositivos de armazenamento e serviços providos na internet, os servidores de arquivos passaram a ser uma ferramenta que não precisa mais ficar alocado dentro da empresa e sim como um serviços na internet. A disponibilização do servidor de arquivos como serviço permitiu que a sua utilização deixa-se de ser apenas pelo meio coorporativo e passou a estar disponível também para o uso particular. Existem alguns exemplos de servidores de arquivos disponível como serviço e utilizado de forma particular hoje em dia, como o google drive da google, Skydrive da microsoft, Dropbox da Dropbox inc. entre outros. Mas não é possível saber se esse servidor de arquivos armazena os documentos em file system ou em banco de dados. Existem também servidores de arquivos para compartilhamento de arquivos de forma pública, onde o usuário disponibilizam arquivos que podem ser baixados por qualquer usuário com conexão de internet e um browser. Essa forma de compartilhamento de arquivo gerou alguns problemas depois de um tempo por uma grande quantidade de usuários disponibilizarem arquivos com conteúdo protegido por direito autoral. alguns desses serviços públicos de servidor de arquivos chegaram a ser fechados judicialmente como por exemplo o mega upload. já outros mudaram sua política de publicação de conteúdo como por exemplo os serviços do 4shared, RapidShare, MediaFire etc. 13

Mas o objetivo do artigo não é falar sobre a parte legal do compartilhamento de arquivos e sim a forma com que esses dados podem ser armazenados. 2.3. Servidores de banco de dados Os servidores de banco de dados, tem como finalidade ser o ponto central de armazenamento de informações em um sistema de tabelas, sendo ela relacional ou não. segundo Júlio Battisti: Sistema inovador surgido nos anos 90 e muito utilizado no meio corporativo, baseado em três componentes principais: gerenciamento de banco de dados, que funcionam como servidores; redes, que funcionam como meio de transporte de dados e, finalmente, softwares para acesso aos dados: Clientes. (BATTISTI, 2001, pg 39). Esse software para acesso apontado por Battisti, pode ser desde um simples browser de internet fazendo uma requisição de informações para o servidor de banco de dados. até uma aplicação específica criada para acessos mais específicos de dados. Um diferencial do servidor de banco de dados é que além de fornecer um ponto central para o armazenamento de arquivos, é possível também armazenar dados de outros tipo de informações pertencente a uns sistema implementado para o cliente. Um outro ponto forte dos servidores de banco de dados seria que a próprias ferramenta fornece mecanismos realização de backups, recuperação por meio de um arquivo único de todas as informações assim como funções desenvolvidas para que o banco realize esses backup s de forma automatizada. 2.4. Servidores web Como o presente trabalho tem como objetivo demostrar a gravação de arquivos nos servidores de arquivos e de banco de dados por meio de um ambiente web, não poderíamos deixar de falar do servidor web. O servidor web tem como finalidade fornecer os serviços uma aplicação web, interagindo assim com os outros 14

servidores(arquivos e banco de dados) em um ambienta acessado por um navegar. segundo o site da microsoft Servidores web são computadores com software específico que permitem a aceitação de solicitações de computadores de clientes e retornam respostas à essas solicitações. Os servidores web permitem que você compartilhe informações pela Internet ou por uma intranet ou extranet..(microsoft, servidor web, 2012) No site da microsoft, ainda é apontado algumas finalidades de uso dos servidores. Que no caso do site expõem algo mais voltado para o servidor desenvolvido pela própria empresa, chamado de IIS(Internet Information Services). Na tabela 1 segue os exemplos das aplicações em servidores web IIS 7 Tabela - Aplicações dos servidores web Fornecer informações para usuários pela Internet. Permitir que usuários façam download e upload de conteúdos com FTP ou WebDAV (criação e versão distribuídas na Web). Hospedar serviços da Web que contém lógica empresarial para aplicativos de três camadas. Distribuir aplicativos para usuários pela Internet ao invés de disquetes ou CDs. Os servidores Web podem ser úteis para clientes e necessidades diferentes. Por exemplo: Proprietários de pequenas empresas podem fornecer informações sobre seus serviços usando um simples site. Proprietários de empresas médias podem oferecer seus produtos e serviços por meio de um sistema de pedidos online composto por vários aplicativos em um site. Empresas de negócios podem desenvolver e fornecer aplicativos de negócios a funcionários por meio de intranets corporativas. Empresas de hospedagem podem fornecer, a clientes individuais, espaço e serviços de hospedagem de diferentes conteúdos online e aplicativos. Empresas podem fornecer aplicativos de negócios e informações pertinentes para parceiros de negócios por meio de extranets. Fonte: Microsoft 15

Mas assim como a escolha de qualquer tipo de servidor, o dimensionamento dos recursos do servidor web passa por uma análise das necessidades da aplicação desenvolvida e da quantidade de recurso que sua aplicação irá necessitar. 2.5. Sobre arquivos Os arquivos de computadores são, um conjunto de bytes estruturado armazenados em algum meio que pode ser recuperado depois. Essas estruturas são armazenadas e contém uma extensão responsável por indicar qual o programa responsável pela leitura, processamento e abertura desse arquivo, assim, recuperando a informação contidas nele. Existe também arquivos denominados executáveis, esses arquivos conseguem a partir da sua própria estrutura serem abertos e lidos para executar ações pré definidas. 2.6. Sobre banco de dados Atualmente existe um grande número de banco de dados que podem ser instalado e utilizados em servidores, a definição de qual o banco de dados será utilizado em sua aplicação, varia muito do que será desenvolvido e o que esse aplicativo irá necessitar armazenar de dados. É comum que a escolha do sistema de banco de dados passe por uma avaliação criteriosa que vai desde a quantidade prevista de acessos simultâneos, tipo de dados que serão armazenados, até quais as licenças que esse sistema de banco de dados segue para a sua utilização. Os banco de dados, tem como princípio básico seguir alguns atributos, como tabelas, registros, colunas e chaves. Uma tabela é uma simples estrutura de linhas e colunas. Em uma tabela, cada linha contém um mesmo conjunto de colunas. Em um banco de dados podem existir uma ou centenas de tabelas, sendo que o limite pode ser imposto tanto pela 16

ferramenta de software utilizada, quanto pelos recursos de hardware disponíveis no equipamento. As colunas de uma tabela são também chamadas de atributos. Ex.: O campo Nome, ou endereço de uma tabela de um banco de dados relacional. Os registros são linhas formadas por pelas colunas, mas não necessariamente todas as colunas precisam estar completas, apenas as que estão estabelecidas como não nulas(not null). As tabelas relacionam-se umas as outras através de chaves. Uma chave é um conjunto de um ou mais atributos que determinam a unicidade de cada registro. Existem diferentes tipos de bancos de dados, sendo diferenciados sempre pela sua estrutura de armazenamento e recuperação de informações. Os banco de dados são divididos em duas classes, os relacionais e os não relacionais, que também são conhecidos como NoSql. 2.6.1. Relacionais Os banco de dados relacionais, são bancos de dados mais utilizados em aplicações por seguirem as 13 regras do modelo relacional, essas regras foram criadas e publicadas por Edgar Frank Codd em 1985, para que o banco de dados seja considerado relacional, ele deve seguir as seguintes regras apresentadas na tabela 2. Tabela - As 12 regras de Codd Regra Regra 1 Descricação Todas as informações em um banco de dados relacional são representadas de forma explícita no nível lógico e exatamente em Regra 2 apenas uma forma - por valores em tabelas. Cada um e qualquer valor atômico (datum) em um banco de 17

dados relacionam possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e Regra 3 do nome da coluna. Valores nulos devem ser suportados de forma sistemática e independente do tipo de dado para representar informações Regra 4 inexistentes e informações inaplicáveis. A descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos Regra 5 dados regulares. Um sistema relacional pode suportar várias linguagens e várias formas de recuperação de informações. Entretanto, deve haver pelo menos uma linguagem, com uma sintaxe bem definida e expressa por conjuntos de caracteres, que suporte de forma compreensiva todos os seguintes itens: definição de dados, definição de "views", manipulação de dados (interativa e embutida em programas), restrições de integridade, autorizações e limites de transações Regra 6 Regra 7 (begin, commit e rollback). Todas as "views" que são teoricamente atualizáveis devem também ser atualizáveis pelo sistema. A capacidade de manipular um conjunto de dados (relação) através de um simples comando deve-se estender às operações Regra 8 de inclusão, alteração ou exclusão de dados. Programas de aplicação permanecem logicamente inalterados quando ocorrem mudanças no método de acesso ou na forma de Regra 9 18 armazenamento físico. Mudanças nas relações e nas views provocam pouco ou nenhum impacto nas aplicações.

Regra 10 Regra 11 Regra 12 As aplicações não são afetadas quando ocorrem mudanças nas regras de restrições de integridade. As aplicações não são logicamente afetadas quando ocorrem mudanças geográficas dos dados. Se um sistema possui uma linguagem de baixo nível, essa linguagem não pode ser usada para subverter as regras de integridades e restrições definidas no nível mais alto. Fonte: Serpro 2.6.2. Não relacionais Bancos não relacionais ou conhecido como NoSql, são bancos criados para atender a necessidades de aplicações onde os bancos de dados relacionais são ineficazes. O termo foi utilizado pela primeira vez em 1998 por seu criado, Carlo Strozzi, onde ele dizia que o NoSql é complemente distindo do modelo relacional e, portanto, deveria ser mais apropriado chamado de NoREL ou algo que produzisse o mesmo efeito. (NoSql, 2012) As principais características dos bancos de dados não relacionais são a sua alta performance, replicação, escalabilidade, suporte a dados estruturados e sub colunas Os bancos de dados não relacionais, ou também conhecidos como NoSQL, são bancos que não seguem os princípios das leis de Edgar Frank Codd, assim sendo, ele armazena os dados de diferentes formar, normalmente esses dados são armazenados com arrays associativos ou pares de chave e valor. Os bancos NoSQL são normalmente utilizados para finalidades específicas, conforme a tabela 3 demostra: Tabela - Projetos NoSql Tipo Documento Projeto RavenDB, CouchDB, MongoDB, MarkLogic, Server, BaseX, exist 19

Orientado a Objetos Chave/Valor (Key/Value) Tabular Grafos Db4o Memcachedb, Project Voldemort, Redis, SimpleDB, Hbase Cassandra e Hypertable DEX e Neo4j Fonte:NoSql 2.7. Sobre gravação de arquivos A gravação de arquivos pode ser feita em vários meios, pois os blocos de bytes, podem ser divididos e armazenados em diversos tipos dispositivos e de diversas formas diferentes, seja ela diretamente no dispositivo de armazenamento, banco de dados, além disso o arquivo pode ser compactado, criptografado, divididos em blocos etc, antes de sua gravação. 2.7.1. Gravação em file system A gravação em file system, ou também conhecida como sistema de arquivos é realizada em pequenos blocos pré-definidos no sistema operacional, esse blocos são conjunto de bytes que o sistema operacional padroniza para gravar e recuperar os arquivos direto de disco rígidos, SSD(Solid state disk), fita magnética, CD(Compact disk) ou qualquer outro meio de gravação. 2.7.2. Gravação em banco de dados Para a gravação de arquivos em banco de dados, existem tipos específicos de campos para registro e técnicas diferentes técnicas de inserção dos dados. Para entender a gravação desses arquivos no banco, é necessário entender os tipo de arquivo que será gravado e como essas informações são armazenadas. Nos bancos de dados relacionais, cada banco tem o seu tipo específico de registro de como armazenas esses arquivos. No caso dos bancos escolhidos para o prensente trabalho, Foram escolhidos bancos de dados de diferentes tipo de 20

licenças, Sendo escolhido no modelo relacional o Postgres, MySql e oracle, já no modelo NoSql foi escolhido o MongoDB. Na tabela 4 é possível visualizar os tipos de dados e o tamaho máximo que é possível armazenar nesses registros Tabela - Tipos de dados Nome Oracle 11g MySql PostgreSQL Tipo para gravação de dados BLOB, CLOB, NCLOB, BFILE TINYBLOB, TINYTEXT BLOB, TEXT MEDIUMBLOB, MEDIUMTEXT LONGBLOB, LONGTEXT BYTEA(HEX,ES CAPE) Fonte: Desenvolvida pelo autor. Máximo por registro 128 terabytes 256 bytes 64 Kilobytes 16 Megabytes 4 Gigabytes 1 Gigabytes 2.7.2.1. Oracle O Banco de dados oracle 11g possuí o diferentes tipos de dados para armazenamento de arquivos, esses tipos de dados são chamado de LOB(Large object) e são divididos em sub-tipo que são os BLOB(Binary large object), CLOB(Caracter larg object), NCLOB e BFILE. segundo a documentação da oracle subro os tipos LOB permitem armazenar e manipular grandes blocos de dados não estruturados (como texto, imagens, gráficos, vídeos, som e formas de onda) em formato binário ou caracteres. (Oracle, 2013, tradução nossa) Ainda na documentação, a oracle descreve como os tipos LOBs trabalham que é: eles fornecem acesso aleatório, eficiente a pedaços inteligentes dos dados. (Oracle, 2013, tradução nossa) Os dados do tipo LOB diferem em dois tipos, os RAW e LONG RAW. Mas ele explica que ambos os tipos não são interpretados pelo banco de dados: Os tipos 21

de dados RAW e LONG RAW são usados para dados que não deve ser interpretado (não convertido ao mover dados entre diferentes sistemas) pelo banco de dados Oracle. Esses tipos de dados são destinados para dados binários ou cadeias de bytes. (Oracle, 2013, tradução nossa). O que indica que por exemplo uma imagem armazenada em banco, é convertida para dados binários ou cadeiras de bytes. Caso uma consulta seja realizada por uma query no banco irá não irá mostrar a imagem, mas sim os dados binários ou a cadeia de bytes. Para que a imagem seja exibida, será necessário que um programa consulte o banco e converta os dados binário ou a cadeia de bytes na imagem. Na documentação do oracle 11g ainda explica que LONG RAW pode ser usado para armazenar gráficos, som, documentos, ou matrizes de dados binários. A interpretação depende do uso. RAW é um tipo de dados de comprimento variável como o tipo de dados de caractere VARCHAR2, A documentação indica que LONG RAW dados não podem ser indexados, mas RAW dados podem ser indexados. (Oracle, 2013, tradução nossa) A tabela 5 mostra outras características dos tipos de dados RAW e LONG RAW indicadas na documentação do banco dados oracle 11g. Tabela - Caracteristicas de RAW e LONG RAW LONG. Uma tabela pode conter colunas LOB, mas apenas uma coluna Uma tabela contendo uma ou mais colunas LOB pode ser dividida, mas uma tabela contendo uma coluna LONG não pode ser particionado. O tamanho máximo de um LOB é de 128 terabytes, dependendo do tamanho do bloco de dados, e o tamanho máximo de um LONG é de apenas 2 gigabytes. LOBs apoiar o acesso aleatório a dados, mas LONG s suportam 22

apenas acesso seqüencial. Tipos de dados LOB (exceto NCLOB ) pode ser atributos de um tipo de objeto definido pelo usuário, mas tipos de dados LONG não pode. LOBs temporários que atuam como variáveis locais podem ser usados para realizar transformações em dados LOB. LOBs temporários internos ( BLOBs, CLOBs e NCLOB s) são criados em um espaço de tabela temporária e são independentes de tabelas. Para tipos de dados LONG, no entanto, não há disponibilidade de estruturas temporárias. Tabelas com colunas LOB pode ser replicadas, mas tabelas com colunas LONG não pode Fonte: Oracle Depois de entendermos sobre o funcionamento dos dados RAW e LONG RAW, podemos prosseguir com o entendimento dos tipo de dados que pertencem ao LOB, que são os BLOB, CLOB, NCLOB e BFILE. Na documentação do oracle 11g, afirma sobre o BLOB que: O tipo de dado BLOB armazena dados binários não estruturados no banco de dados. BLOBs pode armazenar até 128 terabytes de dados binários. (Oracle, 2013, tradução nossa) Os tipo CLOB e NCLOB são diferenciados do BLOB por armazenarem os dados em forma de caracteres: Os tipos de dados CLOB e NCLOB armazenar até 128 terabytes de dados de caracteres do banco de dados. (Oracle, 2013, Tradução nossa). Ainda sobre CLOB e NCLOB, a documentação fala mais especificamente sobre o CLOB: O tipo de dados CLOB armazena dados de caracteres de byte único e multibyte. Ambos os conjuntos de caracteres de largura fixa e variável são suportados, e ambos utilizam o conjunto de caracteres do banco de dados. 23

E sobre NCLOB: O tipo de dados NCLOB armazena dados Unicode. Ambos os conjuntos de caracteres de largura fixa e variável são suportados, e ambos utilizam o conjunto de caracteres nacionalizados. (Oracle.2013. Tradução nossa). Já por fim o tipo BFILE armazena os dados arquivos do sistema operacional, ou seja, fora do banco de dados: O tipo de dado BFILE são dados binários não estruturados de em arquivos do sistema operacional fora do banco de dados. A coluna ou atributo BFILE armazena um arquivo localizador que aponta para um arquivo externo que contém os dados. A quantidade de dados BFILE que podem ser armazenados é limitado pelo sistema operativo. BFILEs são somente leitura, você não pode modificá-los. Eles suportam apenas leituras aleatórias (não sequencial), e não participar de transações. O sistema operacional subjacente deve manter a integridade de arquivos, segurança e durabilidade para BFILEs. O administrador de banco de dados deve garantir que o arquivo existe e que os processos de banco de dados Oracle tem permissões de leitura do arquivo no sistema operacional. (Oracle, 2013, Tradução nossa) Na documentação da oracle, as colunas do tipo LOB são sujeitas a algumas regras, a tabela 6 lista algumas delas. Tabela - Regras das colunas LOB primária. Você não pode especificar um LOB como uma coluna de chave Clusters não pode conter LOBs, quer como chave ou colunas nãochave. Você não pode especificar colunas LOB no ORDER BY cláusula de uma consulta, ou no GROUP BY cláusula de uma consulta ou em uma função agregada. 24

Você não pode especificar uma coluna LOB em uma SELECT... DISTINCT ou SELECT... UNIQUE declaração ou em uma junção. No entanto, você pode especificar um atributo LOB de uma coluna de tipo de objeto em um SELECT... DISTINCT ou em uma consulta que usa a UNION ou operador MINUS de conjunto, se o tipo da coluna objeto tem um MAP ou ORDER função definida sobre ele. O (primeiro INITIAL extensão) de um segmento de LOB deve conter, pelo menos, três blocos de dados. Você não pode especificar uma coluna LOB, como parte de uma chave de índice. No entanto, você pode especificar uma coluna LOB na especificação indextype de um índice de domínio. Além disso, o Oracle Text permite que você defina um índice em uma coluna CLOB. Em uma operação INSERT... AS SELECT, você pode ligar até 4000 bytes de dados para colunas LOB e atributos Se a tabela tem tanto LONG e colunas LOB, você não pode ligar mais de 4000 bytes de dados tanto para o LONG e colunas LOB na mesma instrução SQL. No entanto, você pode ligar mais de 4000 bytes de dados para tanto o LONG ou a coluna LOB. Restrições de operação No SQL Loader, Um campo de leitura de um LOB não pode ser usado como um argumento para uma cláusula. Consulte "Utilitários de banco de dados para carregar dados em LOBs". Sessão migração não é suportada para BFILE em servidor modo compartilhado (servidor multithreaded). Isto implica que as operações em aberto BFILE podem persistir para além do final de uma chamada para um servidor compartilhado. Em sessões de servidor compartilhado, BFILE operações são obrigados a um servidor compartilhado, que não podem migrar de um servidor para outro. Maiúsculas e minúsculas pesquisas sobre colums CLOB muitas vezes não conseguem. Por exemplo, para fazer uma pesquisa de maiúsculas e minúsculas em um colum CLOB. 25

A seleção não sem a LOWER função. Texto Oracle faz pesquisas maiúsculas e minúsculas. Fonte: Oracle 2.7.2.2. MySql O banco de dados MySql, é um banco de dados que se tornou popular com a expansão web e foi difundido principalmente por programadores php. Atualmente o MySql pretence a Oracle Corporation. O MySql, assim como os outros bancos de dados, possui um tipo de registro especifico para arquivos, assim como já citado anteriormente, os tipos de registros são o BLOB, e o TEXT. Segundo o site do MySql: Um BLOB é um objeto binário grande que pode guardar uma quantidade variável de dados. Os quatro tipos de BLOB são TINYBLOB, BLOB, MEDIUMBLOB, e LONGBLOB. Estes diferem apenas no comprimento máximo dos valores que eles podem armazenar. Os quatro tipos TEXT são TINYTEXT, TEXT, MEDIUMTEXT, e LONGTEXT. Estes correspondem aos quatro tipos BLOB e têm o mesmo tamanho máximo e os requisitos de armazenamento. (MySql, 2013, tradução nossa). Ainda na documentação do MySql, a diferença entre o BLOB e o Text são: BLOB são valores tratados como strings binárias (cadeias de bytes). Eles não têm nenhum conjunto de caracteres, e ordenação e comparação, são baseados nos valores numéricos dos bytes de valores da coluna. TEXT são valores tratados como strings não binários (sequências de caracteres). Eles têm um conjunto de caracteres, e os valores são classificados e comparados com base no agrupamento do conjunto de caracteres. (MySql. 2013. Tradução nossa). Segue a tabela 7 demosntra os tamanhos máximos que podem ser armazenados os dados em bytes. Tabela - Tamanho máximo dos dados no MySql 26

Tipo de dado TINYBLOB, TINYTEXT BLOB, TEXT MEDIUMBLOB, MEDIUMTEXT Tamanho L + 1 bytes, where L < 2 8 L + 2 bytes, where L < 2 16 L + 3 bytes, where L < 2 24 LONGBLOB, LONGTEXT Fonte: MySql L + 4 bytes, where L < 2.7.2.3. PostgreSQL Segundo o site do PostgreSQL,: O PostgreSQL é um sistema de gestão de banco de dados objeto-relacional (ORDBMS) com base no POSTGRES, Versão 4.2, desenvolvido no Departamento de Informática da Universidade da Califórnia, em Berkeley. O POSTGRES foi pioneiro muitos conceitos que só se tornaram disponíveis em alguns sistemas de banco de dados comerciais muito mais tarde. (Postgres, 2013. Tradução nossa). O padrão SQL define que o tipo de cadeia binária é chamada de BLOB(Binary Large Object). Mas no caso do PostgreSQL o tipo de armazenamento de dados binários possuem um nome diferente que é o byteae foi inserido no postgres a partir da versão 9.0. Mesmo com o nome diferente, as funções e operadores fornecidos para a operação são praticamente os mesmos. O tipo bytea é descrito na documentação como: O tipo de dado bytea permite o armazenamento de sequências binárias.(postgres, 2013, tradução nossa ) 2 32 Essas sequências binárias de bytes são sequencias diferenciadas de sequência de caracteres por exemplo, onde a sequência de caracteres são codificados normalmente pela tabela ASCII com os caracteres imprimíveis(códigos 27

entre 32 e126), Assim sendo no tipo bytea são permitido codificações de tipos não imprimíveis. O bytea também é um tipo que não sofre de problemas de codificação de localidade como no caso de sequencia de caracteres. Em termos, o bytea serve para armazenar bytes de dados brutos e as sequencias de caracteres servem para armazenar textos. O tipo bytea são diferenciados em dois formatos, o hex e o escape, sendo o escape o tipo de dado mais tradicional do postgresql. No caso do escape ele segue a linha de converter as sequências binárias em sequências de caracteres ASCII. Ao converter os dados para sequencias não representadas pela tabela ASCII, o escape utiliza caracteres especiais do próprio tipo escape. Essa conversão é iniciada sempre com um ou duas barras invertidas (a barra invertida é um escape literal) e faz com que cada byte seja convertido para um conjunto de três dígitos. O mecanismo de caracteres especiais do tipo escape é um pouco pesado, assim sendo, a utilização da conversão de bytes para o tipo escape deve ser evitada. No caso do formato hex, cada registro é iniciado com \x e cada byte dos dados são codificados para dois dígitos hexadecimais, é permitido espaço entre os pares de valores hexadecimais, mas não é permitido espaço em branco entre o par do bytes convertido para hexadecimal. O tipo hex é o tipo padrão do postgres e tende a ser mais rápido que a conversão para o tipo escape, assim sendo, é preferencialmente usando nas aplicações. Ao inserir um registro do tipo bytea, é acrescido de 1 a 4 bytes como bytes de controle e mais a sequencia de bytes convertidos. Assim sendo cabe avaliar o quanto esses bytes de controle podem influir no tamanho do arquivo inserido em bando e no desempenho para sua recuperação, principalmente no caso de um arquivo que foi quebrado em diversos registro. 28

2.7.2.4. MongoDB O mongodb é um banco de dados open source orientado a documento desenvolvido para fácil uso de desenvolvimento e escalabilidade. Para iniciar o entendimento de como funciona um banco de dados orientado a documentos, na tabela 8 vamos comprar e entender os termos e conceitos entre um banco de dados objeto relacional e um banco de dados NoSQL. Tabela - Comparação dos termos e conceitos do Sql e NoSql Termos e conceitos do SQL Database Table Row Index Table joins Primary key(chave primária) uma única coluna ou uma combinação de colunas Termos e conceitos do MongoDB Database Collection Documento ou documento BSON Index Documentos embarcados ou linkados Primary key(chave primária) No mongodb, a chave primária é setada automaticamente no Agregação(Group by) campo _id Framework de agregação Fonte: MongoDB No caso citado na tabela anterior, o framework de agregação possui uma tabela indicando um outro comparativo de como funciona em um banco de dados SQL e o mongodb. A tabela 9 mostra essa diferença. Tabela - Comparativo de termos, funções e conceitos Sql e NoSql Termos, funções e conceitos SQL WHERE GROUP BY HAVING SELECT ORDER BY LIMIT SUM() COUNT() 29 Operações de agregação do mongodb $MATCH $GROUP $MATCH $PROJECT $SORT $LIMIT $SUM $SUM

JOIN Não existe um operador correspondente ao JOIN no mongodb, de toda forma, o operador $UNWIND tem funcionalidades semelhantes com as colunas e com os documentos. Fonte: MongoDB No mongodb a gravação de arquivo é feita atrás vez de um BinData é feita por um registro do tipo BSON(Binary-encoded serialization), que é um registro semelhante ao JSON só que para inserção de documentos. O BSON foi projetado pra ser leve e eficiente, assim como JSON. O BSON suporta a incorporação de objetos e arryas dentro de outros objetos e matrizes. No entando para armazenamento de arquivos maiores de 16 megabytes a documentação do mongodb fala para usar o GridFS como alteranativa, o GridFS tem por padrão pegar os arquivos que excedam 16 megabytes e dividir em blocos menores de 256k, nesta divisão ele utiliza duas coleções para realizado armazenamento dos dados, sendo uma para armazenar os pedrações dos arquivos e outra para armazenar o metadados. Uma das vantagens em usar o GridFS é que ao caso o usuário necessite carregar um arquivo particionado, ele vai montando os pedaços do arquivo conforme necessário, assim sendo, você pode realizar consultas apenas em partes do arquivo, sem ter que carrega-lo todo. Na documentação ainda existe uma seção chamada de Como faço para otimizar o uso de armazenamento para documentos pequenos? (Mongodb, 2013) é explicito que Cada documento MongoDB contém uma certa quantidade recursos 30

ocupados. Esses recursos normalmente são insignificante, mas torna-se significativo se todos os documentos inseridos são apenas alguns bytes, como poderia ser o caso se os documentos em sua coleção só tem um ou dois campos. (Mongodb, 2013) Assim sendo, a documentação passa a seguinte sugestões como estratégia para otimizar a utilização do armazenamento para coleções no mongodb: Clientes MongoDB caso o usuário não insira um valor no campo _id o mongobd adiciona automaticamente um campo _id a cada documento inserido, esse campo _id gerar 12 byte únicos. Para documentos menores isto pode representar uma quantidade significativa de espaço. Para otimizar o uso de armazenamento, os usuários podem especificar um valor para o campo _id explicitamente Ao inserir documentos na coleção. Esta estratégia permite aplicações para armazenar um valor no campo _id Isso teria espaço ocupado em outra parte do documento. Você pode armazenar qualquer valor no campo _id, mas como este valor serve como uma chave primária para documentos, caso esse valor do campo não seja único, então ele não pode servir como uma chave primária havendo colisões de chave primária duplicada, impedindo assim a identificação. Na documentação ainda tem uma seção chamada de Quando devo usar GridFS? está descrito que Para documentos em uma coleção MongoDB, você deve sempre usar GridFS para armazenar arquivos maiores que 16 MB. (Mongodb, 2013). Em algumas situações, o armazenamento de arquivos grandes pode ser mais eficiente no banco de dados MongoDB do que em um sistema de arquivos em nível de sistema, a tabela 10 exibe essas situações. Tabela - Situações onde o armazenamento de arquivos grandes pode ser mais eficiente no sitema e arquivos 31

O sistema de arquivos limita o número de arquivos em um diretório, você pode usar GridFS para armazenar arquivos como quanto necessário. Quando você quer manter seus arquivos e metadados automaticamente sincronizadas e implantado através de uma série de sistemas e instalações. Ao utilizer uma definição de répicas distribuidas o mongodb pode distribuir arquivos e seus metadados automaticamente para um número de instâncias mongodb. Quando você quiser acessar informações de partes de arquivos grandes sem ter que carregar arquivos inteiros na memória, você pode usar GridFS acessar seções de arquivos sem ler o arquivo inteiro na memória. Fonte:MongoDB Mas assim como existem situações onde ele não recomenda o uso do GriFS, como por exemplo Não use GridFS se você precisa atualizar o conteúdo de todo o arquivo atomicamente. (Mongosb, 2013) a alternative no caso de ter que atualizar todo conteúdo é Como alternativa, você pode armazenar várias versões de cada arquivo e especificar a versão atual do arquivo de metadados. Você pode atualizar o campo de metadados indica que "ultimo inserido" em uma atualização atômica após carregar a nova versão do arquivo e, posteriormente, remover versões anteriores, se necessário. (Monogo, 2013) A documentaçaõ ainda afirma que no caso de documentos menores que 16 megabytes que se seus arquivos são todos menores de 16 MB, tamanho limite do documento BSON, considere armazenar o arquivo manualmente em um único documento. Para isso poderá utilizar o tipo de dados BinData para armazenar os dados binários. (Mongodb, 2013) 3. Considerações finais Após a pesquisa, foi possível traçar e observar que cada banco de dados armazena seus arquivos de forma peculiar, onde diferentes tipos de registro de 32

banco permitem inserir diferentes quantidades de registo, assim sendo, foi possível criar uma projeção do armazenamento de dados nos bancos que acrescentam bytes de controle na inserção de arquivos utilizando o tamanho máximo de cada tipo de armazenamento de dados. A seguir iremos discorrer sobre como cada banco se comporta. 3.1. MySql No caso do MySql, a quantidade de dados adicionados aos registros particionados e armazenados no tamanho máximo permitido no registro, faz com que a adição dos dados chegue a 0,039% Já que existem quatro tipos de armazenamento binários e quatro tipos de dados caracteres. Tabela - Arquivo único até 1 Megabyte até 10 Megabytes até 100 Megabytes até 1 Gigabyte até 10 Gigabytes TINYBLOB(256 - - - - - bytes) BLOB(512 Kilobytes) - - - - - MEDIUMBLOB(16 Megabytes) TA + 3 bytes TA + 3 bytes - - - LONGBLOB(4 Gigabytes) TA + 4 bytes TA + 4 bytes TA + 4 bytes TA + 4 bytes TA + 12 bytes Fonte: Desenvolvida pelo autor Tabela - Quantidade de partes do arquivo até 1 Megabyte até 10 Megabytes Quantidade de partes do arquivo até 100 Megabytes até 1 Gigabyte até 10 Gigabytes TINYBLOB(255 bytes) 4113 41121 411207 4210753 42107523 BLOB(511 Kilobytes) 17 161 1601 16385 163843 MEDIUMBLOB(15,99 Megabytes) 1 1 7 65 641 LONGBLOB(3,99 Gigabytes) 1 1 1 1 3 Fonte: Desenvolvida pelo autor Tabela - Quantidade de bytes adicionados aos registros 33 até 1 Megabyte Quantidade de Bytes adicionados até 10 até 100 até 1 Megabytes Megabytes Gigabyte até 10 Gigabytes Bytes 1048576 10485760 104857600 1073741824 10737418240 TINYBLOB(255 bytes) 1 4113 41121 411207 4210753 42107523 BLOB(511 Kilobytes) 2 34 322 3202 32770 327686

MEDIUMBLOB(15,99 Megabytes) 3 3 3 21 195 1923 LONGBLOB(3,99 Gigabytes) 4 4 4 4 4 12 Fonte: Desenvolvida pelo autor Tabela - Tamanho final dos arquivos até 1 Megabyte Tamanho arquivo com bytes adicionados em bytes até 10 até 100 até 1 Megabytes Megabytes Gigabyte até 10 Gigabytes Bytes 1048576 10485760 104857600 1073741824 10737418240 TINYBLOB(255 bytes) 1 1052689 10526881 105268807 1077952577 10779525763 BLOB(511 Kilobytes) 2 1048610 10486082 104860802 1073774594 10737745926 MEDIUMBLOB(15,99 Megabytes) 3 1048579 10485763 104857621 1073742019 10737420163 LONGBLOB(3,99 Gigabytes) 4 1048580 10485764 104857604 1073741828 10737418252 Fonte: Desenvolvida pelo autor Tabela - Tamanho do arquivo com bytes adicionados TINYBLOB(255 bytes) BLOB(511 Kilobytes) MEDIUMBLOB(15,99 Megabytes) LONGBLOB(3,99 Gigabytes) até 1 Megabyte 1,00 Megabytes Tamanho arquivo com bytes adicionados até 10 até 100 até 1 Megabytes Megabytes Gigabyte 10,00 Megabytes 100,00 Megabytes 1,00 Gigabytes até 10 Gigabytes 1048576 10485760 104857600 1073741824 10737418240 1,00 10,03 100,39 1,00 10,03 Megabytes Megabytes Megabytes Gigabaytes Gigabytes 10,00 Gibaytes 1,00 Megabytes 1,00 Megabytes 10,00 Megabytes 100,00 Megabytes 10,00 100,00 Megabytes Megabytes Fonte: Desenvolvida pelo autor 1,00 Gigabytes 1,00 Gigabytes 10,00 Gibaytes 10,00 Gibaytes 3.1.1. Postgres No banco de dados posgtres não fica claro a forma com a quale le insere os bytes de controle, especificando apenas que que são inseridos de 1 a 4 bytes de controle. Assim sendo foi possível estabelecer o cenário de melhor e pior caso de adição de bytes de controle onde mais uma vez os bytes de controle adicionados chegam a menos de 1% do tamanho final do arquivo, a seguir será exibida uma tabela com a projeção dos dados para um único arquivo inserido e para um arquivo inserido em partes. 34

Tabela - Arquivo inteiro Arquivo inteiro até 1 Megabyte até 10 Megabytes até 100 Megabytes até 1 Gigabyte até 10 Gigabytes Bytea melhor caso 4 Bytes 4bytes 4bytes 4bytes - Bytea pior caso 1 byte 1 byte 1 byte 1 byte - Fonte: Desenvolvida pelo autor Tabela - Arquivo em partes Arquivo em partes até 1 Megabyte até 10 Megabytes até 100 Megabytes até 1 Gigabyte até 10 Gigabytes Bytea melhor caso 4 bytes 4 bytes 4 bytes 4 bytes 40 bytes Bytea pior caso 1 byte 1 byte 1 byte 1 byte 10 bytes Fonte: Desenvolvida pelo autor 3.1.2. Oracle No caso do oracle 11g não a indicação de bytes que são adicionados nos registro, assim como o tipo BLOB, CLOB, NCLOB que possuem um tamanho limite de 128 terabytes podendo adicionar registros inteiros até o limite do tipo BLOB, CLOB ou NCLOB. 3.1.3. Mongodb No mongodb os arquivos são inseridos por meio da biblioteca BSON no tipo BinData no caso de arquivos menores de 16 megabytes, em arquivos superiores a 16 megabtyes é recomendável utilizar o GridFS para o armazenamento de dados acima de 16 megabytes. O GridFS realiza a divisão do arquivo inserido em blocos de 256 kilobytes, perminto que um documento seja acessado em seções expecíficas, como por exempo minutos específicos de um vídeo ou mesmo de uma música sem ter carregado o arquivo como um todo. 35

4.Resultados Após a leitura da documentação foram elaborados pequenos testes de gravação em sistema de arquivo e no banco de dados mongodb, esses teste mostrou que a implementação da inserção de arquivo em base de dados pode ser feita de forma simples e eficiente, assim como a utilização de banco de dados NoSql. No caso do mongodb a inicialização do banco foi realizada de forma fácil pelo console de comando, onde o usuário acessava a pasta bin dentro da pasta do mongodb e digitando o comando mongod.exe dbpath <caminho da pasta de armazenamento>. Logo após inicializar o banco O Exemplo desta facilidade de inserção de arquivos na base de dados pode ser observada na figura 2 que mostra o algoritmo de inserção de arquivos no mongodb utilizando o GridFS. Figura - Código de inserção no mongodb 36

Antes de realizar a primeira inserção foi observado que a pasta do mongodb onde era apontada na inicialização estava apenas com arquivos de controle, como pode ser observado na figura 3. Figura - Pasta inicial da base mongodb Nos testes iniciais foram feitos uploads de um arquivo de 69 megabytes para teste e foi possível observar na pasta do mongo que foram criados arquivos de armazenamento e controle dos dados, o upload do mesmo arquivo foi feito onze vezes para observar o comportamento do mongo com o mesmo aquivo e foi observado que o mongodb alocou muito mais espaço que o conjunto de dados enviados, como pode ser observado na figura 4. Figura - Pasta da base mongodb após armazenar 11 arquivos de 69 megabytes Após subir o mesmo arquivo 11 vezes foi realizada uma busca no banco de dados mongodb para verificar como esses dados estavam armazenados e o tamanho ocupado pelo banco de dados mongodb, essa consulta pode ser observada na figura 5 e 6. Essa consulta foi feita no console do mongodb utilizando 37

o comando db.nomedacolecao.find(), onde esse comando retorna todos os dados armazenados na coleção estabelecida, já para observar o tamanho da base de dados mongodb foi utilizado o comando show dbs. Figura - Busca na base de dados mongodb Figura - Tamanho do bado de dados após gravar 11 arquivos de 69 megabytes Após observado o comportamento do mongodb no armazenamento de arquivos, foi efetuado o teste de armazenamento de um arquivo de 192 kb, para observar o tamanho que o arquivo de armazenamento aloca inicial para o sistema. 38

Essa nova coleção alocou um espaço inicial com dois arquivos, sendo um de 64 megabytes e outro de 128 megabytes, mostrando que armazenamento do mongodb com GridFS aloca um espaço inicial de 192 megabytes. Esse comportamento pode ser observado na figura 7. Figura - Pasta da base mongodb após upload de arquivo de 192 kilobytes na coleção ArquivoAteUmMega Após as inserções no banco de dados mongodb foram realizados testes de obtenção do arquivo por meio do GridFS utilizando o comando fs.findone(nomedoarquivo), onde o arquivo foi recuperado e gravado na pasta temporária do sistema operacional, além de recuperar o arquivo o mongodb inseriu um número randômico no nome do arquivo recuperado como pode ser obervado na figura 8. Figura - Pasta temporária onde foram gravados os arquivos recuperados do mongodb 39

Os mesmo testes foram realizados gravando os dados em sistema de arquivos, conforme a figura 9 e 10 mostra, os arquivos que foram feitos uploads foram gravados em uma pasta especificada no código. Mas diferente do banco de dados todas as versões que foram enviadas para o servidor foram sobrescritas pela última versão, restando apenas um arquivo. Figura - Pasta de gravação em sistema de aquios depois de 11 uploads de do mesmo aquivo de 69 megabytes Figura - Pasta de gravação em sistema de arquivos depois de 11 uploads do mesmo aquivo de 69 megabytes e 1 upload de um arquivo de 192 Kilobytes 40

Conclui-se que no caso de gravações em sistema de arquivo deve ser feito uma estratégia de gravação de arquivos em pastas diferentes ou com nomes diferente sujeridos pelo sistema onde está sendo feito o upload, na figura 11 é possível observar a comparação de como ficou a partas de arquivos gravados em sistema de arquivos e no banco mongodb. Figura - Arquivos gravados em sistema de arquivos e arquivos gravados no mongodb Além dos testes demostrados acima, foram realizados testes com outros arquivos, na tabela 18 é possível observar os tempos de subida dos arquivos e gravação em sistema de arquivos. Já na tabela 19 é possível observar os tempos do armazenamento dos arquivos em banco de dados Tabela - Gravação de dados em sistema de arquivos 41