Ana içeriğe geç

Telemetri ve Olcum Tablolari

Bu sayfa, Qapu backend icinde bir telemetry paketinin veritabani acisindan nasil yasadigini tanimlar. Amac yalniz tablo listesi vermek degil; her tablonun neden var oldugunu, kabul zincirindeki yerini, hangi veriyi tuttugunu, hangi veriyi bilerek tutmadigini ve hangi alanlarin ne amacla eklendigini netlestirmektir.

Bu dokuman koda baslamadan once veri sozlesmesini sabitlemek icindir. Bu nedenle burada yazilanlar sadece aciklama degil, davranis kontratidir.

Genel Akis

Bu akista temel roller sunlardir:

  • raw_data: ingress journal
  • streams: accepted telemetry event
  • measurements_*: segment odakli typed measurement persistence
  • measurements: generic dusuk yogunluklu measurement persistence
  • state: son canli cihaz ozeti (runtime projection)
  • ledger_transactions: best-effort integrity trail

Bu dokumanda state, Runtime State kapsamindaki anlik cihaz projeksiyonunu ifade eder. Bu ifade belirli bir fiziksel tablo adini zorunlu kilmaz; telemetry lifecycle dokumani yalnizca bu katmanin akis ve transaction etkisini tarifler.

Ledger fail olursa

Bu modelde ledger yazimi kabul zincirini geri almaz.

Sonuc:

  • accepted stream kalir
  • measurement kalir
  • state kalir
  • ledger eksik kalabilir
  • streams.ledger_status = failed olur

Duplicate Identity Spesifikasyonu

Duplicate karari su ucluden olusur:

  • device_id
  • device_time
  • canonical_payload_hash

Bu ucu ayniysa paket duplicate kabul edilir.

Duplicate kontrolu parse + schema validation sonrasinda, streams insert oncesinde calisir.

Duplicate oldugunda

  • raw_data kaydi tutulur
  • stream_id = null kalir
  • valid_pack = false ve validation_code = DUPLICATE_PACKET olarak isaretlenir
  • stream olusmaz
  • measurement yazilmaz
  • state guncellenmez
  • warning/log uretilebilir

Transaction Boundary

Boundary 1 - Journal

raw_data journal kaydi erken ve bagimsiz yazilir.

Boundary 2 - Accepted transaction

Asagidakiler ayni transaction icinde degerlendirilir:

  • streams insert
  • measurements_* insertleri
  • measurements insertleri
  • state update
  • raw_data.stream_id iliskisinin set edilmesi

Bu zincirin herhangi bir noktasinda hata olursa accepted transaction rollback olur.

Not: Variable-level routing uyusmazliklari (unknown/inactive/segment-column) teknik hata degil, veri kalitesi olayi olarak ele alinir; yalniz ilgili degisken atlanir ve transaction rollback tetiklenmez.

Boundary 3 - Best-effort sonrasi isler

  • ledger write
  • reaction side-effects
  • bazi secondary projection'lar

Failure Matrix

Durumraw_datastreamsmeasurementstateledgerSonuc
invalid JSONvaryokyokyokyokjournal kalir
schema failvaryokyokyokyokjournal kalir
routing mismatch (unknown/inactive/segment-column)varvarkismikismiyokHatali degiskenler atlanir, gecerli degiskenler yazilir, operasyonel log uretilir
duplicatevaryokyokyokyokduplicate journal kalir
stream create failvarrollbackyokyokyokraw failed isaretlenir
measurement failvarrollbackrollbackrollbackyokraw failed isaretlenir
state failvarrollbackrollbackrollbackyokraw failed isaretlenir
ledger failvarvarvarvarfailedaccepted event korunur

Sonuc

Telemetry lifecycle modeli, Qapu backend icindeki accepted veri akisinin veritabani sozlesmesini tanimlar. Burada raw_data giris jurnali, streams accepted event, measurements_* segment odakli typed persistence, measurements generic persistence, state tablosu latest state, ledger_transactions ise best-effort integrity trail olarak konumlanir.

Uctan uca tek senaryo dogrulama seti icin:

Bu ayrim, kod yazarken hangi veri hangi tabloda dogar, hangi veri rollback olur, hangisi tarihsel kanit olarak kalir ve hangisi yalniz en son durumu tasir sorularina net cevap uretir.

Tablolar