สรุป DevClub#2: Databases @AWS

สำหรับงานนี้จัดที่ AWS ตึก SINGHA COMPLEX ตอนมาก็งงๆ รู้ว่าอยู่แถว มศว ประสานมิตรแหละ พอขึ้น MRT ขึ้นมาก็อ๋อเลย ตรงตึก SINGHA COMPLEX สมัยผมเรียนน่าจะเป็นบ้านท่านทูต หรือ สถานทูตเก่านี่แหละ โดยในวันนี้ผมมาจด 3 หัวข้อ ดังนี้ครับ มาช้านิดนึงวันพฤหัสไปเผางานต่อ

Session 1 - Welcome to the world of Database. How to learn about database?

เริ่มกันด้วย Keyword ของ Database ในมุมต่างๆ

- Type of Databases (Ref: GeeksforGeeks)

• มีแบ่ง Database ตามจุดเด่นของมันได้ประมาณ 8 กลุ่ม ดังนี้ Hierarchical databases / Network databases / Object-oriented databases / Relational databases / Cloud Database / Centralized Database / Operational Database / NoSQL databases
• ถ้าลองดูจาก Type ข้างต้นแล้ว DB หลายๆตัว จัดได้หลาย Type นะเนี่ย PostgreSQL เข้าได้หลายกลุ่มเลย

- Data Vault Tech Landscape

เอามาดู Tech เด่นๆในด้านต่างๆได้ พวก Database มีอยู่ในนี้เหมือนกัน อารมณ์แบบ CNCF Landscape สำหรับในส่วน Database (As of 2022/2023) แยกได้ 2 ส่วน Database+File Systems และ Data Format ถ้าใครสนใจ Data Valut Tech Landscape ตัวเต็มๆก็จิ้มได้เลย

- DB-Engines Ranking (Ref: DB-Engines Ranking)

Database Ranks เผือใครเอาไปใช้ในการตัดสินใจเลือก Stack เพิ่มเติม แอบตกใจ DB2 ยัง Ranking สูง แต่ดูเงียบในไทย และหาข้อมูลยากกว่า DB อื่นๆ

- Type of Databases แบ่งตามมุมมองของ Speaker

ต่อมา Speaker ได้แบ่งตาม Workload ที่ใช้งานประจำ โดยแบ่งเป็น 2 มุม ได้แก่

By Purpose มี 5 ตัว ได้แก่

• Relational databases - ที่คุ้นกัน Table / Row / Pk / Fk
• NoSQL - มีหลายแบบ
  - Key-value
  - Document-oriented
  - Column-oriented
  - Graph-based
  - Time series
• NewSQL (ชื่อนี้ไม่คุ้นเลย) มองว่าเป็น Database ที่ Improve แล้วกัน เช่น
  - Relational databases พยายาม Scale ได้ Distribute / มี In-memory / Cluster ชื่อคุ้นๆหลายตัวนนะ อย่าง Oracle / MS SQL และตัว CockroachDB (อันนี้เพิ่งลองเล่นเต็มช่วงปีใหม่)
  - NoSQL อย่าง MongoDB ที่มีการทำ ACID รองรับ SQL
  Tech มันมี Cycle ในการ Improve.
• OLAP เน้นงาน Batch งาน Data Warehouse / Data Science
• Vector DB - สำหรับงานด้าน AI

By Usage มี 2 กลุ่ม ได้แก่

• Operational DB - Realtime ส่วนใหญ่จะเป็น ลูกค้า เข้ามาใช้ง
• Online Analytic Processing DB ใช้ในงาน Internal ลักษณะของข้อมูลจะเป็นแบบ Near Realtime โดยทำเป็น Cube / Event Driven / Time Series หรือ เอามาดูในมุม Monitoring.

Note: DB หลายเจ้า จัดได้หลาย Type นะ

- ถ้าเลือก หรือ ต้องเรียนรู้ Database ใหม่ๆ เราต้องดูอะไร

• Architecture - บอก Component การทำงานในภาพรวม
• File System (Physical Structure) เก็บยังไง
  - มันมีผล scale
  - กู้ด้วยนะ DB
  - Estimate Size
  - การจะ query / transaction /index
• Data Modeling (Logical Structure) จัดการข้อมูลยังไง พวก Keyword เทียบ RDBMS / NoSQL
  - Schema / Collection
  - Table / Document
  - Column / Field / Properties
  - DataType
  > Common string number bool byte
  > special geo-location / image/ xml
• Database Command
  - DDL - Create / Drop / Alter / Truncate ...
  - DML - SELECT / INSERT / UPDATE / DELETE
  - DCL - Grant / Revoke
  - TCL - Commit / Rollback / Save Point / Tx
  - DQL - Aggregation พวก where / join / group by / order ...
• ACID ส่วนใหญ่จะมีกันหมด

- Atomicity - transaction is treated as a single unit ทำสำเร็จจบ ถ้าไม่ ตี Fail
- Consistency - ใน Single Unit มันต้องสอดคล้อง โอนจาก A -> B เงินหัก A ไปเพิ่ม B เก็บตาม data type / Schema
- Isolation - concurrent transactions โอนเงินพร้อมกัน มันไม่ต้องเข้ามั่ว / หลบ race condition
- Durability - อะไรที่ Commit ไปแล้วสถานะคงเดิม เช่น ปิด DB ไปเปิดมาก็เหมือนเดิม

• Security
  - Authentication
  - Authorization การเข้าถึง Resource พวก Table / Store Proc / Row / Column Permission, View ...
  - Encryption
  - Audit Trails พวก DB กลุ่ม Enterpise มีให้
  - Secure Config พวก Hardening
  - Data Masking ตาม PDPA / GDPR
  - Compliance Regulation พวก ISO PCI-DSS
  - Network / Firewall
• Index
  - Fast Query, but More space
  - Slow Operation (Insert Update Delete) แต่ DB หลายๆเจ้า จะแก้นะ เพิ่ม Process ให้งานเป็น Async
  Algorithm ส่วนใหญ่ Base on B-tree แต่หลายยี่ห้อมีทำเอง
• Clustering / Node (เพิ่มเครื่อง) สำหรับงาน Scale + Distribute แต่การทำแบบนี้ต้องมาทำ Load Balance / Automate Provision / Monitoring / Consensus
• Sharding - Logical Lookup for Cluster
  - 1 table อาจจะกระจายได้หลาย shard ตาม Clustering / Node / Storage class / Geo-location
• Partition - Sharding on the same machine
• Programming Driver เช่น พวก ODBC / ADO.NET / JDBC บราๆ ตาม doc ของแต่ละ db เลย หรือ ถ้าไม่มีจริงๆ SDK ครอบ CLI
• CAP Theorem เลือก 2 จาก 3 Consistency/ Partition Tolerance/ Availability
  พอเลือกไปแล้ว อาจจะต้องเปิดปัญหาตามมา ระบบไม่ใหญ่จะได้ CA แต่ถ้า Scale ไปเยอะๆ จะเป็น AP แล้วไปเพิ่ม Process Reconcile อีก Step แทน C

หัวข้อสุดท้าย อันนี้ผมชอบนะ มองว่าเป็นคำถามที่เอาไว้ถามตัวเอง ถามคนอื่นๆ ในการนำ DB ใหม่มาใช้งานได้ หรือ จะเอาไปเป็น Check List ในการเสนอกับทีมก็ได้ เช่นกัน

Session 2 -Introduction to DynamoDB

- What is DynamoDB

• History DynamoDB เกิดจาก RDBMS Scale เดิม Amazon ออก White Paper และเลยมีทำ DB ตัวเองได้ จนมี Service ตอนปี 2012 ตอนนี้ AWS ใช้เองด้วยนะ
• Performance at Scale เน้น High Request ตัว Latency ยังน้อยอยู่ ทำ horizontal scale แต่ต้อง design scheme ให้ตาม Guideline
• Global Table สร้าง table ตาม geo-location จะได้ลด latency ให้ user
• DynamoDB Accelerator (DAX) - ตัว DB Cache

App <--> DAX <--> DynamoDB

• Serverless ยิ่งผ่าน API
• Secure and Resilient
• Built-in with AWS Service เช่น ทำ OBS Cloud watch / Lamda
• Design for OLTP
• Auto Admin งาน Infra สร้าง Table Partition / งาน DBA เดี๋ยวมันจัดการเอง

- SQL vs NoSQL

• SQL (for Storage) scale vertical/ad-hoc query / OLAP / normalize
• NoSQL(for compute) scale horizontal / instance view เอามาทั้งก้อนได้เลย ไม่ต้อง join ต้อว design / demoralize.

- DynamoDB Table

• ตอนทำงานเรายังยุ่งกับมุมมองที่เป็น Table แต่ DynamoDB จัดการข้างหลังให้ ทำ partition ไหน ส่วนไหน
• Item แทน data โดยจะเป็น Schema Free / Semi Sehema คุ้มบ้าง โดย Table จะเป็น key-value DB
  - Partition Key - ตัวบอกว่า Data เก็บที่ไหน
  - Sort Key (Optional) - 1-N relation / for query ลด Cost การ Update Item
  - Fields เก็บข้อมูลที่เราสนใจ
• Data Type เหมือน DB ปกตินะ แต่จะมีพิเศษ
  - Timestamp ไม่มี เก็บ Number (epoch) / String (ISO 8601 แทน ตัว JSON Date)
• Operation ทำ CRUD ยิ่งผ่าน API รอบรับ ACID
  Write
  - PutItem
  - UpdateItem
  - DeleteItem
  - BatchWriteItem
  - TransactionWriteItems
  Read
  - Query - ระบุ partition key
  - Scan - เอาหมด ใช้ cost เยอะ ใน RDBMS ทำ Table Scan ในที่นี้จะหาทุก Partition
  - GetItem - เอา 1 ตัวตาม partition key + sort key
  - BatchGetItem
  - TransactionGetItems
• SQL - PartiQL

- Global Secondary Index & Local Secondary Index

• GSI = composite index ของ Table ใน Dynamo DB ใช้กรณีที่ patition key + sort key ไม่เหมาะสำหนร
  - ทำ table อีกอันนี้มาเลย เหมือน view แยก Capacity - replicate ผ่าน aws backbone มีค่า storage เพิ่ม
  - แต่ตอน Query จะเป็น Eventual Consistency
• LSI Design เพิ่ม Sort Key
  - ต้องทำตั้งแต่ตอนสร้าง Table
  - ตอน Query จะเป็น Storage Consistency มั่นใจว่าได้ข้อมูลล่าสุดเสมอ

RCUs / WCUs เป็น Cost ที่ต้องใช้ในการ Read / Write

- Under The Hood

• How to Item distribute
  Ans partttion key เอามาเข้า hash เพื่อบอก Parition ที่จัดเก็บ
• ข้อมูลเก็บแยกตาม Avability Zone กระจายในแต่ละ Region โดยจะเก็บใน AZ ไหน Node อะไร
  Ans ตัว AWS จะกำหนด Node Leader ตัวหลังที่ Read/Write ที่เหลือ Follower มันจะมา HeartBeat Check ถ้า Fail ขึ้นมาแทน โดยจะรู้ว่าใคร Node Leader จากตัว Request Rounter
• Storage Consistency vs Eventual Consistency
  - Storage Consistency: Get ข้อมูลจาก Node Leader
  - Eventual Consistency: ดึงจาก Follower อาจจะไม่ได้ข้อมูลล่าสุด แต่ใช้ Cost น้อยกวา่

- Managing Throughput

• Mode
  - On-demamd ตาม request เหมาะตอนเริ่มต้น ระวัง cost แต่ถ้านิ่งแล้ว ทำ provision แทน
  - Provision จองไว้ + Scale

• Why request throttle - Capacity เต็ม เพราะ HW มันมี Limit อยู่ เลยมีระบบ Cost (Token) เข้ามาบอก Credit ตอนใช้่ ถ้า Design Partition Key ไม่ดี อาจจะเจอปัญหานี้ได้
  [1-2] ยิง API เข้า Request Rounter
  [3] Authen
  [4] metadata ของ Partion
  [5] ตรวจ Cost มีสองส่วน Table ของที่ใช้ได้ / Burst บอกส่วนยอมให้เกินก่อนได้
  [6] Query Node - query จะไป node ไหน จะตามตัว partion key เป็นหลัก แต่ถ้า partition key ไหนมีการใช้งานเยอะๆ AWS จะมีตัว Adpative Capacity ช่วย Split Parition ที่มี Access บ่อยๆ ออกมาเป็น แต่ละ partion ใหม่ ทำให้มีตัว capacity เพิ่ม เข้าใจว่าเงินต้องเสียเพิ่มด้วยนะ

จริงๆแล้ว ทำ Obserability จากตัว CloudWatch วัดจาก Metric เช่น Most Accessed Key / Most throttel Key เป็นต้น แล้วจะได้มาลด Cost ในส่วนนี้ลงได้

• Scaling ปรับ Max Throuthput (พวก API Limit / Capacity) มันจะ Base On Peek ล่าสุด 2 เท่า
• พวก Stoage class ปกติจะได้ Tier Standard ถ้าไม่ใช่งานเยอะ ลด Class พวก Infrequent access จะได้ cost ได้ ถ้าไม่ใช้บ่อยๆ

- Recap Feature

• Highlights
  - On-demand Backup
  - TTL บอกอายุ tx เช่น พวก OTP
  - PITR (Point in time Recovery)
  - ACID
  - SQL
• Integration:
  - Change Data Capture เอาข้อมูลตรงนี้ไป Trigger Lamda ได้
  - CloudWatch
  - S3

- Key takeaway

• OLTP not for analyric
• NoSQL จัดการ Relationship ได้ พวก Sorted Key
• Design partion key ดีมีชัยไป
• ถ้ามี access pattern ชัดเจน ย้ายจาก RDBMS มาได้ น่าจะหมายถึงตัว Partition Key แต่ถ้าไม่ได้ใช้ RDS

ฟังจบชนกับ Cosmos DB ได้เลย

Session 3 -Large Scale with TiDB

- Recap แต่ละยุค

• Traditional ACID DB จัดการให้
• Distribute System / Microservice จัดการกันยังไง
  - 2 phases commit (2PC)
  - Try-Confirm Cancel (TC/C)
  - SAGA

แต่พอเรา Distribute

• ACID จะเสียไปต้องมาหาทาง Hanble จัดการเอง ไม่ว่าจะเป็น ด้วยตัว Flow Compensate หรือ จะทำ Reconcile
• ต้องเรียนรู้เยอะ เก็บลงตรงไหน Select จากไหน คุมยังไง

- TiDB

TiDB = Titanium Database

• มาลด Cost ด้าน Operation / Infra ตัว DB เอง
• มันทำ OLTP + OLAP ได้เลย รวมถึงใช้ SQL จัดการได้
• ทำ CAP Theorem AP และพยายามเสริม C ให้ได้ด้วย
• มี Use Case หลายที่ PayPay / PingAn / SPD Bank / China Merchants Bank / UnionPay
  - ข้อมูลเยอะ Tx เยอะ ต้องการ Query Per Second ที่สูง + Low Latency
  - เหมือนได้ยินด้วยว่า ทำ Sharding เสีย Storage ไว้ เอา TiDB มา มันจะลด Cost ส่วนนี้ได้
• TiDB Open-Source นะ pingcap/tidb: TiDB is an open-source, cloud-native, distributed, MySQL-Compatible database for elastic scale and real-time analytics. Try AI-powered Chat2Query free at : https://tidbcloud.com/free-trial (github.com) //ถ้าเอาแบบ Support ติดต่อ PingCAP

- TiDB Architecture

จะแบ่งเป็น 2 Layer ใหญ่ แยกคนจัดการกันได้ ผมมองเป็น L1-TiDB Cluster / L2-Storage Cluster นะ

L1-TiDB Cluster

• TiDB หน้าที่มันรับ SQL แปลงส่งต้องให้ L2
• Application ติดต่อผ่าน Driver ของ MySQL ได้เลย

L2-Storage Cluster

• TiKV (Row Base Store) สำหรับ OLTP
• TiFlash (Columnar Store) สำหรับ OLAP เอามาทำ Analytic

Replicate 3 Node เป็นอย่างน้อย เลขคี่ เพื่อเอามาทำ Concensus ด้วย Raft

ระหว่าง TiDB Cluster / Storage Cluster จะมี Map Metadata โดย PD Cluster

- How TiDB Scale

TiDB > Start with gRPC > Transaction with MVCC > Raft Protocal > RockDB

Raft Protocal

• Election จาก Node
  - Concensus แบ่ง Data ย่อยๆ เค้าจะเรียกว่า Region ผมมองว่าคล้ายกับ Partition ใน Section ก่อนหน้า พอซอยย่อยๆแล้ว มาจัดกลุ่ม Leader เลขคี่ ทำ Concensus อีกที เหมือนใน บริษัท และแบ่งงานส่วนย่อยๆแต่ละหมวเดให้แต่ละกลุ่มไปตัดสินใจ (Concensus) ด้วย Raft Protocal
  - เพิ่ม Node ลด HotSpot
• จากนั้นให้ Follower เชื่อตาม

ผ่านส่วนของ Raft ต่อไปเขียนโดยใช้ RockDB เขียนไว แต่ Read ช้า แก้ได้เพิ่ม Node หรือใช้ TiFlash

- Real Use Case in Thailand

แยกเป็น 3 Site เข้าใจว่า แต่ละ Site ทำ 3 Tier

• Frontend - Load Balance / API
• Backend - มันข้าม Site ได้ได้นะ น่าจะมี LB คั่นอีกที
• DB อันนี้ส่วนของ TiDB แล้ว โดย Backend (App) จะเข้ามาที่ TiDB กระจาย Node หลายอันใน Site เดียวกัน

ถ้า Resource ไม่พอ Site ที่ 3 อาจจะให้ช้าหน่อย ลง Node น้อยหน่อย

- Key Takeaway

• นอกจากใช้ DB ดีแล้ว การออกแบบส่วนอื่นสำคัญด้วย เช่น ถ้าแตกเป็น Microservice แล้ว ต้องให้ business ดูในบางเคสตอน Design ด้วย
• TiDB Open-Source Start ได้เองตอน Dev จาก Container หรือ ไม้ใช้ Cloud ก็ได้
• Scale เพิ่มจำนวน Node ได้ แต่ตอน Concensus ต้องเป็นเลขคี่ เช่น 7 node / 3 Copy (กำหนด Copy เองได้)
• ฝั่ง App ถ้าใช้ MySQL Driver อยู่แล้ว ใช้ได้เลย เริ่มต้น อาจจะใช้ RDBMS อื่นก็ได้ แล้วพอถึงจุดที่ Scale ค่อย Move มาใช้ TiDB ได้นะ เข้าใจว่าถ้าเกรียนหน่อย 1 Cluster 1 Node แต่ไม่แน่ใจว่าทำได้ไหมนะ เคยลองกับ CockroachDB มันยอม)
• ได้เสื้อ TiDB ด้วย อิอิ

Live

เผื่อผมจดหลุดไปมาดูได้ จากทาง CodeBangkok

Reference

• DevClub Tech Meetup#2 | Eventpop | Eventpop