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,000 ครั้ง, การเขียน 20,000 ครั้ง และการลบ 20,000 ครั้งต่อวัน ในแผน Blaze ทุกอย่างข้างต้นฟรี และส่วนเกินจะถูกเรียกเก็บ: $0.06 ต่อการอ่าน 100,000 ครั้ง, $0.18 ต่อการเขียน 100,000 ครั้ง ตามข้อมูลของ Google (2026) 90% ของโปรเจกต์อยู่ในขีดจำกัดฟรี

โมเดลข้อมูล: คอลเลกชัน เอกสาร และฟิลด์

โมเดลข้อมูลของ Firestore ถูกจัดเรียงตามลำดับชั้น: รากมีคอลเลกชัน แต่ละคอลเลกชันมีเอกสาร แต่ละเอกสารมีฟิลด์ (ชนิดพื้นฐาน อาร์เรย์ Map) และคอลเลกชันที่ซ้อนกัน (คอลเลกชันย่อย) ความลึกของการซ้อนคอลเลกชันไม่มีขีดจำกัด แต่เอกสารไม่สามารถมีเอกสารอื่นได้โดยตรง — ผ่านการอ้างอิง (ชนิด Reference) เท่านั้น

คอลเลกชันและเอกสาร

คอลเลกชันคือคอนเทนเนอร์ของเอกสารที่มีตัวระบุที่สร้างโดยอัตโนมัติหรือกำหนดโดยผู้ใช้ เอกสารแต่ละฉบับเป็นวัตถุคล้าย 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,000 รายการต่อคอลเลกชันเดียวโดยไม่สูญเสียความเร็ว ในขณะที่ Realtime Database รองรับการเชื่อมต่อสูงสุด 200,000 รายการต่ออินสแตนซ์เดียว

การกำหนดราคา

Realtime Database คิดค่าบริการตามปริมาณข้อมูลที่ถ่ายโอน (ไบต์ที่ดาวน์โหลด) และจำนวนการเชื่อมต่อพร้อมกัน Firestore คิดค่าบริการตามจำนวนการดำเนินการ (อ่าน เขียน ลบ) สำหรับแอปพลิเคชันที่มีการอัปเดตเล็กน้อยบ่อยครั้ง (แชท การแจ้งเตือน) Firestore มักจะคุ้มค่ากว่า — การเขียนแต่ละครั้งมีราคาคงที่ไม่ว่าขนาดข้อมูลจะเป็นเท่าใด สำหรับแอปพลิเคชันที่มีการอ่านข้อมูลปริมาณมากไม่บ่อยครั้ง Realtime Database อาจถูกกว่า

คำแนะนำของ Google (2026): ใช้ Firestore เป็นฐานข้อมูลเริ่มต้นสำหรับโปรเจกต์ใหม่ และใช้ Realtime Database สำหรับเกมและแอปพลิเคชันที่ความหน่วงต่ำสุด (น้อยกว่า 50 มิลลิวินาที) และโครงสร้างข้อมูลแบบราบมีความสำคัญ ฐานข้อมูลทั้งสองสามารถทำงานพร้อมกันในโปรเจกต์เดียวกันได้

การค้นหา ดัชนี และการแบ่งหน้าใน 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

การรวม 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) การอ่านครั้งเดียวจะดึงเอกสารหนึ่งครั้ง — มีประโยชน์สำหรับการตั้งค่าและการกำหนดค่า Listener สมัครรับการเปลี่ยนแปลง — การอัปเดตเอกสารใดๆ จะส่งข้อมูลที่อัปเดตไปยังไคลเอ็นต์ที่เชื่อมต่อทั้งหมดโดยอัตโนมัติแบบเรียลไทม์ set() สร้างหรือเขียนทับเอกสาร update() แก้ไขเฉพาะฟิลด์ที่ระบุโดยไม่เขียนทับเอกสารทั้งหมด

ตามข้อมูลของ Google (2026) แอปพลิเคชันขนาดกลาง (100,000 DAU) ที่ใช้ Firestore แบบเรียลไทม์ใช้ปริมาณการรับส่งข้อมูลขาออกประมาณ 5-10 GB ต่อเดือน การใช้แคชออฟไลน์ (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 ที่คืนค่า boolean 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 ที่เป็นอันตราย — มันบายพาสกฎโดยการออกแบบ สำหรับการป้องกันที่สมบูรณ์ ให้ใช้ Transaction Functions และ Firebase Extensions