O documento discute como lidar com diferentes volumes de dados em bancos de dados, desde 1 GB até 1 TB. Ele aborda questões de hardware, modelagem, acesso aos dados, backup e outras tecnologias. O autor enfatiza a importância de planejamento cuidadoso e conhecimento técnico para administrar bancos de dados grandes de forma eficaz.
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. 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. 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 |
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 |
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. 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. 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. 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. 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. 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. 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. 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. 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 |