Obyekt yaddaşına ixrac
Yerinə yetirilmiş hər hədəf üçün sahib olduğunuz yaddaş bölməsində bir JSON obyekti. BigQuery-dən başqa bütün məlumat anbarlarına yol budur.
1. Hansı boşluğu doldurur
İndiyədək MousePlayer-dən məlumat anbarına məhz bir yol vardı və Google-a aparırdı. Snowflake, Redshift və ya ClickHouse işlədirsinizsə, yol yox idi — hər üçü obyekt yaddaşından problemsiz oxusa belə.
Buna görə körpü hər anbara ayrı-ayrılıqda deyil, obyekt yaddaşına yazır. Snowflake S3-dən, Redshift S3-dən, ClickHouse S3-dən, BigQuery isə Google Cloud Storage-dan qəbul edir. Bir ixrac hamısına çatır.
| Hara | Necə ünvanlanır |
|---|---|
| Amazon S3 | Signature Version 4, hostda yaddaş bölməsi |
| Cloudflare R2 | Hesabınızın son nöqtəsinə Signature Version 4 |
| Google Cloud Storage | S3 uyğun API-si vasitəsilə, HMAC açarı ilə |
| MinIO, Wasabi, Backblaze B2 və digərləri | Son nöqtənizə Signature Version 4 |
| Azure Blob Storage | konteyner SAS keçidi — bizim tərəfdə ümumiyyətlə imzalama yoxdur |
2. Niyə Azure fərqlidir və bu niyə daha yaxşıdır
Azure Blob Signature Version 4 istifadə etmir; SharedKey ilə imzalayır. İkinci imzalama sxemi qura bilərdik. Əvəzində körpü bunu qəbul edir: konteyner SAS keçidi — öz yaddaş hesabınızda yaratdığınız, imzası artıq daxilində olan URL.
Bu, bizim tərəfdə daha az kod, sizin tərəfdə daha az etibar tələbi deməkdir. Hesab açarını ümumiyyətlə görmürük: təqdim etdiyiniz özünüzün bir konteynerlə məhdudlaşdırdığınız, bitmə tarixini seçdiyiniz və başqa heç nəyə toxunmadan istənilən vaxt ləğv edə biləcəyiniz icazədir.
Eyni məhdudiyyəti S3 tərəfində də tətbiq etməyə dəyər: giriş açarına yalnız bu bir prefiksə yazmaq icazəsi verin. Yalnız bu yola əlavə edə bilən açar: mouseplayer/goals/ sızsa belə digər yaddaş bölmələrinizi oxuya bilməz.
3. Hər hədəfə bir obyekt və açar tarixdir
Obyekt yaddaşında sona əlavə etmə yoxdur. Gündəlik fayl hər dəfə tam yenidən yazılmalı olardı və eyni vaxtda gələn iki hədəf bir-birini əvəz edərdi. Buna görə hər yerinə yetirilmiş hədəf öz obyektinə çevrilir.
Əvəzində çoxlu kiçik obyekt olur; bunu işlək edən açarın quruluşudur:
prefix/YYYY/MM/DD/channel/session-goal.json
Məlumat anbarı bir günü bir bölmə kimi oxuyur və keçmişi tamamlama sorğu deyil, prefiks skanıdır. Tarixə deyil, layihəyə görə bölmək istəyirsinizsə, kanal ID-sini prefiksə qoyun.
Hər obyekt bir JSON sətridir
Qəsdən girintisizdir ki, obyektləri bir-bir açmadan bütün prefiks NDJSON kimi oxunsun. Vaxt nişanı, layihə, seans, müştəri ID-si, hədəf, dəyər, valyuta və qeydi oynadan keçid.
Boş dəyər sıfır deyil, null-dur
Pul dəyəri olmayan hədəf bunu yazır: null. Məlumat anbarında sıfır heç mövcud olmamış cəmə əlavə edilərdi — “məbləğ razılaşdırılmayıb” və “sıfır məbləğ” fərqi ixracda qorunur.
4. Cavab 403-dürsə, əvvəlcə bunu oxuyun
Rədd edilmiş S3 sorğusu demək olar ki, heç nə demir və jurnalımızdakı xəta mesajının S3-dən daha çox məlumat verməsinin səbəbi var: region imzaya daxil edilir. Yanlış region və yanlış açar eyni 403 yaradır, buna görə ilk şübhə — açar — yalnız halların yarısında doğrudur.
Bu sıra ilə yoxlanacaq üç şey:
- Region, yaddaş bölməsinin bildirdiyi kimi. R2 və Google Cloud Storage bunu qəbul edir:
autovə yoxlamır; digərləri yoxlayır. - Prefiks icazəsi. Bu yolla məhdudlaşdırılmış açar:
mouseplayer/bu yola yaza bilməz:mouseplayer-goals/— resurs ARN-də sondakı kəsr işarəsi vacibdir. - Son nöqtə, R2 və S3 uyğun yaddaşlar üçün. Hostu bu hissə olmadan yapışdırın:
https://; hər iki halda onu çıxarırıq, amma hosta əlavə edilmiş yol fərqli yaddaş bölməsidir.
Giriş açarının ID-si qəsdən açıq saxlanılır. Quruluşuna görə hər imzalanmış sorğuda ötürülür, buna görə şifrələmək qoruma verməyən zəhmət olardı. Məxfi açar şifrələnir, bir daha göstərilmir və tapşırığı daşıyan daxili növbəyə heç vaxt daxil olmur.
Burada adı çəkilən bütün ticarət nişanları müvafiq sahiblərinə məxsusdur. MousePlayer-in bu provayderlərlə işgüzar əlaqəsi yoxdur.