[okfn-br] Dúvidas com BD; Cuidando + Gastos Abertos; Servidor OK-Br

Andres MRM andres em inventati.org
Segunda Julho 6 22:45:58 UTC 2015


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
> 
> 



Mais detalhes sobre a lista de discussão okfn-br