1. Transaction (OLTP) — กระดูกสันหลังของระบบบัญชี#

ตัวที่นิยม: PostgreSQL, Oracle Database, SQL Server, MySQL

Use case: ทุกอย่างที่เป็น “บันทึกธุรกรรม” — ระบบบัญชี, ERP, CRM, ระบบ billing, ระบบจองตั๋ว, ระบบ checkout

ทำไมต้องเป็นตระกูลนี้: เพราะ ACID บังคับ (เคยคุยใน EP.03 — ACID + Enterprise Backbone) — เงินโอนเข้า A ออก B ต้องเสร็จทั้งคู่หรือไม่เสร็จทั้งคู่ ไม่มี “เสร็จครึ่งทาง” OLTP database (Online Transaction Processing) ออกแบบมาเพื่องานนี้โดยเฉพาะ

เคสคลาสสิกในวงการ: บริษัทใหญ่ของไทย — ธนาคาร สายการบิน โรงพยาบาล เทเลคอม — backbone ระบบบัญชี/ERP มักจะเป็น Oracle E-Business Suite หรือ SAP บน Oracle/SQL Server ทันสมัยขึ้นมาหน่อยก็ย้ายมาเป็น PostgreSQL เพื่อหนีค่า license

2. Cache — ของที่อ่านบ่อยต้องอยู่ใกล้มือ#

ตัวที่นิยม: Redis, Memcached, Hazelcast

Use case: lookup ที่อ่านบ่อยมากๆ — user session, profile ของ user ที่ login อยู่, leaderboard ของเกม, การนับ rate limit, การเก็บผลลัพธ์ของ query ที่แพง

ทำไมต้องเป็นตระกูลนี้: เพราะมันเก็บข้อมูลใน RAM ทั้งหมด — response time ระดับ microsecond (หลักหมื่นเท่าเร็วกว่า disk-based DB) ลองนึกถึงพนักงานเสิร์ฟร้านกาแฟที่จำชื่อกาแฟของลูกค้าประจำได้โดยไม่ต้องเปิดสมุด — ลูกค้าเข้ามาปุ๊บ บอก “เหมือนเดิมไหมครับ” ปั๊บ cache คือพนักงานคนนั้น

เคสคลาสสิกในวงการ: Twitter ใช้ Redis เป็น cache layer หลัก, Stack Overflow มี Redis cluster ที่รับ request เป็นพันล้าน operation ต่อวัน, GitHub ใช้ Redis เก็บ session + rate limit

3. Search — ค้นด้วยคำที่อยู่ในเนื้อหา ไม่ใช่ ID#

ตัวที่นิยม: Elasticsearch, OpenSearch, Algolia, Meilisearch

Use case: full-text search (ค้นในเนื้อหา), faceted search (filter ซ้อนกันหลายชั้น), autocomplete, log analytics

ทำไมต้องเป็นตระกูลนี้: เพราะ relational database ใช้ B-tree index ที่เก่งเรื่องค้นด้วย key (เคยคุยใน EP.07 — Index + Query Optimization) — แต่พอเป็นเรื่อง “หาบทความที่มีคำว่า ‘เศรษฐกิจ’ โผล่อยู่ที่ไหนสักที่” — relational ทำได้แต่ช้ามาก Elasticsearch ใช้โครงสร้างคนละชนิดที่เรียกว่า inverted index — แทนที่จะเก็บ “บทความนี้มีคำอะไรบ้าง” มันเก็บ “คำนี้อยู่ในบทความไหนบ้าง” flip มุมแค่นั้นเอง แต่ทำให้ค้น text เร็วขึ้นเป็นพันเท่า

เคสคลาสสิกในวงการ: Wikipedia search ใช้ Elasticsearch, Shopify ใช้สำหรับ product search ของร้านค้าทั่วโลก, GitHub ใช้สำหรับ code search

4. Analytics (OLAP) — สำหรับคำถามผู้บริหาร ไม่ใช่ลูกค้า#

ตัวที่นิยม: Snowflake, Google BigQuery, Amazon Redshift, ClickHouse, Databricks

Use case: BI dashboard, executive report, ad analytics, การ aggregate ข้อมูลปริมาณ TB-PB เพื่อตอบคำถามแบบ “ยอดขายเดือนที่แล้วของสาขาไหนสูงสุด แบ่งตามหมวดสินค้า”

ทำไมต้องเป็นตระกูลนี้: ตรงนี้สำคัญ — มันคือคำตอบของคำถาม “ทำไม transaction DB ทำ analytics ไม่ได้” ที่ผู้บริหารชอบถาม

OLTP database (Postgres, Oracle) เก็บข้อมูลแบบ row-oriented — ข้อมูลของลูกค้า 1 คนเก็บอยู่ติดกันใน disk เป็นแถวเดียว เพราะตอนเรียกใช้งาน เรามักต้องการ “ทุก field ของ customer ID 12345” พร้อมกัน

OLAP database (Snowflake, BigQuery) เก็บข้อมูลแบบ column-oriented — เก็บ “อายุของลูกค้าทุกคน” ติดกันที่หนึ่ง “ยอดซื้อของลูกค้าทุกคน” ติดกันอีกที่หนึ่ง เพราะตอน analytics เรามักต้องการ “average ยอดซื้อของลูกค้าทุกคน” — เราสนใจ column เดียวข้ามล้านแถว ไม่ใช่ทุก column ของ 1 แถว

ลองนึกภาพ — ถ้าจะหา “ค่าเฉลี่ยอายุของพนักงานทั้งบริษัท” จากตู้แฟ้มประวัติพนักงาน 10,000 คน — แบบ row-oriented ต้องเปิดทุกแฟ้ม ดึงเลขอายุ ปิดแฟ้ม ทำซ้ำ 10,000 รอบ แบบ column-oriented เหมือนมีคนทำสมุดแยกที่จดเฉพาะ “อายุ” ไว้ทุกคน — เปิดสมุดเล่มเดียว นับเสร็จในวินาทีเดียว

นอกจากเรื่อง storage ยังมีเรื่อง workload pattern ด้วย — OLTP รับคำสั่งสั้นๆ ปริมาณมากๆ (insert/update ครั้งละ 1 row อ่านครั้งละไม่กี่ row แต่เป็นล้านครั้งต่อวัน) ส่วน OLAP รับคำสั่งยาวๆ ปริมาณน้อย (query ครั้งเดียวสแกน 100 ล้าน row แต่วันละไม่กี่พัน query) — workload คนละโลก ใช้เครื่องมือเดียวกันไม่เวิร์ก

เคสคลาสสิกในวงการ: Snowflake ตอนนี้เป็น default ของบริษัท Fortune 500 จำนวนมาก — เพราะมันแยก storage กับ compute ออกจากกัน (ตามที่คุยใน EP.05 — Cloud-Native) BigQuery เป็น default ของบริษัทที่อยู่บน Google Cloud, Redshift เป็นของฝั่ง AWS

5. Time-Series — ข้อมูลที่เวลาเป็นแกนหลัก#

ตัวที่นิยม: InfluxDB, TimescaleDB, Prometheus, QuestDB

Use case: ข้อมูลที่ append-only ตามเวลา — sensor IoT, application metric, log ของ server, ราคาหุ้น tick-by-tick, การใช้พลังงานของเครื่องจักรในโรงงาน

ทำไมต้องเป็นตระกูลนี้: เพราะข้อมูลพวกนี้มี pattern เฉพาะ — มัน เพิ่ม อย่างเดียว ไม่ค่อยถูก update, query ส่วนใหญ่เป็นแบบ “ค่าของช่วงเวลา X ถึง Y” และข้อมูลเก่าๆ มีค่าน้อยกว่าข้อมูลใหม่ time-series database optimize ทุกอย่างรอบ pattern นี้ — compress ข้อมูลเก่ารัวๆ อ่านช่วงเวลาเร็วเป็นพิเศษ downsample ข้อมูลเก่าอัตโนมัติ

ลองนึกถึง “สมุดบันทึกอุณหภูมิร่างกายของคนไข้ทุก 5 นาที” ของพยาบาล — สมุดนี้ไม่ต้องการ JOIN ไม่ต้องการ relational ซับซ้อน แค่ต้องเขียนเร็ว อ่านเป็นช่วงเวลาเร็ว และเก็บได้ปริมาณมหาศาล time-series คือสมุดแบบนั้น

เคสคลาสสิกในวงการ: Prometheus เป็น default monitoring stack ของวงการ Kubernetes ทั้งโลก, โรงงานสมัยใหม่ที่มี IoT sensor เป็นหมื่นตัวใช้ InfluxDB/TimescaleDB เก็บข้อมูล, Grafana dashboard ที่เห็นในห้อง NOC ของบริษัท IT ส่วนใหญ่ดึงข้อมูลจาก time-series DB

6. Graph — ข้อมูลที่ความสัมพันธ์คือพระเอก#

ตัวที่นิยม: Neo4j, Amazon Neptune, TigerGraph, Memgraph

Use case: social network (Facebook friend graph), fraud detection network (เครือข่ายการโอนเงินที่น่าสงสัย), recommendation engine, knowledge graph, supply chain mapping

ทำไมต้องเป็นตระกูลนี้: เคยคุยใน EP.04 ไปแล้ว — ใน relational เวลาจะหา “เพื่อนของเพื่อนของเพื่อน” ต้อง JOIN ตาราง friend 3 ครั้งซ้อน ตอน user มีล้านคน — JOIN 3 ชั้นใช้เวลาเป็นวินาที ใน graph database เป็นการเดินตามเส้นเชื่อม (edge) ไป 3 hop — ทำใน 50 ms

เคสคลาสสิกในวงการ: LinkedIn ใช้ graph เก็บ connection ระหว่างคน, ธนาคารใหญ่ของโลกหลายแห่งเปิดเผยว่าใช้ graph ในระบบ fraud detection (ตรวจว่าบัญชีใหม่เชื่อมกับเครือข่ายโจรไหม), Google ใช้ knowledge graph เพื่อตอบคำถามแบบ “Tom Hanks อายุเท่าไหร่” ตรงๆ ในหน้า search

7. Document — Schema ที่ยืดหยุ่น#

ตัวที่นิยม: MongoDB, Couchbase, Firebase Firestore, Amazon DocumentDB

Use case: catalog สินค้า (สินค้าแต่ละชิ้น field ไม่เหมือนกัน), CMS, user profile ที่หลายคน fill ไม่เท่ากัน, mobile app backend

ทำไมต้องเป็นตระกูลนี้: เพราะ JSON-native — เก็บโครงสร้างข้อมูลแบบที่ frontend developer ใช้อยู่แล้วโดยตรง ไม่ต้องแปลง

แต่ — และนี่สำคัญมาก — อย่าใช้ document DB เพราะ “มันเทรนด์” (เคยเตือนยาวๆ ใน EP.04) เลือกเพราะข้อมูลมัน “หลากหลายจริงๆ” ไม่ใช่เพราะขี้เกียจคิด schema

เคสคลาสสิกในวงการ: e-commerce ที่ขายสินค้าหลายหมวด (กล้องมีคุณสมบัติคนละชุดกับเสื้อผ้า), CMS ระดับ enterprise, mobile game ที่เก็บ player state แบบยืดหยุ่น

8. Vector — ค้นด้วย “ความหมาย” ไม่ใช่ “คำ”#

ตัวที่นิยม: Pinecone, Weaviate, Qdrant, pgvector (extension ของ Postgres), Milvus

Use case: semantic search (หาเอกสารที่ “ความหมายใกล้เคียง” กับคำถาม), RAG (Retrieval-Augmented Generation ของระบบ AI), recommendation ที่ดูจาก embedding ของพฤติกรรม user

ทำไมต้องเป็นตระกูลนี้: ถ้า Elasticsearch ค้นด้วย “คำที่ตรงกัน” — vector database ค้นด้วย “ความหมายที่ใกล้กัน” เช่น ถ้าค้นคำว่า “หมาเลี้ยงในบ้าน” — Elasticsearch ต้องเจอคำนี้ตรงๆ vector database จะ match กับเอกสารที่พูดเรื่อง “สุนัข” “puppy” “สัตว์เลี้ยงในครอบครัว” ได้หมด เพราะมันเทียบที่ “ความหมาย” ไม่ใช่ตัวอักษร

ตระกูลนี้คือพระเอกของยุค AI เพราะ LLM ทุกตัวพูด “ภาษา embedding” — เราจะเจาะลึกเรื่อง vector database, embedding คืออะไร, ทำไม RAG ถึงเปลี่ยนวงการ enterprise software ใน EP.15 — Vector Database + AI Era ของ Part 5

8 ตระกูลนี้คือ “หมวดเครื่องครัว” หลักของ enterprise ปี 2026 ทีนี้พอเรามี database หลายตัว — คำถามถัดมาคือ แล้วเก็บข้อมูลรวมกันที่ไหน

Data Warehouse (DW) — โกดังที่จัดของเป็นระเบียบก่อนเก็บ#

ตัวที่นิยม: Snowflake, Amazon Redshift, Google BigQuery, Teradata (รุ่นเก่า)

แนวคิด: เก็บเฉพาะ structured data ที่ผ่านการทำความสะอาดและจัดรูปแบบมาแล้ว — มี schema-on-write หมายความว่า ก่อนเก็บข้อมูลเข้ามา ต้องบอกล่วงหน้าว่า data หน้าตาเป็นยังไง column อะไรบ้าง

Analogy: เหมือนคลังสินค้าของห้างที่มีกฎเข้ม — ของทุกชิ้นต้องติดบาร์โค้ด ติดป้ายราคา ใส่กล่องตามขนาด ก่อนวางบนชั้น พอจะหยิบออก หยิบง่ายมาก ทุกอย่างเป็นระเบียบ

ข้อดี: query เร็ว, schema ชัดเจน, นัก BI / data analyst ใช้ SQL ปกติได้, ผลลัพธ์น่าเชื่อถือ

ข้อเสีย: เก็บได้แค่ structured data, การเปลี่ยน schema ทีหลังเจ็บปวด, cost สูง (ต้อง process ข้อมูลก่อนเก็บ)

Data Lake (DL) — บ่อน้ำที่โยนทุกอย่างลงไปก่อน#

ตัวที่นิยม: S3 + Parquet (AWS), Azure Data Lake Storage, Google Cloud Storage

แนวคิด: เก็บ raw data ทุกแบบ — structured (ตาราง), semi-structured (JSON, XML), unstructured (รูป, video, audio, PDF) ลงในที่เดียว — มี schema-on-read หมายความว่า กำหนด schema ตอนจะอ่านขึ้นมาใช้ ไม่ใช่ตอนเขียน

Analogy: เหมือนโกดังเก่าใหญ่ ใครจะเอาของอะไรมาวางก็วาง ไม่ต้องติดป้าย ไม่ต้องจัดเรียง พอจะหยิบของออก ค่อยสำรวจว่ามีอะไรอยู่ตรงไหน

ข้อดี: cost ถูกที่สุด (S3 ราคาถูกมาก), เก็บได้ทุกชนิดข้อมูล, ไม่ต้องคิด schema ล่วงหน้า, เก็บไว้ก่อนแล้วใช้ทีหลังได้

ข้อเสีย: ถ้าไม่มีคนรู้ว่ามีอะไรอยู่ตรงไหน — กลายเป็น “data swamp” (บึงข้อมูล) — ของกองอยู่เป็น TB แต่ไม่มีใครหาเจอ. การ query ตรงๆ จาก data lake ช้ามาก ต้องมี query engine แยก (เช่น Presto, Trino, Athena)

Data Lakehouse (DLH) — รวมข้อดีของทั้งสองโลก#

ตัวที่นิยม: Databricks, Apache Iceberg, Delta Lake, Apache Hudi

แนวคิด: เก็บข้อมูลแบบ data lake (cost ถูก, ทุกชนิด) + วาง layer ที่มีคุณสมบัติของ data warehouse ทับด้านบน (schema, ACID transaction, time travel, indexing)

Analogy: เหมือนโกดังที่มีระบบจัดเก็บแบบสองชั้น — ของยังวางบนชั้นถูกๆ เหมือนเดิม แต่มีระบบ tag + catalog ที่บอกว่ามีอะไรอยู่ตรงไหน + บันทึกว่าใครเอาไปไหนเมื่อไร + ย้อนกลับไปดูสภาพเมื่อ 3 เดือนก่อนได้ (time travel)

คุณสมบัติที่สำคัญ:

• ACID transaction บนไฟล์ใน data lake — ไม่เคยมีมาก่อนในยุค data lake แบบดั้งเดิม
• Schema evolution — เปลี่ยน schema ได้โดยไม่ต้องเขียนข้อมูลใหม่ทั้งหมด
• Time travel — ดูสภาพข้อมูลย้อนหลังเมื่อวันที่ X ได้
• Open format — ใช้ Parquet + metadata layer ที่ใครก็ใช้ได้ ไม่ผูกกับ vendor

ตัวที่กำลังโตเร็วที่สุดในปี 2026 คือ Apache Iceberg ที่กลายเป็น default format ของวงการ — Snowflake, Databricks, BigQuery, AWS ทุกค่ายรองรับ ทำให้ enterprise ไม่ผูกกับ vendor ใดเดียว

Lakehouse คือทิศทางที่ enterprise ใหม่ๆ เลือก เพราะมันลด cost ลง 50-70% เทียบกับมี DW + DL แยก แต่ได้ feature ทั้ง 2 ชุด

มุมผู้บริหาร: ถ้าบริษัทยังเก็บ data warehouse + data lake แยกกัน 2 ระบบ — ปี 2026 น่าจะถึงเวลาที่ทีม data ของคุณคุยเรื่อง consolidate มาเป็น lakehouse แล้ว ค่า license + ค่าดูแลที่ลดลงคืน ROI ของโปรเจกต์ migrate ได้ภายใน 1-2 ปีในเคสส่วนใหญ่

ETL (Extract → Transform → Load) — ยุค 1990s-2010s#

ขั้นตอนคือ:

1. Extract ข้อมูลจาก source (Oracle, ERP, CRM)
2. Transform บน server กลาง (clean, join, aggregate, แปลงรูปแบบ)
3. Load เข้า data warehouse

ตัว tool คลาสสิค: Informatica PowerCenter, IBM DataStage, Microsoft SSIS, Talend

ทำไมเคยเป็นแบบนี้: เพราะสมัยก่อน data warehouse แพงมาก compute power จำกัด ต้องประมวลผล “นอก” warehouse ก่อนแล้วค่อยโหลดเฉพาะของที่พร้อมใช้แล้วเข้าไป

ปัญหาของยุค ETL:

• transformation logic อยู่ที่ ETL server — เปลี่ยนทีต้องไปแก้ที่ tool ETL
• ถ้าจะเพิ่ม transformation ใหม่ — ต้องดึงข้อมูลใหม่จาก source อีกรอบ
• ETL server กลายเป็น bottleneck พอ data โต

ELT (Extract → Load → Transform) — ยุค Cloud (2015+)#

flip ลำดับ:

1. Extract จาก source
2. Load raw ข้าม cloud DW (Snowflake/BigQuery) ทันที — ไม่ transform
3. Transform ภายใน DW โดยใช้ compute power ของ DW เอง

ตัว tool ยุคใหม่:

• Extract + Load: Fivetran, Airbyte, Stitch
• Transform ใน DW: dbt (data build tool)

ทำไมเปลี่ยน: เพราะ cloud DW อย่าง Snowflake/BigQuery แยก storage กับ compute ออกจากกัน — เพิ่ม compute ทีละชั่วโมงได้ตามต้องการ ราคาถูกลง การ transform ใน DW จึงคุ้มกว่าซื้อ ETL server แยก ข้อดีอีกอย่างคือ — raw data ยังอยู่ใน DW เสมอ ถ้าวันหนึ่ง business ถามคำถามใหม่ที่ต้องใช้ field ที่เคยถูก ETL ตัดทิ้ง — ก็ดึงจาก raw มา transform ใหม่ได้ทันที ไม่ต้อง re-extract จาก source

Reverse ETL — ยุค 2020s#

แล้วก็มาถึงยุคล่าสุด — Reverse ETL ที่ flow กลับด้าน

แทนที่จะดึงข้อมูลจาก operational system → DW (ETL/ELT ปกติ) — Reverse ETL คือ sync ข้อมูลจาก DW กลับไปยัง operational system เช่น sync customer score จาก DW กลับไปที่ Salesforce, sync segment ของ user กลับไปที่ HubSpot, sync product recommendation กลับไปที่หน้าเว็บ

ตัว tool: Census, Hightouch, Polytomic

ทำไมต้องมี: เพราะ insight ที่ data team สร้างใน DW (เช่น “customer คนนี้ความเสี่ยงเลิกใช้สูง”) — ต้องส่งกลับให้ทีม sales/marketing ใช้งานในเครื่องมือที่เขาคุ้นเคย (Salesforce, HubSpot) ไม่ใช่บังคับให้ทุกคนเข้า dashboard ของ DW เอง

วงการเรียก pattern ใหม่นี้ว่า “Operational Analytics” — analytics insight ที่ feed กลับ business workflow ตรงๆ ไม่ใช่จบแค่ใน dashboard

สรุป pattern ปัจจุบัน: Source → ELT → DW/Lakehouse → Transform (dbt) → Reverse ETL → Operational system

นี่คือสาเหตุที่ตำแหน่ง “Analytics Engineer” และ “Data Engineer” ที่เน้น dbt + Fivetran + Snowflake / Databricks กลายเป็นตำแหน่งฮอตสุดของวงการ data ในช่วง 5 ปีที่ผ่านมา

Anti-pattern 1: MongoDB ที่ควรจะเป็น Postgres#

ทีม dev เลือก MongoDB เพราะ “modern” + “schema-less ดี” + “JavaScript ใช้ได้สบาย” 2-3 ปีต่อมา ระบบโตขึ้น เริ่มเจอความเป็นจริง — ข้อมูล business ของบริษัทมี relational กันจริงๆ (order ↔ customer ↔ product ↔ invoice) MongoDB ไม่มี JOIN ที่ดี ไม่มี ACID transaction ข้าม document ที่ scalable สุดท้าย application code ต้อง simulate transaction เอง + aggregate ข้อมูลฝั่ง app ที่ใช้ memory มหาศาล

ทางแก้: เริ่มที่ Postgres เสมอ ถ้าไม่มีเหตุผลชัดเจนว่าทำไมต้อง NoSQL — ปัจจุบัน Postgres รองรับ JSON column ได้ดีมาก ทำตัวเป็น document DB ได้ในกรณีที่ต้องใช้

Anti-pattern 2: Single DB สำหรับทุก use case#

ตรงข้าม anti-pattern แรก — ทีมที่ “stick กับ Postgres ตัวเดียวทำทุกอย่าง” จนถึงจุดที่ Postgres ทำ analytics 100M row ของยอดขาย 5 ปี — query ใช้เวลา 30 นาที หรือใช้ Postgres เป็น cache แทน Redis แล้ว connection pool หมด

ทางแก้: ยอมรับว่า Polyglot Persistence เป็นเรื่องปกติ แยก OLTP กับ OLAP ออกจากกันด้วย ELT pipeline ตั้งแต่ traffic ระดับล้าน user ขึ้นไป

Anti-pattern 3: ETL ที่ run รายเดือน#

ทีม BI ใช้ Informatica หรือ SSIS รัน ETL job เดือนละครั้ง — ทุก dashboard ของผู้บริหารเป็นข้อมูลของเดือนที่แล้ว ทุกการตัดสินใจอยู่บน data ที่ “stale ไป 30 วัน” ในยุคที่คู่แข่งเห็นข้อมูลภายในชั่วโมง — ผู้บริหารบริษัทคุณตัดสินใจช้ากว่า 1 เดือน

ทางแก้: ย้ายมา ELT + dbt + cloud DW ที่ schedule รัน job ได้รายชั่วโมง / รายนาที เคสที่ต้องการ real-time จริงๆ — เพิ่ม CDC + Debezium + Kafka