[okfn-br] Dúvidas com BD; Cuidando + Gastos Abertos; Servidor OK-Br
Andres MRM
andres em inventati.org
Terça Julho 7 11:03:51 UTC 2015
Bom dia Peter,
Eu tinha dito uma semana para a migração de todos os dados. Por enquanto
migrei só a receita e os contratos (que eram os que estavam em MySQL e nem
estavam na conta inicial, já que eu achava que eles estavam em Postgres).
Nesse momento estou cuidando da migração da execução. Mas aquele prazo de uma
semana (depois eu percebi que não fui bem claro) era pensando não só nessa
migração inicial (que deve levar menos tempo), mas também o custo a mais de
desenvolvimento quando realmente for usar o PostGIS, ou precisar adicionar
novas funcionalidades que PythoEve+MongoDB já davam "de graça".
Sobre a doc, realmente precisamos definir melhor isso... Vamos tentar pensar:
O que documentar e onde?
- Mais especificamente sobre os dados que usamos (que eu até fui meio chatinho
com você quanto a isso), a documentação está centralizada aqui:
https://pt.wikiversity.org/wiki/Gastos_Abertos/Prot%C3%B3tipo
- Doc da API. Por enquanto está na wiki GitHub do GA, mas em algum momento ela
será gerada automaticamente em outro lugar.
- Doc de instalação. Estou tentando registrar os passos necessários para
instalar o projeto, mas isso ainda não está consolidado. Ficaria no
repositório.
- Documento sobre como contribuir, na linha do que o Raniere propôs. Esse
precisamos pensar melhor como fazer... Ficaria no repositório também? É só
para quem programa? E quem não programa e quer contribuir?
- Descrição sobre o projeto. Eu consigo pensar em uma parte mais técnica e
outra mais geral. No Cuidando estou deixando na Wiki do GitLab/GitHub. Mas
seria bom pensar qual o mínimo de coisas que ela tem que ter.
- O que mais precisaria ser documentado/consolidado?
Depois a parte de comunicação... Estou enviando os e-mails todos para
GA+OK-Br porque foi isso que entendi que era para fazer. E de certa forma acho
bacana porque vira e mexe aparece alguma pessoa nova comentando. Mas se
acharem que é muito SPAM, por mim podemos mudar.
Abs!
Quoting Peter Krauss (2015-07-07 07:31:37)
> Bom dia Andres,
>
> A estimativa era (até onde lembro pois não consta em ata ou trello) de que o
> processo de migração para PostgreSQL v9.3+
> tomasse no máximo uma semana de trabalho...
> Pelo que estou vendo, tomou só um dia (!) e, a menos de testes e feedbacks da
> equipe, está feito...
> Parabéns!
>
> - - - -
> Nota geral (Bom dia a todos do Gastos+Cuidando!),
> sobre "probleminhas técnicos presentes e futuros": onde é melhor discuti-los?
>
> Pelo que entendi isso tudo agora é responsabilidade do Gastos Abertos (nada de
> dados cadastrais no Cuidando), então temos:
> * Lista geral da OKBr (aqui okfn-br em lists.okfn.org)
> * Lista do Gastos (gastosabertos em lists.okfn.org)
> * github.com/okfn-brasil/gastos_?? (/issue ou /wiki?)
> * Wiki geral do Gastos
> * (...difícil decidir onde...)
>
> Onde a equipe Gastos julga que é melhor fazer a discussão "altamente técnica"
> da coisa?
> Não teria como "criar regra" para evitar de poluir canal inadequado, e de
> ninguém mais ficar perdido?
>
> - - - -
> PS1: o Cuidando2 tem como foco os dados geocodificados, mas se a geocodificação
> é também responsabilidade do Gastos, então o Cuidando2 nem precisa cuidar
> disso.... Ainda assim, existem demandas comuns sob responsabilidade do
> Cuidando2, a arquitetura de web-services e protocolo de autenticação estavam
> sendo discutidos na equipe do Cuidando2...
>
> PS2: a deliberações da "cúpula do Gastos+Cuidando" deveriam ser registradas em
> ATA (no link é um rascunho aguardando revisão dos participantes da reunião).
> ...Estou imaginando/supondo da reunião, que as especificações funcionais e
> requisitos do "escopo arquitetura" seriam responsabilidade do Cuidando2.
>
>
>
> Em 6 de julho de 2015 19:45, Andres MRM <andres em inventati.org> escreveu:
>
>
> Migrei os dados atuais do GA para o Postgres. Aparentemente está
> funcionando:
> http://gastosabertos.org/receitas
> http://demo.gastosabertos.org/contratos
> (Havia um probleminha de ints que passaram a ser floats e apareceram assim
> na interface. Arrumei, mas pode ter outras falhas que não vi.)
> Vamos se assim para o erro aleatório que estava dando também...
>
> Luiz e Edgar, importei os contratos usando o "import_contrato.py". O
> "import_contrato_urls.py" não consegui fazer funcionar, não sei se era para
> usá-lo também, mas pelo que vi o site está normal.
> Mudei a pasta da instância para a home. Espero que assim não dê problema
> caso
> a máquina seja reiniciada...
>
>
> Quoting Peter Krauss (2015-07-06 13:00:04)
> > A minha proposta é a mesma de antes (falta definirmos Wiki's links
> perdidos), e
> > me parece compatível com o seu levantamento:
> >
> > * sem pensar: <ID, JSON> ou <ID, TEXT[]> ou seja, "FLEX";
> >
> > * pensando (planejando o conjunto completo de dados, se surgirem demandas
> joins
> > e indexações): <ID, chave1, chave2, restoFLEX>
> >
> > O segundo parece mais chatinho, mas tem como automatizar no PostgreSQL.
> >
> >
> >
> >
> > Em 6 de julho de 2015 11:46, Andres MRM <andres em inventati.org> escreveu:
> >
> >
> > Dei um "apt-get -f install" que aparentemente arrumou as dependências
> do
> > MariaDB.
> >
> > Consegui então instalar o Postgres 9.4 seguindo isso aqui:
> > http://www.postgresql.org/download/linux/ubuntu/
> > Vou ver agora se migro os dados do GA para ele e começo a colocar os
> novos
> > dados de execução nele também.
> >
> > Sobre esses últimos conversei no canal do IRC do SQLAlchemy sobre a
> questão
> > e
> > me recomendaram ou usar uma coluna no BD para cada coluna da planilha
> > (mesmo
> > que várias delas vazias para alguns anos) ou usar o tipo JSON. Ainda
> não
> > sei,
> > mas acho que vou pelo JSON...
> >
> >
> > Quoting Peter Krauss (2015-07-03 13:10:33)
> > >
> > >
> > > Em 3 de julho de 2015 12:33, Andres MRM <andres em inventati.org>
> escreveu:
> > >
> > >
> > > Quoting Peter Krauss (2015-07-03 11:57:28)
> > > > O primeiro para o coletivo aqui poder ajudar é documentar:
> se
> > precisar
> > > ajudo,
> > > > sugiro na
> > > > https://github.com/okfn-brasil/cuidando2/wiki
> > > > é fundamental saber o perfil dessas tabelas (cabeçalho de
> colunas
> > basta),
> > > e ter
> > > > uma legenda no que for relevante.
> > > Basicamente são Integers e Strings. Mas tem datas também, menos
> > relevantes.
> > >
> > > > Em seguida entender o que seria "chave primária" (candidatos)
> de
> > cada
> > > uma, para
> > > > avaliarmos se ao menos isso foi preservado ao longo dos anos.
> > > As colunas basicamente são códigos (int) e a descrição de cada
> código
> > > (str).
> > > Aparentemente todos esses códigos são necessários para
> construir uma
> > chave
> > > primária. Um jeito seria construir uma str que é a somatória de
> todos
> > esses
> > > ints e colocar em uma nova coluna:
> > >
> > > 2015.23.49.8787.73898798
> > >
> > > Mas, como disse antes, o número de códigos varia ao longo dos
> anos,
> > então
> > > algumas chaves seriam compostas por mais ou menos ints.
> > >
> > >
> > > Se tá difícil documentar na Wiki, pode ser um simples Excel
> (GoogleDocs)
> > > mostrando exemplo dos cabeçalhos (não interessa tanto o tipo do
> valor mas
> > ter
> > > uma ideia da semântica para consolidar as chaves-candidatas ... Eu
> > costumo
> > > documentar com uma linha de cabeçalho e uma linha de exemplo, ou
> seja,
> > duas
> > > linhas a cada tipo de tabela).
> > >
> > >
> > >
> > >
> > > > PostgreSQL v9.3: por favor não perca tempo com versões
> anteriores,
> > pois
> > > sei que
> > > > todos curtem JSON (!) na OKBr.
> > >
> > > Esse é outro problema, a versão que há para instalar no
> servidor é o
> > 9.1.
> > > Teria que puxar um mais recente dos outros repositórios e rezar
> para
> > não
> > > quebrar outro pacote...
> > >
> > > > Se deixar as colunas "de chave" SQL-normais, e as demais
> colunas
> > > codificadas
> > > > num campo só com JSON, terá tudo de bom que já tinha no
> Mongo.
> > > > ... e antes de bater o martelo num tabelão universal,
> > >
> > > Teria que ver qual o suporte do SQLAlchemy para JSON no
> Postgres.
> > Porque se
> > > não for para usar SQLAlchemy teria que reescrever a API atual
> do GA
> > também.
> > > E se fosse para ir por ai, me parece mais razoável migrar tudo
> para o
> > > MongoDB
> > > e pronto...
> > >
> > >
> > > SQLAlchemy (ou o framework-SQL que for) não vai diferenciar tabela
> bruta
> > de
> > > VIEW-SQL,
> > > a modelagem de dados inclui conceber as VIEWs.
> > >
> > >
> > >
> > >
> > > E outra coisa, deixando uma parte em JSON dá para cruzar os
> dados
> > depois
> > > com
> > > as outras tabelas (ex: receita) "de boa"? Será que não vai dar
> tanto
> > > trabalho
> > > quanto interfacear com o Mongo via FDW?
> > >
> > > > - Além disso, pelo que consegui entender no servidor, os
> dados
> > atuais
> > > de
> > > > receita e contratos não estão em um Postgres, mas sim
> num
> > MariaDB.
> > > Logo
> > > > teríamos que migrá-los também para um Postgres... A não
> ser
> > que
> > > alguém ai
> > > > defenda deixar tudo no MariaDB. Não sei como é o NoSQL/
> GIS
> > dele...
> > > >
> > > > Essa parte é tranquila, posso ajudar.
> > >
> > > Em teoria o SQLAlchemy cuidaria disso sozinho. Seria só mudar o
> link
> > para o
> > > BD
> > > nele e reimportar os dados. Mas nunca se sabe o que pode
> acontecer...
> > >
> > >
> > > Mais uma vez, vamos documentar: outra coisa simples de colocar na
> Wiki é
> > uma
> > > descrição sucinta do atual modelo de dados, para conferir o grau de
> > impacto (se
> > > zero ou mais) das mudanças propostas.
> > >
> > >
> > >
> > > > Infra da OKBr: é um problema sério que nasce com os problemas
> de
> > > governança.
> > > > Na minha opinião deveria haver uma infra mínima unificada,
> decente
> > e para
> > > todos
> > > > os projetos.
> > >
> > > Bom, esse servidor É uma infra mínima unificada, e esse é o
> problema:
> > puxa
> > > de
> > > um lado, quebra do outro... Isso quando não quebra sem nem
> ninguém
> > entender
> > > o
> > > que foi.
> > >
> > >
> > > Servidores com bom suporte a PostreSQL custam nos EUA o máximo
> US$10/mês
> > (!!)
> > > (para esse volume de dados e freq. de acesso que temos)
> > > é um absurdo a OKBr não ser capaz de oferecer isso para os
> projetos..
> > Mais
> > > absurdo ainda um projeto de ~R$500k
> > > não poder oferecer isso ao desenvolvedor.
> > > ... Como eu coloquei antes, é uma questão de governança-OKBr (todos
> os
> > > projetos)...
> > > Eu sugiro uma reunião técnico-deliberativa (deliberativa!) sobre o
> > assunto...
> > > :-)
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > okfn-br mailing list
> > > okfn-br em lists.okfn.org
> > > https://lists.okfn.org/mailman/listinfo/okfn-br
> > > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
> > >
> > >
> > _______________________________________________
> > okfn-br mailing list
> > okfn-br em lists.okfn.org
> > https://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
> >
> >
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
>
Mais detalhes sobre a lista de discussão okfn-br