DynamoDB กับ MongoDB NoSQL [ปิด]

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

ตัวเลือกแรกที่อยู่ในใจของฉันคือ mongo db เนื่องจากเป็นผลิตภัณฑ์ที่โตมากพร้อมการสนับสนุนมากมายจากชุมชน แต่ในทางกลับกันเราได้ผลิตภัณฑ์ใหม่ล่าสุดที่ให้บริการที่มีประสิทธิภาพสูงสุดฉันจะพัฒนาสิ่งนี้ แอปพลิเคชั่น แต่ตอนนี้ยังไม่มีแผนการบำรุงรักษา (อย่างน้อยตอนนี้) ดังนั้นฉันคิดว่ามันจะเป็นข้อได้เปรียบอย่างมากเนื่องจาก Amazon ให้วิธีที่ยืดหยุ่นในการขยายขนาด

ความกังวลหลักของฉันเกี่ยวกับโครงสร้างการสืบค้นฉันยังไม่ได้ดูความสามารถในการสืบค้น dynamoDB แต่เนื่องจากการจัดเก็บข้อมูล ak / v ฉันรู้สึกว่านี่อาจมีข้อ จำกัด มากกว่า mongo db

หากมีคนมีประสบการณ์ในการย้ายโครงการจาก mongoDB ไปยัง DynamoDB คำแนะนำใด ๆ จะได้รับการชื่นชมอย่างสมบูรณ์

ฉันเพิ่งย้าย MongoDB ของฉันไปยัง DynamoDB และเขียนบล็อก 3 รายการเพื่อแบ่งปันประสบการณ์และข้อมูลเกี่ยวกับประสิทธิภาพราคา

โอนย้ายจาก MongoDB ไปยัง AWS DynamoDB + SimpleDB

7 เหตุผลที่คุณควรใช้ MongoDB ผ่าน DynamoDB

3 เหตุผลที่คุณควรใช้ DynamoDB บน ​​MongoDB

ฉันรู้ว่านี่เก่า แต่ก็ยังเกิดขึ้นเมื่อคุณค้นหาการเปรียบเทียบ เราใช้ Mongo ย้ายไปที่ Dynamo เกือบทั้งหมดซึ่งเป็นตัวเลือกแรกของเราตอนนี้ ไม่ใช่เพราะมันมีคุณสมบัติมากกว่า แต่ก็ไม่ได้ Mongo มีภาษาข้อความค้นหาที่ดีกว่าคุณสามารถสร้างดัชนีภายในโครงสร้างมีสิ่งต่าง ๆ มากมาย ความเหนือกว่าของไดนาโมคือสิ่งที่ OP ระบุไว้ในความคิดเห็นของเขา: มันง่าย คุณไม่ต้องดูแลเซิร์ฟเวอร์ใด ๆ เมื่อคุณเริ่มตั้งค่าโซลูชัน Mongard ที่มีปัญหามันจะซับซ้อน คุณสามารถไปที่หนึ่งใน บริษัท โฮสติ้ง แต่ก็ไม่ถูกอย่างใดอย่างหนึ่ง ด้วย Dynamo หากคุณต้องการปริมาณงานที่มากขึ้นคุณเพียงคลิกปุ่ม คุณสามารถเขียนสคริปต์เพื่อขยายขนาดโดยอัตโนมัติ เมื่อถึงเวลาอัพเกรดไดนาโมก็ทำเพื่อคุณแล้ว นั่นคือความเครียดและเวลาที่ไม่ได้ใช้ ถ้าคุณไม่ได้

ดังนั้นเราจะเริ่มต้นด้วย Dynamo ตามค่าเริ่มต้น Mongo อาจจะถ้าโครงสร้างข้อมูลนั้นซับซ้อนเพียงพอที่จะรับประกัน แต่เราอาจจะกลับไปที่ฐานข้อมูล SQL ไดนาโมเป็นป้านคุณต้องคิดจริงๆว่าคุณจะสร้างมันอย่างไรและมีแนวโน้มว่าคุณจะใช้ Redis ใน Elasticcache เพื่อให้มันทำงานกับสิ่งที่ซับซ้อน แต่มันก็ดีที่จะไม่ต้องดูแลมัน คุณรหัส แค่นั้นแหละ.

ด้วยเอกสารขนาด 500k ไม่มีเหตุผลที่จะขยายขนาดเอกสารใด ๆ แล็ปท็อปทั่วไปที่มี SSD และหน่วยความจำ 8GB สามารถทำบันทึกได้ 10 ล้านล้านรายการดังนั้นหากคุณพยายามเลือกเพราะขนาดที่คุณเลือกไม่สำคัญ ฉันขอแนะนำให้คุณเลือกสิ่งที่คุณชอบมากที่สุดและบางทีคุณอาจจะได้รับการสนับสนุนออนไลน์ที่สุด

สำหรับการเปรียบเทียบภาพรวมอย่างรวดเร็วฉันชอบเว็บไซต์นี้มากที่มีหน้าเปรียบเทียบมากมายเช่น AWS DynamoDB กับ MongoDB; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

คำตอบสั้น ๆ : เริ่มต้นด้วย SQL และเพิ่ม NoSQL เฉพาะเมื่อ / ถ้าจำเป็น (ยกเว้นว่าคุณไม่ต้องการอะไรนอกเหนือจากการสืบค้นที่ง่ายมาก)

ประสบการณ์ส่วนตัวของฉัน: ฉันไม่ได้ใช้ MongoDB สำหรับการสืบค้น แต่ ณ เดือนเมษายน 2015 DynamoDB ยังพิการมากเมื่อพูดถึงสิ่งอื่นนอกเหนือจากการค้นหาคีย์ / ค่าพื้นฐานที่สุด ฉันรักมันสำหรับสิ่งพื้นฐาน แต่ถ้าคุณต้องการภาษาแบบสอบถามแล้วมองไปที่โซลูชันฐานข้อมูล SQL จริง

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

เพื่อให้เฉพาะเจาะจงเกี่ยวกับปัญหาขีด จำกัด ของตัวกรองในแบบสอบถามนี้มาจากเอกสาร ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ):

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

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

ความคิดเห็นของผู้เชี่ยวชาญ: ในการประชุมสุดยอด AWS เมื่อวันที่ 9 เม.ย. 2558 Brett Hollman ผู้จัดการฝ่ายสถาปัตยกรรมโซลูชัน AWS พูดคุยกับผู้ใช้ 10 ล้านคนแรกที่เริ่มต้นด้วยฐานข้อมูล SQL จากนั้นใช้ NoSQL เมื่อใดก็ตาม เพราะไม่ช้าก็เร็วคุณอาจต้องมีเซิร์ฟเวอร์ SQL ในสแต็กของคุณ สไลด์ของเขาอยู่ที่นี่: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users ดูสไลด์ 28

เราเลือกส่วนผสมของ Mongo / Dynamo สำหรับผลิตภัณฑ์ดูแลสุขภาพ โดยทั่วไป mongo ช่วยให้การค้นหาดีขึ้น แต่ Dynamo ที่โฮสต์นั้นยอดเยี่ยมเพราะเป็นไปตามมาตรฐาน HIPAA โดยไม่มีการทำงานพิเศษใด ๆ ดังนั้นเราจึงโฮสต์ส่วน mongo โดยไม่มีข้อมูลส่วนบุคคลในการตั้งค่ามาตรฐานและอนุญาตให้ amazon จัดการกับส่วน HIPAA ในแง่ของโครงสร้างพื้นฐาน เราสามารถค้นหาบางรายการจาก Mongo ซึ่งแสดงเอกสารด้วยพอยน์เตอร์ (ID's) ของเอกสาร Dynamo ที่เกี่ยวข้อง

เหตุผลหลักที่เราเลือกทำโดยใช้ mongo แทนการโฮสต์แอปพลิเคชันทั้งหมดบนไดนาโมนั้นมี 2 เหตุผล ก่อนอื่นเราต้องทำการ preform การค้นหาตามสถานที่ซึ่ง mongo นั้นยอดเยี่ยมในเวลานั้นไดนาโมไม่ได้ แต่พวกเขามีตัวเลือกตอนนี้

ประการที่สองคือเอกสารบางอย่างไม่มีโครงสร้างและเราไม่ทราบล่วงหน้าว่าข้อมูลจะเป็นเช่นไรสมมติว่าผู้ใช้ป้อนเอกสารในคอลเลกชัน "ฟอร์ม" เช่นนี้: {"ชื่อผู้ใช้": "ผู้ใช้ 1", " อีเมล ":" me@me.com "} และผู้ใช้รายอื่นวางสิ่งนี้ไว้ในคอลเล็กชันเดียวกัน {"phone": "813-555-3333", "location": [28.1234, -83.2342]} ด้วย mongo เราสามารถค้นหาเขตข้อมูลไดนามิกและไม่รู้จักเหล่านี้ได้ทุกเวลาด้วย Dynamo คุณสามารถทำได้ แต่จะต้องสร้างดัชนีทุกครั้งที่มีการเพิ่มเขตข้อมูลใหม่ที่คุณต้องการค้นหา ดังนั้นหากคุณไม่เคยมีช่องโทรศัพท์ในเอกสารไดนาโมของคุณมาก่อนและทันใดนั้นบางคนก็เพิ่มมันมันไม่สามารถค้นหาได้อย่างสมบูรณ์

ทีนี้นี่จะเป็นอีกจุดที่คุณพูดถึง บางครั้งการเลือกโซลูชันที่เหมาะสมสำหรับงานนั้นไม่ได้หมายความว่าการเลือกผลิตภัณฑ์ที่ดีที่สุดสำหรับงานเสมอไป ตัวอย่างเช่นคุณอาจมีลูกค้าที่ต้องการและจะใช้ระบบที่คุณสร้างมานานกว่า 10 ปี การใช้โซลูชัน SaaS / IaaS ที่ดีพอที่จะทำงานให้เสร็จอาจเป็นตัวเลือกที่ดีกว่าเพราะคุณสามารถพึ่งพา amazon เพื่อคอยดูแลและบำรุงรักษาระบบของพวกเขาในระยะยาว

ฉันได้ทำงานกับทั้งคู่และเป็นแฟนของทั้งคู่

แต่คุณต้องเข้าใจว่าจะใช้เมื่อไรและเพื่ออะไร

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

ฉันจะไปหา DB แบบไฮบริดที่ซึ่งข้อมูลที่สามารถสืบค้นได้อย่างกว้าง ๆ ควรจะมี MongoDB ด้วยคุณลักษณะทั้งหมดที่คุณไม่เคยรู้สึกว่าถูก จำกัด ให้มีการปรับปรุงหรือแก้ไข

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

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

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

ควรใช้ DynamoDB ในกรณีที่ความเร็วมีความสำคัญ MongoDB ในทางกลับกันมีมือและคุณสมบัติมากเกินไปบางสิ่งที่ DynamoDB ขาด

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

นั่นคือความคิดเห็นของฉัน

โปรดจำไว้ว่าฉันได้ทดลองกับ MongoDB เท่านั้น

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

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

Takeaway ของฉัน: ถ้าคุณกำลังทำแบบสอบถามฐานข้อมูลที่ร้ายแรงหรือทำงานในภาษาที่ไม่ได้รับการสนับสนุนโดย DynamoDB ให้ใช้ MongoDB มิฉะนั้นติดกับ DynamoDB