Xác định kiến ​​trúc tốt nhất cho triển khai cụm MongoDB

Việc triển khai cụm có ý nghĩa lớn trong việc đảm bảo tính khả dụng cao của dữ liệu cũng như bảo vệ nó. MongoDB tăng cường điều này thông qua sao chép và phân bổ, theo đó nhân rộng đảm bảo mở rộng quy mô theo chiều dọc thông qua việc nâng độ dư thừa trong khi đó sharding làm tăng quy mô theo chiều ngang.

Nhìn chung, cả hai cách tiếp cận đều cố gắng phân phối khối lượng công việc giữa các thành viên và do đó giảm khối lượng công việc mà một nút duy nhất có thể phải chịu. Hiệu suất cơ sở dữ liệu sau đó có thể được xem là nhanh chóng trong việc phục vụ người dùng với các hoạt động thông lượng. Tuy nhiên, nếu không có kiến ​​trúc cụm nguyên tố, bạn có thể không thấy cùng một mức kết quả, ngay cả khi bạn thử phân cấp và nhân rộng.

Nếu các thành viên của nhóm bản sao là số chẵn, thì các thành viên sẽ khó bỏ phiếu và bầu cho nhóm sơ bộ mới nếu nhóm hiện có không thành công tại một thời điểm nào đó. Trong blog này, chúng ta sẽ thảo luận về kiến ​​trúc triển khai tiêu chuẩn mà người ta có thể sử dụng nhưng điều này có thể thay đổi tùy theo yêu cầu ứng dụng.

Chiến lược Triển khai MongoDB

Kiến trúc của bộ bản sao là yếu tố quyết định rất nhiều đến dung lượng và khả năng của MongoDB.

Bộ bản sao ba nút là triển khai cụm tiêu chuẩn cho MongoDB trong bất kỳ môi trường sản xuất nào vì nó cung cấp khả năng dự phòng dữ liệu và khả năng chịu lỗi. Dự phòng rất quan trọng, đặc biệt là trong việc khôi phục cơ sở dữ liệu sau khi xảy ra thảm họa. Bộ bản sao ba nút có thể là kiến ​​trúc triển khai cơ bản, nhưng điều này có thể thay đổi tùy theo yêu cầu và đặc điểm kỹ thuật của ứng dụng. Tuy nhiên, đừng làm cho nó quá phức tạp vì nó có thể dẫn bạn đến một số vấn đề cấu hình lớn hơn.

Chiến lược Sharding MongoDB

Sharding giảm khối lượng công việc mà cơ sở dữ liệu phải làm việc cho một truy vấn nhất định bằng cách giảm số lượng tài liệu phải được xử lý. Do đó, nó nâng quy mô theo chiều ngang cho phép cơ sở dữ liệu phát triển vượt ra ngoài giới hạn phần cứng của một máy chủ duy nhất. Tùy thuộc vào nhu cầu khối lượng công việc, các nút có thể được thêm vào hoặc xóa khỏi cụm và MongoDB sẽ cân bằng lại dữ liệu theo cách tối ưu mà không cần can thiệp hoạt động.

Một số chiến lược triển khai tốt nhất cho một cụm phân đoạn bao gồm:

Đảm bảo các Khóa mảnh được phân phối đồng nhất

Lý do đằng sau sharding là để chia tỷ lệ cơ sở dữ liệu theo chiều ngang và giảm số lượng hoạt động thông lượng mà một phiên bản đơn lẻ có thể phải chịu. Nếu bạn không phân phối các khóa phân đoạn một cách đồng nhất, bạn có thể kết thúc với một số lượng nhỏ các phân đoạn. Với ít phân đoạn, các hoạt động có thể bị giới hạn bởi dung lượng của một phân đoạn, do đó làm cho các hoạt động đọc và ghi chậm.

Các sợi chun nên được Tách trước và Phân phối trước

Phân đoạn có các phần dữ liệu được nhóm theo một số tiêu chí chính của phân đoạn. Khi tạo một bộ sưu tập được phân đoạn mới, trước khi tải nó với dữ liệu, bạn nên tạo các phần trống và phân phối chúng đồng đều trên tất cả các phân đoạn. Khi bạn nhập dữ liệu vào MongoDB, bạn sẽ dễ dàng cân bằng tải trên các phân đoạn liên quan. Tùy chọn numInitialChunks có thể được sử dụng để thực hiện những điều này một cách tự động nếu bạn đang sử dụng sharding dựa trên băm. Tuy nhiên, giá trị số nguyên phải nhỏ hơn 8192 cho mỗi phân đoạn.

Số lượng mảnh

Hai phân đoạn thường được yêu cầu là con số tối thiểu để đạt được mức ý nghĩa tăng dần. Một phân đoạn duy nhất chỉ hữu ích nếu bạn muốn tạo nền tảng cho việc cho phép sharding trong tương lai và không cần trong thời gian triển khai.

Ưu tiên mài sắc dựa trên phạm vi hơn mài sắc dựa trên băm

Sharding dựa trên phạm vi có lợi vì nó cung cấp nhiều phân đoạn hơn, do đó các hoạt động có thể được chuyển đến một số phân đoạn nhỏ nhất cần thiết và thường là một phân đoạn duy nhất. Trên thực tế, điều này có thể không khó trừ khi bạn hiểu rõ về dữ liệu và các mẫu truy vấn liên quan. Mảng băm băm cải thiện sự phân phối đồng đều của hoạt động thông lượng với chi phí cung cấp các hoạt động dựa trên phạm vi kém hơn.

Sử dụng Truy vấn Phân tán-Thu thập Chỉ cho các Truy vấn Tổng hợp Lớn

Các truy vấn không thể được định tuyến dựa trên khóa phân đoạn nên được phát tới tất cả các phân đoạn để đánh giá và vì chúng liên quan đến nhiều phân đoạn cho mỗi yêu cầu, chúng không chia tỷ lệ tuyến tính vì nhiều phân đoạn được thêm vào do đó phát sinh chi phí làm giảm hiệu suất của cơ sở dữ liệu. Thao tác này được gọi là thu thập phân tán và chỉ có thể tránh được nếu bạn đưa khóa phân đoạn vào truy vấn của mình.

Phương pháp này chỉ hữu ích khi xử lý các truy vấn tổng hợp lớn mà mỗi truy vấn có thể được phép chạy song song trên tất cả các phân đoạn.

Chiến lược sao chép MongoDB

Replication nâng cao khả năng mở rộng theo chiều dọc trong MongoDB để khối lượng công việc được phân phối giữa các thành viên liên quan. Trong môi trường sản xuất, đây là một số cân nhắc cần thực hiện để có một kiến ​​trúc cụm tối ưu.

Số Nút

Số lượng nút tối đa mà một tập hợp bản sao có thể có là 50 với 7 thành viên biểu quyết. Bất kỳ thành viên nào sau ngày thứ 7 được coi là không bỏ phiếu. Vì vậy, một cụm tốt nên có 7 thành viên bỏ phiếu để quá trình bầu cử diễn ra thuận lợi.

Triển khai số lượng thành viên biểu quyết là số lẻ và nếu bạn chỉ có ít hơn 7 nhưng là số lượng thành viên chẵn, thì bạn sẽ cần triển khai trọng tài làm thành viên biểu quyết khác. Trọng tài không lưu trữ bản sao của dữ liệu do đó sẽ yêu cầu ít tài nguyên hơn để quản lý. Bên cạnh đó, một người có thể buộc họ phải tuân theo một môi trường mà bạn không thể áp đặt các thành viên khác.

Cân nhắc về Khả năng Chịu Lỗi

Đôi khi một số thành viên có thể không sử dụng được do các yếu tố như mất điện hoặc quá độ mạng và ngắt kết nối. Số lượng thành viên vẫn còn trong nhóm và có khả năng bầu ra một nhóm chính tạo ra một tình huống được gọi là Khả năng chịu lỗi. Do đó, nó là sự khác biệt giữa tổng số thành viên tập hợp bản sao và đa số thành viên biểu quyết cần thiết để bầu ra sơ bộ. Sự vắng mặt của lệnh chính khiến các thao tác ghi không thể được thực hiện.

Bảng dưới đây cho thấy mối quan hệ mẫu giữa ba yếu tố này.

Mối quan hệ không trực tiếp ở chỗ nếu bạn thêm nhiều thành viên hơn vào tập hợp thì khả năng chịu lỗi sẽ không tăng lên như đã thấy trong bảng. Các thành viên bổ sung cung cấp hỗ trợ cho các chức năng chuyên dụng như sao lưu và báo cáo.

Lập kế hoạch công suất và cân bằng tải cho các bài đọc nặng

Bạn cần có dung lượng dự phòng để triển khai bằng cách thêm thành viên mới trước khi nhu cầu hiện tại bão hòa dung lượng của tập hợp hiện có.

Đối với lưu lượng đọc rất cao, hãy phân phối thông lượng đọc cho các thành viên thứ cấp và bất cứ khi nào cụm phát triển, hãy thêm hoặc di chuyển các thành viên sang các trung tâm dữ liệu thay thế để đạt được sự dự phòng và tăng tính khả dụng của dữ liệu.

Bạn cũng có thể sử dụng các hoạt động đích với các tập hợp thẻ để nhắm mục tiêu các hoạt động đọc cho các thành viên cụ thể hoặc sửa đổi mối quan tâm ghi để yêu cầu xác nhận từ các thành viên cụ thể.

Các nút nên được phân bố theo địa lý

Trung tâm dữ liệu cũng có thể bị lỗi do một số sự cố. Do đó, người ta nên giữ ít nhất một hoặc hai thành viên trong một trung tâm dữ liệu riêng biệt cho các mục đích bảo vệ dữ liệu. Nếu có thể, hãy sử dụng số lượng trung tâm dữ liệu lẻ và chọn cách phân phối tối đa hóa khả năng ngay cả khi mất trung tâm dữ liệu, các thành viên còn lại của tập hợp bản sao có thể tạo thành phần lớn hoặc tối thiểu cung cấp một bản sao dữ liệu.

Viết nhật ký cho những thất bại không mong muốn

Theo mặc định, tính năng này được bật trong MongoDB. Bạn nên đảm bảo rằng tùy chọn này được bật để bảo vệ việc mất dữ liệu trong trường hợp dịch vụ bị gián đoạn, chẳng hạn như khởi động lại đột ngột và mất điện.

Mẫu Triển khai

Có hai cách tiếp cận triển khai chủ yếu là:

• Bộ bản sao Ba Thành viên cung cấp kiến ​​trúc được đề xuất tối thiểu cho một bộ bản sao.
• Tập hợp bản sao được phân phối trên hai hoặc nhiều trung tâm dữ liệu để bảo vệ khỏi các sự cố cụ thể của cơ sở như mất điện.

Tuy nhiên, các mẫu phụ thuộc vào các yêu cầu ứng dụng nhưng nếu có thể, bạn có thể kết hợp các tính năng của hai mẫu này trong kiến ​​trúc triển khai của mình.

Tên máy chủ và Đặt tên bản sao

Sử dụng tên máy chủ DNS hợp lý thay vì địa chỉ ip khi định cấu hình thành viên nhóm bản sao hoặc thành viên cụm phân đoạn. Điều này là để tránh những rắc rối liên quan đến các thay đổi cấu hình mà bạn sẽ cần thực hiện do địa chỉ ip đã thay đổi.

Trong trường hợp đặt tên tập hợp bản sao, hãy sử dụng các tên riêng biệt cho các tập hợp vì một số trình điều khiển nhóm các kết nối tập hợp bản sao theo tên tập hợp bản sao.

Kết luận

Bố cục kiến ​​trúc cho một tập hợp bản sao xác định năng lực và khả năng triển khai của bạn. Bảo vệ dữ liệu và hiệu suất hệ thống là những cân nhắc cốt lõi khi thiết lập kiến ​​trúc. Người ta nên xem xét các yếu tố quan trọng như khả năng chịu lỗi, số lượng thành viên tập hợp bản sao, khóa phân tách tối ưu và các mẫu triển khai để có tính khả dụng cao và bảo vệ dữ liệu. Phân bố theo địa lý của các nút tập hợp bản sao có thể giải quyết phần lớn các yếu tố này bằng cách đảm bảo dự phòng và cung cấp khả năng chịu lỗi nếu một trong các trung tâm dữ liệu vắng mặt.