Firebase Firestore — چیست، اسناد و مجموعه‌های NoSQL

Firebase Firestore چیست

Firebase Firestore — یک پایگاه داده ابری NoSQL است که توسط Google در سال 2019 به عنوان جانشین Realtime Database منتشر شد. Firestore بر روی زیرساخت Google Cloud Spanner و Google Cloud Datastore ساخته شده است و سازگاری دقیق داده‌ها را در یک تراکنش و تکرار خودکار چندمنطقه‌ای فراهم می‌کند. SDK از Android، iOS، Web (JavaScript)، Flutter، Kotlin Multiplatform و Unity پشتیبانی می‌کند.

تکامل از Realtime Database

Firestore در Google I/O 2017 با نام «Cloud Firestore» معرفی شد — راه‌حلی که محدودیت‌های کلیدی Realtime Database را برطرف می‌کند: عدم پشتیبانی از پرس‌وجوهای پیچیده، عدم امکان مقیاس‌پذیری داده‌ها در چند گره و سازگاری ضعیف. طبق داده‌های Google (2026)، Firestore روزانه بیش از 1 تریلیون پرس‌وجو پردازش می‌کند و پایگاه داده پیش‌فرض برای 80% پروژه‌های جدید Firebase است. با این حال، Realtime Database به دلیل ساختار ساده JSON برای سناریوهای با تأخیر بسیار کم (بازی‌ها، ویرایش مشترک) همچنان مرتبط است.

محدودیت‌های رایگان Firestore

Firestore با مدل pay-as-you-go با محدودیت رایگان سخاوتمندانه در تعرفه Spark ارائه می‌شود: 1 گیگابایت ذخیره‌سازی، 10 گیگابایت ترافیک شبکه در ماه، 50 هزار عملیات خواندن، 20 هزار عملیات نوشتن و 20 هزار عملیات حذف در روز. در تعرفه Blaze همه موارد مشابه رایگان است و مازاد تعرفه‌گذاری می‌شود: 0.06 دلار به ازای 100 هزار عملیات خواندن، 0.18 دلار به ازای 100 هزار عملیات نوشتن. طبق داده‌های Google (2026)، 90% پروژه‌ها از محدودیت رایگان فراتر نمی‌روند.

مدل داده: مجموعه‌ها، اسناد و فیلدها

مدل داده Firestore به صورت سلسله‌مراتبی سازماندهی شده است: ریشه شامل مجموعه‌ها، هر مجموعه شامل اسناد، هر سند شامل فیلدها (انواع اولیه، آرایه‌ها، Map) و مجموعه‌های تودرتو (subcollections) است. عمق تودرتویی مجموعه‌ها محدود نیست، اما یک سند نمی‌تواند مستقیماً سند دیگری را شامل شود — فقط از طریق ارجاع (Reference type).

مجموعه‌ها و اسناد

مجموعه — ظرفی برای اسناد با شناسه‌های خودکار تولید شده یا تعیین شده است. هر سند یک شیء شبیه JSON با اندازه حداکثر 1 MiB است. فیلدهای سند می‌توانند رشته‌ها، اعداد، مقادیر بولی، آرایه‌ها، Map، مهرهای زمانی (Timestamp)، نقاط جغرافیایی (GeoPoint) و ارجاع به اسناد دیگر (Reference) باشند. اندازه سند با احتساب نام همه فیلدها به 1 MiB محدود شده است.

نوشتن دسته‌ای و تراکنش‌ها

Firestore از تراکنش‌های اتمی در سطح پایگاه داده پشتیبانی می‌کند. تراکنش می‌تواند چندین سند را بخواند و بنویسد — Commit به صورت اتمی همه تغییرات را اعمال می‌کند یا هیچکدام. حداکثر 500 عملیات در یک تراکنش، مهلت 60 ثانیه. نوشتن دسته‌ای (batch write) یک عملیات اتمی غیرتراکنشی روی نوشتن بدون مرحله خواندن است. تراکنش‌ها برای عملیات مالی، رزرو مکان و موجودی انبار حیاتی هستند.

مقایسه Firestore و Realtime Database

انتخاب بین Firestore و Realtime Database به نیازهای پروژه بستگی دارد. هر دو پایگاه داده بخشی از اکوسیستم Firebase هستند، همگام‌سازی در زمان واقعی ارائه می‌دهند و در همه پلتفرم‌ها در دسترس هستند، اما در مدل داده، مقیاس‌پذیری و قیمت‌گذاری تفاوت اساسی دارند.

تفاوت‌های کلیدی

Realtime Database داده‌ها را در یک درخت JSON واحد ذخیره می‌کند که برای ساختارهای ساده مناسب است اما مقیاس‌پذیری را در تودرتویی عمیق‌تر از 3 سطح دشوار می‌کند. Firestore از مدل مجموعه-سند با شرط‌بندی خودکار استفاده می‌کند که امکان مقیاس‌پذیری تا میلیون‌ها سند بدون کاهش عملکرد را فراهم می‌کند. طبق داده‌های Google (2026)، Firestore تا 10 هزار اتصال همزمان به یک مجموعه را بدون کاهش سرعت پشتیبانی می‌کند، Realtime Database — تا 200 هزار اتصال به یک نمونه.

قیمت‌گذاری

Realtime Database بر اساس حجم داده‌های منتقل شده (بایت‌های دانلودی) و تعداد اتصالات همزمان تعرفه‌گذاری می‌شود. Firestore — بر اساس تعداد عملیات (خواندن، نوشتن، حذف). برای برنامه‌هایی با به‌روزرسانی‌های کوچک مکرر (چت، اعلان‌ها) Firestore معمولاً مقرون‌به‌صرفه‌تر است — هر عملیات نوشتن بدون توجه به اندازه داده قیمت ثابتی دارد. برای برنامه‌هایی با خواندن نادر حجم زیاد داده، Realtime Database ممکن است ارزان‌تر باشد.

توصیه Google (2026): از Firestore به عنوان پایگاه داده پیش‌فرض برای پروژه‌های جدید استفاده کنید و از Realtime Database برای بازی‌ها و برنامه‌هایی که تأخیر حداقلی (کمتر از 50 میلی‌ثانیه) حیاتی است و ساختار داده مسطح است. هر دو پایگاه داده می‌توانند همزمان در یک پروژه کار کنند.

پرس‌وجوها، ایندکس‌ها و صفحه‌بندی در Firestore

پرس‌وجوهای Firestore بر روی مجموعه‌ها یا گروه‌های مجموعه با فیلتر، مرتب‌سازی و محدودیت اجرا می‌شوند. برخلاف Realtime Database که هر پرس‌وجو پیمایش کل درخت JSON با فیلتر در سمت کلاینت است، Firestore همه پرس‌وجوها را روی سرور با استفاده از ایندکس‌های از پیش ساخته شده اجرا می‌کند. این تضمین می‌کند که پیچیدگی پرس‌وجو فقط به اندازه نتیجه بستگی دارد، نه به اندازه مجموعه.

انواع پرس‌وجوها

Firestore پشتیبانی می‌کند فیلتر بر اساس یک یا چند فیلد (equality, range, in, array-contains, array-contains-any)، مرتب‌سازی صعودی و نزولی، محدودیت و نشانگرها برای صفحه‌بندی. محدودیت‌ها: پرس‌وجوهای ترکیبی با فیلتر بر اساس فیلدهای مختلف (where price > 10 AND where category == «books») نیاز به ایندکس ترکیبی دارند. پرس‌وجوهای OR ممنوع هستند (به جای آن از in و array-contains-any استفاده می‌شود) و پرس‌وجوهای با نابرابری در فیلدهای مختلف ممنوع هستند.

data class Product(
    val name: String = "",
    val category: String = "",
    val price: Double = 0.0,
    val inStock: Boolean = false
)

suspend fun FirestoreRepository.queryProducts(): List<Product> {
    return firestore
        .collection("products")
        .whereEqualTo("category", "electronics")
        .whereGreaterThanOrEqualTo("price", 100.0)
        .whereLessThan("price", 500.0)
        .orderBy("price")
        .limit(20)
        .get()
        .await()
        .toObjects(Product::class.java)
}

ایندکس‌های خودکار و ترکیبی

Firestore به طور خودکار برای فیلدهای تکی ایندکس ایجاد می‌کند — پرس‌وجوهای بر اساس یک فیلد بدون هیچ تنظیماتی کار می‌کنند. برای پرس‌وجوهای با دو یا چند فیلد (فیلتر + مرتب‌سازی) ایندکس‌های ترکیبی ایجاد می‌شوند. هنگام اولین ارسال پرس‌وجو، Firestore خطایی با پیوند به کنسول برمی‌گرداند که در آن می‌توان ایندکس را با یک کلیک ایجاد کرد. حداکثر 200 ایندکس ترکیبی برای هر پایگاه داده. ایندکس‌ها را می‌توان از طریق firebase CLI صادر و وارد کرد.

ادغام Firestore در Android

اتصال Firestore به برنامه Android به صورت استاندارد از طریق Firebase BOM انجام می‌شود. پس از افزودن وابستگی firebase-firestore-ktx، شیء FirebaseFirestore از طریق getInstance() در دسترس است — بدون کلید یا توکن اضافی. Firestore از همان پروژه Firebase سایر سرویس‌ها استفاده می‌کند.

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-firestore-ktx")
}

// راه‌اندازی
val db = FirebaseFirestore.getInstance()

خواندن و نوشتن داده‌ها

Firestore دو حالت خواندن ارائه می‌دهد: یک‌باره (get) و در زمان واقعی (addSnapshotListener). خواندن یک‌باره سند را یک بار دریافت می‌کند — برای تنظیمات و پیکربندی مفید است. شنونده روی تغییرات مشترک می‌شود — هر به‌روزرسانی سند به طور خودکار داده‌های به‌روز شده را به همه کلاینت‌های متصل در زمان واقعی تحویل می‌دهد. set() یک سند ایجاد یا بازنویسی می‌کند، update() فقط فیلدهای مشخص شده را بدون بازنویسی کل سند تغییر می‌دهد.

طبق داده‌های Google (2026)، برنامه‌های با اندازه متوسط (100 هزار DAU) با Firestore در زمان واقعی حدود 5-10 گیگابایت ترافیک خروجی در ماه مصرف می‌کنند. استفاده از حافظه نهان آفلاین (Persistence Cache) حجم بارگیری‌های تکراری را 60-70% کاهش می‌دهد، زیرا SDK فقط اسناد تغییر یافته را هنگام بازیابی اتصال بارگیری می‌کند.

حالت آفلاین

Persistence Cache — مکانیزم داخلی Firestore برای کار بدون اینترنت است. SDK به طور خودکار همه اسناد خوانده شده را روی دستگاه ذخیره می‌کند (تا 500 MiB در Android). هنگام قطع اتصال، خواندن از حافظه نهان ادامه می‌یابد، نوشتن در صف قرار می‌گیرد. هنگام بازیابی اتصال، همه عملیات به تعویق افتاده به سرور ارسال می‌شوند و حافظه نهان با سرور همگام‌سازی می‌شود. برای کنترل تعارضات از snapshot-metadata.hasPendingWrites و setOptions(ServerTimestampBehavior) استفاده می‌شود.

قوانین امنیتی و اعتبارسنجی داده‌ها

Security Rules — یک زبان اعلامی برای محدودسازی دسترسی به Firestore است که روی سرور Google قبل از هر عملیات خواندن یا نوشتن اجرا می‌شود. Rules نیازی به کد سرور ندارند — در کنسول Firebase یا از طریق firebase CLI نوشته می‌شوند و از طریق Git نسخه‌بندی می‌شوند. هر عملیات از نظر مطابقت با قوانین بررسی می‌شود و در صورت نقض، خطای PERMISSION_DENIED برگردانده می‌شود.

ساختار قوانین

قوانین Firestore Security Rules از بلوک‌های match و عبارات allow تشکیل شده‌اند. match مسیر مجموعه یا سند را مشخص می‌کند، allow عملیات مجاز (read, write, create, update, delete) و شرط — عبارتی شبیه JavaScript که مقدار بولی برمی‌گرداند — را تعیین می‌کند. قوانین می‌توانند احراز هویت (request.auth)، داده‌های درخواست (request.resource.data)، داده‌های موجود (resource.data)، زمان (request.time) و مسیر (request.path) را بررسی کنند.

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth.uid == userId;
    }

    match /products/{productId} {
      allow read: if true;
      allow create: if request.auth.token.role == "admin";
      allow update: if resource.data.authorId == request.auth.uid;
    }
  }
}

اعتبارسنجی داده‌ها

Security Rules از اعتبارسنجی انواع و مقادیر در سمت سرور پشتیبانی می‌کند. می‌توان نوشتن را در صورتی که قیمت منفی یا نام خالی باشد، ممنوع کرد. همه بررسی‌ها روی سرور Google قبل از نوشتن انجام می‌شوند — این سازگاری داده‌ها را بدون توجه به کلاینت (Android, iOS, Web, Admin SDK) تضمین می‌کند. Rules از Admin SDK مخرب محافظت نمی‌کند — طبق تعریف از قوانین عبور می‌کند. برای حفاظت کامل از Transaction Functions و Firebase Extensions استفاده کنید.