อัพเดทบริการ Amazon DocumentDB ในปี 2024

บทความนี้แปลมาจากบทความภาษาญี่ปุ่นที่ชื่อว่า AWS入門ブログリレー2024〜 Amazon DocumentDB 編〜 โดยเจ้าของบทความนี้คือ คุณ emi

ภาพรวมของ Amazon DocumentDB

Amazon DocumentDB เป็น document-oriented database ที่มีการจัดการและเข้ากันได้กับ MongoDB

MongoDB คืออะไร?

MongoDB เป็น document database ที่เป็นโอเพนซอร์ส มีนักพัฒนาจำนวนมากใช้งาน และ DocumentDB ยังเข้ากันได้กับ MongoDB

https://www.mongodb.com/company/what-is-mongodb

Document-Oriented คืออะไร?

นี่คือหัวข้อหลักของบทความนี้ หากคุณเข้าใจว่า DocumentDB เป็น document database ที่เข้ากันได้กับ MongoDB แล้ว ส่วนที่เหลือมีสถาปัตยกรรมเกือบเหมือนกับ Amazon Aurora ทั้งหมด

document database เป็นประเภทหนึ่งของ NoSQL database

การแลกเปลี่ยนข้อมูลระหว่างไคลเอนต์และแอปพลิเคชันมักทำในรูปแบบ JSON เพื่อจัดเก็บข้อมูล JSON นี้ลงใน relational database (RDB) อย่างเหมาะสม จำเป็นต้องใช้ ORM (Object-Relational Mapping)
ORM เป็นเทคนิคการเขียนโปรแกรมที่ใช้แปลงข้อมูลระหว่างการเขียนโปรแกรม object-oriented และ relational database พูดง่ายๆ คือเป็นเครื่องมือที่แปลงข้อมูล JSON ให้สามารถใช้ใน relational databaseได้

การใช้ ORM ทำให้สามารถแปลงข้อมูล JSON ให้เข้ากับโครงสร้าง (schema) ของ relational database และจัดเก็บในตารางได้ แต่ก็มีค่าใช้จ่ายในการดำเนินการ

ในทางกลับกัน document database อย่าง MongoDB มีโครงสร้างข้อมูลที่คล้ายกับ JSON เรียกว่า BSON (Binary JSON) ด้วยเหตุนี้ จึงต้องการการปรับให้สอดคล้องกับข้อมูลที่ได้รับจากไคลเอนต์น้อยที่สุด และสามารถจัดเก็บข้อมูลได้อย่างยืดหยุ่น

ความแตกต่างของโมเดลข้อมูลระหว่าง relational database และ document database

ความแตกต่างหลักระหว่าง relational database (RDB) และ DocumentDB อยู่ที่โมเดลข้อมูลและวิธีการจัดโครงสร้างข้อมูล ใน RDB ข้อมูลถูกจัดโครงสร้างในตาราง โดยแต่ละตารางจะเป็นไปตามโครงสร้าง (schema) ที่กำหนดไว้ล่วงหน้า (ชื่อและประเภทข้อมูลของคอลัมน์) ในขณะที่ใน DocumentDB ข้อมูลถูกจัดเก็บเป็นเอกสารในรูปแบบ JSON โดยแต่ละเอกสารสามารถมีโครงสร้างของตัวเอง

ต่อไปนี้คือความแตกต่างของคำศัพท์ระหว่าง RDB และ DocumentDB

https://docs.aws.amazon.com/documentdb/latest/developerguide/document-database-documents-understanding.html

ตัวอย่างของ RDB เช่น MySQL จะจัดเก็บข้อมูลในรูปแบบตารางดังต่อไปนี้ ข้อมูลในแต่ละแถวมีรายการที่เหมือนกันทั้งหมด เช่น ชื่อ, อายุ, งานอดิเรก เป็นต้น

-- ดึงข้อมูลทุก record จาก users table
MySQL [sampledb]> SELECT * FROM users;
+----+-------+------+-------------------+---------------------+
| id | name  | age  | occupation        | hobbies             |
+----+-------+------+-------------------+---------------------+
|  1 | Alice |   25 | Software Engineer | reading, traveling  |
|  2 | Bob   |   30 | Sales Manager     | music, sports       |
|  3 | Carol |   27 | Data Analyst      | photography, hiking |
+----+-------+------+-------------------+---------------------+
3 rows in set (0.004 sec)

MySQL [sampledb]>

ใน DocumentDB ซึ่งเป็น document database ข้อมูลจะถูกจัดเก็บในรูปแบบคล้าย JSON ดังต่อไปนี้ มีการจัดเก็บสองเอกสาร (ใน document database เรียก record ว่า document) แต่โครงสร้างของทั้งสองไม่เหมือนกัน

// ดึง document ทั้งหมดจาก users collection
rs0 [direct: primary] test> db.users.find()
[
  {
    _id: ObjectId('6605ed165689bca78a1852b9'),
    fullName: 'Alice Smith',
    age: 25,
    nickname: 'Ally',
    city: 'New York',
    hobbies: [ 'reading', 'traveling' ]
  },
  {
    _id: ObjectId('6605ed285689bca78a1852ba'),
    name: 'Bob',
    age: 30,
    occupation: 'Sales Manager',
    interests: [ 'music', 'sports' ]
  }
]
rs0 [direct: primary] test>

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

ด้วยวิธีนี้ document database สามารถพัฒนาโมเดลข้อมูลได้อย่างง่ายดายตามความต้องการของแอปพลิเคชัน document database เหมาะสำหรับโครงสร้างข้อมูลที่ซับซ้อนหรือข้อมูลแบบลำดับชั้น

กรณีการใช้งาน

document database สามารถอัปเดตโมเดลข้อมูลได้อย่างยืดหยุ่นและรวดเร็วตามความต้องการ ด้วยคุณลักษณะนี้ จึงสามารถใช้ในกรณีต่อไปนี้ได้

• User Profile
  • ด้วยโครงสร้างที่ยืดหยุ่นและรองรับโครงสร้างแบบลำดับชั้น จึงสามารถแสดงข้อมูลที่มีคุณสมบัติแตกต่างกันสำหรับแต่ละผู้ใช้ได้อย่างเป็นธรรมชาติ และสามารถจัดการข้อมูลผู้ใช้จำนวนมากได้อย่างมีประสิทธิภาพด้วยความสามารถในการขยายตัว
• Real-time Application
  • เหมาะสำหรับแอปพลิเคชันที่ต้องการ low latency เช่น เกมหรือสื่อสังคมออนไลน์
• ระบบจัดการ Content
  • เหมาะสำหรับการจัดการเนื้อหาที่ต้องการโครงสร้างที่ยืดหยุ่น เช่น บทความหรือความคิดเห็นของผู้ใช้
• การจัดการแคตตาล็อกและสินค้าคงคลัง
  • เหมาะสำหรับแอปพลิเคชันที่มีโครงสร้างข้อมูลแบบลำดับชั้น เช่น ข้อมูลผลิตภัณฑ์หรือการจัดการสินค้าคงคลัง

https://docs.aws.amazon.com/documentdb/latest/developerguide/document-database-use-cases.html

ในกรณีต่อไปนี้ ควรพิจารณาใช้ RDS

• ต้องการดำเนินการ query ที่น่าเชื่อถือโดยใช้ transaction
• ต้องการใช้งานตามโครงสร้างที่กำหนดไว้ล่วงหน้า
• ต้องการใช้ ecosystem เช่น MySQL หรือ PostgreSQL

สถาปัตยกรรมของ DocumentDB

DocumentDB มีคลัสเตอร์ 2 ประเภท คือ "instance-based cluster" และ "elastic cluster" คลัสเตอร์แบบยืดหยุ่นใช้สำหรับวัตถุประสงค์พิเศษ ซึ่งจะกล่าวถึงเล็กน้อยในตอนท้ายของหัวข้อนี้

สถาปัตยกรรมของ instance-based cluster
สถาปัตยกรรมของ instance-based cluster ของ DocumentDB คล้ายกับ Amazon Aurora มาก

คลัสเตอร์ DocumentDB ถูกสร้างขึ้นภายใน subnet ของ VPC คลัสเตอร์ประกอบด้วย primary instance replica instance และcluster storage volume โดยเราสามารถมี primary instance ได้ 1 ตัว และ replica instance ที่รองรับการอ่านอย่างเดียวได้สูงสุด 15 ตัว
การเขียนทั้งหมดจะผ่าน primary instance ส่วน primary instance และ replica instance รองรับการอ่าน
ข้อมูลของคลัสเตอร์จะถูกจัดเก็บใน cluster volume โดยมีสำเนา 6 ชุด แบ่งเป็น 2 ชุดในแต่ละ Availability Zone หรือ AZ ทั้ง 3 เขต

ลักษณะเด่นคือ ภายในคลัสเตอร์แบ่งออกเป็น compute layer ที่รวม instance และ storage layer ที่รวม volume
หากการประมวลผล query หรือการรับ API ไม่ทัน สามารถปรับขนาดเฉพาะ compute layer ได้ และหากพื้นที่ว่างสำหรับจัดเก็บข้อมูลไม่เพียงพอ ก็สามารถปรับขนาดเฉพาะ storage layer ได้ นั่นหมายความว่าสามารถปรับขนาดได้อย่างยืดหยุ่นตามแอปพลิเคชันมากขึ้น

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

elastic cluster รองรับ MongoDB-compatible sharding API

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

Feature

Auto-scale volume
DocumentDB cluster volume ปรับขนาดอัตโนมัติทีละ 10 GB สูงสุดถึง 128 TiB ไม่จำเป็นต้องกำหนดขนาดโวลุ่ม

การปรับขนาด instance
สามารถปรับขนาดขึ้นได้โดยการเปลี่ยนประเภท instance
นอกจากนี้ replica instance ยังสามารถ Auto Scaling ได้

High Availability
เมื่อเกิดความล้มเหลวที่ primary instance จะทริกเกอร์การเปลี่ยนตัวสำรอง และหนึ่งใน replica instance ที่มีอยู่จะถูกเลื่อนขึ้นเป็น primary instance

นอกจากนี้ ข้อมูลจะถูกคัดลอก 2 ชุดในแต่ละ AZ ทั้ง 3 AZ รวมเป็น 6 ชุด ดังนั้นข้อมูลจะยังคงปลอดภัยแม้เกิดความล้มเหลวใน AZ

Backup and Restore
รองรับการสำรองข้อมูลอัตโนมัติตั้งแต่ 1 ถึง 35 วัน ภายในระบบจะมีกระบวนการสำรองข้อมูลอย่างต่อเนื่องที่เรียกว่า streaming backup ซึ่งช่วยให้สามารถกู้คืนข้อมูล ณ เวลาใดเวลาหนึ่งได้ (Point-in-Time Recovery หรือ PITR)

https://docs.aws.amazon.com/documentdb/latest/developerguide/backup_restore.html

ใน Aurora เนื่องจากมีการเก็บ transaction log ทุก 5 นาที จึงสามารถระบุเวลาที่ต้องการกู้คืนได้เฉพาะทุก 5 นาที แต่ใน DocumentDB สามารถระบุจุดเวลาที่ต้องการกู้คืนได้ถึงระดับวินาที

Security
การรับรองตัวตนและการอนุญาตสำหรับ DocumentDB management API ดำเนินการโดย IAM user, IAM roles และ IAM policy
การรับรองตัวตนสำหรับ DocumentDB database ดำเนินการโดย standard MongoDB tool and driver ที่มี Salted Challenge Response Authentication Mechanism (SCRAM) SCRAM เป็นกลไกการรับรองตัวตนเริ่มต้นสำหรับ MongoDB และกลไกนี้สามารถใช้ได้ใน DocumentDB ด้วย

Log
สามารถส่ง Audit log และ Slow Query Log ไปยัง CloudWatch Logs ได้

ความเข้ากันได้กับ MongoDB

DocumentDB รองรับความเข้ากันได้กับ MongoDB เช่น MongoDB 4.0 หรือ MongoDB 5.0 แอปพลิเคชัน, ไดรเวอร์, และเครื่องมือส่วนใหญ่ที่ใช้กับ MongoDB database ในปัจจุบันสามารถใช้กับ DocumentDB ได้โดยแทบไม่ต้องเปลี่ยนแปลง เช่นเดียวกับ MongoDB, สามารถดำเนินการกับ database ผ่าน mongo shell ได้

https://docs.aws.amazon.com/documentdb/latest/developerguide/compatibility.html

อย่างไรก็ตาม ก็ยังมีความแตกต่างบางอย่างในด้านฟังก์ชันการทำงาน โปรดตรวจสอบความแตกต่างเหล่านี้อย่างละเอียดก่อนที่จะย้ายจาก MongoDB ไปยัง DocumentDB

https://docs.aws.amazon.com/documentdb/latest/developerguide/functional-differences.html

ค่าบริการ

DocumentDB มีการกำหนดค่าบริการใน 4 องค์ประกอบดังนี้

• On-Demand Instances
• Database I/O
• Database Storage
• Backup Storage

1. On-Demand Instances
   การคิดค่าบริการขึ้นอยู่กับสเปคของ instance การคำนวณของคลัสเตอร์และเวลาที่ใช้งาน โดยคิดค่าบริการขั้นต่ำที่ 10 นาทีต่อวินาที

ตัวอย่างราคา ณ ธันวาคม 2024 ในภูมิภาคสิงคโปร์
ตัวอย่างราคาสำหรับอินสแตนซ์ที่เหมาะสมกับหน่วยความจำ

ตัวอย่างราคาสำหรับ instance แบบทั่วไป

2. Database I/O
   การคิดค่าบริการขึ้นอยู่กับปริมาณ I/O ที่ใช้เมื่อทำการอ่านและเขียนข้อมูลลงใน storage volume ของคลัสเตอร์ โดยคิดค่าบริการต่อ 1 ล้าน I/O

ราคา ณ ธันวาคม 2024 ในภูมิภาคสิงคโปร์

3. Database Storage
   การคิดค่าบริการขึ้นอยู่กับปริมาณข้อมูลที่จัดเก็บใน storage volume ของคลัสเตอร์ โดยคิดค่าบริการต่อ GB ต่อเดือน

ราคา ณ ธันวาคม 2024 ในภูมิภาคสิงคโปร์

4. Backup Storage
   ไม่มีค่าใช้จ่ายเพิ่มเติมสำหรับพื้นที่จัดเก็บสำรองข้อมูลจนกว่าจะเกิน 100% ของพื้นที่จัดเก็บรวมของ DocumentDB cluster ในหนึ่งภูมิภาค นอกจากนี้ จะไม่มีค่าใช้จ่ายเพิ่มเติมสำหรับพื้นที่จัดเก็บสำรองข้อมูลหากระยะเวลาการเก็บรักษาการสำรองข้อมูลเป็น 1 วัน และไม่มี manual snapshot ที่เกินระยะเวลาการเก็บรักษา

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

https://aws.amazon.com/th/documentdb/pricing/

สรุป

สำหรับผู้ที่ต้องการใช้ NoSQL หรือใช้บริการ MongoDB อยู่แล้วและต้องการย้ายทรัพยากรมาใช้งานบน AWS บริการ DocumentDB ถือว่าเป็นบริการที่ตอบโจทย์ผู้ใช้งานได้เป็นอย่างดี

บทความต้นฉบับ

• AWS入門ブログリレー2024〜 Amazon DocumentDB 編〜(ภาษาญี่ปุ่น)