Amazon DynamoDB ฐานข้อมูลแบบ NoSQL ของ AWS มีอายุครบรอบ 10 ปีแล้วในปีนี้ (ออกเวอร์ชัน GA ในเดือนมกราคม 2012) ในโอกาสนี้ทำให้ AWS เล่าเบื้องหลังการสร้าง DynamoDB ขึ้นมา
เรื่องเริ่มจากเทศกาลคริสต์มาสปลายปี 2004 ที่มียอดสั่งซื้อเป็นจำนวนมาก ทำให้ระบบอีคอมเมิร์ซของ Amazon ที่ตอนนั้นใช้ฐานข้อมูลแบบ relational ถึงกับพัง เป็นสัญญาณบอกว่าฐานข้อมูลแบบ relational ถูกใช้จนถึงขีดจำกัดแล้ว
ทีมวิศวกรรมของ Amazon มีกระบวนการเรียกว่า Correction of Error (COE) มาพูดคุยทบทวนถึงปัญหาเทคนิคที่เกิดขึ้น เพื่อบันทึกไว้ไม่ให้เกิดซ้ำ ในการประชุมครั้งนั้นมีนักศึกษาฝึกงานอายุ 20 ปีชื่อ Swaminathan (Swami) Sivasubramanian ทักขึ้นมาว่าทำไมเรายังต้องใช้ฐานข้อมูลแบบ relational กัน เพราะตัวเนื้องานของ Amazon ไม่จำเป็นต้องใช้ความซับซ้อนระดับภาษา SQL และไม่จำเป็นต้องการันตี transaction ที่เกิดขึ้น
เหตุการณ์นั้นทำให้ทีมวิศวกรรมของ Amazon สร้างแนวคิดฐานข้อมูล Dynamo ขึ้นมา โดยมีโจทย์เรื่องการขยายตัว (scalability) และเสถียรภาพ (reliability) เพื่อตอบโจทย์ของธุรกิจอีคอมเมิร์ซ จนออกมาเป็นเปเปอร์ชื่อ Dynamo ในปี 2007 ที่มีแนวคิดของฐานข้อมูลแบบ key-value
เปเปอร์ Dynamo ถูกนำไปใช้งานโดยทีมภายในต่างๆ ของ Amazon ซึ่งพบว่าฐานข้อมูลมีประสิทธิภาพ เสถียรภาพ และรองรับการขยายตัวตามเป้าหมาย แต่ยังเจอปัญหาการติดตั้ง คอนฟิก และใช้งานตัวซอฟต์แวร์ภายในเครื่องของ Amazon เอง
ในช่วงเวลาเดียวกัน AWS ในฐานะบริการคลาวด์เพิ่งเริ่มต้นขึ้นเช่นกัน (เริ่มบริการครั้งแรกในปี 2002) โดย AWS ผลักดันฐานข้อมูล NoSQL อีกตัวคือ Amazon SimpleDB แต่ก็พบปัญหาในการสเกลเมื่อข้อมูลมีขนาดเกิน 10GB จะเริ่มมีระยะเวลา latency ไม่สม่ำเสมอ (ปัญหาเกิดจากขนาดของฐานข้อมูลและตัวดัชนี)
AWS จึงนำแนวคิดเรื่องการสเกลและ latency ที่สม่ำเสมอของ Dynamo มารวมร่างกับความเรียบง่ายในการดูแลของ SimpleDB จนออกมาเป็น DynamoDB ในท้ายที่สุด
ส่วน Swami นักศึกษาฝึกงานคนนั้น ร่วมเขียนเปเปอร์ Dynamo และปัจจุบันเป็น VP of the database, analytics, and ML ที่ AWS
ที่มา - AWS Blog
Comments
ชื่อคุณ Swami คล้าย ๆ คนอินเดียเลย ใช่คนอินเดียหรือเปล่านะ
เทคโนโลยีไม่ผิด คนใช้มันในทางที่ผิดนั่นแหละที่ผิด!?!
อันนี้โทษเด็กฝึกงานไม่ได้แล้ว เด็กฝึกงานดันเก่ง 555
Oracle หรือเปล่านะที่ล่มไป ฮ่าๆ
อยากหาอ่านเพื่อขยายความเข้าใจเรื่อง "ไม่จำเป็นต้องการันตี transaction ที่เกิดขึ้น" จะอ่านจากไหนได้บ้างครับ
ACID = Atomicity, Consistency, Isolation and Durability
คืองานหลายอย่างมันไม่จำเป็นต้อง query data จริงตลอด บางงานแบ่งโหลดไป cache ก็ได้ พวกข้อมูล product บางครั้งไม่ต้องล่าสุด รอ 30 นาที หรือนานกว่านั้นค่อยข้อมูลเอาล่าสุดมาแสดงก็ได้
หรืองานพวก session state ก็กระจายออกไปหลายๆ เครื่องก็ได้ ไม่จำเป็นต้องรวมไว้ที่เดียว อะไรแบบนั้น
แล้วแต่ use case
อย่างที่ผมใช้บ่อยๆ บน dynamodb คือ session state เก็บบนนั้นแล้วจบ หากคำนวณโหลดได้ก็ reserved capacity หากไม่มั่นใจโหลดก็ on-demand
ขอบคุณครับคุณฟอร์ด
โดยหลักใหญ่ของข้อมูลที่มีความสำคัญ และมีผลทางกฎหมายก็ต้องตามหลักที่คุณ Ford AntiTrust บอกนั่นแหล่ะ คือ ต้องมี Atomicity, Consistency, Isolation and Durability ซึ่งโดยหลักสรุปก็คือ ถึงแม้จะเกิดสถานการณ์ใดขึ้นข้อมูลจะต้องคงอยู่ ย้อนคืน และถูกต้อง สอดคล้องกันเสมอ ไม่ว่าจะสภาวะใดๆ ก็ตาม ไม่ว่าจะเป็น น้ำท่วม แผ่นดินไหว ไฟไหม้ HW หรือ SW พัง ฯลฯ ซึ่งในองค์กรขนาดใหญ่ก็จะเป็นหน้าที่ของ DBA กับ Infra ที่ต้องออกแบบให้รองรับทั้ง SW, HW และ Network
ถ้าสนใจลองหาคำว่า Database Cluster ดูครับ รายละเอียดมันเยอะ มันเป็นศาสตร์อีกสาขานึงของ Database Admin เลย
ส่วนคำว่า "ไม่จำเป็นต้องการันตี transaction ที่เกิดขึ้น" ลองอ่านหัวข้อ Database Cluster ในหัวข้อ High Availability (Failover) แบบ Active - Active ดูมันคือความหมายย้อนกลับนั่นเอง
ถ้าในบริษัทมี DBA หรือมี Partner ที่มี presale ที่ขาย Database ลองให้เขาอธิบายหัวข้อ Database Cluster ให้ฟัง แล้วทำความเข้าใจ จากนั้นคิดย้อนกลับ ก็จะเข้าใจความหมาย
ผมอยากเก่งเรื่องนี้เลยครับ ไม่ใช่เก่งแค่ sql หรือออกแบบ rdb อยากเก่งแบบคนในข่าวเลย ขอบคุณครับ
จากเด็กฝึกงานสู่ VP
แค่อ่านคำถามผมยังคิดว่าคนนี้โคตรเก่ง
เด็กฝึกงานใน Multiverse ที่แท้จริง คนนี้ไม่เตะปลั๊ก
สุดๆไปเลย
..: เรื่อยไป