บริษัท เช่น Amazon หลีกเลี่ยงปัญหาคอขวดในการเข้าถึงเลเยอร์ฐานข้อมูลได้อย่างไร

29

หากคุณนึกภาพ บริษัท อย่าง Amazon (หรือเว็บแอพพลิเคชั่นอีคอมเมิร์ซขนาดใหญ่อื่น ๆ ) นั่นคือการดำเนินงานร้านค้าออนไลน์ขนาดใหญ่และมีจำนวนสินค้าที่มีอยู่จริงจำนวน จำกัด ในคลังสินค้าของ บริษัท คอขวดเดียว? แน่นอนพวกเขาจะต้องมีฐานข้อมูลจำนวนมากที่มีการจำลองแบบและเซิร์ฟเวอร์จำนวนมากที่จัดการโหลดอย่างอิสระ อย่างไรก็ตามหากผู้ใช้หลายคนกำลังให้บริการโดยเซิร์ฟเวอร์แยกต่างหากและทั้งคู่พยายามเพิ่มรายการเดียวกันลงในรถเข็นซึ่งมีเหลืออยู่เพียงรายการเดียวจะต้องมี "แหล่งที่มาของความจริง" สำหรับปริมาณที่เหลือสำหรับรายการนั้น นี่ไม่ได้หมายความว่าอย่างน้อยที่สุดผู้ใช้ทุกคนที่เข้าถึงข้อมูลผลิตภัณฑ์สำหรับรายการเดียวจะต้องค้นหาฐานข้อมูลเดียวกันในอนุกรมหรือไม่

ฉันต้องการที่จะเข้าใจวิธีที่คุณสามารถใช้งานร้านค้าขนาดใหญ่โดยใช้การคำนวณแบบกระจายและไม่สร้างคอขวดขนาดใหญ่บนฐานข้อมูลเดียวที่มีข้อมูลสินค้าคงคลัง

web-applications scalability distributed-computing

— mattgmg1990
แหล่งที่มา

สถาปัตยกรรมอเมซอนในกลางปี 2000 (ยังคงเกี่ยวข้องกับคำถามของคุณ): highscalability.com/amazon-architecture

— Joeri Sebrechts

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

— RemcoGerlich

1

@RemcoGerlich: วิธีที่คุณพูดว่า "หนึ่งฐานข้อมูลความจริงขั้นสุดท้าย" ทำให้ฉันนึกถึงเครื่องเดียวที่มีฐานข้อมูลศักดิ์สิทธิ์ขนาดใหญ่อยู่ ในความเป็นจริงสิ่งที่เกิดขึ้นกับข้อมูลที่สำคัญคือการทำธุรกรรมทั้งหมดเข้าถึงเซิร์ฟเวอร์หลายเครื่องพร้อมกันเพื่อให้มั่นใจว่าฐานข้อมูลทั้งหมดนั้นมีการซิงค์ตลอดเวลา

— Arseni Mourzenko

27

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

ไม่ได้จริงๆ นี่ไม่ใช่ปัญหาที่ต้องใช้โซลูชันทางเทคนิคที่สมบูรณ์แบบ 100% เนื่องจากทั้งสองกรณีข้อผิดพลาดมีโซลูชันทางธุรกิจที่ไม่แพงมาก:

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

ในความเป็นจริงฉันเพิ่งพบกรณีที่สองด้วยตัวเองดังนั้นจึงไม่เป็นข้อสมมติฐานนั่นคือสิ่งที่เกิดขึ้นและวิธีที่ Amazon จัดการกับมัน

มันเป็นแนวคิดที่ใช้บ่อยครั้งเมื่อคุณมีปัญหาที่ยากต่อการแก้ไขในเชิงทฤษฎี (ไม่ว่าจะเป็นในแง่ของประสิทธิภาพการเพิ่มประสิทธิภาพหรืออะไรก็ตาม): คุณมักจะสามารถใช้ชีวิตด้วยโซลูชันที่ทำงานได้ดีสำหรับกรณีส่วนใหญ่และยอมรับว่าบางครั้ง ล้มเหลวตราบใดที่คุณสามารถตรวจจับและจัดการกับความล้มเหลวเมื่อเกิดขึ้น

— Michael Borgwardt
แหล่งที่มา

2

ความทรงจำของ Pat Helland ความคิดและคำขอโทษที่กล่าวถึงในการสร้าง Quicksandและการชดเชยการทำธุรกรรมเป็นแนวคิดที่เกี่ยวข้องที่นี่

— Derek Elkins

1

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

— mattgmg1990

2

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

— Michael Borgwardt

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

— Michael Borgwardt

6

การรวมกันของ

คร่ำเครียด
sharding
การทำซ้ำ
การกระจาย
ล้มเหลวสูง
ร้านค้าคีย์ - ค่า

ไม่มีเวทย์มนตร์สถานการณ์ที่ซับซ้อนมากขึ้นเรื่อย ๆ เช่นเดียวกับ DNS มันถูกปรับขนาด

'ความจริงเวอร์ชั่นเดียว' เป็นส่วนหนึ่งของระบบดังกล่าว การสร้างคีย์ใหม่จะเป็นการดำเนินการที่ซับซ้อนกว่าการสร้างหมายเลขถัดไปในลำดับ ตัวอย่างเช่นลำดับอื่น ๆ ที่มีอยู่ นี่คือความซับซ้อนที่ระบบฐานข้อมูลแบบกระจายสามารถจัดการได้โดยการดำเนินการหลายอย่างกับและจากส่วนประกอบเมื่อสร้างวัตถุใหม่ทำให้ผู้อื่นสามารถใช้งานได้ทำให้มั่นใจได้ว่าลำดับนั้นไม่ซ้ำกันเมื่อจำเป็นต้องใช้คีย์ผสม ฯลฯ .

— Michael Durrant
แหล่งที่มา

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

— mattgmg1990

เพิ่มอีกเล็กน้อย ฉันไม่สามารถอธิบายความซับซ้อนทั้งหมดที่เกี่ยวข้องกับรูปแบบนี้ขออภัย

— Michael Durrant

1

มีเพียงบางคนที่สนใจหนังสือเล่มใดก็ตามซึ่งหมายความว่าหนังสือเล่มนี้สามารถจัดการได้โดยชิ้นส่วนที่ค่อนข้างเล็ก

— Basilevs

6

ฉันคิดว่าในสถานการณ์ที่คุณอธิบายถึงระบบเพียงต้องขออภัยต่อผู้ใช้ว่ามีคนอื่นซื้อสำเนาล่าสุด ฉันคิดว่าสิ่งนี้จะเกิดขึ้นเป็นครั้งคราว

— Matthew James Briggs

1

ฉันพนันได้เลยว่าตัวบ่งชี้ที่เหลืออยู่เพียง 5 เล่มเท่านั้นคือการคำนวณที่น้อยกว่าและการตลาดที่มากขึ้น

— mouviciel

5

ฉันเห็นปัญหา 'รายการสุดท้ายในสต็อก' ได้รับการแก้ไขด้วยวิธีต่อไปนี้:

อัปเดตระดับสต็อกทั้งหมดทุกวันและตั้งค่าสถานะผลิตภัณฑ์เป็นสูง, ต่ำ, ตามคำสั่งหรือหมดหมวดหมู่หุ้นตามระดับเกณฑ์

เห็นได้ชัดว่าเป็นรายการ 'หุ้นต่ำ' ซึ่งเป็นปัญหา

รายการที่มีระดับสต็อกสูง

ไม่ต้องตรวจสอบระดับสต็อค เพียงแค่สั่งซื้อ

รายการที่มีระดับสต็อกต่ำ

เตือนผู้ใช้เมื่อเรียกดู 'เหลือน้อยไม่กี่ครั้ง!' เมื่อพวกเขาจ่ายเงินให้ตรวจสอบและลดระดับสต็อค หากสินค้าหมดปรับปรุงสถานะรายการ

วิธีนี้คุณจะตีฐานข้อมูลสำหรับรายการ 'สินค้าคงคลังต่ำ' และคุณจะทำเช่นนั้นเมื่อลูกค้าค่อนข้างไกลกระบวนการซื้อ ค่าใช้จ่ายก็คือลูกค้าบางคนจะไม่สามารถทำการซื้อให้เสร็จสมบูรณ์ได้

อย่างไรก็ตามในกรณีส่วนใหญ่ 'หมดสต็อก' จริง ๆ แล้วหมายความว่าคุณกำลังรอการจัดส่งอีกครั้งดังนั้นคุณต้องการยอมรับคำสั่งต่อไปและอาจปรากฏคำเตือนหรือ จำกัด ตัวเลือกการจัดส่ง ดังนั้นลูกค้าเหล่านั้นจึงหายไป

ในช่วงเวลาโหลดสูงเช่นการขายคุณอาจปิดการตรวจสอบสต็อกและเพียงส่งอีเมลถึงลูกค้าในภายหลัง 'ขออภัยเราหมด X คุณต้องการ Y'

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

— Ewan
แหล่งที่มา

2

ในวิดีโอนี้ Martin Fowler กล่าวถึงฐานข้อมูล NoSQL:

https://www.youtube.com/watch?v=qI_g07C_Q5I

หนึ่งในจุด (ที่ใดที่หนึ่งในนั้น) คือสถานที่เช่นอเมซอนค่อนข้างจะทำให้ 99% ของผู้คนมีความสุขโดยการยอมรับคำสั่งของพวกเขาโดยไม่สามารถตรวจสอบ "แน่นอน" ไม่ว่าจะมีอยู่จริงหรือไม่ จะพูดว่า "ขอโทษนะดูเหมือนว่ามีใครบางคนเอาชนะคุณ"

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

(btw นั่นเป็นวิดีโอที่ยอดเยี่ยมถ้าคุณอยากรู้เกี่ยวกับ NoSQL)

— jleach
แหล่งที่มา