ข้อดีของการใช้ฐานข้อมูลแบบไม่มีสคีมาเช่น MongoDB เมื่อเทียบกับฐานข้อมูลเชิงสัมพันธ์คืออะไร?

ฉันคุ้นเคยกับการใช้ฐานข้อมูลเชิงสัมพันธ์เช่น MySQL หรือ PostgreSQL และรวมกับเฟรมเวิร์ก MVC เช่น Symfony, RoR หรือ Django และฉันคิดว่ามันใช้งานได้ดี

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

ฐานข้อมูลแบบโอเพ่นซอร์สที่ปรับขนาดได้ประสิทธิภาพสูงไม่ต้องใช้สคีมา

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

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

หากคุณมีคำแนะนำในการจัดทำเอกสารและ / หรือตัวอย่างก็จะช่วยได้มากเช่นกัน

นี่คือข้อดีบางประการของ MongoDB สำหรับการสร้างเว็บแอปพลิเคชัน:

1. แบบจำลองข้อมูลตามเอกสาร หน่วยจัดเก็บข้อมูลพื้นฐานนั้นคล้ายคลึงกับ JSON พจนานุกรม Python แฮช Ruby เป็นต้นซึ่งเป็นโครงสร้างข้อมูลที่สมบูรณ์ซึ่งสามารถเก็บอาร์เรย์และเอกสารอื่น ๆ ได้ ซึ่งหมายความว่าคุณสามารถแสดงโครงสร้างในเอนทิตีเดียวในโครงสร้างที่ต้องใช้หลายตารางเพื่อแสดงอย่างถูกต้องในฐานข้อมูลเชิงสัมพันธ์ สิ่งนี้มีประโยชน์อย่างยิ่งหากข้อมูลของคุณไม่เปลี่ยนรูป
2. ความสามารถในการสืบค้นลึก MongoDB รองรับการสืบค้นแบบไดนามิกบนเอกสารโดยใช้ภาษาคิวรีแบบเอกสารที่มีประสิทธิภาพเกือบเท่ากับ SQL
3. ไม่มีการโยกย้ายสคีมา เนื่องจาก MongoDB ไม่มีสคีมาโค้ดของคุณจึงกำหนดสคีมาของคุณ
4. เส้นทางที่ชัดเจนในการปรับขนาดในแนวนอน

คุณจะต้องอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้และเล่นกับมันเพื่อให้ได้แนวคิดที่ดีขึ้น นี่คือการสาธิตออนไลน์:

http://try.mongodb.org/

มีข้อดีมากมาย

ตัวอย่างเช่นสคีมาฐานข้อมูลของคุณจะปรับขนาดได้มากขึ้นคุณไม่ต้องกังวลเกี่ยวกับการโยกย้ายโค้ดจะน่าเขียนขึ้น ... ตัวอย่างเช่นนี่คือหนึ่งในรหัสโมเดลของฉัน:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

การเพิ่มคีย์ก็แค่เพิ่มโค้ด!

นอกจากนี้ยังมีข้อดีอื่น ๆ ที่จะปรากฏในระยะยาวเช่นความสามารถในการขยายตัวและความเร็วที่ดีขึ้น

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

หากต้องการอ่านข้อมูลเพิ่มเติมฉันขอแนะนำให้ดูที่ " ทำไมฉันคิดว่า Mongo คือฐานข้อมูลที่ Rails เป็น Frameworks " หรือโพสต์นี้บนเว็บไซต์ mongodb เพื่อความตื่นเต้นและถ้าคุณพูดภาษาฝรั่งเศสได้โปรดอ่านบทความนี้เพื่ออธิบายวิธีตั้งค่า MongoDB ตั้งแต่เริ่มต้น

แก้ไข: ฉันเกือบลืมบอกคุณเกี่ยวกับrailscast นี้โดยไรอัน มันน่าสนใจมากและทำให้คุณอยากเริ่มทันที!

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

นอกจากนี้ยังหมายความว่าสิ่งที่คุณทิ้งลงไปจะยังคงไร้ความหมายโดยสิ้นเชิงหลังจากที่คุณทำเช่นนั้น

บางคนจะติดป้ายว่าเป็นข้อเสียเปรียบบางคนไม่ยอม

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

หากไม่มีสคีมาที่ได้รับการยอมรับอย่างดีไม่มีเพรดิเคตแบบขยายและไม่มีพรีซิเคตแบบขยายไม่มีทางที่ผู้ใช้จะสร้างความหมายใด ๆ จากสิ่งที่ถูกยัดไว้ในนั้น

MongoDB ให้ความสำคัญกับ FLOSS Weekly ในสัปดาห์นี้ - http://twit.tv/floss105 ฐานข้อมูลที่ใช้แนวคิดคล้ายกันคือ CouchDB ซึ่งนำเสนอใน FLOSS Weekly อื่น: http://twit.tv/floss36

ฉันคิดว่ามันคุ้มค่าที่จะฟังสิ่งเหล่านี้นอกเหนือจากลิงก์ที่ @marcgg ให้ไว้

ประสบการณ์ของฉันกับ Postgres และ Mongo หลังจากทำงานกับทั้งฐานข้อมูลในโครงการของฉัน

Postgres (RDBMS)

ขอแนะนำให้ใช้ Postgres หากแอปพลิเคชันในอนาคตของคุณมีสคีมาที่ซับซ้อนซึ่งต้องการการรวมจำนวนมากหรือข้อมูลทั้งหมดมีความสัมพันธ์หรือหากเรามีการเขียนจำนวนมาก Postgres เป็นโอเพ่นซอร์สที่เร็วกว่าสอดคล้องกับ ACID และใช้หน่วยความจำบนดิสก์น้อยลงและมีประสิทธิภาพที่ดีสำหรับการจัดเก็บ JSON และรวมถึงความสามารถในการทำธุรกรรมแบบอนุกรมเต็มรูปแบบด้วยการแยกธุรกรรม 3 ระดับ

ข้อดีที่สุดของการอยู่กับ Postgres คือเรามีสิ่งที่ดีที่สุดจากทั้งสองโลก เราสามารถจัดเก็บข้อมูลลงใน JSONB โดยมีข้อ จำกัด ความสอดคล้องและความเร็ว ในทางกลับกันเราสามารถใช้คุณสมบัติ SQL ทั้งหมดสำหรับข้อมูลประเภทอื่น ๆ เอ็นจิ้นพื้นฐานมีความเสถียรมากและทำงานได้ดีกับปริมาณข้อมูลที่หลากหลาย นอกจากนี้ยังทำงานบนฮาร์ดแวร์และระบบปฏิบัติการที่คุณเลือก Postgres ให้ความสามารถ NoSQL พร้อมกับการรองรับธุรกรรมเต็มรูปแบบการจัดเก็บเอกสาร JSON โดยมีข้อ จำกัด เกี่ยวกับข้อมูลฟิลด์

ข้อ จำกัด ทั่วไปสำหรับ Postgres

การปรับขนาด Postgres ในแนวนอนนั้นยากกว่ามาก แต่ทำได้

การดำเนินการอ่านอย่างรวดเร็วไม่สามารถทำได้อย่างสมบูรณ์กับ Postgres

ไม่มีฐานข้อมูล SQL

Mongo DB (เสือมีสาย)

MongoDB อาจเอาชนะ Postgres ในมิติของ "สเกลแนวนอน" การจัดเก็บ JSON เป็นสิ่งที่ Mongo ได้รับการปรับให้เหมาะสม Mongo จัดเก็บข้อมูลในรูปแบบไบนารีที่เรียกว่า BSONb ซึ่ง (โดยประมาณ) เป็นเพียงการแทนค่าไบนารีของส่วนเหนือของ JSON MongoDB จัดเก็บวัตถุตรงตามที่ออกแบบไว้ จากข้อมูลของ MongoDB สำหรับแอปพลิเคชันที่เน้นการเขียน Mongo กล่าวว่าเอ็นจิ้นใหม่ (Wired Tiger) ช่วยให้ผู้ใช้มีประสิทธิภาพในการเขียนเพิ่มขึ้นถึง 10 เท่า (ฉันควรลองสิ่งนี้) โดยลดการใช้พื้นที่จัดเก็บลง 80 เปอร์เซ็นต์ช่วยลดต้นทุนในการจัดเก็บ บรรลุการใช้ประโยชน์จากฮาร์ดแวร์มากขึ้น

ข้อ จำกัด ทั่วไปของ MongoDb

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

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

ทุกอย่างเกี่ยวกับการแลกเปลี่ยน MongoDB เร็ว แต่ไม่ใช่ ACID ไม่มีธุรกรรม มันดีกว่า MySQL ในบางกรณีการใช้งานและแย่กว่าในบางกรณี

สายร้องที่เขียนใน MongoDB: The Definitive Guide

มีเหตุผลที่ดีหลายประการ:

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

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

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