S3 คือเทคโนโลยีจัดเก็บไฟล์ ไม่ใช่ระบบไฟล์

S3 เป็นไฟล์ แต่ไม่ใช่ระบบไฟล์

• Amazon S3 เป็นเทคโนโลยีคลาวด์ดั้งเดิมที่เปิดตัวในปี 2006 โดยถูกเรียกว่า "object storage" แต่ในทางปฏิบัติแล้วมันมีไว้สำหรับไฟล์
• ความคิดที่ว่า S3 คือ "Amazon Cloud Filesystem" เป็นความเชื่อที่มีประโยชน์ในการผลักดันให้ผู้คนหันมาใช้ S3 แต่ความจริงคือ S3 ไม่ใช่ระบบไฟล์

ระบบไฟล์คืออะไร และความ "ลึก" ของโมดูล

• Unix file API ประกอบด้วยฟังก์ชันพื้นฐาน 5 ตัว ซึ่งให้ทุกอย่างที่จำเป็นสำหรับการอ่านและเขียนไฟล์
• ฟังก์ชันเหล่านี้จัดการปัญหามากมาย เช่น buffering, page cache, fragmentation, permissions, IO scheduling โดยไม่เปิดเผยให้ผู้ใช้เห็น
• โมดูลที่ลึกมีข้อดีคือทำให้ผู้ใช้สามารถใช้ความสามารถต่างๆ ได้โดยไม่ต้องคิดถึงความซับซ้อนเบื้องหลัง

คุณลักษณะของ S3 (ซึ่งก็ลึกเหมือนกัน)

• S3 ไม่ได้ reimplement Unix file system API และรูปแบบการเรียกใช้งานพื้นฐานก็แตกต่างกัน
• S3 API เรียบง่ายกว่า Unix file API แต่มีข้อจำกัดคือไม่สามารถเขียนทับบางส่วนของอ็อบเจ็กต์ได้

ซอฟต์แวร์ระบบไฟล์ โดยเฉพาะฐานข้อมูล ไม่สามารถย้ายไปอยู่บน Amazon S3 ได้

• ฐานข้อมูลต้องการที่สำหรับเก็บข้อมูล ซึ่งโดยทั่วไปจะเก็บอยู่ในไฟล์หลายไฟล์บนระบบไฟล์
• ฐานข้อมูลพึ่งพาความสามารถในการเขียนทับบางส่วนอย่างมาก ซึ่ง S3 ทำไม่ได้

สิ่งที่ S3 ทำได้ดีและทำได้ไม่ดี

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

ความสำคัญของความลึกของโมดูลระหว่างองค์กร

• จึงไม่น่าแปลกใจที่ S3 กลายเป็นคลาวด์ API แรกที่ได้รับความนิยม เพราะ API ที่ลึกช่วยจัดการความซับซ้อนระหว่างองค์กรได้
• การเชื่อมต่อซอฟต์แวร์องค์กรที่ซับซ้อนอย่าง SAP เป็นงานที่เจ็บปวด และสาเหตุหนึ่งคือ SAP ไม่ใช่โมดูลที่ลึก

ข้อมูลอื่นๆ

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

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

• สิ่งสำคัญคือต้องเข้าใจว่า S3 ไม่ใช่ตัวแทนของระบบไฟล์ แต่เป็นโซลูชันสตอเรจที่ปรับให้เหมาะกับกรณีใช้งานเฉพาะ ตัวอย่างเช่น เหมาะกับการเก็บและส่งต่อไฟล์ขนาดใหญ่ที่ไม่เปลี่ยนแปลงบ่อย แต่ไม่เหมาะกับแอปพลิเคชันที่ต้องมีการอัปเดตบางส่วนบ่อยครั้งอย่างฐานข้อมูล
• แม้ S3 จะมีประสิทธิภาพและความสามารถในการขยายสูงมาก แต่เมื่อพิจารณาเรื่องความคุ้มค่าและความซับซ้อนในการจัดการ ก็ไม่ได้เหมาะกับทุกโปรเจกต์ ตัวอย่างเช่น โปรเจกต์โอเพนซอร์สอย่าง MinIO อาจเป็นทางเลือกที่ดีสำหรับองค์กรที่ต้องการสร้าง S3-compatible storage บนโครงสร้างพื้นฐานของตัวเอง
• เมื่อใช้งาน S3 ยังมีเรื่องเพิ่มเติมที่ต้องพิจารณา เช่น data consistency, ค่าใช้จ่ายด้านเครือข่าย และ access control ซึ่งปัจจัยเหล่านี้อาจส่งผลต่อการออกแบบระบบโดยรวม
• แม้กรณีใช้งานของ S3 อาจมีข้อจำกัด แต่สำหรับแอปพลิเคชันบางประเภท เช่น data lake หรือโซลูชันแบ็กอัป มันเป็นเครื่องมือที่ทรงพลังมาก ความสามารถในการเก็บข้อมูลอย่างปลอดภัยและดึงกลับมาได้อย่างรวดเร็วเมื่อต้องการ มอบคุณค่าที่สำคัญให้กับหลายธุรกิจ
• บทความนี้ช่วยให้เกิดความเข้าใจเชิงลึกทั้งในด้านรายละเอียดทางเทคนิคของ S3 และกรณีใช้งานจริง ซึ่งอาจช่วยในการตัดสินใจทางเทคนิคได้

[GN⁺]

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

• ไม่เคยได้ยินปัญหาเกี่ยวกับความทนทานของ S3 มาก่อน แต่ก็ไม่เคยเห็นว่าคำกล่าวอ้างเหล่านี้ถูกทดสอบเหมือนกัน เลยค่อนข้างสงสัยเกี่ยวกับมัน

  • ความทนทานของ S3 อยู่ในระดับแนวหน้าของอุตสาหกรรม และเทียบกับระบบไฟล์แบบดั้งเดิมไม่ได้
  • การแยก Availability Zone ของ AWS เหนือกว่าผู้ให้บริการคลาวด์รายอื่น
  • S3 ให้ความสำคัญอย่างมากกับความสมบูรณ์ของข้อมูลและความเสี่ยงจากภัยธรรมชาติ
  • S3 ทำงานในสเกลที่ใหญ่พอจะตรวจจับ bit rot ได้
  • จะไม่เก็บข้อมูลสำคัญไว้ที่อื่นนอกจาก S3
  • ที่มา: คนที่เขียนระบบ batch ของ S3

• การแสดงรายการไฟล์ช้า S3 อ่านและเขียนได้เร็วมาก แต่การแสดงรายการไฟล์ช้ามาก

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

• เพิ่งแปลกใจไม่นานมานี้ว่าการแสดงรายการไฟล์ช้ามาก ตอนทำงานสคริปต์เพื่อจัดการแอสเซ็ตบน S3 ก็พบว่าจำเป็นต้องมีแคชรายการไฟล์

  • มีไดเรกทอรีระดับรากประมาณ 100,000 รายการ และแต่ละรายการก็มีไดเรกทอรีอีกไม่กี่อันที่ภายในมีไฟล์อยู่ไม่กี่ไฟล์
  • การแสดงรายการไฟล์แบบ recursive ใช้เวลา 15 นาที
  • สงสัยว่าเหตุใด Amazon ถึงยังไม่แก้ปัญหานี้

• Amazon S3 เป็นเทคโนโลยีคลาวด์ยุคแรกเริ่ม เปิดตัวในปี 2006 ตอนนั้นคำว่า "object" กำลังเป็นที่นิยม และ S3 ก็ถูกเรียกว่า "object store"

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

• มีการพูดคุยเปรียบเทียบ API ที่ Apache Arrow object_store และ Apache OpenDAL มีให้

  • Apache OpenDAL เป็นไลบรารีที่ให้ API คล้าย FS สำหรับคลาวด์สตอเรจหลายเจ้า รวมถึง S3
  • ระบบฐานข้อมูลบางตัว เช่น GreptimeDB และ Databend ใช้ OpenDAL เพื่อเข้าถึงข้อมูลบนคลาวด์สตอเรจ
  • โซลูชันอื่นอย่าง Alluxio และ JuiceFS ก็จัดการอินเทอร์เฟซคล้ายระบบไฟล์บน S3 เช่นกัน

• ซอฟต์แวร์ระบบไฟล์ โดยเฉพาะฐานข้อมูล ไม่สามารถพอร์ตไปยัง Amazon S3 ได้

  • แต่พอร์ตได้
  • ไม่จำเป็นต้องเขียนทับไฟล์ DB ทั้งไฟล์ทุกครั้งที่ทำ INSERT/UPDATE/DELETE
  • ในกรณีของ SQLite ก็มีเครื่องมืออย่าง Litestream ที่รองรับการ replicate ไปยัง S3 และการกู้คืน

• ใช้ Minio เป็น "S3" แบบโลคัลเพื่อเก็บ dataset และ model checkpoint

  • Minio มีฟีเจอร์จำนวนมากที่ไม่จำเป็น
  • ตอนนี้ตัวเลือกแบบ self-hosted, single-node ที่ดีที่สุดสำหรับ "สิ่ง" ที่คล้าย S3 ขั้นต่ำซึ่งทำ CRUD กับไฟล์และดูรายการได้คืออะไร?

• ระหว่างที่พูดถึง S3 ก็ควรกล่าวถึง Backblaze B2 ด้วย

  • พอใจมากกับราคาที่ต่ำกว่า S3 ถึง 3 เท่า

• S3 อาจถูกนำไปใช้ผิดเป็นระบบไฟล์ได้

  • S3 ต้องการอ็อบเจ็กต์ และตรงนี้มีอ็อบเจ็กต์ขนาด 512 หรือ 4096 ไบต์ที่เรียกว่า cluster