ฐานข้อมูลไม่ใช่เชิงสัมพันธ์ (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 ล่าสุดส่งกลับแอปพลิเคชัน

ทฤษฎีและกลไกการทำงาน (How it works): **Graph Database (เช่น Neo4j)** จัดเก็บข้อมูลในรูปของโหนด (Nodes/Entities) และเส้นเชื่อมความสัมพันธ์ (Edges/Relationships) ชนิดพิเศษของมันคือมีกลไก **Index-Free Adjacency** ทุกโหนดจะเก็บลิงก์ชี้พิกัดแรมของโหนดที่เชื่อมโยงอยู่ด้วยตรงตัว ทำให้เมื่อรันคิวรีเชื่อมสัมพันธ์ยาวหลายทอด (Multi-hop Query) ระบบจะกวาดหาโดยชี้แรมต่อกันทันทีโดยไม่ต้องรันคำสั่ง `JOIN` ที่สแกนดัชนี B-Tree ซ้ำๆ เสมือนฐานข้อมูลทั่วไป

// Cypher query template in Neo4j to find potential fraud rings
MATCH (u1:User)-[:SHARED_IP]->(ip:IPAddress)<-[:SHARED_IP]-(u2:User)
MATCH (u1)-[:TRANSFERRED_MONEY]->(u2)
RETURN u1.id, u2.id, ip.address;
                    

Use Case ในชีวิตจริง (Real-world Scenario): แพลตฟอร์มโซเชียลมีเดียหรือแอปพลิเคชันตรวจจับการฟอกเงินระดับโลก ใช้ Neo4j ค้นหาความสัมพันธ์กลุ่มบัญชีธนาคารโอนเงินวนรอบแบบก้นหอย หรือเชื่อมต่อใช้งาน IP address ร่วมกัน เพื่อบล็อกบัญชีต้องสงสัยได้ทันควัน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การรันคิวรีกราฟแบบไม่จำกัดความลึกสัมพันธ์ (Supernode traversal) เช่น ปล่อยให้ระบบค้นหาความสัมพันธ์กวาดโหนดที่มีการเชื่อมต่อนับสิบล้านเส้น (เช่น ดาราดัง) อาจทำให้หน่วยความจำ RAM พุ่งเต็ม 100% จนเครื่องล่ม แก้ไขโดยจำกัดความลึกสแกน (`*1..3`) หรือจำกัดจำนวนรายการสืบค้นผ่านฟังก์ชัน `LIMIT` เสมอ

ทฤษฎีและกลไกการทำงาน (How it works): Apache Cassandra เป็นฐานข้อมูลแบบกระจายตัวที่มีสถาปัตยกรรมแบบ Peer-to-Peer ไร้ศูนย์กลาง (Masterless) สามารถทำ Multi-Datacenter Replication ได้อย่างแนบเนียน โดยการแบ่งขอบเขตโทเค็นข้อมูล (Token Ring) และใช้ `NetworkTopologyStrategy` เพื่อระบุจำนวนชุดจำลอง (Replicas) ในแต่ละศูนย์ข้อมูล (DC) อย่างอิสระ ส่งผลให้ระบบยังทำงานได้แม้ศูนย์ข้อมูลหลักจะล่มไปทั้งไซต์

-- การสร้าง Keyspace ให้กระจายข้อมูลไปหลาย Data Center
CREATE KEYSPACE global_users 
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'US_East': 3,
  'EU_West': 3,
  'AP_South': 2
};
                    

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

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การใช้ระดับความสม่ำเสมอในการอ่าน/เขียน (Consistency Level) ที่ไม่เหมาะสม เช่น ใช้ `EACH_QUORUM` แทนที่จะเป็น `LOCAL_QUORUM` จะทำให้เกิดความล่าช้ามหาศาลเนื่องจากทุกคิวรีต้องวิ่งข้ามทวีปเพื่อรอการยืนยันจากทุก Data Center

ทฤษฎีและกลไกการทำงาน (How it works): Redis สามารถทำงานบนคลัสเตอร์ได้หลายรูปแบบ: - **Redis Sentinel**: เน้นที่เรื่อง High Availability โดยจะมีกระบวนการ Sentinel คอยตรวจสอบสถานะของ Master หาก Master ล่ม มันจะทำการโปรโมท Slave ขึ้นมาเป็น Master อัตโนมัติ ข้อมูลทั้งหมดยังคงอยู่บนโหนดเดียว - **Redis Cluster**: เน้นทั้ง HA และ การแบ่งซอยข้อมูล (Sharding) โดยจะสับพื้นที่แฮชสล็อตออกเป็น 16,384 ช่อง (Hash Slots) และกระจายไปยังโหนดต่างๆ รองรับการสเกลระบบข้ามเซิร์ฟเวอร์เมื่อข้อมูลมีขนาดใหญ่กว่าที่แรมเครื่องเดียวจะรับไหว

# ตัวอย่างการคอนฟิก Redis Sentinel เพื่อมอนิเตอร์ Master Node
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1
                    

Use Case ในชีวิตจริง (Real-world Scenario): ระบบ Caching หน้าเว็บของสำนักข่าวที่คนเข้าใช้งานพร้อมกันหลักล้านคน หากใช้แค่ Redis Node เดียว แบนด์วิดท์อาจเต็ม จึงต้องเปลี่ยนไปใช้ Redis Cluster เพื่อกระจายทราฟฟิกอ่าน/เขียนไปยังเซิร์ฟเวอร์หลายสิบตัว

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ใน Redis Cluster ไม่สามารถรันคำสั่งกลุ่ม Transaction (`MULTI/EXEC`) หรือคิวรีที่มีเงื่อนไขข้ามคีย์ (Cross-key operations) หากคีย์เหล่านั้นไม่ได้ตกอยู่ใน Hash Slot เดียวกัน (ต้องใช้ Hash Tags เช่น `{user100}.profile` เพื่อบังคับสล็อต) มิฉะนั้นจะเกิดเออเร่อ CROSSSLOT