[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? É
>>       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