MongoDB Schema Design - Nhiều tài liệu nhỏ hay ít tài liệu lớn hơn?

Thông tin cơ bản
Tôi đang tạo mẫu chuyển đổi từ cơ sở dữ liệu RDBMS sang MongoDB. Trong khi không chuẩn hóa, có vẻ như tôi có hai lựa chọn, một dẫn đến nhiều (hàng triệu) tài liệu nhỏ hơn hoặc một dẫn đến ít (hàng trăm nghìn) tài liệu lớn hơn.

Nếu tôi có thể chuyển nó thành một dạng tương tự đơn giản, thì đó sẽ là sự khác biệt giữa một bộ sưu tập có ít tài liệu Khách hàng hơn như thế này (bằng Java):

khách hàng hạng {
    tên chuỗi riêng;
    địa chỉ Địa chỉ riêng;
    // mỗi thẻ CreditCard có hàng trăm trường hợp Thanh toán
    private Set <CreditCard> thẻ tín dụng;
}

hoặc một bộ sưu tập với rất nhiều Chứng từ thanh toán như thế này:

thanh toán lớp học {
    khách hàng khách hàng tư nhân;
    thẻ tín dụng CreditCard tư nhân;
    riêng Ngày payDate;
    private float payAmount;
}

Câu hỏi
MongoDB được thiết kế để thích nhiều, nhiều tài liệu nhỏ hay ít tài liệu lớn hơn? Câu trả lời có chủ yếu phụ thuộc vào những truy vấn tôi định chạy không? (tức là Khách hàng X có bao nhiêu thẻ tín dụng? so với số tiền trung bình mà tất cả khách hàng đã trả vào tháng trước là bao nhiêu?)

Tôi đã xem xét xung quanh rất nhiều nhưng tôi không vấp phải bất kỳ phương pháp hay nhất nào về lược đồ MongoDB sẽ giúp tôi trả lời câu hỏi của mình.

Bạn chắc chắn sẽ cần phải tối ưu hóa cho các truy vấn mà bạn đang thực hiện.

Đây là phỏng đoán tốt nhất của tôi dựa trên mô tả của bạn.

Có thể bạn sẽ muốn biết tất cả các Thẻ tín dụng cho từng Khách hàng, vì vậy hãy lưu giữ một mảng trong số đó trong Đối tượng khách hàng. Bạn cũng có thể muốn có tham chiếu Khách hàng cho mỗi lần Thanh toán. Điều này sẽ giữ cho chứng từ Thanh toán tương đối nhỏ.

Đối tượng Thanh toán sẽ tự động có ID và chỉ mục riêng của nó. Có thể bạn cũng sẽ muốn thêm chỉ mục trên tham chiếu Khách hàng.

Điều này sẽ cho phép bạn nhanh chóng tìm kiếm các Khoản thanh toán của Khách hàng mà không cần lưu trữ toàn bộ đối tượng khách hàng mỗi lần.

Nếu bạn muốn trả lời các câu hỏi như "Số tiền trung bình mà tất cả các khách hàng đã trả vào tháng trước", thay vào đó, bạn sẽ muốn có một bản đồ / giảm bớt cho bất kỳ tập dữ liệu lớn nào. Bạn không nhận được phản hồi này "thời gian thực". Bạn sẽ thấy rằng việc lưu trữ "tham chiếu" cho Khách hàng có lẽ là đủ tốt cho việc thu nhỏ bản đồ này.

Vì vậy, để trả lời trực tiếp câu hỏi của bạn: MongoDB được thiết kế để thích nhiều, nhiều tài liệu nhỏ hay ít tài liệu lớn hơn?

MongoDB được thiết kế để tìm các mục nhập được lập chỉ mục rất nhanh chóng. MongoDB rất giỏi trong việc tìm kiếm một vài cây kim trong đống cỏ khô lớn. MongoDB không giỏi lắm trong việc tìm kiếm hầu hết các cây kim trong đống cỏ khô. Vì vậy, xây dựng dữ liệu của bạn xung quanh các trường hợp sử dụng phổ biến nhất của bạn và viết bản đồ / giảm bớt công việc cho các trường hợp sử dụng hiếm hơn.

Theo tài liệu riêng của MongoDB, có vẻ như nó được thiết kế cho nhiều tài liệu nhỏ.

Từ các phương pháp hay nhất về hiệu suất cho MongoDB :

Kích thước tối đa cho tài liệu trong MongoDB là 16 MB. Trong thực tế, hầu hết các tài liệu có kích thước vài kilobyte hoặc nhỏ hơn. Coi tài liệu giống như các hàng trong bảng hơn là chính các bảng đó. Thay vì duy trì danh sách các bản ghi trong một tài liệu, hãy biến mỗi bản ghi thành một tài liệu.

Từ 6 quy tắc ngón tay cái cho thiết kế lược đồ MongoDB: Phần 1 :

Lập mô hình từ một đến một

Ví dụ về “một đến một” có thể là địa chỉ của một người. Đây là một trường hợp sử dụng tốt để nhúng - bạn sẽ đặt các địa chỉ trong một mảng bên trong đối tượng Person của bạn.

Một-nhiều

Ví dụ về “một-nhiều” có thể là các bộ phận của một sản phẩm trong hệ thống đặt hàng bộ phận thay thế. Mỗi sản phẩm có thể có tới vài trăm bộ phận thay thế, nhưng không bao giờ nhiều hơn vài nghìn hoặc lâu hơn. Đây là một trường hợp sử dụng tốt để tham chiếu - bạn sẽ đặt các ObjectID của các bộ phận trong một mảng trong tài liệu sản phẩm.

One-to-Squillions

Ví dụ về “một-đến-squillions” có thể là một hệ thống ghi nhật ký sự kiện thu thập các thông báo nhật ký cho các máy khác nhau. Bất kỳ máy chủ nhất định nào cũng có thể tạo đủ thông báo để làm tràn kích thước tài liệu 16 MB, ngay cả khi tất cả những gì bạn lưu trữ trong mảng là ObjectID. Đây là trường hợp sử dụng cổ điển cho “tham chiếu phụ huynh” - bạn sẽ có một tài liệu cho máy chủ lưu trữ và sau đó lưu trữ ObjectID của máy chủ lưu trữ trong tài liệu cho thông báo nhật ký.

Các tài liệu phát triển đáng kể theo thời gian có thể là quả bom hẹn giờ. Băng thông mạng và việc sử dụng RAM có thể sẽ trở thành những điểm nghẽn có thể đo lường được, buộc bạn phải bắt đầu lại.

Đầu tiên, hãy xem xét hai tập hợp: Khách hàng và Thanh toán. Do đó, hạt khá nhỏ: một chứng từ cho mỗi lần thanh toán.

Tiếp theo, bạn phải quyết định cách lập mô hình thông tin tài khoản, chẳng hạn như thẻ tín dụng. Hãy xem xét liệu tài liệu khách hàng có chứa các mảng thông tin tài khoản hay bạn cần một bộ sưu tập Tài khoản mới.

Nếu tài liệu tài khoản tách biệt với tài liệu khách hàng, việc tải tất cả tài khoản cho một khách hàng vào bộ nhớ yêu cầu tìm nạp nhiều tài liệu. Điều đó có thể chuyển thành việc sử dụng thêm bộ nhớ, I / O, băng thông và CPU. Điều đó ngay lập tức có nghĩa là Thu thập tài khoản là một ý tưởng tồi?

Quyết định của bạn ảnh hưởng đến chứng từ thanh toán. Nếu thông tin tài khoản được nhúng trong tài liệu khách hàng, bạn sẽ tham chiếu nó như thế nào? Các tài liệu tài khoản riêng biệt có thuộc tính _id riêng. Với thông tin tài khoản được nhúng, ứng dụng của bạn sẽ tạo id mới cho tài khoản hoặc sử dụng các thuộc tính của tài khoản (ví dụ: số tài khoản) cho khóa.

Một chứng từ thanh toán có thể thực sự chứa tất cả các khoản thanh toán được thực hiện trong khung thời gian cố định (ví dụ: ngày?). Sự phức tạp như vậy sẽ ảnh hưởng đến tất cả các mã đọc và ghi chứng từ thanh toán. Tối ưu hóa sớm có thể gây nguy hiểm cho các dự án.

Giống như chứng từ tài khoản, các khoản thanh toán dễ dàng được tham chiếu miễn là chứng từ thanh toán chỉ chứa một khoản thanh toán. Một loại tài liệu mới, ví dụ: tín dụng, có thể tham chiếu đến một khoản thanh toán. Nhưng bạn sẽ tạo bộ sưu tập Tín dụng hay bạn sẽ nhúng thông tin tín dụng vào bên trong thông tin thanh toán? Điều gì sẽ xảy ra nếu sau này bạn cần tham chiếu một khoản tín dụng?

Tóm lại, tôi đã thành công với rất nhiều tài liệu nhỏ và nhiều bộ sưu tập. Tôi triển khai các tham chiếu với _id và chỉ với _id. Vì vậy, tôi không lo lắng về việc các tài liệu ngày càng tăng sẽ phá hủy ứng dụng của tôi. Lược đồ dễ hiểu và dễ lập chỉ mục vì mỗi thực thể có bộ sưu tập riêng. Các thực thể quan trọng không ẩn bên trong các tài liệu khác.

Tôi rất muốn nghe về những phát hiện của bạn. Chúc may mắn!