[Gastosabertos] Dúvidas com BD; Cuidando + Gastos Abertos; Servidor OK-Br
Andres MRM
andres em inventati.org
Sexta Julho 3 14:40:12 UTC 2015
Na última reunião de integração Cuidando 2.0 e Gastos Abertos (GA), tendo em
vista que o GA vai querer mais cedo ou mais tarde usar os dados de execução
orçamentária, fiquei de migrar os dados atuais do Cuidando (execução) do
MongoDB para o Postgres.
Comecei baixando todos os dados de execução do município de SP (até agora
estava usando só os de 2015) e "normalizando" essas planilhas:
https://github.com/okfn-brasil/gastos_abertos_dados/tree/master/Orcamento/execucao
(apenas os CSVs estão "normalizados")
Ia colocar então tudo isso no Postgres e começar a migrar a API que atualmente
usa o Mongo. Mas dai, é claro, sugiram alguns problemas:
- Os dados de execução ganham/perdem colunas ao longo dos anos, inclusive
colunas de códigos que precisariam ser usadas para as chaves primárias.
É claro que isso não impede o uso de um SQL, mas é um ponto favorável a um
NoSQL, não? [1] Das alternativas que esse link cita, excluindo o Mongo, a
mais razoável me parece ser usar o "EAV", que é praticamente usar construir
um NoSQL dentro do SQL... Pesquisando mais sobre achei um documento que
discute possibilidades de NoSQL dentro do Postgres [2]. O que ele parece
recomendar é o HSTORE, que inclusive teria algum suporte via SQLAlchemy (que
é a biblioteca que estamos usando em Python para acessar o BD). Alguém aí
sabe se é uma boa escolha?
Outra opção seria a que o Leonardo deu na outra conversa: manter os dados no
Mongo e interfacear com Postgres usando FDW [3]. Mas essa última opção só
parece fazer mais sentido se fossemos manter duas APIs distintas, o que não
parece bom para o caso.
Logo estou tendendo a experimentar esse HSTORE, mas não sei se ele vai gerar
problemas para relacionar com os outros dados que já estão no BD, ou com os
futuros dados geoespaciais...
- 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...
- Para deixar as coisas mais interessantes, não estou conseguindo instalar o
Postgres no servidor. Por ironia do destino a instalação falha dizendo que o
MariaDB precisa de uma versão mais recente (aparentemente isso está
impedindo qualquer instalação na máquina). Ia tentar ver como atualizar o
Maria, mas tive medo de perder os dados de alguém...
Abraços!
[1]: https://dba.stackexchange.com/questions/58036/how-to-handle-table-design-with-variable-columns
[2]: http://www.wmmi.net/documents/PGSQL-Schemaless.pdf
[3]: https://github.com/citusdata/mongo_fdw
Mais detalhes sobre a lista de discussão Gastosabertos