ฉันเพิ่งค้นพบสิ่งนั้น (พวกเขาบอกว่าเนื่องจากการเปลี่ยนแปลงใบอนุญาต) สิ่งนี้ทำให้ฉันคิดเพราะในช่วงไม่กี่ปีที่ผ่านมา ฉันได้เห็นบทความมากมายเกี่ยวกับความแย่ของ MongoDB และวิธีที่ไม่มีใครควรใช้มัน แต่ในช่วงเวลานี้ MongoDB ได้กลายเป็นผลิตภัณฑ์ที่เป็นผู้ใหญ่มากขึ้น เกิดอะไรขึ้น ความเกลียดชังทั้งหมดเกิดจากความผิดพลาดในการทำการตลาดในช่วงแรกของ DBMS ใหม่หรือไม่? หรือผู้คนใช้ MongoDB ผิดที่?
หากคุณรู้สึกว่าฉันกำลังปกป้อง MongoDB โปรดอ่าน ในตอนท้ายของบทความ
เทรนด์ใหม่
ฉันทำงานในอุตสาหกรรมซอฟต์แวร์มาหลายปีเกินกว่าจะพูดได้ แต่ฉันยังคงได้สัมผัสกับแนวโน้มเพียงเล็กน้อยที่เข้ามาในอุตสาหกรรมของเรา ฉันได้เห็นการเพิ่มขึ้นของ 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... รายการไม่มีที่สิ้นสุด ทุกปีมีแนวโน้มใหม่ปรากฏขึ้น บางตัวก็หายไปอย่างรวดเร็ว ในขณะที่บางตัวก็เปลี่ยนวิธีการพัฒนาซอฟต์แวร์โดยพื้นฐาน
เทรนด์ใหม่ๆ ทุกเทรนด์สร้างความตื่นเต้นโดยทั่วไป ผู้คนอาจกระโดดขึ้นไปบนเรือ หรือเห็นเสียงรบกวนที่ผู้อื่นสร้างขึ้นและติดตามฝูงชน กระบวนการนี้ได้รับการประมวลผลโดย Gartner ใน . แม้ว่าจะเป็นเรื่องที่ถกเถียงกัน แต่ไทม์ไลน์นี้อธิบายคร่าวๆ ว่าเกิดอะไรขึ้นกับเทคโนโลยีก่อนที่จะมีประโยชน์ในที่สุด
แต่ในบางครั้ง นวัตกรรมใหม่ก็ปรากฏขึ้น (หรือมีการมาครั้งที่สอง ในกรณีนี้) ซึ่งขับเคลื่อนโดยการดำเนินการเฉพาะเจาะจงเพียงครั้งเดียว ในกรณีของ NoSQL กระแสความนิยมได้รับแรงผลักดันอย่างมากจากการเกิดขึ้นและการเพิ่มขึ้นของ MongoDB MongoDB ไม่ได้เริ่มเทรนด์นี้: ในความเป็นจริงแล้ว บริษัทอินเทอร์เน็ตขนาดใหญ่เริ่มมีปัญหาในการประมวลผลข้อมูลจำนวนมาก ซึ่งนำไปสู่การส่งคืนฐานข้อมูลที่ไม่เกี่ยวข้อง ความเคลื่อนไหวโดยรวมเริ่มต้นจากโปรเจ็กต์ต่างๆ เช่น Bigtable ของ Google และ Cassandra ของ Facebook แต่เป็น MongoDB ที่กลายเป็นการใช้งานฐานข้อมูล NoSQL ที่เป็นที่รู้จักและเข้าถึงได้มากที่สุดที่นักพัฒนาส่วนใหญ่สามารถเข้าถึงได้
หมายเหตุ: คุณอาจคิดว่าฉันกำลังสร้างความสับสนให้กับฐานข้อมูลเอกสารกับฐานข้อมูลแบบเรียงเป็นแนว การจัดเก็บคีย์/ค่า หรือที่เก็บข้อมูลประเภทอื่นๆ มากมายที่อยู่ภายใต้คำจำกัดความ NoSQL ทั่วไป และคุณพูดถูก แต่ในขณะนั้นความวุ่นวายก็ครอบงำ ทุกคนหมกมุ่นอยู่กับ NoSQL แต่กลายมาเป็นทุกคนแล้ว อย่างแน่นอน จำเป็นแม้ว่าหลายคนจะไม่เห็นความแตกต่างในเทคโนโลยีที่แตกต่างกันก็ตาม สำหรับหลาย ๆ คน MongoDB ได้กลายเป็น ตรงกันกับ NoSQL.
และนักพัฒนาก็ตะครุบมัน แนวคิดของฐานข้อมูลแบบไม่มีสคีมาที่ปรับขนาดอย่างน่าอัศจรรย์เพื่อแก้ไขปัญหาใด ๆ เป็นเรื่องที่น่าดึงดูดทีเดียว ประมาณปี 2014 ดูเหมือนว่าทุกที่ในปีที่แล้วที่ใช้ฐานข้อมูลเชิงสัมพันธ์ เช่น MySQL, Postgres หรือ SQL Server เริ่มปรับใช้ฐานข้อมูล MongoDB เมื่อถามว่าทำไม คุณจะได้รับคำตอบจากคำถามเดิมๆ “นี่คือขนาดของเว็บ” ไปจนถึงคำตอบที่รอบคอบกว่า “ข้อมูลของฉันมีโครงสร้างที่หลวมมากและเข้ากับฐานข้อมูลโดยไม่มีสคีมา”
สิ่งสำคัญคือต้องจำไว้ว่า MongoDB และฐานข้อมูลเอกสารโดยทั่วไป สามารถแก้ปัญหาหลายประการเกี่ยวกับฐานข้อมูลเชิงสัมพันธ์แบบดั้งเดิม:
- โครงการที่เข้มงวด: ด้วยฐานข้อมูลเชิงสัมพันธ์ หากคุณมีข้อมูลที่สร้างขึ้นแบบไดนามิก คุณจะถูกบังคับให้สร้างคอลัมน์ข้อมูล "เบ็ดเตล็ด" แบบสุ่มจำนวนหนึ่ง ยัดข้อมูลลงในนั้น หรือใช้การกำหนดค่า ...ทั้งหมดนี้ก็มีข้อเสียอย่างมาก
- ปรับขนาดความยากลำบาก: หากมีข้อมูลจำนวนมากจนไม่พอดีกับเซิร์ฟเวอร์เดียว MongoDB ก็เสนอกลไกเพื่อให้สามารถปรับขนาดข้ามเครื่องหลายเครื่องได้
- การปรับเปลี่ยนวงจรที่ซับซ้อน: ไม่มีการโยกย้าย! ในฐานข้อมูลเชิงสัมพันธ์ การเปลี่ยนแปลงโครงสร้างฐานข้อมูลอาจเป็นปัญหาใหญ่ (โดยเฉพาะเมื่อมีข้อมูลจำนวนมาก) MongoDB สามารถลดความซับซ้อนของกระบวนการได้อย่างมาก และมันทำให้มันง่ายมากจนคุณสามารถอัพเดตวงจรในขณะที่คุณไปและเดินหน้าต่อไปได้อย่างรวดเร็ว
- ประสิทธิภาพการบันทึก: ประสิทธิภาพ MongoDB ดี โดยเฉพาะอย่างยิ่งเมื่อกำหนดค่าอย่างเหมาะสม แม้แต่การกำหนดค่านอกกรอบของ MongoDB ซึ่งมักถูกวิพากษ์วิจารณ์ก็แสดงตัวเลขประสิทธิภาพที่น่าประทับใจ
ความเสี่ยงทั้งหมดอยู่ที่คุณ
ประโยชน์ที่เป็นไปได้ของ MongoDB นั้นมหาศาล โดยเฉพาะอย่างยิ่งสำหรับปัญหาบางประเภท หากคุณอ่านรายการด้านบนโดยไม่เข้าใจบริบทและไม่มีประสบการณ์ คุณอาจรู้สึกว่า MongoDB เป็น DBMS ที่ปฏิวัติวงการอย่างแท้จริง ปัญหาเดียวคือสิทธิประโยชน์ที่ระบุไว้ข้างต้นมาพร้อมกับข้อควรระวังหลายประการ ซึ่งบางรายการระบุไว้ด้านล่าง
พูดตามตรง ไม่มีใครอยู่ที่ 10gen/MongoDB Inc. จะไม่บอกว่าสิ่งต่อไปนี้ไม่เป็นความจริง สิ่งเหล่านี้เป็นเพียงการประนีประนอมเท่านั้น
- การทำธุรกรรมที่สูญหาย: ธุรกรรมเป็นคุณสมบัติหลักของฐานข้อมูลเชิงสัมพันธ์จำนวนมาก (ไม่ใช่ทั้งหมด แต่เป็นส่วนใหญ่) การทำธุรกรรมหมายความว่าคุณสามารถดำเนินการหลายอย่างแบบอะตอมมิก และมั่นใจได้ว่าข้อมูลจะมีความสอดคล้องกัน แน่นอนว่าด้วยฐานข้อมูล NoSQL ความสามารถในการทำธุรกรรมสามารถอยู่ภายในเอกสารเดียว หรือคุณสามารถใช้การคอมมิตแบบสองเฟสเพื่อรับความหมายเชิงธุรกรรมได้ แต่คุณจะต้องใช้ฟังก์ชันนี้ด้วยตัวเอง... ซึ่งอาจเป็นเรื่องยากและใช้เวลานาน บ่อยครั้งที่คุณไม่ทราบว่ามีปัญหาเกิดขึ้นจนกว่าคุณจะเห็นว่าข้อมูลในฐานข้อมูลอยู่ในสถานะที่ไม่ถูกต้อง เนื่องจากไม่สามารถรับประกันความเป็นอะตอมมิกของการดำเนินการได้ หมายเหตุ: หลายคนบอกฉันว่า MongoDB 4.0 เปิดตัวธุรกรรมเมื่อปีที่แล้ว แต่มีข้อจำกัดบางประการ ประเด็นจากบทความยังคงเหมือนเดิม: ประเมินว่าเทคโนโลยีตรงกับความต้องการของคุณได้ดีเพียงใด
- การสูญเสียความสมบูรณ์เชิงสัมพันธ์ (คีย์ต่างประเทศ): หากข้อมูลของคุณมีความสัมพันธ์ คุณจะต้องนำไปใช้ในแอปพลิเคชัน การมีฐานข้อมูลที่เคารพความสัมพันธ์เหล่านี้จะช่วยลดภาระงานของแอปพลิเคชันและโปรแกรมเมอร์ของคุณด้วย
- ขาดความสามารถในการใช้โครงสร้างข้อมูล: สคีมาที่เข้มงวดบางครั้งอาจเป็นปัญหาใหญ่ได้ แต่ก็เป็นกลไกที่ทรงพลังสำหรับการจัดโครงสร้างข้อมูลที่ดีหากใช้อย่างชาญฉลาด ฐานข้อมูลเอกสารเช่น MongoDB ให้ความยืดหยุ่นของสคีมาอย่างไม่น่าเชื่อ แต่ความยืดหยุ่นนี้ขจัดความรับผิดชอบในการรักษาข้อมูลให้สะอาด หากคุณไม่ดูแลพวกเขา คุณจะต้องเขียนโค้ดจำนวนมากในแอปพลิเคชันของคุณเพื่อชดเชยข้อมูลที่ไม่ได้รับการจัดเก็บในรูปแบบที่คุณคาดหวัง ดังที่เรามักพูดกันที่บริษัทของเรา Simple Thread... สักวันหนึ่งแอปพลิเคชันจะถูกเขียนใหม่ แต่ข้อมูลจะคงอยู่ตลอดไป หมายเหตุ: MongoDB รองรับการตรวจสอบสคีมา: มีประโยชน์ แต่ไม่ได้รับประกันเช่นเดียวกับในฐานข้อมูลเชิงสัมพันธ์ ประการแรก การเพิ่มหรือการเปลี่ยนแปลงการตรวจสอบสคีมาจะไม่ส่งผลต่อข้อมูลที่มีอยู่ในคอลเลกชัน ขึ้นอยู่กับคุณเพื่อให้แน่ใจว่าคุณจะอัปเดตข้อมูลตามสคีมาใหม่ ตัดสินใจด้วยตัวเองว่าสิ่งนี้เพียงพอสำหรับความต้องการของคุณหรือไม่
- ภาษาการสืบค้นดั้งเดิม / การสูญเสียระบบนิเวศของเครื่องมือ: การถือกำเนิดของ SQL เป็นการปฏิวัติที่สมบูรณ์และไม่มีอะไรเปลี่ยนแปลงตั้งแต่นั้นมา มันเป็นภาษาที่ทรงพลังอย่างเหลือเชื่อ แต่ก็ค่อนข้างซับซ้อนด้วย ความจำเป็นในการสร้างการสืบค้นฐานข้อมูลในภาษาใหม่ซึ่งประกอบด้วยแฟรกเมนต์ JSON ถือเป็นก้าวถอยหลังครั้งใหญ่ของผู้ที่มีประสบการณ์ทำงานกับ SQL มีเครื่องมือมากมายที่โต้ตอบกับฐานข้อมูล SQL ตั้งแต่ IDE ไปจนถึงเครื่องมือการรายงาน การย้ายไปยังฐานข้อมูลที่ไม่รองรับ SQL หมายความว่าคุณไม่สามารถใช้เครื่องมือเหล่านี้ส่วนใหญ่ได้ หรือคุณต้องแปลข้อมูลเป็น SQL เพื่อใช้งาน ซึ่งอาจยากกว่าที่คุณคิด
นักพัฒนาหลายคนที่หันมาใช้ MongoDB ไม่เข้าใจถึงข้อดีข้อเสียเหล่านี้จริงๆ และมักจะมุ่งความสนใจไปที่การติดตั้งมันเป็นที่เก็บข้อมูลหลักเป็นอันดับแรก หลังจากนี้การกลับมาเป็นเรื่องยากอย่างไม่น่าเชื่อ
สิ่งที่สามารถทำได้แตกต่างออกไป?
ไม่ใช่ทุกคนที่กระโดดหัวแล้วกระแทกก้นพื้น แต่หลายโครงการได้ติดตั้ง MongoDB ในตำแหน่งที่ไม่พอดี และพวกเขาจะต้องอยู่กับมันไปอีกหลายปี หากองค์กรเหล่านี้ใช้เวลาและคิดอย่างเป็นระบบเกี่ยวกับตัวเลือกเทคโนโลยีของตน หลายๆ องค์กรคงมีตัวเลือกที่แตกต่างกันไป
วิธีการเลือกเทคโนโลยีที่เหมาะสม? มีความพยายามหลายครั้งในการสร้างกรอบการประเมินเทคโนโลยีที่เป็นระบบ เช่น и แต่สำหรับฉันแล้วดูเหมือนว่านี่เป็นความซับซ้อนที่ไม่จำเป็น
เทคโนโลยีหลายอย่างสามารถประเมินได้อย่างชาญฉลาดโดยการถามคำถามพื้นฐานเพียงสองข้อ ปัญหาคือการหาคนที่สามารถตอบคำถามได้อย่างมีความรับผิดชอบ ใช้เวลาในการหาคำตอบและไม่มีอคติ
หากคุณไม่พบปัญหาใดๆ คุณไม่จำเป็นต้องใช้เครื่องมือใหม่ จุด
คำถามที่ 1: ฉันกำลังพยายามแก้ไขปัญหาอะไร
หากคุณไม่พบปัญหาใดๆ คุณไม่จำเป็นต้องใช้เครื่องมือใหม่ จุด ไม่จำเป็นต้องมองหาวิธีแก้ปัญหาแล้วสร้างปัญหาขึ้นมา เว้นแต่ว่าคุณจะพบปัญหาที่เทคโนโลยีใหม่แก้ไขได้ดีกว่าเทคโนโลยีที่มีอยู่ของคุณอย่างมาก ไม่มีอะไรจะพูดคุยที่นี่ หากคุณกำลังพิจารณาที่จะใช้เทคโนโลยีนี้เพราะคุณเคยเห็นคนอื่นใช้ ลองคิดถึงปัญหาที่พวกเขาเผชิญ และถามว่าคุณมีปัญหาเหล่านั้นหรือไม่ เป็นเรื่องง่ายที่จะยอมรับเทคโนโลยีเพราะมีผู้อื่นใช้งานอยู่ ความท้าทายคือการทำความเข้าใจว่าคุณประสบปัญหาเดียวกันหรือไม่
คำถามที่ 2: ฉันพลาดอะไรไป?
นี่เป็นคำถามที่ยากกว่าอย่างแน่นอนเพราะคุณจะต้องเจาะลึกและมีความเข้าใจที่ดีเกี่ยวกับเทคโนโลยีทั้งเก่าและใหม่ บางครั้งคุณไม่สามารถเข้าใจสิ่งใหม่ได้จนกว่าคุณจะสร้างบางสิ่งด้วยมันหรือมีคนที่มีประสบการณ์เช่นนั้น
หากคุณไม่มีทั้งสองอย่าง ก็ควรคำนึงถึงการลงทุนขั้นต่ำที่เป็นไปได้เพื่อกำหนดมูลค่าของตราสารนี้ และเมื่อคุณลงทุนไปแล้ว การกลับคำตัดสินจะยากแค่ไหน?
ผู้คนมักทำลายทุกสิ่งทุกอย่าง
เมื่อคุณพยายามตอบคำถามเหล่านี้อย่างเป็นกลางที่สุดเท่าที่จะเป็นไปได้ โปรดจำไว้อย่างหนึ่ง: คุณจะต้องต่อสู้กับธรรมชาติของมนุษย์ มีอคติด้านความรู้ความเข้าใจหลายประการที่ต้องเอาชนะเพื่อประเมินเทคโนโลยีอย่างมีประสิทธิภาพ นี่เป็นเพียงไม่กี่:
- - ทุกคนรู้เกี่ยวกับเขา แต่ก็ยังยากที่จะต่อสู้กับเขา เพียงตรวจสอบให้แน่ใจว่าเทคโนโลยีตรงกับความต้องการที่แท้จริงของคุณ
- — นักพัฒนาจำนวนมากมักจะดูถูกดูแคลนเทคโนโลยีที่พวกเขาร่วมงานด้วยมาเป็นเวลานาน และประเมินคุณประโยชน์ของเทคโนโลยีใหม่สูงเกินไป ไม่ใช่แค่โปรแกรมเมอร์เท่านั้น ทุกคนมีความเสี่ยงต่ออคติทางการรับรู้นี้
- - เรามักจะมองเห็นสิ่งที่มีอยู่และมองข้ามสิ่งที่ขาดไป สิ่งนี้สามารถนำไปสู่ความสับสนวุ่นวายเมื่อรวมกับเอฟเฟกต์แปลกใหม่ เนื่องจากคุณไม่เพียงแต่ให้คุณค่ากับเทคโนโลยีใหม่ ๆ มากเกินไป แต่ยังเพิกเฉยต่อข้อบกพร่องของมันด้วย.
การประเมินตามวัตถุประสงค์ไม่ใช่เรื่องง่าย แต่การทำความเข้าใจอคติทางความคิดที่ซ่อนอยู่จะช่วยให้คุณตัดสินใจได้อย่างมีเหตุผลมากขึ้น
สรุป
เมื่อใดก็ตามที่มีนวัตกรรมปรากฏขึ้น จะต้องตอบคำถามสองข้ออย่างระมัดระวัง:
- เครื่องมือนี้แก้ปัญหาได้จริงหรือไม่?
- เราเข้าใจการแลกเปลี่ยนดีหรือไม่?
หากคุณไม่สามารถตอบคำถามสองข้อนี้ได้อย่างมั่นใจ ให้ย้อนกลับไปคิดสักสองสามก้าว
MongoDB เป็นตัวเลือกที่ถูกต้องหรือเปล่า? แน่นอนใช่; เช่นเดียวกับเทคโนโลยีทางวิศวกรรมส่วนใหญ่ ขึ้นอยู่กับหลายปัจจัย ในบรรดาผู้ที่ตอบคำถามสองข้อนี้ หลายคนได้รับประโยชน์จาก MongoDB และยังคงทำเช่นนั้นต่อไป สำหรับผู้ที่ไม่ได้ทำ ฉันหวังว่าคุณจะได้เรียนรู้บทเรียนที่มีคุณค่าและไม่เจ็บปวดเกินไปเกี่ยวกับการก้าวผ่านวงจรกระแสเกินจริง
ข้อจำกัดความรับผิดชอบ
ฉันต้องการชี้แจงว่าฉันไม่มีทั้งความรักและความเกลียดชังกับ MongoDB เราแค่ไม่มีปัญหาประเภทที่ MongoDB เหมาะสมที่สุดในการแก้ไข ฉันรู้ว่า 10gen/MongoDB Inc. ในตอนแรกมีความกล้าหาญมาก โดยตั้งค่าเริ่มต้นที่ไม่ปลอดภัยและส่งเสริม MongoDB ทุกที่ (โดยเฉพาะที่ Hackathons) เพื่อเป็นโซลูชันสากลสำหรับการทำงานกับข้อมูลใดๆ มันอาจเป็นการตัดสินใจที่ไม่ดี แต่เป็นการยืนยันแนวทางที่อธิบายไว้ที่นี่: ปัญหาเหล่านี้สามารถตรวจพบได้อย่างรวดเร็วแม้จะมีการประเมินเทคโนโลยีอย่างผิวเผินก็ตาม
ที่มา: will.com