บทที่ 6: Storage
3 min read"It's storage all the way down"
Storage คือรากฐานของทุกอย่างใน data engineering lifecycle — ข้อมูลถูกจัดเก็บหลายครั้งระหว่างเดินทางผ่าน pipeline
Figure 6-1. Storage เป็นแกนกลางของ data engineering lifecycle
Raw Ingredients
| Component | ลักษณะ |
|---|---|
| HDD | ~$0.03/GB, 200-300 MB/s, IOPS (Input/Output Operations Per Second) 50-500 |
| SSD | ~$0.20-0.30/GB, latency <0.1ms, IOPS หลายหมื่น |
| RAM | ~$10/GB, latency ~100ns, volatile |
| Networking | Distributed storage ต้องพึ่ง network performance |
| Serialization | Row-oriented (JSON, Avro) vs Columnar (Parquet, ORC) |
| Compression | ลดพื้นที่ + เพิ่ม effective scan speed แต่เสีย CPU |
| Caching | CPU cache → RAM → SSD → HDD → Object → Archival |
Figure 6-2. Raw ingredients → storage systems → storage abstractions คือ 3 ชั้นที่ chapter นี้ไล่อธิบาย
Storage Systems Taxonomy
| ระบบ | จุดเด่น |
|---|---|
| File Storage | Directory tree, NFS (Network File System), EFS (Elastic File System — cloud version ของ NFS) |
| Block Storage | Raw storage units (หน่วยจัดเก็บดิบ), RAID (Redundant Array of Independent Disks — รวมหลาย disks เป็น volume เดียว), SAN (Storage Area Network — block storage ผ่าน network), EBS (Elastic Block Store — cloud block storage ของ AWS) |
| Object Storage | Key-value สำหรับ immutable data, scale ได้ไม่จำกัด, S3/GCS/Azure Blob — เขียนทับไม่ได้ (write once), update ต้องเขียน object ใหม่ทั้งก้อน |
| Cache/Memory | Memcached (simple key-value), Redis (data types + persistence) |
| HDFS (Hadoop Distributed File System) | รวม compute+storage, NameNode (จัดการ metadata) + DataNodes (เก็บ data), ปัจจุบันเป็น legacy |
| Streaming Storage | Kafka — indefinite retention โดย push เก่าไป object storage |
Figure 6-8. Object storage เก็บ objects ที่ immutable — แก้ไข in-place ไม่ได้ ต่างจากไฟล์บน local disk
CAP Theorem & PACELC
- CAP theorem: ระบบ distributed เลือกได้แค่ 2 ใน 3 —
- Consistency (ความสอดคล้อง): ทุก node เห็น data เดียวกันตลอดเวลา — ถ้าเขียนที่ node หนึ่ง อีก node ต้องเห็นค่าล่าสุด
- Availability (ความพร้อมใช้งาน): ทุก request ได้ response เสมอ — ระบบไม่เคยปิดรับคำขอ
- Partition Tolerance (ทนต่อการขาดconnection): ระบบยังทำงานได้แม้ network ระหว่าง nodes หลุด
- ตัวอย่าง: RDBMS เลือก CP (เสีย availability เมื่อ network ปัญหา), Cassandra เลือก AP (ยอมให้ data ไม่ consistent ชั่วครู่)
- PACELC: ส่วนขยายของ CAP — ถ้า Partition เกิด (P) → เลือกระหว่าง Consistency (C) กับ Availability (A) (เหมือน CAP); ถ้าไม่มี Partition (Else) → เลือกระหว่าง Latency (L) กับ Consistency (C) — เช่น DynamoDB ให้เลือกได้ว่าจะเอา consistent reads (ช้ากว่า) หรือ eventual consistent reads (เร็วกว่า)
- Eventual vs Strong Consistency: BASE (Basically Available, Soft-state, Eventual consistency — ตรงข้ามกับ ACID) ยอมให้อ่านค่าเก่าได้ชั่วคราวเพื่อแลก scale แนวนอน; Strong consistency รับประกันว่าทุก read เห็นค่าล่าสุดเสมอ (ต้อง consensus ก่อน write) แลกกับ latency ที่สูงกว่า — dev เลือกได้ทั้งระดับ database, config, หรือแม้แต่ต่อ query
Data Temperature
| Tier | Access | ตัวอย่าง |
|---|---|---|
| Hot | หลายครั้ง/วันหรือวินาที | SSD, Memory, Cache |
| Warm | เดือนละครั้ง | S3 Infrequent Access |
| Cold | ปีละ 1-2 ครั้ง | Glacier, Tape |
ยิ่ง tier เย็นลง storage cost ยิ่งถูกลง แต่ retrieval cost/latency ยิ่งสูงขึ้น — ควรตั้ง lifecycle policy ให้ข้อมูลไหลจาก hot → warm → cold อัตโนมัติตามอายุ/ความถี่การเข้าถึง แทนที่จะย้ายมือ
Figure 6-9. ต้นทุนของ hot/warm/cold data เทียบกับความถี่ในการเข้าถึง
Separation of Compute from Storage
แนวโน้มสำคัญของ cloud era:
- ข้อดี: ephemeral compute = จ่ายเท่าที่ใช้, data durability ข้าม zones, cost efficiency
- Hybrid: object storage สำหรับ long-term + local storage สำหรับ queries
- ตัวอย่าง EBS (Elastic Block Store): volume แยกจาก host instance แต่ยังอยู่ใน availability zone เดียวกัน (เพื่อ latency ต่ำ) — ข้อมูลจึงอยู่รอดได้แม้ instance ถูกลบ, และ replicate ไปอย่างน้อย 2 host เพื่อกัน disk เสีย
- อนาคต: ความแตกต่างระหว่าง OLAP databases และ data lakes กำลังเลือนลาง
Figure 6-5. EBS replicate ข้อมูลไปหลาย host/disk เพื่อ durability สูง แต่ไม่รอด availability zone ล่ม