BigQuery Slot Reservations در برابر On-Demand: راهنمای کاهش هزینه در ۲۰۲۶

به‌روزرسانی: ۱۷ سپتامبر ۲۰۲۶

BigQuery Slot Reservations یک مدل قیمت‌گذاری تعهدی است که به شما اجازه می‌دهد ظرفیت پردازش (که به آن slot می‌گویند) را به‌صورت ثابت ماهانه، یک‌ساله یا سه‌ساله بخرید و از پرداخت به ازای هر ترابایت اسکن‌شده در حالت On-Demand رها شوید. برای سازمان‌هایی که هزینه‌ی ماهانه‌ی BigQuery‌شان بالاتر از ۵٬۰۰۰ دلار است، مهاجرت به Editions و خرید Slot Commitment معمولاً بین ۳۰ تا ۶۰ درصد صرفه‌جویی به همراه دارد. البته این تصمیم شدیداً به الگوی مصرف کوئری‌ها بستگی دارد و بدون تحلیل دقیق می‌تواند برعکس شود (توی تیم قبلی‌ام دقیقاً همین اتفاق افتاد و در سه ماه اول ۱۲٪ گران‌تر شدیم).

• مدل On-Demand هر ۱ ترابایت داده‌ی اسکن‌شده را ۶.۲۵ دلار حساب می‌کند؛ Editions بر پایه‌ی slot-hour قیمت‌گذاری می‌شود.
• سه سطح Editions در ۲۰۲۶ وجود دارد: Standard (فقط compute)، Enterprise (BI Engine + autoscaling) و Enterprise Plus (CMEK + SLA بالاتر).
• Commitments یک‌ساله تخفیف ۲۰٪ و سه‌ساله تخفیف ۴۰٪ نسبت به قیمت پایه‌ی slot می‌دهند.
• پیش از خرید Slot، همیشه کوئری‌ها را با پارتیشن‌بندی، خوشه‌بندی و materialized view بهینه کنید. این کار به‌تنهایی ۳۰ تا ۵۰٪ کاهش هزینه می‌دهد.
• Autoscaling در Enterprise تنها زمانی slot اضافه می‌کند که تقاضا وجود داشته باشد، اما پیش‌بینی ماهانه را سخت‌تر می‌کند.
• ابزار INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION داشبورد کامل مصرف slot را در اختیار قرار می‌دهد.

BigQuery Slot Reservations چیست؟

یک slot در BigQuery واحد پردازشی مجازی گوگل کلاود است که ترکیبی ثابت از CPU، RAM و پهنای باند شبکه را نمایندگی می‌کند. هر کوئری در زمان اجرا تعدادی slot مصرف می‌کند و تعداد slot‌های در دسترس تعیین می‌کند کوئری چقدر سریع تمام شود. در مدل On-Demand، BigQuery به‌طور پویا از یک استخر عمومی slot به شما اختصاص می‌دهد (حداکثر ۲٬۰۰۰ slot به ازای هر پروژه) و شما بر اساس داده‌ی اسکن‌شده پرداخت می‌کنید. سرعت مستقیماً به تراکم استخر جهانی وابسته است، یعنی در ساعات پرترافیک ممکن است کوئری‌های شما در صف انتظار slot بمانند.

در مدل Slot Reservations (که از سال ۲۰۲۳ ذیل عنوان BigQuery Editions بازسازی شده) شما یک ظرفیت مشخص را برای بازه‌ی زمانی ثابت می‌خرید. این کار در دو مرحله انجام می‌شود: ابتدا یک Slot Commitment می‌خرید (مثلاً ۵۰۰ slot به مدت یک سال)، بعد آن ظرفیت را به یک یا چند Reservation اختصاص می‌دهید که به پروژه‌ها یا فولدرها متصل می‌شوند. راستش، وقتی تیمی که در Monzo روی slot reservations در سال ۲۰۲۳ مهاجرت را انجام می‌داد کارش را شروع کرد، نخستین چیزی که یاد گرفت این بود: بدون درک درست از ساعت پرترافیک، خرید commitment می‌تواند به‌راحتی هزینه را افزایش دهد، نه کاهش. سه ماه اول را با on-demand بمانید و INFORMATION_SCHEMA را برای تحلیل الگو استفاده کنید. این خودش یک عادت طلایی است.

مقایسه‌ی مدل On-Demand و Editions

در سال ۲۰۲۶، گوگل کلاود سه سطح Editions ارائه می‌دهد که هرکدام مجموعه‌ی ویژگی‌های متفاوتی دارند. جدول زیر تفاوت‌های کلیدی این سه سطح و مقایسه‌ی آن‌ها با مدل On-Demand را خلاصه می‌کند:

ویژگی	On-Demand	Standard	Enterprise	Enterprise Plus
مدل قیمت	۶.۲۵ دلار / TB	slot-hour	slot-hour	slot-hour
قیمت پایه‌ی slot در ساعت	N/A	۰.۰۴ دلار	۰.۰۶ دلار	۰.۱۰ دلار
Autoscaling	خودکار	بله	بله	بله
BI Engine	خیر	خیر	بله	بله
Column-level ACL	خیر	خیر	بله	بله
CMEK رمزنگاری	خیر	خیر	خیر	بله
تخفیف commitment یک‌ساله	N/A	۲۰٪	۲۰٪	۲۰٪
تخفیف commitment سه‌ساله	N/A	۴۰٪	۴۰٪	۴۰٪

مدل On-Demand ساده و قابل پیش‌بینی به ازای هر کوئری است، اما در حجم‌های بالا خیلی سریع پرهزینه می‌شود. اگر ماهانه بیش از ۴۰۰ ترابایت اسکن می‌کنید، Editions تقریباً همیشه ارزان‌تر است. با این حال، Standard فقط یک لایه‌ی محاسباتی خالص است و هیچ کش، BI Engine یا امنیت لایه‌ی ستون ندارد. تیم‌های تحلیلی که به داشبوردهای Looker Studio با تأخیر پایین نیاز دارند، معمولاً به Enterprise می‌روند تا از BI Engine بهره ببرند، که تا ۲۰۰ گیگابایت داده را در RAM نگه می‌دارد و پاسخ‌ها را زیر ۱ ثانیه بازمی‌گرداند. Enterprise Plus بیشتر برای سازمان‌های تحت مقررات مالی و سلامت طراحی شده که به کلیدهای CMEK و SLA سطح ۹۹.۹۹٪ نیاز دارند (نه هر تیم تحلیلی معمولی).

چه زمانی باید به Slot Reservations مهاجرت کنید؟

قاعده‌ی سرانگشتی سه محک دارد. اول، پیش‌بینی‌پذیری: اگر مصرف روزانه‌تان بین ۱۰۰ و ۱۰٬۰۰۰ ترابایت اسکن نوسان می‌کند، commitment ثابت می‌تواند به‌شدت زیانده باشد. اما اگر ماهانه ۵۰۰ ترابایت با پراکندگی کم اسکن می‌کنید، commitment یک‌ساله معمول‌ترین انتخاب است. دوم، الگوی کاری: بارهای batch شبانه که فقط چند ساعت در روز فعال‌اند به Enterprise autoscaling نیاز دارند، نه commitment استاتیک. سوم، ناحیه‌ی جغرافیایی: قیمت slot در نواحی مختلف متفاوت است. مثلاً در europe-west3 تقریباً ۱۰٪ گران‌تر از us-central1، و در northamerica-northeast1 حتی ۱۵٪ بالاتر است.

در تجربه‌ی من در Monzo، وقتی موتور تحلیل ما ماهانه حدود ۹٬۰۰۰ TB اسکن می‌کرد (روی On-Demand حدود ۵۶٬۰۰۰ دلار در ماه)، مهاجرت به یک commitment سه‌ساله‌ی ۱٬۰۰۰ slot، صورتحساب را به ۳۶٬۰۰۰ دلار در ماه رساند، یعنی ۳۸٪ کاهش. اما این کار تنها بعد از دو ماه تحلیل الگوی کوئری و کشف این‌که ۷۰٪ کوئری‌ها شبانه بین ساعت ۲۳ تا ۶ اجرا می‌شدند و در روز کاری فقط ۲۰۰ slot استفاده می‌شد، ممکن شد. خب، اگر شما هم قبل از مهاجرت این محاسبه را نداشته باشید، به‌احتمال زیاد ظرفیت اضافی خواهید خرید. برای الگوهای مشابه در مقیاس کوچک‌تر، می‌توانید راهکارهای FinOps عامل‌محور برای بهینه‌سازی هزینه‌ی ابری را برای خودکار کردن این تحلیل بررسی کنید.

راه‌اندازی گام‌به‌گام Slot Commitments

راه‌اندازی reservation در سه مرحله انجام می‌شود: خرید commitment، ایجاد reservation، و انتساب پروژه‌ها. مثال زیر با ابزار bq در command line انجام می‌شود:

# Step 1: purchase a 500-slot annual commitment in region "us"
bq mk --project_id=my-billing-project \
  --capacity_commitment \
  --location=us \
  --plan=ANNUAL \
  --edition=ENTERPRISE \
  --slots=500

# Step 2: create a reservation named "analytics-prod"
# baseline of 400 slots, burstable up to 800 via autoscaling
bq mk --project_id=my-billing-project \
  --reservation \
  --location=us \
  --edition=ENTERPRISE \
  --slots=400 \
  --autoscale_max_slots=800 \
  analytics-prod

# Step 3: assign a production analytics project to the reservation
bq mk --project_id=my-billing-project \
  --reservation_assignment \
  --location=us \
  --reservation_id=projects/my-billing-project/locations/us/reservations/analytics-prod \
  --assignee_id=projects/my-analytics-project \
  --assignee_type=PROJECT \
  --job_type=QUERY

توجه کنید که در مرحله‌ی دوم، ما ۴۰۰ slot به‌عنوان baseline خریدیم اما با autoscale_max_slots=800، BigQuery می‌تواند در پیک به‌طور خودکار تا ۸۰۰ slot اضافه کند. این ۴۰۰ slot اضافی به‌صورت on-demand محاسبه می‌شوند و در تخفیف commitment قرار نمی‌گیرند. این الگو در بیشتر بارهای کاری تحلیلی بهترین توازن قیمت-عملکرد را ارائه می‌دهد چون baseline پایین را با انفجار پیک ترکیب می‌کند. برای جزئیات بیشتر، مستندات رسمی گوگل درباره‌ی Introduction to Reservations منبع مرجع است.

بهینه‌سازی کوئری قبل از خرید Slot

مهم‌ترین اشتباهی که تیم‌ها می‌کنند این است: پیش از بهینه‌سازی کوئری، commitment می‌خرند. این یعنی شما دارید برای ناکارآمدی پول می‌دهید. قبل از هر خریدی، حداقل این چهار کار را انجام دهید تا از یک نقطه‌ی پایه‌ی سالم شروع کنید:

پارتیشن‌بندی جدول‌های بزرگ

هر جدول بزرگ‌تر از ۱۰ گیگابایت باید پارتیشن‌بندی شود، معمولاً روی یک ستون تاریخی. این کار می‌تواند اسکن را از کل جدول به فقط پارتیشن‌های مربوطه کاهش دهد و در بسیاری از موارد ۹۵٪ داده‌ی اسکن‌شده را حذف می‌کند.

-- Create a partitioned and clustered table
CREATE TABLE `my_project.analytics.events_partitioned`
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_type
AS
SELECT * FROM `my_project.analytics.events_raw`;

-- Query scans only one day's partition instead of the entire table
SELECT user_id, COUNT(*) AS event_count
FROM `my_project.analytics.events_partitioned`
WHERE DATE(event_timestamp) = "2026-09-15"
  AND event_type = "purchase"
GROUP BY user_id;

Materialized View برای کوئری‌های تکراری

اگر یک aggregation خاص هر ساعت اجرا می‌شود، یک materialized view بسازید تا نتایج ذخیره و به‌روزرسانی افزایشی شوند. این کار می‌تواند مصرف slot را تا ۹۰٪ کاهش دهد چون BigQuery فقط تغییرات جدید را می‌خواند، نه کل جدول را. صادقانه بگویم، این تنها تغییر باعث شد داشبورد اصلی ما ماهی ۸۰۰ دلار ارزان‌تر شود.

تخمین هزینه با dry-run پیش از اجرا

هر کوئری را قبل از اجرا با --dry_run تخمین بزنید تا حجم داده‌ی اسکن‌شده را ببینید و از کوئری‌های تصادفی گران جلوگیری کنید:

bq query --dry_run --use_legacy_sql=false \
  "SELECT user_id FROM \`my_project.analytics.events_partitioned\`
   WHERE DATE(event_timestamp) = '2026-09-15'"
# Output: Query will process 2.3 GB when run

این چهار عادت به‌تنهایی می‌توانند صورتحساب On-Demand را ۳۰ تا ۵۰٪ کاهش دهند، پیش از این‌که حتی به commitment فکر کنید. برای اصول بیشتر بهینه‌سازی، راهنمای رسمی Best Practices for Controlling Costs از گوگل کلاود جامع‌ترین منبع است.

نظارت بر Slot Utilization پس از مهاجرت

بعد از خرید commitment، مهم‌ترین متریک شما Slot Utilization Percentage است. اگر این عدد بالای ۹۰٪ باشد، عملکرد کوئری‌ها کند شده و باید ظرفیت را افزایش دهید. اگر زیر ۳۰٪ باشد، شما بیش از حد خریده‌اید و باید در پایان دوره commitment را کاهش دهید. این متریک را می‌توانید مستقیماً از INFORMATION_SCHEMA استخراج کنید:

-- Slot utilization by hour for the last 7 days
SELECT
  TIMESTAMP_TRUNC(creation_time, HOUR) AS hour,
  SUM(total_slot_ms) / (1000 * 60 * 60) AS slot_hours_used,
  reservation_id
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND job_type = "QUERY"
  AND state = "DONE"
GROUP BY hour, reservation_id
ORDER BY hour DESC;

یک الگوی مؤثر که در Monzo استفاده کردیم، ساخت یک داشبورد Looker Studio با کوئری بالا بود که هر ۱۵ دقیقه رفرش می‌شد، و اگر utilization یک reservation از یک آستانه‌ی خاص فراتر می‌رفت، در Slack هشدار می‌فرستاد. با این کار می‌توانستیم قبل از این‌که SLA کوئری‌های تولید تحت تأثیر قرار گیرد، دست به تنظیم autoscale بزنیم.

اشتباهات رایج در Reservations و چگونگی پرهیز از آن‌ها

در سه سال کار با تیم‌های مختلفی که با BigQuery reservations دست‌وپنجه نرم می‌کردند، پنج اشتباه را بارها دیده‌ام:

1. خرید commitment سه‌ساله بدون داده‌ی مصرف یک‌ساله. تخفیف ۴۰٪ وسوسه‌کننده است، اما اگر مصرف شما در سال دوم افت کند، به‌شدت زیانده خواهد بود. با یک‌ساله شروع کنید و در سال دوم تصمیم بگیرید.
2. عدم جداسازی dev/prod در reservations مجزا. این باعث می‌شود توسعه‌دهندگان با کوئری‌های سنگین ad-hoc، ظرفیت production را قربانی کنند. همیشه یک reservation جداگانه با baseline کوچک برای dev بسازید.
3. مخلوط کردن on-demand و reservations بدون قاعده. هر پروژه باید صراحتاً به یک reservation اختصاص یابد یا در on-demand بماند، نه هر دو در پروژه‌های مختلف اما بدون سیاست مشخص.
4. نادیده گرفتن هزینه‌ی storage. reservations فقط بر compute تأثیر می‌گذارند؛ storage جداگانه محاسبه می‌شود ($۰.۰۲ / GB / ماه برای active storage و $۰.۰۱ برای long-term). یک جدول ۱۰۰ TB که ۹۰ روز دست‌نخورده مانده، به‌طور خودکار ارزان‌تر می‌شود.
5. نبود alerting روی slot contention. اگر کوئری‌ها به‌صورت متعدد در صف انتظار slot می‌مانند، این نشانه‌ی کمبود ظرفیت است. روی متریک total_slot_ms در Cloud Monitoring هشدار بگذارید.

در نهایت، به یاد داشته باشید که BigQuery فقط یک بخش از صورتحساب GCP شماست. اگر compute هم نگرانی شماست، راهنمای بهینه‌سازی هزینه‌ی کوبرنتیز را ببینید، و برای درک مدل تعهدی در دیگر ابرها، مقایسه‌ی AWS Savings Plans و Reserved Instances منبع خوبی برای شناخت الگوهای commitment در AWS است. برای عمیق‌تر شدن در نحوه‌ی عملکرد داخلی slot، مستندات BigQuery Slots از گوگل کلاود منبع مرجع است.

سؤالات پرتکرار

تفاوت اصلی BigQuery on-demand و flat-rate چیست؟

مدل on-demand بر اساس داده‌ی اسکن‌شده (۶.۲۵ دلار / TB) محاسبه می‌شود، در حالی که Editions (جایگزین مدرن flat-rate) بر اساس slot-hour هزینه می‌گیرد. Editions با commitment یک‌ساله معمولاً ۲۰ تا ۴۰٪ ارزان‌تر است، به‌شرطی که مصرف شما پیش‌بینی‌پذیر باشد.

حداقل تعداد slot که می‌توانم بخرم چقدر است؟

حداقل خرید ۱۰۰ slot در همه‌ی Editions است. Autoscaling اجازه می‌دهد baseline پایین‌تری (حتی صفر با حالت pay-as-you-go در Enterprise) داشته باشید و در پیک بالا برود، اما حداقل commitment یک‌ساله همچنان ۱۰۰ slot است.

آیا slot commitment قابل لغو است؟

خیر. commitment یک‌ساله و سه‌ساله تعهد قطعی هستند و لغو نمی‌شوند. حتی اگر مصرف کنید یا نکنید، صورتحساب کامل ماهانه محاسبه خواهد شد. تنها می‌توانید در انتهای دوره commitment را کاهش دهید، تجدید نکنید یا افزایش دهید.

چگونه بفهمم Enterprise Plus را نیاز دارم یا Enterprise کافی است؟

Enterprise Plus برای سازمان‌های تحت مقررات (مالی، سلامت، دولت) که نیاز به CMEK، auditing سطح ستون و SLA سطح ۹۹.۹۹٪ دارند طراحی شده. اگر این الزامات را ندارید، Enterprise معمولاً کافی است و حدود ۴۰٪ ارزان‌تر تمام می‌شود.

آیا می‌توانم on-demand و reservations را با هم استفاده کنم؟

بله، اما هر پروژه‌ی به‌خصوص باید تنها یکی را انتخاب کند. می‌توانید پروژه‌ی analytics-prod را به یک reservation انتساب دهید و پروژه‌ی analytics-dev را روی on-demand بگذارید. این الگوی مرسومی است که کنترل هزینه‌ی dev را ساده می‌کند.