แค่ประสิทธิภาพอย่างเดียวไม่พอ

• เวลาจะเลือกฐานข้อมูล หากมองแค่ความเร็วของ raw queryและ benchmark ทั่วไป ก็อาจพลาดเวลารวมทั้งหมดที่ผู้ใช้ต้องใช้ตั้งแต่ตั้งคำถามจนได้คำตอบ
• benchmark ของ GigaOm ในปี 2019 ยกให้ Azure Data Warehouse และ Redshift นำหน้า แต่ในตลาดจริง Snowflake และ BigQuery กลับขายดีกว่า แสดงให้เห็นถึงพลังของปัจจัยที่นอกเหนือจากประสิทธิภาพ
• ต่อให้ลดเวลาในการรันบนเซิร์ฟเวอร์ได้ JDBC driver, การดาวน์โหลดผลลัพธ์, การ parse CSV, และความยากในการเขียน SQL ก็อาจเป็นคอขวดที่ใหญ่กว่า
• ClickBench, TPC-H, และ TPC-DS มีประโยชน์ แต่ข้อสรุปอาจเปลี่ยนไปตามเงื่อนไขอย่างมี JOIN หรือไม่, การสแกนตารางเดียว, การปรับแต่งสคีมา, และเงื่อนไขเรื่องความถูกต้องหรือการรับประกัน ACID
• ประสิทธิภาพของ database engine มักค่อย ๆ เข้าใกล้กันเมื่อเวลาผ่านไป ดังนั้นเกณฑ์เลือกในระยะยาวควรเป็นความเร็วจากไอเดียไปสู่คำตอบและการผสานเข้ากับ workflow มากกว่าลำดับอันดับในปัจจุบัน

---

เวลาหน่วงจริงที่ benchmark มองไม่เห็น

• ในการเดินทางจากบ้านที่ซีแอตเทิลไปออฟฟิศที่ซานฟรานซิสโกซึ่งใช้เวลา 4.5 ชั่วโมง ต่อให้เพิ่มความเร็วขณะบินของเครื่องบินเป็น 10 เท่า เวลารวมก็อาจลดลงได้แค่ราว 20% เพราะยังมีเวลาเดินทางไปสนามบิน ตรวจความปลอดภัย ขึ้นเครื่อง รอที่รันเวย์ รับกระเป๋า และเดินทางต่อไปยังปลายทาง
• ฐานข้อมูลก็คล้ายกัน
  • ต่อให้ engine เร็วขึ้น ผู้ใช้ก็ยังต้องเจอกับไฟล์ CSV ที่ประหลาด ปัญหาที่เขียนคำถามเป็น SQL ได้ยาก และปัญหาการเชื่อมต่อเครื่องมือ
  • สินค้าที่ชนะสงคราม benchmark นั้นเอาไปทำการตลาดได้ง่าย แต่ไม่ได้แปลว่าจะลดเวลาที่ผู้ใช้ใช้แก้ปัญหาได้ทันที
• เวลาจะเลือกฐานข้อมูล ความง่ายในการใช้งาน, ecosystem, ความเร็วในการอัปเดต, และการผสานกับ workflow อาจเป็นเกณฑ์ที่ดีกว่า
• ประสิทธิภาพแสดงเพียงเวลาของงานบางอย่างในช่วงเวลาหนึ่ง และอาจทำให้เราไป optimize คอขวดผิดจุดอย่างจริงจัง

ผล GigaOm ปี 2019 ที่สวนทางกับตลาด

• ในปี 2019 GigaOm ได้รัน benchmark TPC-H และ TPC-DS กับคลาวด์ดาต้าแวร์เฮาส์
  • ผู้เข้าแข่งขันคือผู้ให้บริการคลาวด์ 3 รายและ Snowflake
  • ผลคือ Azure Data Warehouse เร็วที่สุด ตามด้วย Redshift ส่วน Snowflake และ BigQuery ตามหลังห่างพอสมควร
• ในเวลานั้น จากการประเมินของผู้ใช้ BigQuery ก็มักพบว่าลูกค้าที่เทียบกับ Azure โดยตรงเลือก BigQuery บ่อยกว่า
• ผลในตลาดจริงเกือบตรงข้ามกับอันดับ benchmark
  • Snowflake และ BigQuery ขายได้มากกว่า Redshift
  • Redshift ขายได้ดีกว่า Azure
• แม้ TPC-H และ TPC-DS จะเป็นมาตรฐานอุตสาหกรรมและใช้ตัดสินประสิทธิภาพภายในด้วย แต่ถ้าระบบที่ได้อันดับต่ำกว่าใน benchmark ด้านประสิทธิภาพกลับมีลูกค้าซื้อมากกว่า ก็พอมองได้ว่ามีปัจจัยที่สำคัญกว่าประสิทธิภาพอยู่

ความเร็วที่ผู้ใช้รับรู้ไม่ใช่เวลาเซิร์ฟเวอร์

• คนที่สร้างฐานข้อมูลมักโฟกัสที่เวลาในการรันบนเซิร์ฟเวอร์ตั้งแต่ผู้ใช้กดปุ่ม “run” จนผลลัพธ์พร้อม
• แต่เวลาที่สำคัญต่อผู้ใช้คือเวลารวมที่ใช้เพื่อทำงานให้เสร็จ ซึ่งไม่เท่ากับเวลาที่เซิร์ฟเวอร์ฐานข้อมูลใช้รัน query
• กรณีของ JDBC driver ของ BigQuery แสดงความต่างนี้ได้ชัด
  • JDBC driver เป็นอินเทอร์เฟซทั่วไปที่โปรแกรมเมอร์และเครื่องมือ BI ใช้เชื่อมต่อกับฐานข้อมูล
  • แม้ query ของ BigQuery จะรันเสร็จภายใน 1–2 วินาที แต่ด้วยวิธี polling ตรวจ completion และการดาวน์โหลดผลลัพธ์ของ driver ทำให้ผู้ใช้รู้สึกว่าช้ากว่าไปอีกหลายวินาทีหรือหลาย分钟
  • เมื่อผลลัพธ์มีจำนวนมาก driver จะดึงข้อมูลทั้งหมดเป็นรายหน้า รวมถึงข้อมูลที่ผู้ใช้ไม่ต้องการ ทำให้หน่วงมากขึ้น และบางครั้งก็พังเพราะหน่วยความจำไม่พอ
• วิศวกรใช้เวลาอย่างมากเพื่อลดเวลา query ลงเพียงเศษเสี้ยววินาที แต่ connector ที่ผู้ใช้ใช้จริงกลับเป็นต้นเหตุของความหน่วงที่ใหญ่กว่า
• benchmark ภายในรันทุกวัน แต่ประสิทธิภาพแบบ end-to-endและเวลาที่ผู้ใช้รับรู้จริงกลับมองไม่เห็น

ประสิทธิภาพไม่ได้ถูกกำหนดด้วยตัวเลขเดียว

• ควรวัดประสิทธิภาพจากมุมมองของผู้ใช้ไม่ใช่มุมมองของฐานข้อมูล และเหมือนกับ UX ตรงที่อธิบายทั้งหมดด้วยตัวเลขเดียวได้ยาก
• ฐานข้อมูลไหนเร็วกว่ากันขึ้นอยู่กับ workload จริง
  • ต่อให้ Lamborghini เร็วกว่า Prius มาก แต่ถ้ารถติด เวลาเดินทางไปทำงานอาจไม่ได้ต่างกัน
  • ความต่างด้านประสิทธิภาพระหว่าง ClickHouse กับ Redshift ก็เปลี่ยนไปตามวิธีใช้งาน
• ClickBench ของ ClickHouse แสดงผลว่า ClickHouse เร็วกว่าหลายฐานข้อมูล
  • benchmark นี้ทำงานบนตารางเดียวโดยไม่มี JOIN และพึ่งพา distinct count เป็นอย่างมาก
  • จึงอาจเป็นตัวแทนที่ดีสำหรับงานวิเคราะห์ log หรือการนับผู้ใช้ไม่ซ้ำของเว็บไซต์
  • แต่ก็อาจทำให้เข้าใจผิดกับ workload แบบ star schema ของดาต้าแวร์เฮาส์แบบดั้งเดิม
• benchmark จาก vendor มักเน้นสิ่งที่ vendor ทำนั้นเก่งอยู่แล้ว
• BigQuery อาจดูคะแนนไม่ดีใน benchmark แต่เพราะแทบไม่มี knob ให้ปรับและส่วนใหญ่ปรับจูนเองได้ จึงอาจให้ประสบการณ์ใช้งานจริงที่ดีกว่า
• อินสแตนซ์ SingleStore ที่ปรับจูนอย่างหนักอาจเอาชนะ BigQuery ได้ขาดในหลายงาน แต่ก็ต้องแลกกับเวลาในการปรับสคีมาและการรองรับ workload ใหม่
• เราอาจเพิ่มประสิทธิภาพได้โดยลดกลไกความปลอดภัยหรือความถูกต้อง
  • ตัด overflow check ออก
  • ข้ามการ flush เวลาเขียน
  • ให้ผลลัพธ์แบบประมาณค่าสำหรับบาง operation
  • ไม่รองรับ การรับประกัน ACID
• ทางลัดเหล่านี้อาจเป็นตัวเลือกที่ไม่อยากใช้ นอกเสียจากอยู่ในสภาพแวดล้อมที่ควบคุมได้

สำคัญกว่าลำดับวันนี้คือความเร็วในการพัฒนา

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

ช่องว่างด้านประสิทธิภาพจะแคบลงเมื่อเวลาผ่านไป

• ถ้าฐานข้อมูลหลายตัวที่มีการดูแลอย่างจริงจังถูกปรับปรุงต่อเนื่องอยู่หลายปี ประสิทธิภาพมักมีแนวโน้มเข้าใกล้กัน
• เทคนิคด้านประสิทธิภาพของผลิตภัณฑ์หนึ่ง เมื่อเวลาผ่านไปก็มักถูกนำไปใช้ในอีกผลิตภัณฑ์ได้
  • ถ้า ClickHouse ใช้เทคนิคที่ได้เปรียบด้านความเร็วในการสแกน Snowflake ก็อาจมีฟีเจอร์ใกล้เคียงกันภายใน 1–2 ปี
  • ถ้า Snowflake เพิ่ม incremental materialized view BigQuery ก็อาจตามมาได้ไม่นาน
• แต่ละฐานข้อมูลมีวิธีทำประสิทธิภาพต่างกัน
  • compile query เป็น machine code
  • cache ข้อมูลไว้บน local SSD
  • ใช้ฮาร์ดแวร์เครือข่ายเฉพาะทางจัดการ shuffle
• เทคนิคที่ได้ผล เมื่อมีเวลาเพียงพอใคร ๆ ก็ทำตามได้ และถ้าทำงานได้ดีจริงก็มักกระจายไปยังหลายระบบ
• ใน การเปรียบเทียบประสิทธิภาพดาต้าแวร์เฮาส์ ของ George Fraser ซีอีโอ Fivetran เวลาที่เร็วที่สุดในปี 2020 คือ 8 วินาที และช้าที่สุดคือ 18 วินาที แต่ในปี 2022 ผู้ให้บริการ 3 รายทำเวลาได้ราว 7 วินาที และรายที่ช้าที่สุดอยู่ที่ 9 วินาที ทำให้ช่องว่างแคบลงมาก
• อย่างไรก็ตาม ความต่างด้านสถาปัตยกรรม เอาชนะได้ยาก
  • ฐานข้อมูลแบบ shared nothing อาจเสียเปรียบเมื่อเทียบกับ shared disk
  • Redshift ใช้เวลาหลายปีกว่าจะเปลี่ยนผ่านไปยังสถาปัตยกรรม shared disk เป็นหลัก
  • lakehouse ที่เก็บ metadata ไว้ใน object store อาจมีปัญหากับการอัปเดตที่รวดเร็ว
• ความต่างเหล่านี้มักปรากฏชัดในสภาวะขอบเขต แต่ในระยะยาวก็ไม่มีเหตุผลเชิงแก่นแท้ที่ Redshift ต้องเร็วหรือช้ากว่า Snowflake เสมอไป

ฟีเจอร์ที่ลดเวลาจากคำถามไปสู่คำตอบ

• ประสิทธิภาพที่สำคัญต่อผู้ใช้คือเวลาตั้งแต่เกิดคำถามจนได้คำตอบ
• วิธีลดเวลานี้ไม่ได้มีแค่การปรับปรุง query plan
  • ทำให้การเขียนคำถามง่ายขึ้น
  • ทำให้ผลลัพธ์ของ query เข้าใจง่ายขึ้น
  • ให้ feedback เมื่อผู้ใช้ถามผิด
  • ช่วยให้เข้าใจปัญหาของข้อมูล
  • ช่วยเตรียมข้อมูลที่ต้องการให้อยู่ในตำแหน่งและรูปแบบที่ถูกต้อง
• Snowflake เด่นเรื่องทำให้ตอนผู้ใช้พิมพ์ SQL แล้ว “มันใช้ได้เลย”
  • เวลาใช้คำนวณความต่างของวันที่ สามารถใช้ได้ทั้ง DATEDIFF และ TIMEDIFF
  • ถ้า type สมเหตุสมผล ทั้งคู่ก็ใช้ได้
  • จะระบุหรือไม่ระบุ granularity ก็ได้
  • จะใส่หรือไม่ใส่เครื่องหมายคำพูดให้ granularity ก็ได้
• DuckDB เองก็เพิ่มฟีเจอร์ Friendlier SQL เพื่อให้เขียนและดูแล query ได้ง่ายขึ้น
  • GROUP BY ALL ช่วยลดการลืมฟิลด์ใน clause GROUP BY ของ query แบบ aggregate
  • แก้แค่รายการ SELECT ก็พอ จึงลดความจำเป็นต้องไปแก้หลายจุดเวลาที่ query เปลี่ยนแปลง
  • เมื่อฟีเจอร์นี้พิสูจน์ว่ามีประโยชน์ vendor ฐานข้อมูลหลายเจ้าก็เพิ่มฟีเจอร์คล้ายกัน
• ไฟล์ CSV เป็นรูปแบบที่เก็บข้อมูลจำนวนมากของโลก แต่หลายไฟล์ถูกจัดรูปแบบมาไม่ดี และการ parse จริง ๆ ก็ยาก
  • ตัว CSV splitter ยุคแรกของ BigQuery ทำ inference ไม่ได้ และเมื่อสคีมาระหว่างไฟล์ต่างกันเล็กน้อยก็สับสน
  • การ parse CSV เป็นปัญหาที่ซับซ้อนกว่าที่คิด
• ถ้าวิศวกรสองคนต้องอ่านข้อมูล CSV แล้วคำนวณผลลัพธ์เดียวกัน ฝั่งที่ ingest CSV ได้ถูกต้องและง่ายกว่าจะได้คำตอบก่อน โดยไม่เกี่ยวกับความเร็วของ query engine
• วิธีจัดการผลลัพธ์ก็มีผลต่อประสบการณ์ผู้ใช้อย่างมาก
  • ถ้า SELECT * คืนหน้าแรกพร้อม cursor แบบ MySQL ผู้ใช้ก็อาจเห็นผลได้ทันที
  • แต่ถ้าเหมือน BigQuery ที่ต้องสร้างสำเนาตารางฝั่งเซิร์ฟเวอร์ก่อน ก็อาจใช้เวลาหลายชั่วโมงเมื่อเป็นตารางใหญ่
  • ถ้า client พยายามดาวน์โหลดข้อมูลทั้งหมดลงมา ก็อาจหน่วยความจำหมด
  • การเชื่อมต่อที่ยาวนานเปราะบางต่อปัญหาเครือข่าย และการ polling ก็อาจทำให้ query ดูช้ากว่าจริงเมื่อมันรันเสร็จระหว่างช่วงห่างของการ polling

ข้อสังเกตเวลาอ่าน benchmark ของ DuckDB

• DuckDB เร็วมาก และอยู่ระดับบนสุดใน ClickBench บางขนาดเครื่อง
  • มีการยกตัวอย่างผลลัพธ์ของ c6a.4xlarge
• DuckDB ยังทำผลงานได้ดีใน benchmark ของ h2o.ai ส่วนใหญ่ และก็ไม่ได้แย่ใน TPC-H กับ TPC-DS
• ก่อนจะสรุปว่าฐานข้อมูลตัวไหนเร็ว ควรทดสอบกับworkloadของตัวเองโดยตรง

แก้ปัญหาให้เร็ว สำคัญกว่าทำ query ให้เร็ว

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

[GN⁺]

ความเห็นจาก Hacker News

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

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

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

  • มองจากมุมการบริหารก็พอเข้าใจได้ ประมาณว่า “เราจ้างคนเก่งคอมพิวเตอร์ไซเอนซ์ระดับท็อปมา ก็ให้ไปแก้ปัญหาคอมพิวเตอร์ไซเอนซ์แกนหลัก ส่วน JDBC driver ไม่ใช่ความสามารถหลัก ก็เอาออกไปจ้าง”
    ปัญหาคือถ้าทำให้ส่วนที่ไม่ใช่แกนหลักพังมากพอ ต่อให้ความสามารถหลักยอดเยี่ยมแค่ไหนก็ไร้ประโยชน์ การ outsource ไม่ใช่อาหารฟรี
  • Python wrapper สำหรับ Google API ก็เป็นเรื่องแบบนี้ทั้งหมด
  • นี่คือผลจากการขาด vertical integration Apple ชนะในหลายด้านก็เพราะทำ vertical integration ได้ดีมาก
  • แม้แต่สัญญาธุรกิจอย่าง Workspace ก็เป็นโครงแบบเดียวกัน คือมีผลิตภัณฑ์แกนหลักที่ยอดเยี่ยม แล้วถูกครอบด้วยสัญญา “support” ที่ไม่ใช่แค่ไร้ประโยชน์แต่ถึงขั้นเป็นโทษ โดยบริษัทที่ปรึกษาระดับแย่ที่สุดในโลกหักไปประมาณ 15%

• ในบทความบอกว่า “ประสิทธิภาพเป็นเรื่องอัตวิสัย” และการวัดแบบตรง ๆ อย่างเดียวไม่พอ แต่ตัวอย่างที่ยกมากลับเป็นกรณีที่ประสิทธิภาพสำคัญจริงและเป็นเรื่องเชิงภววิสัยด้วยซ้ำ เพียงแค่วัด สิ่งผิดตัว เท่านั้น

  • ย่อหน้าแรกก็เปิดมาด้วยกรณีที่เข้ากับ กฎของ Amdahl แบบเป๊ะ ๆ แต่กลับน่าแปลกที่ทั้งบทความไม่พูดถึงเลยสักครั้ง

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

  • “เวลาที่ anecdote กับ metrics ขัดกัน โดยปกติแล้ว anecdote มักถูกต้อง” — Jeff Bezos น่าเสียดายที่บางครั้งเขาก็พูดดีอยู่เหมือนกัน
  • ดูเหมือน Google จะมีอาการแพ้นิด ๆ กับการคุยกับลูกค้าโดยตรง
  • https://en.wikipedia.org/wiki/Seeing_Like_a_State
  • ถ้าโซลูชันของเราแก้ปัญหาลูกค้าไม่ได้ งั้นลูกค้าก็น่าจะต้องมีปัญหาอย่างอื่น หรือไม่ก็เราต้องการลูกค้าคนละแบบ
  • เห็นด้วยเต็มที่ ดูเหมือนเป็นปัญหาจากการเลือก ตัวชี้วัดผิดตัว มาเป็นเป้าหมาย เพียงแต่กรณีนี้ไปไกลกว่าแค่ทีมวิศวกรรมวัดเฉพาะส่วนแคบ ๆ ของ latency
    ผมยิ่งสงสัยว่าฝั่ง product กับผู้นำองค์กรกำลังดูตัวชี้วัดอะไรกันอยู่ ถึงพลาดฟีดแบ็กจากลูกค้าแบบนี้ได้

• พอเห็นประโยค “จากประตูบ้านใน Seattle ถึงประตูออฟฟิศใน San Francisco ใช้เวลา 4.5 ชั่วโมง” ก็รู้สึกว่าผู้ก่อตั้งสมัยนี้คงไม่ได้เคลื่อนที่ด้วยความเร็ว 179 ไมล์ต่อชั่วโมงกันแล้ว ดูเหมือนพอ Fed ขึ้นดอกเบี้ยก็เป็นแบบนี้

  • ตอนอ่านครั้งแรกนึกว่าขับรถ แต่คงหมายถึงเวลารวม เครื่องบิน + การเดินทางไปสนามบิน + การตรวจความปลอดภัย มากกว่า
  • ตอนนี้กำลังเดินทางจากบ้านใน Seattle ไปออฟฟิศที่ SF อยู่จริง ๆ ออกมาแล้ว 48 นาที พอถึงแล้วจะมาอัปเดตเพื่อเพิ่ม data point ให้เธรดนี้ด้วยตัวเอง

• มีประเด็นดี ๆ ชัดเจนหลายอย่าง แต่ข้อสรุปดูจะคลาดไปนิดหนึ่ง ประสิทธิภาพที่นี่ไม่ได้เป็นเรื่องรองอย่างที่พูด แต่ใกล้เคียงกับการเป็น สิ่งที่ต้องผ่านเกณฑ์ให้ได้ มากกว่า
  ต้องเร็วพอให้ผ่านก่อน ถึงจะไปตัดสินปัจจัยอื่นต่อได้ ก่อนหน้านั้นคุณยังไม่ได้แม้แต่ที่นั่งบนโต๊ะแข่ง ผู้เขียนเองก็บอกว่า “DuckDB เร็ว” ซึ่งถ้ามันไม่เร็ว อย่างน้อยก็ต้องแข่งกันด้วยประสิทธิภาพจนกว่าจะติ๊กช่องนี้ได้
  อีกอย่างคำว่า “เอนจินฐานข้อมูลที่เคลื่อนที่เร็วที่สุดจะเป็นผู้ชนะในที่สุด” อาจจริงได้ในระดับหนึ่ง แต่ไม่ค่อยใช้การในทางปฏิบัติ ตอนเป็นผู้เล่นหน้าใหม่ ความก้าวหน้ามักเร็ว แต่พอไปถึงจุดแบบ Snowflake ความเร็วก็ช้าลงเป็นธรรมดา ในฐานะคนเลือกระบบวันนี้ คุณไม่อาจลากเส้น extrapolate ความเร่งปัจจุบันออกไปในอนาคตได้ตรง ๆ
  ถึงอย่างนั้น มุมมองเรื่อง “ไม่ใช่จาก query ถึง result แต่คือจาก ไอเดียถึงคำตอบ ใช้เวลาเท่าไร” ก็ดูเป็นประเด็นที่ควรขุดต่ออย่างจริงจัง

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

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

• เว็บแอปที่ได้รับความนิยมช่วงแรก ๆ เอาสถานะทั้งหมดใส่ไว้ใน Python dict แล้ว dump ลงดิสก์ทุก ๆ ไม่กี่นาที มันเป็น API ที่เร็วที่สุดเท่าที่เคยเห็นมาในชีวิต
  หลังจากย้ายไป Mongo ประสิทธิภาพก็ไม่เคยกลับมาเหมือนเดิมอีกเลย ถึงอย่างนั้นเวลาสร้างเว็บไซต์ตอนนี้ก็ไม่ได้หยิบ “pickledb” มาใช้

  • ตัวเลือกกึ่งกลางระหว่าง fopen ก็คือ SQLite
  • ผมคิดว่าควรมีคนมากกว่านี้ที่พิจารณาสถาปัตยกรรมแบบ อยู่ในหน่วยความจำ + snapshot ตั้งแต่แรก แทนที่จะเริ่มจากโครงสร้างฐานข้อมูลแบบ transactional เสมอ
    มันอาจเหมาะน้อยกว่าสำหรับปฏิสัมพันธ์ผู้ใช้แบบ request/response แต่สำหรับข้อมูลสถิตขนาดใหญ่ หรือข้อมูลสตรีมที่เล่นซ้ำได้ซึ่งประมวลผลแบบ incremental หรือ batch ได้ ผมคิดว่ามันควรพบเห็นบ่อยกว่าที่เป็นอยู่ตอนนี้

• กำลังมองหาแหล่งข้อมูลดี ๆ เกี่ยวกับประเด็น “ฐานข้อมูลแบบ shared nothing เสียเปรียบเมื่อเทียบกับ shared disk และ Redshift ใช้เวลาหลายปีกว่าจะเปลี่ยนไปเป็นสถาปัตยกรรม shared disk เป็นหลัก ขณะที่ Lakehouse ที่เก็บ metadata ไว้ใน object store ก็อัปเดตได้เร็วลำบาก”

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