4 คะแนน โดย GN⁺ 2024-11-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ฟีเจอร์ใหม่ของ Amazon S3: การเขียนแบบมีเงื่อนไข

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

    • ฟีเจอร์นี้ใช้งานได้ทั้งกับ S3 general purpose bucket และ directory bucket โดยส่ง ETag ของอ็อบเจ็กต์ผ่านคำขอ API ของ S3 PutObject หรือ CompleteMultipartUpload

    • การเขียนแบบมีเงื่อนไขช่วยทำให้แนวทางของแอปพลิเคชันแบบกระจายที่มีไคลเอนต์หลายตัวอัปเดตชุดข้อมูลร่วมกันพร้อมกันง่ายขึ้น คล้ายกับการใช้ HTTP if-none-match conditional header เพื่อตรวจสอบว่าอ็อบเจ็กต์มีอยู่ก่อนถูกสร้างหรือไม่ ตอนนี้ไคลเอนต์สามารถระบุ ETag ของอ็อบเจ็กต์ผ่าน HTTP if-match header ในคำขอ API เพื่อทำการตรวจสอบการเขียนแบบมีเงื่อนไขได้แล้ว

    • S3 จะคอมมิตการเขียนหลังจากประเมินว่า ETag ของอ็อบเจ็กต์ตรงกับค่าที่ส่งมาในคำขอ API หรือไม่ และจะป้องกันไม่ให้ไคลเอนต์เขียนทับอ็อบเจ็กต์จนกว่าเงื่อนไขจะเป็นจริง

    • conditional header ใหม่นี้สามารถช่วยปรับปรุงประสิทธิภาพของงานวิเคราะห์ขนาดใหญ่, distributed machine learning และงานอื่น ๆ ที่มีการประมวลผลแบบขนานสูงได้

    • ฟีเจอร์การเขียนแบบมีเงื่อนไขใหม่นี้พร้อมใช้งานแล้วในทุก AWS Region โดยไม่มีค่าใช้จ่ายเพิ่มเติม สามารถทำการเขียนแบบมีเงื่อนไขได้ผ่าน AWS SDK, API หรือ CLI สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการเขียนแบบมีเงื่อนไข สามารถดูได้จากคู่มือผู้ใช้ S3

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

 
GN⁺ 2024-11-26
ความคิดเห็นจาก Hacker News
  • มีการเพิ่มฟีเจอร์ที่บังคับการเขียนแบบมีเงื่อนไขได้ใน Amazon S3

    • ต้องการฟีเจอร์ที่บังคับให้ชื่ออ็อบเจ็กต์ตรงกับแฮชใน S3
    • สิ่งนี้ช่วยในการสร้างสตอเรจแบบ content-addressable
  • Turbopuffer.com ใช้สิ่งนี้กับฐานข้อมูลมาโดยตลอดเพื่อหลีกเลี่ยงการพึ่งพาสิ่งอื่นนอกเหนือจาก object storage

    • ดีใจที่หลังจากเริ่มต้นกับ Google Cloud Storage ได้ 1 ปี ตอนนี้ก็ใช้ฟีเจอร์นี้บน S3 ได้แล้ว
  • ความสอดคล้องที่เข้มงวดช่วยให้บรรลุสิ่งที่ต้องการได้ครึ่งหนึ่ง

  • บางคนก็ยังเข้าใจได้ยากว่าทำไมฟีเจอร์นี้ถึงสำคัญ

  • สิ่งนี้ใกล้เคียงกับ compare-and-set มากกว่า compare-and-swap

  • เมื่อรวมกับการรับประกัน read-after-write consistency ก็เป็นรากฐานที่สมบูรณ์แบบสำหรับการสร้างสตอเรจแบบ append-only incremental บน object storage

    • ช่วยแก้ปัญหาเมื่อมีผู้เขียนหลายรายเข้าถึง WAL
  • Azure Blob Storage ก็รองรับ e-tag และ optimistic control เช่นกัน

    • บางคนสงสัยว่ามันต่างจากฟีเจอร์ของ AWS อย่างไร
  • หากอัลกอริทึม ETag เริ่มต้นของ AWS เป็นเพียงแฮช MD5 ธรรมดา ก็มีข้อสงสัยว่าอาจเกิดกรณีที่ข้อมูลอ็อบเจ็กต์ล้มเหลวเพราะ MD5 collision หรือไม่

    • พิจารณาสถานการณ์ที่สมมติว่าข้อมูลที่ผู้ใช้จัดเตรียมซึ่งแตกต่างกันจะสร้าง ETag ที่แตกต่างกันเสมอ
  • MinIO ซึ่งเป็นอิมพลีเมนเทชันโอเพนซอร์สของ Amazon S3 มีฟีเจอร์นี้มานานเกือบ 2 ปีแล้ว

    • ตอนนี้ Amazon เพิ่งตามทัน
  • ฟีเจอร์ใหม่ถูกเพิ่มเข้ามาในช่วงฤดูร้อนเพื่อตอบสนองต่อ IfNoneMatch ของ s3fs

    • บางคนก็สงสัยว่าฟีเจอร์ใหม่นี้จะแสดงออกมาอย่างไรใน file system abstraction