MongoDB
 sql >> Cơ Sở Dữ Liệu >  >> NoSQL >> MongoDB

Chuẩn bị máy chủ MongoDB để sản xuất

Sau khi phát triển ứng dụng và mô hình cơ sở dữ liệu của bạn (đã đến lúc chuyển môi trường vào sản xuất), có một số việc cần phải làm trước tiên. Thông thường các nhà phát triển không cân nhắc các bước MongoDB quan trọng bổ sung trước khi triển khai cơ sở dữ liệu vào sản xuất. Do đó, chính trong phương thức sản xuất, họ sẽ gặp phải những trở ngại cơ bản mà trong phương thức phát triển không thể hiện được. Đôi khi có thể là quá muộn hoặc đúng hơn là rất nhiều dữ liệu sẽ bị mất nếu thảm họa xảy ra. Bên cạnh đó, một số bước được thảo luận ở đây sẽ cho phép người ta đánh giá tình trạng của cơ sở dữ liệu và từ đó lập kế hoạch cho các biện pháp cần thiết trước khi thảm họa xảy ra.

Sử dụng phiên bản hiện tại và trình điều khiển mới nhất

Nói chung, các phiên bản mới nhất của bất kỳ công nghệ nào đều đi kèm với các tính năng được cải thiện về chức năng cơ bản hơn so với các phiên bản tiền nhiệm. Các phiên bản mới nhất của MongoDB mạnh mẽ hơn và được cải thiện hơn so với các phiên bản tiền nhiệm về hiệu suất, khả năng mở rộng và dung lượng bộ nhớ. Điều tương tự cũng áp dụng cho các trình điều khiển liên quan vì chúng được phát triển bởi các kỹ sư cơ sở dữ liệu cốt lõi và được cập nhật thường xuyên hơn ngay cả chính cơ sở dữ liệu.

Các tiện ích mở rộng gốc được cài đặt cho ngôn ngữ của bạn có thể dễ dàng tạo nền tảng cho các thủ tục nhanh chóng và tiêu chuẩn để kiểm tra, phê duyệt và nâng cấp trình điều khiển mới. Ngoài ra còn có các phần mềm ô tô như Ansible, Puppet, SaltStack và Chef có thể được sử dụng để nâng cấp dễ dàng MongoDB trong tất cả các nút của bạn mà không phải chịu chi phí và thời gian chuyên môn.

Cũng nên xem xét sử dụng công cụ lưu trữ WiredTiger vì nó là công cụ được phát triển nhất với các tính năng hiện đại phù hợp với mong đợi của cơ sở dữ liệu hiện đại

Đăng ký danh sách gửi thư MongoDB để nhận thông tin mới nhất liên quan đến các thay đổi đối với phiên bản &trình điều khiển mới và các bản sửa lỗi do đó luôn được cập nhật.

Sử dụng Hệ thống 64 bit để chạy MongoDB

Trong hệ thống 32-bit, các quy trình MongoDB bị giới hạn ở khoảng 2,5 GB dữ liệu vì cơ sở dữ liệu sử dụng các tệp được ánh xạ bộ nhớ để thực hiện. Điều này trở thành một hạn chế đối với các quá trình có thể vượt qua ranh giới dẫn đến việc phải lòng. Tác động cốt lõi sẽ là:trong trường hợp xảy ra lỗi, bạn sẽ không thể khởi động lại máy chủ cho đến khi bạn xóa dữ liệu của mình hoặc di chuyển cơ sở dữ liệu của mình sang hệ thống cao hơn như 64-bit, do đó thời gian ngừng hoạt động cao hơn cho ứng dụng của bạn.

Nếu bạn phải tiếp tục sử dụng hệ thống 32 bit, việc mã hóa của bạn phải rất đơn giản để giảm số lượng lỗi và độ trễ cho các hoạt động thông lượng.

Tuy nhiên, đối với các mã phức tạp như đường ống tổng hợp và dữ liệu địa lý, bạn nên sử dụng hệ thống 64 bit.

Đảm bảo tài liệu được giới hạn ở kích thước 16MB

Các tài liệu MongoDB được giới hạn ở kích thước 16MB nhưng bạn không cần phải đạt đến gần giới hạn này vì nó sẽ dẫn đến một số suy giảm hiệu suất. Trên thực tế, các tài liệu chủ yếu có kích thước KB trở xuống. Kích thước tài liệu phụ thuộc vào chiến lược mô hình hóa dữ liệu giữa nhúng và tham chiếu. Nhúng được ưu tiên khi kích thước tài liệu dự kiến ​​sẽ không tăng nhiều về kích thước. Ví dụ:nếu bạn có một ứng dụng mạng xã hội nơi người dùng đăng bài và nó có nhận xét, thì phương pháp hay nhất là có hai bộ sưu tập, một bộ sưu tập để lưu giữ thông tin bài đăng.

  {

   _id:1,

   post: 'What is in your mind?',

   datePosted: '12-06-2019',

   postedBy:'xyz',

   likes: 10,

   comments: 30

}

và người khác giữ nhận xét cho bài đăng đó.

     {

   _id: ObjectId('2434k23k4'),

   postId: 1,

   dateCommented: '12-06-2019',

   commentedBy:'ABCD',

   comment: 'When will we get better again',

}

Bằng cách có các mô hình dữ liệu như vậy, các nhận xét sẽ được lưu trữ trong một bộ sưu tập khác với bài đăng. Điều này ngăn không cho tài liệu trong bộ sưu tập bài phát triển ra khỏi giới hạn trong trường hợp có quá nhiều nhận xét. Đảm bảo bạn tránh các mẫu ứng dụng cho phép tài liệu phát triển không giới hạn.

Đảm bảo Bộ Hoạt động Phù hợp với Bộ nhớ

Cơ sở dữ liệu có thể không đọc được dữ liệu từ bộ nhớ ảo (RAM) dẫn đến lỗi trang. Lỗi trang sẽ buộc cơ sở dữ liệu đọc dữ liệu từ đĩa vật lý dẫn đến tăng độ trễ và do đó gây ra độ trễ trong hiệu suất ứng dụng tổng thể. Lỗi trang xảy ra do làm việc với một tập hợp lớn không vừa với bộ nhớ. Điều này có thể do một số tài liệu có kích thước không giới hạn hoặc chiến lược phân loại kém.

  • Đảm bảo tài liệu được giới hạn ở kích thước 16 MB.
  • Đảm bảo một chiến lược sharding tốt bằng cách chọn một khóa sharding tối ưu sẽ giới hạn số lượng tài liệu mà một hoạt động thông lượng sẽ phải tuân theo.
  • Tăng kích thước của phiên bản MongoDB để chứa nhiều nhóm làm việc hơn.

Đảm bảo bạn có Bộ bản sao tại chỗ

Trong thế giới cơ sở dữ liệu, không phải là lý tưởng nếu chỉ dựa vào một cơ sở dữ liệu do thảm họa có thể xảy ra. Bên cạnh đó, bạn sẽ mong đợi sự gia tăng số lượng người dùng vào cơ sở dữ liệu, do đó cần đảm bảo tính sẵn có của dữ liệu cao. Nhân rộng là một cách tiếp cận quan trọng để đảm bảo tính sẵn sàng cao trong trường hợp chuyển đổi dự phòng. MongoDB có khả năng cung cấp dữ liệu theo địa lý:có nghĩa là người dùng từ các vị trí khác nhau sẽ được máy chủ đám mây gần nhất phục vụ như một cách để giảm độ trễ cho các yêu cầu.

Trong trường hợp nút chính bị lỗi, các nút phụ có thể chọn một nút mới để theo kịp các hoạt động ghi thay vì ứng dụng có thời gian chết trong quá trình chuyển đổi dự phòng. Trên thực tế, một số nền tảng lưu trữ đám mây khá cân nhắc với việc sao chép không hỗ trợ MongoDB không được sao chép cho môi trường sản xuất.

Bật tính năng Ghi nhật ký

Việc viết nhật ký dẫn đến một số suy giảm hiệu suất, điều đó cũng quan trọng. Việc ghi nhật ký giúp tăng cường các thao tác ghi trước, có nghĩa là trong trường hợp cơ sở dữ liệu bị lỗi trong quá trình cập nhật, bản cập nhật sẽ được lưu ở đâu đó và khi nó hoạt động trở lại, quá trình này có thể được hoàn tất. Tính năng ghi nhật ký có thể dễ dàng tạo thuận lợi cho việc khôi phục sự cố do đó nên được bật theo mặc định.

Đảm bảo bạn Thiết lập Chiến lược Dự phòng

Nhiều doanh nghiệp không thể tiếp tục sau khi mất dữ liệu do không có hoặc hệ thống sao lưu kém. Trước khi triển khai cơ sở dữ liệu của bạn vào sản xuất, hãy đảm bảo rằng bạn đã sử dụng một trong các chiến lược sao lưu sau:

  • Mongodump :tối ưu cho các đợt triển khai nhỏ và khi tạo các bản sao lưu được lọc theo nhu cầu cụ thể.
  • Đang sao chép cơ bản :tối ưu cho các đợt triển khai lớn và cách tiếp cận hiệu quả để sao lưu đầy đủ và khôi phục chúng.
  • Dịch vụ quản lý MongoDB (MMS) :cung cấp sao lưu trực tuyến liên tục cho MongoDB như một dịch vụ được quản lý hoàn toàn. Tối ưu cho một cụm phân đoạn và nhóm bản sao.

Các tệp sao lưu cũng không được lưu trữ trong cùng một nhà cung cấp máy chủ của cơ sở dữ liệu. Backup Ninja là một dịch vụ có thể được sử dụng cho việc này.

Chuẩn bị cho các Truy vấn chậm

Hầu như không ai có thể nhận ra các truy vấn chậm trong môi trường phát triển do thực tế là ít dữ liệu có liên quan. Tuy nhiên, điều này có thể không đúng trong trường hợp sản xuất vì bạn sẽ có nhiều người dùng hoặc nhiều dữ liệu sẽ tham gia. Các truy vấn chậm có thể phát sinh nếu bạn không sử dụng được chỉ mục hoặc sử dụng khóa lập chỉ mục không tối ưu. Tuy nhiên, chúng ta nên tìm cách cho bạn biết lý do khiến các truy vấn chậm.

Do đó, chúng tôi quyết định bật Hồ sơ truy vấn MongoDB. Vì điều này có thể dẫn đến suy giảm hiệu suất, trình biên dịch sẽ giúp giải quyết các vấn đề về hiệu suất. Trước khi triển khai cơ sở dữ liệu của mình, bạn cần bật trình biên dịch cho các bộ sưu tập mà bạn nghi ngờ có thể có các truy vấn chậm, đặc biệt là các bộ liên quan đến tài liệu với nhiều lần nhúng.

Kết nối với Công cụ Giám sát

Lập kế hoạch năng lực là một công việc rất cần thiết trong MongoDB. Bạn cũng sẽ cần biết sức khỏe của db của bạn tại bất kỳ thời điểm nào. Để thuận tiện, việc kết nối cơ sở dữ liệu của bạn với một công cụ giám sát sẽ giúp bạn tiết kiệm thời gian trong việc nhận ra những gì bạn cần cải thiện trên cơ sở dữ liệu của mình theo thời gian. Ví dụ:một biểu diễn đồ họa cho biết hiệu suất chậm của CPU do truy vấn tăng lên sẽ hướng dẫn bạn thêm nhiều tài nguyên phần cứng hơn vào hệ thống của mình.

Các công cụ giám sát cũng có hệ thống cảnh báo thông qua gửi thư hoặc tin nhắn ngắn giúp cập nhật một cách thuận tiện cho bạn về một số vấn đề trước khi chúng phát triển thành thảm họa. Do đó, trong quá trình sản xuất, hãy đảm bảo cơ sở dữ liệu của bạn được kết nối với một công cụ giám sát.

ClusterControl cung cấp tính năng giám sát MongoDB miễn phí trong Phiên bản Cộng đồng.

Triển khai các Biện pháp Bảo mật

Bảo mật cơ sở dữ liệu là một tính năng quan trọng khác cần được tính đến một cách nghiêm ngặt. Bạn cần bảo vệ cài đặt MongoDB trong quá trình sản xuất bằng cách đảm bảo tuân thủ một số danh sách kiểm tra bảo mật trước khi sản xuất. Một số điều cần cân nhắc là:

  • Định cấu hình điều khiển truy cập dựa trên vai trò
  • Bật kiểm soát truy cập và thực thi xác thực
  • Mã hóa các kết nối đến và đi (TLS / SSL)
  • Hạn chế hiển thị trên mạng
  • Mã hóa và bảo vệ dữ liệu
  • Có kế hoạch theo dõi quyền truy cập và các thay đổi đối với cấu hình cơ sở dữ liệu

Tránh tiêm từ bên ngoài bằng cách chạy MongoDB với các tùy chọn cấu hình an toàn. Ví dụ:vô hiệu hóa tập lệnh phía máy chủ nếu không sử dụng các hoạt động phía máy chủ JavaScript như mapReduce và $ where. Sử dụng trình xác thực JSON cho dữ liệu thu thập của bạn thông qua một số mô-đun như mongoose để đảm bảo rằng tất cả các tài liệu được lưu trữ ở định dạng BSON hợp lệ.

Cân nhắc về Phần cứng và Phần mềm

MongoDB có ít điều kiện tiên quyết về phần cứng, vì nó được thiết kế rõ ràng với sự cân nhắc kỹ lưỡng về phần cứng hàng hóa cần thiết. Sau đây là những cân nhắc phần cứng chính cho MongoDB mà bạn cần cân nhắc trước khi triển khai vào sản xuất.

  • Chỉ định RAM và CPU thích hợp
  • Sử dụng công cụ lưu trữ WiredTiger. Được thiết kế để sử dụng bộ đệm ẩn của hệ thống tệp và bộ đệm bên trong WiredTiger do đó tăng hiệu suất. Ví dụ:khi hoạt động với hệ thống RAM 4GB, bộ nhớ đệm WiredTiger sử dụng 1,5GB RAM (0,5 * (4GB -1GB) =1,5GB) trong khi hệ thống có RAM 1,2GB bộ nhớ đệm WiredTiger chỉ sử dụng 256MB.
  • Phần cứng NUMA. Có rất nhiều vấn đề hoạt động bao gồm hiệu suất chậm và sử dụng quy trình hệ thống cao, do đó, người ta nên xem xét việc định cấu hình chính sách xen kẽ bộ nhớ.
  • Hệ thống lưu trữ và Đĩa:Sử dụng trạng thái rắn Đĩa (SSD):MongoDB cho thấy tỷ lệ hiệu suất giá cả tốt hơn với SSD SATA

Kết luận

Cơ sở dữ liệu trong sản xuất là rất quan trọng để đảm bảo hoạt động trơn tru của doanh nghiệp do đó cần được cân nhắc rất nhiều. Người ta nên đặt ra một số thủ tục có thể giúp giảm thiểu lỗi hoặc đúng hơn là cung cấp một cách dễ dàng để tìm ra những lỗi này. Bên cạnh đó, nên thiết lập một hệ thống cảnh báo sẽ hiển thị tình trạng của cơ sở dữ liệu theo thời gian để lập kế hoạch năng lực và phát hiện các vấn đề trước khi chúng giảm thiểu thành thảm họa.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. MongoDB - Tạo mối quan hệ

  2. sắp xếp tổng hợp mongodb

  3. Không tìm thấy lớp 'MongoClient'

  4. MongoParseError:các tùy chọn useCreateIndex, useFindAndModify không được hỗ trợ

  5. Mongo phân loại phức tạp?