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 Spark پلان پر فراخدلانہ مفت حد کے ساتھ ادائیگی کے مطابق ماڈل پر پیش کیا جاتا ہے: 1 GB اسٹوریج، ماہانہ 10 GB نیٹ ورک ٹریفک، روزانہ 50 ہزار پڑھنے کے آپریشنز، 20 ہزار لکھنے کے آپریشنز اور 20 ہزار حذف کرنے کے آپریشنز۔ Blaze پلان پر، مذکورہ بالا سب کچھ مفت ہے اور اضافی استعمال پر چارج کیا جاتا ہے: $0.06 فی 100 ہزار پڑھنے کے آپریشنز، $0.18 فی 100 ہزار لکھنے کے آپریشنز۔ Google (2026) کے مطابق، 90% پروجیکٹس مفت حد کے اندر رہتے ہیں۔

ڈیٹا ماڈل: مجموعے، دستاویزات اور فیلڈز

Firestore کا ڈیٹا ماڈل درجہ بندی کے لحاظ سے ترتیب دیا گیا ہے: جڑ میں مجموعے ہوتے ہیں، ہر مجموعے میں دستاویزات ہوتی ہیں، ہر دستاویز میں فیلڈز (ابتدائی اقسام، صفیں، Map) اور نیسٹڈ مجموعے (ذیلی مجموعے) ہوتے ہیں۔ مجموعوں کی نیسٹنگ گہرائی لامحدود ہے، لیکن ایک دستاویز براہ راست دوسری دستاویز پر مشتمل نہیں ہو سکتی — صرف حوالہ (Reference قسم) کے ذریعے۔

مجموعے اور دستاویزات

مجموعہ خودکار طور پر پیدا کردہ یا صارف کے متعین کردہ شناخت کنندگان کے ساتھ دستاویزات کا ایک کنٹینر ہے۔ ہر دستاویز 1 MiB سائز تک کی JSON نما آبجیکٹ ہے۔ دستاویز کے فیلڈز سٹرنگز، اعداد، بولین ویلیوز، صفیں، 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 ms سے کم) اور فلیٹ ڈیٹا ساخت اہم ہے۔ دونوں ڈیٹا بیسز ایک ہی پروجیکٹ میں بیک وقت کام کر سکتے ہیں۔

Firestore میں سوالات، انڈیکس اور پیجینیشن

Firestore سوالات فلٹرنگ، ترتیب اور حدود کے ساتھ مجموعوں یا مجموعہ گروپوں پر عمل کیے جاتے ہیں۔ Realtime Database کے برعکس، جہاں ہر سوال کلائنٹ سائڈ فلٹرنگ کے ساتھ پورے JSON درخت کو گھومتا ہے، Firestore پہلے سے بنائے گئے انڈیکس کا استعمال کرتے ہوئے سرور پر تمام سوالات پر عمل کرتا ہے۔ یہ ضمانت دیتا ہے کہ سوال کی پیچیدگی صرف نتیجہ کے سائز پر منحصر ہے، مجموعہ کے سائز پر نہیں۔

سوالات کی اقسام

Firestore ایک یا متعدد فیلڈز کے ذریعے فلٹرنگ (مساوات، رینج، 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 کے ذریعے ایکسپورٹ اور امپورٹ کیا جا سکتا ہے۔

Android میں Firestore کا انضمام

Android ایپ میں Firestore کو جوڑنا 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) کے مطابق، ریئل ٹائم Firestore والی درمیانے سائز کی ایپلیکیشنز (100 ہزار DAU) ماہانہ تقریباً 5-10 GB آؤٹ گوئنگ ٹریفک استعمال کرتی ہیں۔ آف لائن کیش (Persistence Cache) کا استعمال بار بار ڈاؤن لوڈز کو 60-70% کم کرتا ہے، کیونکہ SDK کنکشن بحال ہونے پر صرف تبدیل شدہ دستاویزات لوڈ کرتا ہے۔

آف لائن موڈ

Persistence Cache انٹرنیٹ تک رسائی کے بغیر کام کرنے کے لیے Firestore کا ایک بلٹ ان میکانزم ہے۔ SDK پڑھی گئی تمام دستاویزات کو ڈیوائس پر خود بخود کیش کرتا ہے (Android پر 500 MiB تک)۔ جب کنکشن ختم ہو جاتا ہے، تو پڑھنا کیش سے جاری رہتا ہے اور لکھنا قطار میں لگ جاتا ہے۔ جب کنکشن بحال ہوتا ہے، تمام زیر التواء آپریشنز سرور کو بھیجے جاتے ہیں اور کیش سرور کے ساتھ سنکرونائز ہو جاتا ہے۔ تنازعات کے کنٹرول کے لیے، snapshot-metadata.hasPendingWrites اور setOptions(ServerTimestampBehavior) استعمال کریں۔

سیکیورٹی رولز اور ڈیٹا کی توثیق

Security Rules Firestore کے لیے ایک اعلانیہ رسائی کنٹرول زبان ہے جو ہر ریڈ یا رائٹ آپریشن سے پہلے Google کے سرور پر عمل میں آتی ہے۔ Rules کو سرور سائڈ کوڈ کی ضرورت نہیں ہے — یہ Firebase کنسول یا Firebase CLI کے ذریعے لکھے جاتے ہیں اور Git کے ذریعے ورژن کیے جاتے ہیں۔ ہر آپریشن کا Rules کے خلاف جائزہ لیا جاتا ہے اور خلاف ورزی پر PERMISSION_DENIED خرابی واپس کی جاتی ہے۔

Rules کی ساخت

Firestore Security Rules match بلاکس اور allow ایکسپریشنز پر مشتمل ہوتی ہیں۔ match کسی مجموعہ یا دستاویز کا راستہ متعین کرتا ہے، allow اجازت شدہ آپریشنز (read, write, create, update, delete) اور ایک شرط — boolean لوٹانے والا JavaScript نما ایکسپریشن متعین کرتا ہے۔ Rules تصدیق (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 سے حفاظت نہیں کرتی — یہ ڈیزائن کے لحاظ سے Rules کو نظرانداز کرتا ہے۔ مکمل تحفظ کے لیے، Transaction Functions اور Firebase Extensions استعمال کریں۔