NoSQL แบบเน้นคอลัมน์แตกต่างจากแบบเอกสารอย่างไร?

ฐานข้อมูล NoSQL สามประเภทที่ฉันอ่านคือคีย์ - ค่าเชิงคอลัมน์และเชิงเอกสาร

คีย์ - ค่าค่อนข้างตรงไปตรงมา - คีย์ที่มีค่าธรรมดา

ฉันเคยเห็นฐานข้อมูลเชิงเอกสารที่อธิบายว่าเหมือนคีย์ - ค่า แต่ค่าสามารถเป็นโครงสร้างได้เช่นเดียวกับออบเจ็กต์ JSON "เอกสาร" แต่ละรายการสามารถมีคีย์ทั้งหมดบางส่วนหรือไม่มีคีย์ใดก็ได้เหมือนกัน

คอลัมน์ที่เน้นดูเหมือนจะเหมือนกับเอกสารที่คุณไม่ได้ระบุโครงสร้าง

แล้วสองสิ่งนี้แตกต่างกันอย่างไรและทำไมคุณถึงใช้อีกอันหนึ่ง?

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

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

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

มีโครงสร้างอีกระดับหนึ่ง (ไม่นิยมใช้) เรียกว่าซุปเปอร์คอลัมน์โดยที่คอลัมน์มีคอลัมน์ซ้อนกัน (ย่อย)

คุณสามารถคิดว่าโครงสร้างโดยรวมเป็นแฮชแท็ก / พจนานุกรมที่ซ้อนกันโดยมีคีย์ 2 หรือ 3 ระดับ

ตระกูลคอลัมน์ปกติ:

row
    col  col  col ...
    val  val  val ...

ตระกูลซุปเปอร์คอลัมน์:

row
      supercol                      supercol                     ...
          (sub)col  (sub)col  ...       (sub)col  (sub)col  ...
           val       val      ...        val       val      ...

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

ดูคำถามนี้ด้วย: คาสซานดรา: คอลัมน์ย่อยคืออะไร

หรือลิงก์การสร้างแบบจำลองข้อมูลจากhttp://wiki.apache.org/cassandra/ArticlesAndPresentations

Re: การเปรียบเทียบกับฐานข้อมูลที่เน้นเอกสาร - ส่วนหลังมักจะแทรกเอกสารทั้งหมด (โดยทั่วไปคือ JSON) ในขณะที่ Cassandra คุณสามารถระบุคอลัมน์หรือคอลัมน์พิเศษแต่ละคอลัมน์และอัปเดตทีละคอลัมน์ได้เช่นทำงานในระดับความละเอียดที่แตกต่าง แต่ละคอลัมน์มีการประทับเวลา / เวอร์ชันแยกกัน (ใช้เพื่อกระทบยอดการอัปเดตข้ามคลัสเตอร์แบบกระจาย)

ค่าคอลัมน์ Cassandra เป็นเพียงไบต์ แต่สามารถพิมพ์เป็น ASCII ข้อความ UTF8 ตัวเลขวันที่ ฯลฯ

แน่นอนคุณสามารถใช้ Cassandra เป็นที่เก็บเอกสารดั้งเดิมได้โดยการแทรกคอลัมน์ที่มี JSON แต่คุณจะไม่ได้รับคุณสมบัติทั้งหมดของที่เก็บเอกสารที่แท้จริง

ข้อแตกต่างที่สำคัญคือที่เก็บเอกสาร (เช่น MongoDB และ CouchDB) อนุญาตให้ใช้เอกสารที่ซับซ้อนโดยพลการเช่นเอกสารย่อยภายในเอกสารย่อยรายการที่มีเอกสาร ฯลฯ ในขณะที่ที่เก็บคอลัมน์ (เช่น Cassandra และ HBase) อนุญาตเฉพาะรูปแบบคงที่เช่นระดับเดียวที่เข้มงวดหรือ พจนานุกรมสองระดับ

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

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

นอกจากนี้โปรดพิจารณาด้วยว่า Mongo DB เขียนด้วย C ++ และเป็นรุ่นหลักที่สองในขณะที่ Cassandra จำเป็นต้องทำงานบน JVM และรุ่นหลักรุ่นแรกเป็นรุ่นที่เปิดตัวเฉพาะตั้งแต่เมื่อวานนี้ (แต่รุ่น 0.X ได้เปิดตัวในการผลิตของ บริษัท ใหญ่แล้ว).

ในทางกลับกันการออกแบบของ Cassandra นั้นมีพื้นฐานมาจาก Amazon Dynamo และสร้างขึ้นที่แกนหลักเพื่อให้เป็นโซลูชัน High Availibility แต่นั่นไม่ได้เกี่ยวข้องอะไรกับรูปแบบตามคอลัมน์ MongoDB ขยายออกเช่นกัน แต่ไม่สง่างามเท่าคาสซานดรา

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

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