Với công cụ lưu trữ MMAPv1, các bản cập nhật tại chỗ thường được đánh dấu như một chiến lược tối ưu hóa vì các chỉ mục cho một tài liệu trỏ trực tiếp đến các vị trí và phần bù của tệp. Di chuyển tài liệu đến vị trí lưu trữ mới (đặc biệt nếu có nhiều mục nhập chỉ mục cần cập nhật) có chi phí cao hơn cho MMAPv1 so với cập nhật tại chỗ chỉ phải cập nhật các trường đã thay đổi. Xem:Đặc điểm lưu trữ bản ghi trong MMAPv1.
WiredTiger không hỗ trợ cập nhật tại chỗ vì bên trong nó sử dụng MVCC (kiểm soát đồng thời đa vũ trụ), thường được sử dụng bởi các hệ thống quản lý cơ sở dữ liệu. Đây là một cải tiến kỹ thuật đáng kể so với chế độ xem đơn giản trong MMAP và cho phép xây dựng các tính năng nâng cao hơn như mức độ cô lập và giao dịch. Các chỉ mục của WiredTiger có mức định hướng (tham chiếu đến RecordID nội bộ thay vì vị trí tệp &độ lệch), vì vậy việc di chuyển tài liệu ở cấp độ lưu trữ không phải là một điểm khó khăn.
Tuy nhiên, bài viết này cũng nói rằng "Mặc dù [WiredTiger] không cho phép cập nhật tại chỗ, nó vẫn có thể hoạt động tốt hơn MMAP đối với nhiều khối lượng công việc".
Điều đó có nghĩa là mặc dù MMAPv1 có thể có đường dẫn hiệu quả hơn cho các bản cập nhật tại chỗ, nhưng WiredTiger có những ưu điểm khác như nén và cải thiện khả năng kiểm soát đồng thời. Có lẽ bạn có thể tạo một khối lượng công việc chỉ bao gồm các bản cập nhật tại chỗ cho một số tài liệu có thể hoạt động tốt hơn trong MMAPv1, nhưng khối lượng công việc thực tế thường đa dạng hơn. Cách duy nhất để xác nhận tác động đối với một khối lượng công việc nhất định là thử nghiệm trong một môi trường đại diện.
Tuy nhiên, lựa chọn chung của MMAPv1 vs WiredTiger là tranh luận nếu bạn muốn lập kế hoạch cho tương lai:WiredTiger đã là công cụ lưu trữ mặc định kể từ MongoDB 3.2 và một số tính năng sản phẩm mới hơn không được MMAPv1 hỗ trợ. Ví dụ:MMAPv1 không hỗ trợ Majority Read Concern, do đó có nghĩa là nó không thể được sử dụng cho Máy chủ cấu hình thiết lập bản sao (bắt buộc để phân bổ trong MongoDB 3.4+) hoặc Luồng thay đổi (MongoDB 3.6+). MMAPv1 sẽ không được dùng nữa trong bản phát hành chính tiếp theo của MongoDB (4.0) và hiện đang được lên lịch xóa trong MongoDB 4.2.
Những tác động chính xác mà tôi phải biết khi sử dụng WiredTiger là gì? Ví dụ:nếu không có các bản cập nhật tại chỗ thì kích thước cơ sở dữ liệu có phát triển nhanh chóng không?
Kết quả lưu trữ phụ thuộc vào một số yếu tố bao gồm thiết kế giản đồ, khối lượng công việc, cấu hình và phiên bản của máy chủ MongoDB. MMAPv1 và WiredTiger sử dụng các chiến lược phân bổ bản ghi khác nhau, nhưng cả hai sẽ cố gắng sử dụng không gian được phân bổ trước được đánh dấu là miễn phí / có thể tái sử dụng. Nhìn chung, WiredTiger hiệu quả hơn trong việc sử dụng không gian lưu trữ và nó cũng có lợi thế về khả năng nén dữ liệu và chỉ mục. MMAPv1 phân bổ không gian lưu trữ bổ sung để cố gắng tối ưu hóa cho các bản cập nhật tại chỗ và tránh di chuyển tài liệu, mặc dù bạn có thể chọn chiến lược "không có phần đệm" cho các bộ sưu tập mà khối lượng công việc không thay đổi kích thước tài liệu theo thời gian.
Đã có sự đầu tư đáng kể vào việc cải thiện và điều chỉnh WiredTiger cho các khối lượng công việc khác nhau kể từ khi nó được giới thiệu lần đầu tiên trong MongoDB 3.0, vì vậy tôi thực sự khuyến khích thử nghiệm với loạt bản phát hành sản xuất mới nhất để có kết quả tốt nhất. Nếu bạn có câu hỏi cụ thể về thiết kế lược đồ và tăng trưởng bộ nhớ, tôi khuyên bạn nên đăng thông tin chi tiết trên DBA StackExchange để thảo luận.
Tôi cũng biết được rằng WiredTiger trong MongoDB 3.6 đã thêm khả năng lưu trữ delta thay vì ghi lại toàn bộ tài liệu (https://jira.mongodb.org/browse/DOCS-11416). Chính xác thì điều này có nghĩa là gì?
Đây là chi tiết triển khai giúp cải thiện cấu trúc dữ liệu nội bộ của WiredTiger cho một số trường hợp sử dụng. Đặc biệt, WiredTiger trong MongoDB 3.6+ có thể hiệu quả hơn khi làm việc với các thay đổi nhỏ đối với tài liệu lớn (so với các bản phát hành trước). Bộ nhớ cache WiredTiger cần có khả năng trả về nhiều phiên bản tài liệu miễn là chúng được sử dụng bởi các phiên nội bộ đang mở (MVCC, như đã đề cập trước đó), vì vậy, đối với các tài liệu lớn có bản cập nhật nhỏ, việc lưu trữ danh sách các delta có thể hiệu quả hơn. Tuy nhiên, nếu tích tụ quá nhiều delta (hoặc các delta đang thay đổi hầu hết các trường trong tài liệu) thì phương pháp này có thể kém hiệu quả hơn so với việc duy trì nhiều bản sao của tài liệu đầy đủ.
Khi dữ liệu được chuyển vào đĩa thông qua một trạm kiểm soát, một phiên bản đầy đủ của tài liệu vẫn cần được ghi. Nếu bạn muốn tìm hiểu thêm về một số nội dung bên trong, có một loạt video Đường dẫn đến giao dịch trong MongoDB sau sự phát triển của các tính năng để hỗ trợ giao dịch nhiều tài liệu trong MongoDB 4.0.
Ngoài ra, điều tôi không hiểu là ngày nay hầu hết (nếu không phải tất cả) ổ cứng có kích thước khu vực là 4096 byte, vì vậy bạn không thể ghi vào ổ cứng chỉ 4 byte (ví dụ) mà thay vào đó phải ghi toàn bộ khối 4096 byte (vì vậy hãy đọc nó trước, cập nhật 4 byte trong đó và sau đó viết nó). Vì hầu hết các tài liệu thường <4096 byte, điều này có nghĩa là việc viết lại toàn bộ tài liệu là cần thiết trong mọi trường hợp (ngay cả với MMAP). Tôi đã bỏ lỡ điều gì?
Không đi quá sâu vào chi tiết triển khai và cố gắng giải thích tất cả các phần chuyển động liên quan, hãy xem xét cách các phương pháp tiếp cận khác nhau áp dụng cho khối lượng công việc trong đó nhiều tài liệu đang được cập nhật (thay vì ở cấp tài liệu đơn lẻ) cũng như tác động đến việc sử dụng bộ nhớ (trước đây tài liệu được ghi vào đĩa). Tùy thuộc vào các yếu tố như kích thước và độ nén của tài liệu, một khối I / O có thể đại diện cho mọi nơi từ một phần nhỏ của tài liệu (kích thước tối đa 16MB) đến nhiều tài liệu.
Trong MongoDB, quy trình chung là tài liệu được cập nhật ở chế độ xem trong bộ nhớ (ví dụ:bộ đệm WiredTiger) với các thay đổi được lưu giữ trên đĩa ở định dạng tạp chí chỉ phụ thêm nhanh trước khi được chuyển định kỳ vào tệp dữ liệu. Nếu O / S chỉ phải ghi các khối dữ liệu đã thay đổi, thì việc chạm vào ít khối dữ liệu hơn yêu cầu I / O tổng thể ít hơn.
