Zimin A.N.
c06ae263e0
dict-relationships-v2 epic, Phase 2. Precomputed reverse FK index +
throttled refresh + feature flag + UI staleness badge. Migration катится
всегда; query path активируется через ordinis.lineage.mv.enabled=true.
Backend:
- Liquibase 0016: CREATE MATERIALIZED VIEW record_dependents_index +
UNIQUE INDEX(source_record_id, source_field) (REQUIRED для REFRESH
CONCURRENTLY) + composite indices для record-level и schema-level lookup.
Plus lineage_mv_meta table — single-row tracking (last_refreshed_at,
duration_ms, row_count, status, error).
- DependentsQueryMv (interface impl, @Primary + @ConditionalOnProperty)
— один SQL query через MV вместо N JSONB lookups (по одному per
source dict).
- MaterializedViewRefreshService:
* @Scheduled refresh каждые ordinis.lineage.mv.refresh-interval-sec
(default 60). Storm prevention: AtomicReference guard для in-flight,
cooldown через ordinis.lineage.mv.min-interval-sec (default 30).
* REFRESH CONCURRENTLY с fallback на plain REFRESH когда MV пустой
(initial state). Не блокирует concurrent reads.
* MvGateway interface (extracted из-за JDK 25 + Mockito incompat для
concrete JdbcTemplate). Production: JdbcMvGateway (nested static).
- LineageIndexService теперь возвращает LineageMeta в RecordDependentsPage
— mvEnabled, lastRefreshedAt, lastStatus, lastDurationMs. Optional<MV>
inject — works без MV (mvEnabled=false, всё null).
Tests:
- MaterializedViewRefreshServiceTest (9 tests):
* scheduledRefresh first time → REFRESH CONCURRENTLY
* skip when within cooldown
* refreshNow throws RefreshThrottledException when throttled
* refresh succeeds после cooldown
* fallback на plain REFRESH когда CONCURRENTLY fails
* STORM PREVENTION (R2): 100 concurrent refresh attempts → ровно 1
actual refresh (via cooldown + in-flight guard)
* lastRefresh returns meta correctly
* updates lineage_mv_meta after refresh (status=ok)
* updates with error если оба refresh'а fail (status=error)
Admin UI:
- RecordDependentsPage type расширен LineageMeta { mvEnabled,
lastRefreshedAt, lastStatus, lastDurationMs }.
- RecordDependentsPanel показывает staleness badge "обновлено N мин
назад" если MV active + last refresh > 2 min ago. Tooltip объясняет
что closed-between-refreshes records отфильтрованы query-side.
- i18n RU/EN: lineage.refs.{stale, staleHint}.
Verify:
- mvn -pl ordinis-rest-api -am test: 98/98 PASS (+9 new MV tests).
- mvn verify -pl '!ordinis-app': все модули SUCCESS (9.3s).
- pnpm tsc --noEmit: clean.
- pnpm test (vitest): 89/89 PASS.
Deploy strategy:
- Migration катится автоматом (initial REFRESH < 5 min на 5k records).
- Query path остаётся JSONB direct (Phase 1) до явного flip flag'а
ordinis.lineage.mv.enabled=true. Это позволит верифицировать MV
корректность на staging без риска для prod.
- После flip: refresh каждые 60 sec, stale window <= 2 min обычно.
Ordinis
MDM сервис для НСИ ЦУОД ОДХ (Оперативное и Долговременное Хранение). Часть линейки Terravault. Ордо/порядок (от лат. ordo) — упорядоченные классификаторы и справочные данные.
ЦУОД — anchor-клиент v1, второй клиент = свой config bundle, без code change.
Maven multimodule
ordinis/
├── ordinis-domain JPA entities, JSONB types, bitemporal model
├── ordinis-validation JSON Schema validator (networknt)
├── ordinis-events-api DTO для Kafka (semver shared module)
├── ordinis-outbox Outbox pattern + @Scheduled poller
├── ordinis-rest-api Admin write API (CRUD, bundle import)
├── ordinis-app Spring Boot main: writer side
├── ordinis-read-api Read service (PG replica + scope filtering)
├── ordinis-projection-writer Опц.: Kafka → Redis projection (feature-flagged)
├── ordinis-cuod-bundle ЦУОД config: JSON Schema, seed, Grafana dashboards
└── ordinis-migrations Liquibase changelogs → Helm pre-upgrade Job (1-shot)
Стек
- Java 21, Spring Boot 3.4
- PostgreSQL 18 + PostGIS 3.6 + btree_gist (EXCLUSION CONSTRAINT)
- Apache Kafka 4.2 (KRaft, SASL SCRAM-SHA-512)
- Hibernate Envers (tx-time) + valid_from/valid_to (effective-time) — bitemporal
- Liquibase
- Spring Cloud Config + Spring Cloud Vault (Kubernetes auth)
- Micrometer + Prometheus
- LogstashEncoder JSON stdout → Loki через Alloy
- OpenTelemetry → Tempo (OTLP gRPC)
Архитектурные принципы
- Generic dictionary engine + ЦУОД config bundle (Approach B). Engine не знает про "КА"/"наземные станции" — узнаёт через JSON Schema из bundle
- Bitemporal: Envers для tx-time + valid_from/valid_to для effective-time + EXCLUSION CONSTRAINT
- 3 scope-топика Kafka (
public/internal/restricted) — изоляция через ACL, не через filter в consumer - System boundary: 3 deployable делят БД (master+replica). Внешние consumers — только REST/Kafka, никогда прямо в БД
- Tiered performance: 1k RPS из коробки (PG replica + Caffeine). 10k+ RPS включается per-dictionary через Redis projection
- Audit log в БД (compliance), технические логи в Loki
Build
mvn clean install # все модули
mvn -pl ordinis-app -am package -DskipTests # только app + transitive
docker build -f ordinis-app/Dockerfile -t ordinis-app:0.1.0 .
docker build -f ordinis-migrations/Dockerfile -t ordinis-migrations:0.1.0 ordinis-migrations/
Связанные репо
- terravault/ordinis-infra — k8s манифесты, helm values
- terravault/ordinis-config — Spring Cloud Config (feature flags, business params)