Upload
pichiliani
View
2.784
Download
2
Embed Size (px)
DESCRIPTION
Esta palestra foi apresentada no evento SQLSaturday 345, realizado em 27/09/2014 em São Paulo
Citation preview
Como lidar com 1, 10, 100 e 1024 GB no seu banco de dadosMsc. Mauro Pichiliani (@pichiliani)
AVISO
27/09/2014 |2 |
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
27/09/2014 |3 |
Roteiro Cenário Hardware, nuvem e distribuição Modelagem Acesso aos dados Backup/Restore Importação/exportação Outras tecnologias Conclusão
27/09/2014 |4 |
Cenário
27/09/2014 |5 |
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
Cenário (2)
27/09/2014 |6 |
Cenário (3)
27/09/2014 |7 |
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
Cenário (4)
27/09/2014 |8 |
FUTURO
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
27/09/2014 |9 |
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?
27/09/2014 |10 |
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
27/09/2014 |11 |
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())
27/09/2014 |12 |
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
27/09/2014 |13 |
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
27/09/2014 |14 |
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
27/09/2014 |15 |
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
27/09/2014 |16 |
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
27/09/2014 |17 |
#prontofalei
Perguntas?
27/09/2014 |18 |