ในกรณีของ "เดี่ยว" ผมว่าระบบเมฆก็น่าจะช่วยในส่วนของ web app ตรงกลาง กระจายเป็นหลาย ๆ instance ดูแลผู้ใช้หลาย ๆ คนพร้อม ๆ กัน

ส่วน Database เองก็อาจจะออกแบบเป็น db server หลาย ๆ ตัว ดูแลเป็นตัวละรอบไปเลยก็น่าจะช่วยได้ (รันบน VM ก็ได้ จะได้ไม่ต้องใช้ HW มากมาย) ผมว่าถ้าเอา DB ตัวเดียวอาจจะเอาไม่อยู่ ไม่รู้นะครับ ไม่รู้ด้วยว่าถ้าทำเป็น distribute DB แล้วจะมีปัญหาอะไรบ้าง (น่าจะเรื่อง sync เรื่องนึงล่ะ)

หรือถ้าเป็นกรณี iPhone ก็อาจจะเป็นให้ DB Server มี quota จำนวนลูกค้าไปเลยส่วนหนึ่ง (สมมติว่าสัก 5000 เครื่องต่อ server) ถ้ามี server นึงเต็มโควต้าไปแล้ว ก็หยุดแล้วให้ server ตัวอื่นทำงานแทน ตอนที่ application พยายามเขียน db ก็สุ่มเอาว่าจะเขียนลง db server ตัวไหน วิธีจะมีปัญหาคือตอนอ่านข้อมูลขึ้นมา เพราะต้องไปรันหาข้อมูลในหลาย ๆ server แต่ก็ไม่เป็นไรมั้ง ยังไงเรื่องการเขียนน่าจะสำคัญกว่า (ผมไม่รู้ว่าถ้าใช้ Distributed DB แล้วจะมีวิธีการทำ load balance ลักษณะนี้หรือเปล่านะครับ อาจจะมีก็ได้)

ข้างบนที่ว่ามาผมจินตนาการณ์เอานะครับ ไม่เคยลองเองแม้แต่นิด ในความเป็นจริงมันอาจจะไม่เวิร์คก็ได้

เจ็บกันไปเยอะ พวก impactที่เดียวกันแบบนี้ ถ้าไม่มีประสบการณ์ก็ตายเรียบ

ถ้าจะให้ทำรองรับงานนี้ ค่าใช้จ่ายไม่สูงมากหรอกครับ ปริมาณไม่ได้เยอะขนาดนั้น

การทำงานกับข้อมูลแบบแบบ burst กับ database นี่ผมว่าจริงๆแล้วคอขวดด้านประสิทธิภาพหลักๆไม่ได้ติดที่ CPU/Network Controller เลย คือ request หลักหมื่นที่ไม่ได้มีการคำนวนเยอะๆเนี่ย CPU ในปัจจุบันรองรับได้ค่อนข้างสบาย

คอขวดหลักๆน่าจะมาจากปัญหาด้าน I/O มากกว่า (ซึ่งส่งผลกระทบโดยตรงกับการทำ locking) ควรทำการ optimize คำสั่งต่างๆ(Application/SQL)ให้ดีๆ อาจใช้งาน DB Engine แบบ MEMORY หรือใช้ DB Engine ที่ทำการ Lock ในระดับต่ำๆ เช่น InnoDB ที่ lock ในระดับ ROW จากนั้นก็ปรับ Buffer Pool ให้ค่อนข้างใหญ่ และ/หรือ เปลี่ยนมาใช้ SSD เพื่อลดคอขวดตรงนี้ พอหลังจาก request แบบ burst หมดก็สบายแล้วครับ โอนข้อมูลจาก MEMORY ลงฐานข้อมูลปกติ

ไม่เกิน 20k transaction/sec Database ไม่มีปัญหาหรอกครับ

ร้านมีสองหมื่นสาขา ยังไงจองบัตรก็ต้องกรอกข้อมูล ไอ้เรื่องที่ Transaction เยอะจน Database ไม่ไหวไม่น่าใช่ อันนี้ต้องไปดูการออกแบบแล้ว ว่าทำยังไงให้ระบบล่มได้

ล่มยังกับระบบทะเบียนมหาลัย เปิดไม่ถึงห้านาที ซัดไปสี่หมื่นคน/วิ ก็เดี้ยงละ

คุ้นๆว่าใช้ db เจ้าที่ไม่ค่อยดังในไทยครับ

มันล่มเพราะคนเข้าเยอะ ดังนั้นถ้าเป็นผมนะ ผมแยกการขายตั๋วแต่ระรอบ เป็น 1 รอบ/ 1ระบบ

ประมาณว่าแยก web app แยก Server แยก DB เป็น 1รอบ/1ชุด

ง่าย และจบโดยไม่ต้องคิดอะไรมากมาย (@_@)!

ไปดูระบบใช้ขายตั๋ว olympic ปีที่ผ่านมาสิครับ