Nhiệm vụ DBA MongoDB vs RDBMS

Sự khác biệt giữa các nhiệm vụ / nhiệm vụ hàng ngày của Mongo DBA so với RBAMS DBA là gì?

Ví dụ: một số trang web cho rằng DBA MongoDB sẽ không yêu cầu mô hình hóa dữ liệu hoặc thiết kế cơ sở dữ liệu, như điều đó sẽ được thực hiện bởi nhà phát triển hoặc nhà thiết kế ứng dụng.

Điều này có nghĩa là một số nhiệm vụ không còn cần phải thực hiện khi quản trị MongoDB, mà trước đó đã được thực hiện bởi các DBA RDBMS.

Những nhiệm vụ nào khác sẽ được yêu cầu, thường không có trong lịch trình của RBAMS DBA?, Và cũng là nhiệm vụ mà các DBA RDBMS đã sử dụng để thực hiện nhưng không còn trong lịch trình của các DBA MongoDB?

Tôi là người mới trong quản trị MongoDB, vì vậy tôi đang cố gắng xác định các nhiệm vụ này để tôi không phạm phải sai lầm khi làm những việc trong công việc hàng ngày không cần thiết hoặc tôi bỏ lỡ điều gì đó mà tôi cần.

Bất kỳ DBA MongoDB có kinh nghiệm nào có thể giúp tôi để tôi không mắc phải những sai lầm ngu ngốc trong công việc của mình không?

Tôi đã ở trong lĩnh vực NoQuery từ 3 năm trước.
Là một DBA MongoDB, bạn cần hợp tác chặt chẽ với các nhóm Phát triển và Ops. Sau đây là những điều bạn cần thực hiện hàng ngày như một DBA MongoDB. Vai trò có thể được phân loại thành ba phần:

1. Quản trị:

   • Triển khai mới (thủ công / tự động)
   • Thiết kế triển khai hệ thống cơ sở dữ liệu của bạn
   • Giám sát
   • Sao lưu và phục hồi
   • Bảo vệ
   • Thực hành tốt nhất cho sức khỏe DB

2. Phát triển:

   • Bạn được yêu cầu viết mã / tập lệnh chạy định kỳ / một lần trên dữ liệu của mình, điều này có thể được yêu cầu để tạo báo cáo & phân tích.
   • Gỡ lỗi các vấn đề về ứng dụng-db với các nhóm phát triển
   • Triển khai tính khả dụng, khả năng mở rộng và bảo mật từ phía ứng dụng
   • Truy vấn cơ sở dữ liệu về dàn dựng và sản xuất bất cứ khi nào cần thiết
   • Đề xuất chiến lược lập chỉ mục và thực hiện chúng
   • Bạn đang tham gia thiết kế cơ sở dữ liệu và mô hình hóa

3. Điều chỉnh hiệu suất:

   • Điều này đòi hỏi phải liên tục đo hiệu suất của cơ sở dữ liệu của bạn bằng các công cụ
   • Tạo chỉ mục hoặc cơ sở dữ liệu phân đoạn dựa trên các yêu cầu
   • Báo cáo hiệu suất cơ sở dữ liệu cho nhóm phát triển

DBA là một từ viết tắt nhỏ nhưng có vai trò lớn. Nhiều lúc tôi đã thấy một DBA chăm sóc

• lưu trữ
• mạng
• Máy ảo
• nút tính toán
• cài đặt và cấu hình ở trên
• sao lưu và khôi phục thử nghiệm
• Chiến lược DR
• toàn vẹn dữ liệu doanh nghiệp
• ETL
• bảo mật dữ liệu
• mô hình hóa dữ liệu, chuẩn hóa và thiết kế cơ sở dữ liệu
• lập trình tầng dữ liệu
• điều chỉnh hiệu suất
• sẵn sàng hoạt động
• nhân rộng
• thất bại
• hỗ trợ trực tiếp

.. và những người khác bên cạnh. Tôi không thể thấy bất kỳ thứ nào trong số này biến mất chỉ vì Oracle / SQL Server / PostgreSQL được thay thế bằng MongoDB / Cassandra / CouchDB.

"Ồ," nhưng bạn nói, "Không có lược đồ. Tôi không phải làm điều đó về mô hình & thiết kế."

"Bạn đang ảo tưởng", tôi sẽ trả lời. Nếu hệ thống dành cho xử lý đơn đặt hàng (và không xử lý đơn đặt hàng và nhận bánh sô cô la và tự chụp danh mục, v.v.) và Doanh nghiệp phân biệt Đơn hàng theo Số thứ tự 7 chữ số và mỗi Đơn hàng bao gồm một hoặc nhiều Dòng đơn hàng (tham khảo mỗi một Sản phẩm), sau đó bạn có một lược đồ. Chỉ vì nó được thi hành trong lớp ứng dụng chứ không phải trong DBMS không làm cho nó biến mất. Và ai đótốt hơn hết là viết ra các quy tắc đó, và xác nhận chúng với người dùng, và truyền đạt chúng cho nhóm thử nghiệm, đồng thời dạy cho nhân viên mới được thuê, và đưa chúng vào tài liệu của người dùng cuối và đảm bảo dữ liệu cũ vẫn có thể đọc bởi ứng dụng vừa thay đổi. Chỉ vì các quy tắc có thể được thay đổi trong mã ứng dụng, thay vì mã ứng dụng và tập lệnh DBMS, không làm cho bất kỳ nội dung nào trở nên ít quan trọng hơn.

Vì vậy, với giá trị hai xu của tôi, mặc dù có rất nhiều lợi ích, tôi không tin rằng lớp phần mềm này sẽ loại bỏ bất kỳ nhiệm vụ quan trọng nào theo truyền thống của một DBA trong thế giới RDBMS. Nó có thể phân phối lại chúng cho những người nắm giữ các chức danh công việc khác và các nhiệm vụ có thể trở nên dễ thực hiện hơn hoặc ít xâm phạm hơn vào SDLC.

Đối với việc thêm các tác vụ, có vấn đề duy trì khả năng tương thích với dữ liệu cũ được viết theo sự hiểu biết trước đó về các quy tắc kinh doanh. Một RDBMS sẽ không gặp vấn đề này vì chỉ có một lược đồ có thể chấp nhận tại bất kỳ thời điểm nào.