Data Engineering

แนะนำ Firestore เบื้องต้น (ตอน 1 Data model)

Firestore เป็น NoSQL ไม่เหมือนกับ SQL database ที่มีตารางหรือแถว แต่ข้อมูลจะถูกจัดเก็บไว้ใน documents ซึ่งถูกรวมไว้ใน collections อีกที

ขอบคุณแหล่งข้อมูล: cloud.google.com

Firestore เป็น NoSQL ไม่เหมือนกับ SQL database ที่มีตารางหรือแถว แต่ข้อมูลจะถูกจัดเก็บไว้ใน documents ซึ่งถูกรวมไว้ใน collections อีกที

แต่ละ document จะบรรจุ set ของ key กับ value. Firestore นั้นเหมาะสำหรับการเก็บ collections ขนาดใหญ่ ซึ่งภายในมี document ขนาดเล็กๆ

ทุก documents ต้องถูกเก็บไว้ใน collections. Document สามารถเก็บ subcollections และ nested objects ซึ่งทั้งคู่สามารถใช้ fields อย่าง strings หรือ objects ที่มีความซับซ้อนอย่าง lists ได้

Collections และ documents ต่างถูกสร้างไว้แล้วใน Cloud Firestore ในตอนเริ่มต้น

Documents

ใน Firestore หน่วยที่ใช้เก็บข้อมูล คือ document. document นึง จะมีจำนวน record น้อยๆ ซึ่งบรรจุ fields ซึ่งอ้างอิงไปยัง values. โดยแต่ละ document จะถูกระบุโดยชื่อ

ใน Firestore หน่วยที่ใช้เก็บข้อมูล คือ document. document นึง จะมีจำนวน record น้อยๆ ซึ่งบรรจุ fields ซึ่งอ้างอิงไปยัง values. โดยแต่ละ document จะถูกระบุโดยชื่อ เช่น document ที่ระบุถึง user ชื่อ alovelace อาจมีหน้าตาแบบนี้

Note: Firebase รองรับตัวแปรหลากหลายชนิด ทั้ง boolean, number, string, geo point, binary blob และ timestamp. คุณสามารถใช้ทั้ง arrays หรือ nested objects ที่เรียกว่า maps เพื่อจัดการโครงสร้างข้อมูลใน document ได้อีกด้วย

Complex, nested objects ใน document ที่ถูกเรียกว่า maps นั้น สามารถเขียนโครงสร้างจากตัวอย่างด้านบนได้ดังนี้

คุณอาจสังเกตได้ว่า documents มันหน้าตาคล้ายกับ JSON. จริงๆแล้วมันก็ใช่น่ะแหละ แต่มีบางอย่างที่แตกต่างกัน เช่น document รองรับ extra data types และจำกัดขนาดอยู่ แค่ 1 MB แต่โดยทั่วไปแล้วคุณสามารถถือว่า document เป็น JSON ที่มี records น้อยๆได้เลย

Collections

Documents อยู่ใน collections เช่น คุณสามารถมี users collection ที่เก็บ users ต่างๆ ดังนี้

อย่างที่บอกว่า Firestore นั้นไม่มีโครงสร้างตายตัว ดังนั้นคุณสามารถใส่ fields อะไรก็ได้ data types อะไรก็ได้ที่คุณต้องการลงไปใน document นอกจากนั้น Document ใน collection เดียวกัน ก็สามารถเก็บ fields หรือ types ที่แตกต่างกันอย่างสิ้นเชิงได้อีกด้วย แต่ยังไงก็ตามการใช้ fields และ data types แบบเดียวกันก็ยังเป็นไอเดียที่ดีอยู่ เพราะคุณสามารถ query documents ได้ง่ายยิ่งขึ้น

collection นั้นจะเก็บแค่ documents (ไม่มีอะไรนอกเหนือจากนั้นจริงๆ) มันไม่สามารถเก็บค่า fields ได้ และไม่สามารถเก็บ collections อื่นได้

ชื่อของ documents ใน collection ต้องไม่ซ้ำกัน (unique) คุณสามารถใช้ keys ของคุณเอง เช่น user IDs หรือจะให้ Firestore สร้าง IDs แบบสุ่มขึ้นมาแบบอัตโนมัติก็ได้

คุณไม่จำเป็นต้อง “create” หรือ “delete” collections เพราะหลังจากที่คุณสร้าง document แรกไปแล้ว collection ก็ถูกสร้าง ณ ขณะนั้น และถ้าคุณลบทุก documents ใน collection ไปแล้ว ตัว collection นั้นก็หายไปเอง

Hierarchical Data

เพื่อที่จะเข้าใจว่า hierarchical data structures หรือ โครงสร้างข้อมูลแบบลำดับขั้น นั้นทำงานอย่างไรใน Firestore ลองดูตัวอย่างแอปแชทที่มีข้อความแชทกับห้องแชทดูนะครับ

คุณสามารถสร้าง collection ที่ชื่อว่า rooms เพื่อเก็บห้องแชทต่างๆได้

ตอนนี้คุณก็มีห้องแชทละ คุณต้องตัดสินใจว่าจะเก็บข้อความแชทยังไง. คุณอาจจะไม่ต้องการเก็บไว้ใน document ของห้องแชท เพราะ Documents ใน Firestore ควรจะมีขนาดเล็ก และห้องแชทอาจมีข้อความจำนวนมาก. ยังไงก็ตามคุณสามารถสร้าง collections เพิ่มเติมใน document ห้องแชทด้วย subcollections

Subcollections

ทางที่ดีที่สุดในการเก็บข้อความในเคสตัวอย่างนี้คือ ใช้ subcollections ซึ่งจะเชื่อมโยงกับ document

Note: คุณสามารถ query ข้าม subcollections ด้วย collection ID เดียวกัน โดยการใช้ Collection Group Queries

คุณสามารถสร้าง subcollection ที่ชื่อว่า messages สำหรับทุก document ห้องแชท ภายใต้ collection ชื่อว่า rooms

Subcollection อนุญาตให้คุณวางโครงสร้างแบบเป็นลำดับชั้นได้ ทำให้เข้าถึงข้อมูลได้ง่ายขึ้น. ในการ get ทุกข้อความใน roomA คุณสามารถสร้าง collection reference เพื่ออ้างอิงไปยัง subcollection messages และปฏิสัมพันธ์กับมันเช่นเดียวกับที่คุณทำการอ้างอิงไปยัง collection อื่นๆ

Documents ใน subcollections ก็สามารถเก็บ subcollections ได้เช่นกัน จริงๆแล้วคุณสามารถเก็บแบบลำดับขั้นได้ลึกถึง 100 ระดับ

พอมองเห็นภาพคร่าวๆ แล้วใช่ป่ะครับ ลองหยิบกระดาษ ปากกา มาออกแบบโครงสร้างเล่นๆกันดูนะครับ