MongoDB กับ Cassandra [ปิด]

738

ปิด. คำถามนี้ไม่เป็นไปตามหลักเกณฑ์กองมากเกิน ไม่ยอมรับคำตอบในขณะนี้

ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นไปตามหัวข้อสำหรับ Stack Overflow

ปิดให้บริการใน3 ปีที่ผ่านมา

ฉันกำลังประเมินสิ่งที่อาจเป็นตัวเลือกการโยกย้ายที่ดีที่สุด

ขณะนี้ฉันอยู่ใน MySQL (พาร์ติชันแนวนอน) ที่ถูกแบ่งส่วนด้วยข้อมูลส่วนใหญ่ของฉันที่จัดเก็บใน JSON blobs ฉันไม่มีการสืบค้น SQL ที่ซับซ้อนใด ๆ (หลังจากย้ายไปแล้วตั้งแต่ฉันแบ่งพาร์ติชัน db)

ตอนนี้ดูเหมือนว่าทั้ง MongoDB และ Cassandra น่าจะเป็นทางเลือก สถานการณ์ของฉัน:

มีการอ่านจำนวนมากในทุกข้อความค้นหามีการเขียนน้อยกว่าปกติ
ไม่กังวลเกี่ยวกับความสามารถในการขยายขนาดใหญ่
มีความกังวลเกี่ยวกับการตั้งค่าการบำรุงรักษาและรหัสอย่างง่าย
ลดค่าใช้จ่ายด้านฮาร์ดแวร์ / เซิร์ฟเวอร์ให้น้อยที่สุด

— หมิงเย้า
แหล่งที่มา

4

มีสถิติการวัดประสิทธิภาพอย่างเป็นทางการ คาสซานดรา vs MongoDB vs HBase

— ราวิ

1

> จำนวนมากอ่านในทุกแบบสอบถามน้อยเขียนปกติ => มองหา CQRS (แยกการอ่านของคุณจากการเขียนของคุณอาจจะไม่จัดหาเหตุการณ์ แต่ตรวจสอบว่าคุณสามารถอัปเดตการอ่านแบบจำลอง async .. ซิงค์อาจทำงานได้ .. ขึ้นอยู่กับการใช้งานของคุณ -case)

— bodrin

2

นี่เป็นคำถามที่ยอดเยี่ยมจริงๆ ฉันสงสัยว่ามีรุ่นที่อัปเดตหรือไม่ อันนี้เก่ามากตอนนี้

— slashdottir

584

มีการอ่านจำนวนมากในทุกข้อความค้นหามีการเขียนปกติน้อยลง

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

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

สำหรับการวิเคราะห์ MongoDB จัดทำแผนที่แบบกำหนดเอง / ลดการใช้งาน Cassandra ให้การสนับสนุน Hadoop แบบดั้งเดิมรวมถึง Hive (คลังข้อมูล SQL ที่สร้างบนแผนที่ Hadoop / ย่อขนาด) และPig (ภาษาการวิเคราะห์เฉพาะ Hadoop ที่หลายคนคิดว่าเหมาะสำหรับแผนที่ / ลดปริมาณงานมากกว่า SQL) คาสซานดรานอกจากนี้ยังสนับสนุนการใช้งานของสปาร์ค

ไม่กังวลเกี่ยวกับความสามารถในการขยายขนาดใหญ่

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

มีความกังวลเกี่ยวกับการตั้งค่าการบำรุงรักษาและรหัสอย่างง่าย

ทั้งสองเป็นเรื่องง่ายที่จะตั้งค่าด้วยค่าเริ่มต้นที่เหมาะสมสำหรับเซิร์ฟเวอร์เดียว Cassandra นั้นง่ายต่อการตั้งค่าในการกำหนดค่าหลายเซิร์ฟเวอร์เนื่องจากไม่มีโหนดบทบาทพิเศษที่ต้องกังวล

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

— ไมเคิล
แหล่งที่มา

86

ความคิดเห็นนั้นไม่ใหญ่พอ แต่ ... Cassandra เป็นไดนามิค / google bigtable ไฮบริดที่ปรับขนาดได้เชิงเส้น (ตัดและอ่านค่าคงที่แบบคงที่) ชุดคุณลักษณะเป็นแบบเรียบง่ายเล็กน้อยนอกเหนือจากที่เก็บค่าคีย์ที่สั่งซื้อ MongoDB เป็นที่เก็บเอกสารที่โดดเด่น (และเร็ว) ในราคาที่มีความทนทานและรับประกันเกี่ยวกับการเขียนที่คงอยู่ (เนื่องจากไม่ได้เขียนลงในดิสก์ในทันที) พวกเขาเป็นสัตว์ต่าง ๆ ที่มีปรัชญาต่างกัน MongoDB ใกล้จะเข้ามาแทนที่ RDMS ...

— Michael

28

ในขณะที่ Cassandra อยู่ในระดับที่ต่ำกว่า แต่อนุญาตให้ปรับขนาด uber (ดู Twitter / Digg / Facebook) แต่คุณจะต้องพิจารณาอย่างรอบคอบว่าคุณวางโครงสร้างข้อมูลอย่างไรสร้างดัชนีรองเป็นต้นเนื่องจากไม่อนุญาตการสืบค้นที่ยืดหยุ่น

— Michael

11

เนื่องจากทุกคนพูดถึงทวิตเตอร์ที่นี่เกี่ยวกับคาสซานดรา: พวกเขาไม่ได้ใช้คาสซานดราสำหรับทวีตที่มีอยู่พวกเขายังใช้ MySQL ที่นี่ ( engineering.twitter.com/2010/07/cassandra-at-twitter-today.html ) ตกลง แต่ฉันสามารถจินตนาการได้ว่าพวกเขายังเก็บข้อมูลจำนวนมากเพื่อจุดประสงค์อื่นใน Cassandra

— H6

7

ดูเหมือนว่าล็อคการเขียนทั่วโลกอาจถูกลบออกไปใน Mongo 2.2 ...

— Matt Farmer

16

แม้กระทั่งก่อนที่โปรเจ็กต์ของฉันจะแสดงสดฉันรู้สึกถึงความเจ็บปวดของ Mongodb การสำรองข้อมูลยอดนิยมเป็นข้อกำหนดขั้นพื้นฐาน หากต้องการสำรองข้อมูลร้อนในเซิร์ฟเวอร์ Linux คุณต้องตั้งค่าพาร์ติชัน LVM ก่อน (ไม่ธรรมดา) และทำการถ่ายภาพก่อนทุกครั้งที่ทำการสำรองข้อมูล อีกวิธีที่ง่ายคือใช้ Mongodb ซึ่งเป็นบริการสำรองข้อมูลที่ชำระเงินแล้ว แต่บริการนั้นมีราคาแพง (2.3 $ / GB / เดือน) ในไม่ช้าคุณจะต้องมีแบบจำลองสำหรับการยอมรับข้อบกพร่อง ด้วยเวอร์ชันโอเพ่นซอร์สโหนดสามารถแลกเปลี่ยนข้อมูลเป็นข้อความธรรมดาเท่านั้น สำหรับ SSL คุณต้องไปกับ Entprise edition และนั่นคือ 10,000 $ Goodbye Mongodb เปลี่ยนรหัสของฉันเป็น Cassandra อีกครั้ง

— Karthik Sankar

146

ฉันใช้ MongoDB อย่างกว้างขวาง (ในช่วง 6 เดือนที่ผ่านมา) การสร้างระบบการจัดการข้อมูลแบบลำดับชั้นและฉันสามารถรับรองได้ทั้งความง่ายในการติดตั้ง (ติดตั้งใช้งานใช้มัน!) และความเร็ว ตราบใดที่คุณคิดเกี่ยวกับดัชนีอย่างระมัดระวังก็สามารถกรีดร้องอย่างฉลาดความเร็ว

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

Swinger ที่แท้จริงสำหรับฉันเมื่อเราประเมินฐานข้อมูล NoSQL คือการสอบถาม - Cassandra นั้นเป็นเพียงที่เก็บคีย์ / ค่ายักษ์และการสืบค้นนั้นค่อนข้างยุ่งเหยิง (อย่างน้อยเมื่อเทียบกับ MongoDB) ดังนั้นสำหรับประสิทธิภาพที่คุณต้อง ทำสำเนาข้อมูลค่อนข้างมากเป็นดัชนีคู่มือ ในทางกลับกัน MongoDB จะใช้โมเดล "เคียวรีตามตัวอย่าง"

ตัวอย่างเช่นสมมติว่าคุณมี Collection (MongoDB parlance สำหรับเทียบเท่ากับตาราง RDMS) ที่มีผู้ใช้ MongoDB เก็บบันทึกเป็นเอกสารซึ่งโดยทั่วไปแล้วเป็นวัตถุ JSON ไบนารี เช่น:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "john@smith.com",
   Groups: ["Admin", "User", "SuperUser"]
}

หากคุณต้องการค้นหาผู้ใช้ทั้งหมดที่เรียกว่าสมิ ธ ซึ่งมีสิทธิ์ผู้ดูแลระบบคุณเพียงแค่สร้างเอกสารใหม่ (ที่คอนโซลผู้ดูแลระบบโดยใช้ Javascript หรือในการผลิตโดยใช้ภาษาที่คุณเลือก):

{
   LastName: "Smith",
   Groups: "Admin"
}

... แล้วเรียกใช้แบบสอบถาม แค่นั้นแหละ. มีโอเปอเรเตอร์ที่เพิ่มเข้ามาสำหรับการเปรียบเทียบการกรอง RegEx และอื่น ๆ แต่ทั้งหมดนั้นค่อนข้างง่ายและเอกสารที่ใช้ Wiki นั้นค่อนข้างดี

— Richard K
แหล่งที่มา

54

Update (8 สิงหาคม 2554): ศูนย์ข้อมูล EC2 ในไอร์แลนด์ของ Amazon มีเหตุการณ์ที่เกี่ยวข้องกับฟ้าผ่าเมื่อคืนและในการจัดเรียงการกู้คืนเซิร์ฟเวอร์ของเราฉันค้นพบจุดสำคัญหนึ่งที่น่าสนใจ: หากคุณมีชุดการจำลองแบบของเซิร์ฟเวอร์สองเครื่อง ง่ายต่อการติดตั้ง) ตรวจสอบให้แน่ใจว่าคุณมีโหนด Arbiter ดังนั้นหากมีการล่มโหนดอื่นจะไม่ตื่นตระหนกและหยุดชะงักในโหมดรอง! เชื่อฉันเถอะว่ามันเป็นความเจ็บปวดในการเรียงลำดับฐานข้อมูลขนาดใหญ่

— Richard K.

8

ในการเพิ่มสิ่งที่ @Richard K กล่าวคุณควรมีโหนดผู้ตัดสินเมื่อคุณมีจำนวนโหนด (หลัก + รอง) ในชุดแบบจำลอง

— Amareswar

เพิ่มไปที่พิจารณา mongodb เมื่อรวมมากขึ้นที่จะต้องทำในการวิเคราะห์ข้อมูล

— user1503117

As long as you think about indexes carefully, it can absolutely scream along, speed-wise.รอจนกว่าหน่วยความจำกายภาพของคุณจะเต็มและระบบปฏิบัติการเริ่มต้นหน้าข้อบกพร่อง lol

— sturcotte06

117

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

โดยทั่วไปแล้ว NoSQL datastores จะปรับขนาดได้ดีกว่า DB แบบดั้งเดิมสำหรับรายละเอียดอื่น ๆ - มีเหตุผลว่าทำไม Facebook, Twitter, Google และ start-ups ส่วนใหญ่ใช้โซลูชัน NoSQL มันไม่ใช่แค่การได้เห็นเทคโนโลยีใหม่ ๆ

— Jason Grant Taylor
แหล่งที่มา

8

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

— Ram on Rails-n-React

ฉันยังใช้วิธีการสองอย่างในโครงการส่วนใหญ่ของฉันและในบางกรณีระบบไฟล์ที่ติดตั้งของ NFS ก็ถูกใช้ร่วมกับ PostgreSQL สำหรับการเกิดแผ่นดินไหวที่ใกล้ถึง 1 Gb ในบางกรณี เส้นทางเป็นชนิดของแบบสอบถามไปยังฐานข้อมูลค่าคีย์

— Audrius Meskauskas

1

นี่คือลิงค์ไปยังคำถามที่ฉันถามเกี่ยวกับวิธีการออกแบบฐานข้อมูลทั้ง sql และ nosql: dba.stackexchange.com/questions/102053/ฉันสามารถใช้ข้อมูลเชิงลึกที่คุณอาจมี

— j

เขาได้หลบหนีจากการทำธุรกรรมเพื่อความดี => ตอนนี้ความสามารถในการขยายแบบไม่ จำกัด อาจเป็นไปได้ .. มิฉะนั้น -> ไม่ :)

— bodrin

1

นี้ไม่ได้เป็นวิธีการแก้ปัญหาที่ดีถ้าข้อมูลของคุณมีการกระจาย

— Esteban Verbel

60

ฉันอาจจะเป็นคนแปลกหน้า แต่ฉันคิดว่าคุณต้องอยู่กับ MySQL คุณยังไม่ได้อธิบายถึงปัญหาที่แท้จริงที่คุณต้องแก้ไขและ MySQL / InnoDB เป็นที่เก็บข้อมูลส่วนหลังที่ยอดเยี่ยมแม้สำหรับข้อมูล blob / json

มีกลอุบายทั่วไปในหมู่วิศวกรเว็บในการพยายามใช้ NoSQL ให้มากขึ้นในทันทีที่การรับรู้เกิดขึ้นว่ามีการใช้คุณสมบัติบางอย่างของ RDBMS สิ่งนี้เพียงอย่างเดียวไม่ใช่เหตุผลที่ดีเนื่องจากฐานข้อมูลส่วนใหญ่ของ NoSQL มักมีเอ็นจิ้นข้อมูลที่ไม่ดีนัก (สิ่งที่ MySQL เรียกว่าเอ็นจิ้นการจัดเก็บ)

ตอนนี้ถ้าคุณไม่ได้เป็นประเภทนั้นโปรดระบุสิ่งที่ขาดหายไปใน MySQL และคุณกำลังมองหาในฐานข้อมูลที่แตกต่างกัน (เช่น auto-sharding, failover อัตโนมัติ, การจำลองแบบ multi-master, การรับประกันความสอดคล้องของข้อมูลที่อ่อนแอกว่า คลัสเตอร์จ่ายเงินเป็นปริมาณงานการเขียนที่สูงขึ้น ฯลฯ )

— Kostja
แหล่งที่มา

13

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

— fabspro

18

เขายังเก็บ blobs JSON ส่วนใหญ่ใน RDBMS - การเรนเดอร์การออกแบบเชิงสัมพันธ์ (คุณลักษณะ) ไร้ประโยชน์

— Damir Sudarevic

4

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

— Kostja

7

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

— Kostja

20

ฉันไม่ได้ใช้ Cassandra แต่ฉันใช้ MongoDB และคิดว่ามันยอดเยี่ยม

หากคุณตั้งค่าได้ง่าย ๆ นี่คือ: คุณเพียงแค่ปลดล็อค MongoDB และเรียกใช้ mongod daemon และนั่นก็คือ ... มันกำลังทำงานอยู่

เห็นได้ชัดว่าเป็นเพียงผู้เริ่มต้น แต่เพื่อให้คุณเริ่มต้นได้ง่าย

— ดาลตัน
แหล่งที่มา

22

AFAIK เช่นเดียวกันกับ Cassandra เช่นกัน ก่อนอื่นให้เรียกใช้ daemon คลัสเตอร์การทดสอบกำลังติดตั้งและพร้อมสำหรับการผลิต!

— asgs

13

ฉันเห็นงานนำเสนอบน mongodb เมื่อวานนี้ ฉันสามารถพูดได้ว่าการตั้งค่านั้น "ง่าย" ง่ายพอ ๆ กับการแกะกล่องออกมาและทำการยิง เสร็จสิ้น

ฉันเชื่อว่าทั้ง mongodb และ Cassandra จะทำงานบนฮาร์ดแวร์ linux ปกติใด ๆ ดังนั้นคุณไม่ควรเจออุปสรรคมากมายในพื้นที่นั้น

ฉันคิดว่าในกรณีนี้ในตอนท้ายของวันมันจะลงมาที่คุณรู้สึกสะดวกสบายมากขึ้นและมีชุดเครื่องมือที่คุณต้องการ เท่าที่มีการนำเสนอบน mongodb พรีเซนเตอร์ระบุว่าชุดเครื่องมือสำหรับ mongodb นั้นค่อนข้างเบาและมีหลาย ๆ อันที่พวกเขาพูดถึงเครื่องมือที่คล้ายกันกับ MySQL แน่นอนว่านี่คือประสบการณ์ของพวกเขาดังนั้น YMMV สิ่งหนึ่งที่ฉันชอบเกี่ยวกับ mongodb คือดูเหมือนจะมีภาษารองรับมากมาย (Python และ. NET เป็นสองภาษาที่ฉันใช้เป็นหลัก)

รายการไซต์ที่ใช้ Mongodb นั้นน่าประทับใจมากและฉันรู้ว่า Twitter เพิ่งเปลี่ยนมาใช้ Cassandra

— GrayWizardx
แหล่งที่มา

4

ในตอนท้ายของวันมันเป็นแอปเปิ้ล vs ส้มเปรียบเทียบ ฐานข้อมูลทั้งสองมีจุดแข็งของตัวเอง ต่อไปนี้เป็นบางสิ่งที่ต้องพิจารณา - โมเดลวัตถุดัชนีรองเขียนย่อความยืดหยุ่นสูง ฯลฯ มีโพสต์บล็อกที่อธิบายถึงความแตกต่างเชิงกลยุทธ์ระดับสูงระหว่าง Mongodb กับ Cassandra ที่นี่ - scalegrid.io/blog/cassandra-vs-mongodb

— Dharshan