AWS MySQL RDS เทียบกับ AWS DynamoDB [ปิดแล้ว]

109

ปิด . คำถามนี้เป็นคำถามความคิดเห็นตาม ขณะนี้ยังไม่ยอมรับคำตอบ

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

ปิดให้บริการใน7 ปีที่ผ่านมา

ปรับปรุงคำถามนี้

ฉันใช้ MySQL มาพอสมควรแล้วและฉันก็พอใจกับโครงสร้างและแบบสอบถาม SQL เป็นต้น

ขณะนี้กำลังสร้างระบบใหม่ใน AWS และฉันได้ดู DynamoDB ตอนนี้ฉันรู้เพียงเล็กน้อยเกี่ยวกับเรื่องนี้

หนึ่งดีกว่าอีกหรือไม่?

ข้อดีของ DynamoDB คืออะไร?

การเปลี่ยนจากแบบสอบถาม MySQL ฯลฯ เป็นฐานข้อมูลแบบแบนนี้เป็นอย่างไร

— อดัม
แหล่งที่มา

66

คุณสามารถอ่านคำอธิบาย AWS เกี่ยวกับเรื่องนี้ที่นี่

ในระยะสั้นหากคุณมีแบบสอบถามการค้นหาเป็นหลัก(และไม่ใช่การสืบค้นเข้าร่วม) DynamoDB (และ NoSQL DB อื่น ๆ ) จะดีกว่า หากคุณต้องการจัดการข้อมูลจำนวนมากคุณจะถูก จำกัด เมื่อใช้ MySQL (และ RDBMS อื่น ๆ )

คุณไม่สามารถใช้คำค้นหา MySQL หรือสคีมาข้อมูลของคุณซ้ำได้ แต่ถ้าคุณใช้ความพยายามในการเรียนรู้ NoSQL คุณจะเพิ่มเครื่องมือที่สำคัญลงในกล่องเครื่องมือของคุณ มีหลายกรณีที่ DynamoDB ให้วิธีที่ง่ายที่สุด

— ผู้ชาย
แหล่งที่มา

262

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

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

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

ประโยชน์หลักสำหรับการใช้ DynamoDB เป็นที่เก็บ NoSQL คือคุณจะได้รับการรับประกันปริมาณงานอ่าน / เขียนในระดับใดก็ตามที่คุณต้องการโดยไม่ต้องกังวลกับการจัดการที่เก็บข้อมูลแบบคลัสเตอร์ ดังนั้นหากแอปพลิเคชันของคุณต้องการการอ่าน / เขียน 1,000 ครั้งต่อวินาทีคุณสามารถจัดเตรียมตาราง DynamoDB ของคุณสำหรับปริมาณงานระดับนั้นและไม่ต้องกังวลเกี่ยวกับโครงสร้างพื้นฐานที่สำคัญ

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

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

— ไมค์แบรนต์
แหล่งที่มา

10

ถ้าฉันสามารถโหวตให้คำตอบของคุณได้ 100 คะแนนฉันจะทำ

— สลิล

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

— user398039

150

เราเพิ่งย้ายตาราง DynamoDB ทั้งหมดไปยัง RDS MySQL

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

นี่คือเหตุผลของเราที่เราย้ายจาก DynamoDB:

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

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

เท่าที่มีข้อดีฉันจะบอกว่า Scalability and Durability มันปรับขนาดได้อย่างเหลือเชื่อและโปร่งใสและ (เรียงลำดับ) ขึ้นเสมอ สิ่งเหล่านี้เป็นคุณสมบัติที่ยอดเยี่ยมจริง ๆ แต่ไม่ได้ชดเชยข้อเสียใด ๆ

— ยามิกลิก
แหล่งที่มา

11

ข้อดี / ข้อเสียที่เฉพาะเจาะจงมาก คำตอบที่ดี

— stevendesu

10

บางส่วนนี้ล้าสมัย ตัวอย่างเช่น 1 ไม่เป็นความจริงอีกต่อไป

— mbroshi

2

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

— doles

1

ไดนาโมยังขาดความยืดหยุ่นในขณะที่การสืบค้น แม้ว่า GSI จะช่วยได้มาก แต่เรายังสามารถสร้างโมเดลข้อมูลของเราได้ดีขึ้นด้วยสคีมา RDBMS

— Pavan

1

ฉันจะเพิ่มว่าความสามารถในการสืบค้นภายใน DynamoDB มี "gotchas" อยู่เล็กน้อย ตัวอย่างเช่นหากคีย์หลักของคุณประกอบด้วยแฮชเท่านั้นคิวรีไดนาโมสามารถส่งคืนได้เพียง 1 รายการคุณไม่สามารถระบุช่วงให้กับคีย์แฮชอย่างเดียวในเวลาสืบค้นและไม่สามารถค้นหาโดยไม่ทราบแฮชเฉพาะของ รายการที่คุณกำลังมองหา BatchGet ยอมรับคำขอเพียง 100 รายการขนาดการตอบกลับทั้งหมด 1MB หรือขนาดแบบสอบถามทั้งหมด 1MB แล้วแต่ว่ากรณีใดจะเกิดขึ้นก่อน Scan ช่วยให้คุณค้นหาได้อย่างยืดหยุ่น แต่ไม่มีประสิทธิภาพและเสียค่าใช้จ่ายสูงโดยส่งคืนตารางทั้งหมดก่อนที่จะกรอง

— Brooks

12

เมื่อใช้ DynamoDB คุณควรทราบด้วยว่ารายการ / ระเบียนใน DynamoDB ถูก จำกัด ไว้ที่ 400KB (ดูขีด จำกัด DynamoDB ) สำหรับกรณีการใช้งานจำนวนมากสิ่งนี้จะไม่ทำงาน ดังนั้น DynamoDB จะดีสำหรับบางสิ่ง แต่ไม่ใช่ทั้งหมด เช่นเดียวกันกับฐานข้อมูล NoSQL อื่น ๆ

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