01 - Arquitetura V-0'75

Prévia do material em texto

BANCO DE DADOS II 
 
Arquitetura de SGBDs 
 
Versão dos slides: 0.75 
 
 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
 
 
 
DCC-UFLA, Lavras 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Agenda 
 Motivação 
 Arquitetura de SGBDs 
 SGBDs Paralelos 
 SGBDs Distribuídos 
 Distribuição Vertical de Processamento 
 Evolução Arquitetural de SGBDs 
2 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Sistemas Gerenciadores 
de Banco de Dados (SGBDs) 
 Sistemas de software extremamente complexos e 
de missão crítica 
 Incorporam décadas de pesquisa acadêmica e 
industrial + intenso desenvolvimento de software 
corporativo 
 Um primeiros sistemas servidores amplamente 
implantados e testados 
• Sistema de software influenciador de diversas áreas 
como redes, sistemas operacionais e sistemas 
distribuídos 
3 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Exigências Básicas de um SGBD 
 Confiabilidade: Consistência, durabilidade, 
tolerância a falhas 
 Funcionalidade: Suporte a novos requisitos de 
aplicações, flexibilidade, hardware, dados, etc 
 Performance: “Performance is not everything, 
but without performance everything is worth 
nothing“ 
4 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Como Atender estas Exigências? 
 Independência lógica: capacidade de alterar a 
descrição lógica dos dados (esquema) sem 
inteferir com usuários e programas de aplicação 
(problema em sua maior parte em aberto) 
Independência de dados 
 Independência física: capacidade de alterar a 
representação física dos dados em meios de 
armazenamento e as técnicas usadas para 
acessar estes dados sem inteferir com 
usuários e programas de aplicação 
5 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Agenda 
 Motivação 
 Arquitetura de SGBDs 
 SGBDs Paralelos 
 SGBDs Distribuídos 
 Distribuição Vertical de Processamento 
 Evolução Arquitetural de SGBDs 
6 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Projeto de uma Arquitetura de SGBD 
 Princípios básicos: 
• Abstração de informações e operações 
 
 
• Encapsulamento e estruturação 
hierárquica 
 
 
A key task in computer science is sistematic 
abstraction (H. Wedekind) 
Many sucessful designs can be seen as sucessful 
applications of abstraction and information hiding 
(David L. Parnas) 
7 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Encapsulamento e Estruturação 
Hierárquica: Benefícios 
 A implementação de componentes em 
uma camada é simplificado através do 
uso de componentes da camada abaixo 
 Componentes em uma camada são 
independentes da funcionalidade e de 
modificações em componentes das 
camadas acima 
 Testes e refinamentos em componentes 
de uma camada são possíveis sem 
afetar componentes das camadas acima 
SGBD 
BD 
8 
9 
Arquitetura ANSI/SPARC 
Esquema conceitual descreve a 
estrutura lógica do banco de dados 
Nível Interno 
Mapeamento 
Conceitual/Interno 
Nível Conceitual 
Nível 
Externo 
Esquema interno descrevendo 
detalhes de armazenamento e 
métodos de acesso 
Esquema externo descreve uma 
parte especifíca do banco de dados 
para um grupo de usúarios 
Mapeamento 
Externo/Conceitual 
Nível 
Externo 
Mapeamento 
Externo/Conceitual 
10 
Arquitetura de 5 Níveis 
(Härder e Reuter) 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas C5 
C4 
C3 
C2 
C1 
11 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
interface do(s) dispositivos 
canais de acesso 
estruturas de 
dados lógicas C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis 
(Härder e Reuter) 
12 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
interface de arquivos 
leitura e escrita de blocos 
unidades de endereçamento: 
blocos, arquivos 
estruturas auxiliares: 
catálogos de arquivos, blocos livres info. 
unidades de endereçamento: 
trilhas, cilindros, canais 
C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis 
(Härder e Reuter) 
13 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
interface do buffer do BD 
fix/unfix de páginas 
unidades de endereçamento: 
páginas, segmentos 
estruturas auxiliares: 
tabelas de páginas, tabelas de blocos 
unidades de endereçamento: 
blocos, arquivos 
C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis 
(Härder e Reuter) 
14 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
interface de registros internos 
armazenamento de registros (na B*-tree) 
unidades de endereçamento: 
registros intern., B*-trees, tabelas hash 
estruturas auxiliares: 
índices de páginas, tabelas de endereços 
unidades de endereçamento: 
páginas, segmentos 
C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis 
(Härder e Reuter) 
15 
Arquitetura de 5 Níveis 
(Härder e Reuter) 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
interface orientada a registros 
FIND NEXT/STORE, SCAN, SORT 
unidades de endereçamento: 
registros externos, conjuntos, chaves… 
estruturas auxiliares: 
dados de caminhos de acesso 
unidades de endereçamento: 
registros intern., B*-trees, tabelas hash 
C5 
C4 
C3 
C2 
C1 
16 
Arquitetura de 5 Níveis 
(Härder e Reuter) 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
interface orientada a conjuntos 
SQL, QBE 
unidades de endereçamento: 
tabelas, visões, tuplas 
estruturas auxiliares: 
descrição do esquema externo 
unidades de endereçamento: 
registros externos, conjuntos, chaves… 
C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis (Härder e Reuter) 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
3 abc $ de tabelas 
visões 
7 xyz # zz 
C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis (Härder e Reuter) 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
3 abc $ de tabelas 
visões 
7 xyz # zz 
registros 
externos 3 abc 7 xyz 
reg. 1 reg. 2 
$ de 3 # zz 7 
reg. 3 reg. 4 
C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis (Härder e Reuter) 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
3 abc $ de tabelas 
visões 
7 xyz # zz 
registros 
externos 3 abc 7 xyz 
reg. 1 reg. 2 
$ de 3 # zz 7 
reg. 3 reg. 4 
registros 
internos 
registro 1 registro 2 
214 abc 3 318 xyz 7 
C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis (Härder e Reuter) 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas3 abc $ de tabelas 
visões 
7 xyz # zz 
registros 
externos 3 abc 7 xyz 
reg. 1 reg. 2 
$ de 3 # zz 7 
reg. 3 reg. 4 
registros 
internos 
registro 1 registro 2 
214 abc 3 318 xyz 7 
reg. 1 
reg. 3 
reg. 2 … 
… 
buffer do BD 
C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis (Härder e Reuter) 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
3 abc $ de tabelas 
visões 
7 xyz # zz 
registros 
externos 3 abc 7 xyz 
reg. 1 reg. 2 
$ de 3 # zz 7 
reg. 3 reg. 4 
registros 
internos 
registro 1 registro 2 
214 abc 3 318 xyz 7 
reg. 1 
reg. 3 
reg. 2 … 
… 
buffer do BD 
A 
A A‘ 
B 
B 
C 
C C‘ 
segmento 
arquivo 
C5 
C4 
C3 
C2 
C1 
Arquitetura de 5 Níveis (Härder e Reuter) 
armazenamento externo 
serviços de arquivos 
controle de propagação 
estruturas de 
armazenamento 
caminhos de acesso 
lógicos 
estruturas de 
dados lógicas 
3 abc $ de tabelas 
visões 
7 xyz # zz 
registros 
externos 3 abc 7 xyz 
reg. 1 reg. 2 
$ de 3 # zz 7 
reg. 3 reg. 4 
registros 
internos 
registro 1 registro 2 
214 abc 3 318 xyz 7 
reg. 1 
reg. 3 
reg. 2 … 
… 
buffer do BD 
A 
A A‘ 
B 
B 
C 
C C‘ 
segmento 
arquivo 
cilindros 
trilhas, etc 
1 
3 
5 
4 
2 
C5 
C4 
C3 
C2 
C1 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
C1: Serviço de Arquivos 
 Esta camada opera sobre padrões de bits armazenados 
em dispositivos de armazenamento não volátil 
 Principal serviço de C1: abstração de características de 
cada dispositivo de armazenamento em blocos de 
tamanho fixo que podem ser acessados através de um 
identificador de bloco 
• Banco de dados dividido logicamente em blocos 
 Notem que o BD ainda pode ser dividido em diferentes 
espaços de armazenamento 
• Termo usado em manuais: table space 
• Podemos ter diferentes table spaces para servir diferentes 
tipos de dados: table spaces diferentes para tabelas 
regulares, tabelas temporárias, índices, etc 
 
23 
C1: Serviço de Arquivos 
 A abstração de C1 pode ser feita diretamente pelo SGBD ou pelo 
sistema de arquivos do sistema operacional 
 C1 implementada pelo SO: 
• Maior facilidade de administração: o SGBD simplesmente usa os 
serviços do sistema de arquivos 
• Sujeito a double buffering, isto é, dados podem estar duplicados em 
memória no cache do SO e no buffer do SGBD em C2 : em muitos 
casos, uma desvantagem 
• Certos SGBDs suportam apenas esta opção (e.g., PostgreSQL) 
 C1 implementada pelo SGBD: 
• O SGBD provê um sistema de arquivos customizado realizando acesso 
direto aos dispositivos de armazenamento (raw IO) 
• Maior peformance, mas administração é mais complexa 
• Certos SGBDs suportam as duas opções e ainda permitem uma 
configuração hibrída, onde certas table spaces são gerenciadas pelo 
SO e outras diretamente pelo SGBD (e.g., IBM DB2) 
24 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
C1: Serviço de Arquivos 
25 
C1 implementada 
pelo SO 
C1 implementada 
pelo SGBD 
Sistema de arquivos do SO 
C2: Controle de Propagação Dados 
Dados 
Double 
buffering 
Sistema de arquivos do SBBD 
Raw IO 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
C2: Controle de Propagação 
 Esta camada divide o BD em páginas: partições de tamanho 
fixo de um espaço de endereçamento linear 
 Páginas são mapeadas para blocos de C1 
• Relação 1-1 entre páginas e blocos é comum, mas não é uma 
restrição conceitual 
 Para efetivamente reduzir IO, esta camada provê um ou 
mais buffers para BD 
• Termo para buffers nos manuais: buffer pool 
• Assim como table spaces, podemos ter buffers associados com 
diferentes porções do BD: buffer para tabelas regulas, tabelas 
temporárias, índices, etc 
 C2 provê uma interface orientada à páginas para o(s) 
buffer(s) do SGBD 
26 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
C3: Estruturas de Armazenamento 
 Esta camada gerencia representações físicas de objetos do 
BD (registros, campos, informações do catálogo, etc) em 
páginas 
 Provê uma variedade de caminhos de acesso para a 
camada superior (ponteiros, árvores de busca, tabelas 
hash, etc) 
 Em conjunção com caminhos de acesso, mecanismos de 
agrupamento de dados (clustering) são implementados 
nesta camada 
 Realiza mapeamentos muito mais complicados que aqueles 
realizados pelas camadas C1 e C2 
 Por razões de performance, o particionamento dos dados 
em páginas ainda visível é em C3 
27 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
C4: Caminhos de Acesso Lógicos 
 Esta camada provê operações e objetos típicos 
de uma linguagem para manipulação de dados 
procedural (e.g., álgebra relacional) 
 Operadores nesta camada usam uma interface 
de acesso a dados do tipo one-record-at-a-time 
• Dados são acessados através de uma hierarquia ou 
rede de registros lógicos ou através de caminhos de 
acesso lógicos 
28 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
C5: Estruturas de Dados Lógicas 
 Esta camada provê estruturas de dados lógicas 
(como tabelas e visões) e suporte à operações 
declarativas 
• Interface não procedural do SGBD 
• Suporta um modelo de dados independente de 
caminhos de acesso e detalhes de armazenamento 
com acesso declarativo (e.g., SQL) 
 Nesta camada é realizada a compilação de 
consultas SQL em planos de consulta que serão 
executados em C4 
29 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Arquitetura de 5 níveis: Flexibilizações 
 Número de níves reconsiderado 
• Maior número de níveis: 
− Complexidade reduzida em camadas individuais -> evolução 
facilitada 
− Maior número de mapeamentos necessários durante execução 
-> performance prejudicada 
• Grande espaço de buffer -> acesso a N1 é evitado 
• Compilação e early binding -> execução a partir de N4 
− Modificações (dados, esquema, índices, etc) podem invalidadar 
modulos de acesso 
 Encapsulamento reconsiderado 
• Dependências e transmissão de informações inter-níveis 
− Informações sobre uso de buffers (N2) para otimizar otimização 
de consultas em N4 (Hot set model) 
 
 
30 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Componentes de um SGBD (XML) 
31 
OS File System 
Transaction Log Container Files Temporary Files 
X
T
C
se
rv
e
r 
Transaction Services 
File Services 
Propagation Control 
Access Services 
Node Processing 
Services 
XML Processing Services 
Interface Services 
Http Agent Ftp Agent DOM RMI SAX RMI API RMI 
XML Manager XSLT Processor XQuery Processor 
Node Manager 
Record Mgr Index Mgr Catalog Mgr 
Buffer Manager 
I/O Manager Temp File Mgr 
Transaction Manager 
Lock Manager 
Deadlock Detector 
Path Processing 
C1 
C2 
C3 
C4 
C5 
TSJ Processing 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Agenda 
 Motivação 
 Arquitetura de SGBDs 
 SGBDs Paralelos 
 SGBDs Distribuídos 
 Distribuição Vertical de Processamento 
 Evolução Arquitetural de SGBDs 
32 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
SGBDs Paralelos 
 Três designs populares 
• Memória compartilhada: todos processadores 
compartilham uma memória global e tem acesso a 
todos discos 
• Disco compartilhado: cada processador possui 
uma mémoria privada mas tem acesso a todos 
discos 
• Shared-nothing: cada processador possui 
mémoria(s) e disco(s) privados 
33 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Memória Compartilhada 
34 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
CPU 
CacheCPU 
Cache Memoria 
Local 
Arquitetura NUMA 
Disco 
RAM 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Memória Compartilhada 
 Todos processadores podem acessar a mesma 
RAM e disco com a mesma performance 
 Caso os nós de processamento possuam 
mémoria local (o cache do processador não é 
considerado) com tempo de acesso superior 
com a memória remota compartilhada, 
teremos uma configuração de memória 
compartilhada baseada em arquitetura NUMA 
(Non Uniform Memory Acess) 
35 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Memória Compartilhada 
 Configuração mais comum: 2-8 processadores 
 Configuração high-end: dúzias de processadores 
• Um dos últimos cash cows da indústria de hardware 
• Servições OLTP de missão crítica 
 Custo reduzido de administração 
 Modelo de programação bastante similar ao 
modelo usado em arquiteturas multi-core 
 Otimizador deve ser adaptado para paralelizar a 
execução de uma consulta entre múltiplas CPUs 
 Suportada pelos principais produtos comerciais: 
IBM DB2, Oracle, Microsoft SQL Server 
36 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Shared-Nothing 
37 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
RAM 
RAM 
RAM 
RAM 
RAM 
RAM 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Shared-Nothing 
 Composto por um cluster de máquinas independentes que 
se comunicam via rede de comunicação de alta-velocidade 
 Um nó não possui acesso direto ao disco e memória dos 
outros nós 
 Frequentemente, implementado usando componentes 
básicos de hardware 
 Coordenação realizada em sua totalidade pelo SGBD: 
inexistência de abstrações de hardware 
 Na configuração mais comum, cada instância do SGBD 
executa em seu modelo de processo e é completo, isto é, 
pode processar consultas de maneira autonôma 
 Paralelismo ditado por particionamento dos dados 
38 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Shared-Nothing 
39 
 Particionamento horizontal dos dados 
• Round-robin 
• Baseado em hash 
• Baseado em intervalos 
SCAN 
SORT 
SCAN 
SORT 
SCAN 
SORT 
MERGE 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Shared-Nothing 
 Requer mecanismos de coordenação entre os nós 
(possível gargalo) 
• Transações: bloqueios, deadlock, etc 
• Balanceamento de carga 
 Falha de um nó pode fazer com parte dos dados 
se torne inacessível 
• Necessidade de redundância 
 Excelente escalabidade e performance 
 Exemplos: IBM DB2, 
 Informix, Tandem, NCR Teradata, NoSQL, etc 
40 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Disco Compartilhado 
41 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
CPU 
Cache 
Disco 
RAM RAM 
RAM 
RAM 
RAM 
RAM 
SAN 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Disco Compartilhado 
 Todos processadores podem acessar o disco com 
a mesma performance, mas um processador não 
possui acesso direto a memória dos demais 
processadores 
 Design tem se tornado mais atraente com a 
popularização de SAN (Storage Area Networks) 
• Um ou mais discos lógicos podem ser montados 
• Rede de alta performance 
 Exemplos: Oracle RAC e DB2 for zSeries SYSPLEX 
 
42 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Disco Compartilhado 
 Fácil manutenção em comparação com shared-
nothing 
• Para DBs de tamanho mediano, não é necessário 
considerar particionamento de dados para obter 
paralelismo 
 Falha em um dos nós de processamento não 
afeta os demais 
• Memória compartilhada: compromete todo o sistema 
• Shared-nothing: parte dos dados pode ser tornar 
inacessível (caso não exista redundância) 
 Falha no disco compromete todo o sistema 
43 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Disco Compartilhado 
 Como cada máquina possui sua memória local e 
pool de buffer, diferentes cópias dos dados do 
disco compartilhado podem estar replicado nas 
memórias locais 
 Risco de inconsistência-> coordenação explicíta 
dos dados é requerida 
 Mecanismos de coordenação podem representar 
sério gargalo 
• IBM zSeries SYSPLEX implementa o gerenciador de 
bloqueios em um subsistema de hardware 
44 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Agenda 
 Motivação 
 Arquitetura de SGBDs 
 SGBDs Paralelos 
 SGBDs Distribuídos 
 Distribuição Vertical de Processamento 
 Evolução Arquitetural de SGBDs 
45 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
SGBD Distribuídos 
46 
Rede de Comunicação 
SGBD 
SGBD 
SGBD 
SGBD 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
SGBD Distribuídos 
 Amplo espaço de alternativas arquiteturais ao longo 
das dimensões de distribuição, heterogeneidade e 
autonomia 
47 
 Autonomia: refere-se a distribuição 
de controle; indica o grau de 
independência de cada SGBD 
 Distribuição: refere-se a distribuição 
dos dados 
 Heterogeneidade: pode ser de 
hardware, SO, etc. Particularmente 
importante é a heterogeneidade de 
dados 
Autonomia 
D
is
tr
ib
u
iç
ão
 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
SGBD Distribuídos: Exemplo 
48 
Esquema 
Federado 
Federação: formada por SGBDs 
heterôgeneos e autonômos 
Esquema 
Local 
Esquema 
Local 
Esquema 
Local 
Mapeamento 
local/global 
Usuario1 Usuario3 Usuario2 
 Situado no extremo das três 
dimensões 
 Integração de dados virtual 
 Maiores problemas: 
Heterogenidade semântica em 
nível de esquema e instância 
 Trade-off entre poder 
expressão e tratabilidade para 
linguagens usadas para 
descrever e consultar as fontes 
de dados 
 Nova tendência: paradigma 
pay-as-you go 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Agenda 
 Motivação 
 Arquitetura de SGBDs 
 SGBDs Paralelos 
 SGBDs Distribuídos 
 Distribuição Vertical de Processamento 
 Evolução Arquitetural de SGBDs 
49 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Distribuição Vertical de 
Processamento 
 Componentes básicos em um sistema de 
informação: 
• Camada de apresentação: Interação com usuário, 
GUIs 
• Camada de aplicação: Lógica de aplicação 
• Camada de dados: Gerenciamento dos dados 
(SGBD) 
 
50 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Distribuição Vertical de 
Processamento 
51 
Camada de Apresentação 
Camada de Aplicação 
Dados 
Servid
o
r 
Cliente 
Sistem
a d
e 
In
fo
rm
ação
 
Arquitetura Centralizada 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Distribuição Vertical de 
Processamento 
52 
Arquitetura Cliente/Servidor 
Cliente 
Camada de Apresentação 
Camada Aplicação 
Camada Dados 
Sistem
a d
e 
In
fo
rm
ação
 
Servid
o
r 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Distribuição Vertical de 
Processamento 
53 
Arquitetura Três Camadas 
Middleware 
Cliente 
Camada de Apresentação 
Camada de Aplicação 
Camada de Dados 
Sistem
a d
e 
In
fo
rm
ação
 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Agenda 
 Motivação 
 Arquitetura de SGBDs 
 SGBDs Paralelos 
 SGBDs Distribuídos 
 Distribuição Vertical de Processamento 
 Evolução Arquitetural de SGBDs 
54 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
SGBD Universal? 
 OLTP - Online Transaction Processing: transações 
simples, curtas, altamente concorrentes (>1k 
tpm), pré-definidas, garantias ACID, operações 
rw, BD tamanho moderado (0.1TB-1TB) 
 OLAP – Online Analytic Processing: transações 
complexas (com agregações), não concorrentes e 
não-transacionais, ad-hoc, operações ro, BDs 
grandes [-,10 PB) 
55 
Prof. Dr.-Ing. Leonardo AndradeRibeiro 
SGBD Universal? 
 Processamento de streams (ex.: redes de sensores, 
feeds): consultas estáticas/dados dinâmicos, fluxo 
contínuo (sem end-of-table), consultas aproximadas e 
baseadas em janelas de tempo, etc 
 Banco de dados científicos: operações especializadas 
(ex.: regressão), linhagem, arquivamento, imprecisão, ... 
 Texto e dados semi-estruturados: ausência de estrutura 
(e noção de consistência), resultados ranqueados, 
critério de relevância... 
 É viável (ou possível) desenvolver um SGBD para atender 
a todas estas demandas (“One size fits all”)? 
56 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
SGBD Universal: Problemas 
 Modelo Relacional: 
• Processamento de dados de negócio (sistemas bancários, 
controle de estoque, etc) = OLTP 
• Simplicidade espartana 
• Novos ornamentos requerem novas operações 
 SGBD complexos: 
• Curva de aprendizagem acentuada (sistema + linguagem), 
difíceis de gerenciar, ajustar, performance imprevisível 
(algumas consultas podem ser desastrosas), consumo de 
mémoria excessivo (inapropriado para dispositivos com 
restrição de hardware) 
• Sistemas especializados para OLAP, streaming, dados 
científicos, e texto superaram sistemas convencionais por 
um fator de 10, podendo chegar até 2 ordens de magnitude 
[Stonebraker et al. 2007]! 
 
 
57 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
SGBD Universal: Virtudes 
 Alguma aplicações são inerentemente híbridas: 
• OLTP + OLAP (ex.: análise de dados em tempo real) 
• Dados estruturados + texto (ex.: Web 2.0) 
 Solução 1: múltiplos sistemas especializados 
conectados através de um mesmo parser, pre-
processador, ou middleware 
• Múltiplas APIs, diferentes semânticas, heterogeneidade 
de dados, integração ad-hoc em nível de aplicação. 
• Otimização de consultas difícil (se não impossível) 
 Solução 2: SGBD Hibrído 
• Integração uniforme em todos os níveis (API, 
linguagem, modelo de dados, algebra, otimização) 
58 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
SGBD: Extensibilidade 
 Extensibilidade via ADTs (abstract data type) 
• Pacotes de tipos para operações e dados 
sofisticados: texto, imagens, etc 
• Vários nomes: Datablades (Informix), Data 
cartridges (Oracle), Relational Extenders (IBM) 
 Requer modificações significativas no 
compilador de consultas e mecanismo de 
armazenamento 
• parser, regras para lidar com propriedades 
semânticas dos ADTs, etc 
59 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Evolução Arquitetural 
(ou como ensinar novos truques para um elefante velho) 
1. Novas aplicações -> novas demandas 
2. SGBDs especializados 
3. Simulação no topo de SGBDs convencionais 
(relacionais) 
4. Suporte nativo no SGBD convencional (novo tipo de 
dados, índice, e técnica de processamento) 
5. Diferença de performance entre o SBGD especializado 
e convencional diminui a cada nova versão 
6. Pronto! 
 Exemplos: XML, consultas espaciais 
 
60 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Arquiteturas RISC [Chaudhuri e Weikum] 
 Conjunto de componentes básicos de funcionalidade 
especializada e reduzida e interfaces simplificada 
 Componentes mais complexos construídos a partir 
destes componentes básicos 
 Pros/Contras 
+ Previsibilidade e auto-ajuste (automatic tuning) 
- Mais mapeamentos e interfaces -> overhead 
- Requer padronização extensiva: universal “glue” 
- Definição de um conjunto mínimo de funcionalidades não é 
trivial 
- Complexidade pode reaparecer no nível global 
61 
62 
NoSQL (Not only SQL) 
• O termo NoSQL é usado para se refereir a tecnologias de 
armazenamento de dados que abrem mão de consistência em 
prol de escalabilidade e alta disponibilidade 
• O teorema CAP (Consistency, Availability, Partition Tolerance): 
É possível ter apenas duas destas três propriedades em 
sistemas distribuídos [Brewer 04] 
• Modelo de dados tipicamente baseado em pares chave-
payload 
 
 
 
 Relacional: ACID 
• Atomicity 
• Consitency 
• Isolation 
• Durability 
 
 NoSQL: BASE 
• Basically Available 
• Soft-state 
• Eventual consistency 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
NoSQL (Not only SQL) 
 Vários sistemas implementados, diferentes características 
(“One size does not fits all”): Hadoop, Cassandra, 
MongoDB, CouchDB, e muito mais 
 Extensiva adoção (aplicações Web): Google, Facebook, 
eBay, Amazon, Digg, Twitter, e muito mais 
 Pros/Contras 
+ De fato, vários sistemas entregam escalabilidade (petabytes!) e 
alta disponibilidade 
+ Schema-free 
- Muitos sistemas ainda baseados em linguagens procedurais de 
baixo-nível 
- Falta de padronização 
- É realmente necessário abrir mão de consistência? 
 
63 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Evolução Motivada por Hardware 
 Preço 1GB RAM 
• 1970 = $2B, 
• 1985 = $1M, 
• 2000 = $500 
• 2015 = $0.25 
− 1TB < $300 
 
64 
Banco de dados OLTP crescem 
modestamente. A grande maioria 
hoje é menor que 1TB. Este quadro 
não deverá mudar nos próximos anos 
OLTP BDs em memória RAM 
 Fenômeno similar em outros componentes de hardware: 
Moore‘s law 
 Popularização de arquiteturas multiprocessadores shared-
nothing (clusters/grids) como plataforma de hardware 
65 
BDs em RAM e Grids 
• Controle de buffer não 
é necessário 
• Single-thread 
• Exploraçao de 
propriedades de certas 
transações (ex.: 
comutatividade) 
• Hardware redundante 
(réplicas) 
Contagem de instruçoes para vários 
componentes de um típico BD OLTP 
[Harizopoulos et al. SIGMOD 2008] 
Melhoria de performance 
em até 20x! 
Prof. Dr.-Ing. Leonardo Andrade Ribeiro 
Referências Adicionais 
 Härder, T; Reuter, A.: Principles of 
Transaction-Oriented Database Recovery. ACM 
Comput. Surv. 15(4): 287-317 (1983) 
 Härder, T.: DBMS Architecture - Still an Open 
Problem. BTW 2005, pp. 2-28 (2005) 
 Hellerstein, J. M.; Stonebraker, M.; Hamilton, 
J. R.: Architecture of a Database System. 
Foundations and Trends in Databases 1(2): 
141-259 (2007) 
 
66