เมื่อใดจึงจะใช้ MongoDB หรือระบบฐานข้อมูลเชิงเอกสารอื่น ๆ [ปิด]

เรานำเสนอแพลตฟอร์มสำหรับวิดีโอและคลิปเสียงภาพถ่ายและ vector-grafics เราเริ่มต้นด้วย MySQL เป็นแบ็กเอนด์ฐานข้อมูลและเมื่อเร็ว ๆ นี้ได้รวมMongoDBสำหรับการจัดเก็บข้อมูลเมตาทั้งหมดของไฟล์เพราะ MongoDB เหมาะกับความต้องการมากขึ้น ตัวอย่างเช่น: ภาพถ่ายอาจมีข้อมูลExifวิดีโออาจมีแทร็กเสียงที่เราต้องการจัดเก็บข้อมูลเมตาของด้วย วิดีโอและกราฟิกแบบเวกเตอร์ไม่แชร์ข้อมูลเมตาทั่วไป ฯลฯ ดังนั้นฉันจึงรู้ว่า MongoDB นั้นสมบูรณ์แบบในการจัดเก็บข้อมูลที่ไม่มีโครงสร้างและเก็บไว้ค้นหาได้

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

ดังนั้นคำถามคือเมื่อใช้ MongoDB และเมื่อใดควรใช้ RDBMS คุณจะเลือกอะไร mongoDB หรือ MySQL ถ้าคุณมีทางเลือกและทำไมคุณถึงเลือกมัน

ในNoSQL: ถ้าเป็นอย่างนั้นง่ายผู้เขียนเขียนเกี่ยวกับ MongoDB:

MongoDB ไม่ใช่ที่เก็บคีย์ / ค่ามันค่อนข้างมากกว่า มันไม่ใช่ RDBMS อย่างแน่นอนเช่นกัน ฉันไม่ได้ใช้ MongoDB ในการผลิต แต่ฉันได้ใช้มันเป็นแอปทดสอบขนาดเล็กและมันก็เป็นชุดที่เยี่ยมมาก ดูเหมือนว่าจะเป็นนักแสดงมากและอาจจะมีหรือจะมีความอดทนต่อความผิดพลาดและการจัดเรียงอัตโนมัติ ฉันคิดว่า Mongo อาจเป็นสิ่งที่ใกล้เคียงที่สุดกับการเปลี่ยน RDBMS ที่ฉันเคยเห็นมาแล้ว มันจะไม่ทำงานสำหรับชุดข้อมูลและรูปแบบการเข้าถึงทั้งหมด แต่สร้างขึ้นสำหรับสิ่ง CRUD ทั่วไปของคุณ การจัดเก็บสิ่งที่เป็นแฮชขนาดใหญ่และสามารถเลือกได้จากกุญแจเหล่านี้คือสิ่งที่คนส่วนใหญ่ใช้ฐานข้อมูลเชิงสัมพันธ์ถ้า DB ของคุณคือ 3NF และคุณไม่ได้เข้าร่วมใด ๆ (คุณเพียงแค่เลือกกลุ่มของตารางและรวมวัตถุทั้งหมดเข้าด้วยกัน AKA ที่คนส่วนใหญ่ทำกันในเว็บแอป) MongoDB อาจจะเตะคุณแทน

จากนั้นในบทสรุป:

สิ่งที่จริงที่จะชี้ให้เห็นก็คือถ้าคุณถูกระงับไม่ให้ทำสิ่งที่ยอดเยี่ยมเพราะคุณไม่สามารถเลือกฐานข้อมูลได้คุณกำลังทำผิด ถ้าคุณรู้จัก mysql ให้ใช้มัน ปรับให้เหมาะสมเมื่อคุณต้องการ ใช้มันเหมือนร้าน ak / v ใช้มันเหมือน rdbms แต่เพื่อประโยชน์ของพระเจ้าสร้างแอพนักฆ่าของคุณ! สิ่งเหล่านี้จะไม่มีผลกับแอพส่วนใหญ่ Facebook ยังคงใช้ MySQL อยู่มาก Wikipedia ใช้ MySQL เป็นจำนวนมาก FriendFeed ใช้ MySQL เป็นจำนวนมาก NoSQL เป็นเครื่องมือที่ยอดเยี่ยม แต่แน่นอนว่ามันจะไม่เป็นข้อได้เปรียบในการแข่งขันของคุณมันจะไม่ทำให้แอปของคุณร้อนแรงและที่สำคัญที่สุดคือผู้ใช้ของคุณจะไม่สนใจสิ่งนี้

ฉันจะสร้างแอปต่อไปของฉันในอะไร อาจ Postgres ฉันจะใช้ NoSQL หรือไม่ อาจจะ. ฉันอาจใช้ Hadoop และ Hive ฉันอาจเก็บทุกอย่างไว้ในไฟล์แบน บางทีฉันอาจเริ่มแฮ็คที่ Maglev ฉันจะใช้สิ่งที่ดีที่สุดสำหรับงาน หากฉันต้องการรายงานฉันจะไม่ใช้ NoSQL ใด ๆ หากฉันต้องการแคชฉันอาจใช้ Tokyo Tyrant หากฉันต้องการ ACIDity ฉันจะไม่ใช้ NoSQL หากฉันต้องการเคาน์เตอร์จำนวนมากฉันจะใช้ Redis หากฉันต้องการธุรกรรมฉันจะใช้ Postgres ถ้าฉันมีเอกสารประเภทเดียวฉันอาจจะใช้ Mongo ถ้าฉันต้องการเขียนวัตถุวันละ 1 พันล้านชิ้นฉันอาจใช้โวลเดอมอร์ หากฉันต้องการค้นหาข้อความแบบเต็มฉันอาจใช้ Solr ถ้าฉันต้องการค้นหาข้อความแบบเต็มของข้อมูลที่ระเหยได้ฉันอาจใช้สฟิงซ์

ฉันชอบบทความนี้ฉันพบว่าข้อมูลมีประโยชน์มากมันให้ภาพรวมที่ดีของภูมิทัศน์ NoSQL และ hype แต่นั่นเป็นส่วนที่สำคัญที่สุดมันช่วยให้คุณถามคำถามที่ถูกต้องเมื่อเลือกระหว่าง RDBMS และ NoSQL คุ้มค่ากับการอ่าน IMHO

ลิงก์สำรองไปยังบทความ

หลังจากสองปีที่ใช้ MongoDb สำหรับแอปโซเชียลฉันได้เห็นความหมายของการมีชีวิตอยู่โดยปราศจาก SQL RDBMS

1. คุณต้องเขียนงานเพื่อทำสิ่งต่าง ๆ เช่นการเข้าร่วมข้อมูลจากตาราง / คอลเลกชันต่าง ๆ สิ่งที่ RDBMS จะทำเพื่อคุณโดยอัตโนมัติ
2. ความสามารถในการสืบค้นของคุณด้วย NoSQL นั้นพิการอย่างมาก MongoDb อาจเป็นสิ่งที่ใกล้เคียงกับ SQL มากที่สุด แต่ก็ยังห่างไกลกันมาก เชื่อฉัน. แบบสอบถาม SQL นั้นใช้งานง่ายยืดหยุ่นและทรงพลังอย่างยิ่ง คำสั่ง MongoDb ไม่ใช่
3. คำสั่ง MongoDb สามารถดึงข้อมูลจากการรวบรวมเพียงครั้งเดียวและใช้ประโยชน์จากดัชนีเพียงอันเดียว และ MongoDb น่าจะเป็นหนึ่งในฐานข้อมูล NoSQL ที่ยืดหยุ่นที่สุด ในหลายสถานการณ์สิ่งนี้หมายถึงการไปกลับไปยังเซิร์ฟเวอร์เพื่อค้นหาระเบียนที่เกี่ยวข้อง และจากนั้นคุณก็เริ่มทำการลดขนาดข้อมูลลงซึ่งหมายถึงงานพื้นหลัง
4. ความจริงที่ว่ามันไม่ใช่ฐานข้อมูลเชิงสัมพันธ์หมายความว่าคุณจะไม่ได้รับข้อ จำกัด ที่สำคัญในต่างประเทศเพื่อให้แน่ใจว่าข้อมูลของคุณสอดคล้องกัน ฉันมั่นใจว่านี่จะเป็นการสร้างความไม่สอดคล้องของข้อมูลในฐานข้อมูลของคุณ เตรียมตัว. ส่วนใหญ่แล้วคุณจะเริ่มเขียนกระบวนการหรือตรวจสอบเพื่อให้ฐานข้อมูลของคุณสอดคล้องกันซึ่งอาจจะทำงานได้ไม่ดีไปกว่าการปล่อยให้ RDBMS ทำเพื่อคุณ
5. ลืมเกี่ยวกับกรอบผู้ใหญ่เช่นจำศีล

ฉันเชื่อว่า 98% ของโครงการทั้งหมดน่าจะดีกว่ากับ SQL RDBMS ทั่วไปมากกว่า NoSQL

เพื่อจัดเก็บข้อมูลที่ไม่มีโครงสร้างนี้

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

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

แต่ในทางตรงกันข้าม RDBM บังคับใช้ ACID และสกีมาบนข้อมูล หากคุณต้องการทำงานกับข้อมูลที่มีโครงสร้างคุณสามารถไปกับ RDBM ได้

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

โปรดทราบว่า Mongo จะเก็บ JSON เป็นหลัก หากแอปของคุณจัดการกับ JS Objects จำนวนมาก (ที่มีการซ้อนกัน) และคุณต้องการคงอยู่กับวัตถุเหล่านี้แสดงว่ามีอาร์กิวเมนต์ที่แข็งแกร่งมากสำหรับการใช้ Mongo มันทำให้ชั้น DAL และ MVC ของคุณบางเฉียบเป็นพิเศษเพราะพวกเขาไม่ได้ทำการบรรจุคุณสมบัติของออบเจ็กต์ JS ทั้งหมดและพยายามบังคับให้มันพอดีกับโครงสร้าง (สคีมา) ที่ไม่เข้ากับธรรมชาติ

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

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

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

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

โดยส่วนตัวฉันคิดว่า "nosql" จะเหี่ยวแห้งและตายจากการแตกแฟรกเมนต์เนื่องจากไม่มีมาตรฐานที่กำหนดไว้ (เกือบจะเป็นคำจำกัดความ) ดังนั้นฉันจะไม่เดิมพันเป็นการส่วนตัวสำหรับโครงการระยะยาว

สิ่งเดียวที่สามารถบันทึก "nosql" ในหนังสือของฉันคือถ้ามันสามารถรวมเข้ากับ Ruby หรือภาษาที่คล้ายกันได้อย่างราบรื่นและทำให้ภาษา "ถาวร" เกือบจะไม่มีค่าใช้จ่ายในการเขียนโปรแกรมและการออกแบบ อาจจะเกิดขึ้น แต่ฉันจะรอจนกว่าจะถึงตอนนั้นไม่ใช่ตอนนี้และมันจะต้องเป็นผู้ใหญ่มากขึ้นแน่นอน

แต่ทำไมคุณถึงสร้างฟอรัมขึ้นมาใหม่? มีฟอรัมโอเพนซอร์ซมากมายที่สามารถปรับแต่งให้เหมาะกับความต้องการส่วนใหญ่เว้นแต่ว่าคุณกำลังสร้าง The Next Generation of Forums (ซึ่งฉันสงสัย)

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

นั่นคือสิ่งหนึ่งที่ฉันคิดว่า MongoDB เหมาะสำหรับ แต่ MySQL / PostgreSQL แนะนำโดยทั่วไป มีเอกสารและแหล่งข้อมูลสำหรับนักพัฒนามากมายบนเว็บรวมถึงฟังก์ชั่นและความทนทานของมัน

เหตุผลหลัก 2 ข้อที่คุณอาจต้องการ Mongo คือ

• ความยืดหยุ่นในการออกแบบสคีมา (ที่เก็บเอกสารประเภท JSON)
• ความสามารถในการขยาย - เพียงแค่เพิ่มโหนดและมันสามารถขยายได้ในแนวนอน

เหมาะสำหรับการใช้งานข้อมูลขนาดใหญ่ RDBMS ไม่ดีสำหรับข้อมูลขนาดใหญ่

คุณรู้ทุกอย่างเกี่ยวกับการเข้าร่วมและ 'การทำธุรกรรมที่ซับซ้อน' - แต่มันก็เป็น Monty ที่เมื่อหลายปีก่อนอธิบายถึง "ความต้องการ" สำหรับ COMMIT / ROLLBACK โดยบอกว่า 'สิ่งที่ทำในคลาสตรรกะ (และไม่ใช่ฐานข้อมูล) อย่างไรก็ตาม '- ดังนั้นจึงเป็นสิ่งเดียวกันอีกครั้ง สิ่งที่จำเป็นคือเครื่องมือจัดเก็บ / เรียกคืนข้อมูลที่รวดเร็วและเป็นระเบียบอย่างไม่น่าเชื่อและ 99% ของสิ่งที่เว็บแอปทำ

อย่างที่ได้กล่าวไปแล้วก่อนหน้านี้คุณสามารถเลือกได้หลายทางเลือกดูตัวเลือกเหล่านั้นทั้งหมด: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

สิ่งที่ฉันแนะนำคือหาชุดที่ดีที่สุดของคุณ: MySQL + Memcache นั้นยอดเยี่ยมมากถ้าคุณต้องการกรดและคุณต้องการเข้าร่วมบางตาราง MongoDB + Redis เหมาะสำหรับที่เก็บเอกสาร Neo4J เหมาะสำหรับฐานข้อมูลกราฟ

ฉันต้องทำอะไร: ฉันเริ่มต้นด้วย MySQl + Memcache เพราะฉันคุ้นเคยแล้วฉันก็เริ่มใช้กรอบงานฐานข้อมูลอื่น ๆ ในโครงการเดียวคุณสามารถรวม MySQL และ MongoDB เข้าด้วยกัน!