เมื่อใดจึงควรใช้ CouchDB บน ​​MongoDB และในทางกลับกัน

ฉันติดอยู่ระหว่างฐานข้อมูล NoSQL ทั้งสองนี้

ในโครงการของฉันฉันจะสร้างฐานข้อมูลภายในฐานข้อมูล ตัวอย่างเช่นฉันต้องการโซลูชันเพื่อสร้างตารางแบบไดนามิก

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

จาก C, A & P (ความสอดคล้องความพร้อมใช้งานและความทนทานต่อพาร์ติชัน) ซึ่ง 2 มีความสำคัญต่อคุณมากกว่าหรือไม่ คู่มืออ้างอิงฉบับย่อเกี่ยวกับระบบ NoSQL

• MongodB: ความสม่ำเสมอและความอดทนของการแบ่งส่วน
• CouchDB: ความพร้อมใช้งานและความทนทานของพาร์ติชัน

บล็อกโพสต์Cassandra vs MongoDB เทียบกับ CouchDB เทียบกับ Redis เทียบกับ Riak เทียบกับ HBase เทียบกับ Membase vs Neo4j การเปรียบเทียบมีสถานการณ์ 'ที่ใช้ดีที่สุด ' สำหรับแต่ละฐานข้อมูล NoSQL เปรียบเทียบ อ้างถึงลิงก์

• MongoDB: หากคุณต้องการคิวรีแบบไดนามิก หากคุณต้องการกำหนดดัชนีอย่าแมป / ลดฟังก์ชั่น หากคุณต้องการประสิทธิภาพที่ดีในฐานข้อมูลขนาดใหญ่ หากคุณต้องการ CouchDB แต่ข้อมูลของคุณเปลี่ยนแปลงมากเกินไปให้เติมดิสก์
• CouchDB: สำหรับการรวบรวมข้อมูลที่เปลี่ยนแปลงเป็นครั้งคราวซึ่งแบบสอบถามที่กำหนดไว้ล่วงหน้าจะต้องถูกเรียกใช้ สถานที่ที่การกำหนดเวอร์ชันมีความสำคัญ

ล่าสุด (ก.พ. 2555) และการเปรียบเทียบที่ครอบคลุมยิ่งขึ้นโดย Riyad Kalla

• MongoDB: การจำลองแบบ Master-Slave เท่านั้น
• CouchDB: การจำลองแบบต้นแบบหลัก

โพสต์บล็อก (ต.ค. 2011) โดยคนที่ลองทั้งสองคนA MongoDB Guy Learns CouchDB ให้ความเห็นเกี่ยวกับเพจของ CouchDB ว่าไม่มีประโยชน์

เกณฑ์มาตรฐานวันที่ (มิ.ย. 2009) โดยKristina Chodorow ( ส่วนหนึ่งของทีมที่อยู่เบื้องหลัง MongoDB )

ฉันจะไป MongoDB

หวังว่ามันจะช่วย

คำตอบข้างต้นทำให้เรื่องราวซับซ้อนขึ้น

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

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

คำถามเก่ามาก แต่อยู่ด้านบนของ Google และฉันไม่ชอบคำตอบที่ฉันเห็นดังนั้นนี่เป็นของฉันเอง

Couchdb มีอะไรมากกว่าความสามารถในการพัฒนา CouchApps คนส่วนใหญ่ใช้ CouchDb ในสถาปัตยกรรมเว็บคลาส 3 ชั้น

ในการฝึกปัจจัยการตัดสินใจสำหรับคนส่วนใหญ่จะเป็นข้อเท็จจริงที่ MongoDb อนุญาตให้ทำการสอบถามด้วย SQL เช่นไวยากรณ์ในขณะที่ CouchDb ไม่ได้ (คุณต้องสร้างแผนที่ / มุมมองลดซึ่งบางคนปิดแม้ว่าจะสร้างมุมมองเหล่านี้ การพัฒนาแอปพลิเคชันอย่างรวดเร็วเป็นมิตร - พวกเขาไม่เกี่ยวข้องกับกระบวนการจัดเก็บ)

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

สิ่งสำคัญอย่างหนึ่งที่ไม่มีใครพูดถึงคือความจริงที่ว่า CouchDb อาศัยดัชนี b-tree ซึ่งหมายความว่าไม่ว่าคุณจะมี 1 "แถว" หรือ 20 พันล้านครั้งเวลาสอบถามจะยังคงต่ำกว่า 10ms เสมอ นี่คือตัวเปลี่ยนเกมซึ่งทำให้ CouchDb เป็นฐานข้อมูลที่มีความหน่วงต่ำและอ่านง่ายและนี่ไม่ควรมองข้าม

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

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

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

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

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

ถามคำถามนี้ด้วยตัวเอง? และคุณจะตัดสินใจเลือก DB ของคุณ

1. คุณต้องการปริญญาโทหรือไม่? จากนั้น CouchDB CouchDB ส่วนใหญ่สนับสนุนการจำลองแบบต้นแบบหลักซึ่งคาดว่าโหนดจะถูกตัดการเชื่อมต่อเป็นระยะเวลานาน MongoDB จะทำได้ไม่ดีในสภาพแวดล้อมนั้น
2. คุณต้องการปริมาณงานสูงสุด R / Wหรือไม่? จากนั้น MongoDB
3. คุณต้องการความทนทานของเซิร์ฟเวอร์เดียวระดับสูงสุดเพราะคุณจะมีเซิร์ฟเวอร์ฐานข้อมูลเดียวหรือไม่ จากนั้น CouchDB
4. คุณกำลังจัดเก็บชุดข้อมูลขนาดใหญ่ที่ต้องใช้การแบ่งส่วนขณะที่ยังคงรักษาปริมาณงานได้อย่างบ้าคลั่งอยู่หรือไม่? จากนั้น MongoDB
5. คุณต้องการข้อมูลที่สม่ำเสมอหรือไม่? จากนั้น MongoDB
6. คุณต้องการฐานข้อมูลที่พร้อมใช้งานสูงหรือไม่? จากนั้น CouchDB
7. คุณหวังว่าหลายฐานข้อมูลและหลายตาราง / คอลเลกชัน? จากนั้น MongoDB
8. คุณมีผู้ใช้แอปมือถือออฟไลน์และต้องการซิงค์ข้อมูลกิจกรรมของพวกเขากับเซิร์ฟเวอร์หรือไม่? จากนั้นคุณต้อง CouchDB
9. คุณต้องการเครื่องมือสืบค้นข้อมูลจำนวนมากหรือไม่? จากนั้น MongoDB
10. คุณต้องการให้ชุมชนขนาดใหญ่ใช้ DB หรือไม่? จากนั้น MongoDB

ฉันสรุปคำตอบที่พบในบทความนั้น:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

MongoDB: การสืบค้นที่ดีกว่า, การจัดเก็บข้อมูลใน BSON (เข้าถึงได้เร็วขึ้น), ความสอดคล้องของข้อมูลที่ดีขึ้น, การรวบรวมหลายครั้ง

CouchDB: การจำลองแบบที่ดีกว่าด้วยการจำลองแบบต้นแบบสู่ต้นแบบและการแก้ไขข้อขัดแย้งจัดเก็บข้อมูลใน JSON (มนุษย์อ่านได้เข้าถึงได้ดีขึ้นผ่านบริการ REST) ​​สอบถามผ่านการลดแผนที่

ดังนั้นโดยสรุป MongoDB เร็วกว่า CouchDB ปลอดภัยกว่า

นอกจากนี้: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

ระวังปัญหาด้วยดัชนีที่กระจัดกระจายใน MongoDB ฉันได้รับมันและมันเป็นวิธีที่ยุ่งยากที่สุดในการแก้ปัญหา

ปัญหาคือสิ่งนี้ - คุณมีเขตข้อมูลซึ่งมีลักษณะเฉพาะถ้ามีและคุณต้องการค้นหาวัตถุทั้งหมดที่ไม่มีเขตข้อมูล วิธีการนำดัชนีที่กระจัดกระจายมาใช้ใน Mongo นั้นคือวัตถุที่เขตข้อมูลนั้นหายไปนั้นไม่ได้อยู่ในดัชนีเลย - พวกเขาไม่สามารถเรียกค้นได้โดยแบบสอบถามในเขตข้อมูลนั้น -{$exists: false}ใช้งานไม่ได้

วิธีแก้ปัญหาเดียวที่ฉันพบคือการมีตระกูลค่าพิเศษซึ่งค่าว่างถูกแปลเป็นคำนำหน้าพิเศษ (เช่นnull: :) ตัดแบ่งเป็น uuid นี่เป็นอาการปวดหัวจริง ๆ เพราะเราต้องดูแลการเปลี่ยนเป็น / จากค่าที่ว่างเมื่อเขียน / เลิก / อ่าน ความรำคาญครั้งใหญ่

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

BTW ถ้าใครรู้ลิงค์ไปยังประเด็น Mongo ที่อธิบายปัญหาดัชนีกระจัดกระจาย - โปรดแชร์

ฉันแน่ใจว่าคุณสามารถทำได้กับ Mongo (คุ้นเคยกับมันมากกว่า) และค่อนข้างแน่ใจว่าคุณสามารถใช้โซฟาได้เช่นกัน

ทั้งสองเป็นเอกสารเชิง (อิง JSON) ดังนั้นจะไม่มี "คอลัมน์" แต่เป็นฟิลด์ในเอกสาร - แต่สามารถเป็นแบบไดนามิกได้อย่างสมบูรณ์

พวกเขาทั้งสองทำคุณอาจต้องการดูปัจจัยอื่น ๆ ที่ใช้: คุณสมบัติอื่น ๆ ที่คุณสนใจความนิยม ฯลฯ ข้อมูลเชิงลึกของ Google, แน่นอนงานโพสต์แน่นอนจะเป็นวิธีการดูความนิยม

คุณสามารถลองมันฉันคิดว่าคุณควรจะสามารถใช้ mongo ใน 5 นาที