“ความเรียบง่ายคือความซับซ้อนขั้นสูงสุด” —เลโอนาร์โด ดา วินชี

“ข้อมูลส่วนใหญ่ไม่เกี่ยวข้องและความพยายามส่วนใหญ่สูญเปล่า แต่มีเพียงผู้เชี่ยวชาญเท่านั้นที่รู้ว่าควรเพิกเฉยอะไร ”—เจมส์ เคลียร์ นิสัยปรมาณู

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

ถ้าคุณไม่ระวัง คุณอาจจบลงด้วยสถานการณ์ต่อไปนี้ตามที่แสดงในวิดีโอความยาวสามนาทีด้านล่าง เราขอแนะนำให้คุณดูก่อนดำเนินการต่อ

ความซับซ้อนเกิดขึ้นเนื่องจากแม้ว่าแต่ละระบบอาจดูเหมือนง่ายบนพื้นผิว แต่จริงๆ แล้วพวกมันนำตัวแปรต่อไปนี้มาสู่ไปป์ไลน์ของคุณและสามารถเพิ่มความซับซ้อนได้มากมาย:

1. โปรโตคอล—ระบบขนส่งข้อมูลอย่างไร (HTTP, TCP, REST, GraphQL, FTP, JDBC)
2. รูปแบบข้อมูล—รูปแบบใดที่ระบบรองรับ (ไบนารี, CSV, JSON, รว์)
3. สคีมาข้อมูลและวิวัฒนาการ—ข้อมูลถูกจัดเก็บอย่างไร? (ตาราง สตรีม กราฟ เอกสาร)
4. SDK และ API—ระบบมี SDK และ API ที่จำเป็นหรือไม่
5. กรดและเบส—มีความสอดคล้องของกรดหรือเบสหรือไม่
6. การย้ายข้อมูล—ระบบมีวิธีง่ายๆ ในการย้ายข้อมูลทั้งหมดเข้าหรือออกจากระบบหรือไม่
7. ความทนทาน—ระบบมีการรับประกันอะไรเกี่ยวกับความทนทาน
8. ความสามารถ—ระบบมีการรับประกันอะไรเกี่ยวกับความพร้อมใช้งาน (99.9%, 99.999%)
9. ความสามารถในการปรับขนาด—ขยายได้อย่างไร
10. ความปลอดภัย—ระบบมีความปลอดภัยเพียงใด
11. ประสิทธิภาพ—ระบบในการประมวลผลข้อมูลเร็วแค่ไหน?
12. ตัวเลือกการโฮสต์—โฮสต์หรือในองค์กรเท่านั้นหรือผสมกัน
13. คลาวด์—ใช้งานบนคลาวด์ ภูมิภาค และอื่นๆ ของฉันได้ไหม
14. ระบบเพิ่มเติม—จำเป็นต้องมีระบบเพิ่มเติมหรือไม่? (เช่น Zookeeper for Kafka)

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

ตอนนี้ คุณอาจโต้แย้งว่าระบบของคุณ แม้ว่าอาจดูซับซ้อน แต่จริง ๆ แล้วเป็นระบบที่ง่ายที่สุดสำหรับความต้องการของคุณ แต่คุณจะพิสูจน์ได้อย่างไร?

กล่าวอีกนัยหนึ่ง คุณจะวัดและบอกได้อย่างไรว่าชั้นข้อมูลของคุณเรียบง่ายหรือซับซ้อนจริงๆ และประการที่สอง คุณจะประเมินได้อย่างไรว่าระบบของคุณจะยังคงเรียบง่ายเมื่อคุณเพิ่มคุณสมบัติเพิ่มเติม นั่นคือ หากคุณเพิ่มคุณสมบัติเพิ่มเติมในแผนงานของคุณ คุณต้องเพิ่มระบบด้วยหรือไม่

นั่นคือที่มาของ "การทดสอบอิมพีแดนซ์ที่ไม่ตรงกัน" แต่ก่อนอื่นเรามาดูว่าอิมพีแดนซ์ที่ไม่ตรงกันคืออะไร จากนั้นเราจะเข้าสู่การทดสอบเอง

อิมพีแดนซ์ไม่ตรงกันคืออะไร

คำนี้มีต้นกำเนิดมาจากวิศวกรรมไฟฟ้าเพื่ออธิบายความไม่ตรงกันของอิมพีแดนซ์ไฟฟ้า ส่งผลให้สูญเสียพลังงานเมื่อพลังงานถูกถ่ายโอนจากจุด A ไปยังจุด B

พูดง่ายๆ ก็คือ สิ่งที่คุณมีไม่ตรงกับสิ่งที่คุณต้องการ ในการใช้งาน คุณต้องใช้สิ่งที่คุณมีอยู่ แปลงเป็นสิ่งที่คุณต้องการ แล้วใช้มัน ดังนั้นจึงมีความไม่ตรงกันและค่าใช้จ่ายที่เกี่ยวข้องกับการแก้ไขที่ไม่ตรงกัน

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

ในโลกของฐานข้อมูล อิมพีแดนซ์ไม่ตรงกันเกิดขึ้นได้จากสองสาเหตุ:

1. ค่าโสหุ้ยในการเปลี่ยนแปลง:วิธีที่ระบบประมวลผลหรือจัดเก็บข้อมูลแตกต่างจากข้อมูลที่ดูเหมือนจริง หรือวิธีที่คุณคิดเกี่ยวกับข้อมูลนั้น ตัวอย่างเช่น:ในเซิร์ฟเวอร์ของคุณ คุณมีความยืดหยุ่นในการจัดเก็บข้อมูลในโครงสร้างข้อมูลจำนวนมาก เช่น คอลเล็กชัน สตรีม รายการ ชุด อาร์เรย์ และอื่นๆ ช่วยให้คุณจำลองข้อมูลได้อย่างเป็นธรรมชาติ อย่างไรก็ตาม คุณต้องแมปข้อมูลนี้ลงในตารางในที่เก็บเอกสาร RDBMS หรือ JSON เพื่อจัดเก็บ จากนั้นทำตรงกันข้ามกับการอ่านข้อมูล โปรดทราบว่าความไม่ตรงกันระหว่างแบบจำลองภาษาเชิงวัตถุและแบบจำลองตารางเชิงสัมพันธ์เรียกว่า “อิมพีแดนซ์เชิงวัตถุไม่ตรงกัน”
2. ค่าโสหุ้ยของไปป์ไลน์:จำนวนข้อมูลและประเภทของข้อมูลที่คุณประมวลผลในเซิร์ฟเวอร์แตกต่างจากจำนวนข้อมูลที่ฐานข้อมูลของคุณสามารถจัดการได้ ตัวอย่างเช่น หากคุณกำลังประมวลผลเหตุการณ์นับล้านที่มาจากอุปกรณ์มือถือ RDBMS ทั่วไปหรือที่เก็บเอกสารของคุณอาจไม่สามารถจัดเก็บได้ หรือจัดเตรียม API เพื่อรวบรวมหรือคำนวณเหตุการณ์เหล่านั้นอย่างง่ายดาย ดังนั้น คุณจึงต้องใช้ระบบประมวลผลสตรีมพิเศษ เช่น Kafka หรือ Redis Streams เพื่อประมวลผลและอาจต้องใช้คลังข้อมูลเพื่อจัดเก็บ

การทดสอบอิมพีแดนซ์ที่ไม่ตรงกัน

เป้าหมายของการทดสอบคือการวัดความซับซ้อนของแพลตฟอร์มโดยรวม และดูว่าความซับซ้อนจะเพิ่มขึ้นหรือลดลงเมื่อคุณเพิ่มฟีเจอร์เพิ่มเติมในอนาคต

วิธีการทำงานของการทดสอบคือเพียงแค่คำนวณ "ค่าโสหุ้ยในการเปลี่ยนแปลง" และ "ค่าโสหุ้ยในท่อส่ง" โดยใช้ "คะแนนอิมพีแดนซ์ที่ไม่ตรงกัน" (IMS) สิ่งนี้จะบอกคุณว่าระบบของคุณซับซ้อนอยู่แล้วเมื่อเทียบกับระบบอื่น และหากความซับซ้อนนั้นเพิ่มขึ้นเมื่อเวลาผ่านไปเมื่อคุณเพิ่มคุณสมบัติเพิ่มเติม

นี่คือสูตรคำนวณ IMS:

สูตรจะเพิ่มค่าโสหุ้ยทั้งสองประเภทแล้วหารด้วยจำนวนคุณสมบัติ ด้วยวิธีนี้ คุณจะได้รับค่าใช้จ่าย/คุณลักษณะทั้งหมด (เช่น คะแนนความซับซ้อน)

เพื่อให้เข้าใจได้ดียิ่งขึ้น ให้เปรียบเทียบไปป์ไลน์ข้อมูลอย่างง่ายสี่แบบและคำนวณคะแนน ประการที่สอง ลองนึกภาพว่าเรากำลังสร้างแอปที่เรียบง่ายในสองขั้นตอน เพื่อให้เราเห็นว่าคะแนน IMS เปลี่ยนแปลงไปอย่างไรเมื่อเราเพิ่มฟีเจอร์เพิ่มเติมเมื่อเวลาผ่านไป

ระยะที่ 1:การสร้างแดชบอร์ดแบบเรียลไทม์

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

กรณีที่ 1:สมมติว่าคุณเพิ่งใช้ RDBMS เพื่อจัดเก็บกิจกรรมเหล่านี้ แม้ว่าตารางอาจไม่พอดี

1. ค่าโสหุ้ยการเปลี่ยนแปลง =1
   1. คุณต้องเปลี่ยนสตรีมเหตุการณ์ให้เป็นตาราง
2. ค่าโสหุ้ยท่อ =1
   1. คุณมีฐานข้อมูลเดียวในไปป์ไลน์ของคุณ
3. จำนวนคุณสมบัติ =1

กรณีที่ 2:สมมติว่าคุณใช้ Kafka เพื่อประมวลผลเหตุการณ์เหล่านี้แล้วจัดเก็บไว้ใน RDBMS

1. ค่าโสหุ้ยการเปลี่ยนแปลง =1
   1. Kafka สามารถจัดการกระแสการคลิกได้อย่างง่ายดาย อย่างไรก็ตาม Kafka ถึง RDBMS เป็นค่าใช้จ่าย
2. ค่าโสหุ้ยท่อ =2
   1. คุณมีสองระบบ (RDBMS และ Kafka) โปรดทราบว่าเรากำลังละเลย Zookeeper
3. จำนวนคุณสมบัติ =1

กรณีที่ 3:สมมติว่าคุณใช้ Kafka เพื่อประมวลผลเหตุการณ์เหล่านี้แล้วจัดเก็บไว้ใน KsqlDB

1. ค่าโสหุ้ยการเปลี่ยนแปลง =0
   1. Kafka สามารถจัดการกับการคลิกสตรีมได้อย่างง่ายดาย
2. ค่าโสหุ้ยท่อ =1
   1. คุณมีเพียงระบบเดียว ( Kafka + KSqlDB) โปรดทราบว่าเรากำลังละเลย Zookeeper
3. จำนวนคุณสมบัติ =1

กรณีที่ 4:สมมติว่าคุณใช้ Redis Streams เพื่อประมวลผลเหตุการณ์เหล่านี้แล้วจัดเก็บไว้ใน RedisTimeseries (ทั้งสองเป็นส่วนหนึ่งของ Redis และทำงานแบบ Natively กับ Redis)

1. ค่าโสหุ้ยการเปลี่ยนแปลง =0
   1. สตรีม Redis สามารถจัดการสตรีมการคลิกได้อย่างง่ายดาย
2. ค่าโสหุ้ยท่อ =1
   1. คุณมีเพียงระบบเดียว (Redis Streams + RedisTimeSeries)
3. จำนวนคุณสมบัติ =1

บทสรุปหลังระยะที่ 1: 

เราเปรียบเทียบสี่ระบบในตัวอย่างนี้ และพบว่า “กรณีที่ 3” หรือ “กรณีที่ 4” นั้นง่ายที่สุดด้วย IMS เท่ากับ 1 ณ จุดนี้ ทั้งสองระบบเหมือนกัน แต่จะเหมือนเดิมหรือไม่เมื่อเราเพิ่มคุณสมบัติเพิ่มเติม ?

มาเพิ่มฟีเจอร์ในระบบของเรากันดีกว่า และดูว่า IMS ทำงานอย่างไร

ระยะที่ 2:การสร้างแดชบอร์ดแบบเรียลไทม์ด้วย IP-Whitelisting

สมมติว่าคุณกำลังสร้างแอปเดียวกัน แต่ต้องแน่ใจว่ามาจากที่อยู่ IP ที่อนุญาตพิเศษเท่านั้น ตอนนี้คุณกำลังเพิ่มคุณสมบัติใหม่

กรณีที่ 1:สมมติว่าคุณเพิ่งใช้ RDBMS เพื่อจัดเก็บเหตุการณ์เหล่านี้ แม้ว่าตารางอาจไม่พอดีและใช้ Redis หรือ MemCached สำหรับ IP-whitelisting

1. ค่าโสหุ้ยการเปลี่ยนแปลง =1
   1. สำหรับการอนุญาต IP คุณไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ อย่างไรก็ตาม คุณต้องแปลงสตรีมเหตุการณ์เป็นตาราง
2. ค่าโสหุ้ยท่อ =2
   1. คุณมี Redis + RDBMS
3. จำนวนคุณสมบัติ =2

กรณีที่ 2:สมมติว่าคุณกำลังใช้ Redis + Kafka + RDBMS

1. ค่าโสหุ้ยการเปลี่ยนแปลง =1
   1. สำหรับการอนุญาต IP คุณไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ นอกจากนี้ Kafka ยังสามารถจัดการกับสตรีมได้อย่างง่ายดาย
2. ค่าโสหุ้ยท่อ =3
   1. คุณมี Redis + Kafka + RDBMS หมายเหตุ:เราไม่สนใจว่า Kafka ต้องการ Zookeeper ด้วย หากคุณเพิ่มตัวเลขนั้น ตัวเลขจะลดลงอีก
3. จำนวนคุณสมบัติ =2

กรณีที่ 3:สมมติว่าคุณกำลังใช้ Redis + Kafka + KsqlDB

1. ค่าโสหุ้ยการเปลี่ยนแปลง =0
   1. สำหรับการอนุญาต IP คุณไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ นอกจากนี้ Kafka และ KsqlDB ยังสามารถจัดการสตรีมได้อย่างง่ายดาย
2. ค่าโสหุ้ยท่อ =2
   1. คุณมี Redis + (Kafka + KsqlDB) หมายเหตุ:ในกรณีนี้ เรากำลังพิจารณา Kafka + KsqlDB เป็นส่วนหนึ่งของระบบเดียวกัน
3. จำนวนคุณสมบัติ =2

กรณีที่ 4:สมมติว่าคุณกำลังใช้ Redis + Redis Streams + RedisTimeSeries

1. ค่าโสหุ้ยการเปลี่ยนแปลง =0
   1. สำหรับการอนุญาต IP คุณไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ นอกจากนี้ Redis Streams และ RedisTimeseries ยังสามารถจัดการสตรีมและการแจ้งเตือนได้อย่างง่ายดาย
2. ค่าโสหุ้ยท่อ =1
   1. คุณมี Redis +  Redis Streams + Redis TimeSeries หมายเหตุ:ในกรณีนี้ ทั้ง 3 รายการเป็นส่วนหนึ่งของระบบเดียวกัน
3. จำนวนคุณสมบัติ =2

บทสรุปหลังระยะที่ 2: 

เมื่อเราเพิ่มคุณสมบัติเพิ่มเติม 

• กรณีที่ 1 อยู่ที่ 2 ในระยะที่ 1 และลดลงเหลือ 1.5
• กรณีที่ 2 อยู่ที่ 3 ในระยะที่ 1 และลดลงเหลือ 2
• กรณีที่ 3 อยู่ที่ 1 ในระยะที่ 1 และยังคงอยู่ที่ 1
• กรณีที่ 4 อยู่ที่ 1 ในระยะที่ 1 และลดลงเหลือ 0.5 (ดีที่สุด)

ในตัวอย่างของเรา กรณีที่ 4 ซึ่งมีคะแนน IMS ต่ำสุดที่ 1 นั้น จริง ๆ แล้วดีขึ้นเมื่อเราเพิ่มคุณสมบัติใหม่ และจบลงที่ 0.5

โปรดทราบ:หากคุณเพิ่มคุณสมบัติเพิ่มเติมหรือแตกต่างกัน กรณีที่ 4 อาจไม่ง่ายที่สุด แต่นั่นเป็นแนวคิดของคะแนน IMS เพียงระบุคุณสมบัติทั้งหมด เปรียบเทียบสถาปัตยกรรมต่างๆ และดูว่าอันไหนดีที่สุดสำหรับกรณีการใช้งานของคุณ

เพื่อให้ใช้งานได้ง่ายยิ่งขึ้น เราขอเสนอเครื่องคิดเลขที่คุณสามารถนำไปใช้ในสเปรดชีตง่ายๆ เพื่อคำนวณคะแนน IMS

เครื่องคิดเลข IMS

วิธีใช้งาน:

1. สำหรับแต่ละชั้นข้อมูลหรือไปป์ไลน์ข้อมูล เพียงแค่ระบุ:
   1. คุณสมบัติที่คุณมีในปัจจุบัน
   2. คุณลักษณะที่อยู่ในแผนงาน นี่เป็นสิ่งสำคัญ เนื่องจากคุณต้องการให้แน่ใจว่าชั้นข้อมูลของคุณสามารถรองรับคุณลักษณะที่กำลังจะมีขึ้นต่อไปโดยไม่ต้องมีค่าใช้จ่ายเพิ่มเติม
2. จากนั้นจับคู่โอเวอร์เฮดการเปลี่ยนแปลงและโอเวอร์เฮดไปป์ไลน์สำหรับแต่ละฟีเจอร์
3. และสุดท้าย หารผลรวมของค่าใช้จ่ายทั้งหมดด้วยจำนวนจุดสนใจ
4. ทำซ้ำขั้นตอนที่ 2 และ 3 สำหรับไปป์ไลน์ที่มีระบบต่างกันเพื่อเปรียบเทียบและเปรียบเทียบ

ไปป์ไลน์ข้อมูล 1

ไปป์ไลน์ข้อมูล 2

สรุป

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

คุณสามารถใช้คะแนน IMS เพื่อเปรียบเทียบและเปรียบเทียบระบบต่างๆ สำหรับกรณีการใช้งานของคุณได้อย่างง่ายดาย และดูว่าระบบใดดีที่สุดสำหรับชุดคุณลักษณะของคุณ คุณยังสามารถตรวจสอบได้ว่าระบบของคุณสามารถรองรับการขยายฟีเจอร์ได้หรือไม่ และยังคงใช้งานได้ง่ายที่สุด

โปรดจำไว้เสมอ:

“ความเรียบง่ายคือความซับซ้อนขั้นสูงสุด” — เลโอนาร์โด ดา วินชี

“ข้อมูลส่วนใหญ่ไม่เกี่ยวข้องและความพยายามส่วนใหญ่สูญเปล่า แต่มีเพียงผู้เชี่ยวชาญเท่านั้นที่รู้ว่าควรเพิกเฉยอะไร ” — James Clear นิสัยปรมาณู