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

Hiểu về độ bền &độ an toàn khi viết trong MongoDB

Độ bền là chữ “D” trong thuộc tính “ACID” (A - Atomicity, C - Consistency, I - Isolation), được phổ biến bởi các hệ thống quản lý cơ sở dữ liệu quan hệ truyền thống (RDBMS). Độ bền là sự đảm bảo rằng dữ liệu bằng văn bản đã được lưu và sẽ tồn tại vĩnh viễn. Cơ sở dữ liệu NoSQL như MongoDB cung cấp cho các nhà phát triển khả năng kiểm soát chi tiết về độ bền của các cuộc gọi ghi của họ. Điều này cho phép các nhà phát triển chọn các mô hình độ bền, độ an toàn và hiệu suất khác nhau cho các lớp dữ liệu khác nhau. Tuy nhiên, điều này cũng đặt ra gánh nặng cho nhà phát triển trong việc phân biệt và hiểu các sắc thái của các tùy chọn an toàn ghi khác nhau. Trong bài đăng này, chúng ta sẽ xem xét các tùy chọn khác nhau để đảm bảo an toàn khi ghi được cung cấp trong trình điều khiển Java.

Theo cách nói của MongoDB, điều này được gọi là “Viết quan tâm”. Viết các mối quan tâm khác nhau từ “yếu” đến “mạnh”. Mối quan tâm về ghi yếu có thể dẫn đến thông lượng cao hơn nhưng cung cấp ít an toàn dữ liệu hơn và mối quan tâm về ghi mạnh thì ngược lại.

Trình điều khiển Java cho phép bạn chỉ định các tùy chọn an toàn khi ghi của mình bằng cách sử dụng một số cấu trúc telescoping. Đây là hàm tạo với tất cả các tùy chọn:

WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)

Như bạn thấy, hàm tạo này có rất nhiều tùy chọn. Để giúp các nhà phát triển dễ dàng hơn, “Thẻ” được cung cấp cho các giá trị quan tâm khi viết phổ biến - Chưa được xác nhận, Đã được thừa nhận, Journalled, Fsynced và Replica Acknowledged. Mỗi thẻ ánh xạ tới một lệnh gọi nhất định của hàm tạo ở trên.

Chế độ MongoDB chưa được xác nhận

Đây là chế độ “cháy và quên”. Trình điều khiển MongoDB không cố gắng xác nhận việc nhận các hoạt động ghi. Ví dụ:nếu dịch vụ MongoDB của bạn không hoạt động và bạn đang sử dụng chế độ này, tất cả các lỗi sẽ được bỏ qua một cách im lặng và dữ liệu của bạn sẽ bị mất. Rõ ràng, bạn chỉ nên sử dụng chế độ này cho dữ liệu có giá trị thấp, nơi thông lượng ghi quan trọng hơn việc mất một lượng dữ liệu nhất định. Chế độ này có thể được chỉ định như sau:

new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED

Chế độ MongoDB được công nhận

Đây là chế độ ghi mặc định cho MongoDB. Trong chế độ này, trình điều khiển MongoDB cố gắng xác nhận việc nhận các thao tác ghi trên máy chủ, cho phép trình điều khiển bắt bất kỳ lỗi mạng, lỗi khóa trùng lặp, v.v. Tuy nhiên, điều này không đảm bảo rằng dữ liệu được lưu trên đĩa. Nếu máy chủ MongoDB bị treo sau khi ghi nhận, nhưng trước khi ghi vào đĩa, dữ liệu sẽ bị mất. Chế độ này có thể được chỉ định như sau:

new WriteConcern(1) / WriteConcern.ACKNOWLEDGED

Chế độ MongoDB được ghi nhật ký

Trong chế độ này, máy chủ MongoDB chỉ xác nhận việc ghi sau khi xác nhận dữ liệu vào tạp chí. Khi sử dụng chế độ này, ngay cả khi máy chủ bị treo khi máy chủ khởi động lại, dữ liệu vẫn được áp dụng lại từ nhật ký. Rõ ràng, việc ghi nhật ký cần được kích hoạt để tính năng này hoạt động. Tất cả các hệ thống sản xuất phải bật tính năng ghi nhật ký và bạn có thể tìm hiểu thêm về điều này trong bài đăng của chúng tôi Bạn có nên bật tính năng ghi nhật ký MongoDB không?

Trong kịch bản tập hợp bản sao, mối quan tâm về viết nhật ký chỉ áp dụng cho trường hợp chính. Theo mặc định, tạp chí được cam kết vào đĩa cứ sau 100 mili giây. Khi bạn chỉ định ghi bằng tùy chọn ghi nhật ký, nhật ký sẽ được lưu vào đĩa trong 30 mili giây. Vì vậy, nếu bạn chỉ định j:true cho mỗi lần ghi, thông lượng của bạn sẽ tối đa là 1000/30 =33,3 lần ghi / giây. Nếu bạn muốn thông lượng tốt hơn, bạn sẽ cần phải cập nhật hàng loạt và đặt j:true cho lần cập nhật cuối cùng của lô. Chế độ này có thể được chỉ định như sau:

WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED

Chế độ Fsynced MongoDB

Trong chế độ này, máy chủ MongoDB chỉ xác nhận ghi sau khi ghi được ghi vào đĩa. Chế độ này có thể được chỉ định như sau:

new WriteConcern(true) / WriteConcern.FSYNCED

Chế độ MongoDB được xác nhận bản sao

Các chế độ an toàn ghi trước đây chỉ áp dụng cho một máy chủ duy nhất. Khi bạn chạy bộ bản sao, bạn có tùy chọn kiểm soát số lượng bản sao mà bài viết của bạn cần được viết trước khi nó được coi là thành công. Ví dụ:với mối quan tâm viết là “w:2 ″, việc ghi cần được viết cho một chính và ít nhất một phụ trước khi nó được coi là thành công. Điều này làm giảm thông lượng nhưng mang lại cho bạn sự an toàn tốt hơn. Nếu bạn không biết trước số lượng bản sao, bạn có thể sử dụng thẻ WriteConcern.MAJORITY để đảm bảo rằng dữ liệu được lưu trong phần lớn các bản sao. Đây là tùy chọn an toàn nhất trong MongoDB. Nếu bạn định sử dụng tùy chọn này, hãy nhớ đặt giá trị “thời gian chờ” để cho biết lệnh sẽ đợi bao lâu trước khi trả về lỗi:

new WriteConcern(2)/ REPLICA_ACKNOWLEDGED
new Majority()/ WriteConcern.MAJORITY

Các thẻ sau không được dùng nữa (hoặc có kế hoạch) - ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Vui lòng sử dụng các tùy chọn mới hơn thay vì các tùy chọn này. Như thường lệ, nếu bạn có bất kỳ nhận xét hoặc câu hỏi nào, vui lòng liên hệ với chúng tôi theo địa chỉ [email protected].


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Cách đặt khối lượng dữ liệu mongo của docker

  2. Hình ảnh trả về từ API REST luôn hiển thị bị hỏng

  3. BadValue Không hợp lệ hoặc không có ngôn ngữ người dùng được đặt. Hãy đảm bảo các biến môi trường LANG và / hoặc LC_ * được đặt chính xác

  4. DeprecationWarning:collection.findAndModify không được dùng nữa. Sử dụng findOneAndUpdate, findOneAndReplace hoặc findOneAndDelete thay thế?

  5. Kết nối ứng dụng Heroku với dịch vụ đám mây Atlas MongoDB