ฐานข้อมูลไม่ใช่เชิงสัมพันธ์ (NoSQL Databases & Modern Stores)

ทฤษฎีและกลไกการทำงาน (How it works): NoSQL แบ่งโครงสร้างตามการจัดเก็บหลัก: - **Key-Value Store (เช่น Redis)**: ทำการเก็บข้อมูลทั้งหมดในหน่วยความจำชั่วคราว (In-memory) ดึงหาค่าตรงตัวผ่านรหัสกุญแจ (Key) ด้วยความเร็วระดับไมโครวินาที - **Document Store (เช่น MongoDB)**: เก็บข้อมูลในรูปแบบไฟล์กึ่งมีโครงสร้าง (BSON/JSON Documents) รองรับการสร้างดัชนีซ้อนและคิวรี่ที่มีความยืดหยุ่นสูงโดยไม่ต้องประกาศโครงสร้างตารางล่วงหน้า (Schemaless)

# Python script interacting with Redis (Key-Value) and MongoDB (Document)
import redis
from pymongo import MongoClient

# 1. Redis Session Cache Write
r = redis.Redis(host='localhost', port=6379, db=0)
r.setex("user:42:session", 3600, "active_session_payload")

# 2. MongoDB Event Log Write
client = MongoClient("mongodb://localhost:27017/")
db = client.pipecraft_logs
db.events.insert_one({
    "user_id": 42,
    "action": "checkout",
    "metadata": {"items_count": 3, "ip": "192.168.1.1"}
})
                    

Use Case ในชีวิตจริง (Real-world Scenario): ระบบจำหน่ายสินค้าออนไลน์ใช้ Redis ในการจำลองที่เก็บตะกร้าสินค้าชั่วคราว (Session Cache) เพื่อการันตีความเร็ว และเลือกใช้ MongoDB ในการบันทึกประวัติการกระทำหรือล็อกพฤทีพฤติกรรมผู้ใช้เพื่อประโยชน์ในการวิเคราะห์

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ความไม่ยืดหยุ่นของสกีมาใน MongoDB อาจส่งผลให้ระบบงานพังหากแอปพลิเคชันป้อนฟิลด์ผิดเพี้ยนเข้ามาโดยไม่มีตัวคัดกรอง แก้ไขโดยกำหนดกฎการตรวจสอบโครงสร้างเอกสาร (Schema Validation Rules) ที่ฝั่ง MongoDB หรือใช้ไลบรารี Pydantic คัดกรองประเภทในระดับโค้ดก่อนเซฟ

ทฤษฎีและกลไกการทำงาน (How it works): การเขียนและอ่านลงแผ่นดิสก์ขับเคลื่อนด้วย 2 อัลกอริทึมหลัก: - **B-Tree Engine (เช่น InnoDB ของ MySQL)**: บันทึกข้อมูลแบ่งเป็นบล็อกขนาดคงที่ (Pages) เมื่ออัปเดตจะเข้าไปเขียนทับที่ตำแหน่งดิสก์เดิมตรงตัว (In-place Update) ทำให้ดึงข้อมูลสุ่มอ่าน (Random Read) รวดเร็ว แต่เขียนช้า - **LSM-Tree Engine (เช่น RocksDB, Cassandra)**: แปลงการเขียนเป็นระเบียบล็อกต่อท้าย (Append-only) โดยจะพักข้อมูลเรียงลำดับในหน่วยความจำ (Memtable) แล้วทยอยเขียนลงดิสก์ทีเดียวเป็นโครงสร้างไฟล์ SSTable ทำให้ประสิทธิภาพฝั่งเขียน (Write Throughput) ดีเลิศ

# Disk Layout Logic Comparison
B-Tree (In-Place):
Disk Block [Page 1: Row A, Row B, Row C] -> (Update B) -> Overwrite Page 1

LSM-Tree (Append-only):
Memtable (RAM) -> (Sorted Flush) -> SSTable 1 (Disk) [Row B v2]
(Old Row B v1 remains in SSTable 0 on disk until Compaction merges them)
                    

Use Case ในชีวิตจริง (Real-world Scenario): ระบบจัดเก็บตัววัดประเมินความดันหรืออุณหภูมิเซนเซอร์ IoT ที่พ่นข้อมูลเขียนเข้ามาวินาทีละหลายล้านแถว เลือกใช้ LSM-Tree เพื่อให้บันทึกได้ทันโดยไม่เกิดภาวะคอขวดที่ความเร็วอุปกรณ์ฮาร์ดดิสก์

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): LSM-Tree ต้องแลกมาด้วยความล่าช้าในการอ่าน (Read Latency) เนื่องจากข้อมูลของหนึ่งออบเจกต์อาจกระจายอยู่หลายไฟล์ SSTable แก้ไขโดยใช้อัลกอริทึม **Bloom Filter** (ตัวทดสอบทางสถิติขนาดเล็กในแรม) เพื่อคัดกรองข้ามการเปิดไฟล์ SSTable ที่ไม่มีคีย์นั้นๆ แน่นอน

ทฤษฎีและกลไกการทำงาน (How it works): ใน LSM-Tree เพื่อป้องกันความปลอดภัยของข้อมูลสูญหายเมื่อไฟดับระหว่างที่ข้อมูลพักใน Memtable ระบบจะทำการเขียนบันทึกลงไฟล์ **Write-Ahead Log (WAL)** บนดิสก์แบบต่อท้ายทันทีก่อนตอบยืนยันสำเร็จ เมื่อ Memtable เต็มจะถูก Flush ลงดิสก์เป็นไฟล์ **SSTable** (Sorted String Table) ขนาดเล็กๆ ที่แก้ไขไม่ได้ เมื่อไฟล์ SSTable สะสมตัวมากขึ้น ระบบจะทำ **Compaction** (การเคลียร์พื้นที่ดิสก์ย่อย) โดยเปิดอ่าน SSTable หลายๆ ตัวมาทำการผสานและคัดเลือกเฉพาะคีย์รุ่นใหม่ล่าสุดเก็บไว้ แล้วลบไฟล์เก่าทิ้ง

# Configuration parameters for RocksDB SSTable Compaction size thresholds
# Set maximum size of level-1 SSTables to 256MB before compaction triggers
write_buffer_size = 67108864 # 64MB Memtable Size
max_write_buffer_number = 3
target_file_size_base = 268435456 # 256MB
                    

Use Case ในชีวิตจริง (Real-world Scenario): ระบบบันทึกข้อความสนทนาใน Messenger ใช้ระบบ LSM-Tree เมื่อผู้ใช้ส่งข้อความ ข้อมูลจะเข้าสู่ WAL เพื่อความทนทาน และในเบื้องหลังช่วงเวลาเที่ยงคืนที่มีคนใช้งานน้อย ระบบจะรัน Compaction เพื่อยุบรวมไฟล์ SSTable ช่วยไม่ให้ดิสก์เต็มและเร่งความเร็วการดึงประวัติย้อนหลัง

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): สภาวะ **Compaction Storm** เกิดขึ้นเมื่อระบบรัน Compaction หนักหน่วงแย่งชิงพลังดิสก์ I/O และ CPU จนแอปพลิเคชันหลักทำงานช้าลงกะทันหัน แก้ไขโดยจำกัดความเร็วการเขียนเขียนของ Compaction (Rate Limiting) หรือเลือกโหมดการบดอัดแบบ Leveled Compaction ที่ควบคุมสัดส่วนได้ดีขึ้น

ทฤษฎีและกลไกการทำงาน (How it works): **Apache Cassandra** ทำงานบนโครงสร้างแบบคอลัมน์กว้าง (Wide-Column) โดยการกระจายข้อมูลออกเป็นโหนดแบบไร้ศูนย์กลาง (Masterless Architecture) ข้อมูลจะถูกจัดพิกัดลงในวงแหวนเสมือน (Hash Ring) โดยมีพาร์ทิชันคีย์ (Partition Key) แปลงเป็นค่าแฮชเพื่อเลือกว่าข้อมูลจะถูกยิงเก็บไว้ที่โหนดใดเป็นเครื่องหลัก เพื่อรองรับความคงทน ระบบจะจำลองข้อมูลคัดลอก (Replication) ส่งต่อไปยังโหนดข้างเคียงตามค่าที่กำหนด (Replication Factor)

# Cassandra Keyspace creation defining replication strategy across datacenters
CREATE KEYSPACE pipecraft_analytics
WITH replication = {
    'class': 'NetworkTopologyStrategy',
    'datacenter1': 3 -- Keep 3 copies of data in datacenter1
};
                    

Use Case ในชีวิตจริง (Real-world Scenario): ระบบสตรีมมิ่งความบันเทิงระดับโลกบันทึกพฤติกรรมการกดหยุดหรือเล่นไฟล์ภาพยนตร์ของผู้ใช้ทุกคนข้ามประเทศ โดยกระจายคลัสเตอร์ Cassandra ไว้ตามทวีปต่างๆ ทำให้เขียนข้อมูลได้รวดเร็วแบบไร้รอยต่อโดยไม่มีโหนดหลักเป็นคอขวด

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ปัญหาข้อมูลสองโหนดขัดแย้งกันเนื่องจากการซิงก์ล่าช้า แก้ไขโดยใช้ระบบการอ่านแบบแก้ข้อมูลด้วยเสียงข้างมาก (Quorum Reads/Writes) เช่น การตั้งเกณฑ์ให้อ่านข้อมูลจาก 2 ใน 3 โหนดพร้อมกันและสแกนคัดเลือกค่าที่มี Time stamp ล่าสุดส่งกลับแอปพลิเคชัน