Skip to content

מצב סטטיסטיקות 2.0 #141

@Uripeer3

Description

@Uripeer3

מה הייתם רוצים?

אני רואה שהכיוון היה להרים שמירה שמנוהלת פה ולא ע"י גורם שלישי. אהבתי.
רוצה להאמין שהתשתיות כבר יותר בשלות להוספת פיצ'ר של סטטיסטיקות.

להבנתי נכון להוסיף תיעוד בטבלאות SQL בנוסף ל־DUMP ב־R2,
ואז ע"ג ה־SQL הזה יהיה קל יחסית לבצע שליפות.

ה־API המוצע:

  • GET /api/alert-types?from=YYYY-MM-DD&to=YYYY-MM-DD[&includeGreen=1][&state=red,purple,yellow,green]
    מחזיר רשימת סוגי התרעות בטווח, כולל כמות התרעות וכמות פוליגונים ייחודיים לכל סוג.

  • GET /api/polygon-counts?from=YYYY-MM-DD&to=YYYY-MM-DD[&type=...][&state=...][&includeGreen=1][&polygonCountOnly=1]
    מחזיר ספירת התרעות לפי פוליגון (ממויין מהגבוה לנמוך), כולל totalAlerts, uniquePolygons, scannedEntries.

  • GET /api/polygon-histogram?from=YYYY-MM-DD&to=YYYY-MM-DD&polygon=... [&type=...][&state=...][&includeGreen=1]
    מחזיר היסטוגרמה לפי שעה (hourBuckets) ולפי דקה בתוך שעה (minuteBuckets) עבור פוליגון ספציפי.

ארכיטקטורת הנתונים המוצעת (Hybrid):

  • מקור היסטורי גולמי נשאר ב־R2 (oref-history, קבצי JSONL לפי יום).
  • מתווספת שכבת SQL ב־D1:
    • stats_alerts (אירועים מנורמלים לפי RID + שדות זמן/מיקום/סוג/state)
    • stats_coverage (סטטוס כיסוי לכל יום: partial / complete)
  • לוגיקת קריאה:
    • ימים עם כיסוי complete נקראים מ־D1.
    • ימים ללא כיסוי נשלפים אוטומטית מ־R2.
    • אם הטווח כולל את היום הנוכחי, מתבצע גם השלמה מ־/api2/history כדי לגשר על lag ב־ingestion.
  • קיימת דה־דופליקציה בין מקורות (RID + מפתח סמנטי לאירועים ללא RID).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or improvement

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions