Postgres vs Kafka: การถกเถียงเรื่องการใช้ฐานข้อมูลเป็นคิวร้อนแรงขึ้น

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

ปริศนาด้านประสิทธิภาพ

หัวใจของข้อโต้แย้งอยู่ที่การเปรียบเทียบประสิทธิภาพที่ทำให้นักวิศวกรรมหลายคนต้องฉงน ผู้แสดงความคิดเห็นหนึ่งคนชี้ให้เห็นถึงความแตกต่างที่ชัดเจน: ผลลัพธ์ที่พวกเขาได้จากการตั้งค่า 96 vCPU นั้น สามารถบรรลุได้ด้วย Kafka บนการตั้งค่า 4 vCPU ตัวเลขบอกเล่าเรื่องราวที่น่าสนใจ – ในขณะที่ PostgreSQL สามารถจัดการข้อความได้หลายพันข้อความต่อวินาที แต่โซลูชันที่เข้ากันได้กับ Kafka อย่าง Redpanda ได้แสดงขีดความสามารถในการประมวลผลข้อความได้หลายแสนข้อความต่อวินาทีบนฮาร์ดแวร์ที่ทรงพลังน้อยกว่ามาก

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

การได้ปริมาณงานที่น้อยกว่านั้นบน 3x c7i.24xlarge — รวมทั้งหมด 288 vCPU – เป็นการสิ้นเปลืองอย่างน่างงงัน

การเปรียบเทียบประสิทธิภาพ: PostgreSQL เทียบกับ Kafka Solutions

ข้อโต้แย้งด้านความเรียบง่าย

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

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

กรอบความคิดเรื่องเครื่องมือที่เหมาะสม

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

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

ความจริงเรื่องการขยายขนาด

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

ข้อจำกัดที่สำคัญอีกประการที่กล่าวถึงคือการขาดฟังก์ชันกลุ่มผู้บริโภค (consumer group) โดยธรรมชาติที่ทำให้ Kafka มีประสิทธิภาพมากสำหรับการประมวลผลแบบกระจาย ดังที่วิศวกรคนหนึ่งอธิบาย 'สิ่งที่ดีเกี่ยวกับ Kafka consumer groups คือมันทำให้การกระจายโหลดไปยังอินสแตนซ์หลายอินสแตนซ์ที่รันบริการของคุณเป็นเรื่องง่าย' การสร้างฟังก์ชันนี้ซ้ำใน PostgreSQL ต้องใช้การพัฒนาที่กำหนดเองอย่างมีนัยสำคัญ

ต้นทุนของความซับซ้อน

การถกเถียงไม่ใช่แค่เกี่ยวกับขีดความสามารถทางเทคนิคเท่านั้น - มันยังเกี่ยวกับต้นทุนของมนุษย์และองค์กรจากความซับซ้อนอีกด้วย ผู้แสดงความคิดเห็นหลายคนกล่าวถึงปรากฏการณ์ของการออกแบบที่ขับเคลื่อนโดยเรซูเม่ (resume-driven design) ซึ่งวิศวกรนำเทคโนโลยีที่ซับซ้อนเข้ามาเป็นหลักเพื่อพัฒนาทักษะของพวกเขา แทนที่จะแก้ไขปัญหาธุรกิจในทันที ซึ่งสามารถทำให้ทีมต้องดิ้นรนกับโซลูชันที่ถูกออกแบบให้ซับซ้อนเกินไปนานหลังจากที่ผู้ออกแบบดั้งเดิมย้ายไปแล้ว

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

เมื่อไหร่ควรเลือกแต่ละโซลูชัน

เลือก PostgreSQL เมื่อ:

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

เลือก Kafka เมื่อ:

• คุณต้องการประมวลผลข้อความหลักแสนรายการต่อวินาที
• คุณต้องการฟังก์ชัน consumer group แบบเนทีฟ
• คุณต้องการความสามารถในการประมวลผลแบบ exactly-once
• ทีมของคุณมีความเชี่ยวชาญใน Kafka หรือสามารถลงทุนเพื่อเรียนรู้
• คุณได้ตรวจสอบแล้วว่าความต้องการในการขยายขนาดของคุณคุ้มค่ากับความซับซ้อนที่เพิ่มขึ้น

การหาจุดสมดุล

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

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

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

อ้างอิง: Kafka is taxi — Till I use Postgres