این صفحه رابطهای مختلف موجود برای دسترسی به دادهها در یک پایگاه داده حالت بومی را توضیح میدهد.
رابطهای عملیاتی
حالت بومی از دو رابط برای دسترسی به دادهها پشتیبانی میکند:
عملیات خط لوله
رابط پرسوجوی جدیدتر برای Cloud Firestore . عملیات خط لوله از یک سینتکس قابل ترکیب مبتنی بر مرحله پشتیبانی میکند. شما با تعریف مجموعهای از مراحل متوالی که به ترتیب اجرا میشوند، یک عملیات را میسازید. این امر امکان عملیات پیچیدهای مانند فیلتر کردن نتیجه یک تجمیع را فراهم میکند، که قبلاً در رابط اصلی (عملیات اصلی) امکانپذیر نبود.
عملیات خط لوله فقط در نسخه Cloud Firestore Enterprise در دسترس است و در مرحله راهاندازی پیشنمایش قرار دارد.
عملیات اصلی
عملیات اصلی رابط اصلی Cloud Firestore هستند. عملیات اصلی از یک سینتکس زنجیرهای متد ( .where() ، .orderBy() ، .get() ) روی ارجاعات سند یا مجموعه برای بازیابی اسناد استفاده میکند. ترتیب مراحل پرسوجو ضمنی است و پشتیبانی از تجمیع محدود است.
عملیات اصلی در هر دو نسخه Enterprise و Standard موجود است، اما پیشفرضهای شاخص بین نسخهها بسیار متفاوت است. برای جزئیات بیشتر به بخش بعدی مراجعه کنید.
تفاوتهای رابط کاربری بین نسخهها
با معرفی پشتیبانی از حالت Native در نسخه Enterprise، هر دو عملیات Firestore Core و Pipeline در دسترس هستند. هنگام استفاده از عملیات Core در نسخه Enterprise، رفتار شاخص و مدل قیمتگذاری جدید، بسیاری از محدودیتهای نسخه Standard را حذف میکند.
| ویژگی | نسخه استاندارد | نسخه سازمانی |
| عملیات پرس و جو پشتیبانی شده | محدود به عملیات Firestore Core. | از عملیاتهای Firestore Core و Pipeline و Firestore با عملیاتهای سازگار با MongoDB پشتیبانی میکند. |
| الزامات نمایهسازی | همه پرس و جوها به فهرست نیاز دارند. | برای کوئریها نیازی به ایندکس نیست. |
| ایجاد فهرست | ایندکسهای خودکار برای فیلدهای تکی ایجاد میشوند. شما میتوانید ایندکسهای مرکب را به صورت دستی ایجاد کنید. | هیچ ایندکس خودکاری ایجاد نمیشود. ایندکسها باید به صورت دستی مدیریت شوند. |
| عملکرد و هزینه پرس و جو | پرسوجوها معمولاً به دلیل الزامات ایندکس، عملکرد خوبی دارند. | با ایجاد ایندکسها، عملکرد و هزینههای پرسوجو را بهینه کنید. میتوانید با استفاده از Query Explain و Query Insights، ایندکسهای از دست رفته را شناسایی کنید. پرسوجوهای بدون شاخص ممکن است با رشد مجموعه دادهها، ناکارآمد و پرهزینه باشند و نیاز به نظارت و تنظیم داشته باشند. |
| هزینه سربار نمایه سازی | برای نوشتن فهرست هزینهای دریافت نمیشود، زیرا فهرستها خودکار هستند. | نوشتن ورودیهای فهرست، هنگام نوشتن یک سند مرتبط، واحدهای نوشتن را مصرف میکند (1 واحد نوشتن به ازای هر 1 کیلوبایت از اندازه ورودی فهرست). با عدم ایجاد ورودیهای فهرست برای هر فیلد، در هزینههای ذخیرهسازی صرفهجویی میکنید. |
| مدل صورتحساب (خواندن/نوشتن/حذف) | هزینه به ازای خواندن، نوشتن و حذف سند محاسبه میشود. | هزینه به ازای خواندن و نوشتن (سهم) محاسبه میشود. هزینه خواندنها بر اساس واحدهای خواندن (سهم ۴ کیلوبایتی) محاسبه میشود. هزینه نوشتنها و حذفها در واحدهای نوشتن (سهم ۱ کیلوبایتی) ادغام میشوند. |
| قیمت پایه (به ازای هر میلیون) قیمتهای نشان داده شده برای منطقه مرکزی ایالات متحده است. | هزینه مطالعه: 0.03 دلار به ازای هر 100000 سند (یا 0.30 دلار به ازای هر میلیون سند). هزینه نوشتن: 0.09 دلار برای هر 100000 سند (یا 0.90 دلار برای هر میلیون سند). حذفها: ۰.۰۱ دلار به ازای هر ۱۰۰۰۰۰ سند (یا ۰.۱۰ دلار به ازای هر میلیون سند) | واحدهای خوانده شده: 0.05 دلار به ازای هر 1 میلیون واحد خوانده شده. واحدهای نوشتن: ۰.۲۶ دلار به ازای هر ۱ میلیون واحد نوشتن. اگر حجم اسناد کمتر از ۴ کیلوبایت باشد، قیمتها معمولاً در مقایسه با هزینه استاندارد خواندن، پایینتر هستند. |
| بهروزرسانیهای بلادرنگ قیمتهای نشان داده شده برای منطقه us-central1 است | بهروزرسانیهای بلادرنگ (Realtime ) به عنوان خوانده شده (Reads) با قیمت ۰.۰۳ دلار برای هر ۱۰۰۰۰۰ سند ارائه میشوند. | بهروزرسانیهای بیدرنگ دارای یک SKU (واحدهای بهروزرسانی بیدرنگ) جداگانه هستند که به ازای هر ۴ کیلوبایت هزینه دریافت میکنند. بهروزرسانیهای بیدرنگ به ازای هر میلیون واحد خوانده شده، ۰.۳۰ دلار هزینه دارند. |