Tug là chuột phải vào và cho phép tôi thêm một số quan điểm là tốt.
Một xô có thể được coi quan hệ gần gũi nhất đối với (mặc dù không chính xác) một "cơ sở dữ liệu instantiation" trong thế giới RDMS. Sẽ có nhiều bảng/lược đồ trong "cơ sở dữ liệu" đó và tất cả những bảng đó có thể được kết hợp trong một nhóm. Hãy suy nghĩ về một nhóm như một nhóm dữ liệu hợp lý mà tất cả chia sẻ một số thông số cấu hình chung (hạn ngạch RAM, số bản sao, v.v.) và bạn chỉ cần chia dữ liệu thành nhiều nhóm khi bạn cần một số bộ dữ liệu nhất định được kiểm soát riêng biệt. Các lý do khác liên quan đến khối lượng công việc rất khác nhau đối với các tập dữ liệu khác nhau hoặc mong muốn có thể theo dõi khối lượng công việc cho các tập dữ liệu đó một cách riêng biệt.
Một số ví dụ:
-Tôi muốn kiểm soát hành vi bộ nhớ đệm cho một bộ dữ liệu khác với nhau. Ví dụ, nhiều khách hàng có một "phiên" xô mà họ muốn luôn luôn trong RAM trong khi họ có thể có một lớn hơn, "hồ sơ người dùng" xô mà không cần tất cả các dữ liệu được lưu trữ trong bộ nhớ RAM. Về mặt kỹ thuật, hai tập dữ liệu này có thể nằm trong một nhóm và cho phép Couchbase thông minh về dữ liệu nào cần lưu trong RAM, nhưng bạn không có nhiều bảo đảm hoặc kiểm soát dữ liệu phiên sẽ không bị đẩy ra ... nó trong xô riêng của nó cho phép bạn thực thi điều đó. Nó cũng mang lại cho bạn lợi ích bổ sung khi có thể giám sát lưu lượng truy cập đó một cách riêng biệt.
-Tôi muốn có một số dữ liệu được lặp lại nhiều lần hơn những người khác. Mặc dù chúng tôi thường chỉ đề xuất một bản sao ở hầu hết các cụm, đôi khi người dùng của chúng tôi chọn một số tập dữ liệu nhất định mà họ muốn sao chép thêm một thời gian. Điều này có thể được kiểm soát thông qua các nhóm riêng biệt.
-Along theo đường cùng, tôi chỉ muốn có một số dữ liệu được sao chép đến một cụm/trung tâm dữ liệu. Điều này cũng được kiểm soát trên mỗi nhóm và do đó dữ liệu có thể được chia thành một nhóm riêng biệt.
-Khi bạn có sự khác biệt khá lớn về khối lượng công việc (đặc biệt là khoảng số lượng ghi) cho tập dữ liệu nhất định, bắt đầu có ý nghĩa từ phối cảnh chế độ xem/chỉ mục để tách dữ liệu thành một nhóm riêng biệt. Tôi đề cập đến điều này bởi vì nó là sự thật, nhưng tôi cũng muốn rõ ràng rằng nó không phải là trường hợp phổ biến. Bạn nên sử dụng phương pháp này sau khi bạn xác định một vấn đề, không phải trước đây bởi vì bạn nghĩ rằng bạn có thể.
Về điểm cuối cùng này, mỗi lần ghi vào thùng sẽ được chọn bởi công cụ lập chỉ mục nhưng bằng cách sử dụng các loại tài liệu trong JSON, bạn có thể hủy bỏ quá trình xử lý một tài liệu nhất định rất nhanh chóng một tác động bất lợi để có nhiều dữ liệu đến mà không áp dụng cho một số lượt xem nhất định. Nếu bạn không nhớ, tôi đặc biệt tò mò về những phần nào của tài liệu ngụ ý khác vì đó chắc chắn không phải là ý định của chúng tôi.
Vì vậy, nói chung, chúng tôi thấy hầu hết các triển khai với một số ít các xô (2-3) và chỉ có một vài trở lên 5.Giới hạn 10 của chúng tôi xuất phát từ một số chi phí CPU và đĩa IO đã biết của việc theo dõi thống kê nội bộ của chúng tôi (tải hoặc thiếu trên một thùng không quan trọng ở đây). Chúng tôi chắc chắn có kế hoạch giảm chi phí này với các bản phát hành trong tương lai, nhưng điều đó vẫn không thay đổi đề xuất của chúng tôi chỉ có một vài nhóm. Những lợi thế của việc có thể kết hợp nhiều "lược đồ" thành một nhóm lôgíc duy nhất và áp dụng các khung nhìn/chỉ mục trên đó vẫn tồn tại bất kể.
Hiện tại, chúng tôi đang trong quá trình đưa ra các hướng dẫn và kích thước định hướng cụ thể hơn (tôi đã viết hai blog đầu tiên đó là khoảng cách dừng cho đến khi chúng tôi thực hiện).
Cách tiếp cận ban đầu, bạn muốn thử và giữ số lượng tài liệu thiết kế khoảng 4 vì theo mặc định, chúng tôi xử lý tối đa 4 tài liệu song song. Bạn có thể tăng số này, nhưng nó phải được so khớp bằng khả năng tăng dung lượng đĩa cứng của CPU và IO. Sau đó, bạn sẽ muốn giữ số lượt xem trong mỗi tài liệu tương đối thấp, có thể dưới 10, vì chúng được xử lý theo chuỗi.
Gần đây, tôi đã làm việc với một người dùng có số lượt xem khá lớn (khoảng 8 tài liệu thiết kế và một số dd có gần 20 lượt xem) và chúng tôi có thể giảm đáng kể việc này bằng cách kết hợp nhiều lượt xem thành một. Rõ ràng nó phụ thuộc rất nhiều ứng dụng, nhưng bạn nên cố gắng tạo ra nhiều "truy vấn" khác nhau của một chỉ mục. Sử dụng giảm, khóa tiền tố (trong lượt xem) và đối chiếu, tất cả được kết hợp với các truy vấn nhóm và nhóm khác nhau có thể tạo một chỉ mục duy nhất có thể xuất hiện đông đúc lúc đầu nhưng thực sự rất linh hoạt.
Tài liệu thiết kế ít hơn và chế độ xem bạn có, không gian đĩa ít hơn, tài nguyên IO và CPU bạn sẽ cần. Sẽ không bao giờ có một viên đạn ma thuật hay một số hướng dẫn nhanh và khó. Cuối cùng, YMMV và thử nghiệm trên tập dữ liệu của riêng bạn tốt hơn bất kỳ phản hồi nhiều trang nào mà tôi có thể viết ;-)
Xin vui lòng liên hệ trực tiếp với chúng tôi nếu bạn có câu hỏi cụ thể về trường hợp sử dụng cụ thể của bạn mà bạn không muốn xuất bản.
Perry
Danh sách tiêu chí rất tốt về cách chia nhỏ các nhóm. Cảm ơn. Phần ngụ ý chi phí khi xử lý nhiều loại tài liệu trong một nhóm là http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-writing-bestpractice.html phần "Sử dụng loại tài liệu": "Theo thời gian, điều này có thể thêm chi phí đáng kể cho quy trình xây dựng chế độ xem". và "có thể dễ dàng hơn từ góc độ ứng dụng để sử dụng các nhóm riêng biệt cho các đối tượng và người chơi" –
@ perry-krug điểm rất thú vị về việc tối ưu hóa các chế độ xem kết hợp chúng thành một. Bất kỳ hướng dẫn/ví dụ để hiển thị một kỹ thuật có thể? Cảm ơn. – loretoparisi