Có bất kỳ lợi ích nào khi sử dụng _id tùy chỉnh cho tài liệu trong MongoDB không?

Thuận lợi khi tạo _id của riêng bạn s:

Bạn có thể làm cho chúng thân thiện với con người hơn bằng cách gán các số tăng dần:1 , 2 , 3 , ...
Hoặc bạn có thể làm cho chúng thân thiện với con người hơn bằng cách sử dụng các chuỗi ngẫu nhiên:t3oSKd9q

(Điều đó không chiếm quá nhiều không gian trên màn hình, có thể được chọn từ danh sách và có thể được sao chép theo cách thủ công nếu cần. Tuy nhiên, bạn cần phải đặt nó đủ dài để ngăn chặn sự cấu kết.)
Nếu bạn sử dụng các chuỗi được tạo ngẫu nhiên, chúng sẽ có một phân phối gần như đồng đều, không giống như các ObjectIds mongo tiêu chuẩn, có xu hướng nhóm các bản ghi được tạo vào cùng một thời điểm vào cùng một phân đoạn. (Điều đó có hữu ích hay không thực sự phụ thuộc vào chiến lược sharding của bạn.)
Hoặc bạn có thể muốn tạo _id tùy chỉnh của riêng mình s sẽ nhóm các đối tượng có liên quan vào một phân đoạn, ví dụ:bởi chủ sở hữu, hoặc khu vực địa lý, hoặc kết hợp. (Một lần nữa, điều đó có được mong muốn hay không phụ thuộc vào cách bạn định truy vấn dữ liệu và / hoặc tốc độ bạn sản xuất và lưu trữ dữ liệu đó. Bạn cũng có thể thực hiện việc này bằng cách chỉ định khóa phân đoạn, thay vì _id chính nó. Xem thảo luận bên dưới.)

Ưu điểm khi sử dụng ObjectId s:

ObjectIds rất tốt trong việc tránh va chạm. Nếu bạn tạo _id của riêng mình ngẫu nhiên hoặc đồng thời, khi đó bạn cần tự quản lý rủi ro va chạm.
ObjectIds chứa thời gian tạo của chúng bên trong chúng. Đó có thể là một cách rẻ và dễ dàng để giữ lại ngày tạo tài liệu và sắp xếp tài liệu theo thứ tự thời gian. (Mặt khác, nếu bạn không muốn để lộ / rò rỉ ngày tạo tài liệu, thì bạn không được để lộ ObjectId của nó!)

nanoid mô-đun có thể giúp bạn tạo id ngẫu nhiên ngắn. Họ cũng cung cấp một máy tính điều này có thể giúp bạn chọn độ dài id tốt, tùy thuộc vào số lượng tài liệu / id bạn đang tạo mỗi giờ.

Ngoài ra, tôi đã viết mongoose-create-unique-key để tạo ra rất id ngẫu nhiên ngắn (miễn là bạn đang sử dụng thư viện mongoose).

Chiến lược sắc nét

Tôi sẽ không tự nhận mình là chuyên gia về cách tốt nhất để phân chia dữ liệu, nhưng đây là một số tình huống mà chúng tôi có thể xem xét:

Một đài quan sát thiên văn hoặc máy gia tốc hạt xử lý hàng gigabyte dữ liệu mỗi giây. Khi một sự kiện thú vị được phát hiện, họ có thể muốn lưu trữ một lượng lớn dữ liệu chỉ trong vài giây. Trong trường hợp này, họ có thể muốn phân phối đồng đều các tài liệu trên các phân đoạn, để mỗi phân đoạn sẽ làm việc chăm chỉ như nhau để lưu trữ dữ liệu và không có phân đoạn nào bị quá tải.
Bạn có một lượng lớn dữ liệu và đôi khi bạn cần phải xử lý tất cả một lần. Trong trường hợp này (nhưng tùy thuộc vào thuật toán) một lần nữa có thể mong muốn phân phối đều, để tất cả các phân đoạn có thể làm việc chăm chỉ như nhau trong việc xử lý phần dữ liệu của chúng, trước khi kết hợp các kết quả vào cuối. (Mặc dù trong trường hợp này, chúng tôi có thể dựa vào trình cân bằng của MongoDB, thay vì khóa phân đoạn của chúng tôi, để phân phối đồng đều. Trình cân bằng chạy trong nền sau khi dữ liệu đã được lưu trữ. Sau khi thu thập nhiều dữ liệu, bạn có thể cần phải để nó phân phối lại các khối qua đêm.)
Bạn có một ứng dụng mạng xã hội với lượng lớn dữ liệu, nhưng lần này nhiều người dùng khác nhau đang thực hiện nhiều truy vấn nhẹ chủ yếu liên quan đến dữ liệu của riêng họ, hoặc bạn bè hoặc chủ đề cụ thể của họ. Trong trường hợp này, không có ý nghĩa gì khi liên quan đến mọi phân đoạn bất cứ khi nào người dùng thực hiện một truy vấn nhỏ. Có thể hợp lý nếu phân đoạn theo userId (hoặc theo chủ đề hoặc theo khu vực địa lý) để tất cả tài liệu thuộc về một người dùng sẽ được lưu trữ trên một phân đoạn và khi người dùng đó thực hiện truy vấn, chỉ cần một phân đoạn đó hoạt động. Điều này sẽ để các phân đoạn khác tự do xử lý truy vấn cho những người dùng khác, vì vậy nhiều người dùng có thể được phục vụ cùng một lúc.
Làm sắc nét tài liệu theo thời gian tạo (mà ObjectIds mặc định sẽ cung cấp cho bạn) có thể là mong muốn nếu bạn có nhiều truy vấn nhẹ xem dữ liệu trong các khoảng thời gian tương tự. Ví dụ:nhiều người dùng khác nhau truy vấn các biểu đồ lịch sử khác nhau.

Nhưng nó có thể không được mong muốn như vậy nếu hầu hết người dùng của bạn chỉ truy vấn các tài liệu gần đây nhất (một tình huống phổ biến trên các nền tảng truyền thông xã hội) bởi vì điều đó có nghĩa là một hoặc hai phân đoạn sẽ nhận được hầu hết công việc. Phân phối theo chủ đề hoặc có thể theo khu vực có thể cung cấp phân phối tổng thể phẳng hơn, đồng thời cho phép các tài liệu liên quan tập hợp lại với nhau trên một phân đoạn duy nhất.

Bạn có thể muốn đọc các tài liệu chính thức về chủ đề này: