Como lidar com 1, 10, 100 e 1024 GB no seu banco de dadosMsc. Mauro Pichiliani (@pichiliani)

mauro@pichiliani.com.br

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 |