Igen, valami ilyesmi lesz a helyes irány (minio vagy hasonló, esetleg még az opensearch v. elastic).
Azért válaszolok a kérdéseidre, hátha valakinek beugrik valami egy kis konkretizálással:
- A számosság tipikusan munkaidőben növekszik (nem jellemzően 0-24-es témakör), van h. napi 20k, van h. 100k.
- Semmilyen pattern nincs arra h. hogyan keletkeznek (sejthető h. hangátvitellel foglalkozunk, tehát akkor amikor Gizike felemeli a telefont :) ). A logika gyakorlatilag az h. van egy SQL db, amibe bekerül a fájl neve és néhány metaadat plusz egy uniqueid, ami a fájl neve is lesz. Jelenleg ez úgy néz ki h. account/ev/honap/nap/*.mp3. Nyers wav-ból egy script rakja oda, ha ez számít, tehát van felette azért kontrollunk h. hogy kerül oda az átmeneti tárból.
- Nincs túl nagy workload, de előfordulhatnak tüskék (átlag max. 100IOPS olvasás most, konstans 80-100IOPS írás)
- Nincs róla statom, de kb. 1Kb - 20Mb
- Nagyságrendileg 75% a kisebb
- A fájlokat nem tudom újragenerálni, ez kvázi egy végleges archívum (hangfelvételek)
- Természetesen kell backup, de ennek a mikéntje és terminológiája más kérdés. Törölni nem törlünk innen soha semmit, kvázi tekinthető append only tárolónak is. Nyilván ez nem teljesen igaz, mert pl. ha egy account lezáródik és az ahhoz tartozó felvételeket meg kell semmisíteni, akkor azt tudni kell törölni, de a törlés, módosítás, nem üzemszerű működés. Jelenleg erre van a "másik szerver", amire szinkronizálva van. Kvázi backup, de ha kell be tudjuk állítani kiszolgálni, ha megsemmisülne az "éles szerver".
Ami esetleg plusz "para", bár ahogy láttam minden object store-ból, DB-ből van lehetőség erre: ki kell tudni nyerni egy adott szűrésnek megfelelően az összes tárolt adatot fájlként (pl. 1 accounthoz tartozó összes fájl és metaadat)