การประกาศ "การเพิ่มประสิทธิภาพอัตราการร้องขอ S3 ใหม่" หมายความว่าอย่างไร


12

เมื่อวันที่ 17 กรกฎาคม 2018 มีการประกาศ AWS อย่างเป็นทางการซึ่งอธิบายว่าไม่จำเป็นต้องสุ่มตัวอักษรตัวแรกของทุก ๆ object S3 เพื่อให้ได้ประสิทธิภาพสูงสุด: https://aws.amazon.com/about-aws/whats-new / 2018/07 / Amazon-S3-ประกาศเพิ่มขึ้นขออัตราประสิทธิภาพ /

Amazon S3 ประกาศเพิ่มประสิทธิภาพของอัตราคำขอ

โพสต์เมื่อ: 17 ก.ค. 2018

ขณะนี้ Amazon S3 มอบประสิทธิภาพที่เพิ่มขึ้นเพื่อรองรับการร้องขออย่างน้อย 3,500 คำขอต่อวินาทีเพื่อเพิ่มข้อมูลและ 5,500 คำขอต่อวินาทีเพื่อดึงข้อมูลซึ่งสามารถประหยัดเวลาการประมวลผลที่สำคัญโดยไม่เสียค่าใช้จ่ายเพิ่มเติม คำนำหน้า S3 แต่ละตัวสามารถรองรับอัตราการร้องขอเหล่านี้ทำให้ง่ายต่อการเพิ่มประสิทธิภาพอย่างมาก

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

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

เยี่ยมมาก แต่ก็สับสนเช่นกัน มันบอกว่าแต่ละคำนำหน้าS3สามารถรองรับอัตราการร้องขอเหล่านี้ทำให้ง่ายต่อการเพิ่มประสิทธิภาพอย่างมีนัยสำคัญ

แต่เนื่องจากคำนำหน้าและตัวคั่นเป็นเพียงอาร์กิวเมนต์ไปยังGET Bucket (List Objects)API เมื่อแสดงรายการเนื้อหาของที่เก็บข้อมูลวิธีที่เหมาะสมที่จะพูดคุยเกี่ยวกับประสิทธิภาพการดึงวัตถุ "ต่อคำนำหน้า" ทุกการเรียกไปGET Bucket (List Objects)สามารถเลือกคำนำหน้าใดก็ได้และตัวคั่นที่ต้องการดังนั้นคำนำหน้าจึงไม่ใช่เอนทิตีที่กำหนดไว้ล่วงหน้า

ตัวอย่างเช่นถ้าถังของฉันมีวัตถุเหล่านี้:

a1/b-2
a1/c-3

จากนั้นฉันอาจเลือกที่จะใช้ "/" หรือ "-" เป็นตัวคั่นของฉันเมื่อใดก็ตามที่ฉันรายการเนื้อหาฝากข้อมูลดังนั้นฉันอาจคิดว่าคำนำหน้าของฉันจะเป็นอย่างใดอย่างหนึ่ง

a1/ 

หรือ

a1/b-
a1/c-

แต่เนื่องจากGET ObjectAPI ใช้คีย์ทั้งหมดแนวคิดของคำนำหน้าหรือตัวคั่นเฉพาะจึงไม่มีอยู่สำหรับการดึงวัตถุ ดังนั้นฉันสามารถคาดหวังได้ 5,500 req / sec a1/หรืออีก 5,500 req / sec on a1/b-และ 5,500 on a1/c-?

ดังนั้นใครบางคนสามารถอธิบายสิ่งที่มีความหมายโดยการประกาศเมื่อมันแสดงให้เห็นถึงระดับประสิทธิภาพที่เฉพาะเจาะจง (เช่น +5,500 คำขอต่อวินาทีเพื่อดึงข้อมูล) สำหรับ "คำนำหน้า s3 แต่ละคำ"


ฉันคิดว่าฉันมีคำอธิบายเกี่ยวกับเรื่องนี้ แต่ฉันกำลังมองหาเพื่อดูว่าฉันสามารถหาคำยืนยันบางอย่าง ฉันสงสัยว่ามันเกี่ยวข้องกับอัลกอริทึมการแบ่งพาร์ติชันดัชนีซึ่งเป็นไปโดยอัตโนมัติและยึดตามปริมาณการรับส่งข้อมูล ... และคำศัพท์แทนที่จะใช้แฮช
Michael - sqlbot

คำตอบ:


9

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

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

ตอนนี้ a1 / a -... และ a1 / b -... และ a1 / c -... อาจเป็นคำนำหน้าทั้งหมด แต่มีทราฟฟิกเพียงพอที่ที่ฝากข้อมูลและ S3 อาจตัดสินใจแบ่งพาร์ติชันดังนั้นพรุ่งนี้ a1 / a- และ a1 / b- อาจอยู่ในคำนำหน้าเดียวในขณะที่ a1 / c- อาจอยู่ในคำนำหน้าของตัวเอง (นั่นคือคีย์ <a1 / c- อยู่ในพาร์ติชันเดียวขณะที่คีย์> = a1 / c- อยู่ในพาร์ติชันอื่น)

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


1
น่าสนใจมากและน่าเชื่อถือ อย่างไรก็ตามเนื่องจากคำนำหน้านั้นเป็นแบบไดนามิกที่ขึ้นอยู่กับโหลดแน่นอนว่ามันไม่มีความหมายที่จะกำหนดการวัดประสิทธิภาพเฉพาะใด ๆ "ต่อคำนำหน้า" หากคำนำหน้าฝากข้อมูลของคุณเปลี่ยนแบบไดนามิกแสดงว่าไม่มีการวัดประสิทธิภาพที่เชื่อถือได้ หรือบางทีฉันอาจอนุมานว่าคำนำหน้าในทางทฤษฎีควรเปลี่ยนแบบไดนามิกจนกว่าฉันจะสามารถคาดหวัง 5,500 req / วินาทีต่อวัตถุ S3?
John Rees

1
การวัดประสิทธิภาพยังคงมีประโยชน์เพราะการปรับขนาดถังมักจะไปในทิศทางเดียวขึ้น - ลงไม่ลง ความไร้เหตุผลที่ชัดเจนของการปรับขนาดให้กับวัตถุเดียวต่อพาร์ติชันส่วนใหญ่ดูเหมือนจะหายไปเมื่อคุณรู้ว่า AWS จะต้องใช้เงินมากแค่ไหนถ้าคุณจ่ายเงิน 5k + req / s ต่อวัตถุ
Michael - sqlbot

1
ใช่ฉันเป็นคนคล่องแคล่วเล็กน้อยกับวัตถุเดียวต่อพาร์ติชัน :-) อย่างไรก็ตามอย่างจริงจังยิ่งขึ้นฉันเดาว่านี่หมายความว่าฉันคาดหวังได้ว่าหากที่เก็บวัตถุ 10,000 ชิ้นของฉันมีวัตถุยอดนิยมเพียง 10 ชิ้นหวังว่า S3 จะได้รับการจัดสรรใหม่ในที่สุดจนกว่าแต่ละ 10 จะได้รับ 5k reqs / วินาที ในพาร์ทิชันขนาดใหญ่สอง เป็นไปได้?
John Rees

2
ฉันมีความมั่นใจทุกอย่างที่ S3 จะปรับให้เข้ากับปริมาณงานใช่ คำแนะนำอย่างเป็นทางการสำหรับการรับส่งข้อมูลสูงในด้านคำขอคือก่อนหน้านี้เพื่อใช้ CloudFront ร่วมกับ S3 เนื่องจาก CloudFront มีการกระจายแบบ gobally และจะแคชวัตถุในขอบที่ใกล้ที่สุดที่ผู้ชมร้องขอ ราคาเป็นเช่นนั้นการเพิ่ม CloudFront ไป S3 มักจะไม่มีผลกระทบต่อต้นทุนโดยรวม (เนื่องจาก S3 ไม่ได้เรียกเก็บเงินสำหรับแบนด์วิดท์ใด ๆ เมื่อคำขอมาจาก CloudFront เพื่อให้บริการแคชพลาด)
Michael - sqlbot

ขอบคุณไมเคิล คำตอบที่ดีจริงๆระวังชื่นชมมาก
John Rees
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.