Làm cách nào để bạn theo dõi quan hệ bản ghi trong NoSQL?

Tôi đang cố gắng tìm ra các khóa và chỉ mục ngoại tương đương trong cơ sở dữ liệu NoSQL KVP hoặc Document. Vì không có bảng tổng hợp (để thêm các khóa đánh dấu mối quan hệ giữa hai đối tượng) nên tôi thực sự bối rối về cách bạn có thể truy xuất dữ liệu theo cách hữu ích cho các trang web bình thường.

Giả sử tôi có một người dùng, và người dùng này để lại nhiều bình luận trên khắp trang web. Cách duy nhất tôi có thể nghĩ ra để theo dõi nhận xét của người dùng đó là

1. Nhúng chúng vào đối tượng người dùng (có vẻ khá vô dụng)
2. Tạo và duy trì một user_id:commentsgiá trị chứa danh sách khóa của mỗi nhận xét [nhận xét: 34, nhận xét: 197, v.v.] để tôi có thể tìm nạp chúng khi cần.

Tuy nhiên, lấy ví dụ thứ hai, bạn sẽ sớm gặp phải một bức tường gạch khi bạn sử dụng nó để theo dõi những thứ khác, chẳng hạn như khóa có tên "active_comments" có thể chứa 30 triệu id trong đó, khiến cho việc truy vấn mỗi trang phải tốn một TON chỉ để biết một số gần đây bình luận tích cực. Nó cũng sẽ rất dễ xảy ra các điều kiện đua vì nhiều trang có thể cố gắng cập nhật nó cùng một lúc.

Làm cách nào để theo dõi các quan hệ như sau trong cơ sở dữ liệu NoSQL?

• Tất cả nhận xét của người dùng
• Tất cả các bình luận hoạt động
• Tất cả các bài đăng được gắn thẻ [từ khóa]
• Tất cả học sinh trong một câu lạc bộ - hoặc tất cả các câu lạc bộ mà một học sinh tham gia

Hay tôi đang nghĩ về điều này không đúng?

Tất cả các câu trả lời cho cách lưu trữ nhiều-nhiều liên kết theo "cách NoSQL" giảm xuống cùng một thứ: lưu trữ dữ liệu dư thừa.

Trong NoSQL, bạn không thiết kế cơ sở dữ liệu của mình dựa trên mối quan hệ giữa các thực thể dữ liệu. Bạn thiết kế cơ sở dữ liệu của mình dựa trên các truy vấn mà bạn sẽ chạy với nó. Sử dụng cùng tiêu chí mà bạn sẽ sử dụng để chuẩn hóa cơ sở dữ liệu quan hệ: nếu dữ liệu quan trọng hơn để có sự gắn kết (hãy nghĩ về các giá trị trong danh sách được phân tách bằng dấu phẩy thay vì bảng chuẩn hóa), thì hãy làm theo cách đó.

Nhưng điều này chắc chắn sẽ tối ưu hóa cho một loại truy vấn (ví dụ: nhận xét của bất kỳ người dùng nào cho một bài báo nhất định) với chi phí của các loại truy vấn khác (nhận xét cho bất kỳ bài viết nào của một người dùng nhất định). Nếu ứng dụng của bạn có nhu cầu để cả hai loại truy vấn được tối ưu hóa như nhau, bạn không nên chuẩn hóa lại. Và tương tự như vậy, bạn không nên sử dụng giải pháp NoSQL nếu bạn cần sử dụng dữ liệu theo cách quan hệ.

Có một rủi ro với việc không chuẩn hóa và dư thừa là các bộ dữ liệu dư thừa sẽ không đồng bộ với nhau. Đây được gọi là sự bất thường . Khi bạn sử dụng cơ sở dữ liệu quan hệ được chuẩn hóa, RDBMS có thể ngăn chặn sự bất thường. Trong cơ sở dữ liệu không chuẩn hóa hoặc trong NoSQL, bạn có trách nhiệm viết mã ứng dụng để ngăn chặn sự bất thường.

Người ta có thể nghĩ rằng sẽ thật tuyệt khi một cơ sở dữ liệu NoSQL thực hiện công việc khó khăn trong việc ngăn chặn sự bất thường cho bạn. Có một mô hình có thể làm được điều này - mô hình quan hệ.

Cách tiếp cận couchDB đề xuất phát ra các lớp nội dung phù hợp trong giai đoạn lập bản đồ và tóm tắt nó lại. Vì vậy, bạn có thể ánh xạ tất cả các nhận xét và phát ra 1cho người dùng nhất định và sau đó chỉ in ra những nhận xét đó. Tuy nhiên, nó sẽ yêu cầu rất nhiều dung lượng lưu trữ trên đĩa để xây dựng chế độ xem liên tục của tất cả dữ liệu có thể theo dõi trong couchDB. btw họ cũng có trang wiki này về các mối quan hệ: http://wiki.apache.org/couchdb/EntityRelationship .

Mặt khác, Riak có công cụ để xây dựng quan hệ. Nó là liên kết. Bạn có thể nhập địa chỉ của tài liệu được liên kết (tại đây nhận xét) vào tài liệu 'gốc' (tài liệu người dùng tại đây). Nó có một mẹo. Nếu nó được phân phối, nó có thể được sửa đổi cùng một lúc ở nhiều địa điểm. Nó sẽ gây ra xung đột và kết quả là cây đồng hồ vectơ rất lớn: / .. không quá tệ, không quá tốt.

Riak cũng có một 'cơ chế' khác. Nó có không gian tên khóa 2 lớp, được gọi là thùng và khóa. Vì vậy, ví dụ sinh viên, Nếu chúng ta có câu lạc bộ A, B và C và sinh viên StudentX, StudentY, bạn có thể duy trì quy ước sau:

{ Key = {ClubA, StudentX}, Value = true }, 
{ Key = {ClubB, StudentX}, Value = true }, 
{ Key = {ClubA, StudentY}, Value = true }

và để đọc mối quan hệ, chỉ cần liệt kê các khóa trong các nhóm nhất định. Có gì sai với điều đó? Thật là chậm chạp. Nhóm niêm yết chưa bao giờ được ưu tiên cho riak. Nó đang trở nên tốt hơn và tốt hơn tho. btw. bạn không lãng phí bộ nhớ vì ví dụ này {true}có thể được liên kết với một hồ sơ đầy đủ của StudentX hoặc Y (ở đây không thể xảy ra xung đột).

Như bạn thấy, NoSQL! = NoSQL. Bạn cần phải xem xét việc thực hiện cụ thể và kiểm tra nó cho chính mình.

Được đề cập trước Cửa hàng cột trông có vẻ phù hợp với các mối quan hệ .. nhưng tất cả phụ thuộc vào nhu cầu A và C và P của bạn;) Nếu bạn không cần A và bạn có ít hơn Peta byte, hãy tiếp tục với MySql hoặc Postgres.

chúc may mắn

1. user: userid: comments là một cách tiếp cận hợp lý - hãy nghĩ về nó tương đương với một chỉ mục cột trong SQL, với yêu cầu bổ sung là bạn không thể truy vấn trên các cột không được lập chỉ mục.

2. Đây là lúc bạn cần suy nghĩ về các yêu cầu của mình. Một danh sách với 30 triệu mục không phải là không hợp lý vì nó chậm, mà vì nó không thực tế để bao giờ làm bất cứ điều gì với nó. Nếu yêu cầu thực sự của bạn là hiển thị một số nhận xét gần đây, bạn nên giữ một danh sách rất ngắn được cập nhật bất cứ khi nào nhận xét được thêm vào - hãy nhớ rằng NoSQL không có yêu cầu chuẩn hóa. Điều kiện cuộc đua là một vấn đề với danh sách trong kho giá trị khóa cơ bản nhưng nhìn chung hoặc nền tảng của bạn hỗ trợ danh sách đúng cách, bạn có thể làm gì đó với khóa hoặc bạn không thực sự quan tâm đến các bản cập nhật không thành công.

3. Tương tự như đối với nhận xét của người dùng - tạo một từ khóa chỉ mục: bài đăng

4. Tương tự như vậy - có thể là danh sách các câu lạc bộ như một tài sản của sinh viên và một chỉ mục trên lĩnh vực đó để thu hút tất cả các thành viên của một câu lạc bộ

Bạn có

"user": {
    "userid": "unique value",
    "category": "student",
    "metainfo": "yada yada yada",
    "clubs": ["archery", "kendo"]
}

"comments": {
    "commentid": "unique value",
    "pageid": "unique value",
    "post-time": "ISO Date",
    "userid": "OP id -> THIS IS IMPORTANT"
}

"page": {
    "pageid": "unique value",
    "post-time": "ISO Date",
    "op-id": "user id",
    "tag": ["abc", "zxcv", "qwer"]
}

Trong cơ sở dữ liệu quan hệ, điều bình thường phải làm trong quan hệ một-nhiều là chuẩn hóa dữ liệu. Đó cũng là điều bạn sẽ làm trong cơ sở dữ liệu NoSQL. Chỉ cần lập chỉ mục các trường mà bạn sẽ tìm nạp thông tin.

Ví dụ: các chỉ mục quan trọng đối với bạn là

• Comment.UserID
• Nhận xét.PageID
• Comment.PostTime
• Trang.Tag []

Nếu bạn đang sử dụng NosDB (Cơ sở dữ liệu NoSQL dựa trên .NET có hỗ trợ SQL) thì các truy vấn của bạn sẽ như thế nào

 SELECT * FROM Comments WHERE userid = ‘That user’;

 SELECT * FROM Comments WHERE pageid = ‘That user’;

 SELECT * FROM Comments WHERE post-time > DateTime('2016, 1, 1');

 SELECT * FROM Page WHERE tag = 'kendo'

Kiểm tra tất cả các loại truy vấn được hỗ trợ từ bảng hoặc tài liệu gian lận SQL của chúng .