Tôi cần lời khuyên về cấu trúc NoSQL/MongoDb và dữ liệu/mô hình

Question

Gần đây tôi đang khám phá Cơ sở dữ liệu NoSQL. Tôi cần một lời khuyên về cách lưu trữ dữ liệu theo cách tối ưu và hiệu quả nhất cho một vấn đề nhất định. Tôi đang nhắm MongoDB, bây giờ. Tuy nhiên nó phải giống với CouchDB.

giả sử chúng ta có những 3 mô hình:

Story: 
id 
title 

User: 
id 
name 

Vote: 
    id 
    story_id 
    user_id 

Tôi muốn có thể yêu cầu các cơ sở dữ liệu các câu hỏi sau:

• Ai đã bình chọn cho chủ đề này?
• Người dùng này đã bỏ phiếu cho điều gì?

Tôi đang tham gia đơn giản khi làm việc với một DB quan hệ. Câu hỏi là, làm thế nào tôi nên lưu trữ dữ liệu cho các đối tượng đó để có hiệu quả nhất.

Ví dụ: nếu tôi lưu trữ đối tượng Bỏ phiếu dưới dạng phần phụ của Câu chuyện, bạn sẽ không dễ dàng nhận được thông tin - "Những gì người dùng đã bỏ phiếu cho".

Answer 1

Tôi khuyên bạn nên lưu trữ phiếu bầu dưới dạng danh sách câu chuyện _id trong mỗi người dùng. Bằng cách đó, bạn có thể tìm hiểu câu chuyện mà người dùng đã bỏ phiếu chỉ bằng cách xem danh sách. Để có được những người dùng đã bình chọn cho một câu chuyện bạn có thể làm một cái gì đó như:

db.users.find({stories: story_id})

nơi story_id là _id của câu chuyện trong câu hỏi. Nếu bạn tạo chỉ mục trên trường stories thì cả hai truy vấn đó sẽ nhanh chóng.

Answer 2

Ok, bạn đã đưa ra một mô hình dữ liệu chuẩn hóa như bạn sẽ làm trong một thiết lập SQL.

Theo hiểu biết của tôi, bạn không làm điều này trong MongoDB. Bạn có thể lưu trữ tài liệu tham khảo, nhưng bạn không vì lý do hiệu suất trong trường hợp chung.

Tôi không phải là chuyên gia trong khu vực NoSQL, nhưng tại sao bạn không đơn giản theo nhu cầu của bạn và lưu trữ người dùng (id) đã bỏ phiếu cho một câu chuyện trong bộ sưu tập truyện và câu chuyện (id) người dùng đã bỏ phiếu trong bộ sưu tập của người dùng?

Answer 3

Trong CouchDB, điều này rất đơn giản. Một cái nhìn phát ra:

function(doc) { 
if(doc.type == "vote") { 
    emit(doc.story_id, doc.user_id); 
} 
} 

xem Một phát ra:

function(doc) { 
if(doc.type == "vote") { 
    emit(doc.user_id, doc.story_id); 
} 
} 

Cả hai đều là các truy vấn cực kỳ nhanh chóng kể từ khi có không tham gia. Nếu bạn cần dữ liệu người dùng hoặc dữ liệu câu chuyện, CouchDB hỗ trợ tìm nạp nhiều tài liệu. Cũng khá nhanh và là một cách để làm một "tham gia".

Answer 4

• đừng lo lắng nếu truy vấn của bạn có hiệu quả cho đến khi nó bắt đầu có vấn đề
• theo xuống dưới báo giá, bạn đang làm nó sai

Con đường tôi đã đi về chuyển đổi ý thức là để quên cơ sở dữ liệu alltogether.Trong thế giới db quan hệ quan hệ bạn luôn phải lo lắng về việc chuẩn hóa dữ liệu và cấu trúc bảng của bạn. Mương tất cả. Chỉ cần bố cục trang web của bạn. Đặt chúng tất cả. Bây giờ hãy nhìn vào chúng. của bạn đã có 2/3 ở đó. Nếu bạn quên quan niệm rằng kích thước cơ sở dữ liệu quan trọng và dữ liệu không được sao chép so với 3/4 ở đó và thậm chí bạn không cần phải viết bất kỳ mã nào! Hãy để chế độ xem của bạn quyết định Mô hình của bạn. Bạn không cần phải chụp đối tượng của mình và biến chúng thành 2 chiều nữa như trong thế giới quan hệ . Bạn có thể lưu trữ đối tượng có hình dạng ngay bây giờ.

how-to-think-in-data-stores-instead-of-databases

Answer 5

Tôi đã nhìn vào MongoDB và CouchDB rất nhiều thời gian gần đây, nhưng cái nhìn sâu sắc của tôi bị hạn chế. Tuy nhiên, khi suy nghĩ về việc lưu trữ các phiếu bầu trong tài liệu câu chuyện, bạn có thể phải lo lắng về việc đạt đến giới hạn kích thước tài liệu 4MB. Thậm chí nếu bạn không, bạn có thể liên tục tăng kích thước của tài liệu đủ để làm cho nó được di chuyển và do đó làm chậm quá trình viết của bạn (xem cách các tài liệu có kích thước trong MongoDB).

Đối với CouchDB, những thứ này khá đơn giản, thanh lịch và khá nhanh khi các chỉ số chế độ xem được tính toán. Cá nhân, tuy nhiên, tôi đã do dự để làm một dự án tương tự trong CouchDB vì điểm chuẩn cho thấy nó dần dần chậm lại đến một mức độ đáng kể khi cơ sở dữ liệu phát triển (và các chỉ số xem tăng). Tôi rất muốn thấy một số điểm chuẩn gần đây cho thấy hiệu suất CouchDB khi tăng kích thước cơ sở dữ liệu. Tôi muốn thử MongoDB hoặc CouchDB, nhưng SQL vẫn có vẻ rất hiệu quả và hợp lý, vì vậy tôi sẽ ở lại với nó cho đến khi dự án phù hợp với sự cám dỗ vừa phải.