[Gastosabertos] [okfn-br] Dúvidas com BD; Cuidando + Gastos Abertos; Servidor OK-Br
Andres MRM
andres em inventati.org
Terça Julho 7 13:29:50 UTC 2015
Falei uma semana pensando em trabalho extra por abandonar MongoDB+PythonEve.
Há coisas que já precisariam ser feitas de qualquer jeito (como a padronização
de todos os anos dos dados de execução, que fiz semana passada). Mas sim, é
possível que o custo extra total por se adotar PostGIS no lugar de MongoDB
seja maior que uma semana... Ou não. É difícil estimar...
Não sabia que PostGIS também suporta GeoJSON, depois vejo se o GeoAlchemy já
implementou isso.
Quoting Luiz Armesto (2015-07-07 09:44:10)
> A minha proposta é que discussão de questões técnicas sejam feitas na lista
> gastosabertos [1].
>
> Os issues do Github ficam para descrição de tarefas. Sempre que alguém for
> realizar qualquer tarefa, deve ter um ticket aberto, com a descrição do que
> será feito e assinado para aquela pessoa. Seja uma tarefa de desenvolvimento,
> de administração de servidor, de pesquisa por soluções técnicas... Assim
> evitamos trabalho duplicado e sabemos o que cada um está fazendo. (vou abrir
> uma outra thread na lista do gastosabertos para conversarmos sobre como nos
> organizarmos, esperem para responder esse ponto nela)
>
> Sobre a migração do cuidando para o gastosabertos, uma semana é suficiente
> mesmo? Na minha opinião não basta passar a salvar os dados que eram salvos na
> base de dados do cuidando em mongodb na base de dados do gastosabertos. Tem que
> fazer realmente a utilização das funcionalidades de indexação espacial do
> postgis, visto que atualmente os valores de longitude e latitude do cuidando
> são salvos como simples colunas float. Os dados de geolocalização não devem ser
> contaminados com códigos de erro, então nada de "404" para representar valores
> que não foi possível fazer o geocoding. O formato intermediário para os valores
> de geolocalização deve seguir um padrão, de preferencia geojson que é suportado
> tanto pelo postgis quanto pelo leaflet.
>
>
> [1] https://lists.okfn.org/mailman/listinfo/gastosabertos
>
> 2015-07-07 8:03 GMT-03:00 Andres MRM <andres em inventati.org>:
>
>
> 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
> >
> >
> _______________________________________________
> 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
>
>
>
>
> --
> Luiz Armesto
Mais detalhes sobre a lista de discussão Gastosabertos