MongoDB เป็นตัวเลือกที่ถูกต้องในกรณีของฉันหรือไม่? [ปิด]

ฉันจะสร้างโปรเจ็กต์แรกของฉันใน Rails ซึ่งประกอบด้วยในเว็บแอปที่ประกอบด้วย 3 ส่วนหลัก:

• ส่วนคงที่ที่ไม่มีการใช้ฐานข้อมูล
• ส่วนการลงทะเบียนผู้ใช้ซึ่งจะต้องใช้ฐานข้อมูลและฉันสามารถใช้ MySQL ได้เนื่องจากแถวของผู้ใช้แต่ละคนจะมีเขตข้อมูลเดียวกัน
• "แอป" ที่ผู้ใช้จะสามารถสร้างจัดการแก้ไข ... รายการในคอลเล็กชันและแบ่งปันกับผู้ใช้รายอื่น

จะมีหลายประเภทรายการและแต่ละประเภทจะมีตัวเลือกต่างกันเช่นฉันอาจมีรายการ "วิดีโอ" พร้อมตัวเลือกต่อไปนี้:

• รหัส
• user_id
• collection_id
• หัวข้อ
• แพลตฟอร์ม (ถ้าฝัง)
• URL (ถ้าฝัง)
• ชื่อไฟล์ (หากโฮสต์บนแอปของฉัน)
• ขนาดไฟล์ (id โฮสต์บนแอปของฉัน)

และรายการ "แผนที่":

• รหัส
• user_id
• collection_id
• หัวข้อ
• แพลตฟอร์ม (แผนที่ google, แผนที่ bing ... )
• ที่ตั้ง
• URL
• ขนาดแผนที่

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

ถึงตอนนี้ฉันมักจะใช้ PHP และ MySQL (บนพื้นที่สาธารณะที่ใช้ร่วมกันสำหรับโครงการขนาดเล็ก) และความสามารถในการปรับขนาดนั้นเป็นคำศัพท์ใหม่สำหรับฉันทั้งหมด

ฉันมีเวลาเรียนรู้ แต่ฉันอยากจะทำสิ่งที่เป็นรูปธรรมในบางสิ่งอย่างเช่น 1 เดือน

ฉันได้อ่านมากเกี่ยวกับ MongoDB และ NoSQL vs RDMS และ MySQL และหลังจากลองฉันต้องบอกว่าฉันชอบวิธีการทำงานของ MongoDB: ไม่มีตารางไม่มีแถวและเอกสาร JSON เช่น:

• ในสถานการณ์ของฉันคุณจะแรคคูน? ทำไม?
• เกี่ยวกับความสามารถในการปรับขยายอาจมีปัญหากับ MongoDB หรือไม่ ถ้าใช่เมื่อ (ในแง่ของขนาดฐานข้อมูล) และปัญหาเหล่านี้อาจทำให้แอปของฉันช้าลงอย่างมาก?

แก้ไข: แอพจะทำงานอย่างไร

เนื่องจากหลายคนถามว่านี่เป็นวิธีที่ฉันต้องการให้แอปทำงาน:

1. ผู้ใช้ลงทะเบียน
2. เขาเข้าสู่ระบบ
3. เขาสร้างคอลเล็คชั่นแรกของเขาซึ่งเขาสามารถสร้างไอเท็มไม่สิ้นสุด
4. รายการมีหลากหลายประเภทและแต่ละประเภทต้องการข้อมูลที่แตกต่างกันเพื่อบันทึกในฐานข้อมูลและประเภทของรายการอาจถูกเพิ่มหรือแก้ไข

ผู้ใช้สามารถสร้างคอลเลกชันและรายการอื่น ๆ ที่อยู่ภายใน

ดังนั้นเราจึงมี CRUD สำหรับคอลเลกชันและรายการภายในของพวกเขาและแต่ละคอลเลกชัน / รายการจะเรียกผู้ใช้เฉพาะ

ปัญหาหลักของ MySQL คือมันไม่มี schema ที่ยืดหยุ่นมีวิธีแก้ไขปัญหานี้หรือไม่?

คิดเกี่ยวกับ NoSQL ข้อสงสัยเดียวที่ฉันมีเกี่ยวกับการเข้าร่วมตัวอย่างเช่นมีการรวบรวมบางอย่างที่ฉันต้องการดึงข้อมูลที่เกี่ยวข้องกับผู้ใช้ที่มี id = user_id ในคอลเลกชัน

แก้ไข: ความคิดที่จะใช้ MySQL ต่อไป

สร้างเขตข้อมูลในตาราง "รายการ" ด้วยการตั้งค่าเพิ่มเติมแต่ละการตั้งค่าหารด้วย | หรือสัญลักษณ์อื่น

จากนั้นฉันจะบันทึกโครงสร้างของการตั้งค่าเพิ่มเติมแต่ละรายการตัวอย่างเช่น "หมายเหตุ" ประเภทรายการต้องการการตั้งค่าเพิ่มเติมสองแบบ "สี" และ "strange_setting" เมื่อฉันได้รับข้อมูลจาก MySQL ฉันจะแยกฟิลด์สำหรับการตั้งค่าเพิ่มเติมลงใน array รู้ว่ารายการแรกในอาร์เรย์มีไว้สำหรับ "color" และอื่น ๆ

คุณคิดอย่างไร? มีปัญหากับวิธีแก้ไขปัญหาเหรอ? คุณมีความคิดอื่น ๆ อีกไหม?

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

อย่างที่บางคนเคยบอกกับฉันที่นี่บน SO:

ส่วนเชิงสัมพันธ์ของฐานข้อมูลเชิงสัมพันธ์นั้นได้รับการปรับให้เหมาะสมกว่าส่วนอื่น ๆ

หมายความว่าคุณสามารถใช้ฐานข้อมูลเชิงสัมพันธ์ได้เช่นกันถ้ามันดูเหมือนว่าเหมาะสมกับกรณีการใช้งานของคุณ อย่าเพิ่งไปข้างหน้ากับ MongoDB เพราะความยืดหยุ่น / ความสามารถในการปรับขยายได้ นี่เป็นบรรทัดแรกเกี่ยวกับ MongoDB บน ​​Wikipedia:

MongoDB (จาก "humongous") เป็นระบบฐานข้อมูล NoSQL แบบโอเพ่นซอร์สที่มุ่งเน้นเอกสาร

คุณตั้งใจจะใช้ฐานข้อมูลเชิงเอกสารจริงๆหรือ? หากมีความยุ่งยากในการใช้งานของคุณคุณอาจจะต้องใช้ฐานข้อมูลกราฟอย่าง Neo4j หรือคุณสามารถใช้ SQL และ NoSQL ร่วมกันได้ดีที่สุดเช่นเดียวกับบางคน

BTW ฉันยังทำโครงการที่ฉันใช้ส่วนที่ดีที่สุดของทั้ง SQL และ NoSQL

แก้ไข: ฉันพูดอีกครั้ง:

ตรวจสอบNeo4j VS Hadoopส่วนนี้บทความ มันบอกว่า:

ในหลักการ Hadoop และร้านค้าอื่น ๆ key-value จะเกี่ยวข้องส่วนใหญ่กับโครงสร้างข้อมูลค่อนข้างแบน กล่าวคือพวกมันรวดเร็วและสามารถปรับขนาดได้เกี่ยวกับการดึงวัตถุอย่างง่ายเช่นค่าเอกสารหรือแม้แต่วัตถุ

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

นอกจากนี้คุณอาจต้องการอ้างอิงคำถามเหล่านี้:

/programming/2124274/mongodb-what-to-know-before-using

/programming/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems

( ลองดูคำตอบด้านบน / ที่เลือกของคำถามที่สองอย่างแน่นอนคุณอยู่ในภาวะที่ลำบากซึ่งสิ่งนี้อาจแก้ไขได้ )

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

แก้ไขอีกครั้ง (สำหรับส่วน MySQL): ตามที่ฉันเข้าใจแล้วคุณกำลังวางแผนที่จะจัดเก็บบางอย่างในฐานข้อมูลและแยกพวกเขาผ่านตัวคั่น สิ่งนี้นำเสนอ 2 ปัญหา:

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

   ส่วนเชิงสัมพันธ์ของฐานข้อมูลเชิงสัมพันธ์นั้นได้รับการปรับให้เหมาะสมกว่าส่วนอื่น ๆ (เช่นการจับคู่สตริง)

3. อย่าใช้คุณลักษณะที่มีหลายค่า คนทั่วไปกลัวพวกเขา

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

ฉันคิดว่าชุดค่าผสมที่ดีที่สุดนั้นแน่นอนทั้งสองและฉันอยากจะยกย่องคุณสำหรับวิธีการใช้ mylsql สำหรับบางส่วนเช่นผู้ใช้ แต่ใช้ MongoDB สำหรับส่วนอื่น ๆ เนื่องจากฉันรู้สึกว่าการรับรองความถูกต้องและการอนุญาตทำได้ดีที่สุดกับ mySQL และ ตัวอย่างและโมดูลจำนวนมากที่ทำได้ดีจริงๆ

สำหรับชิ้นส่วน 'รายการจำนวนมาก' นั่นคือสิ่งที่คุณต้องการพิจารณาใช้ mongoDB หากปริมาณของคุณสูงและ / หรือส่วนใหญ่จะอ่านและ / หรือเป็นข้อมูลที่ไม่มีโครงสร้าง

ฉันขอแนะนำว่าอย่ายึดการตัดสินใจของคุณกับความยืดหยุ่นของ schema-less ของ Mongo SQL และ sql-schemas เกิดขึ้นจากความต้องการข้อมูลที่มีโครงสร้างและสามารถทำการคำนวณและการแปลงที่เป็นไปได้กับโครงสร้างดังกล่าวเท่านั้น ฉันเรียนรู้สิ่งนี้จาก 5 ปีที่ทำงานในบทบาทคลังข้อมูล ฉันแค่มองไปที่ MongoBD สำหรับปัญหาด้านประสิทธิภาพเท่านั้น หากคุณหรือคาดว่าจะมีผู้ใช้และคำขอจำนวนมากพูดได้ 100,000 ผู้ใช้และร้องขอ 20 ครั้งต่อวินาทีฉันจะใช้ mongoDB ไม่เช่นนั้นฉันจะพยายามอยู่กับ sql ในหลายกรณีฉันจะใช้ mySQL สำหรับปริมาณน้อยและจากนั้นปริมาณและรายได้และโครงสร้างพื้นฐานก็สนับสนุนให้เปลี่ยนเป็น Oracle ก่อนที่จะผสมใน mongoDB ฉันยอมรับว่าคุณไม่ควรพยายามจัดการกับปัญหาเกี่ยวกับปริมาณก่อนที่คุณจะประสบปัญหาอย่างไรก็ตามหากคุณมีความคิดที่เป็นธรรมว่าคุณกำลังมุ่งหน้าไปที่ใดและไม่ ' ไม่ต้องการที่จะเขียนสิ่งต่าง ๆ อีกครึ่งทางมันสมเหตุสมผลที่จะเลือกเทคโนโลยีที่เหมาะสมที่สุด เพียงจำไว้ว่าถ้าคุณมีปริมาณมากจริง ๆ มีตัวเลือกและเทคโนโลยีจำนวนมากในทุกระดับของสแต็กที่คุณจะใช้ดู

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

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

fyi Rick Obsorne มีแผนภาพเปรียบเทียบที่น่าทึ่งซึ่งค่อนข้างมีเอกลักษณ์!

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

หากคุณเลือกที่จะไปตามเส้นทาง NoSQL (และพร้อมที่จะรับค่าใช้จ่ายที่มาพร้อมกับมัน - ไม่ต้องเข้าร่วมเหมือนกัน) ให้พิจารณา AWS DynamoDB (http://aws.amazon.com/dynamodb/) ที่นี่คุณสามารถลืมส่วนการปรับขนาดฐานข้อมูลทั้งหมดและมุ่งเน้นไปที่แอปพลิเคชันของคุณ โชคดี.

คำเตือน: ฉันเป็นนักพัฒนาในทีม AWS DynamoDB แต่ฉันเชื่อในผลิตภัณฑ์ของเราอย่างแท้จริง ลองดู :)

ดังนั้นการออกแบบของคุณจะถูกบันทึกลงในฐานข้อมูลของคุณสองชนิดของวัตถุที่แตกต่างกัน:

• วัตถุผู้ใช้ (ซึ่งมีเขตข้อมูลเสมอ)
• แอปวัตถุ (ซึ่งสามารถมีฟิลด์ต่างกัน) แอปจะเป็นของผู้ใช้คนเดียวเท่านั้น

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

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

ใน MySQL คุณจะมีปัญหาในการจัดการกับรูปแบบที่แตกต่างกันสำหรับแอพที่แตกต่างกัน แต่เป็นไปได้ ความคิดบางอย่าง:

• คุณสามารถสร้างตารางกลางที่มีข้อมูลทั่วไปทั้งหมดระหว่างวัตถุทั้งหมด (id, user_id, ชื่อและอื่น ๆ ) จากนั้นพิมพ์เพื่อให้คุณสามารถค้นหาได้ในตารางอื่นโดยมีเฉพาะฟิลด์ที่ไม่ใช่รูปแบบทั่วไป (เช่น file_name และ file_size สำหรับไฟล์) คุณจะต้องสร้างตารางที่แตกต่างกันสำหรับแต่ละรูปแบบที่แตกต่างกัน หากตารางทั้งสองมีการจัดทำดัชนีโดย app_id (คีย์หลัก) มันจะเร็วพอเนื่องจากการเข้าถึงตารางโดยค่าดัชนีจะเร็ว
• คุณสามารถเข้ารหัสข้อมูลในบางรูปแบบและจัดเก็บมาตรฐาน เช่นเข้ารหัสข้อมูลที่ไม่ทั่วไปใน JSON เป็นสตริงและเก็บไว้ในฟิลด์ VARCHAR ระวังขนาดของเขตข้อมูลนั้นเพื่อที่คุณจะได้ไม่เหลือพื้นที่ รูปแบบอาจซับซ้อน (JSON) หรือแบบง่าย (ค่าที่คั่นด้วยเครื่องหมายจุลภาค)
• คุณสามารถสร้างฟิลด์ "ทั่วไป" ที่แตกต่างกันเช่น int1, int2, str1, str2 และกำหนดว่า str1 สำหรับประเภทแอปคือ "file_name" ในขณะที่ประเภทอื่นอาจเป็น "สถานที่"

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

ฉันไม่แน่ใจเกี่ยวกับการสนับสนุนของ MongoDB บนทางรถไฟ ฉันใช้มันใน Python และ JavaScript

แก้ไข: เพิ่มความคิดเห็นเกี่ยวกับเวลาเมื่อเข้าถึงสองตารางและอีกตัวเลือก MySQL

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

เหตุผลที่ดีอย่างหนึ่งในการเลือกใช้ MongoDB ในกรณีของคุณคือข้อมูลของคุณ ดังที่คุณได้กล่าวไว้คุณจะมีรายการหลายประเภทสำหรับคอลเลกชันของคุณ: แผนที่วิดีโอและอื่น ๆ หากคุณจะใช้สิ่งนี้โดยใช้ RDBMS คุณมี 3 วิธี:

• table-per-type: แต่ละตารางมีคอลัมน์เฉพาะสำหรับแต่ละประเภทของวัตถุ

  ข้อเสีย : ไม่มีข้อความค้นหาเพื่อค้นหาข้อมูลทุกประเภท

  ข้อดี : การออกแบบ OO ที่ดีง่ายต่อการรักษา

• ตารางเดียว: ตารางขนาดใหญ่หนึ่งตารางที่มีแอตทริบิวต์ที่เป็นไปได้ทั้งหมดสำหรับทุกประเภทโดยส่วนใหญ่เป็นค่า null สำหรับรายการเฉพาะ

  ข้อเสีย : เปลี่ยนเป็นวัตถุใด ๆ จะต้องแก้ไขตารางเจ็บปวดเมื่อตารางกลายเป็นใหญ่ บำรุงรักษายาก

  ข้อดี : ใช้งานง่าย

• ตารางหลักที่มีข้อมูลเมตา: คุณมีตารางเดียวที่มีแอตทริบิวต์หลักพูดชื่อวันที่และตารางข้อมูลเมตาที่มีคู่ค่าคีย์สำหรับแอตทริบิวต์เพิ่มเติม

  ข้อเสีย : สองแบบสอบถามเพื่อรับข้อมูลทั้งหมดสำหรับวัตถุเดียว

  ข้อดี : มีความยืดหยุ่นสูงไม่ยากที่จะนำไปใช้

ก่อนหน้านี้ฉันเคยใช้วิธีการเหล่านี้มาก่อนและฉันสามารถบอกได้ว่าไม่มีใครทำงานได้อย่างเป็นธรรมชาติกับ Mongo ข้อมูลของคุณอาจมีลักษณะดังนี้:

{_id:"collection1",
 name:"My first Collection",
 owner: "user123243342",
 entries: [
    {type:"video",
     url: "http://www.youtube.com/234324",
     tags: ["roadtrip", "fun", "camera"]
     },
    {type:"map",
     coordinates: [LOC: [38, –102], LOC: [43, –33], LOC: [228, –102]],
     description: "Road trip to nowhere",
 ]
}

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

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

แก้ไข

เพื่อตอบคำถามเฉพาะของคุณเกี่ยวกับการใช้ MySQL และเก็บแอตทริบิวต์ในเขตข้อมูลเดียวกันโดยใช้ "|" อย่าทำอย่างนี้ วิธีการนี้จะทำให้คุณมีปัญหามากกว่าที่จะแก้ปัญหา ก่อนอื่นคุณจะไม่สามารถสืบค้นคุณสมบัติแต่ละรายการโดยใช้ MySql ประการที่สองมันเพิ่มความซับซ้อนให้กับชั้นการเข้าถึงข้อมูลของคุณมากเกินไป ใช้วิธีพิมพ์ต่อตารางหรือเมตาดาต้าแทน หากคุณเคยทำงานกับ WordPress มาก่อนจะใช้วิธี meta-data:

• ตารางผู้ใช้ + usemeta สำหรับผู้ใช้
• โพสต์ตาราง + โพสต์ postmeta ตาราง

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

บทความด้านล่างให้ผลลัพธ์ที่ดีเมื่อเปรียบเทียบกับ MySQL และ MongoDB ในแง่ของการเลือกดึงและแทรกพิจารณาปริมาณข้อมูลในฐานข้อมูลและปริมาณข้อมูลที่ดึงมา ผลลัพธ์แสดงให้เห็นถึงความสมบูรณ์แบบที่ยอดเยี่ยมสำหรับ MongoDB เกี่ยวกับ "ส่วนแทรก" แต่กรณีอื่น ๆ MySQL ชนะ ดูด้านล่าง:

http://www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/

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