อุปกรณ์ IO และปัญหาความหน่วง

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

อุปกรณ์ IO และเวลาแฝง

  • อุปกรณ์จัดเก็บข้อมูลแบบไม่ลบเลือน เป็นองค์ประกอบหลักของระบบคอมพิวเตอร์สมัยใหม่ โดยสามารถเก็บข้อมูลได้แม้ปิดเครื่อง ต่างจากอุปกรณ์จัดเก็บข้อมูลแบบลบเลือน เช่น CPU register, CPU cache และ RAM ที่ต้องใช้พลังงานอย่างต่อเนื่อง

อุปกรณ์จัดเก็บข้อมูลแบบเทป

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

ฮาร์ดดิสก์ไดรฟ์ (HDD)

  • ฮาร์ดดิสก์ไดรฟ์ ให้การเข้าถึงข้อมูลได้เร็วกว่าเทป และจัดเก็บข้อมูลลงบนดิสก์โลหะทรงกลม โดยพื้นที่ผิวทั้งหมดของดิสก์พร้อมใช้งานอยู่เสมอ จึงช่วยลดเวลาแฝงในการอ่านและเขียนข้อมูล
  • HDD รองรับ command queuing ทำให้สามารถประมวลผลหลายคำสั่งแบบขนานได้

โซลิดสเตตไดรฟ์ (SSD)

  • โซลิดสเตตไดรฟ์ อ่านและเขียนข้อมูลด้วยอิเล็กทรอนิกส์โดยไม่มีชิ้นส่วนเชิงกล และใช้ NAND flash เพื่อให้การจัดเก็บข้อมูลแบบไม่ลบเลือน
  • SSD สามารถปรับประสิทธิภาพให้เหมาะสมได้ผ่านการประมวลผลแบบขนานและ garbage collection โดยการจัดเรียงข้อมูลอาจส่งผลต่อประสิทธิภาพได้

การจัดเก็บข้อมูลบนคลาวด์

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

การแยก storage และ compute

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

local vs network storage

  • local NVMe SSD ให้ความเร็ว IO สูงมาก และมีเวลาแฝงต่ำกว่า storage ที่เชื่อมต่อผ่านเครือข่าย
  • storage ที่เชื่อมต่อผ่านเครือข่ายอาจมีข้อจำกัดต่อการทำงานของ IO ซึ่งนำไปสู่ประสิทธิภาพที่ลดลง

ทางออก: Metal

  • Metal คือโซลูชันจาก PlanetScale ที่ใช้ไดรฟ์ NVMe SSD แบบเชื่อมต่อโดยตรง เพื่อมอบทั้งประสิทธิภาพและความสามารถในการขยายระบบที่ยอดเยี่ยม
  • คลัสเตอร์ Metal โดยพื้นฐานประกอบด้วยเซิร์ฟเวอร์หลักและรีพลิกา 2 ตัว เพื่อรับประกันความทนทานของข้อมูล และสามารถขยายความจุในการจัดเก็บได้อย่างง่ายดาย
  • ฐานข้อมูล Metal ไม่มีการจำกัดงาน IO แบบประดิษฐ์ขึ้น และสามารถดำเนินงาน IO ได้ด้วยเวลาแฝงต่ำที่สุด

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

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

 
GN⁺ 2025-03-15
ความคิดเห็นจาก Hacker News
  • มีการกล่าวว่าผู้เขียนบล็อกสนุกกับการเขียนบทความนี้มาก โดยใช้ JavaScript หลายพันบรรทัดเพื่อสร้างภาพแบบอินเทอร์แอ็กทีฟ
  • ระบุว่าตนสนับสนุน SQLite+NVMe มานานแล้ว นี่เป็นรูปแบบใหม่ที่เปิดโอกาสให้แก้ปัญหาได้โดยไม่ต้องขยายระบบในแนวนอน
    • ในปัญหาด้านประสิทธิภาพ สิ่งที่สำคัญที่สุดคือ latency
    • ยิ่งสำคัญมากเป็นพิเศษในกรณีที่ต้องประมวลผลแบบลำดับ
    • หากรัน SQLite บน NVMe ก็จะได้ข้อได้เปรียบด้าน latency ที่ผู้ให้บริการรายอื่นไม่สามารถให้ได้
    • ในกรณีใช้งานจริงส่วนใหญ่ การรันบนหน่วยความจำไม่ได้ให้ข้อได้เปรียบมากกว่าความคงทนของ NVMe อย่างมีนัยสำคัญ
  • ชื่นชมว่าบทความให้ข้อมูลแน่นมากจนแทบลืมไปเลยว่าเป็นการโปรโมตผลิตภัณฑ์ พร้อมกล่าวถึงภาพและความอินเทอร์แอ็กทีฟที่ยอดเยี่ยม
  • ขณะดูแอนิเมชันของ disk IO ทำให้นึกถึง Melvin Kaye
    • Mel ไม่ได้เขียน time-delay loop
    • เช่นเดียวกัน แม้ในตอนที่ Flexowriter ต้องมีการหน่วงระหว่างอักขระที่พิมพ์ออกมา
    • เขาจัดวางคำสั่งบน drum ให้ไปอยู่ถัดจากหัวอ่านพอดีในเวลาที่ต้องใช้งาน
    • drum ต้องหมุนครบหนึ่งรอบเพื่อค้นหาคำสั่งถัดไป
  • กล่าวว่าบล็อกนี้ดีมาก และชี้ว่าปกติแล้ว cloud storage นั้น "ช้าผิดปกติ"
    • กล่าวว่าช่วงหลังได้เพิ่มการรองรับการเก็บ incremental index บน S3/object storage
    • สาเหตุที่ใช้ NVMe มานานกว่าก็มาจากข้อได้เปรียบด้านประสิทธิภาพที่กล่าวไว้ในบทความก่อนหน้า
    • ระบุว่าอยากให้มีใครสักคนเข้ามาพลิกวงการนี้ด้วยข้อเสนอที่ดีกว่า
  • ชี้ให้เห็นว่าบทความนี้พูดถึง distributed storage ไม่เพียงพอ
    • บางระบบไม่ได้รองรับ replication เป็นพื้นฐาน
    • Cassandra cluster และ MySQL ทำ master-slave replication ได้ แต่หลายระบบทำไม่ได้
    • เมื่อใช้ NVMe storage บนคลาวด์ ก็ต้องคำนึงถึงรอบการบำรุงรักษาและการ drain ที่เริ่มจากฝั่งคลาวด์
    • หากแยก storage ออกจาก compute ผู้ให้บริการคลาวด์ก็สามารถย้าย compute ได้ตามต้องการ
    • เนื่องจากข้อมูลเป็นอิสระจาก compute ผู้ให้บริการคลาวด์จึงจัดการ data system และการ drain ได้
  • Metal ดูเจ๋งมาก มีการกล่าวว่าที่ทำงานเก่าเคยพยายามใช้ instance local SSD ของ GCP แล้วพบปัญหาความน่าเชื่อถือร้ายแรง
    • มีปัญหาที่บาง block ของอุปกรณ์ทำข้อมูลหาย
    • สงสัยว่าสถานการณ์นี้ดีขึ้นหรือยัง
    • ถามว่าใช้ machine type อะไรอยู่
    • กล่าวถึงการใช้ network disk ของ Discord เป็นแนวทางแก้ไข
  • PlanetScale Metal ดูแข็งแกร่งมาก การได้เห็น latency ลดลงอย่างมากในรีลีสแต่ละครั้งเป็นเรื่องน่าสนใจเสมอ
  • เป็นบทความที่ยอดเยี่ยมมาก การทำภาพแสดง random write ทำได้ดีมาก
    • ปัญหาอีกอย่างของ network-attached storage บนคลาวด์คือข้อจำกัด IOPS
    • ผู้ให้บริการคลาวด์จำนวนมาก รวมถึง AWS และ Google Cloud ใช้โมเดลนี้และจำกัดปริมาณงาน IO ที่ส่งได้
    • ถ้า storage เชื่อมต่อโดยตรงกับ compute instance ก็จะไม่มีการจำกัดงาน IO แบบเทียม ๆ
    • สามารถอ่านเขียนได้เร็วเท่าที่ฮาร์ดแวร์จะอนุญาต
    • สงสัยว่าข้อจำกัด "IOPS" เป็นการจำกัดทราฟฟิกเครือข่ายบางประเภทหรือไม่
    • ถามว่าหมายถึงทราฟฟิกเครือข่ายของ EBS volume หรือไม่
    • สงสัยว่าสามารถประหยัดต้นทุนได้หรือไม่ เป็นเพราะการทำ arbitrage แปลก ๆ ของ AWS หรือเพราะได้ประสิทธิภาพจากการใช้เครือข่าย EBS น้อยลง
    • เห็นได้ชัดว่าการวาง storage และ compute ไว้บนเครื่องเดียวกันมีข้อได้เปรียบด้าน latency
    • สงสัยว่ามีข้อได้เปรียบด้าน throughput ต่อราคาด้วยหรือไม่
  • สงสัยว่าผู้ให้บริการฐานข้อมูลแบบ "serverless" โฆษณาการเข้าถึงแบบ "low-latency" ได้อย่างไร
    • ใช้ object storage อย่าง S3 ซึ่งคาดว่า latency น่าจะแย่กว่า network storage มาก
    • กล่าวว่าพวกเขาสร้าง caching layer ขึ้นมา และระบุว่าจะเก็บข้อมูลไว้บน NVMe ที่เชื่อมต่อภายในเครื่อง