Theo Cục Thống kê Lao động, triển vọng việc làm liên quan đến việc quản lý kiến ​​trúc dữ liệu và cơ sở dữ liệu có vẻ khá tốt: Số lượng chuyên gia có vai trò quản lý dữ liệu là do lớn lên tăng 2022% từ năm 2032 đến năm XNUMX. Tuy nhiên, trong khi số lượng vai trò xử lý dữ liệu ngày càng tăng thì chỉ riêng vị trí quản trị viên cơ sở dữ liệu (DBA) đang thực sự giảm xuống. Thay vào đó, vai trò chuyên gia DBA đã được thay thế bằng kỹ sư về độ tin cậy trang web (SRE) của thế giới DevOps. 

Vai trò SRE được phát triển tại Google, áp dụng các kỹ năng của họ về quản lý và vận hành trang web vào các lĩnh vực công nghệ khác. SRE có phạm vi công việc rộng hơn nhiều so với DBA, bao gồm các loại nhiệm vụ tương tự như quản lý vận hành, tính khả dụng, dự phòng hệ thống và bảo mật, nhưng đối với toàn bộ cơ sở hạ tầng CNTT, không chỉ các cơ sở dữ liệu hiện có. Tuy nhiên, các nhiệm vụ mà các DBA thực hiện vẫn không giảm đi và có những sắc thái mà các DBA có thể hiểu còn các nhân viên khác thì không.

Các DBA phải đối mặt với những vấn đề gì? 

Mặc dù phần lớn SRE sẽ có thể quản lý các phiên bản cơ sở dữ liệu và duy trì hoạt động của chúng, nhưng họ sẽ không có kinh nghiệm và kiến ​​thức chuyên sâu như những người tập trung vào lý thuyết và quản lý cơ sở dữ liệu sẽ có. Khi điều gì đó bất thường xảy ra, SRE sẽ phải hiểu chuyện gì đang xảy ra và liệu họ có thể khắc phục sự cố hay không hoặc liệu họ có cần gọi chuyên gia hay không.

Một ví dụ điển hình cho việc này là cách thiết lập và quản lý Structured Query Languagehoặc SQL. SQL có thể là ngôn ngữ phổ biến nhất năm 2023 của IEEE, nhưng nó có cú pháp phức tạp mà tương đối ít người nỗ lực để thành thạo. Nhiều nhà phát triển không quen với cách viết các truy vấn SQL hiệu quả và hiệu quả, vì vậy họ có thể nhận được các yêu cầu hoạt động kém và mất nhiều thời gian hơn để trả về kết quả. Ngoài ra, các nhà phát triển thường chuyển sang Trình ánh xạ quan hệ đối tượng (ORM) để xử lý các yêu cầu SQL dành cho họ. Mặc dù ORM có thể làm cho tình huống trở nên đơn giản hơn đối với các nhà phát triển, nhưng họ có thể gặp phải hiệu suất kém và thiết kế truy vấn kém giống như việc viết mã SQL của riêng bạn, cùng với nhu cầu cập nhật và quản lý chính ORM. Sự kết hợp này thường được thấy cùng với xu hướng sử dụng các giao dịch kéo dài nhằm hạn chế hiệu suất. 

Đối với các DBA, việc phát hiện những vấn đề này và khắc phục chúng là một phần công việc toàn thời gian. Tuy nhiên, đối với các SRE không quen với hiệu suất cơ sở dữ liệu, những giao dịch chậm này có thể được chấp nhận là “mọi thứ diễn ra như thế nào” chứ không phải là dấu hiệu của một điều gì đó không ổn. Ngoài ra, các nhà phát triển có thể thử sử dụng nhiều tài nguyên hơn để giải quyết vấn đề bằng cách mua các máy lớn hơn hoặc phiên bản đám mây để chạy.

Bên cạnh việc thiết kế truy vấn, các DBA còn chịu trách nhiệm thiết lập các chỉ mục dữ liệu trên cơ sở dữ liệu của họ. Lập chỉ mục dữ liệu là một nghệ thuật đen tối giống như Harry Potter đối với nhiều người, những người lập chỉ mục quá mức hoặc dưới chỉ mục, dẫn đến hiệu suất kém. Trước đây, các DBA thường tìm kiếm các chỉ mục dư thừa không còn được sử dụng hoặc các truy vấn phổ biến chưa được lập chỉ mục, sau đó sửa cơ sở dữ liệu để có hiệu suất tốt hơn. 

Cuối cùng, các DBA sẽ chịu trách nhiệm tự chạy các truy vấn để theo dõi hiệu suất theo thời gian bằng cách sử dụng BẢNG PHÂN TÍCH. Điều này sẽ cập nhật số liệu thống kê cho trình tối ưu hóa và gắn cờ bất kỳ khu vực nào mà các thay đổi hoặc bổ sung đã ảnh hưởng đến mức hiệu suất. Nếu không có thông tin chi tiết này, SRE có thể để lại các chỉ mục không còn cần thiết ở mức tốt nhất hoặc có ảnh hưởng tiêu cực đến hiệu suất ở mức tồi tệ nhất. 

Lập Kế hoạch trước

Ngoài ra còn có những bài học cần được học lại về mặt vận hành cơ sở dữ liệu. Ví dụ, có một câu nói cũ rằng DBA chỉ hoạt động tốt như bản sao lưu cuối cùng của họ. Mặc dù bạn có thể hy vọng rằng mình không bao giờ cần khôi phục dữ liệu sau sự cố, nhưng việc có một bản sao lưu hoạt động và được kiểm tra đầy đủ cho bất kỳ tệp quan trọng nào là điều cần thiết. Trong thế giới cơ sở dữ liệu, nhiều SRE hiện dựa vào nhà cung cấp đám mây để thực hiện việc này cho họ. Tuy nhiên, liệu điều này có đủ thỏa đáng? 

Mặc dù bạn có thể chỉ ra những gì Thỏa thuận cấp độ dịch vụ của bạn nêu rõ về quy trình sao lưu và khôi phục, nhưng điều này có thể không mô tả chính xác tốc độ bạn có thể sao lưu và chạy sau khi xảy ra sự cố. Thứ nhất, SLA này phụ thuộc vào khả năng sao lưu của bạn tốt và khả năng phục hồi hoàn toàn sau đó. Cho đến khi bạn thực sự tải lên bản sao lưu và bắt đầu sử dụng lại dữ liệu đó, bạn không thể chắc chắn rằng mình đã bảo vệ hoàn toàn hoạt động của mình. Thứ hai, thời gian SLA của bạn có thể rất khác so với lượng thời gian bạn có thể ngoại tuyến và không xử lý. Nhiệm vụ của DBA trước đây là có thể phát hiện tình trạng mất dữ liệu và đưa dữ liệu về trạng thái tốt. Mặc dù nhà cung cấp dịch vụ đám mây có thể cho bạn biết SLA của họ dành cho dữ liệu của bạn nhưng họ không nhất thiết phải cung cấp mọi thứ bạn cần để đáp ứng các yêu cầu dịch vụ nội bộ của bạn.

Tương tự, việc cấu trúc các bảng cơ sở dữ liệu đòi hỏi nhiều kiến ​​thức về cách quản lý dữ liệu. Mặc dù các nhà phát triển có thể hiểu cách sử dụng cơ sở dữ liệu để lưu trữ, sắp xếp và trả về dữ liệu họ cần cho ứng dụng của mình, nhưng có một số sắc thái liên quan đến cách căn chỉnh bảng hợp lý để tận dụng tối đa dữ liệu đó theo thời gian. Bên cạnh đó, việc hiểu đúng về mô hình quan hệ sẽ giúp bạn hiểu rằng việc phân chia dữ liệu thành các bảng riêng biệt sẽ gây ra hiệu suất kém. Ngoài ra còn có các thủ thuật dành riêng cho cơ sở dữ liệu mà bạn sử dụng như một phần của việc quản lý trực tiếp các phiên bản này – ví dụ: nhiều người không biết rằng MySQL hiện muốn bạn có khóa chính trên mỗi bảng hoặc PostgreSQL có thể cần đệm các bảng nếu các cột làm như vậy. không vừa khít với ranh giới tám byte. 

Tương lai cho quản lý dữ liệu

Dữ liệu ngày càng quan trọng trong các công ty. Nó cung cấp cơ sở để phục vụ khách hàng một cách hiệu quả nhưng cũng là trọng tâm của các dịch vụ kinh doanh mới hoặc các dự án phân tích chuyên sâu được sử dụng trong các sản phẩm mới. Nếu không có dữ liệu này, những sản phẩm đó – và doanh thu mà chúng mang lại – sẽ không tồn tại hoặc không mang lại giá trị mà chúng được thiết kế để cung cấp.

Đồng thời, các kỹ năng xung quanh việc quản lý dữ liệu đang bị rò rỉ ra khỏi các tổ chức, được đưa vào các vai trò rộng hơn hoặc được chuyển giao cho các nhà cung cấp dịch vụ. Khi mọi thứ đang hoạt động, điều này là tốt. Nhưng khi một vấn đề xảy ra, bạn sẽ cần kiến ​​thức chuyên sâu đó để giải quyết vấn đề và đảm bảo nó không xảy ra lần nữa. Điều đó cũng có nghĩa là bạn có thể chi tiêu nhiều hơn mức cần thiết để duy trì dữ liệu bạn lưu giữ và thực hiện công việc xung quanh dữ liệu đó.

Mặc dù vai trò của DBA đã được đảm nhận bởi các vị trí mới hơn về DevOps và SRE, nhưng các nhiệm vụ liên quan đến vai trò đó vẫn thuộc về chúng tôi. Đối với các chuyên gia SRE và DevOps, việc biết lý thuyết dữ liệu của bạn có thể là sự khác biệt giữa việc chi tiền mặt cho cơ sở hạ tầng và tiết kiệm hiệu suất.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
• PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
• PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
• nguồn: https://www.dataversity.net/devops-and-data-lessons-teams-can-learn-about-managing-databases/