Bancos de dados¶

Contrato de onde os dados ficam no DSP — da fonte do adotante até os arquivos de download. O passo a passo entre componentes está em Fluxo de dados; visão de camadas em Arquitetura.

Sumário¶

• Todos os bancos e repositórios
• Detalhe dos Postgres do Compose
• Diagrama
• Papéis de conexão
• Schema dsp — negócio e geo leve
• Schemas batch no dsp-db
• Pendências de download territorial
• Quem lê e quem escreve
• Dual-write da migração
• SRID via YAML
• Prefixos Spring (jobs)

Todos os bancos e repositórios¶

No fluxo completo do DSP (adotante real com fonte JDBC) entram quatro destinos de dados distintos, mais a origem:

flowchart LR
  src[("Banco de origem<br/>(adotante)")]
  mig[Job migração]
  dsp[("dsp-db")]
  gsdb[("dsp-geoserver-db")]
  geoJob[Job geo-file]
  s3[("SeaweedFS")]

  mig -->|lê| src
  mig -->|grava negócio + bbox/centroid| dsp
  mig -->|grava geom · outro Postgres| gsdb
  geoJob -->|lê flags| dsp
  geoJob -->|lê geom| gsdb
  geoJob -->|grava CSV| s3

Cada execução da migração faz dual-write: um destino operacional (dsp-db, sem polígono completo) e outro banco (dsp-geoserver-db) só para a geometria integral.

Na demo local (Começando rápido) não há banco de origem externo: o setup.sh aplica um seed sintético direto nos dois Postgres. Object storage e job geo-file costumam ficar desligados; downloads pequenos podem usar só o GeoServer Download.

Detalhe dos Postgres do Compose¶

Os dois bancos SQL são instâncias Postgres separadas no Compose. Repetem as mesmas tabelas lógicas no schema dsp, mas a migração não grava geom no dsp-db — a geometria completa vai somente para o dsp-geoserver-db (detalhe na seção seguinte).

Dentro do dsp-db há três schemas:

Cada job batch usa um schema próprio no mesmo Postgres para não misturar histórico de execução.

Diagrama¶

As setas seguem quem faz a operação: lê e grava saem do componente (job, backend, GeoServer) e apontam para o banco ou repositório.

flowchart LR
  src[(Fonte JDBC<br/>adotante)]
  mig[dsp-batch<br/>migração]
  jobGeo[job geo-file]
  dsp[(dsp-db<br/>dsp + batch schemas)]
  ex[(dsp-geoserver-db<br/>geom completa)]
  s3[(SeaweedFS)]
  api[backend]
  gsEx[GeoServer Exhibition]
  gsDl[GeoServer Download]

  mig -->|lê| src
  mig -->|grava negócio + bbox/centroid<br/>batch + flags| dsp
  mig -->|grava geom completa| ex
  jobGeo -->|lê flags| dsp
  jobGeo -->|grava batch + limpa flags| dsp
  jobGeo -->|lê geom| ex
  jobGeo -->|grava CSV| s3
  api -->|lê negócio| dsp
  api -->|lê CSV| s3
  api -->|lê WFS fallback| gsDl
  gsEx -->|lê camadas| ex
  gsDl -->|lê camadas| ex

Papéis de conexão¶

São papéis de datasource, não bancos extras. O job de migração abre quatro conexões Java: source, target, geo-target e batch (este último no mesmo host que target, schema data_migration).

O job geo-file também usa target (flags territoriais) e geo-target (exportação), com batch em geo_file_generation.

Object storage (SeaweedFS) não é Postgres: o backend e o geo-file acessam via API S3 quando o profile object-storage está ativo.

Schema dsp — negócio e geo leve¶

As mesmas tabelas lógicas existem nos dois Postgres (territory_level_1, territory_level_2, territory_level_3, area_of_interest e camadas configuradas). IDs territoriais são VARCHAR(64); AOI/camadas usam VARCHAR(255) no id.

O job deriva boundary_box e centroid_coordinates na origem e grava só no dsp-db. A geometria integral vai para geom no geoserver-db.

A coluna area em dsp.area_of_interest e a tabela dsp.kpi_measure existem somente no dsp-db (não no geo-target). A área não faz parte do dual-write: o kpiCalculationJob a calcula a partir da geom no geo-target. Temas de KPI também não são colunas da AOI.

created_at no destino é obrigatório (base do watermark). updated_at é preenchido quando o YAML declara updated-at-column.

Por que não guardar o polígono inteiro no dsp-db? Ver o aviso em Arquitetura — Fluxo de dados.

Schemas batch no dsp-db¶

SQL de init desses schemas vem do dsp-core (imagens dsp-db e jobs). Detalhe operacional: dsp-core.

Pendências de download territorial¶

Colunas só em territory_level_2 e territory_level_3 no dsp-db:

Fluxo resumido:

1. A migração processa o delta definido pelo watermark (criação/atualização desde o último sucesso).
2. Se a execução termina COMPLETED, marca territórios afetados na mesma janela temporal (requires_s3_file_regeneration = true). Na primeira carga, marca o conjunto territorial relevante.
3. O geo-file, na agenda configurada no setup, processa só pendências, publica no SeaweedFS e desliga a flag por território quando termina todos os formatos.

Se a migração falha, as flags não mudam. Mais contexto: dsp-job-geo-file-generation.

Quem lê e quem escreve¶

Os dois GeoServers usam apenas dsp-geoserver-db (processos separados, mesmo dataset).

Dual-write da migração¶

Cada execução com delta faz uma leitura na origem e duas escritas em bancos diferentes (camadas genéricas podem gravar só no geo-target):

1. Lê atributos + geometria na fonte JDBC (watermark + where-clause).
2. UPSERT no dsp-db: atributos + boundary_box + centroid_coordinates — sem coluna geom.
3. UPSERT no dsp-geoserver-db (outro Postgres): mesmos atributos + geom completa.

O kpiCalculationJob não participa desse dual-write: depois dos jobs de AOI e camadas, lê o geo-target e atualiza area e kpi_measure só no dsp-db.

flowchart LR
  job[dsp-batch] -->|1. lê| src[(Fonte JDBC)]
  subgraph w ["2. grava em dois Postgres"]
    job -->|grava sem geom| dsp[(dsp-db)]
    job -->|grava geom completa| ex[(dsp-geoserver-db)]
  end

Watermark incremental: Visão geral do job.

SRID via YAML¶

O SRID não é fixo no código. No DDL de unidades administrativas do core, geom pode ir sem typmod; AOI/camadas geradas automaticamente podem incluir SRID no CREATE TABLE.

Camadas distintas podem usar SRIDs diferentes se origem e YAML estiverem alinhados.

Prefixos Spring (jobs)¶

Visão do job de migração: Visão geral. Checagens após carga: Validação pós-migração.