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

 (planetscale.com)
1 คะแนน โดย GN⁺ 2025-03-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อุปกรณ์จัดเก็บข้อมูลแบบไม่ลบเลือนพัฒนาจากเทปมาเป็น HDD, SSD และสตอเรจเครือข่ายบนคลาวด์ แต่ ตำแหน่งและการจัดวางข้อมูล ยังคงเป็นตัวกำหนดเวลาแฝงของ IO
  • อุปกรณ์จัดเก็บข้อมูลแบบเทป เด่นด้านการอ่าน·เขียนแบบลำดับ แต่เมื่ออ่านข้อมูลที่อยู่ไกลกันอาจใช้เวลาถึงหลายสิบวินาที จึงไม่เหมาะกับฐานข้อมูลธุรกรรมที่มีทราฟฟิกสูง
  • HDD ลดเวลาแฝงลงมากเมื่อเทียบกับเทป แต่เนื่องจากจานหมุนและการเคลื่อนที่ของหัวอ่าน การอ่านแบบสุ่มมักอยู่ที่ระดับ 1~3ms และประสิทธิภาพแตกต่างกันมากตามลำดับคำขอ
  • SSD ทำงานด้วย NAND flash โดยไม่มีชิ้นส่วนกลไก ทำให้การอ่านแบบสุ่มเร็วได้ถึง 16μs แต่การจัดวางข้อมูลยังคงสำคัญเพราะต้องใช้ประโยชน์จากการทำงานแบบขนานและ garbage collection
  • การแยกสตอเรจกับคอมพิวต์ในคลาวด์ช่วยให้ขยายระบบและรับมือความขัดข้องได้ง่ายขึ้น แต่เพิ่มรอบไปกลับของเครือข่ายและข้อจำกัด IOPS โดย PlanetScale Metal พยายามลดต้นทุนนี้ด้วย NVMe SSD ที่เชื่อมต่อโดยตรงและการทำ replication

ปัจจัยพื้นฐานที่กำหนดเวลาแฝงของสตอเรจ

  • อุปกรณ์จัดเก็บข้อมูลแบบไม่ลบเลือน เก็บข้อมูลไว้ได้แม้ปิดเครื่อง และเป็นพื้นฐานสำหรับการเก็บข้อมูลอย่างรูปถ่าย อีเมล ยอดเงินในบัญชีธนาคาร และเวชระเบียน
  • อุปกรณ์จัดเก็บข้อมูลแบบลบเลือน เช่น CPU register, CPU cache และ RAM เร็วกว่า แต่ต้องมีไฟเลี้ยงอย่างต่อเนื่อง
  • ประสิทธิภาพของสตอเรจไม่ได้ขึ้นอยู่กับความจุเพียงอย่างเดียว แต่ขึ้นอยู่กับวิธีเข้าถึงข้อมูล หน่วยของการอ่าน·เขียน การเข้าคิว ความขนาน และว่าต้องมีรอบไปกลับของเครือข่ายหรือไม่
  • PlanetScale ระบุพร้อมการเปิดตัว PlanetScale Metal ว่า Metal รันฐานข้อมูลคลาวด์ด้วยไดรฟ์ NVMe ภายในเครื่อง แทนสตอเรจที่เชื่อมต่อผ่านเครือข่าย

อุปกรณ์จัดเก็บข้อมูลแบบเทป: แข็งแกร่งกับการเข้าถึงแบบลำดับ แต่อ่อนกับการเข้าถึงแบบสุ่ม

  • คอมพิวเตอร์ใช้ เทปไดรฟ์ เป็นอุปกรณ์จัดเก็บข้อมูลดิจิทัลแบบไม่ลบเลือนมาตั้งแต่ทศวรรษ 1950
  • ตลับเทปประกอบด้วยหลายแทร็กและเซลล์จำนวนมาก โดยสถานะการโพลาไรซ์ทางแม่เหล็กของแต่ละเซลล์แทนข้อมูลไบนารี
  • เมื่อนำตลับใส่ในเครื่องอ่านและให้มอเตอร์ม้วนเทป IO head จะอ่านข้อมูลที่ผ่านหัวอ่านไป
  • ถ้าตำแหน่งอ่าน·เขียนอยู่ใกล้หัวอ่านก็จะเร็ว แต่ถ้าอยู่ไกล เวลาแฝงจะสูงขึ้น
    • แม้ในระบบเทปสมัยใหม่ หากต้องอ่านข้อมูลที่อยู่ไกล อาจต้องม้วนเทปเป็นร้อยเมตร
    • ในกรณีเช่นนี้ การอ่านอาจใช้เวลา หลายสิบวินาที
  • แม้จำนวนการอ่าน·เขียนเท่ากัน หากข้อมูลกระจัดกระจายก็จะใช้เวลานานกว่าการจัดวางแบบลำดับมาก
    • ตัวอย่างในบทความแสดงสถานการณ์ที่การอ่าน·เขียนแบบกระจัดกระจายใช้เวลานานกว่าประมาณ 7 เท่า สำหรับปริมาณงานเท่ากัน
  • เทปมีเวลาแฝงของการอ่าน·เขียนแบบสุ่มที่แย่ แต่ยังเหมาะกับการอ่าน·เขียนแบบลำดับยาวๆ
    • มีต้นทุนต่อ GB ต่ำกว่า SSD และ HDD และมีอายุการเก็บรักษายาวนาน
    • CERN จัดการข้อมูลมากกว่า 400PB ใน data warehouse ของสตอเรจเทป
    • AWS ก็ให้บริการ tape archiving เช่นกัน
  • เทปไม่เหมาะกับ ฐานข้อมูลธุรกรรม ที่มีทราฟฟิกสูง

HDD: จุดประนีประนอมของดิสก์หมุนและ command queueing

  • HDD เก็บข้อมูลบนแผ่นโลหะทรงกลมที่เรียกว่า platter แทนเทป
  • platter หมุนอย่างรวดเร็วภายใน enclosure โดยตัวอย่างระบุว่า 7200 RPM เป็นความเร็วที่พบได้ทั่วไป
  • แทร็กของ HDD เป็นวงกลม และดิสก์หนึ่งแผ่นอาจมีแทร็กได้ มากกว่า 100,000 แทร็ก
  • แต่ละแทร็กมี page หลายแสนหน้า และแต่ละ page เก็บข้อมูลประมาณ 4KB
  • HDD จัดตำแหน่งอ่าน·เขียนด้วยการเคลื่อนหัวอ่านและการหมุนของ platter
    • ต่างจากเทป บิตบนพื้นผิวทั้งหมดสามารถเข้าถึงได้ตลอดเวลา
    • ไม่จำเป็นต้องม้วนเทปรอให้ข้อมูลที่ต้องการปรากฏ
  • การอ่านแบบสุ่มทั่วไปสามารถทำได้ใน 1~3ms
  • ลำดับคำขอส่งผลต่อประสิทธิภาพอย่างมาก
    • การอ่าน·เขียนที่มีความเป็นลำดับสูงจะเสร็จเร็ว
    • แม้เป็นการอ่าน·เขียน 6 รายการเท่ากัน หากลำดับสลับกัน เวลาที่ต้องรอให้ platter หมุนมาถึงตำแหน่งที่ถูกต้องจะเพิ่มขึ้น
  • ดิสก์แม่เหล็กรองรับ command queueing มานานแล้ว
    • SCSI มีฟีเจอร์ที่เกี่ยวข้องตั้งแต่ทศวรรษ 1980 และ SATA ตั้งแต่ทศวรรษ 2000
    • OS สามารถส่งคำสั่งหลายรายการให้ทำงานแบบขนานหรือทำงานต่างลำดับจากที่ส่งได้
    • disk controller สามารถใช้คิวงานเพื่อจัดตารางการอ่าน·เขียนให้เหมาะกับโครงสร้างของดิสก์
  • HDD ดีขึ้นกว่าเทป แต่ยังมีบางกรณีที่ช้า โดยเฉพาะ การอ่าน·เขียนแบบสุ่ม

SSD: ตัวแปรด้านประสิทธิภาพที่ยังคงอยู่แม้ไม่มีชิ้นส่วนกลไก

  • SSD หรือ flash storage ถูกประดิษฐ์ขึ้นในทศวรรษ 1980 แต่เริ่มเป็นอุปกรณ์จัดเก็บข้อมูลสำหรับผู้บริโภคในกระแสหลักในทศวรรษ 2000
  • SSD ไม่พึ่งพาชิ้นส่วนกลไกในการอ่านข้อมูล
    • ใช้ทรานซิสเตอร์แบบไม่ลบเลือนที่เรียกว่า NAND flash
    • 1 และ 0 ถูกอ่าน เขียน และลบด้วยสัญญาณไฟฟ้าโดยไม่มีการเคลื่อนที่ของชิ้นส่วนทางกายภาพ
  • SSD ประกอบด้วย target อย่างน้อยหนึ่งรายการ แต่ละ target มีหลาย block และ block มีหลาย page
  • SSD อ่านและเขียนเป็นหน่วย page
    • แม้ต้องการข้อมูลเพียงบางส่วน หน่วยคำขอของไดรฟ์ก็ยังเป็น page
  • ในโครงสร้างตัวอย่าง หาก page มี 4096 บิต, block มี 16K page, target มี 16K block และอุปกรณ์มี 8 target จะรวมเป็น 4k * 16k * 16k * 8 = 8,796,093,022,208 บิต หรือ 8TB
  • การอ่านแบบสุ่มของ SSD แตกต่างกันตามรุ่น แต่เร็วได้ถึง 16μs
  • แม้ไม่มีชิ้นส่วนกลไก การจัดวางข้อมูลก็ยังสำคัญ
    • ปัจจัยด้านประสิทธิภาพของ SSD รวมถึง ความขนาน และ garbage collection

ความขนานของ SSD: การกระจาย target เปลี่ยน throughput

  • โดยทั่วไป target แต่ละรายการมี line เฉพาะที่เชื่อมต่อกับ control unit
  • line แต่ละเส้นประมวลผลการอ่าน·เขียนได้ แต่ส่งผ่านได้ครั้งละหนึ่ง page เท่านั้น
  • การส่งผ่าน page เร็วมาก แต่ก็ยังใช้เวลาเล็กน้อย
  • หาก write 8 รายการกระจายไปยัง 4 target ก็สามารถใช้ line 4 เส้นแบบขนานและเขียนได้ในสองช่วงเวลา
  • หาก write 8 รายการไปรวมอยู่ที่ target เดียวทั้งหมด จะใช้ line เพียงเส้นเดียวและ line ที่เหลือจะว่าง
  • ลำดับการอ่าน·เขียนและการจัดวางข้อมูลส่งผลต่อประสิทธิภาพแม้ใน SSD
  • เมื่อออกแบบซอฟต์แวร์อย่าง MySQL ต้องใส่ใจว่าข้อมูลถูกเก็บในโครงสร้างใดและถูกจัดวางบนดิสก์อย่างไร

SSD garbage collection: ต้นทุนของการลบก่อนเขียน

  • page ของ SSD อ่านได้หลายครั้ง แต่ page ที่ถูกเขียนไปแล้วไม่สามารถเขียนทับด้วยข้อมูลใหม่ได้จนกว่าจะลบข้อมูลเดิมอย่างชัดเจน
  • ไม่สามารถลบ page แยกเดี่ยวได้ ต้องลบ ทั้ง block
  • SSD ต้องมีอัลกอริทึมภายในสำหรับจัดการ page แบบ empty, in-use และ dirty
    • dirty page คือ page ที่ถูกเขียนแล้ว แต่ไม่จำเป็นต้องใช้ข้อมูลนั้นอีกต่อไปและพร้อมสำหรับการลบ
  • บางกรณีต้องย้ายข้อมูลเพื่อรับ write ใหม่ และอัลกอริทึมที่จัดการเรื่องนี้คือ garbage collector
  • หากมี unused page เพียงพอ ก็สามารถเขียนข้อมูลใหม่ได้ทันที
  • หาก unused page ไม่พอและมี dirty page จำนวนมาก ต้องทำ garbage collection ก่อน
    • ในตัวอย่าง เพื่อเขียน page ใหม่ 5 หน้า จะย้าย non-dirty page 2 หน้าไปยังตำแหน่งอื่น
    • จากนั้นทำให้ page ทั้งหมดของ target นั้นเป็นสถานะ dirty เพื่อให้ลบได้
    • ขั้นตอนเพิ่มเติมเหล่านี้ทำให้ประสิทธิภาพการ write ช้าลงมาก
  • ใน SSD ที่ยุ่งและมีการอ่าน เขียน ลบจำนวนมาก garbage collection อาจทำให้งานอื่นช้าลง

การเปลี่ยนแปลงที่คลาวด์เพิ่มเข้ามา: การแยกสตอเรจกับคอมพิวต์

  • การเปลี่ยนจากเทปเป็น HDD และ SSD เพิ่มประสิทธิภาพ IO ที่ทนทานได้อย่างมาก
  • การย้ายสู่คลาวด์สร้างการเปลี่ยนแปลงอีกอย่างต่อประสิทธิภาพ IO
  • AWS ถูกนำเสนอว่าเป็นบริการที่ทำให้การย้ายสู่คลาวด์แพร่หลายมากขึ้นหลังเปิดตัวในปี 2006
  • ในสภาพแวดล้อมคลาวด์ ผู้ใช้เช่าเซิร์ฟเวอร์เสมือนบนฮาร์ดแวร์ใดๆ ในดาต้าเซ็นเตอร์ขนาดใหญ่
  • เซิร์ฟเวอร์อาจถูกปิดได้ทุกเมื่อด้วยเหตุผลหลายอย่าง เช่น ฮาร์ดแวร์เสีย การเปลี่ยนเครื่อง หรือเครือข่ายขาด
  • เมื่อสร้างระบบบนโครงสร้างพื้นฐานคลาวด์แบบเช่า ต้องทนต่อความขัดข้องที่เกิดบ่อยขึ้นได้
  • เงื่อนไขเหล่านี้และความต้องการ storage volume ที่ขยายได้แบบไดนามิก นำไปสู่การ แยก storage กับ compute

ข้อดีและต้นทุนของสตอเรจที่เชื่อมต่อผ่านเครือข่าย

  • โดยทั่วไป เซิร์ฟเวอร์ เดสก์ท็อป แล็ปท็อป และโทรศัพท์มือถือเชื่อมต่ออุปกรณ์จัดเก็บข้อมูลแบบไม่ลบเลือนโดยตรง
    • ใช้สาย SATA, อินเทอร์เฟซ PCIe หรือรูปแบบที่ฝังอยู่ใน SoC เดียวกัน
  • สตอเรจที่เชื่อมต่อโดยตรงรวดเร็ว แต่มีข้อจำกัดสองอย่าง
    • หากเซิร์ฟเวอร์ล่ม ข้อมูลก็จะใช้งานไม่ได้ไปด้วย
    • ขนาดของสตอเรจถูกกำหนดตายตัว
  • แอปพลิเคชันเซิร์ฟเวอร์มักเหมาะกับสภาพแวดล้อมแบบชั่วคราว (ephemeral) และงานจำนวนมากเกิดขึ้นในหน่วยความจำ ดังนั้นปัญหานี้จึงไม่ใหญ่นัก
  • ฐานข้อมูลต้องไม่สูญเสียข้อมูลเมื่อเซิร์ฟเวอร์ล่ม และขนาดข้อมูลอาจเพิ่มอย่างรวดเร็วจนถึงขีดจำกัดของสตอเรจ
  • ผู้ให้บริการคลาวด์จำนวนมากอนุญาตให้แนบสตอเรจที่เชื่อมต่อผ่านเครือข่ายซึ่งกำหนดค่าแยกได้กับ compute instance
    • การกำหนดค่าพื้นฐานของ EC2 โดยทั่วไปเป็นการแนบ volume สตอเรจเครือข่าย EBS
    • บริการฐานข้อมูลอย่าง Amazon RDS, Amazon Aurora, Google Cloud SQL และ PlanetScale ก็พึ่งพาระบบที่แยก compute กับ storage ผ่านเครือข่าย
  • วิธีนี้ทำให้ปรับ storage volume ได้แบบไดนามิกตามการเพิ่มลดของข้อมูล
  • แม้เซิร์ฟเวอร์ล่ม ข้อมูลยังคงปลอดภัยและสามารถแนบกลับเข้ากับเซิร์ฟเวอร์อื่นได้
  • แต่แลกมาด้วยต้นทุนด้านประสิทธิภาพ ได้แก่ รอบไปกลับของเครือข่ายและข้อจำกัด IOPS

ความต่างของเวลาแฝงระหว่าง NVMe ภายในเครื่องกับสตอเรจเครือข่าย

  • NVMe SSD ที่เชื่อมต่อโดยตรงคือ SSD ที่ใช้ข้อกำหนด non-volatile memory host controller interface เพื่อให้ความเร็ว IO และแบนด์วิดท์สูง
  • รอบไปกลับจาก CPU ถึง RAM ถูกระบุไว้ที่ประมาณ 100ns
  • รอบไปกลับจาก CPU ถึง NVMe SSD ที่เชื่อมต่อภายในเครื่องอยู่ที่ประมาณ 50,000ns หรือ 50μs
  • storage volume ที่เชื่อมต่อผ่านเครือข่ายต้องใช้รอบไปกลับของเครือข่ายสั้นๆ ภายในดาต้าเซ็นเตอร์
  • สตอเรจที่เชื่อมต่อผ่านเครือข่ายอย่าง EBS ถูกระบุว่ามีเวลาไปกลับประมาณ 250,000ns หรือ 250μs หรือ 0.25ms
  • แม้ใช้ SSD รุ่นใหม่แบบเดียวกัน การเชื่อมต่อผ่านเครือข่ายทำให้เวลาประมวลผลคำขออ่าน·เขียนแต่ละรายการยาวขึ้นในระดับหนึ่งหลักเท่า
  • ใน IO แบบลำดับปริมาณมาก สามารถลดผลกระทบเชิงลบได้ แต่ไม่สามารถกำจัดได้
  • สตอเรจที่เชื่อมต่อผ่านเครือข่ายสร้าง เวลาแฝงเพิ่มเติม ทุกครั้งที่เข้าถึงระบบสตอเรจ

ข้อจำกัด IOPS และความต่างของสตอเรจที่เชื่อมต่อโดยตรง

  • ผู้ให้บริการคลาวด์จำนวนมาก รวมถึง AWS และ Google Cloud จำกัดจำนวนงาน IO ที่ส่งผ่าน wire ได้ในโมเดลสตอเรจที่เชื่อมต่อผ่านเครือข่าย
  • อินสแตนซ์ GP3 EBS ของ Amazon อนุญาตโดยค่าเริ่มต้นที่ 3000 IOPS ต่อวินาที
    • สามารถตั้งให้สูงขึ้นได้ แต่มีค่าใช้จ่ายเพิ่มเติม
  • volume GP2 EBS รุ่นก่อนทำงานด้วยวิธีสะสม IOPS pool เพื่ออนุญาตให้ burst ได้เป็นครั้งคราว
  • หากเชื่อมต่อสตอเรจกับ compute instance โดยตรง จะไม่มีข้อจำกัดงาน IO แบบประดิษฐ์
  • ในการเชื่อมต่อโดยตรง สามารถอ่านและเขียนได้เท่าที่ฮาร์ดแวร์รองรับ

วิธีรักษาความทนทานและความสามารถในการขยาย

  • ปัญหาข้อแรกของ SSD ที่เชื่อมต่อโดยตรงคือ ความทนทานของข้อมูล ซึ่งแก้ได้ด้วย replication
  • วิธีทั่วไปคือให้เซิร์ฟเวอร์หนึ่งเป็น primary เพื่อรับคำขอ write ทั้งหมด และมีเซิร์ฟเวอร์เพิ่มเติมอีก 2 เครื่องขึ้นไปรับ replication ของข้อมูล
  • หากข้อมูลอยู่ในสามที่ ความเป็นไปได้ที่จะสูญเสียข้อมูลจะลดลง
  • หากสมมติเป็นตัวเลขว่าความน่าจะเป็นที่เซิร์ฟเวอร์ล้มเหลวต่อเดือนคือ 1%:
    • สำหรับเซิร์ฟเวอร์เดียว ความน่าจะเป็นในการสูญเสียข้อมูลในแต่ละเดือนคือ 1%
    • สำหรับสามเซิร์ฟเวอร์ จะลดเหลือ 1% × 1% × 1% = 0.0001% หรือ 1 ใน 1,000,000
  • PlanetScale ตรวจจับและแทนที่ node ที่ล้มเหลวโดยอัตโนมัติ และสำรองข้อมูลฐานข้อมูลอย่างเสถียรและบ่อยครั้ง
  • ปัญหาข้อที่สองคือ ความสามารถในการขยายไดรฟ์ ซึ่งต้องอาศัยการแทรกแซงด้วยมือมากขึ้น
    • ต้องมีการมอนิเตอร์และแจ้งเตือนเมื่อดิสก์ใกล้ถึงขีดจำกัดความจุ
    • ต้องมีเครื่องมือที่เพิ่มความจุได้ง่ายเมื่อจำเป็น

แนวทางของ PlanetScale Metal

  • Metal ให้บริการคลัสเตอร์ฐานข้อมูลที่ใช้ NVMe SSD ซึ่งเชื่อมต่อโดยตรง
  • ฐานข้อมูลแต่ละ instance ทำงานบน direct-attached NVMe SSD
  • โดยค่าเริ่มต้น คลัสเตอร์ Metal ประกอบด้วย primary 1 ตัวและ replica 2 ตัว
  • คลัสเตอร์ฐานข้อมูลที่รองรับคือ Vitess หรือ Postgres
  • เมื่อถึงขีดจำกัดสตอเรจ สามารถปรับขนาดไปยังเซิร์ฟเวอร์ที่มีไดรฟ์ใหญ่ขึ้นได้ด้วยการคลิกไม่กี่ครั้ง
  • ภายในระบบจะเปิด node ใหม่และ migrate ข้อมูลจาก instance เดิมไปยัง instance ใหม่ โดยกระบวนการนี้ทำแบบ zero downtime
  • ฐานข้อมูล Metal ไม่มี IOPS cap แบบประดิษฐ์
  • ผู้ใช้สามารถทำงาน IO ด้วยเวลาแฝงต่ำ และใช้ได้เท่าที่ฮาร์ดแวร์รองรับ โดยไม่ต้องเสียค่า IOPS class แพงๆ ของผู้ให้บริการคลาวด์หรือเจอ throttle

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

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

 
GN⁺ 2025-03-15
ความคิดเห็นจาก Hacker News

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

    • visualization ยอดเยี่ยมมาก โดยเฉพาะ แอนิเมชันกล่องที่เด้งไปมา เป็นคำอธิบาย latency แบบสัมพัทธ์ที่ดีที่สุดที่เคยเห็น
      แต่การใช้คำว่า “1 ใน 1 ล้าน” เรื่อง durability ดูจะมองโลกแง่ร้ายเกินไป เมื่อคำนึงว่าช่วงเวลาที่ระบบล้มเหลวก่อนเซิร์ฟเวอร์ใหม่เข้ามาและ replicate ใหม่นั้นสั้นมาก
      เช่น ถ้าการกู้คืนใช้เวลา 10 นาที ต่อให้เซิร์ฟเวอร์ทั้งสามเครื่องต้องล้มเหลวเดือนละครั้ง ความน่าจะเป็นที่ทั้งสามจะล้มเหลวซ้อนกันก็น่าจะราว ๆ 1 ใน 2 ล้านแล้ว และถ้าความน่าจะเป็นที่ล้มเหลวต่อเดือนอยู่ที่ 1% โอกาสที่ความล้มเหลวทั้งสามจะซ้อนกันก็จะต่ำมาก
      ที่เสริมเพราะถ้ามีลูกค้า 1 ล้านคน ตัวเลข 1 ใน 1 ล้านก็ไม่ได้ดีนัก
    • แอนิเมชันยอดเยี่ยมมาก และการทำ interaction ก็ดีมาก ผมต้องอธิบายเรื่อง latency ให้คนในงานฟังบ่อย ๆ การได้เห็นความแตกต่างของ latency ระหว่างอุปกรณ์อย่าง HDD กับ SSD ด้วยตา ทำให้เข้าใจง่ายขึ้นมาก
    • เห็นได้ชัดเลยว่าทุ่มเทมาก อยากรู้คร่าว ๆ ว่าใช้ เวลาในการทำ ไปเท่าไร
      รู้ดีว่าเวลาที่นั่งพิมพ์กับเวลาที่คิดอยู่ในหัวนั้นต่างกันพอสมควร
    • คำถามที่เกี่ยวกับหัวข้อประมาณครึ่งหนึ่งคือ อยากรู้ว่าใช้ ไลบรารี อะไรทำแอนิเมชัน ในหน้า source ดูไม่เห็นทันที
      หัวข้อนี้คุ้นเคยมากอยู่แล้ว เลยไม่มีอะไรจะเสริมกับเนื้อหาเอง และลองไล่ดูก็ดูดี แต่ผมกำลังวางแผนทำแอนิเมชันสำหรับบล็อกตัวเอง และไลบรารีบางตัวที่ลองใช้ช่วงหลังไม่ค่อยถูกใจ

  • ผมผลักดันชุด SQLite+NVMe มาสักพักแล้ว โดยส่วนตัวมองว่าเป็น pattern ใหม่ที่ทำให้ไปได้ไกลกว่าปกติมาก และในบางกรณีก็อาจรองรับไปจนสุดได้โดยไม่ต้อง scale แนวนอน
    ในด้าน performance นั้น latency คือราชา โดยเฉพาะเมื่อจำเป็นต้องประมวลผลรายการแบบ serial การรัน SQLite บน NVMe ให้ข้อได้เปรียบด้าน latency ที่ provider อื่นให้ไม่ได้
    สำหรับ use case จริงส่วนใหญ่ ผมก็ไม่คิดว่าการรันใน memory จะดีกว่า persistent storage บน NVMe มากนัก

    • สงสัยว่าทำไมถึงเลือก SQLite แทน ฐานข้อมูลแบบ client-server ดั้งเดิมอย่าง Postgres
      บนโฮสต์เดียวอาจเร็วขึ้นเล็กน้อย แต่ทันทีที่เว็บเซิร์ฟเวอร์เพิ่มจาก 1 เครื่องเป็น 2 เครื่อง และทั้งสองต้องเขียนลงฐานข้อมูล ก็เหมือนทำให้ตัวเองลำบากขึ้น
      คำว่า latency สำคัญก็ชวนให้เข้าใจผิดได้ ถ้าไม่มี consistency แล้ว performance ก็ไม่มีความหมาย และทันทีที่มีเว็บเซิร์ฟเวอร์หลายเครื่อง คุณก็ต้องแก้ปัญหา consistency นั้นเอง
      อีกอย่าง latency ของฐานข้อมูลมักจะน้อยกว่า latency ไปกลับทางอินเทอร์เน็ตมาก และ latency ทางอินเทอร์เน็ตนั้นก็ยังน้อยเมื่อเทียบกับ “การรอ” โหลด asset ของหน้าอย่างรูปภาพหรือ code library
      แต่แรกแล้วควรหลีกเลี่ยง query ฐานข้อมูลแบบ serial ให้มากที่สุด ใช้ join ถ้าทำได้ และถ้าทำไม่ได้ก็ควรยิง query แบบ async พร้อมกันให้มากที่สุดเท่าที่ทำได้ เพื่อให้รันแบบ parallel
    • layout ของ file system ใน SQLite ถูกออกแบบมาเผื่อ defragmentation ของ HDD ดังนั้นคงไม่ได้ประโยชน์มากเท่าที่ควรจากการใช้ NVMe หากไม่เปลี่ยนเป็น layout ที่ทันสมัยกว่าและเหมาะกับ SSD
    • SQLite ไม่ได้เข้ากันได้ดีมากกับ parallelism ของการเขียน แม้จะรองรับ แต่ก็ค่อนข้างหยาบและยังล้มเหลวได้
      เพื่อหลีกเลี่ยงปัญหาการเขียนพร้อมกัน นอกจากตั้งค่าโหมดการทำงานแบบหยาบ ๆ บางอย่างแล้ว ยังใช้ทริกในแอปพลิเคชันให้มี single thread สำหรับเขียนโดยเฉพาะได้
      แบบนั้นโค้ด parallel ที่ซับซ้อนอยู่แล้วก็มักจะซับซ้อนขึ้นอีกเล็กน้อย ถ้ามี write thread เดียว SQLite ทำงานได้ยอดเยี่ยมจริง ๆ
    • ลอง fsync() กับไฟล์บน file system ext4 ในคอมพิวเตอร์เดสก์ท็อป แม้บนดิสก์ NVMe ก็ยังวัดได้ latency 1–2ms
      บนระบบใหม่กว่านั้นได้ประมาณ 800µs
    • ลองรันแอปกับฐานข้อมูลบนเครื่องเดียวกันด้วย Coolify แล้วค่อนข้างน่าสนุก เห็น latency ใกล้ 0 มาก ๆ ใน SQL query และน่าประทับใจที่แทบจะเหลือแค่ต้นทุนของ engine

  • ปริมาณข้อมูลดีมากจนอ่านไปแล้วลืมสนิทว่านี่เป็นการโปรโมตผลิตภัณฑ์ visualization และ interaction ทำได้ยอดเยี่ยม

  • พอเห็นแอนิเมชัน disk I/O ก็นึกถึง Melvin Kaye
    Mel ไม่ได้ใช้ time delay loop แม้ตอนที่ Flexowriter ที่ช้าต้องการ delay ระหว่างอักขระที่พิมพ์ออกมา
    แต่เขาปรับตำแหน่งคำสั่งบน drum แทน เพื่อให้ทุกครั้งที่ต้องใช้คำสั่งถัดไป หัวอ่านเพิ่งผ่านคำสั่งนั้นไปพอดี และ drum ต้องหมุนเพิ่มอีกหนึ่งรอบเพื่อหาคำสั่งถัดไป
    https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/The...

    • ผมก็นึกถึง Mel เหมือนกัน ถ้ายังไม่ได้ดู Usagi Electric บน YouTube ได้กู้คืนระบบ drum memory ยุค 1950s ให้กลับมาแทบทำงานได้สมบูรณ์แล้ว

  • Metal ดูเจ๋งมากจริง ๆ แต่ตอนอยู่ที่ทำงานก่อนและลองใช้ instance local SSD ของ GCP เคยเจอปัญหาความน่าเชื่อถือรุนแรง เช่น block ของอุปกรณ์ทำข้อมูลหาย
    อยากรู้ว่าตอนนี้สถานการณ์เปลี่ยนไปหรือยัง และใช้ machine type แบบไหน
    ตอนนั้น workaround คืออันนี้: https://discord.com/blog/how-discord-supercharges-network-di...

    • เป็น workaround ที่น่าสนใจ เราเพิ่งเริ่มใช้ GCP Local SSD ในปี 2024 และระหว่างทดสอบยังไม่เจอ read/write failure จาก bad sector
      อย่างไรก็ตาม เรารันระบบ redundancy ด้วย MySQL semi-synchronous replication เพื่อให้ทุก write ถูก persist บนเครื่องสองเครื่องใน availability zone ที่ต่างกันก่อนจะ acknowledge ให้ client
      Kubernetes operator กับโปรเซส vtorc ของ Vitess ทำงานร่วมกันเพื่อตรวจจับและแทนที่ replica ที่ล้มเหลวหรือน่าสงสัยอย่าง proactive
      บน GCP เราได้ผลดีที่สุดกับเครื่อง n2d-highmem และบน AWS เราใช้ type รุ่นล่าสุดที่มี instance storage แทบทั้งหมด

  • เป็นบทความที่ดี โดยทั่วไปแล้วก็มีปัญหาว่า Cloud Storage ช้าเป็นพิเศษ อยู่ด้วย
    ที่อื่นก็เคยพูดถึงเรื่องนี้แล้ว แต่บทความนี้สรุปปัญหาได้ดี: http://databasearchitects.blogspot.com/2024/02/ssds-have-bec...
    ล่าสุด https://github.com/feldera/feldera เพิ่มการรองรับการเก็บ incremental index ไว้บน S3/object storage แล้ว ส่วน NVMe รองรับมาก่อนหน้านั้นนานแล้ว เพราะมีข้อได้เปรียบด้านประสิทธิภาพที่ชัดเจนตามที่บทความก่อนหน้าพูดถึง
    ถ้ามีใครมาสั่นสะเทือนพื้นที่นี้ด้วยวิธีให้บริการที่ดีกว่านี้ก็คงดี

    • บล็อก Database Architects นั้นคุ้มค่าแก่การอ่านมาก

  • มีบางส่วนเกี่ยวกับ distributed storage ในบทความนี้ที่ยังประเมินไว้ไม่เพียงพอ
    อย่างแรก บางระบบไม่ได้มี replication มาให้ในตัว คลัสเตอร์ Cassandra หรือ MySQL สามารถทำ master-slave replication ได้ แต่หลายระบบไม่ได้เป็นแบบนั้น
    อย่างที่สอง ถ้าใช้ NVMe storage บนคลาวด์ จะต้องใส่ใจกับช่วงเวลาบำรุงรักษาและการ drain ที่คลาวด์เริ่มเอง ทำให้การปฏิบัติการยากขึ้นมาก
    ถ้าไม่ผูกเข้ากับระบบแบบนั้นเพื่อย้ายข้อมูลออกไปยังโหนดอื่น ข้อมูลก็จะหายไป
    เมื่อแยก storage กับ compute ออกจากกัน ผู้ให้บริการคลาวด์สามารถเคลียร์และย้าย compute ได้เมื่อต้องการ ข้อมูลเป็นอิสระจาก compute และผู้ให้บริการคลาวด์ก็จัดการระบบข้อมูลนั้นกับการ drain ด้วย จึงปรับการวาง workload ได้โดยไม่ต้องให้ลูกค้าเข้ามาแทรกแซง

    • เป็นประเด็นที่ดี ความทนทานและความน่าเชื่อถือของ PlanetScale สร้างอยู่บน MySQL replication และซอฟต์แวร์ปฏิบัติการที่เราเขียนขึ้นเพื่อพยายามรักษา replication ไว้ท่ามกลางการเข้าออกของเซิร์ฟเวอร์, network partition และสถานการณ์ล้มเหลวต่าง ๆ ที่พบในคลาวด์
      storage ที่เชื่อมต่อผ่านเครือข่ายและมี replication ซึ่งดูเหมือน API ของระบบไฟล์ “local” เป็นวิธีที่ทรงพลังในการมอบความทนทานให้กับระบบที่ไม่มี replication ในตัวแบบที่เรามี
    • ในเชิงทฤษฎี s2.dev อาจช่วยสถานการณ์แบบนี้ได้ สามารถให้ความทนทานไปพร้อมกับตามแบนด์วิดท์ของ streaming ได้ทัน
    • DRBD น่าจะยังมีอยู่ แต่ใช้ EBS ง่ายกว่าแน่นอน
    • สงสัยว่าคำว่า drain ในที่นี้หมายถึงอะไร

  • เยี่ยมมากจริง ๆ และ PlanetScale Metal ก็ดูค่อนข้างแข็งแรง ชอบเป็นพิเศษที่ได้เห็น latency ลดลงมากในรีลีส: https://planetscale.com/blog/upgrading-query-insights-to-met...

  • เป็นเวลาหลายปีที่ไม่เข้าใจว่าทำไมฐานข้อมูลที่มี replication ถึงยังยึดติดกับ EBS และยอมรับ latency นั้นอยู่เสมอ ทั้งที่มี replication อยู่แล้ว ทำไมไม่กล้าใช้ ดิสก์ local กันนะ
    ตอนอยู่ในองค์กรก่อนหน้า เราใช้ Elasticsearch เป็นที่เก็บ log/metrics ชั่วคราว ความต้องการด้านความน่าเชื่อถือก็ไม่ได้สูงมาก เลยเสนอให้ทำแบบนั้น แต่โน้มน้าวไม่สำเร็จ สุดท้ายก็ต้องใช้ AWS Elasticsearch ที่แย่กว่า
    รู้ว่าความจุของดิสก์ local มีจำกัด แต่คิดว่าสัดส่วน core/memory/disk น่าจะเพียงพอกับ use case ส่วนใหญ่ไม่ใช่หรือ มี instance ที่มีดิสก์ local ในสัดส่วนต่างกันอยู่มาก จึงหาจุดสมดุลที่เหมาะได้
    จะทำ hot/cold storage ด้วย instance ที่มีฮาร์ดดิสก์ local มากกว่า 20TB ก็ได้
    อยากชมทีม PlanetScale มาก เพราะในที่สุดก็กำลังทำสิ่งที่สมเหตุสมผล แม้แต่ AWS ยังไม่รัน Elasticsearch บนดิสก์ local ลองคิดดูว่า ClickHouse หรือ Cassandra อะไรพวกนั้นทั้งหมดรันบนดิสก์ local

    • เคยลองพิจารณาไอเดียการรัน SQL Server Availability Groups บน local SSD ระดับเทราไบต์ของ VM ตระกูล Azure Las_v3
      ปัญหาหลักคือหลังเหตุการณ์ stop-start ดิสก์จะถูกล้าง แม้ว่าคลัสเตอร์ที่เหลือจะยังปกติและมี replica ที่ใช้งานได้ SQL Server ก็จัดการเรื่องนี้โดยอัตโนมัติไม่ได้
      เพราะมันไม่กู้คืนโหนดที่ถูก initialize ใหม่โดยอัตโนมัติ การทำ scripting และการทดสอบเพื่อหลบปัญหานี้จึงรับมือใน production ได้ยาก เว้นแต่องค์กรจะกล้าหาญและมีความสามารถที่สุดจริง ๆ
    • ยังมีแกนด้านประสิทธิภาพของ storage อีกหลายอย่างที่บทความยอดเยี่ยมนี้ไม่ได้พูดถึง หนึ่งในนั้นคือเมื่อใช้ EBS คุณสามารถ scale VM ขึ้นลงเพื่อเปลี่ยน CPU และ RAM สำหรับประมวลผลข้อมูลบนดิสก์ได้
      เราดำเนินงานคลัสเตอร์ ClickHouse หลายร้อยคลัสเตอร์ด้วยโมเดลนี้ การปรับขนาดเพื่อแก้ปัญหาประสิทธิภาพเกิดขึ้นบ่อยกว่าการแก้เหตุขัดข้องมาก
      เช่น ถ้าเกิดปัญหาประสิทธิภาพของ tenant ตอนเช้าวันอาทิตย์ตามเวลาอเมริกา วิธีแก้ที่ง่ายที่สุดคือขยับขึ้นไปใช้ VM ที่ใหญ่ขึ้นช่วงสุดสัปดาห์ แล้วให้ทีมหลักดู root cause ในเช้าวันจันทร์
      ค่าใช้จ่ายเพิ่มเติมเล็กน้อย และหลีกเลี่ยง burnout ของพนักงานที่แพงกว่ามากได้

  • เป็นบทความที่ยอดเยี่ยมจริง ๆ และ การ visualization ของ random write ก็ทำออกมาได้ดีมาก
    มีคำถามบางข้อที่อาจจะดูโง่เกี่ยวกับข้อจำกัด IOPS ของ network-attached storage
    อย่างแรก สงสัยว่าข้อจำกัด “IOPS” เป็นการจำกัดความเร็วของทราฟฟิกเครือข่ายบางประเภท คือทราฟฟิกเข้าออก EBS volume ใช่หรือไม่ สุดท้ายแล้วอยากถามว่า “IOPS” หมายถึง “ทราฟฟิกเครือข่ายของ EBS volume” หรือเปล่า
    อย่างที่สอง สงสัยว่าวิธีนี้ช่วยประหยัดค่าใช้จ่ายด้วยหรือไม่ ถ้าใช่ ก็สงสัยว่าเป็นเพราะส่วนต่างราคาแปลก ๆ ของ AWS หรือเป็นเพราะได้ประสิทธิภาพจากการทำ EBS networking น้อยลง
    การวาง storage กับ compute ไว้บนเครื่องเดียวกันดูชัดเจนว่าได้ประโยชน์เชิงโครงสร้างในแง่ latency เพราะลด hop ไปหนึ่งครั้ง แต่ก็อยากรู้ว่าได้เปรียบในแง่ throughput ต่อดอลลาร์ด้วยไหม

    • ตัว EBS volume เองมี IOPS และ throughput ที่ provision ไว้ และ EC2 instance ที่ attach volume นั้นอยู่ก็มี limit แยกต่างหากสำหรับ EBS volume ทั้งหมดที่เชื่อมต่ออยู่
      ผมมักมองมันเป็นอีกโมเดลหนึ่ง EBS volume ไม่ใช่ชิ้นส่วน physical board ที่เสียบอยู่กับ PCIe bus แต่เป็นส่วนแบ่งในระบบ distributed ขนาดใหญ่ที่ประกอบด้วย physical drive จำนวนมาก และคล้าย SAN ที่มีความจุเครือข่ายเฉพาะไป-กลับกับ compute
      อาจประหยัดค่าใช้จ่ายได้ แต่สุดท้ายก็เป็นชุดของ trade-off หลายอย่าง
    • ข้อจำกัด IOPS ของ network-attached storage ไม่ได้จำกัดแบนด์วิดท์ แต่จำกัด จำนวนแพ็กเก็ตต่อวินาที เพราะงาน input/output อาจเกิดขึ้นด้วยขนาดที่ต่างกัน เช่น block ขนาด 4K หรือ 16K