การเปลี่ยนจากข้อมูลเชิงสัมพันธ์ไปสู่อีเวนต์

 (event-driven.io)
2 คะแนน โดย GN⁺ 2023-12-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

คู่มือการเปลี่ยนจากข้อมูลเชิงสัมพันธ์ไปสู่อีเวนต์

  • ในแนวคิด event sourcing ข้อมูลทางธุรกิจจะถูกเก็บรักษาเป็นอีเวนต์โดยไม่สูญหาย
  • อีเวนต์แสดงถึงข้อเท็จจริงที่เกิดขึ้น และจะถูกบันทึกหลังจากการทำงานแต่ละครั้ง
  • event stream คือรายการของอีเวนต์ทั้งหมดที่ถูกบันทึกไว้ มีคุณสมบัติไม่เปลี่ยนแปลง และสามารถแก้ไขความผิดพลาดในอดีตได้ด้วยการเพิ่มอีเวนต์ใหม่

1. ค้นหาคอลัมน์สถานะ

  • ค่าของคอลัมน์สถานะอาจสะท้อนช่วงต่างๆ ในวงจรชีวิตของข้อมูล
  • ตัวอย่างเช่น คำสั่งซื้ออาจเริ่มต้น ถูกจัดส่ง หรือชำระเงินแล้ว
  • สถานะเหล่านี้สามารถแปลงเป็นอีเวนต์อย่าง Order Initiated, Order Shipped, Order Paid ได้

2. ตรวจสอบคอลัมน์วันที่

  • คอลัมน์วันที่อาจให้ข้อมูลเกี่ยวกับเหตุการณ์สำคัญในกระบวนการ
  • เช่น ShipmentDate, DeliveryDate, OrderPlacementDate ซึ่งช่วยบอกคำศัพท์ทางธุรกิจและช่วยในการนำอีเวนต์ใหม่เข้ามาใช้

3. วิเคราะห์ selectivity ของคอลัมน์

  • คอลัมน์ที่เป็น Nullable อาจเป็นข้อมูลที่ให้ภายหลังหรือเป็นทางเลือก
  • คอลัมน์บังคับควรถูกส่งมาในอีเวนต์ Order Initiated แรก

4. ค้นหาตารางที่มีความสัมพันธ์แบบ 1 ต่อ หลาย มากที่สุด

  • ใน event sourcing จะจัดกลุ่มข้อมูลโดยมี business process เป็นศูนย์กลางเพื่อให้ประมวลผลได้อย่างมีประสิทธิภาพ
  • ตารางที่มีความสัมพันธ์แบบ 1 ต่อ หลาย จำนวนมาก อาจเป็นตัวเลือกที่ดีสำหรับประเภทของสตรีม

5. เพิ่มอีเวนต์แบบชัดเจน

  • เมื่อต้องย้ายข้อมูลเชิงสัมพันธ์ไปเป็นอีเวนต์ ไม่ควรนำอีเวนต์ที่ค้นพบใหม่มาใช้ซ้ำระหว่างการ import แต่ควรระบุอีเวนต์ Order Imported อย่างชัดเจน

6. ทดลองและตรวจสอบ

  • ลองทำต้นแบบในสภาพแวดล้อมที่ปลอดภัย เปรียบเทียบผลลัพธ์กับที่คาดไว้ และทำซ้ำอย่างไม่เร่งรีบ

ความเห็นของ GN⁺

  • ประเด็นสำคัญที่สุดของบทความนี้คือความสำคัญของแนวทางใหม่ในการเก็บรักษาข้อมูลทางธุรกิจระหว่างการเปลี่ยนจากฐานข้อมูลเชิงสัมพันธ์ไปสู่ event sourcing
  • เหตุผลที่บทความนี้น่าสนใจคือมันนำเสนอวิธีที่ช่วยให้เข้าใจและใช้ประโยชน์จากวงจรชีวิตของข้อมูลได้ดีกว่ารูปแบบการจัดการข้อมูลแบบเดิม
  • event sourcing อาจช่วยสร้างความเข้าใจร่วมกันระหว่างทีมธุรกิจและทีมเทคนิคได้ ไม่ใช่แค่ในมุมมองทางเทคนิคเท่านั้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-18
ความคิดเห็นบน Hacker News

  • แนะนำให้ใช้ PostgreSQL และเครื่องมือรายงานแบบ FOSS

    • หากในแอปพลิเคชันใช้งาน PostgreSQL อยู่แล้ว ก็แนะนำให้เก็บข้อมูลอีเวนต์ไว้ใน PostgreSQL และใช้เครื่องมือรายงานแบบ FOSS (เช่น Apache Superset, Metabase)
    • ใช้ PostgreSQL ไปจนกว่าข้อมูลจะมีขนาดราว 2TB แล้วหลังจากนั้นค่อยตัดสินใจว่าจำเป็นต้องให้ข้อมูล 2TB ทั้งหมดออนไลน์อยู่หรือไม่ หรือว่าต้องการเพียงข้อมูลสรุปรายวัน/รายชั่วโมง
    • ในกรณีของลูกค้ารายหนึ่ง มีการประมวลผลข้อมูลมากกว่า 10TB และอีเวนต์ 1,500 รายการต่อวินาที โดยเก็บข้อมูลละเอียดไว้แบบออนไลน์ 2 วัน จากนั้นสรุปข้อมูลส่วนที่เหลือแล้วย้ายไป S3 เพื่อให้ query ได้ผ่าน Athena SQL
    • ใช้ AWS RDS Multi-AZ เพื่อรองรับการ failover อัตโนมัติ และมีวิศวกรเพียงคนเดียวที่ดูแลทั้งหมดโดยใช้เวลาไม่ถึง 5 ชั่วโมงต่อเดือน
    • PostgreSQL มอบระบบเดียวสำหรับเก็บข้อมูลไว้ในที่เดียว เรียนรู้ ดูแล และขยายระบบได้
    • บุคลากรที่ไม่ใช่สายเทคนิคก็สามารถสร้างกราฟได้ง่ายในระบบอย่าง Metabase หรือ Preset
    • PostgreSQL พัฒนาขึ้นทุกปี และหากจำเป็นก็สามารถขยายเพิ่มได้ผ่านระบบที่เข้ากันได้กับ PostgreSQL (เช่น Aurora, TimescaleDB, CitusDB)

  • ช่วงเวลาที่เหมาะสมในการใช้สถาปัตยกรรมแบบ event-driven

    • หากลูกค้าทำบางอย่างแล้วคาดหวังการตอบกลับ นั่นไม่ใช่ event-driven แต่เป็นรูปแบบ request/response
    • event-driven หมายถึงกรณีที่บางอย่างเกิดขึ้นในสถานการณ์ที่ไม่ได้คาดไว้ล่วงหน้า เช่น เมื่อ push โค้ดไปยัง GitHub แล้วมีการ trigger การ build

  • การแชร์ประสบการณ์ที่ค่อนข้างไม่เชื่อมั่นต่อ event sourcing

    • ทีมหนึ่งเคยพิจารณาใช้ event sourcing แต่สุดท้ายตัดสินใจไม่ใช้ เพราะไม่เห็นข้อดีที่ชัดเจนและมองว่าการลองสิ่งใหม่มีความเสี่ยง
    • ไม่ได้รู้สึกเสียดายที่พลาดโอกาสเรียนรู้ และมองในแง่บวกว่าอย่างน้อยก็ไม่ได้กระโดดเข้าไปแก้ปัญหาที่ซับซ้อนโดยไม่จำเป็น

  • ประโยชน์ของการทำ domain event modeling

    • domain event modeling มีประโยชน์ในการสื่อสารกับผู้เชี่ยวชาญโดเมนที่กำลังร่วมกันแก้ปัญหา
    • หากต้องการสร้างระบบที่ให้ audit trail ของ state machine ในช่วงเวลายาวนาน การใช้เครื่องมืออย่าง Temporal.io/durable functions จะเหมาะสมกว่า
    • เครื่องมือเหล่านี้ใช้ event sourcing ภายในอยู่แล้ว และบังคับให้เขียนโค้ดโดยคำนึงถึง deduplication และ idempotency

  • คำถามเกี่ยวกับการนำ event sourcing ไปใช้จริง

    • ยังขาดคำอธิบายเกี่ยวกับวิธี reconstruct สถานะปัจจุบันจาก event stream อย่างมีประสิทธิภาพ และวิธี model event stream ในฐานข้อมูล

  • bottom-up เทียบกับ top-down, แบบปรับแต่งเฉพาะ เทียบกับแบบทั่วไป

    • แนวทางแบบ top-down เริ่มจาก business domain แล้วค่อยแมปการใช้งานให้เข้ากับเทคโนโลยี เครื่องมือ และผู้ขายที่มีอยู่
    • แนวทางแบบ bottom-up เริ่มจากเทคโนโลยี เครื่องมือ และผู้ขายที่มีอยู่ แล้วประกอบกันเป็นโซลูชันที่ใช้งานได้
    • แนวทางแบบปรับแต่งเฉพาะรวมถึง DDD, CQRS/ES, Sagas, TBUI, GraphQL, algebraic data types เป็นต้น
    • แนวทางแบบทั่วไปประกอบด้วย RDBMS, CRUD, REST, ACID transactions, CDC, UI สำหรับการจัดการแบบทั่วไป, no-code/low-code, limited/general-purpose types เป็นต้น

  • ทั้งสนับสนุนและวิจารณ์สถาปัตยกรรมแบบ event-based

    • มีท่าทีสนับสนุนสถาปัตยกรรมแบบ event-based แต่บทความนี้สื่อสารข้อโต้แย้งของตัวเองได้ไม่ชัดเจน
    • หากโฟกัสที่ความแตกต่างระหว่างความสัมพันธ์ของข้อมูลกับพฤติกรรมทางธุรกิจ ก็จะเห็นชัดขึ้นว่าทำไมจึงควรถอยออกจาก relational data store สำหรับงานปฏิบัติการ

  • event sourcing กับความจำเป็นของความเป็นเชิงสัมพันธ์

    • แม้ event sourcing จะมีข้อดีหลายอย่าง แต่ก็ยังต้องการความเป็นเชิงสัมพันธ์อยู่ดี
    • หากความเป็นเชิงสัมพันธ์ทั้งหมดถูกซ่อนไว้โดยนัยในโค้ดชั้น application อย่างเดียว ก็ถือว่ายอมรับไม่ได้
    • จำเป็นต้องมีวิธี query ความสัมพันธ์เหล่านั้น หรือทำให้มุมมองเชิงสัมพันธ์อัปเดตอยู่เสมอ

  • การสนับสนุนข้อมูลเชิงสัมพันธ์

    • ตัดสินใจหลีกเลี่ยงความซับซ้อนและยึดตามข้อมูลเชิงสัมพันธ์แบบดั้งเดิม

  • มุมมองใหม่ต่อการออกแบบแบบ event-driven

    • เพิ่งได้รู้จักการออกแบบแบบ event-driven เมื่อไม่นานมานี้ และระหว่างที่กำลังคิดถึงโครงสร้างข้อมูลที่เหมาะสมที่สุดในโลกที่ AI มีบทบาทครอบงำ ก็ได้ข้อสรุปคล้ายกัน
    • มองว่าหากการออกแบบแบบ event-driven ช่วยจัดการความซับซ้อนและทำให้สามารถนำข้อมูลไปใช้ได้จริง ก็ถือว่ามีคุณค่า
    • คาดว่าในอีกไม่กี่ปีข้างหน้า เมื่อ AI สามารถมีความรู้เกี่ยวกับทุก business event และ query ได้ การออกแบบแบบ event-driven จะกลายเป็นเรื่องแพร่หลาย