NoSQL hướng cột khác với hướng tài liệu như thế nào?

Ba loại cơ sở dữ liệu NoSQL mà tôi đã đọc về là khóa-giá trị, hướng cột và hướng tài liệu.

Khóa-giá trị khá dễ hiểu - một khóa có giá trị đơn giản.

Tôi đã thấy cơ sở dữ liệu hướng tài liệu được mô tả giống như khóa-giá trị, nhưng giá trị có thể là một cấu trúc, như một đối tượng JSON. Mỗi "tài liệu" có thể có tất cả, một số hoặc không có khóa nào giống với khóa khác.

Định hướng cột dường như rất giống với định hướng tài liệu ở chỗ bạn không chỉ định cấu trúc.

Vậy sự khác biệt giữa hai cái này là gì, và tại sao bạn lại sử dụng cái này hơn cái kia?

Tôi đã đặc biệt xem xét MongoDB và Cassandra. Về cơ bản, tôi cần một cấu trúc động có thể thay đổi, nhưng không ảnh hưởng đến các giá trị khác. Đồng thời, tôi cần có thể tìm kiếm / lọc các khóa cụ thể và chạy báo cáo. Với CAP, AP là quan trọng nhất đối với tôi. Dữ liệu "cuối cùng" có thể được đồng bộ hóa giữa các nút, miễn là không có xung đột hoặc mất dữ liệu. Mỗi người dùng sẽ nhận được "bảng" của riêng họ.

Trong Cassandra, mỗi hàng (được đánh địa chỉ bằng một khóa) chứa một hoặc nhiều "cột". Bản thân các cột là cặp khóa-giá trị. Tên cột không cần được xác định trước, tức là cấu trúc không cố định. Các cột trong một hàng được lưu trữ theo thứ tự được sắp xếp theo các khóa (tên) của chúng.

Trong một số trường hợp, bạn có thể có số lượng cột rất lớn trong một hàng (ví dụ: hoạt động như một chỉ mục để kích hoạt các loại truy vấn cụ thể). Cassandra có thể xử lý các cấu trúc lớn như vậy một cách hiệu quả và bạn có thể truy xuất các dải cột cụ thể.

Có một cấp cấu trúc khác (không được sử dụng phổ biến) được gọi là siêu cột, trong đó một cột chứa các cột (con) lồng nhau.

Bạn có thể coi cấu trúc tổng thể như một bảng băm / từ điển lồng nhau, với 2 hoặc 3 cấp độ khóa.

Họ cột bình thường:

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

Họ siêu cột:

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

Ngoài ra còn có các cấu trúc cấp cao hơn - họ cột và không gian khóa - có thể được sử dụng để phân chia hoặc nhóm dữ liệu của bạn lại với nhau.

Xem thêm Câu hỏi này: Cassandra: Cột con là gì

Hoặc các liên kết mô hình hóa dữ liệu từ http://wiki.apache.org/cassandra/ArticlesAndPresentations

Re: so sánh với cơ sở dữ liệu hướng tài liệu - cơ sở dữ liệu sau này thường chèn toàn bộ tài liệu (thường là JSON), trong khi trong Cassandra, bạn có thể giải quyết các cột hoặc siêu cột riêng lẻ và cập nhật chúng một cách riêng lẻ, tức là chúng hoạt động ở một mức độ chi tiết khác. Mỗi cột có dấu thời gian / phiên bản riêng biệt (được sử dụng để điều chỉnh các bản cập nhật trên toàn bộ cụm phân tán).

Giá trị cột Cassandra chỉ là byte, nhưng có thể được nhập dưới dạng ASCII, văn bản UTF8, số, ngày, v.v.

Tất nhiên, bạn có thể sử dụng Cassandra như một kho lưu trữ tài liệu nguyên thủy bằng cách chèn các cột chứa JSON - nhưng bạn sẽ không nhận được tất cả các tính năng của một cửa hàng hướng tài liệu thực.

Sự khác biệt chính là kho lưu trữ tài liệu (ví dụ: MongoDB và CouchDB) cho phép các tài liệu phức tạp tùy ý, tức là các tài liệu con trong các tài liệu con, danh sách có tài liệu, v.v. trong khi các kho lưu trữ cột (ví dụ: Cassandra và HBase) chỉ cho phép một định dạng cố định, ví dụ: một cấp nghiêm ngặt hoặc từ điển hai cấp.

Trong "insert", để sử dụng các từ rdbms, Document-based phù hợp và dễ hiểu hơn. Lưu ý hơn cassandra cho phép bạn đạt được sự nhất quán với khái niệm về túc số, nhưng điều đó sẽ không áp dụng cho tất cả các hệ thống dựa trên cột và điều đó làm giảm tính khả dụng. Trên hệ thống nặng ghi một lần / đọc thường xuyên, hãy chuyển sang MongoDB. Cũng nên cân nhắc nếu bạn luôn có kế hoạch đọc toàn bộ cấu trúc của đối tượng. Hệ thống dựa trên tài liệu được thiết kế để trả lại toàn bộ tài liệu khi bạn lấy nó và không mạnh lắm trong việc trả lại các phần của toàn bộ hàng.

Các hệ thống dựa trên cột như Cassandra tốt hơn so với dựa trên tài liệu trong "cập nhật". Bạn có thể thay đổi giá trị của một cột mà không cần đọc hàng chứa nó. Việc ghi không thực sự cần thiết phải được thực hiện trên cùng một máy chủ, một hàng có thể được chứa trên nhiều tệp của nhiều máy chủ. Trên hệ thống dữ liệu phát triển nhanh chóng khổng lồ, hãy sử dụng Cassandra. Cũng nên cân nhắc nếu bạn dự định có một lượng lớn dữ liệu cho mỗi khóa và không cần tải tất cả chúng ở mỗi truy vấn. Trong "select", Cassandra chỉ cho phép bạn tải cột bạn cần.

Cũng nên xem xét rằng Mongo DB được viết bằng C ++ và đang ở bản phát hành chính thứ hai, trong khi Cassandra cần chạy trên JVM và bản phát hành chính đầu tiên của nó chỉ là ứng cử viên phát hành kể từ ngày hôm qua (nhưng các bản phát hành 0.X đã chuyển sang sản xuất công ty lớn rồi).

Mặt khác, thiết kế của Cassandra một phần dựa trên Amazon Dynamo và nó được xây dựng cốt lõi để trở thành một giải pháp Tính khả dụng cao, nhưng điều đó không liên quan gì đến định dạng dựa trên cột. MongoDB cũng mở rộng quy mô, nhưng không duyên dáng như Cassandra.

Tôi muốn nói rằng sự khác biệt chính là cách mỗi loại DB này lưu trữ dữ liệu một cách vật lý.
Với các loại cột, dữ liệu được lưu trữ bởi các cột có thể cho phép các hoạt động / truy vấn tổng hợp hiệu quả trên một cột cụ thể.
Với các loại tài liệu, toàn bộ tài liệu được lưu trữ hợp lý ở một nơi và thường được truy xuất toàn bộ (không thể tổng hợp hiệu quả trên "cột" / "trường").

Điều khó hiểu là một "hàng" cột rộng có thể dễ dàng được biểu diễn dưới dạng tài liệu, nhưng, như đã đề cập, chúng được lưu trữ khác nhau và được tối ưu hóa cho các mục đích khác nhau.