ไฟร์เบส เรียลไทม์ ฐานข้อมูล: คืออะไร โครงสร้าง JSON และการซิงค์ข้อมูลแบบเรียลไทม์

ไฟร์เบส เรียลไทม์ ฐานข้อมูลคืออะไร

ไฟร์เบส เรียลไทม์ ฐานข้อมูล เป็นหนึ่งในฐานข้อมูลแบบเรียลไทม์บนคลาวด์รุ่นแรก ๆ ที่เปิดตัวโดยกูเกิลร่วมกับไฟร์เบสในปี 2012 เป็นฐานข้อมูล NoSQL ที่จัดเก็บข้อมูลเป็นต้นไม้ JSON เดียวที่เข้าถึงได้ผ่าน URL เดียว SDK ของไคลเอนต์ (แอนดรอยด์, iOS, เว็บ) สมัครรับข้อมูลโหนดเฉพาะของต้นไม้ผ่าน WebSocket และได้รับการอัปเดตเมื่อข้อมูลมีการเปลี่ยนแปลงทุกครั้ง — โดยไม่ต้อง ping เซิร์ฟเวอร์และไม่ต้องใช้กลไก Push ของตัวเอง

ประวัติและพัฒนา

ไฟร์เบสดั้งเดิมก่อตั้งขึ้นในปี 2011 โดยเจมส์ แทมพลินและแอนดรูว์ ลี และผลิตภัณฑ์แรกคือเรียลไทม์ ฐานข้อมูล หลังจากที่กูเกิลเข้าซื้อกิจการในปี 2014 (ตามข้อมูลของเทคครันช์ — มูลค่าระหว่าง 50 ถึง 100 ล้านดอลลาร์) ฐานข้อมูลถูกรวมเข้ากับกูเกิล คลาวด์และได้รับความจุที่สูงขึ้นอย่างมาก ในปี 2017 กูเกิลประกาศไฟร์สโตร์เป็นตัวทดแทนเชิงวิวัฒนาการ แต่เรียลไทม์ ฐานข้อมูลยังคงได้รับการสนับสนุนและอัปเดตอย่างต่อเนื่อง ตามข้อมูลของกูเกิล (2026) เรียลไทม์ ฐานข้อมูล ยังคงถูกใช้ในโครงการที่ใช้งานอยู่มากกว่า 1.5 ล้านโครงการ

ขีดจำกัดฟรีและอัตราค่าบริการ

แผนสปาร์ก (ฟรี) ประกอบด้วย: พื้นที่จัดเก็บ 1 GB, ข้อมูลที่ดาวน์โหลด 10 GB ต่อเดือน, การเชื่อมต่อพร้อมกัน 100 รายการ และรองรับฐานข้อมูลในหนึ่งภูมิภาค ในแผนเบลซ (จ่ายตามการใช้งาน) จะคิดค่าธรรมเนียมสำหรับพื้นที่จัดเก็บเพิ่มเติม ($1/GB), ปริมาณการรับส่งข้อมูล ($0.12/GB) และการเชื่อมต่อพร้อมกัน ($5 ทุก ๆ 100,000 ที่เกินขีดจำกัด) สำหรับการทดสอบ ยังสามารถใช้โหมดจำลอง — firebase emulators:start — ซึ่งรันเรียลไทม์ ฐานข้อมูลในเครื่องโดยไม่ต้องเชื่อมต่อกับคลาวด์

โครงสร้างข้อมูล: ต้นไม้ JSON และการทำให้เป็นบรรทัดฐาน

เรียลไทม์ ฐานข้อมูล ไม่มีตาราง คอลเล็กชัน หรือเอกสาร — ทุกอย่างเป็นต้นไม้ JSON เดียวที่เข้าถึงได้ผ่าน URL รูปแบบ https://project-name-default-rtdb.firebaseio.com/ แต่ละคีย์ของต้นไม้เป็นค่าปลายทาง (สตริง ตัวเลข boolean null) หรือโหนดที่ซ้อนกันพร้อมคีย์ย่อย เอนจินฐานข้อมูลไม่รองรับ JOIN คำสั่งย่อย หรือการรวม — คำสั่งค้นหาจะส่งคืนเนื้อหาของโหนดเดียวพร้อมองค์ประกอบย่อยทั้งหมดเสมอ

การทำให้ข้อมูลเป็นบรรทัดฐาน

เนื่องจากไม่มี JOIN ในเรียลไทม์ ฐานข้อมูล การทำให้ข้อมูลเป็นบรรทัดฐาน จึงเป็นสิ่งจำเป็น แทนที่จะใช้ต้นไม้ที่ซ้อนกัน (ผู้ใช้ → รายการโพสต์ของเขา) ข้อมูลจะถูกแบ่งออกเป็นรายการแบบแบนพร้อมการอ้างอิงผ่านคีย์ นี่เป็นแนวทางมาตรฐาน: ข้อมูลถูกทำให้ไม่เป็นบรรทัดฐานเพื่อให้การอ่านโหนดเดียวไม่ดึงบริบททั้งหมด ตัวอย่างเช่น รายการข้อความแชทจะถูกจัดเก็บแยกจากโปรไฟล์ผู้ใช้ และแต่ละโพสต์จะมีเฉพาะ ID ของผู้แต่ง ไม่ใช่โปรไฟล์ทั้งหมด

คำค้นหาในเรียลไทม์ ฐานข้อมูล

คำค้นหา ในเรียลไทม์ ฐานข้อมูลดำเนินการด้วย filter (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt) ต่างจากไฟร์สโตร์ ดัชนีจะถูกสร้างขึ้นด้วยตนเองผ่านส่วน Rules (.indexOn) หากไม่ได้ประกาศดัชนี คำค้นหาที่มีการเรียงลำดับจะส่งคืนข้อผิดพลาด PERMISSION_DENIED คำค้นหาทำงานกับฟิลด์เดียวเท่านั้น — คำค้นหาแบบผสม (กรองตามราคา + เรียงตามวันที่) ไม่ได้รับการสนับสนุน สำหรับการกรองที่ซับซ้อน ข้อมูลมักจะถูกทำซ้ำในโหนดต่าง ๆ ด้วยคีย์การเรียงลำดับที่แตกต่างกัน

เรียลไทม์ ฐานข้อมูล vs ไฟร์สโตร์: เลือกอะไรดี

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

สามสถานการณ์หลักสำหรับเรียลไทม์ ฐานข้อมูล

สถานการณ์แรก — เกม多人ผู้เล่นที่มีการซิงค์สถานะ (หมากรุก เกมไพ่ แอคชันเรียลไทม์) ความหน่วงของเรียลไทม์ ฐานข้อมูลอยู่ที่ 10-30 มิลลิวินาที เทียบกับ 50-100 มิลลิวินาทีของไฟร์สโตร์ในภูมิภาคเดียวกัน สถานการณ์ที่สอง — แชทและเมสเซนเจอร์ที่มีความถี่ข้อความสูง เรียลไทม์ ฐานข้อมูลคิดค่าบริการตามปริมาณข้อมูล ไม่ใช่จำนวนการเขียน ทำให้ถูกกว่าไฟร์สโตร์มากเมื่อมีความถี่มากกว่า 1 ข้อความต่อวินาที สถานการณ์ที่สาม — การแสดงสถานะผู้ใช้ออนไลน์/ออฟไลน์ (presence) ซึ่งตัวจัดการ onDisconnect ของเรียลไทม์ ฐานข้อมูลช่วยให้ตั้งค่าสถานะอัตโนมัติเมื่อการเชื่อมต่อขาด

ตามข้อมูลของกูเกิล (2026) ประมาณ 15% ของโครงการไฟร์เบสใหม่เลือกเรียลไทม์ ฐานข้อมูลอย่างมีสติ — เมื่อทีมเข้าใจข้อกำหนดด้านความหน่วง โครงสร้างข้อมูล และงบประมาณอย่างชัดเจน ในอีก 85% ของกรณี ไฟร์สโตร์เป็นตัวเลือกที่ปลอดภัยกว่าเนื่องจากความสามารถในการปรับขนาดที่ดีกว่า คำค้นหาที่ทรงพลังกว่า และการจำลองแบบอัตโนมัติ

การรวมเรียลไทม์ ฐานข้อมูลในแอนดรอยด์

การเชื่อมต่อเรียลไทม์ ฐานข้อมูล กับแอปพลิเคชันแอนดรอยด์ทำได้โดยเพิ่ม dependency firebase-database-ktx ใน build.gradle ออบเจกต์ FirebaseDatabase สามารถเข้าถึงได้ผ่าน getInstance(url) — สามารถเชื่อมต่อกับหลายฐานข้อมูลภายในโครงการไฟร์เบสเดียว หลังจากเริ่มต้น SDK จะสร้างการเชื่อมต่อ WebSocket กับเซิร์ฟเวอร์โดยอัตโนมัติและเริ่มซิงค์ข้อมูล

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

// การเริ่มต้นด้วย URL ที่กำหนดเอง
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

การเขียนและอ่านข้อมูล

เรียลไทม์ ฐานข้อมูล ใช้ออบเจกต์ DatabaseReference สำหรับการดำเนินการทั้งหมด setValue() เขียนข้อมูลไปยังโหนดที่ระบุ โดยแทนที่เนื้อหาทั้งหมด push() จะสร้างคีย์ที่ไม่ซ้ำกันโดยอัตโนมัติ (ตามการประทับเวลา) สำหรับเพิ่มรายการในรายการ — นี่เป็นวิธีมาตรฐานในการสร้างข้อความแชท โพสต์ และเรกคอร์ด updateChildren() เปลี่ยนแปลงหลายโหนดแบบอะตอมมิกในการดำเนินการเดียว addValueEventListener สมัครรับการเปลี่ยนแปลงของโหนดและได้รับการเรียกกลับทุกครั้งที่มีการอัปเดตข้อมูล

data class Message(
    val author: String = "",
    val text: String = "",
    val timestamp: Long = ServerValue.TIMESTAMP
)

class ChatRepository(private val ref: DatabaseReference) {
    fun sendMessage(author: String, text: String) {
        val msg = Message(author = author, text = text)
        ref.child("messages").push().setValue(msg)
    }

    fun observeMessages(): Flow<List<Message>> = callbackFlow {
        val listener = ref.child("messages")
            .addValueEventListener(object : ValueEventListener {
                override fun onDataChange(snapshot: DataSnapshot) {
                    val messages = snapshot.children.mapNotNull { it.getValue(Message::class.java) }
                    trySend(messages)
                }
                override fun onCancelled(error: DatabaseError) {}
            })
        awaitClose { ref.removeEventListener(listener) }
    }
}

การซิงค์แบบเรียลไทม์และโหมดออฟไลน์

กลไกการซิงค์ ของเรียลไทม์ ฐานข้อมูลใช้โปรโตคอล WebSocket (ก่อนหน้านี้ใช้ long-polling) ไคลเอนต์ส่งคำขอสมัครรับข้อมูลโหนดที่กำหนด และเซิร์ฟเวอร์คงการเชื่อมต่อไว้ เมื่อมีการเปลี่ยนแปลงข้อมูลในโหนดที่สมัครไว้ เซิร์ฟเวอร์จะส่ง JSON ทั้งหมดของโหนดนั้นไปยังไคลเอนต์ SDK บนไคลเอนต์จะอัปเดตสถานะในเครื่องโดยอัตโนมัติและเรียกการเรียกกลับที่เกี่ยวข้อง (onDataChange)

OnDisconnect — ทริกเกอร์การตัดการเชื่อมต่อ

OnDisconnect — ความสามารถพิเศษของเรียลไทม์ ฐานข้อมูลที่ไม่มีในไฟร์สโตร์ นักพัฒนาสามารถลงทะเบียนการดำเนินการเขียนที่จะดำเนินการบนเซิร์ฟเวอร์โดยอัตโนมัติเมื่อการเชื่อมต่อของไคลเอนต์ขาด ใช้สำหรับสถานะการแสดงตน: "user123/status": "online" พร้อม onDisconnect.setValue("offline") หากผู้ใช้ปิดแอปหรือสูญเสียอินเทอร์เน็ต เซิร์ฟเวอร์จะตั้งค่าสถานะเป็น "offline" โดยอัตโนมัติภายในไม่เกิน 3 นาที (ปรับแต่งได้ในคอนโซลไฟร์เบส)

แคชออฟไลน์

Persistence ในเรียลไทม์ ฐานข้อมูลเปิดใช้งานด้วยบรรทัดเดียว: FirebaseDatabase.getInstance().setPersistenceEnabled(true) SDK จะแคชสถานะล่าสุดของโหนดที่สมัครทั้งหมดบนดิสก์ (สูงสุด 10 MiB โดยค่าเริ่มต้น ปรับได้ถึง 100 MiB) เมื่อการเชื่อมต่อขาด ไคลเอนต์ยังคงทำงานกับข้อมูลที่แคชไว้ และการดำเนินการเขียนทั้งหมดจะถูกจัดคิว เมื่อการเชื่อมต่อกลับคืนมา SDK จะส่งการเปลี่ยนแปลงที่สะสมทั้งหมดไปยังเซิร์ฟเวอร์ตามลำดับที่ถูกต้อง (FIFO)

ตามข้อมูลของกูเกิล (2026) แอปพลิเคชันที่เปิดใช้งาน persistence cache สูญเสียข้อมูลผู้ใช้เมื่อการเชื่อมต่อขาดน้อยลง 40% อย่างไรก็ตาม หากไคลเอนต์สะสมการดำเนินการที่รอดำเนินการมากกว่า 1,000 รายการ เซิร์ฟเวอร์อาจปฏิเสธทั้งหมดและขอให้ซิงค์ข้อมูลทั้งหมด — นี่เป็นกลไกป้องกันสำหรับไคลเอนต์ที่ล้าสมัย

กฎความปลอดภัยและการตรวจสอบความถูกต้อง

กฎความปลอดภัย ในเรียลไทม์ ฐานข้อมูลเป็นการกำหนดค่า JSON ที่อธิบายว่าใครสามารถอ่านและเขียนข้อมูลในแต่ละโหนดได้ภายใต้เงื่อนไขใด กฎทำงานบนเซิร์ฟเวอร์ของกูเกิลและดำเนินการก่อนทุกการดำเนินการ โดยค่าเริ่มต้น (ในโหมดการผลิต) แนะนำให้ตั้งค่า rules เป็นโหมด "ปิด" — เฉพาะผู้ใช้ที่ผ่านการยืนยันตัวตนเท่านั้นที่สามารถเข้าถึงได้

โครงสร้างของกฎ

กฎของ เรียลไทม์ ฐานข้อมูล เขียนในรูปแบบ JSON พร้อมส่วน .read, .write, .validate, .indexOn ต่างจากไฟร์สโตร์ (ที่ใช้ไวยากรณ์ match) เรียลไทม์ ฐานข้อมูลใช้ออบเจกต์ที่ซ้อนกันซึ่งสะท้อนโครงสร้างข้อมูล เงื่อนไขตรวจสอบ auth (การยืนยันตัวตน), data (ข้อมูลที่มีอยู่), newData (ข้อมูลใหม่เมื่อเขียน) และ now (เวลาเซิร์ฟเวอร์) กฎการตรวจสอบ (.validate) ช่วยให้ตรวจสอบชนิด ช่วงค่า และโครงสร้างข้อมูลได้

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid",
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      ".indexOn": ["timestamp"],
      "$msgId": {
        ".read": true,
        ".write": "auth.uid !== null",
        ".validate": "newData.child('text').isString() && newData.child('text').val().length <= 500"
      }
    }
  }
}

พฤติกรรมแบบลูกโซ่และการทดสอบกฎ

กฎของเรียลไทม์ ฐานข้อมูลได้รับการสืบทอดแบบลูกโซ่ — หาก .read = false ในระดับบน โหนดย่อยทั้งหมดจะไม่สามารถอ่านได้ไม่ว่าจะมีกฎของตัวเองอย่างไร ไฟร์เบสมีโปรแกรมจำลองกฎในคอนโซลที่สามารถทดสอบการดำเนินการด้วย auth token ที่แตกต่างกันก่อนการนำไปใช้ แนะนำให้ทดสอบ rules ในโปรแกรมจำลองเสมอ — ข้อผิดพลาดในกฎอาจเปิดเผยข้อมูลส่วนตัวของผู้ใช้ทั้งหมด ตามข้อมูลของกูเกิล (2026) 40% ของการรั่วไหลของข้อมูลในโครงการไฟร์เบสเกิดจากกฎความปลอดภัยที่กำหนดค่าไม่ถูกต้อง