Cơ sở dữ liệu hiện đại phải có khả năng nắm bắt và phản ứng với dữ liệu khi chúng lưu chuyển trong thời gian thực. Điều này giải thích tại sao MongoDB có một tính năng gọi là MongoDB Change Streams chịu trách nhiệm thu thập và phản hồi dữ liệu trong thời gian thực. Change Streams là một tính năng được giới thiệu để truyền thông tin từ ứng dụng đến cơ sở dữ liệu trong thời gian thực. Nó dựa trên một khung tổng hợp giám sát các bộ sưu tập và cho phép các thay đổi xảy ra trong cơ sở dữ liệu và bộ sưu tập cơ sở dữ liệu. Ngoài ra, MongoDB Change Stream có thể thu thập dữ liệu từ các cảm biến IOT và cập nhật các báo cáo như thay đổi dữ liệu hoạt động trong doanh nghiệp. Blog này sẽ mở bài diễn thuyết về Luồng thay đổi MongoDB và thay đổi các đề xuất trong quá trình sản xuất.
MongoDB Thay đổi Luồng và Bộ sưu tập Bỏ qua
Đổi tên hoặc loại bỏ cơ sở dữ liệu hoặc bộ sưu tập sẽ dẫn đến việc đóng con trỏ nếu có một luồng thay đổi mở đang hoạt động chống lại bộ sưu tập đã bỏ. Đổi tên hoặc bỏ một bộ sưu tập làm cho con trỏ có FullDocument:updateLookup để trả về null trên bất kỳ tài liệu tra cứu nào. Một lỗi xảy ra nếu một người cố gắng tiếp tục sau khi làm rơi cơ sở dữ liệu với một dòng thay đổi đang chạy.
Ngoài ra, tất cả các thay đổi trong dữ liệu được thực hiện trước khi đổi tên tập hợp có luồng thay đổi đang chạy sẽ bị mất. Giới hạn tài liệu cho dòng Thay đổi vẫn là 16MB BSON; do đó, các tài liệu lớn hơn 16MB không được chấp nhận. Nếu một người cố gắng làm việc với tài liệu lớn hơn 16MB, thông báo không thành công và tài liệu đó được thay thế bằng tài liệu khác đáp ứng giới hạn đã đặt.
Khi một bộ sưu tập hoặc cơ sở dữ liệu có các luồng thay đổi được mở trên nó bị xóa hoặc đổi tên, các con trỏ của luồng thay đổi có xu hướng đóng lại khi chúng tiến đến điểm đó trong oplog. Nếu bạn thay đổi con trỏ luồng bằng tài liệu đầy đủ, tùy chọn updateLookup có thể trả về giá trị rỗng cho tài liệu tìm kiếm.
Do đó, nỗ lực tiếp tục các luồng thay đổi đối với một tập hợp đã bị loại bỏ sẽ dẫn đến lỗi. Bất kỳ sự kiện thay đổi dữ liệu nào xảy ra trong tập hợp giữa sự kiện cuối cùng của luồng thay đổi được ghi lại và sự kiện giảm tập hợp sẽ bị mất.
Thay đổi tài liệu phản hồi luồng phải tuân theo giới hạn tài liệu BSON 16 MB. Tùy thuộc vào kích thước của tài liệu trong bộ sưu tập mà bạn đang mở luồng thay đổi, thông báo có thể không thành công nếu tài liệu thông báo kết quả lớn hơn 16 MB. Một ví dụ điển hình là các thao tác cập nhật trên các luồng thay đổi được thiết lập để trả về một tài liệu được cập nhật đầy đủ hoặc thay thế / chèn các quy trình bằng tài liệu ở mức giới hạn hoặc thấp hơn một chút so với giới hạn.
Tập bản sao và luồng thay đổi MongoDB
Tập bản sao MongoDB là tập hợp các quy trình trong MongoDB có tập dữ liệu không thay đổi; nghĩa là, tập dữ liệu vẫn được giữ nguyên. Trong trường hợp tập hợp bản sao có thành viên trọng tài, các luồng thay đổi có thể vẫn ở trạng thái không hoạt động nếu không có đủ thành viên mang dữ liệu để phần lớn không thể thực hiện các hoạt động. Ví dụ, chúng ta có thể xem xét một tập hợp bản sao có ba thành viên với hai nút chứa dữ liệu cùng với một trọng tài viên. Trong trường hợp thứ cấp xảy ra sự cố, ví dụ:do lỗi hoặc do nâng cấp hoặc bảo trì, thì các hoạt động ghi sẽ không thể được cam kết đa số. Luồng thay đổi sẽ vẫn mở nhưng sẽ không gửi thông báo. Trong trường hợp hiện tại, ứng dụng có thể bắt kịp tất cả các hoạt động đã diễn ra trong khoảng thời gian ngừng hoạt động, miễn là hoạt động cuối cùng mà ứng dụng nhận được vẫn nằm trong oplog của tập hợp bản sao cụ thể đó. Ngoài ra, lệnh rs.printReplicationInfo () được sử dụng để lấy dữ liệu từ oplog; dữ liệu được truy xuất bao gồm một loạt các hoạt động và kích thước của oplog.
Nếu thời gian ngừng hoạt động được ước tính đáng kể, chẳng hạn như để thực hiện nâng cấp hoặc trong trường hợp xảy ra thảm họa, thì việc tăng kích thước nhật ký sẽ là lựa chọn tốt nhất để duy trì các hoạt động trong khoảng thời gian lớn hơn thời gian chết ước tính. Để truy xuất thông tin trạng thái oplog, lệnh được sử dụng là printReplicationInfo (). Lệnh sẽ truy xuất không chỉ thông tin trạng thái oplog mà còn cả kích thước oplog và phạm vi thời gian của các hoạt động.
Tính sẵn có của Luồng thay đổi MongoDB
Các luồng thay đổi MongoDB có thể đạt được đối với các tập hợp bản sao và các cụm phân đoạn:Kích hoạt “đa số” Đọc Quan tâm, Công cụ lưu trữ và Phiên bản giao thức tập hợp bản sao. Kích hoạt “đa số” mối quan tâm đọc:Bắt đầu với MongoDB phiên bản 4.2 trở lên, các luồng thay đổi có thể truy cập được bất chấp các trường hợp phổ biến của hỗ trợ mối quan tâm đọc “đa số”, nghĩa là có thể bật hoặc tắt hỗ trợ đa số mối quan tâm đọc. Trong MongoDB phiên bản 4.0 và các phiên bản cũ hơn, Luồng thay đổi chỉ khả dụng nếu kích hoạt hỗ trợ mối quan tâm của "đa số".
- Công cụ lưu trữ:Công cụ lưu trữ WiredTiger là loại công cụ lưu trữ được các nhóm bản sao và các cụm phân đoạn sử dụng.
- Phiên bản giao thức tập hợp bản sao:Các tập hợp bản sao và các cụm phân đoạn phải luôn sử dụng phiên bản 1 của giao thức tập hợp bản sao (pv1).
MongoDB Sharded Cluster
Các cụm được chia nhỏ trong MongoDB bao gồm các phân đoạn, mongos và máy chủ cấu hình. Phân đoạn bao gồm một tập hợp con dữ liệu được phân đoạn. Trong trường hợp của MongoDB 3.6, các phân đoạn được sử dụng như một tập hợp bản sao. Mongos cung cấp một giao diện giữa các cụm phân đoạn và các ứng dụng khách; mongos đóng vai trò của một bộ định tuyến truy vấn. Từ phiên bản MongoDB 4.4 trở lên, mongos hỗ trợ đọc được bảo vệ để giảm độ trễ. Máy chủ cấu hình là vị trí lưu trữ cho cài đặt cấu hình cụm và siêu dữ liệu.
Luồng thay đổi sử dụng đồng hồ lôgic toàn cục để cung cấp thứ tự toàn cầu của các thay đổi trên các phân đoạn. MongoDB đảm bảo rằng thứ tự của các thay đổi được duy trì và các thông báo của luồng thay đổi có thể được diễn giải một cách an toàn theo thứ tự mà chúng đã được nhận. Ví dụ:con trỏ của luồng thay đổi được mở trên một cụm 3 phân đoạn trả về các thông báo của thay đổi liên quan đến tổng thứ tự của các thay đổi trên ba phân đoạn.
Để đảm bảo tổng số thứ tự các thay đổi, Mongos kiểm tra từng phân đoạn để xem liệu nó có thấy các thay đổi gần đây hơn cho mỗi thông báo thay đổi hay không. Các cụm phân đoạn có một đến một số phân đoạn có ít hoặc không có hoạt động thu thập hoặc ở trạng thái "lạnh" có khả năng gây ảnh hưởng tiêu cực đến thời gian phản hồi của luồng thay đổi vì mongos vẫn phải kiểm tra các phân đoạn nguội đó để đảm bảo thứ tự tổng thể của các thay đổi. Hiệu ứng này có thể rõ ràng hơn khi các phân đoạn được phân phối theo địa lý hoặc khi khối lượng công việc với hầu hết các hoạt động xảy ra trên một tập hợp con các phân đoạn trong một cụm. Nếu bộ sưu tập được phân đoạn có mức độ hoạt động cao, mongos có thể không quản lý để theo dõi các thay đổi trên tất cả các phân đoạn. Ví dụ:hãy xem xét sử dụng bộ lọc thông báo cho loại tập hợp này, chuyển đường ống $ match, được định cấu hình chỉ để lọc các hoạt động chèn.
Trong trường hợp tập hợp bị phân đoạn, các thao tác cập nhật đa:thích hợp có khả năng gây ra các luồng thay đổi được mở đối với tập hợp để gửi thông báo cho các tài liệu bị tách rời. Bắt đầu từ thời điểm một bộ sưu tập chưa được đóng cứng được chia nhỏ cho đến khi luồng thay đổi chuyển đến đoạn di chuyển đầu tiên, documentKey trong tài liệu thông báo luồng thay đổi chỉ bao gồm id tài liệu chứ không phải khóa phân đoạn đầy đủ.
Kết luận
Mục đích của các luồng thay đổi là làm cho dữ liệu của ứng dụng có thể thay đổi trong thời gian thực, không có nguy cơ rình rập oplog và không có bất kỳ dấu vết phức tạp nào. Các ứng dụng MongoDB sử dụng các luồng thay đổi để ký vào các thay đổi dữ liệu trên cơ sở dữ liệu, một bộ sưu tập hoặc triển khai và ngay lập tức phản ứng với chúng. Vì các luồng thay đổi sử dụng khung tổng hợp, các ứng dụng có thể lọc các thay đổi cụ thể và tự chuyển đổi thông báo.
