Tôi có nên tạo id của các tài liệu trong CouchDB hay tôi nên phụ thuộc vào CouchDB để tạo ra nó? Những ưu điểm hay nhược điểm trong các phương pháp này là gì? Có bất kỳ tác động hiệu suất nào đối với bất kỳ tùy chọn nào trong số này không?Điều nào là tốt hơn - id được tạo tự động hoặc gán id thủ công trong tài liệu couchdb?
Không có sự khác biệt nào về CouchDB. Frederick đúng là các id tuần tự nhanh hơn một chút. Nếu bạn truy vấn /_uuids?count=10, bạn sẽ nhận thấy rằng UUID là tuần tự (theo mặc định).
Tuy nhiên, ngay cả với ID ngẫu nhiên, khi bạn chạy nén, tất cả chúng sẽ ở thứ tự "bên phải" bên trong tệp .couch và tại thời điểm đó không có sự khác biệt. Vì vậy, về lâu dài, tôi không thường lo lắng về điều đó.
Điều chính là bạn nên sử dụng hầu hết các id tuần tự. Như this article và bit này của giải thích couchdb book, sử dụng các id ngẫu nhiên dẫn đến kết cấu kém hiệu quả hơn nhiều, cả về tốc độ và không gian được sử dụng trên đĩa.
[wiki chính thức] (http://wiki.apache.org/couchdb/HttpGetUuids) là viết tắt của thuật toán "chuỗi" nếu bạn sử dụng id CouchDB tạo. Trong dự án của chúng tôi, chúng tôi quyết định tạo ID độc lập như sau: ** sha1 (uuid()) ** để giảm các yêu cầu GET tới CouchDB –
Thưa bạn, vấn đề gì nảy sinh do ID tuần tự? Chúng tôi không thể sử dụng ID tuần tự trong URL ứng dụng do các ID khác có thể dự đoán được bằng một ID và sử dụng id dài làm xác thực là không thể, –
Id tự tạo gần như không thể xử lý nếu bạn có hai hoặc nhiều phiên bản ứng dụng được tách riêng. Bởi vì việc đồng bộ hóa giữa các trường hợp khác nhau không phải là tức thời. Một giải pháp cho điều này có thể là có một máy chủ chuyên dụng để tạo ra (hoặc kiểm tra tính khả dụng của) các id, ví dụ bằng cách sử dụng một cơ sở dữ liệu SQL và hoạt động như một cổng để tạo tài liệu. Mặt khác, nếu bạn chỉ có một máy chủ và sẽ không bao giờ cần nhiều hơn nữa, có một lợi thế mà tôi thấy thú vị với các uids tự tạo: vì chúng phải là duy nhất, bạn có thể sử dụng chúng trong url. Ví dụ: lấy sên tiêu đề của bài đăng trên blog là _id.
Hiệu suất-khôn ngoan, các id được tạo của CouchDB khá dài nên nếu id của bạn ngắn hơn, bạn sẽ tiết kiệm được không gian đĩa quan trọng (giả sử bạn có một looot tài liệu).
Bạn có nghĩa là sử dụng BigCouch (nhiều phiên bản) không? –
@DmitrySorin Tôi có nghĩa là thông qua nhân rộng hai chiều. Tôi không biết nhiều về BigCouch nhưng từ những gì tôi vừa đọc, nó có thể giải quyết vấn đề… – Simon
Cả hai câu trả lời ở trên đều nói về PROS của các ID tuần tự. Đây là một vấn đề lớn phát sinh bởi các ID tuần tự.
Khả năng dự đoán của các ID khác trong tài liệu bằng một ID duy nhất.
Do đó, chúng tôi không thể sử dụng ID tuần tự trong URL ứng dụng làm số nhận dạng do các ID khác có thể dự đoán được bằng một ID và sử dụng xác thực url cũng không thể thực hiện được (Thực hiện bởi dịch vụ chia sẻ tệp).
Theo tuần tự bạn có nghĩa là 'tăng theo thứ tự', phải không? Không tăng thêm 1 hoặc bất kỳ số không đổi nào khác? –
Phải. ID là các chuỗi, vì vậy để tăng hiệu suất, bạn muốn mỗi cái "lớn hơn" so với cái kia, sử dụng so sánh chuỗi. Tuy nhiên, như tôi đã nói, khi bạn chạy nén, CouchDB xây dựng một cây cân bằng bất kể ID của bạn, để tăng hiệu suất chỉ là tạm thời. – JasonSmith