चेतावनी: 2 घंटे में $14k का BigQuery शुल्क

मूल लेख ↗ Hacker News चर्चा ↗

Google के BigQuery में सार्वजनिक HTTP Archive डेटासेट पर क्वेरी करने वाले एक शोधकर्ता से अनजाने में दो घंटे में $14,000 का शुल्क लिया गया, जिससे cloud data services में लागत को कैसे दिखाया या छिपाया जाता है, इस पर व्यापक चर्चा छिड़ गई। टिप्पणीकार समझाते हैं कि डेटासेट मुफ्त है लेकिन क्वेरियों का बिल स्कैन किए गए प्रति terabyte के हिसाब से लगता है, और संभवतः एक खराब-optimized, बार-बार चलने वाली क्वेरी ने petabytes डेटा पढ़ लिया; फिर भी कई लोगों का कहना है कि Google का UI, कड़े spending caps की कमी, और अस्पष्ट cost indicators ऐसी गलतियों को बहुत आसान बनाते हैं। अन्य लोग जवाब देते हैं कि BigQuery की pricing और warnings दस्तावेज़ित हैं और उपयोगकर्ताओं की भी जिम्मेदारी है कि वे quotas सेट करें और billing समझें, तथा इस घटना को individuals और छोटे startups के लिए opaque, usage-based cloud pricing के व्यापक जोखिम के रूप में देखते हैं.

घटना का अवलोकन

  • एक उपयोगकर्ता ने BigQuery में HTTP Archive सार्वजनिक डेटासेट के विरुद्ध ऐतिहासिक क्वेरी चलाईं और लगभग 2 घंटे में ~$14k का शुल्क लग गया।
  • कार्यभार ने संभवतः कई बड़ी तालिकाओं को बार-बार full-scan किया (कुल मिलाकर कई पेटाबाइट्स स्कैन हुए), शायद कई महीनों/साइटों पर लूप के माध्यम से।
  • प्रारंभिक समर्थन ने कथित तौर पर बिल माफ करने से इनकार कर दिया; बाद में थ्रेड में उपयोगकर्ता ने कहा कि Google ने इसे हल करने में मदद शुरू की।

BigQuery की pricing कैसे काम करती है (थ्रेड के अनुसार)

  • सार्वजनिक डेटासेट के लिए storage Google द्वारा कवर किया जाता है; उपयोगकर्ता query processing के लिए भुगतान करते हैं।
  • On-demand BigQuery pricing स्कैन किए गए डेटा के प्रति TiB के हिसाब से होती है, साथ ही एक छोटा free tier भी होता है।
  • UI क्वेरी चलाने से पहले processed bytes का अनुमान दिखाता है, लेकिन इसे आसानी से नज़रअंदाज़ किया जा सकता है और यह डॉलर में नहीं, TB/PB में दिखता है।

जिम्मेदारी और दोष

  • एक पक्ष का तर्क है कि यह मुख्यतः उपयोगकर्ता की गलती है: BigQuery docs और HTTP Archive की “getting started” guide प्रति-byte billing और free-tier limits का उल्लेख करते हैं।
  • दूसरा पक्ष कहता है कि भले ही उपयोगकर्ता ने गलतियाँ कीं (जैसे SELECT *, LIKE फ़िल्टर, limits न लगाना, looped queries), लेकिन सिस्टम डिज़ाइन महँगी गलतियों को बहुत आसान बनाता है और पर्याप्त चेतावनी नहीं देता।

UI/UX और लागत की पारदर्शिता

  • कई टिप्पणियाँ BigQuery के “TBs scanned” abstraction और छोटे, कम प्रमुख cost indicators की आलोचना करती हैं; इन्हें user-hostile या “dark pattern”–जैसा माना गया।
  • कई लोग सुझाव देते हैं कि UI को स्पष्ट रूप से डॉलर का अनुमान दिखाना चाहिए और बहुत महंगी क्वेरियों के लिए blocking warning देनी चाहिए (जैसे, “इसकी लागत $14k हो सकती है – पुष्टि करें?”)।

Quotas, caps, और safeguards

  • BigQuery custom quotas का समर्थन करता है (जैसे प्रति क्वेरी/उपयोगकर्ता अधिकतम TB scanned) और project-level limits भी हैं, लेकिन वे स्पष्ट नहीं हैं और कड़े spend caps नहीं हैं।
  • GCP billing alerts और budget notifications मौजूद हैं, लेकिन वे देर से आते हैं और सख्त dollar ceiling की गारंटी नहीं दे सकते।
  • कई टिप्पणीकार true hard budget caps या prepaid models की माँग करते हैं, खासकर individuals, students, और hobbyists के लिए।

सलाह और विकल्प

  • व्यावहारिक सुझाव: बड़ी columnar tables पर SELECT * से बचें, partitions/clusters का उपयोग करें, पहले smaller tables में pre-filter करें, samples पर परीक्षण करें, और conservative quotas सेट करें।
  • कुछ लोग व्यक्तिगत cards को major clouds पर न इस्तेमाल करने, या LLCs, budget-capped providers, या self-hosted / open-source alternatives अपनाने की सलाह देते हैं।