Según la Oficina de Estadísticas Laborales, las perspectivas para los empleos relacionados con la gestión de arquitectura de datos y bases de datos parecen bastante buenas: la cantidad de profesionales con funciones relacionadas con la gestión de datos es debido a crecer en un ocho por ciento entre 2022 y 2032. Sin embargo, si bien el número de roles que trabajan con datos está aumentando, el puesto de administrador de bases de datos (DBA) por sí solo en realidad está disminuyendo. En cambio, el rol de especialista de DBA ha sido reemplazado por el de ingeniero de confiabilidad del sitio (SRE) del mundo DevOps.
El rol de SRE se desarrolló en Google, aplicando sus habilidades en torno a la gestión y operaciones de sitios web a otras áreas de la tecnología. Los SRE tienen un alcance laboral mucho más amplio que el de un DBA, cubriendo los mismos tipos de tareas como gestión operativa, disponibilidad, redundancia del sistema y seguridad, pero para toda la infraestructura de TI, no solo las bases de datos existentes. Sin embargo, las tareas realizadas por los DBA no han disminuido y hay matices que los DBA pueden entender y otros empleados no.
¿A qué problemas se enfrentan los DBA?
Si bien la mayoría de los SRE podrán administrar instancias de bases de datos y mantenerlas en funcionamiento, no tendrán la experiencia y el conocimiento profundos que tendrá alguien que se haya concentrado en la teoría y la administración de bases de datos. Cuando sucede algo fuera de lo común, las SRE tendrán que entender qué está pasando y si pueden solucionar el problema, o si necesitarán llamar a un experto.
Un buen ejemplo de esto es cómo configurar y administrar lenguaje de consulta estructuradoo SQL. SQL puede ser el lenguaje más popular del IEEE en 2023, pero tiene una sintaxis complicada que relativamente pocos se dedican a dominar. Muchos desarrolladores no están familiarizados con cómo escribir consultas SQL efectivas y eficientes, por lo que pueden terminar con solicitudes de bajo rendimiento que tardan más en devolver resultados. Alternativamente, los desarrolladores suelen recurrir a mapeadores relacionales de objetos (ORM) para manejar sus solicitudes SQL. Si bien los ORM pueden simplificar la situación para los desarrolladores, pueden sufrir el mismo rendimiento deficiente y el mismo diseño de consulta incorrecto que escribir su propio código SQL, junto con la necesidad de actualizar y administrar el propio ORM. Esta combinación a menudo se ve junto con una inclinación por utilizar transacciones de larga duración que sofocan el rendimiento.
Para los DBA, detectar estos problemas y corregirlos era parte del trabajo de tiempo completo. Sin embargo, para los SRE que no están familiarizados con el rendimiento de las bases de datos, estas transacciones lentas pueden aceptarse como "tal como son las cosas" en lugar de un síntoma de que algo anda mal. Alternativamente, los desarrolladores pueden intentar dedicar más recursos al problema comprando máquinas más grandes o instancias en la nube para ejecutar.
Además del diseño de consultas, los DBA también eran responsables de configurar índices de datos en sus bases de datos. Para muchos, la indexación de datos es un arte oscuro al estilo de Harry Potter, que indexa demasiado o subíndice, lo que conduce a un rendimiento deficiente. En el pasado, los DBA solían buscar índices redundantes que ya no se usaban o consultas populares que no habían sido indexadas y luego corregir la base de datos para mejorar el rendimiento.
Por último, los DBA serían responsables de ejecutar consultas ellos mismos para realizar un seguimiento del rendimiento a lo largo del tiempo utilizando ANALYZE TABLE. Esto mantendría actualizadas las estadísticas del optimizador y señalaría cualquier área donde los cambios o adiciones hubieran afectado los niveles de rendimiento. Sin esta información, los SRE pueden dejar índices que, en el mejor de los casos, ya no son necesarios o, en el peor, que afectan negativamente el rendimiento.
Planeando por adelantado
También hay lecciones que es necesario volver a aprender en el aspecto operativo de las bases de datos. Por ejemplo, hay un viejo dicho que dice que un DBA es tan bueno como su última copia de seguridad. Si bien es posible que nunca necesite recuperar datos después de un problema, es esencial tener una copia de seguridad funcional y completamente probada para cualquier archivo crítico. En el mundo de las bases de datos, muchas SRE ahora dependen de su proveedor de nube para que las ejecute por ellos. Sin embargo, ¿es esto suficiente para ser adecuado?
Si bien puede indicar lo que establece su Acuerdo de nivel de servicio sobre un proceso de copia de seguridad y restauración, es posible que esto no refleje con precisión la rapidez con la que puede volver a funcionar después de un problema. En primer lugar, este SLA depende de que su copia de seguridad sea buena y de que pueda recuperarse completamente de ella. Hasta que no haya cargado una copia de seguridad y haya comenzado a usar esos datos nuevamente, no podrá estar seguro de haber protegido completamente sus operaciones. En segundo lugar, su tiempo de SLA puede ser muy diferente de la cantidad de tiempo que puede permitirse estar fuera de línea y sin procesar. Solía ser deber del DBA poder detectar la pérdida de datos y devolverlos a un buen estado. Si bien un proveedor de servicios en la nube puede decirle cuál es su SLA para sus datos, no necesariamente le proporcionará todo lo que necesita para cumplir con sus requisitos de servicio interno.
De manera similar, estructurar tablas de bases de datos requiere mucho conocimiento sobre cómo se administran los datos. Si bien los desarrolladores pueden comprender cómo se pueden utilizar las bases de datos para almacenar, ordenar y devolver los datos que necesitan para sus aplicaciones, existen algunos matices en cómo alinear correctamente las tablas para aprovechar al máximo esos datos a lo largo del tiempo. Además de esto, tener una comprensión adecuada del modelo relacional le ayuda a comprender que la compartimentación de datos en tablas separadas provoca un rendimiento deficiente. También hay trucos específicos de bases de datos que puede aprender como parte de la gestión directa de estas instancias; por ejemplo, muchos no saben que MySQL ahora quiere que tenga claves primarias en cada tabla, o que PostgreSQL puede necesitar rellenar las tablas si las columnas las tienen. no encaja bien en un límite de ocho bytes.
El futuro de la gestión de datos
Los datos son cada vez más importantes dentro de las empresas. Proporciona la base para atender a los clientes de manera eficiente, pero también está en el centro de nuevos servicios comerciales o proyectos de análisis profundo que se utilizan en nuevos productos. Sin estos datos, esos productos (y los ingresos que generan) no existen o no logran ofrecer el valor para el que fueron diseñados.
Al mismo tiempo, las habilidades en torno a la gestión de datos se están escapando de las organizaciones, subsumidas en roles más amplios o entregadas a proveedores de servicios. Cuando todo funciona, esto está bien. Pero cuando surge un problema, necesitará ese conocimiento profundo para resolverlo y asegurarse de que no vuelva a suceder. También significa que puede gastar más de lo necesario para mantener los datos que conserva y solucionarlos.
Si bien la función del DBA ha sido asumida por puestos más nuevos en torno a DevOps y SRE, las tareas asociadas con esa función todavía están con nosotros. Para los profesionales de SRE y DevOps, conocer su teoría de datos puede marcar la diferencia entre gastar dinero en infraestructura y ahorrar en rendimiento.
- Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
- PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
- PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
- PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
- PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
- Fuente: https://www.dataversity.net/devops-and-data-lessons-teams-can-learn-about-managing-databases/
