ภาพรวมของ Firestore ในโหมดดั้งเดิม

Firestore ในโหมดเนทีฟประกอบด้วยการดำเนินการ 2 ชุด ได้แก่ การดำเนินการหลักของ Firestore และการดำเนินการไปป์ไลน์ของ Firestore

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

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

ฟีเจอร์ของการดำเนินการหลักของ Firestore

การดำเนินการหลักช่วยให้ดำเนินการ CRUD มาตรฐานและคำค้นหาแบบเรียลไทม์ได้ อย่างไรก็ตาม เมื่อใช้การดำเนินการเหล่านี้ในรุ่น Enterprise ลักษณะการทำงานพื้นฐานเกี่ยวกับการจัดทำดัชนีและการเรียกเก็บเงินจะเปลี่ยนแปลงอย่างมาก เมื่อเทียบกับรุ่น Standard

ฟังก์ชันการทำงานและความต่อเนื่อง

การดำเนินการหลักยังคงใช้ไวยากรณ์การเชื่อมโยงเมธอดที่คุ้นเคย (เช่น .where(), .orderBy()) ที่ใช้ในรุ่นมาตรฐาน การดำเนินการเหล่านี้รองรับคำค้นหาการฟังแบบเรียลไทม์และความต่อเนื่องแบบออฟไลน์สำหรับไคลเอ็นต์บนอุปกรณ์เคลื่อนที่และเว็บ ขอแนะนำให้ใช้การดำเนินการเหล่านี้สำหรับภาระงานธุรกรรมมาตรฐาน การค้นหาอย่างง่าย และการย้ายโค้ดของแอปพลิเคชันที่มีอยู่

การจัดทำดัชนีที่กำหนดเอง

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

รูปแบบการเรียกเก็บเงิน (อิงตามหน่วย)

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

ฟีเจอร์ของการดำเนินการไปป์ไลน์ Firestore

Firestore Enterprise Edition ที่มีการดำเนินการแบบไปป์ไลน์ใช้เครื่องมือค้นหาขั้นสูงที่ช่วยขจัดข้อจำกัดที่มีอยู่มากมายของ Firestore Standard Edition การดำเนินการไปป์ไลน์มีฟีเจอร์การค้นหาเพิ่มเติมอีกหลายร้อยรายการ การดำเนินการไปป์ไลน์มีความสามารถต่อไปนี้

ไวยากรณ์ที่ประกอบได้ตามระยะ

การสร้างคําค้นหาไปป์ไลน์ทําได้โดยการกําหนดชุดขั้นตอนตามลําดับ ซึ่งจะดําเนินการตามลําดับ ซึ่งจะช่วยให้ดําเนินการที่ซับซ้อนได้ เช่น การกรองผลลัพธ์ของการรวม ซึ่งก่อนหน้านี้ทําไม่ได้

ตัวอย่างต่อไปนี้แสดงการค้นหาแบบไปป์ไลน์ที่ค้นหาจำนวนรหัสผลิตภัณฑ์ที่ไม่ซ้ำกัน ที่ดูในเดือนที่ผ่านมา

guard let cutoffDate = Calendar.current.date(byAdding: .month, value: -1, to: Date()) else {
  return
}
let snapshot = try await db.pipeline()
  .collection("productViews")
  .where(Field("viewedAt").greaterThan(cutoffDate.timeIntervalSince1970))
  .aggregate([Field("productId").countDistinct().as("uniqueProductViews")])
  .execute()

ความสามารถที่เพิ่มขึ้น

การค้นหาไปป์ไลน์จะเปิดตัวความสามารถใหม่ๆ มากมาย ซึ่งรวมถึงความสามารถต่อไปนี้

  • การรวม: รองรับฟังก์ชันการรวมใหม่ (เช่น sum(...), min(...) และ count_distinct(...)) ร่วมกับฟิลด์การจัดกลุ่มที่กำหนดเอง
  • การรวมเชิงสัมพันธ์: ทำการรวมฝั่งเซิร์ฟเวอร์ในคอลเล็กชันและ คอลเล็กชันย่อยโดยใช้คําสั่งย่อยที่สัมพันธ์กัน
  • การกรองที่ซับซ้อน: รองรับฟังก์ชันเพิ่มเติมอีกหลายร้อยฟังก์ชันเพื่อแสดงข้อความ where(...) ที่ซับซ้อนโดยพลการ รวมถึง regex_match(...), add(...) และ str_contains(...) โดยไม่ต้องมีข้อกำหนดดัชนีที่ซับซ้อน
  • การอ่าน / การคาดการณ์บางส่วน: ดึงข้อมูลชุดย่อยแบบไดนามิกของเอกสารโดยใช้select(...) remove_fields(...) และขั้นตอนการจัดการเอกสารอื่นๆ อีกมากมาย

ดูข้อมูลเพิ่มเติมเกี่ยวกับความสามารถเหล่านี้ได้ที่ค้นหาข้อมูลด้วยการดำเนินการ Pipeline

การสนับสนุนแบบเรียลไทม์และแบบออฟไลน์

หากต้องการใช้แบบเรียลไทม์และออฟไลน์ นักพัฒนาซอฟต์แวร์สามารถใช้การดำเนินการหลักของ Firestore ในรุ่น Firestore Enterprise ได้

การผสานรวมไคลเอ็นต์และเครื่องมือ

รุ่น Enterprise มีฟีเจอร์เฉพาะสำหรับการโต้ตอบ และการจัดการการค้นหาในไปป์ไลน์ ดังนี้

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

ความแตกต่างระหว่าง Firestore รุ่น Standard กับ Firestore รุ่น Enterprise

ความแตกต่างด้านการปฏิบัติงานที่สำคัญระหว่างการปฏิบัติงานหลักและการปฏิบัติงานของไปป์ไลน์อยู่ที่ การจัดการการจัดทำดัชนี ซึ่งส่งผลต่อประสิทธิภาพและต้นทุนโดยตรง

รุ่นมาตรฐาน - การดำเนินการหลัก รุ่น Enterprise - การดำเนินการหลักและการดำเนินการไปป์ไลน์
ข้อกำหนดในการจัดทำดัชนี ต้องมีดัชนีสำหรับการค้นหา

ระบบจะสร้างดัชนีสำหรับแต่ละช่องโดยอัตโนมัติ ส่วนการค้นหาที่ซับซ้อนกว่านั้นจะอาศัยดัชนีผสมหรือดัชนีกลุ่มคอลเล็กชันซึ่งต้องกำหนดค่าด้วยตนเอง

ไม่จำเป็นต้องมีดัชนี ดังนั้นการค้นหาจึงไม่บังคับ

คุณกำหนดดัชนีได้ตามต้องการ นอกจากนี้ รุ่น Enterprise ยังรองรับดัชนีหลายประเภทมากขึ้น ซึ่งรวมถึงดัชนีแบบไม่กระจัดกระจาย/กระจัดกระจาย และดัชนีที่ไม่ซ้ำกัน

ฟิลด์ที่จัดทำดัชนี ระบบจะต่อท้ายฟิลด์ __name__ เพิ่มเติมกับฟิลด์ที่จัดทำดัชนีโดยอัตโนมัติหากยังไม่มี ระบบไม่ผนวก __name__ เข้ากับฟิลด์ที่จัดทำดัชนีโดยอัตโนมัติ คุณต้องระบุ __name__ ในฟิลด์ที่จัดทำดัชนีอย่างชัดเจนหากมีความสำคัญต่อแอปพลิเคชัน
การปรับการจัดเรียงให้เป็นมาตรฐาน ระบบจะทำให้ส่วน ORDER BY ของคำค้นหาเป็นมาตรฐานโดยการต่อท้ายฟิลด์ความไม่เท่ากันและฟิลด์ __name__ ไว้ที่ท้าย (หากยังไม่มี) ซึ่งจะรับประกันการจัดลำดับผลลัพธ์ที่ไม่ซ้ำกันและเป็นไปตามที่กำหนด ไม่ว่าจะมีฟิลด์อื่นๆ ใดในอนุประโยค ORDER BY ไม่มีการปรับลำดับการจัดเรียงให้เป็นมาตรฐาน ลำดับการจัดเรียง เช่น sort a ASC จะรับประกันได้ว่าผลลัพธ์จะได้รับการจัดเรียงตามฟิลด์ a เท่านั้น Cloud Firestore จะใช้ดัชนีที่มีอยู่เพื่อแสดงผลลัพธ์ตามลำดับที่มีประสิทธิภาพมากที่สุด ดังนั้นหาก a ไม่ซ้ำกันในชุดผลลัพธ์ ลำดับของผลลัพธ์อาจแตกต่างกันไปในแต่ละคำค้นหา ทั้งนี้ขึ้นอยู่กับการกำหนดค่าดัชนี กลยุทธ์การดำเนินการ ฯลฯ หากต้องการรับประกันการจัดลำดับผลลัพธ์ที่ไม่ซ้ำกันและเป็นไปตามที่กำหนด คุณต้องเพิ่มฟิลด์ที่ไม่ซ้ำกัน เช่น __name__ ลงในลำดับการจัดเรียง
ประสิทธิภาพ คำค้นหาที่จัดทำดัชนี: ประสิทธิภาพและต้นทุนจะปรับขนาดตามขนาดของชุดผลลัพธ์

การค้นหาที่ไม่ได้จัดทำดัชนี: ประสิทธิภาพและต้นทุนจะปรับขนาดตามขนาดของชุดข้อมูล

คำค้นหาที่จัดทำดัชนี: ประสิทธิภาพและต้นทุนจะปรับขนาดตามขนาดของชุดผลลัพธ์

เราขอแนะนําให้ใช้เครื่องมืออธิบายการค้นหาและข้อมูลเชิงลึกของการค้นหาเพื่อสร้างดัชนี รวมถึงปรับปรุงประสิทธิภาพและต้นทุนของการค้นหา

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

ดูข้อมูลเกี่ยวกับการกำหนดราคาใหม่พร้อมตัวอย่าง

กฎความปลอดภัย กฎความปลอดภัยจะปกป้องคอลเล็กชันโดยการยืนยันสิทธิ์อ่าน/เขียน กฎความปลอดภัยจะปกป้องคอลเล็กชันโดยการยืนยันสิทธิ์อ่าน/เขียน ดูวิธีสร้างโมเดลข้อมูลเพื่อรองรับการค้นหา Pipeline ในคำแนะนำโมเดลข้อมูล