Como lidar com 1, 10, 100 e 1024 
GB no seu banco de dados 
Msc. Mauro Pichiliani (@pichiliani) 
mauro@pichiliani.com.br
AVISO 
2 | 27/09/2014 |
Sobre mim 
 Mestre e doutorando em computação pelo ITA 
 Escritor da SQL Magazine, Fórum Access, Java 
Magazine, SQLServ...
Roteiro 
 Cenário 
 Hardware, nuvem e distribuição 
 Modelagem 
 Acesso aos dados 
 Backup/Restore 
 Importação/expo...
Cenário 
 1 GB = Dá para por no meu note 
 10 GB = Meu desktop dá conta 
 100 GB = Preciso de um servidor… 
 1024 GB (...
Cenário (2) 
6 | 27/09/2014 |
Cenário (3) 
 Você vai precisar de muito mais armazenamento do que 1, 10, 100 e 
1024 GB para: 
 Transaction log (talvez...
Cenário (4) 
8 | 27/09/2014 | 
FUTURO
Hardware 
 Hardware é a primeira preocupação: 
 Memória RAM + ou - até 100 GB atualmente 
 Subsistema de HD (RAID, NAS,...
Distribuição 
 Distribuição é boa pedida para suportar muitos dados, mas: 
 Saiba as opções disponíveis (Cluster? Log sh...
Nuvem 
 A nuvem (i.e. Azure) encapsula muitos detalhes: 
 Hardware 
 Custos de uso 
 Tempo de processamento 
 Process...
Modelagem 
 Boa modelagem ajuda muito! 
 Evitar tabela ‘central’ com muitas linhas e colunas 
 Tipagem correta! Evite a...
Acesso a dados 
 BDs muito grandes consomem muita memória por conexão 
 Saber limitar acesso a dados (intervalo) é uma o...
Backup/Restore 
 BD grandes = dor de cabeça no backup e restore 
 Certos volumes requerem necessariamente fitas tipo LTO...
Importação e exportação 
 Importação e exportação: comuns em BDs grandes 
 Consome muitos recursos de hardware 
 Devem ...
Outras tecnologias 
 Novos tipos de particionamento (Oracle, MongoDB, 
Cassandra) 
 Processamento de dados com o Hadoop ...
Conclusões 
 Quantidade de dados pode enganar… 
 Redimensionamento de recursos é importante 
 Opções: 
 Scale Up x Sca...
#prontofalei 
Perguntas? 
18 | 27/09/2014 |
Próximos SlideShares
Carregando em…5
×

Como lidar com 1, 10, 100 e 1024 GB no seu banco de dados

3.081 visualizações

Publicada em

Esta palestra foi apresentada no evento SQLSaturday 345, realizado em 27/09/2014 em São Paulo

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
3.081
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2.553
Ações
Compartilhamentos
0
Downloads
12
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Como lidar com 1, 10, 100 e 1024 GB no seu banco de dados

  1. 1. Como lidar com 1, 10, 100 e 1024 GB no seu banco de dados Msc. Mauro Pichiliani (@pichiliani) mauro@pichiliani.com.br
  2. 2. AVISO 2 | 27/09/2014 |
  3. 3. Sobre mim  Mestre e doutorando em computação pelo ITA  Escritor da SQL Magazine, Fórum Access, Java Magazine, SQLServerCentral.com e outras  Colaborador do iMasters há 13 anos  Autor do livro “Conversando sobre banco de dados”  Co-autor do @databasecast 3 | 27/09/2014 |
  4. 4. Roteiro  Cenário  Hardware, nuvem e distribuição  Modelagem  Acesso aos dados  Backup/Restore  Importação/exportação  Outras tecnologias  Conclusão 4 | 27/09/2014 |
  5. 5. Cenário  1 GB = Dá para por no meu note  10 GB = Meu desktop dá conta  100 GB = Preciso de um servidor…  1024 GB (ou 1 TB) = Vários servidores ou nuvem 5 | 27/09/2014 |
  6. 6. Cenário (2) 6 | 27/09/2014 |
  7. 7. Cenário (3)  Você vai precisar de muito mais armazenamento do que 1, 10, 100 e 1024 GB para:  Transaction log (talvez 1.5x)  Índices (tavez 2.x)  Espaço para backup (talvez 2.5)  TempDB (talvez 1.3x)  Tudo depende do que será feito com os dados!  Somente armazenar?  OLTP x OLAP  Mineração de dados?  Banco read only x read-write  Conheça as espectativas de desempenho, disponibilidade e outros aspectos 7 | 27/09/2014 |
  8. 8. Cenário (4) 8 | 27/09/2014 | FUTURO
  9. 9. Hardware  Hardware é a primeira preocupação:  Memória RAM + ou - até 100 GB atualmente  Subsistema de HD (RAID, NAS, SSD, etc)  Processamento (múltiplos cores)  Rede adequada para volume trafegado  Redimensionar/justificar hardware com cuidado  Saber de cabeça tempos e valores (MB/S) ajuda muito!  Hardware nem sempre é a solução…  Mudanças na aplicação  Arquitetura  Processamento paralelo  Tipo e quantidade de dados oferecida aos usuários 9 | 27/09/2014 |
  10. 10. Distribuição  Distribuição é boa pedida para suportar muitos dados, mas:  Saiba as opções disponíveis (Cluster? Log shipping? Mirroring?)  Pense nos componentes da arquitetura  Divisão dos dados pode ser complexa  Separação de acessos por usuário  Consistência se torna crucial (Constraints? Triggers?)  Replicação é OK, mas quando dá problema….  Opinião pessoal: SQL Server ainda precisa melhorar quando se fala em distribuição de dados  Servidor linkado? Views distribuídas? Particionamento? Triggers?  Se administrar um BD grande é complicado, como seria administrar vários BDs pequenos e conectados? 10 | 27/09/2014 |
  11. 11. Nuvem  A nuvem (i.e. Azure) encapsula muitos detalhes:  Hardware  Custos de uso  Tempo de processamento  Processo de upload de dados  Para certos tamanhos somente a nuvem é viável  Muito cuidado, pois:  Fornecedor quer que você gaste cada vez mais com ele  Qualquer teste é cobrado  Algumas limitações de opções e configurações 11 | 27/09/2014 |
  12. 12. Modelagem  Boa modelagem ajuda muito!  Evitar tabela ‘central’ com muitas linhas e colunas  Tipagem correta! Evite abusar de INT  Usar e abusar do particionamento em diversos arquivos  Saiba lidar com detalhes de expurgo no modelo  Evite modelos demasiadamente complexos  Normalização x Certos graus de desnormalização  Instruções SQL sofrem muito impacto da modelagem  Constraints (PK e FK)  Índices  Joins  Agregações (GROUP BY e COUNT()) 12 | 27/09/2014 |
  13. 13. Acesso a dados  BDs muito grandes consomem muita memória por conexão  Saber limitar acesso a dados (intervalo) é uma opção  Exemplos: Saldo bancário, APIs do Twitter e Facebook  Um usuário pode travar todos os outros….  Se possível, separe os usuários por tarefa e use o Resource Governor  Relatórios operacionais do dia a dia  Relatórios periódicos (fechamento do mês)  Importação/Exportação  Tarefas fora do comum  Operações que não são logadas ou fora da auditoria 13 | 27/09/2014 |
  14. 14. Backup/Restore  BD grandes = dor de cabeça no backup e restore  Certos volumes requerem necessariamente fitas tipo LTO  Padrão LTO 6 suporta 2.5TB com 160 MB/S  Planeje muito bem a estratégia de backup e recuperação:  Periodicidade  Testes  Criptografia  Documentação  Tipo de restauracão (completa, parcial)  Tempo estimado  Servidor e recursos para restauração do backup 14 | 27/09/2014 |
  15. 15. Importação e exportação  Importação e exportação: comuns em BDs grandes  Consome muitos recursos de hardware  Devem ser feitos fora do horário de trabalho  Raramente o banco total é exportado  Trabalhe com amostragens ou partições específicas  Uma simples importação de poucos dados pode atrapalhar muito  Nunca se esqueça de ter área de staging e ambientes:  De testes  De homologação  De produção 15 | 27/09/2014 |
  16. 16. Outras tecnologias  Novos tipos de particionamento (Oracle, MongoDB, Cassandra)  Processamento de dados com o Hadoop  Usabilidade e facilidades para inserção/retirada de nós e distribuição de dados  Exportação para outras ferramentas (DM, estatísticas, gráficos)  Saiba até onde ir com a tecnologia! Conheça os limites  Seja humilde e assuma que certos volumes requerem software/hardware especial 16 | 27/09/2014 |
  17. 17. Conclusões  Quantidade de dados pode enganar…  Redimensionamento de recursos é importante  Opções:  Scale Up x Scale Out  Nuvem  Distribuição de dados  Não tenha dúvidas: bancos grandes VÃO dar dor de cabeça  Ambiente desafiador gera possibilidades e oportunidades  Experiência pessoal: Murphy sempre vai ser seu amigo e te abraçar quando você menos espera 17 | 27/09/2014 |
  18. 18. #prontofalei Perguntas? 18 | 27/09/2014 |

×