Embed Size (px)
Citation preview
Modelos RicosUm outro motivo para usar NoSQL
Luciano Ramalho@luciano
BIREME/OPAS/OMSAcademia Python/Globalcode
Modelo de dados LILACS
Visãoparcial!
Parte de um registro ISIS
Parte de um registro ISIS
Um contexto de usoISIS ainda é largamente utilizado em bibliotecas,museus, arquivos públicos, escritórios de advocacia
BIREME/OPAS/OMS: convênio entre a Escola Paulistade Medicina (Unifesp), Organização Panamericana daSaúde e Ministério da Saúde do Brasil, com a missãode organizar, indexar e disseminar a produçãocientífica da América Latina e do Caribe
BIREME usa ISIS há 25 anos, SOLR/Lucene há 5 anose CouchDB há alguns meses
•
•
•
A missão da nossa equipe
Renovar os métodos, práticas e as ferramentas dedesenvolvimento
Práticas ágeis
Ferramentas e métodos de trabalho Open Source
Primeiro passo: de PHP sem framework para Pythoncom Django
•
•
•
•
Projeto pilotoOpenTrials
sistema de registro de ensaios clínicos
testes de medicamentos e procedimentos comseres humanos
Registro Brasileiro de Ensaios Clínicos
Financiado pelo Ministério da Saúde e OPAS
Operado pela Fiocruz com suporte da BIREME
•
•
•
•
•
•
www.ensaiosclinicos.gov.br
Retrospectiva
No projeto piloto com Python e Django, optamos pornão inovar no banco de dados, usamos MySQL, que jáera conhecido da instituição
O ReBEC está em produção desde 2010
Ganhamos um ótimo contra-exemplo: a aplicaçãoOpentTrials ficaria muito mais simples usando ummodelos de dados não normalizado
•
•
•
Onde a normalizaçãoatrapalhou
Traduções: para alguns campos, precisamos ter otexto em n línguas
Mas nunca vamos querer acessar estes campos forado contexto do resto do registro principal, eles são defato parte integrante e inseparável dele
Não queremos que eles possam ser atualizadosindendentemente do registro principal
•
•
•
Onde a normalizaçãoatrapalhou 2
Vários campos repetitivos viraram tabelas auxiliares
Versionamento
Quando um registro (ou registro auxiliar) éatualizado, o registro inteiro (e seus registrosauxliares) precisam ser revalidados pelos revisores(para verificar inconsistências) e re-publicados
Mas o histórico não pode ser perdido!
•
•
•
•
Onde a normalizaçãoatrapalhou 3
Auditoria: precisamos saber sempre que qualquerdado de um registro (ou registros auxiliares) foi alterado
Jamais um registro de uma tabela auxiliar pode seratualizado independente do registro principal
Ex: o contato científico que foi registradooriginalmente nunca poderá ser esquecido
A descrição da metodologia de intervenção é comoum contrato do pesquisador com a sociedade
•
•
•
•
Como resolvemos?Criamos uma app chamada django-fossil (no Github)
O django-fossil cria um fósil de cada registro publicado
Um fóssil é um registro desnormalizado,“petrificado”, imutável
Usa como chave primária uma assinatura digital(hash) do conteúdo
Tem uma chave estrangeira que aponta para aversão anterior
•
•
•
•
•
Solução inspirada noCouchDB e no GIT!
Isto é um fóssil!
Lição aprendida
Persistênciapoliglota
Persistência poliglota
Usar um BD relacional para aproveitar o seuconhecimento e ferramental existente
Integrar um BD NoSQL apropriado assim que omodelo relacional deixa de ser parte da solução ecomeça a ser parte do problema
•
•
Referências: elas existem!
A palavra-chave é: semistructured (ou semi-structured)
Document databases
Bases de dados documentais
ISIS é um exemplo antigo dessa categoria
Modelo de dados semiestruturado, parecido comJSON (mais simples que XML)
O esquema é armazenado junto com cada registro
Exemplos modernos e Open Source:
CouchDB e MongoDB
•
•
•
•
•
•
Para o OpenTrials/ReBECA melhor solução é o CouchDB
Mas o MongoDB também seria apropriado, comtodas as chaves de durabilidade ligadas
Motivo fundamental: MVCC (multi-version concurrencycontrol), garante que a aplicação não conseguesobrescrever acidentalmente um registro
Para fazer update, é obrigatório informar o hash daversão anterior, e assim provar que você não estáfazendo uma atualização com dados vencidos sem saber
•
•
•
•
http://python.globalcode.com.br
Minicurso gratuito em 1 de novembro, 19h00:OO sem Sotaque em Python
