آبجیکٹ اسٹوریج میں برآمد

پورے ہونے والے ہر ہدف کے لیے ایک JSON آبجیکٹ، آپ کے اپنے بکٹ میں۔ یہ BigQuery کے علاوہ ہر ڈیٹا گودام تک کا راستہ ہے۔

1. یہ کون سا خلا پُر کرتا ہے

اب تک MousePlayer سے ڈیٹا گودام تک صرف ایک راستہ تھا، اور وہ Google تک جاتا تھا۔ Snowflake، Redshift یا ClickHouse کے لیے کوئی نہیں تھا — حالانکہ تینوں آبجیکٹ اسٹوریج سے بآسانی پڑھتے ہیں۔

اس لیے رابطہ ہر گودام میں الگ لکھنے کے بجائے آبجیکٹ اسٹوریج میں لکھتا ہے۔ Snowflake، S3 سے لیتا ہے؛ Redshift، S3 سے لیتا ہے؛ ClickHouse، S3 سے لیتا ہے؛ اور BigQuery، Google Cloud Storage سے لیتا ہے۔ ایک برآمد سب تک پہنچتی ہے۔

کہاںپتہ کیسے طے ہوتا ہے
Amazon S3Signature Version 4، بکٹ ہوسٹ میں
Cloudflare R2Signature Version 4، آپ کے اکاؤنٹ اینڈپوائنٹ پر
Google Cloud Storageاس کی S3 سے مطابقت رکھنے والی API کے ذریعے، HMAC کلید کے ساتھ
MinIO، Wasabi، Backblaze B2 اور دیگرSignature Version 4، آپ کے اینڈپوائنٹ پر
Azure Blob Storageکنٹینر کا SAS لنک — ہماری طرف کوئی دستخط نہیں

2. Azure مختلف کیوں ہے اور یہ بہتر کیوں ہے

Azure Blob، Signature Version 4 نہیں سمجھتا؛ یہ SharedKey سے دستخط کرتا ہے۔ ہم دستخط کا دوسرا طریقہ بنا سکتے تھے۔ اس کے بجائے رابطہ یہ لیتا ہے: کنٹینر کا SAS لنک — وہ URL جو آپ اپنے اسٹوریج اکاؤنٹ میں بناتے ہیں اور جس میں دستخط پہلے سے ہوتا ہے۔

ہماری طرف کم کوڈ اور آپ کی طرف کم بھروسا درکار ہے۔ ہمیں اکاؤنٹ کی کلید کبھی نہیں ملتی: آپ اپنی مقرر کردہ اجازت دیتے ہیں، ایک کنٹینر کے لیے، اپنی منتخب میعاد کے ساتھ، جسے کسی اور چیز کو چھیڑے بغیر کسی بھی وقت واپس لے سکتے ہیں۔

یہی احتیاط S3 پر بھی مفید ہے: رسائی کلید کو صرف اس میں لکھنے کی اجازت دیں: یہی ایک سابقہ اور کہیں نہیں۔ صرف اس میں اضافہ کر سکنے والی کلید mouseplayer/goals/ لیک ہونے پر بھی دوسرے بکٹس نہیں پڑھ سکتی۔

3. ہر ہدف کا ایک آبجیکٹ، اور کلید تاریخ ہے

آبجیکٹ اسٹوریج میں آخر میں اضافہ نہیں ہوتا۔ یومیہ فائل ہر بار مکمل دوبارہ لکھنی پڑے گی، اور بیک وقت دو ہدف ایک دوسرے پر لکھ دیں گے۔ اس لیے ہر پورا ہدف الگ آبجیکٹ بنتا ہے۔

اس کی قیمت کئی چھوٹے آبجیکٹس ہیں؛ کلید کی ساخت اسے قابلِ عمل بناتی ہے:

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

ڈیٹا گودام ایک دن کو ایک پارٹیشن پڑھتا ہے، اور پچھلا ڈیٹا بھرنا استفسار کے بجائے سابقے کی تلاش ہے۔ تاریخ کے بجائے پروجیکٹ سے تقسیم کرنا چاہیں تو چینل ID سابقے میں رکھیں۔

ہر آبجیکٹ JSON کی ایک سطر ہے

جان بوجھ کر بغیر حاشیہ بندی، تاکہ پورا سابقہ آبجیکٹس کو الگ الگ کھولے بغیر NDJSON بن کر پڑھا جائے۔ وقت، پروجیکٹ، سیشن، گاہک ID، ہدف، قدر، کرنسی اور ریکارڈنگ چلانے والا لنک۔

خالی قدر null ہے، صفر نہیں

مالی قدر کے بغیر ہدف یہ لکھتا ہے: null۔ ڈیٹا گودام میں صفر ایسے مجموعے میں شامل ہوتا جو کبھی تھا ہی نہیں — “رقم مقرر نہیں” اور “صفر رقم” کا فرق برآمد میں برقرار رہتا ہے۔

4. 403 آئے تو پہلے یہ پڑھیں

مسترد S3 درخواست تقریباً کچھ نہیں بتاتی، اور ہمارے لاگ کا پیغام S3 سے زیادہ بتانے کی وجہ ہے: خطہ دستخط میں شامل ہوتا ہے۔ غلط خطہ اور غلط کلید ایک ہی 403 دیتے ہیں، اس لیے واضح شبہ — کلید — صرف آدھی بار درست ہوتا ہے۔

اس ترتیب سے تین چیزیں جانچیں:

  • خطہ، بالکل بکٹ کے بتائے مطابق۔ R2 اور Google Cloud Storage یہ لیتے ہیں: auto اور جانچتے نہیں؛ باقی سب جانچتے ہیں۔
  • سابقے کی اجازت۔ اس تک محدود کلید mouseplayer/ اس میں نہیں لکھ سکتی: mouseplayer-goals/ — resource ARN میں آخری سلیش اہم ہے۔
  • اینڈپوائنٹ، R2 اور S3 سے مطابقت رکھنے والے اسٹورز کے لیے۔ اس کے بغیر ہوسٹ چسپاں کریں: https://؛ ہم اسے دونوں صورتوں میں ہٹاتے ہیں، مگر شامل کیا گیا راستہ مختلف بکٹ ہو گا۔

رسائی کلید ID جان بوجھ کر صاف متن میں محفوظ ہے۔ یہ اصولاً ہر دستخط شدہ درخواست میں جاتی ہے، اس لیے رمز کاری حفاظت کے بغیر محنت ہو گی۔ خفیہ قدر رمز شدہ ہے، دوبارہ نہیں دکھتی، اور کام لے جانے والی اندرونی قطار میں کبھی نہیں جاتی۔

یہاں مذکور تمام تجارتی نشان اپنے متعلقہ مالکان کی ملکیت ہیں۔ MousePlayer کا ان فراہم کنندگان سے کوئی کاروباری تعلق نہیں۔