ความแตกต่างระหว่างฐานข้อมูล Document-based และ Key / Value-based?


98

ฉันรู้ว่ามีฐานข้อมูลที่ไม่ใช่ sql ที่เป็นที่นิยมสามประเภท

  • คีย์ / ค่า: Redis, Tokyo Cabinet, Memcached
  • ColumnFamily: Cassandra, HBase
  • เอกสาร: MongoDB, CouchDB

ฉันอ่านบล็อกยาว ๆ เกี่ยวกับเรื่องนี้โดยไม่เข้าใจมากนัก

ฉันรู้จักฐานข้อมูลเชิงสัมพันธ์และใช้งานฐานข้อมูลเอกสารเช่น MongoDB / CouchDB

ใครช่วยบอกฉันหน่อยว่าความแตกต่างที่สำคัญระหว่างสิ่งเหล่านี้กับ 2 อดีตในรายการคืออะไร


4
มีห้า: (1) Key-Value Stores: Oracle Coherence, Redis, Kyoto Cabinet (2) ฐานข้อมูลแบบ BigTable: Apache HBase, Apache Cassandra (3) ฐานข้อมูลเอกสาร: MongoDB, CouchDB (4) เครื่องมือค้นหาข้อความแบบเต็ม: Apache Lucene, Apache Solr (5) Graph Databases: neo4j, FlockDB, ดูnosql-data-modeling-technique
Gary Gauh

คำตอบ:


75

ความแตกต่างที่สำคัญคือแบบจำลองข้อมูลและความสามารถในการสืบค้น

ร้านค้าคีย์ - ค่า

ประเภทแรกนั้นง่ายมากและอาจไม่ต้องการคำอธิบายเพิ่มเติม

รูปแบบข้อมูล: มากกว่าที่เก็บคีย์ - ค่า

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

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

ฐานข้อมูลเอกสารเช่น CouchDB และ MongoDB เก็บเอกสารทั้งในรูปแบบของวัตถุ JSON คุณสามารถคิดว่าออบเจ็กต์เหล่านี้เป็นคู่คีย์ - ค่าที่ซ้อนกัน ไม่เหมือนกับ Cassandra คุณสามารถซ้อนคู่คีย์ - ค่าได้มากเท่าที่คุณต้องการ JSON ยังรองรับอาร์เรย์และเข้าใจประเภทข้อมูลต่างๆเช่นสตริงตัวเลขและค่าบูลีน

การสืบค้น

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

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


2
ดังนั้นที่เก็บคีย์ - ค่าเช่น redit จึงไม่อนุญาตให้คุณเก็บคีย์ที่ซ้อนกัน: ค่า? และจากคำอธิบายของคุณการจัดเก็บฐานข้อมูลทั้งหมด (จาก RDBMS) ลงใน Cassandra ไม่ได้ฟังดูฉลาดนักเพราะมันไม่อนุญาตให้มีการสืบค้นที่ยืดหยุ่นและมีความลึกของการซ้อน จำกัด ฉันใช่ไหม
never_had_a_name

7
@ajsie: ที่เก็บคีย์ - ค่าที่ถูกต้องไม่รองรับคู่คีย์ - ค่าที่ซ้อนกัน ส่วนใหญ่สนับสนุนค่าเฉพาะเช่นรายการ Cassandra แตกต่างจาก RDBMS มากเนื่องจากทั้งสองได้รับการออกแบบมาเพื่อแก้ปัญหาที่แตกต่างกันมาก ระบบ RDBMS มุ่งเป้าไปที่ข้อมูลเชิงสัมพันธ์ที่ต้องการการสืบค้นที่ซับซ้อนในขณะที่ Cassandra มุ่งเป้าไปที่การประมวลผลข้อมูลที่ไม่ใช่เชิงสัมพันธ์ส่วนใหญ่เป็นจำนวนมหาศาล แน่นอนว่าเป็นไปได้ที่จะย้ายฐานข้อมูล RDBMS ไปที่ Cassandra แต่ก็ไม่ได้ฉลาดมากนัก แต่ละคนมีการใช้งานของตัวเอง
Niels van der Rest

ดังนั้นฐานข้อมูลเอกสารทุกรายการจึงเป็นคีย์ที่เก็บค่าโดยที่ค่าเป็นเพียง JSON เช่น {value: base64 (val)}
GroovyDotCom

@GroovyDotCom: ใช่คุณสามารถใช้ฐานข้อมูลเอกสารเพื่อจัดเก็บวัตถุคีย์ / ค่าอย่างง่าย
Niels van der Rest

16

Ayendeได้ให้คำอธิบายที่ดีเกี่ยวกับความแตกต่างระหว่างคีย์ - ค่าและฐานข้อมูลเอกสาร:

ฐานข้อมูลเอกสารเป็นที่เก็บคีย์ / ค่าที่เป็นแกนหลักโดยมีข้อยกเว้นที่สำคัญอย่างหนึ่ง แทนที่จะเก็บ blob ใด ๆ ไว้ในนั้นdb ของเอกสารต้องการให้เก็บข้อมูลในรูปแบบที่ฐานข้อมูลสามารถเข้าใจได้ (เช่น JSON, XML เป็นต้น) ใน doc dbs ส่วนใหญ่นั่นหมายความว่าตอนนี้เราสามารถอนุญาตการสืบค้นข้อมูลเอกสารได้แล้ว

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.