Perf อย่างเดียวไม่พอ

 (motherduck.com)
2 คะแนน โดย GN⁺ 2024-03-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

วัฒนธรรมหมกมุ่นกับประสิทธิภาพของฐานข้อมูล

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

จุดจบของสงครามเบนช์มาร์ก

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

ความหมายของคำว่าเร็ว

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

ประสิทธิภาพเป็นเรื่องอัตวิสัย

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

ความเร็วของการเปลี่ยนแปลง

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

ไม่มีถั่ววิเศษ

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

ปัญหาอยู่ระหว่างเก้าอี้กับคีย์บอร์ด และระหว่างคีย์บอร์ดกับฐานข้อมูล

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

ว่าด้วยองุ่นเปรี้ยว

  • ตอนนี้ DuckDB ติดอันดับต้น ๆ ในเบนช์มาร์ก ClickBench และ h20.ai และยังทำผลงานได้ไม่เลวใน TPC-H และ TPC-DS
  • ก่อนจะสรุปว่าฐานข้อมูลใดเร็ว ควรลองกับเวิร์กโหลดจริงของตัวเองก่อน

บทสรุป

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

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

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

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

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

 
GN⁺ 2024-03-12
ความเห็นจาก Hacker News

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

    • ความเห็นนี้แสดงความผิดหวังที่ Google "มองไม่เห็นอย่างสิ้นเชิง" ต่อคำร้องเรียนของลูกค้า และไม่ได้ใช้ผลิตภัณฑ์ของตัวเอง โดยเฉพาะประเด็น JDBC ที่น่าประทับใจมาก
  • Google สร้างฐานข้อมูลที่ทำงานได้ดีภายในองค์กร แต่เลเยอร์ตัวปรับให้เข้ากับโลกภายนอกถูกจ้างคนนอกทำ และมันทำงานได้ไม่ดี ทำให้โลกภายนอกต้องใช้ฐานข้อมูลที่มีคุณภาพแย่ แกนกลางที่ซับซ้อนและดีที่ Google ใช้งานถูกห่อหุ้มด้วยอะแดปเตอร์ที่ไม่สมบูรณ์ ส่งผลให้ภาพรวมออกมาเละเทะโดยไม่จำเป็น ภายในองค์กรกลับไม่ตระหนักถึงเรื่องนี้ และคนนอกก็ยากที่จะมองออก
    • ความเห็นนี้มองว่าเป็นคำอธิบายที่เหมาะสมอย่างมากต่อกลยุทธ์โอเพนซอร์สของ Google
  • คิดว่าการที่บล็อกอ้างว่า "ประสิทธิภาพเป็นเรื่อง主觀" เป็นเรื่องแปลก การวัดประสิทธิภาพอย่างเดียวอาจไม่เพียงพอ แต่ในตัวอย่างเดียวที่ยกมา ประสิทธิภาพนั้นสำคัญและเป็นเรื่องเชิงวัตถุวิสัย เพียงแค่วัดผิดสิ่งเท่านั้น
    • ความเห็นนี้ตั้งข้อสงสัยต่อข้ออ้างของบล็อกเกี่ยวกับการวัดประสิทธิภาพ
  • ฟังดูเหมือนนี่เป็นปัญหาด้านโครงสร้างองค์กรของบริษัท หากเป้าหมายสุดท้ายคือทำให้ลูกค้าใช้งานคลาวด์และได้รับคุณค่า ก็ไม่ควรมีเมตริกที่ต่างจากสิ่งที่ลูกค้าให้ความสำคัญ ภายใน Google ควรมีคนที่รับฟังปัญหาของลูกค้าอย่างจริงจัง แล้วส่งต่อให้วิศวกรเพื่อบอกว่าควรปรับปรุงอะไร
    • ความเห็นนี้เน้นย้ำความจำเป็นของโครงสร้างองค์กรที่ช่วยให้ Google เข้าใจความต้องการของลูกค้าและปรับปรุงตามนั้น
  • จากบ้านในซีแอตเทิลไปถึงออฟฟิศในซานฟรานซิสโก แบบประตูถึงประตูใช้เวลาประมาณ 4.5 ชั่วโมง
    • ความเห็นนี้ชี้ว่าผู้ก่อตั้งไม่ได้เคลื่อนไหวเร็วเหมือนเดิมอีกแล้ว และพูดติดตลกว่าอาจเป็นเพราะธนาคารกลางสหรัฐขึ้นอัตราดอกเบี้ย
  • ไม่คิดว่าประสิทธิภาพเป็นเรื่องรองอย่างที่พูดกันในที่นี้ ควรตรวจสอบก่อนว่าประสิทธิภาพดีพอ แล้วค่อยประเมินอย่างอื่นทั้งหมด ผู้เขียนเองก็พูดว่า "DuckDB เร็ว" ถ้าไม่เร็ว ก็คงต้องลงแข่งกันเรื่องประสิทธิภาพ
    • ความเห็นนี้ไม่เห็นด้วยกับคำกล่าวที่ว่าประสิทธิภาพเป็นเรื่องรอง และยืนยันว่าต้องเช็กก่อนว่ามันดีพอหรือไม่
  • ประสิทธิภาพไม่ใช่ "เรื่อง主觀" แต่เป็น "เรื่องสัมพัทธ์" ความหมายของมันขึ้นอยู่กับงานที่กำลังทำ
    • ความเห็นนี้อธิบายเรื่องความสัมพัทธ์ของประสิทธิภาพ และแยกมันออกจากความรู้สึกเรื่องความเร็วที่เกี่ยวข้องกับการออกแบบส่วนติดต่อผู้ใช้
  • เว็บแอปยอดนิยมตัวแรกเก็บสถานะทั้งหมดไว้ใน Python dict และดัมป์ลงดิสก์ทุก ๆ สองสามนาที มันเป็น API ที่เร็วมาก แต่เมื่อย้ายไป MongoDB แล้ว ประสิทธิภาพก็ไม่กลับมาเหมือนเดิม ถึงอย่างนั้นทุกวันนี้เวลาสร้างเว็บไซต์ก็ไม่ได้เลือก "pickledb"
    • ความเห็นนี้แชร์ประสบการณ์เรื่องประสิทธิภาพของเว็บแอปยุคแรกและการถดถอยของประสิทธิภาพหลังเปลี่ยนฐานข้อมูล
  • เคยสร้างระบบฐานข้อมูลเองและต้องการทำเบนช์มาร์กประสิทธิภาพกับฐานข้อมูลยอดนิยมอื่น ๆ (Postgres, Sqlite, MySQL, SQL Server)
    • ความเห็นนี้อธิบายว่าตนจะไม่พอใจจนกว่าฐานข้อมูลของตัวเองจะเร็วกว่าในคิวรีหลากหลายแบบ โดยวัดตั้งแต่ผู้ใช้กดปุ่ม 'Run' จนผลลัพธ์แสดงบนหน้าจอ
  • "แน่นอนว่ากฎนี้มีข้อยกเว้น และนั่นคือกรณีที่ยากจะเอาชนะความแตกต่างด้านสถาปัตยกรรมได้ ฐานข้อมูลแบบ shared nothing เสียเปรียบเมื่อเทียบกับ shared disk และ Redshift ใช้เวลาหลายปีกว่าจะเปลี่ยนไปใช้สถาปัตยกรรม shared disk เป็นหลักได้ เลคเฮาส์ที่จัดเก็บเมทาดาทาแบบถาวรไว้ใน object storage จะมีปัญหากับการอัปเดตที่รวดเร็ว ซึ่งเป็นข้อจำกัดที่มีอยู่ในโมเดลอยู่แล้ว"
    • ความเห็นนี้ชี้ให้เห็นปัญหาที่เกี่ยวข้องกับความแตกต่างด้านสถาปัตยกรรมของฐานข้อมูล และบอกว่ากำลังมองหาเอกสารที่ดีเกี่ยวกับหัวข้อนี้