veja o trabalho

UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE SISTEMAS DE INFORMAÇÃO
SimpleSQL: Uma Camada Relacional sobre o SimpleDB
Aluno: André Luiz Calil Roslindo
Orientador: Ronaldo dos Santos Mello
Florianópolis, SC
Maio de 2012
SUMÁRIO
LISTA DE TABELAS ........................................................................................................................................... 4
LISTA DE FIGURAS ........................................................................................................................................... 5
LISTA DE COMANDOS ...................................................................................................................................... 6
LISTA DE REDUÇÕES ....................................................................................................................................... 7
RESUMO ............................................................................................................................................................... 8
ABSTRACT ........................................................................................................................................................... 9
1
INTRODUÇÃO .......................................................................................................................................... 10
1.1
VISÃO GERAL .......................................................................................................................................... 10
1.2
OBJETIVOS ............................................................................................................................................... 12
1.2.1
Geral .............................................................................................................................................. 12
1.2.2
Específicos ..................................................................................................................................... 12
1.3
METODOLOGIA ........................................................................................................................................ 12
1.4
ESTRUTURA DO TRABALHO ..................................................................................................................... 13
2
COMPUTAÇÃO NAS NUVENS .............................................................................................................. 15
3
BANCOS DE DADOS EM NUVEM ........................................................................................................ 17
4
3.1
NOSQL .................................................................................................................................................... 19
3.2
AMAZON SIMPLEDB ................................................................................................................................ 20
SIMPLESQL .............................................................................................................................................. 25
4.1
PRÉ-REQUISITOS ...................................................................................................................................... 27
4.2
INTERFACE ............................................................................................................................................... 28
4.3
DECOMPOSIÇÃO DO COMANDO ................................................................................................................ 29
4.4
EXECUÇÃO E RETORNO ............................................................................................................................ 31
4.4.1
INSERT .......................................................................................................................................... 31
4.4.2
UPDATE e DELETE ..................................................................................................................... 32
4.4.3
SELECT ......................................................................................................................................... 32
2
5
AVALIAÇÃO EXPERIMENTAL ........................................................................................................... 34
5.1
CARGA ..................................................................................................................................................... 36
5.2
SELEÇÃO .................................................................................................................................................. 37
6
TRABALHOS RELACIONADOS ........................................................................................................... 42
7
CONCLUSÃO ............................................................................................................................................ 44
7.1
TRABALHOS FUTUROS .............................................................................................................................. 45
3
LISTA DE TABELAS
TABELA 1: REQUISITOS DE BANCOS DE DADOS NAS NUVENS [20]. ......................................................................... 18
TABELA 2: EQUIVALÊNCIA ENTRE CONCEITOS RELACIONAIS E O MODELO DO SIMPLEDB...................................... 26
TABELA 3: ATRIBUTOS GERADOS NO SIMPLESQL A PARTIR DO COMANDO 2. ....................................................... 27
TABELA 4: COMANDOS DML SUPORTADOS E SUAS EXPRESSÕES REGULARES........................................................ 30
TABELA 5: RESULTADO DAS OPERAÇÕES DE CARGA. ............................................................................................. 36
TABELA 6: CONSULTAS SIMPLES PARA AVALIAÇÃO. .............................................................................................. 38
TABELA 8: CONSULTA COMPLEXA NA FORMA ORIGINAL E NA SINTAXE DO SIMPLEDB .......................................... 40
TABELA 9: DURAÇÃO MÉDIA DA EXECUÇÃO DE CADA ETAPA DO PROCESSAMENTO DE UMA CONSULTA COMPLEXA
..................................................................................................................................................................... 41
4
LISTA DE FIGURAS
FIGURA 1: MODELO DE DADOS DO SIMPLEDB [5]. ................................................................................................. 21
FIGURA 2: ARQUITETURA DO SIMPLESQL. ............................................................................................................ 25
FIGURA 3: PERSISTÊNCIA NO MODELO DO SIMPLESQL. ......................................................................................... 27
FIGURA 3: DIAGRAMA DE CLASSES DO DOMÍNIO DO SIMPLESQL. .......................................................................... 31
FIGURA 4: ESQUEMA RELACIONAL USADO NOS EXPERIMENTOS. ............................................................................ 35
FIGURA 5: GRÁFICO COMPARATIVO PARA A MÉDIA DE TUPLAS CARREGADAS POR MINUTO. .................................. 37
5
LISTA DE COMANDOS
COMANDO 1:EXEMPLO DE UM COMANDO DE CRIAÇÃO DE ITEM NA API REST DO SIMPLEDB ATRAVÉS DE GET. 24
COMANDO 2: EXEMPLO DE UM COMANDO GENÉRICO DE INSERÇÃO. ...................................................................... 26
6
LISTA DE REDUÇÕES
SGBD
Sistema de Gerenciamento de Bancos de Dados
SQL
Structured Query Language
XML
Extended Markup Language
7
RESUMO
Este trabalho apresenta os principais conceitos de bancos de dados NoSQL,
seu vínculo com sistemas distribuídos e características de utilização. Estes conceitos
fundamentam o desenvolvimento do SimpleSQL, uma camada de acesso relacional
ao SimpleDB, um banco de dados NoSQL orientado a documentos e também
abordado no trabalho. O SimpleSQL provê uma interface SQL simplificada,
abstraindo qualquer conhecimento a respeito do método de acesso ao SimpleDB,
persistência de dados na nuvem e seu modelo de representação .
A avaliação experimental apresentada sustenta a viabilidade da camada e sua
evolução é sugerida nos trabalhos futuros.
Palavras chave: banco de dados em nuvem, NoSQL, SimpleDB, SimpleSQL.
8
ABSTRACT
This work presents the key concepts of NoSQL databases, its distributed
system characteristics and the scenarios for its application. This research serves as
basis for the development of SimpleSQL, a relational layer for accessing SimpleDB, a
NoSQL document database available at the cloud. SimpleSQL offers a simplified
SQL interface, covering any knowledge about the access layer to SimpleDB, data
persistence in the cloud and its data modeling.
Experimental evaluation shows the feasibility of our layer, and its evolution is
discussed in terms of future work.
9
1
INTRODUÇÃO
1.1
Visão Geral
O conceito de software as a service transformou-se de paradigma inovador a
modelo de negócio durante os últimos anos. Enquanto o modelo de software
licenciado e mantido pela companhia representava um alto custo em termos de
aquisição e manutenção, software mantido pelo provedor do serviço e faturado de
acordo com o uso (modelo pay as you go) [3], com garantias contratuais de
disponibilidade e privacidade, passou a se tornar atrativos e populares [7]. Este
paradigma se insere no que se denomina computação nas nuvens (cloud
computing), onde os serviços utilizados, como software e infraestrutura, são
remotos.
Seguindo esse paradigma, soluções de armazenamento e gerenciamento de
dados também passaram a ser oferecidos como serviço [14]. Este movimento
modificou a arquitetura dos sistemas gerenciadores de bancos de dados para
atribuir-lhes características de sistemas distribuídos, como alta disponibilidade e
tolerância a falhas. Neste processo, surgiram SGBDs com modelos de dados
divergentes do modelo relacional clássico [1]. Esses modelos são compatíveis com
os paradigmas de programação e aplicações web correntes, que lidam com alto
volume de dados e transações, mais orientados a objetos do que a relações.
Exemplos desses novos modelos são coleções chave-valor, documento ou
super-coluna [15]. Bancos de dados baseados nesses modelos são conhecidos
como NoSQL [19]. A principal diferença entre estes sistemas e SGBDs relacionais
está no aprimoramento à disponibilidade de dados em detrimento da consistência
[8], além do modelo de dados propriamente dito.
10
Bancos de dados NoSQL, que são intimamente relacionados com conceitos
de cloud computing, possuem também um forte relacionamento com as plataformas
atuais de desenvolvimento de sistemas. A modelagem da solução segundo um
paradigma orientado a objetos é mais facilmente persistida em um modelo de dados
NoSQL e sua interface de acesso simplificada, geralmente desenvolvida sobre
HTTP. Tal fato possibilita a sua utilização com menos esforço.
Como esses novos bancos de dados não são relacionais, não há suporte ao
padrão SQL, o que dificulta a migração e adoção de aplicações baseadas no modelo
relacional de representação e acesso aos dados. Para atender esta demanda, este
trabalho apresenta uma camada relacional, chamada SimpleSQL, para acesso ao
SimpleDB [4], solução NoSQL da Amazon para gerenciamento de dados na nuvem.
A escolha do SimpleDB foi motivada pela sua popularidade entre as ferramentas
NoSQL do mercado e pela sua simplicidade de configuração e uso. SimpleSQL
suporta uma versão restrita do SQL ISO/IEC, que permite inserção, atualização,
remoção e consulta aos dados. Ao utilizar o SimpleSQL, a aplicação cliente fica
isolada da interface de acesso ao SimpleDB, das suas operações e modelo de
dados, tendo, desta forma, uma interface relacional para acesso a dados na nuvem.
Além da transparência para manipulação e armazenamento dos dados, o
SimpleSQL suporta consultas com junções, recurso indisponível no SimpleDB e
raramente encontrado em soluções NoSQL. A camada é capaz de decompor uma
consulta que relaciona diversas tabelas com junções em um conjunto de consultas
individuais, para cada tabela relacionada, e combinar os dados obtidos para gerar
uma única tabela de retorno no formato desejado e com os parâmetros de junção
definidos.
11
1.2
Objetivos
1.2.1 Geral
Desenvolver uma camada de software para acesso relacional ao sistema
Amazon SimpleDB, abstraindo da aplicação cliente conhecimento sobre o modelo de
dados não relacional, interface de acesso e manipulação de dados.
1.2.2 Específicos
 Oferecer uma interface relacional, suportando uma versão simplificada do
SQL ISO/IEC, para acesso ao Amazon SimpleDB;
 Realizar experimentos que comprovem a viabilidade de utilização desta
camada relacional;
 Transformar resultados primitivos, com um conjunto de objetos não
relacionais, em uma tabela relacional no esquema definido pelo cliente;
 Prover um vínculo entre o modelo relacional de manipulação de dados e
bancos de dados NoSQL.
1.3
Metodologia
Para atender aos objetivos expostos, este trabalho segue as etapas abaixo
elencadas:
 Estudo sobre cloud computing e NoSQL;
 Estudo detalhado sobre o funcionamento e operação do Amazon
SimpleDB;
 Implementação do SimpleSQL;
12
 Apresentação de avaliações experimentais.
Na primeira etapa, é apresentado um breve histórico e os conceitos
atualmente aceitos sobre recursos computacionais oferecidos no modelo de serviço
e o surgimento de novos bancos de dados não relacionais.
A segunda etapa consiste em uma pesquisa sobre o repositório escolhido
para o trabalho, apresentando sua forma de operação, funcionamento e conceitos
necessários para seu entendimento.
A terceira etapa refere-se à implementação da ferramenta, que consiste na
decomposição de instruções SQL em um modelo genérico e sua tradução para a
interface do SimpleDB, tratamento dos dados e retorno.
Na quarta etapa são apresentadas as avaliações experimentais executadas
sobre o SimpleSQL, atestando seu funcionamento e desempenho.
1.4
Estrutura do Trabalho
Este trabalho está dividido da seguinte forma:
 Capítulo 1: Introdução – Apresentação geral do trabalho, com breve
contextualização sobre as tecnologias envolvidas, exploração do problema
chave e a solução proposta;
 Capítulo 2: Computação nas nuvens – Apresentação dos conceitos,
histórico e visão atual da computação nas nuvens;
 Capítulo 3: Bancos de dados nas nuvens – Motivação e problemática de
bancos de dados publicados na nuvem, apresentação das definições
existentes para bancos de dados NoSQL, classificações das principais
ferramentas e detalhamento sobre o Amazon SimpleDB;
13
 Capítulo 4: SimpleSQL – Explicação da ferramenta desenvolvida, com
detalhamento
sobre
o
funcionamento,
implementação
e
conceitos
utilizados;
 Capítulo 5: Avaliação experimental – Apresentação das baterias de
experimentos realizados com a ferramenta, com avaliação do desempenho
e comparações;
 Capítulo 6: Trabalhos Relacionados – Análise de alguns trabalhos com
temas correlatos;
 Capítulo 7: Conclusões – Este capítulo apresenta as conclusões extraídas
da pesquisa e desenvolvimento do SimpleSQL, bem como uma análise
sobre restrições de escopo e limitações do SimpleSQL, abrindo
possibilidades para trabalhos futuros.
14
2
COMPUTAÇÃO NAS NUVENS
Sendo um dos principais paradigmas de computação nos dias de hoje [15], a
computação nas nuvens representa o modelo de utilização de recursos
computacionais em que o usuário, abstraído de toda a complexidade de instalação,
manutenção e infraestrutura, possui acesso a um determinado recurso através de
uma simples interface. Por isolar o usuário de todas as questões internas do recurso
em questão e prover apenas uma interface externa para consumo, entende-se que
computação nas nuvens segue também o paradigma as a service.
Os recursos oferecidos podem ser de diferentes naturezas, que compõem os
modelos de serviços que podem ser encontrados [16]:
 Software as a Service (SaaS): softwares para fins específicos,
disponibilizados para o usuário final através de uma interface amigável,
geralmente Web. Serviços de webmail, como Gmail e Hotmail, são
exemplos deste modelo;
 Plataform as a Sevice (PaaS): sistemas operacionais, linguagens de
programação e ambientes de desenvolvimento e publicação de
aplicações. Assim como no modelo anterior, a infraestrutura subjacente
não é controlada pelo usuário. Google App Engine e Microsoft Azure
podem ser citados como PaaS;
 Infrastructure as a Service (IaaS): recursos computacionais de baixo
nível de abstração, como armazenamento, ativos de rede e poder de
processamento. Um exemplo deste modelo é o Amazon EC2.
15
É importante destacar que a nuvem não necessariamente refere-se à Internet.
Há diferentes modelos de implantação, quem podem variar entre nuvens públicas,
privadas ou híbridas [15].
Ainda assim, recursos no modelo de computação nas nuvens são sempre
alcançados através de uma rede de computadores. Desta forma, características
essenciais como alta disponibilidade e elasticidade [15] trazem para a computação
nas nuvens conceitos fundamentais de sistemas distribuídos [9].
Em termos comerciais, a computação nas nuvens proporcionou que a
cobrança fosse feita de acordo com o uso (pay as you go) [15], conveniência já
observada em outros serviços do cotidiano.
Considerando este paradigma de computação nas nuvens, o próximo capítulo
concentra-se em apresentar os novos desafios para bancos de dados neste
paradigma.
16
3
BANCOS DE DADOS EM NUVEM
A oferta de bancos de dados em nuvem possui várias vantagens para os
usuários, dentre elas:
 Previsibilidade e custos mais baixos, proporcional à qualidade do
serviço e cargas de trabalho reais;
 Complexidade técnica reduzida, graças a interfaces de acesso
unificado e a delegação de tuning e administração dos sistemas;
 Elasticidade e escalabilidade, proporcionando a percepção de recursos
quase infinitos.
Diversos sistemas e arquiteturas estão sendo desenvolvidos para suprir as
novas demandas de aplicações com diferentes requisitos de processamento e
armazenamento [2]. Estes novos sistemas tentam fornecer uma visão de
armazenamento e escalabilidade infinitos, mas tem que tratar o problema de
provisionar recursos. Este problema, que em SGBDs tradicionais consiste em
determinar quais recursos são alocados para um único banco de dados, no ambiente
em nuvem torna-se um problema de otimização, onde se tem uma grande
quantidade de usuários, múltiplos repositórios em nuvem e grandes centros de
dados. Isso fornece uma oportunidade sem precedentes para explorar a economia
em escala, balanceamento dinâmico de carga e gerenciamento de energia.
Esse aumento no número de abordagens disponíveis de repositórios em
nuvem [2] agrava o problema da escolha, implantação e soluções de administração
para a gestão de dados.
17
Com isso, os bancos de dados em nuvem estão sendo disponibilizados como
serviços, que encapsulam a complexidade do gerenciamento por meio de formas de
acesso simples e garantias de acordos de nível de serviço (SLAs).
A Tabela 1 apresenta os requisitos de um banco de dados oferecido como
serviço, sob as perspectivas do usuário, do provedor e da nuvem subjacente [20].
Estes parâmetros reforçam o diferente contexto em que os bancos de dados na
nuvem estão incluídos.
Tabela 1: Requisitos de bancos de dados nas nuvens [20].
Requisitos de usuário
API simples com pouca configuração e administração
Alto desempenho
Alta disponibilidade e confiança
Acesso fácil a características avançadas
Requisitos do Provedor
Atender o SLA do usuário
Limitar hardware e custo de energia
Limitar custo de administração
Requisitos extra de Nuvem Pública
Esquema de preço: barato, previsível e proporcional ao uso
Garantias de segurança e privacidade
Baixa latência
18
3.1
NoSQL
Este novo cenário de implantação de um banco de dados e os requisitos
demandados pelo mercado impulsionaram a criação de novas soluções de
armazenamento de dados. Como um dos principais objetivos era otimizar a
distribuição dos dados em diferentes máquinas [21], as ferramentas que surgiram
não seguiram o modelo relacional.
Esta tendência vem sendo chamada de NoSQL. Muito embora haja
discordância se o nome significa Not Only SQL [8] ou No SQL [19], concorda-se em
algumas características apresentadas nesta nova abordagem:
 Suporte à escalabilidade horizontal [8], isto é, aumento na capacidade
de processamento através da inclusão de novas máquinas à grade;
 Replicação e particionamento de dados entre diferentes servidores;
 Interface de acesso simples e com alto nível de abstração;
 Liberdade de esquema.
Nota-se, mais uma vez, similaridade com sistemas distribuídos. Para suportar
tais características e atender aos requisitos esperados do serviço, bancos de dados
NoSQL possuem menor controle transacional em termos de concorrência, como
proposto no teorema CAP (Consistency, Availability, and Partition-tolerance) [12], que
afirma que sistemas distribuídos, para que possam assegurar os benefícios do seu
modelo, devem escolher apenas duas características entre consistência, alta
disponibilidade e tolerância a falhas.
Neste
sentido,
as
características
ACID
(Atomicidade,
Consistência,
Isolamento e Durabilidade) dos bancos de dados relacionais são substituídas pelo
19
acrônimo BASE (Basically Available, Soft state, Eventually consistent) [8] [13],
destacando a disponibilidade em detrimento à consistência.
Em termos de modelo de dados, bancos de dados NoSQL são basicamente
agrupados em três categorias [8][19]:
 Chave-valor: sistemas de persistência baseados em pares chave-valor.
Esta estrutura oferece apenas um índice para acesso a dados, através
da sua chave. As interfaces de acesso costumam ter apenas os
métodos de inserção, remoção e consulta pelo índice. Em ambientes
distribuídos, é comum encontrar a denominação DHT (distributed
hashtable, tabela de espalhamento distribuída);
 Documento: persistência do objeto em um documento, que não deve
ser confundido com um arquivo em um sistema de arquivos. Estes
bancos
geralmente
suportam
múltiplos
índices
e
documentos
(estruturas) aninhados;
 Super coluna (wide column): também conhecido por família de colunas,
é uma persistência em tabela que suporta particionamento horizontal e
vertical. O particionamento respeita as chaves primárias, quando
horizontal, ou “grupo” de colunas, quando vertical, de forma a deixar
dados relacionados entre si em um mesmo nó.
Na próxima seção são apresentados detalhes do Amazon SimpleDB, um
banco de dados NoSQL que segue o modelo de documento [8].
3.2
Amazon SimpleDB
SimpleDB é um dos serviços que compõe o Amazon Web Services, uma suíte
da Amazon com ferramentas para diferentes aplicações, todas oferecidas na nuvem
20
na forma de serviços. O SimpleDB é um banco de dados NoSQL de rápida
contratação e configuração. Sendo oferecido exclusivamente como um serviço, não
há opção de licenciar para uso interno em uma corporação ou afins.
Durante a configuração do sistema, o usuário deve escolher uma região
geográfica onde seus dados serão mantidos. As opções são EUA (Virgína, Oregon
ou Norte da Califórnia), Irlanda, Cingapura, Tóquio e São Paulo. Esta seleção é
importante para manter os dados próximos da região de maior acesso e para
respeitar legislações locais quanto a armazenamento de dados. Há também variação
no preço do serviço entre as diferentes regiões.
Dentro da região selecionada há um conjunto de data centers onde os dados
serão
replicados.
Informações
detalhadas
sobre
esta
operação
não
são
disponibilizadas ao usuário, mas a Amazon garante que, em uma operação de
escrita, todas as cópias do dado são atualizadas [4].
O modelo de dados do SimpleDB é composto de domínios, itens, atributos e
valores, conforme apresentado na Figura 1.
Figura 1: Modelo de dados do SimpleDB [5].
Um domínio possui um nome e uma coleção de itens. Um item, por sua vez,
possui uma identificação única e um conjunto de atributos, que são pares chavevalor.
21
O domínio é a unidade de replicação e alocação de recursos. Um usuário
pode ter até 250 domínios, com no máximo 10 Gb de dados cada um. A distribuição
de dados entre domínios, conforme decisão do usuário, deve ser cuidadosamente
selecionada. Como o SimpleDB não suporta operações entre domínios, deve ficar a
cargo da aplicação cliente a junção dos dados. Da mesma forma, caso seja
necessário processar um item para decidir em qual domínio inseri-lo, o desempenho
da aplicação poderá ser comprometida.
Assim como ocorre com os domínios, o nome de um item deve identificá-lo
exclusivamente. Um atributo é um par chave-valor, e o SimpleDB suporta múltiplos
valores para uma mesma chave e não há limites para a quantidade de atributos que
um item pode possuir. Também não há restrição quando ao número de atributos dos
itens de um mesmo domínio. Seguindo a liberdade de esquema, itens em um
mesmo domínio podem ter atributos completamente diferentes entre si.
Como vimos, em termos de consistência o SimpleDB garante que uma
operação de escrita atualiza todas as cópias do item em questão, muito embora não
imediatamente após a conclusão do comando. Para leituras, entretanto, não há esta
garantia. Há duas opções de consistência para as operações de leitura: leituras
coerentes e leituras eventualmente coerentes [4]. A primeira opção aguarda a
finalização de qualquer operação de escrita nos itens em questão e os bloqueia
durante sua execução, garantindo que o valor retornado é o último valor atualizado.
Consequentemente, operações de leitura com esta configuração apresentam um
tempo de resposta maior e também podem impactar em outras operações sobre os
mesmos dados. A segunda opção, que é o comportamento padrão, retorna o valor
do nó que estiver mais disponível. Desta forma, pode não refletir uma última escrita
que, eventualmente, ainda não tenha sido replicada.
22
A interface de acesso ao SimpleDB é implementada em uma API REST [10].
Como é baseada em requisições HTTP, a maior parte das plataformas de
desenvolvimento possuem a capacidade de utilizá-la. Todas as operações de escrita,
leitura e até mesmo administração de domínios são realizadas por requisições HTTP
GET e POST. Ambos os verbos são suportados para todos os comandos da API,
mas o cliente deverá utilizar POST caso os atributos excedam o limite máximo de
parâmetros suportados em um GET.
Tanto a operação sendo executada quanto seus parâmetros são enviados
através da requisição HTTP. O Comando 1 ilustra uma operação PutAttributes, que é
utilizada na criação de um item (caso o nome não exista) ou para atualizar seu
conjunto de atributos.
Há de ser destacado que o nome da operação, PutAttributes, é determinado
pela API da Amazon, devidamente documentada pela companhia. Cada operação
suportada pela API possui uma ação (Action, no comando), e todos parâmetros da
operação são enviados através da requisição HTTP (POST ou GET, a critério do
cliente).
23
GET https://sdb.amazonaws.com/?Action=PutAttributes
&DomainName=dominio
&ItemName=nomeDoItem
&Attribute.1.Name=quantidade&Attribute.1.Value=20
&Attribute.2.Name=categoria&Attribute.2.Value=alimento
&AWSAccessKeyId=accessKey
&Version=2009-04-15
&Signature=assinatura
&SignatureVersion=2
&SignatureMethod=HmacSHA256
&Timestamp=2010-01-25T15%3A01%3A28-07%3A00 HTTP/1.1
Comando 1:Exemplo de um comando de criação de item na API REST do SimpleDB
através de GET.
Um comando PutAttributes é utilizado tanto para as operações SQL INSERT e
UPDATE. No exemplo, está sendo criado um item com dois atributos (quantidade e
categoria) e dois valores (20 e alimento, respectivamente).
24
4
SIMPLESQL
O SimpleSQL foi proposto neste trabalho para solucionar as barreiras de
adoção de um banco de dados NoSQL, tanto em termos de adaptação de sistemas
legados quanto de capacitação de profissionais. Como não há padrão de interface
de acesso entre os sistemas NoSQL, o SimpleSQL, na sua versão atual, suporta
unicamente o Amazon SimpleDB.
Desenvolvido como uma biblioteca de classes, o SimpleSQL serve como a
única camada de comunicação necessária entre a aplicação cliente e o SimpleDB.
Ele recebe instruções SQL em formato texto e trata da sua interpretação,
manipulação e execução no SimpleDB. Para consultas, o resultado é transformado
em uma tabela, construída com as colunas esperadas como resultado da consulta.
SimpleSQL foi
desenvolvido
utilizando
a
plataforma
Microsoft
.NET
Framework 3.5 e a linguagem de programação C# 3.0. Sua arquitetura é
apresentada na Figura 2, que ilustra as três etapas do processamento de um
comando, detalhadas nas seções a seguir.
Comandos
Interface de
acesso
Decomposição
Processamento
e retorno
Respostas tabulares
Figura 2: Arquitetura do SimpleSQL.
25
REST
Para que seja viável a tradução de comandos SQL em comandos SimpleDB,
utilizou-se o relacionamento entre conceitos dos modelos relacional e de documento
do SimpleDB apresentados na Tabela 1.
Tabela 2: Equivalência entre conceitos relacionais e o modelo do SimpleDB.
Relacional
Esquema
Tabela
Tupla
Atributo
Valor
Chave primária
SimpleDB
Domínio
Item
Chave de atributo
Valor de atributo
Nome do item
Muito embora o esquema e o domínio sejam conceitos equivalentes, o
SimpleSQL não suporta o nome do esquema como qualificador de uma tabela. Vale
observar que o SimpleDB não possui um conceito equivalente à tabela do modelo
relacional, que determina um tipo de objeto. Para contornar esta característica e
sustentar a execução dos comandos, o SimpleSQL persiste o nome da tabela como
um atributo do item.
Para ilustrar o processo de criação de um item, considere o Comando 2,
genérico para uma operação de inserção de dados a seguir.
INSERT INTO tabela (coluna1, coluna2)
VALUES (valor1, valor2)
Comando 2: Exemplo de um comando genérico de inserção.
Após a submissão deste comando ao SimpleSQL, o mesmo identifica qual o
domínio responsável pelos objetos do tipo tabela e gera um item com a coleção de
atributos, conforme apresentado na Tabela 3.
26
Tabela 3: Atributos gerados no SimpleSQL a partir do Comando 2.
Chave
coluna1
coluna2
SimpleSQL_TableName
Valor
valor1
valor2
tabela
Depois de traduzido o INSERT para a API do SimpleDB e executado o
comando, a tupla ficaria disposta em um esquema similar ao apresentado no Figura
3, em uma notação ilustrativa. Destaca-se que o nome do domínio é identificado a
partir de uma configuração enviada pelo usuário ao SimpleSQL (discutida na
próxima seção) e que o nome exclusivo do item é gerado automaticamente pelo
SimpleSQL
dominio:
{
1234567890:
{
coluna1: valor1;
coluna2: valor2;
SimpleSQL_TableName: tabela;
}
}
Figura 3: Persistência no modelo do SimpleSQL.
4.1
Pré-requisitos
Para que seja capaz de conectar-se ao SimpleDB e identificar os domínios, o
SimpleSQL deve receber, quando da sua instanciação, as seguintes informações:
 Access Key: chave de acesso do usuário ao SimpleDB. Esta
informação pode ser encontrada no portal da Amazon, após
autenticação;
27
 Secret Access Key: chave de acesso secreta. Junto da access key,
formam o par de autenticação e autorização do usuário. Também é
encontrada no portal da Amazon;
 Distribuição de domínios: caso o usuário tenha mais de um domínio,
ele deverá prover ao SimpleSQL um dicionário que tenha como chave
o nome do domínio e como valor a lista de tabelas daquele domínio.
Caso seja apenas um (1) domínio, é informado apenas o seu nome,
simplificando o processo.
Como um requisito não funcional, o ambiente de execução do SimpleSQL
deve ter acesso ao website da Amazon.
4.2
Interface
A interface de acesso do SimpleSQL é composta por dois métodos:
ExecuteQuery, que retorna um objeto do tipo DataTable (estrutura tabular), e
ExecuteNonQuery, que retorna um texto (string). Ambos recebem um comando SQL,
em formato texto, como único parâmetro.
Como apresentado anteriormente, SimpleSQL suporta as quarto operações
tradicionais de manipulação de dados. Contudo, como uma restrição de escopo,
cada operação possui limitações quanto à sintaxe suportada nesta primeira versão:
 SELECT: suporta consultas sobre uma única tabela ou conjunto de
tabelas relacionadas através de INNER JOIN. Casa haja junções, todos
os atributos do comando (no retorno, nas junções e nos critérios)
devem estar no formato tabela.atributo;
28
 UPDATE: suporta atualização de múltiplos itens, mas sem subcomandos. Múltiplos critérios de filtro são suportados, mas ao menos
um deve ser informado;
 INSERT: suporta inserção de um item por comando, sem subcomandos ou instruções do tipo INSERT SELECT;
 DELETE: suporta remoção de múltiplos itens. Múltiplos critérios de filtro
são suportados, mas ao menos um deve ser informado.
4.3
Decomposição do comando
O primeiro passo do processamento é decompor o comando SQL,
convertendo-o em um objeto do domínio do SimpleSQL. Para esta operação, cada
tipo de comando suportado pelo SimpleSQL possui uma expressão regular que
possui duas finalidades: (i) validar a sintaxe do comando e (ii) extrair os elementos
determinantes do comando. Tabela 4 apresenta os comandos e suas expressões
regulares.
Os elementos extraídos do comando são utilizados para instanciar o objeto
referente ao tipo de comando submetido no domínio do SimpleSQL. Por exemplo,
para um comando do tipo SELECT, o SimpleSQL extrairia os atributos esperados, a
tabela destino, a lista de junções e o conjunto de critérios.
29
Tabela 4: Comandos DML suportados e suas expressões regulares.
Operação
INSERT
UPDATE
Expressão regular
^(?:\s*(?i:INSERT
INTO)\s+)(?<table>[^\(]+)(?:\(\s*)(?<attributes>(?:\w+\s*)(?:\,\s*\w+\s*)*)(?:\)\
s+)(?:(?i:VALUES)\s+\(\s*)(?<values>(?:[^\,]+|[^\)])+\s*(?:\,\s*[^\)])*)(?:\))$
^\s*(?i:UPDATE)\s+(?<table>\S+\s+)(?i:SET)\s+(?<attributes>(\s*\S+\s*)\=(\s
*\S+\s*)(,(\s*\S+\s*)\=(\s*\S+\s*))*)+(?<condition>((?i:where)|(?i:and)|(?i:or))(\
s+\w+\s*)(=|<|>|<=|>=|<>|(?i:in)|(?i:not
in))((\s*\(?)(\s*\w+\s*)(,\s*\w+\s*)*(\s*\)?)))*$
^(?:\s*(?i:DELETE
DELETE
FROM)\s+)(?<table>\S+\s+)(?<condition>(?:(?i:where)|(?i:and)|(?i:or))(?:\s+.
+\s*)(?:=|<|>|<=|>=|<>|(?i:in)|(?i:not
in))(?:(?:\s*\(?)(?:\s*.+\s*)(?:,\s*.+\s*)*(?:\s*\)?)))*$
^\s*(?i:SELECT)\s+(?<attributes>(\S+\s*)(,\s*\w+\s*)*)\s+(?i:FROM)\s+(?<tab
SELECT
le>\s*\S+\s*)\s+(?<join>(?i:inner
join)\s+(?<toTable>\s*\S+\s*)\s+(?i:on)\s+(?<fromKey>\s*\S+\s*)\s*=\s*(?<to
Key>\s*\S+\s*)\s+)*(?<condition>((?i:where)|(?i:and)|(?i:or))(\s+.+\s*)(=|<|>|<
=|>=|<>|(?i:in)|(?i:not in))((\s*\(?)(\s*.+\s*)(,\s*.+\s*)*(\s*\)?)))*$
É importante observar, na Tabela 4, o uso expressivo de grupos de captura
nomeados, denotados pela sintaxe (?<nome do grupo>expressão). Grupos de
captura nomeados são uma técnica de expressões regulares para pesquisa e
obtenção de partes de um texto sem a necessidade de buscar manualmente os
padrões esperados [11]. Com esta técnica, é possível obter facilmente cada
elemento do comando, como a tabela destino, a lista de atributos ou critérios de
filtro.
Em termos de implementação, o SimpleSQL trabalha com uma classe
abstrata chamada Command, que é especializada nas classes Insert e na classe
abstrata ConditionedCommand, que é herdada e implementada pelas classes
Update, Select e Delete. A Figura 3 apresenta o diagrama de classes do domínio do
SimpleSQL.
30
Figura 4: Diagrama de classes do domínio do SimpleSQL.
4.4
Execução e retorno
Uma vez instanciado o objeto de domínio correspondente à operação
submetida, o SimpleSQL irá traduzi-lo para uma chamada de método na interface
REST do SimpleDB. Todos os comandos iniciam com a identificação do domínio do
SimpleDB a partir da tabela destino, extraída do comando.
DELETE e UPDATE retornam a quantidade de itens afetados. INSERT
retorna o resultado da operação (sucesso ou falha) e SELECT retorna os dados
obtidos em uma estrutura de tabela, utilizando a classe DataTable, nativa do .Net. A
seguir são apresentados maiores detalhes sobre o processamento de cada
comando.
4.4.1 INSERT
Uma tupla corresponde a um item no modelo do SimpleDB. Portanto, um
comando INSERT gera um item.
No início do processamento deste comando, o SimpleSQL verifica se a
quantidade de atributos corresponde à quantidade de valores fornecidos. Além de
31
transformar os atributos do comando em uma coleção de atributos no modelo do
SimpleDB, o SimpleSQL adiciona o atributo SimpleSQL_TableName, para manter o
nome da tabela daquele item no esquema relacional. O nome do item é preenchido
com uma instância de um global unique identifier (GUID) [14].
4.4.2 UPDATE e DELETE
A lista de filtros na parte de condição destes comandos é executada no
formato de um SELECT simples (uma consulta sem junções) para recuperar os itens
a serem atualizados ou removidos.
No caso de um DELETE, cada item obtido é removido em uma operação
isolada. Caso seja um UPDATE, a coleção de atributos de cada item obtido é iterada
na busca do atributo com o nome informado na lista atributos a serem atualizados.
Caso ele exista (como há liberdade de esquema, itens de um mesmo tipo podem
não ter os mesmos atributos), seu valor é atualizado.
4.4.3 SELECT
Ao receber um comando de consulta, o SimpleSQL extrai os atributos
esperados, a tabela destino, as junções e os critérios de filtro. Em havendo junções,
o comando é dividido em consultas simples. Isso significa que, através da notação
tabela.atributo, o SimpleSQL é capaz de identificar todos os componentes do
comando referentes a cada tabela envolvida.
Depois de receber o retorno de cada consulta individual, é criado um objeto
do tipo DataTable com o esquema esperado no resultado do comando principal e as
listas de itens obtidas são combinadas usando os atributos determinados nas
junções, similar a chaves estrangeiras em um esquema relacional, preenchendo a
32
tabela de retorno com os registros resultantes. Recomenda-se que cada tabela
envolvida em uma consulta tenha ao menos um critério de filtro, para evitar que o
SimpleSQL carregue todos os itens daquele tipo ao executar as consultas
individuais.
Para cada consulta submetida ao SimpleDB, o SimpleSQL inclui o nome da
tabela, persistido no atributo SimpleSQL_TableName, como filtro. Com isso, o
SimpleSQL é capaz de distinguir itens de diferentes tipos (tabelas) que tenham
atributos de mesmo nome.
O resultado de consultas submetidas ao SimpleDB é um conjunto de itens. O
SimpleSQL itera em todos os atributos de todos os itens recebidos, de forma a
recuperar seus valores e satisfazer os critérios do comando. Na formação da tabela
de retorno, cada item representa um registro da tabela. Caso os itens obtidos não
contenham o mesmo esquema e ocorra de um item não possuir um dos atributos
esperados como retorno, o valor daquele atributo será definido como nulo (Null).
Outro aspecto do SimpleDB é que a resposta de qualquer comando é limitada
a 1MB, por questões de escalabilidade e desempenho. Isso significa que nem todos
os itens resultantes de uma consulta são enviados na primeira resposta. O resultado
completo é dividido, e o SimpleDB envia um atributo chamado NextToken, para que
a consulta possa ser novamente submetida e o próximo lote de resposta seja
retornado. O SimpleSQL identifica este controle e possui métodos recursivos para
obter o resultado completo.
Um exemplo de decomposição de uma consulta complexa com junções é
apresentado na próxima seção, bem como os resultados obtidos na avaliação
experimental ao qual o SimpleSQL foi submetido.
33
5
AVALIAÇÃO EXPERIMENTAL
Experimentos foram realizados com o intuito de avaliar o impacto no
desempenho com a inclusão do SimpleSQL como uma camada de acesso relacional
sobre o SimpleDB. Estes experimentos foram baseados em uma amostra de dados
relacionais referentes ao sistema de vestibular da UFSC. A amostra consiste em seis
tabelas que representam candidatos, suas opções de curso, seus resultados e a
qual evento (vestibular anual) eles estão associados.
A Figura 4 apresenta o
esquema relacional da amostra, que conta com mais de 500 mil tuplas no total.
Os experimentos foram processados no seguinte ambiente computacional:
 Notebook Dell Vostro 3550;
 Processador Intel Core i5-2430M;
 Memória RAM 6GB DDR3 1066mHz;
 Conexão de internet 10Mbps ADSL2.
No que diz respeito às configurações do SimpleDB, todos os dados foram
persistidos em um único domínio, localizado na região Leste dos EUA. A carga dos
dados ao SimpleDB fez parte dos experimentos, como apresentado nas próximas
seções. Infelizmente, não é possível obter com a Amazon a quantidade de
servidores envolvidos no processamento das consultas, uma vez que esta
transparência é parte das características de um sistema distribuído.
Foram avaliados o desempenho de duas operações: INSERT e SELECT. A
primeira foi escolhida para avaliar o tempo necessário para a carga de um grande
volume de dados. A operação de consulta foi escolhida para avaliar o
processamento para um conjunto de comandos com diferentes complexidades.
Demais operações não foram diretamente avaliadas porque são derivadas do
34
processamento de uma consulta e não agregariam valor na análise do desempenho
do SimpleSQL.
Para cada operação, foi comparado o tempo utilizando o SimpleSQL e o
tempo gasto apenas com a utilização da API .NET do SimpleDB [6]. Os resultados
são detalhados nas seções a seguir.
Figura 5: Esquema relacional usado nos experimentos.
35
5.1
Carga
Operações INSERT foram executadas para carregar dados de duas tabelas,
candidato e opcaoCandidato, apresentadas na Figura 4 (canto superior esquerdo e
direito). A Tabela 5 apresenta o tempo de processamento com o SimpleSQL e
apenas com o SimpleDB, bem como a média de tuplas inseridas por minuto.
Destaca-se o incremento na quantidade de tuplas de cada tabela, para averiguar o
comportamento em escalabilidade da camada.
Tabela 5: Resultado das operações de carga.
Média
Tabela
# tuplas
Modo
Duração
(tuplas/min)
SimpleSQL
03:29:24
238,78
SimpleDB
03:19:24
250,75
SimpleSQL
18:49:10
221,40
SimpleDB
18:41:45
222,87
SimpleSQL
37:32:08
222,01
SimpleDB
37:15:24
223,67
SimpleSQL
07:37:08
218,75
SimpleDB
07:07:32
233,90
SimpleSQL
38:12:16
218,12
SimpleDB
36:53:40
225,87
SimpleSQL
77:15:48
215,71
SimpleDB
73:08:07
227,89
50.000
candidato
250.000
500.000
100.000
opcao
500.000
Candidato
1.000.000
36
A Figura 5 apresenta os dados acima em um gráfico comparativo, facilitando a
análise do desempenho do SimpleSQL em contraste com a carga direta ao
SimpleDB.
Figura 6: Gráfico comparativo para a média de tuplas carregadas por minuto.
Percebe-se um aumento do tempo de processamento do SimpleSQL, o que é
esperado. Contudo, a sobrecarga média foi de 6% e a diferença na média de tuplas
inseridas também foi pequena. Isso mostra que a utilização do SimpleSQL não
compromete o desempenho e escalabilidade do SimpleDB.
5.2
Seleção
SimpleSQL foi avaliado ainda com a execução de consultas simples
(consultas sem junções, executadas apenas em uma tabela) e também com uma
consulta complexa combinando quatro tabelas. A Tabela 6 apresenta as consultas
simples utilizadas para medição, na sintaxe SQL e na sintaxe do SimpleDB, bem
37
como o total de tuplas retornadas. A Tabela 7, por sua vez, apresenta o tempo médio
de processamento destas consultas.
Tabela 6: Consultas simples para avaliação.
Consulta
1
2
SimpleSQL
SimpleDB
SELECT nu_candidate,
SELECT nu_candidate,
cd_race FROM candidate WHERE en_city
like 'FLORIAN%'
cd_race FROM domain1
WHERE en_city like
'FLORIAN%'
SELECT nu_candidate,
cd_race FROM candidate WHERE cd_gender
= 'F'
SELECT nu_candidate,
cd_race FROM domain1
WHERE cd_gender =
'F'
34678
58410
SELECT * FROM do-
SELECT * FROM curse
3
# tuplas
WHERE cd_area = 1
and nm_curse like
'ENGE%' and
nu_places >= 100 AND
nu_applicants > 1000
main1 WHERE cd_area
= '1' and nm_curse
like 'ENGE%' and
nu_places >= '100'
AND nu_applicants >
'1000'
58
Na Tabela 6 podem ser observadas as diferenças entre uma consulta no
padrão SQL e a sintaxe própria utilizada pelo SimpleDB. Muito embora pareçam
similares, a sintaxe do SimpleDB sempre deve referenciar um domínio na cláusula
FROM, todos os valores devem estar entre aspas simples e não há suporte a grande
parte dos operadores de agrupamento. Por outro lado, a sintaxe do SimpleDB possui
funções próprias, como itemName(), para referenciar o nome do item.
38
Tabela 7: Média de duração de cada consulta simples.
Query
SimpleSQL
SimpleDB
1
00:02:22
00:01:34
2
00:03:09
00:02:33
3
00:00:03
00:00:02
A partir dos tempos acima, observa-se que a sobrecarga do SimpleSQL não
foi superior a 40% em todas as consultas. Considera-se este resultado aceitável
(inferior a um minuto no pior caso), dado o alto volume de dados carregados,
especialmente para a tabela Candidato, que possui mais de 160 mil tuplas.
Quanto a consultas complexas, como o SimpleDB não possui o conceito de
tipo de item (tabela) e não suporta o operador de junção, como comentado
anteriormente, ele oferece apenas a liberdade de buscar itens de um único domínio .
A análise e combinação de resultados ficam a cargo da aplicação cliente.
Mesmo assim, o SimpleSQL foi projetado para suportar consultas complexas.
As etapas de processamento envolvidas na execução deste tipo de consulta são as
que seguem:
 Divisão: o comando é dividido em consultas simples sem junções.
Cada atributo esperado e critério de filtro é aplicado à sua consulta
respectiva;
 Acesso: cada consulta simples é submetida ao SimpleDB;
 Transformação: cada resultado obtido é convertido para o esquema
relacional correspondente;
 Junção: as tabelas são combinadas de acordo com os critérios de
junção definidos no comando principal, formando a tabela de retorno.
39
Desta forma, considerando-se o fluxo acima no processamento nativo do
SimpleDB, a etapa de acesso é a única que possui equivalência. Os outros passos
são recursos do SimpleSQL para oferecer suporte ao processamento de consultas
complexas.
Com esta equivalência, para comparar o desempenho do SimpleSQL e do
SimpleDB, foi tomado o tempo de cada etapa de execução, sendo o passo de
acesso foi diretamente comparado ao SimpleDB. A Tabela 8 apresenta a consulta
complexa utilizada na medição, no formato original e nas consultas individuais na
sintaxe do SimpleDB.
Tabela 8: Consulta complexa na forma original e na sintaxe do SimpleDB
SimpleSQL
SimpleDB
SELECT
candidatoClassificado.nu_or
dem, candidato.en_cidade,
estabelecimentoEnsino.nm_es
tabelecimento,
evento.dc_evento FROM
candidato INNER JOIN
estabelecimentoEnsino ON
candidato.cd_estabeleciment
o =
estabelecimentoEnsino.cd_es
tabelecimento INNER JOIN
candidatoClassificado ON
candidato.nu_candidato =
candidatoClassificado.nu_ca
ndidato INNER JOIN evento
ON
candidatoClassificado.cd_ev
ento = evento.cd_evento
WHERE evento.cd_evento = 25
AND
estabelecimentoEnsino.cd_ev
ento = 25 AND
candidatoClassificado.cd_ev
ento = 25 AND
candidato.cd_evento = 25
40
SELECT nu_ordem FROM domain1 WHERE cd_evento =
‘25’
SELECT en_cidade FROM domain1 WHERE cd_evento =
‘25’
SELECT
nm_estabelecimentoEnsino
FROM domain1 WHERE
cd_evento = ‘25’
SELECT dc_evento FROM domain1 WHERE cd_evento =
‘25’
A Tabela 9 apresenta os tempos de cada etapa. Para o SimpleDB, foi
realizada a somatória do tempo de processamento de cada consulta individual. De
acordo com estes dados, nota-se que a etapa mais custosa em todo o processo é o
acesso, mas que apresenta pequena diferença entre o SimpleSQL e o SimpleDB. As
demais etapas, necessárias para suportar a funcionalidade adicional do SimpleSQL,
demandam um pequeno tempo de processamento, se comparado ao benefício
oferecido.
Tabela 9: Duração média da execução de cada etapa do processamento de uma
consulta complexa
Etapa
SimpleSQL
Divisão
00:00:03
Acesso
00:18:17
Transformação
00:02:23
Junção
00:04:08
41
SimpleDB
00:18:05
6
TRABALHOS RELACIONADOS
Há uma variedade de trabalhos que discutem a disponibilização de bancos de
dados relacionais na nuvem. (Rys, 2011) propõe que SGBDs relacionais estejam
divididos em nodos e cada nodo deve estar pareado, para garantir disponibilidade
das informações daquele nodo. Um protocolo de consenso trata da distribuição de
dados entre a grade [22].
(Curino et. al. 2011), por sua vez, concentra-se no processamento paralelo de
uma mesma consulta em diversos nodos [16], onde a problemática está na
consolidação dos resultados, com um escopo similar ao algoritmo de MapReduce
[23].
(Campbell et. al., 2010) descreve uma implementação sobre o Microsoft SQL
Server que funciona sobre um ambiente distribuído e, com o conceito de “domínios
de consistência”, garante alta disponibilidade sem abrir mão das propriedades ACID
dentro dos domínios especificados [17].
Como alternativa ao SimpleDB, a Amazon também oferece o Relational
Database Service (RDS) [18], que oferece uma instância de MySQL, Oracle ou
Microsoft SQL Server para acesso através da nuvem. Em sendo um SGBD
relacional, há total suporte ao padrão SQL, porém as características de
escalabilidade e alta disponibilidade estão restritas à instância, que possui limitações
de tamanho.
(Arnaut et. al., 2011) e (Egger, 2009) possuem trabalhos bastante
relacionados ao SimpleSQL. Ambos utilizaram o MySQL como SGBD e adaptam sua
persistência para o Scalaris [24] e Cloudy [25], respectivamente. Ainda assim, há
uma leve diferença no foco dos trabalhos. Ao aplicarem a interface de um SGBD já
42
existente, toda a parte de tratamento dos comandos é abstraída, sendo substituída
por técnicas eficientes de armazenamento e recuperação da informação nos
repositórios escolhidos. O modelo de dados dos repositórios também varia, sendo o
Scalaris um repositório chave-valor e o Cloudy uma implementação do Casandra,
que segue o modelo de super-coluna.
Destaca-se, ainda assim, a estratégia de utilizar como interface de acesso um
SGBD relacional de mercado. Esta adaptação corrobora da ideia de facilitar a
migração de aplicações para repositórios NoSQL, que é um dos objetivos do
SimpleSQL. Da mesma forma, o trabalho desenvolvido para interpretação dos
comandos seria delegado ao SGBD.
Contudo, muito embora os repositórios utilizados tenham sido desenvolvidos
para ambientes distribuídos, eles não são voltados para a nuvem pública, que é uma
das principais características do SimpleDB. Desta forma, o usuário seria responsável
também pela sua implantação e administração.
Portanto, preserva-se ainda o pioneirismo do SimpleSQL neste sentido. Ainda
assim, é interessante o plano de desenvolver uma camada de persistência do
MysQL para o Amazon SimpleDB, como uma das possíveis evoluções do
SimpleSQL.
43
7
CONCLUSÃO
A oferta de SGBDs como serviço traz vários benefícios, como redução de
custos e menos preocupação com manutenção e administração do banco de dados.
Contudo, a maior parte das aplicações contemporâneas utilizam dados relacionais,
sendo necessário prover um vínculo entre o tradicional modelo relacional para os
dados armazenados em nuvem, que seguem outros modelos.
Este trabalho contribui com esta problemática ao propor o SimpleSQL, uma
solução específica para mapeamento relacional e interface de acesso ao SimpleDB,
um banco de dados NoSQL orientado a documentos. Apesar de ser voltada para um
sbanco de dados NoSQL em especial, esta solução pretende evoluir para uma
proposta genérica de mapeamento entre o modelo relacional e o modelo orientado a
documentos, que é um tema de futuras pesquisas. A intenção é propor uma interface
e um modelo de representação de dados padrão, permitindo ao SimpleSQL suportar
demais bases NoSQL e prover liberdade de escolha ao usuário.
Como apresentado no Capítulo 5, a avaliação experimental mostra que o
SimpleSQL adiciona uma pequena sobrecarga de processamento se comparado à
utilização direta do SimpleDB, mas essa diferença não representa um obstáculo para
sua adoção. Para operações de carga, a sobrecarga média foi de 6%. Para
consultas simples, foi observada uma adição de 40% no tempo total de
processamento, o que é esperado, considerando-se a conversão dos modelos
executada pelo SimpleSQL. Estes resultados mostram que o SimpleSQL não é
proibitivo em termos de desempenho. Uma sobrecarga maior foi observada com
consultas complexas, o que atesta o processamento adicional do SimpleSQL para
44
suportar operações não oferecidas pelo SimpleDB. Ainda assim, observou-se
otimizações que podem ser realizadas no processamento do SimpleSQL.
Como apresentado no capítulo de Trabalhos Futuros, planeja-se continuar o
desenvolvimento do SimpleSQL e a pesquisa no tema de bancos de dados NoSQL.
7.1
Trabalhos futuros
Muito embora a versão atual do SimpleSQL esteja funcional e devidamente
evidenciada na avaliação experimental, ela ainda carece de extensões e algumas
melhorias. Algumas restrições de escopo e limitações podem ser entendidas como
itens para trabalhos futuros:
 Suporte ao SQL ISO/IEC: as operações atualmente suportadas podem
ser aprimoradas para aceitar mais recursos da linguagem, como
operadores de agrupamento para consultas;
 Origem dos dados: a versão atual do SimpleSQL suporta operações
apenas sobre dados que tenham sido inseridos através dele, em
virtude da dependência do atributo SimpleSQL_TableName. Pode ser
elaborada uma ferramenta que opere sobre um volume de dados
existente, preparando-o para o SimpleSQL;
 Suporte a operações DDL: o SimpleSQL não suporta operações SQL
DDL visto que não há como definir esquemas no repositório NoSQL.
Contudo, a principal restrição do SimpleSQL é o suporte exclusivo ao
SimpleDB. Isto ocorre porque não há um padrão na interface de acesso e
representação dos dados entre os diferentes bancos de dados NoSQL.
Estes obstáculos e restrições são potenciais temas para trabalhos futuros, em
nível de graduação e pós.
45
BIBLIOGRAFIA
[1]
Abadi, D. J.: Data management in the cloud: Limitations and opportunities. IEEE
Data Eng. Bull., 32:3-12 (2009).
[2]
Abouzeid, A., Bajda-Pawlikowski, K., Abadi, D. J., Rasin, A., and Silberschatz,
A.: Hadoopdb: An architectural hybrid of Map-Reduce and DBMS technologies
for analytical workloads. PVLDB, 2(1):922-933 (2009).
[3]
Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee,
G., Patterson, D., Rabkin, A., Stoica, I., Zaharia, M.: Above the Clouds: A Berkeley View of Cloud Computing. UC Berkeley Reliable Adaptive Distributed
Systems Laboratory (2009).
[4]
Amazon SimpleDB, http://aws.amazon.com/simpledb/. Acesso em 01 de junho
de 2012.
[5]
Amazon
SimpleDB,
Getting
Start
Guide,
http://docs.amazonwebservices.com/AmazonSimpleDB/latest/GettingStartedGui
de/Welcome.html?r=1. Acesso em 03 de maio de 2012
[6]
Amazon Web Services .NET SDK,
http://aws.amazon.com/pt/sdkfornet/.
Acesso em 15 de dezembro de 2011.
[7]
Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and Brandic, I.: Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing
as the 5th utility. Future Gener. Comput. Syst., 25(6):599–616 (2009).
[8]
Cattell, R.: Scalable SQL and NoSQL Data Stores. SIGMOD (2010).
[9]
G. Coulouris, J. Dollimore, T. Kindberg: Distributed Systems: Concepts and Design, 5ª edition. Addison-Wesley, (2011).
[10] Fielding, R. T.: Architectural Styles and the Design of Network-based Software
Architectures. University of California (2000).
46
[11] Friedl, J. E. F.: Mastering Regular Expressions, 2ª edition. O’Reilly (2002).
[12] Gilbert, S., Lynch, N.: Brewer’s conjecture and the feasibility of consistent, available, and partition-tolerant Web services. ACM SIGACT News 33 (2002).
[13] Pritchett, D.: BASE, an ACID alternative. ACM Queue (2008).
[14] MSDN
Library,
Guid
Structure,
http://msdn.microsoft.com/en-
us/library/system.guid%28v=vs.90%29.aspx. Acesso em 03 de maio de 2012
[15] Sousa, F. R. C., Moreira, L. O., de Macêdo, J. A. F., Javam, C. M.:
Gerenciamento de Dados em Nuvem: Conceitos, Sistemas e Desafios. Em:
Tópicos em sistemas colaborativos, interativos, multimídia, web e bancos de
dados. Mini-cursos do XXV Simpósio Brasileiro de Banco de Dados (2010).
[16] Carlo Curino, Evan P. C. Jones, Raluca A. Popa, Nirmesh Malviya, Eugene Wu,
Samuel Madden, Hari Balakrishnan, Nickolai Zeldovich: Relational Cloud: a Database Service for the cloud. CIDR 2011:235-240 (2011).
[17] Campbell, D. G., Kakivaya, G., Ellis, N (2010). Extreme Scale with Full SQL
Language Support in Microsoft SQL Azure.
[18] Amazon Relational Database Service, http://aws.amazon.com/pt/rds/. Acesso
em 18 de maio de 2012.
[19] Fowler,
Martin.
NosqlDefinition,
http://martinfowler.com/bliki/NosqlDefinition.html. Acesso em 18 de maio de
2012.
[20] Curino, C., Jones, E., Zhang, Y., Wu, E., and Madden, S. (2010). Relational
cloud: The case for a database service. Technical report, MIT-CSAIL-TR-2010014. Computer Science and Artificial Intelligence Laboratory, MIT, USA.
47
[21] Fowler,
Martin.
Aggregate
Oriented
Database.
http://martinfowler.com/bliki/AggregateOrientedDatabase.html. Acesso em 18
de maio de 2012.
[22] Rys, Michael. Scalable SQL. Communications of the ACM 54, 6 (2011), 48-53.
[23] Foto N. Afrati, Anish Das Sarma, Semih Salihoglu, Jeffrey D. Ullman: Vision Paper: Towards an Understanding of the Limits of Map-Reduce Computation
CoRR abs/1204.1754 (2012).
[24] D. E. M. Arnaut, R. Schroeder, and C. S. Hara. PHOENIX - UM COMPONENTE
RELACIONAL PARA PLATAFORMAS DE ARMAZENAMENTO EM NUVEM. 4º
IEEE CLOUD, (684-691), 2011.
[25] Egger, D.: SQL in the Cloud. Departamento de Ciências da Computação, ETH
Zurique, 2009.
48