ઑબ્જેક્ટ સ્ટોરેજ નિકાસ

1. કઈ ખાલી જગ્યા ભરે છે

અત્યાર સુધી MousePlayerથી ડેટા વેરહાઉસનો એક જ માર્ગ હતો અને તે Google તરફ જતો. Snowflake, Redshift કે ClickHouse માટે નહોતો — ત્રણેય ઑબ્જેક્ટ સ્ટોરેજ સરળતાથી વાંચે છતાં.

તેથી સેતુ દરેક વેરહાઉસમાં અલગ લખવાને બદલે ઑબ્જેક્ટ સ્ટોરેજમાં લખે છે. Snowflake S3માંથી, Redshift S3માંથી, ClickHouse S3માંથી અને BigQuery Google Cloud Storageમાંથી લે છે. એક નિકાસ બધે પહોંચે છે.

ક્યાં	સંબોધન કેવી રીતે
Amazon S3	Signature Version 4; હોસ્ટમાં બકેટ
Cloudflare R2	તમારા ખાતાના એન્ડપોઇન્ટ સામે Signature Version 4
Google Cloud Storage	HMAC કી સાથે તેની S3-સુસંગત APIથી
MinIO, Wasabi, Backblaze B2 અને અન્ય	તમારા એન્ડપોઇન્ટ સામે Signature Version 4
Azure Blob Storage	કન્ટેનર SAS લિંક — અમારી બાજુ સહી જ નહીં

2. Azure જુદું કેમ અને તે સારું કેમ

Azure Blob Signature Version 4 નથી વાપરતું; SharedKeyથી સહી કરે છે. બીજી સહી પદ્ધતિ બનાવી શક્યા હોત. તેના બદલે સેતુ લે છે કન્ટેનર SAS લિંક — તમારા સ્ટોરેજ ખાતામાં બનાવેલું URL; સહી પહેલેથી અંદર.

અમારી બાજુ ઓછો કોડ અને તમારી બાજુ ઓછી વિશ્વાસની જરૂર. ખાતાની કી ક્યારેય દેખાતી નથી: તમે પોતે નક્કી કરેલી, એક કન્ટેનરની, પસંદ કરેલી સમાપ્તિ તારીખવાળી પરવાનગી આપો છો; બીજું બદલ્યા વિના ગમે ત્યારે રદ કરી શકો.

3. લક્ષ્યદીઠ એક ઑબ્જેક્ટ અને તારીખવાળી કી

ઑબ્જેક્ટ સ્ટોરેજમાં પાછળ ઉમેરવાનું નથી. દૈનિક ફાઇલ દર વખતે આખી ફરી લખવી પડે; એકસાથે આવતાં બે લક્ષ્યો એકબીજાને ઓવરરાઇટ કરે. તેથી દરેક પૂર્ણ લક્ષ્ય પોતાનો ઑબ્જેક્ટ બને છે.

કિંમત અનેક નાના ઑબ્જેક્ટ છે; કીની રચના તેને વ્યવહારુ બનાવે છે:

prefix/YYYY/MM/DD/channel/session-goal.json

વેરહાઉસ એક દિવસને એક પાર્ટિશન તરીકે વાંચે છે; પાછળની માહિતી ભરવી ક્વેરીને બદલે પ્રીફિક્સ સ્કૅન બને છે. તારીખને બદલે પ્રોજેક્ટ મુજબ વહેંચવું હોય તો પ્રીફિક્સમાં channel ID મૂકો.

દરેક ઑબ્જેક્ટ એક લીટીનું JSON છે

જાણીજોઈને ઇન્ડેન્ટ નથી, જેથી ઑબ્જેક્ટ એકએક ખોલ્યા વિના આખો પ્રીફિક્સ NDJSON તરીકે વાંચાય. સમયમુદ્રા, પ્રોજેક્ટ, સત્ર, ગ્રાહક ID, લક્ષ્ય, મૂલ્ય, ચલણ અને રેકોર્ડિંગની લિંક.

ખાલી મૂલ્ય null છે; શૂન્ય નહીં

નાણાકીય મૂલ્ય વિનાનું લક્ષ્ય લખે છે null. વેરહાઉસમાં શૂન્ય સરવાળામાં ક્યારેય ન રહેલું કુલ બનાવે — “રકમ નક્કી નથી” અને “શૂન્ય રકમ”નો ભેદ નિકાસમાં જળવાય છે.

4. 403 મળે તો પહેલાં આ વાંચો

નકારેલી S3 વિનંતી લગભગ કશું કહેતી નથી; અમારા લૉગની ભૂલ S3 કરતાં વધુ કહે તેનું કારણ છે: પ્રદેશ સહીમાં જાય છે. ખોટો પ્રદેશ અને ખોટી કી એક જ 403 આપે; તેથી દેખીતો શંકાસ્પદ — કી — ફક્ત અડધો સમય સાચો હોય.

આ ક્રમે ત્રણ તપાસ:

• પ્રદેશ, બકેટ જણાવે તે જ. R2 અને Google Cloud Storage લે છે auto અને તપાસતાં નથી; બીજા બધા તપાસે છે.
• પ્રીફિક્સની પરવાનગી. આ સુધીની કી mouseplayer/ અહીં લખી શકતી નથી: mouseplayer-goals/ — resource ARNમાં અંતનો સ્લૅશ મહત્ત્વનો છે.
• એન્ડપોઇન્ટ, R2 અને S3-સુસંગત સ્ટોર માટે. આ વિના હોસ્ટ પેસ્ટ કરો: https://; બંને રીતે દૂર કરીએ છીએ, પણ પાછળનો માર્ગ જુદી બકેટ છે.