เมื่อใดที่เราควรใช้ MongoDB

MongoDB เป็นฐานข้อมูล NoSQL ที่ฉันพบว่าใช้ง่าย เมื่อเร็ว ๆ นี้ฉันต้องพัฒนาแอพพลิเคชั่นที่ต้องการรวบรวมข้อมูลโดยใช้คำร้องขอ HTTP และเก็บผลลัพธ์บางอย่างหลังจากประมวลผลข้อมูลและฉันพยายามใช้ MongoDB

จากประสบการณ์นี้ฉันพบว่ามันดีกว่าการใช้มากกว่าฐานข้อมูลเชิงสัมพันธ์แบบดั้งเดิมและเนื่องจากฉันเป็นนักพัฒนาไม่ใช่ DBA งานของฉันจึงง่ายขึ้นมาก

ถึงกระนั้นบางครั้งฉันก็ไม่แน่ใจว่าเมื่อไหร่ที่ฉันควรใช้ MongoDB แทนที่จะเป็นฐานข้อมูลเชิงสัมพันธ์แบบดั้งเดิมเช่น SQL Server หรือ MySQL

ในกรณีนี้เมื่อเราสามารถใช้ MongoDB แทนฐานข้อมูลเชิงสัมพันธ์ มีบาง trully ใหญ่ข้อแม้เกี่ยวกับ MongoDB ที่ทำให้มันไม่เหมาะสมสำหรับสถานการณ์บางอย่าง?

โดยทั่วไป:

• หากคุณสามารถแสดงข้อมูลของคุณในรูปแบบของเอกสาร MongoDB อาจเป็นทางเลือกที่ดี

• หากคุณต้องการจินตนาการว่าข้อมูลของคุณเป็นกลุ่มของตารางที่เชื่อมต่อกัน MongoDB อาจไม่ใช่ทางเลือกที่ดี

นี่คือสองตัวอย่างที่ฉันพบตัวอย่าง:

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

  สิ่งนี้สามารถจัดเก็บเป็นกลุ่มของตาราง แต่เมื่อพยายามสร้างแบบจำลองมันจะเติบโตอย่างรวดเร็วมากถึงหนึ่งโหลของตารางหากไม่มาก ข้อความค้นหา SQL บางรายการอาจดูน่าเกลียดมากjoinและ ... คุณก็เห็นภาพได้

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

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

  ด้วยวิธีการใช้เอกสารเป็นเรื่องยากที่จะค้นหาสิ่งที่จะเป็นเอกสาร ผู้ใช้อาจจะ? นั่นเป็นการเริ่มต้นที่ดี เอกสารผู้ใช้จะมีทุกสิ่งที่ผู้ใช้นี้เขียน แต่สิ่งที่เธอแบ่งปัน

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

  ทางเลือกอื่นคือเก็บไว้ในเอกสารผู้ใช้เพียงแค่รายการของผู้ใช้รายนี้ที่แชร์ (ด้วย ID ของผู้ใช้และรายการที่อ้างอิง) แต่ตอนนี้ปัญหาที่แตกต่างจะเกิดขึ้น: หากผู้ใช้แชร์รายการนับพันจากผู้ใช้นับพันคนมันจะต้องเปิดเอกสารหลายพันรายการเพื่อรับรายการเหล่านั้น

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

  ทีนี้คุณจะต้องการโต๊ะมากแค่ไหนถ้าคุณใช้ฐานข้อมูลเชิงสัมพันธ์? ใช่สาม มันจะตรงไปตรงมากับรุ่นและตรงไปตรงมาเพื่อใช้

แต่ละเทคโนโลยีมีข้อดี

ข้อดีของฐานข้อมูลเชิงสัมพันธ์คือ RDBMS ทำบางสิ่งให้คุณเช่น:

• การบังคับใช้ Referential Integrity (ไม่อนุญาตให้มีการแทรกรายละเอียดใบแจ้งหนี้หากไม่มีใบกำกับสินค้าอยู่)
• หลีกเลี่ยงความซ้ำซ้อน: สิ่งต่าง ๆ จะถูกเก็บไว้เพียงครั้งเดียว
• การสืบค้นที่ซับซ้อนสามารถทำได้ด้วยภาษาที่ประกาศได้ (SQL) ซึ่งมีอายุการใช้งานที่พิสูจน์แล้วและแพร่กระจายอย่างกว้างขวาง

สิ่งที่ทำให้คุณต้องเขียนโค้ดน้อยลงเพราะ RDBMS บังคับใช้สิ่งต่าง ๆ ให้คุณ

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

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

สำหรับกรณีของคุณโดยเฉพาะ MongoDB ฟังดูเหมือนเป็นทางเลือกที่ดี แต่มีสถานการณ์มากมาย

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

MongoDB ไม่เหมาะกับสถานการณ์ที่ต้องการ:

1. การรับประกันกรดที่แข็งแกร่ง: MongoDB ช่วยให้สามารถจัดเก็บข้อมูลที่ซ้ำกันการอ่านที่ไม่สอดคล้องและการสูญหายของข้อมูล สิ่งเหล่านี้ใช้ได้ในบางแอปพลิเคชัน แต่ไม่ได้อยู่ในส่วนใหญ่
2. ธุรกรรมหลายวัตถุ: MongoDB รองรับธุรกรรม ACID แต่สำหรับวัตถุ / เอกสารเดียวเท่านั้น สิ่งนี้จะไม่ลดลงสำหรับการดำเนินการที่ซับซ้อนมากขึ้นเช่นการโอนเงินผ่านธนาคารการจอง ฯลฯ
3. Traditional BI: มีเครื่องมือ BI มากมายที่เล่นได้ดีกับ SQL แบบดั้งเดิมเท่านั้น
4. SQL: MongoDB มีภาษาข้อความค้นหาที่เฉพาะเจาะจงมากในขณะที่ SQL เป็นที่รู้จักกันดีโดยผู้คนจำนวนมาก (อาจเป็นสิ่งสำคัญในการพิจารณา) สามารถทำสิ่งที่ซับซ้อนได้หลายอย่าง เข้าร่วม) และสามารถถ่ายโอนข้ามการใช้งานได้มากมาย

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

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

MongoDB นั้นยอดเยี่ยมเมื่อคุณสามารถแสดงข้อมูลของคุณในรูปของ "แพ็คเกจ" อิสระของข้อมูล คุณมีรหัสไปรษณีย์ของ Google Maps ฝังอยู่ในรหัสไปรษณีย์คือ บริษัท และภายใน บริษัท มีพนักงาน รหัสไปรษณีย์ทั้งหมดเป็นอิสระจากกันและคุณสามารถรับข้อมูลทั้งหมดในวิธีที่ง่ายสวยงามและรวดเร็ว นั่นเป็นสถานการณ์ที่ดีสำหรับโซลูชันที่ไม่ใช่ SQL

เมื่อบอกว่าฉันไม่เห็นด้วยกับแนวโน้มปัจจุบันทั้งหมดที่ฉันมองว่า MongoDB เป็นโพสต์และโซลูชั่นที่เหนือกว่าสำหรับ RDBMS และ noSQL ต้องเป็นโซลูชันของคุณโดยค่าเริ่มต้น ทั้งหมดที่ไร้สาระ MongoDB เป็นฐานข้อมูลเฉพาะและ 90% ของโครงการมีความสัมพันธ์กันและต้องการตัวเลือก RDBMS เพราะคุณต้องการโซลูชันการสืบค้นที่ทรงพลังเช่น SQL เพื่อสร้างรายงานของคุณและมองหาการกระจายข้อมูล: "เชื่อมต่อ" เป็นมืออาชีพ นอกจากนี้ RDBMS ที่ทันสมัยยังสนับสนุนการรวบรวม BSON และการรวมเชิงพื้นที่ดังนั้นบางทีช่องสำหรับ noSQL ก็แคบลงในขณะนี้

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

ในบริบทดังกล่าว MongoDB นั้นรวดเร็วและเชื่อถือได้ แต่อย่าลืมว่าคุณไม่มีข้อมูลเชิงสัมพันธ์ในฐานข้อมูลของคุณ ซึ่งหมายความว่าหากคุณเปลี่ยนแปลงบางสิ่งในโครงสร้างของหน้าเว็บคุณอาจไม่สามารถเติมช่องว่างในหน้าเว็บที่เก็บไว้แล้วของคุณได้เพราะคุณไม่มีข้อมูลที่จำเป็นในการทำเช่นนั้น เพิ่มเติมเกี่ยวกับเรื่องนี้ที่นี่: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/