Desenvolvendo Serviços de Alta Performance com APIs NoSQL para MySQL

Desenvolvendo Serviços de Alta Performance
com APIs NoSQL para MySQL

Airton Lastori
airton.lastori@oracle.com

out-2012
1 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 12

Alguns clientes MySQL


Alguns clientes MySQL

fonte: alexa.com/topsites 10-mai-2012

Agenda

 Alta Performance com MySQL
 Arquitetura e Topologias
 Métodos de Acesso e API’s
 Instalação e Exemplos
 Aprenda Mais
 Perguntas?


Agenda

 Aprenda Mais
 Perguntas?


Alta Performance
Por que há demanda?

2.2 BILHÕES DE USUÁRIOS
630 MILHÕES DE WEBSITES
40% CRESCIMENTO
DE DADOS POR ANO
1 BILHÃO
USUÁRIOS
Velocidade de escrita
560 MILHÕES
ATIVOS DIARIAMENTE Acesso chave/valor
Modelo de dados flexível
400 MILHÕES Escalabilidade horizontal
DE TWEETS
Suporte à “Big Data”
72 HORAS
POR DIA
UPLOAD A CADA
MINUTO

Disponível 24x7
5,9 BILHÕES ASSINATURAS $1 TRILHÃO
MÓVEIS EM 2011 EM 2013

1,2+ BILHÃO APPS iOS & Android $700 BILHÕES
JÁ AIXADOS EM 2012 EM 2011


Resposta tecnológica: NoSQL

Fonte: 451 Group


Usos comuns: usado como cache para
armazenamento de dados requisitados
frequentemente, especialmente em
aplicações web.

Pontos Fortes: escalabilidade,
armazenamento e busca de dados muito
rápidos; dados não estruturados e
parcialmente estruturados.

Pontos Fracos: usualmente todos os dados
tem que caber em memória rápida; falta de
recursos para Queries complexas.


Uso Tradicional do Memcached
2 níveis de hashing

httpd memcached
Usa chave
para
PHP/Perl/Java memcached
encontrar o
Memcache dado (valor)

friends:12389 memcached
chave memcache
VALUE friends:12389 0 31rn
101, 11009, 11150, 55881, 77798
rn

Não encontra valor no cache: sincronização 1/2
aplicação é responsável por buscar no Banco de Dados

httpd memcached
Não há valor
PHP/Perl/Java memcached para chave
informada
Memcache
memcached

MySQL
Slave


Não encontra valor no cache: sincronização 2/2
aplicação é responsável por sincronizar

httpd memcached
Armazenar
valor com
PHP/Perl/Java memcached
chave/valor
Memcache informados
memcached

Processo similar ocorre quando há escrita
no MySQL Master: aplicação precisa
sincronizar com cache.


Memcached + InnoDB MySQL 5.6
Mais Flexibilidade e Simplicidade Memcached com
Persistência no InnoDB
Método transparente para persistir
os dados em memória volátil
Application Memcached plug-in no mysqld ,
mapeado à API nativa do InnoDB
SQL NoSQL
(MySQL Client) (Memcached Prot.) Shared process para baixa latência

mysqld Acesso chave-valor ao
MySQL Server Memcached plugin InnoDB
Via Memcached API
InnoDB Storage Engine Usa clients Memcached existentes
Sem SQL parsing
Acesso SQL e NotOnlySQL
Operações chave-valor mas
http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.html também queries SQL, JOINs, FKs,
etc.

Usos comuns: aplicações web ou
outras que requerem melhor
performance e escalabilidade sem que
seja necessários definir esquemas
relacionais.

Pontos Fortes: armazenamento
persistente com recursos de
escalabilidade tais como sharding
nativo; melhor suporte a Queries que
apenas chave-valor.

Pontos Fracos: falta de recursos para
Queries complexas.



Usos comuns: aplicações
científicas ou de tradução direta do
paradigma orientado a objetos.

Pontos Fortes: performance e
mapeamento natural de objetos.

Pontos Fracos: falta de recursos
para realizar Queries complexas.



Usos comuns: log em tempo-real para
aplicações web ou financeiras.

Pontos Fortes: throughput muito alto
para Big Data (de Terabytes a
Petabytes); suporte excelente a
particionamento e acesso aleatório de
leitura-escrita.

Pontos Fracos: APIs de baixo-nível,
falta de recursos para realizar Queries
complexas, alta latência na resposta de
Queries.


Requisitos NoSQL
O que a solução deve cumprir?
Alta Performance
alto throughput leitura/escrita

Escalabilidade massiva
Performance auto-sharding
Escalabilidade Facilidade de uso
acesso simples (APIs)
Facilidade de Uso manutenção simples
modelo evolutivo de dados
Disponibilidade ~24x7
Alta Disponibilidade
tolerância a falhas


Ainda há espaço para SGBDs relacionais

Usos comuns: análise de dados
históricos, data warehousing,
business intelligence.

Pontos Fortes: suporte a Queries
rápidas especialmente em datasets
grandes e compressão.

Pontos Fracos: não adequado
para transações, importações e
exportações rápidas; utilização de
computação pesada.


Ainda há espaço para SGBDs relacionais

Usos comuns: processamento de
transações, aplicações interativas
transacionais

Pontos Fortes: formas facilitadas de
manipular registros; consistência;
tecnologia comprovadamente robusta.

Pontos Fracos: problemas de
escalabilidade, especialmente para
Queries contra grande volume de
dados (dezenas de Terabytes).

Escalabilidade: horizontal vs vertical
Scale Out Scale Up
• Adicionar mais servidores para • Trocar por hardware mais
aumentar performance poderoso, adicionar memória,
• MySQL adota esta abordagem CPU
em sistemas altamente • Outras soluções normalmente
escaláveis em hardware usam hardware proprietário
commodity (Intel / AMD) (SMP)

É possível combinar as duas abordagens

MySQL 5.6 SysBench Benchmarks
MySQL 5.6 vs. 5.5 - Read Write (Linux)
12.000
Transactions per Second

10.000 MySQL 5.6.7
8.000

6.000
MySQL 5.5.28
4.000

2.000

0 Oracle Linux 6
Intel(R) Xeon(R) E7540 x86_64
32 64 128 256 512 MySQL leveraging:
- 48 of 96 available CPU threads
Connections - 2 GHz, 512GB RAM

151% Ganho Performance

MySQL 5.6 SysBench Benchmarks
MySQL 5.6 vs. 5.5 - Read Only (Linux)
18.000
Transactions per Second

16.000
MySQL 5.6.7
14.000
12.000
10.000
8.000
6.000 MySQL 5.5.28
4.000
2.000 Oracle Linux 6
Intel(R) Xeon(R) E7540 x86_64
0 MySQL leveraging:
- 48 of 96 available CPU threads
32 64 128 256 512 - 2 GHz, 512GB RAM
Connections

234% Ganho de Performance

Comparativo com/sem Thread Pool
MySQL 5.5 Sysbench OLTP Apenas Leitura
12.000
10.000 MySQL Enterprise Edition
ComThread Pool
8.000
6.000
T

4.000
2.000 MySQL Community Server
SemThread Pool
0

Conexões Simultâneas no Banco de Dados MySQL 5.5.16
Oracle Linux 6.1, Unbreakable Kernel 2.6.32
2 sockets, 24 cores, 2 X 12-core
Intel(R) Xeon(R) X5670 2.93GHz CPUs
3x Melhor Escalabilidade com Thread Pool 72GB DDR3 RAM
2 X LSI SCSI Disk (MR9261-8i) (597GB)


Comparativo com/sem Thread Pool
MySQL 5.5 Sysbench OLTP Leitura/Escrita
8.000
Transações por segundo

7.000
MySQL Enterprise Edition
6.000 ComThread Pool
5.000
4.000
3.000
2.000
1.000
0
MySQL Community Server
Sem Thread Pool

Conexões Simultâneas no Banco de Dados
MySQL 5.5.16
Oracle Linux 6.1, Unbreakable Kernel 2.6.32
2 sockets, 24 cores, 2 X 12-core

20x Melhor Escalabilidade comThread Pool Intel(R) Xeon(R) X5670 2.93GHz CPUs
72GB DDR3 RAM
2 X LSI SCSI Disk (MR9261-8i) (597GB)


Escalabilidade horizontal
3 Abordagens para
Replicação escalar o MySQL
MySQL

Particionamento
Funcional

Data Sharding



Replicação • método mais simples e mais comum
• indicado para aplicações de LEITURA intensiva
MySQL • problemas com cache duplicado em aplicações com datasets grandes

• dividir a carga em múltiplos nós, com responsabilidades distintas
Particionamento • os nós podem ter redundância via replicação para alta-disponibilidade
• normalmente não é transparente para a aplicação e também recorre ao
Funcional scale up para cada database funcional, o que impõe limites

• método de maior sucesso para escalar aplicações MySQL de grande
porte hoje
Data Sharding • dados compartilhados em tabelas/caches globais, SOA
• difícil de adaptar aplicações legadas


Replicação MySQL: como escalar 1/2
Aplicação

Escritas & Leituras Leituras

Master Slave

• Divisão de leituras e escritas (R/W Split)
• Modelo assíncrono (padrão)
• Modelo semi-síncrono (a partir da versão 5.5)

Replicação MySQL: como escalar 2/2
Aplicação Load Balancer

Escritas & Leituras Leituras Leituras

Master Slave Slave

Replicação MySQL
• Escreva para 1 Master
• Leia de vários Slaves, adicione mais quando necessário
• Perfeito para aplicações de leitura intensiva

Caso de sucesso
Benefício-chave
Wikipedia • O MySQL permite economias
significativas com custos de
hardware, adicionando novos
servidores commodity de
acordo com o necessário e de
maneira incremental

Por que MySQL?
• Capacidade de escalar
conforme necessidade e de
maneira incremental
• Baixos custos e flexibilidade
mysql.com/customers



Replicação • método mais simples e mais comum
• indicado para aplicações de LEITURA intensiva
MySQL • problemas com cache duplicado em aplicações com datasets grandes

• dividir a carga em múltiplos nós, com responsabilidades distintas
Particionamento • os nós podem ter redundância via replicação para alta-disponibilidade
• normalmente não é transparente para a aplicação e também recorre ao
Funcional scale up para cada database funcional, o que impõe limites

• método de maior sucesso para escalar aplicações MySQL de grande
porte hoje
Data Sharding • dados compartilhados em tabelas/caches globais, SOA
• difícil de adaptar aplicações legadas


Escalabilidade horizontal: Data Sharding
Table T1 Data Node 1

P1 Data Node 2

P2
P3 Data Node 3

P4
Data Node 4


F1

P1 Data Node 2

P2
P3 Data Node 3

P4
Data Node 4


F1

P1 Data Node 2
F1
P2
P3 Data Node 3

P4
Data Node 4


F1

P1 Data Node 2
F3 F1
P2
P3 Data Node 3

P4
Data Node 4


F1 F3

P1 Data Node 2
F3 F1
P2
P3 Data Node 3

P4
Data Node 4


F1 F3

P1 Data Node 2
F3 F1
P2
P3 Data Node 3
F2
P4
Data Node 4


F1 F3

P1 Data Node 2
F3 F1
P2
P3 Data Node 3
F2
P4
Data Node 4
F2


F1 F3

P1 Data Node 2
F3 F1
P2
P3 Data Node 3
F2
P4
Data Node 4
F4 F2


F1 F3

P1 Data Node 2
F3 F1
P2
P3 Data Node 3
F2 F4
P4
Data Node 4
F4 F2


F1 F3

P1 Node Group 1
Data Node 2
F3 F1
P2
P3 Data Node 3
F2 F4
P4
Data Node 4
F4 F2


F1 F3

P1 Node Group 1
Data Node 2
F3 F1
P2
P3 Data Node 3
F2 F4
P4
Node Group 2
Data Node 4
F4 F2


Caso de sucesso
Benefícios-chave
• Propriedades ACID
• Solução comprovada por muitas
empresas ao longo de anos

• Por que MySQL?
• Escalabilidade virtualmente infinita:
hoje com 20 milhões de usuários, 1
Evernote bilhão de Notes e 2 bilhões de
arquivos (fotos, documentos etc)
• Flexibilidade para crescer de
maneira incremental e com baixos
custos

blog.evernote.com/tech/2012/02/23/whysql

NewSQL


Requisitos NewSQL
Relacional + NoSQL

Performance

Escalabilidade Não há solução única para
todas situações. Não há
Facilidade de Uso bala de prata.
Combine e supere
SQL/Joins
expectativas!
Transações ACID


MySQL Cluster
Carrier Grade • Arquitetura shared-nothing in-memory parallel
Database • Modelo relacional ACID, SQL

• 99.999% de disponibilidade
Alta Disponibilidade • Self-healing, failover abaixo de 1 segundo

• Performance em tempo real para altas cargas
Alta Performance • Latência baixa e preditiva

• Elasticidade, crescimento incremental
Escalabilidade • Escalabilidade linear, distribuition aware

• Open Source, hardware commodity
Open Source • APIs NoSQL (C++, Java, Memcached, Node.js)


Alguns Clientes MySQL Cluster


Caso de sucesso
•2 milhões usuários, com 30.000 novos
usuários por dia
•10.000 usuários concorrentes
•10.000 Transações Por Segundo
•99.999% uptime

“The MySQL support service has
been essential in helping us for
troubleshooting and giving
recommendations for the production
cluster.”
Carlos Morales (DBA), Playfulplay.com

blogs.oracle.com/MySQL/entry/mysql_cluster_powers_el_chavo

Performance do MySQL Cluster
SELECT Queries per Minute Performance a
1.200
Escalabilidade
1.000
800 Facilidade de Uso
Millions

600 Disponibilidade ~24x7
400
SQL/Joins
200
0 Transações ACID
2 4 8
Number of Data Nodes
 8 Servidores Intel Commodity
UPDATE Queries per Minute – 2 x 6-core processors 2.93GHz
150
– x5670 processors (24 threads)
100
Millions

– 48GB RAM
50
 Rede Infiniband
0
4 8  flexAsynch benchmark (NDB API)
Number of Data Nodes


Agenda

 Aprenda Mais
 Perguntas?


Arquitetura MySQL Cluster Performance
Escalabilidade
a

Facilidade de Uso ?
Clients

SQL/Joins ?
Transações ACID ?
Application Layer

Data Layer

Management

MySQL Cluster Data Nodes


Escalabilidade
a

Facilidade de Uso a
Clients

SQL/Joins a
Transações ACID a
Application Layer

NDB

Data Layer

Management



Escalabilidade
a
?
Facilidade de Uso a
Clients

SQL/Joins a
Transações ACID a
Application Layer

Table T1
Data Layer
P1 P2 P1
Management P3 P4 P2
P3
MySQL Cluster Data Nodes P4


Escalabilidade
a
a
Facilidade de Uso a
Clients
Disponibilidade ~24x7 ?

SQL/Joins a
Transações ACID a
Application Layer

Data Layer
P1 P2
Management P3 P4 Management



Escalabilidade
a
a
Facilidade de Uso a
Clients
Disponibilidade ~24x7 a

SQL/Joins a
Transações ACID a
Application Layer

E mais:

• Permite mudanças no
schema sem interrupção de
leituras ou escritas

Data Layer • Permite adicionar colunas
e índices online
P1 P2 P3 P4
Management P3 P4 P1 P2

MySQL Cluster Data Nodes Management


Flexibilidade da Topologia
Replicação
Replicação síncrona
entre os grupos de nós para HA

Geo-Replicação
Cluster 1 Cluster 2 assíncrona entre nós remotos
NDB para redundância
geográfica

Replicação assíncrona
entre Storage Engines
InnoDB InnoDB InnoDB
diferentes para aplicações
Synchronous
replication especializadas como geração
Asynchronous
replication
de relatórios


Agenda

 Aprenda Mais
 Perguntas?


APIs de Acesso aos Dados

Os mesmos dados
acessados
simultaneamente
através de interfaces
SQL e NoSQL


APIs Java: ClusterJ e JPA

ClusterJ
API de persistência Domain
Object Model (DataMapper)

JPA
API de persistência padronizada
pelo OpenJPA


ClusterJ ou JPA?
ClusterJ JPA
 Fácil de usar, parecida com Hibernate /  A interface JPA interface é compatível
JPA / JDO com o padrão Java Persistent API
– Domain Object Model DataMapper pattern – Implementada como um plugin OpenJPA
– Dados são representados por Objetos de Domínio
 Performance mais alta que o JDBC puro
– Objetos de Domínio não contém lógica de negócio (camada
separada)  Construída sobre ClusterJ e JDBC
– Objetos de Domínio são mapeados para tabelas no MySQL
– Usa ClusterJ onde possível e reverte para JDBC para
 Altíssima Performance algumas operações

 Construído sobre interface nativa Java  Adoção mais natural para profissionais
– JNI adapter (ndbjtie)
Java
– Parte integral do MySQL Cluster  Facilita adoção do Cluster em aplicações
– Mapeamento direto do MySQL Cluster API (NDB API) para web e aplicações legadas
Java

 Limitação: não suporta relacionamentos
– Olhe na API JPA / JDO para estes padrões de modelagem

API Memcached
Baseado em chave-valor
API simples e bastante popular entre
desenvolvedores
hash table com persistência em disco
e alta performance

Extensão do Memcached
adiciona persistência em disco sem
perda de performance
evita rotinas de invalidação do cache,
sincronismo manual

Simplicidade e Flexibilidade
evita camadas adicionais na infra-
estrutura
acesso ao dado via tabelas relacionais


Memcached é Schemaless

Evolução rápida da
aplicação:
Novos tipos de dados
adicionados
constantemente
Não requer tempo para
estender o schema ou
parada do servidor
Não requer conhecimento
de modelagem relacional
Escalabilidade incremental


Cluster & Memcached
Schemaless

key value
<town:maidenhead,SL6>
Application view
SQL view key value
set maidenhead 0 0 3
<town:maidenhead,SL6> SL6
STORED

Key Value get maidenhead
town:maidenhead SL6 VALUE maidenhead 0 3
generic table SL6
END

Cluster & Memcached
Schema configurável

key value
Application view
SQL view prefix key value


Prefix Table Key- Val-col policy
town ... code ...
col
maidenhead ... SL6 ...
town: map.zip town code cluster
Config tables map.zip


Desenvolvendo Serviços de Alta Performance com APIs NoSQL para MySQL

Desenvolvendo Serviços de Alta Performance com APIs NoSQL para MySQL

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Desenvolvendo Serviços de Alta Performance com APIs NoSQL para MySQL

Semelhante a Desenvolvendo Serviços de Alta Performance com APIs NoSQL para MySQL (20)

Mais de MySQL Brasil

Mais de MySQL Brasil (20)

Desenvolvendo Serviços de Alta Performance com APIs NoSQL para MySQL