# Ser Consultor de PostgreSQL

### El acercamiento

Esta mañana tuve una reunión con el CEO de una empresa de desarrollo de software y con parte de su equipo técnico. Fue una primera reunión de acercamiento que serviría para conocernos y hablar de sus necesidades de consultoría y capacitación acerca de PostgreSQL. En esa reunión inicial el equipo de desarrollo me habló de sus proyectos, de la manera que usan el lenguaje SQL y de sus inquietudes con la administración de sus bases de datos.

Como consultor, mi trabajo consiste en compartir mis conocimientos en PostgreSQL para ayudar a las empresas de todo tipo a resolver problemas tecnológicos de manera eficiente y a implementar soluciones avanzadas que les permitan aprovechar las prestaciones de un producto de software complejo y maduro, que se ha destacado en el ámbito del software libre desde el siglo pasado: PostgreSQL.

Para poder generar una propuesta de trabajo para una empresa en particular es necesario averiguar el nivel de conocimientos del equipo de desarrollo y entender sus necesidades específicas con respecto al manejo de sus datos. Al hacerlo, puedo personalizar mis recomendaciones y soluciones para atender sus necesidades específicas.

Durante mi entrevista con ellos puedo comprender cómo es que las aplicaciones de software que ellos desarrollan aprovechan las características del motor de la base de datos o si, en caso contrario, estás desaprovechando algunas características que les permitirían crear sistemas más eficientes, seguros y más administrables.

Así, una vez que entiendo sus necesidades, puedo proporcionar soluciones personalizadas para cada caso. Esto puede incluir recomendaciones de soporte y capacitación en algunos de los muchos temas que intervienen en el funcionamiento de un motor de base de datos, Las entrañas del monstruo Una de las tareas más interesantes y retadoras de dedicarse a ser consultor de PostgreSQL es el enfrentarse a la gran cantidad de temas que tienen que ver con el funcionamiento, puesta a punto y diseño de un artefacto tan complejo.

Entre los temas que debe manejar un administrador de base de datos o DBA (database administrator) destacan los siguientes:

* Diseño de las bases de datos: Relacional o dimensional.
    
* Uso de alguna herramienta para administrar el cluster: psql, pgAdmin y OmniDB.
    
* Instalación y configuración del cluster.
    
* Lenguaje PL/pgSQL para escribir procedimientos almacenados.
    
* Optimización de las diversas bases de datos.
    
* Monitoreo y diagnóstico.
    
* Seguridad.
    
* Mantenimiento.
    
* Respaldos y recuperación.
    
* Replicación.
    

Es claro que los temas no son pocos y que son de una extensa variedad de disciplinas aparentemente disconexas. No es extraño que un especialista en el tema de diseño de base de datos relacionales no sea el mismo que atienda los temas de replicación, por ejemplo.

Sin embargo, un DBA senior debe conocer a fondo el funcionamiento del sistema operativo donde reside la base de datos que va a administrar o contar con personal especializado en algunas de esas áreas, aunque es común que su experiencia en algunos temas sea mayor que en otros.

Los temas relevantes que deben conocerse para administrar adecuadamente un cluster de PostgreSQL son:

**Rendimiento**: El sistema operativo es el componente que administra los recursos del servidor, como la CPU, la memoria y los dispositivos de almacenamiento. Un DBA necesita saber cómo se asignan y administran estos recursos para garantizar que la base de datos tenga el rendimiento adecuado.

**Seguridad**: Un DBA debe conocer los aspectos de seguridad del sistema operativo, como la autenticación de usuarios, la configuración de permisos y la administración de cuentas de usuario. Esto ayuda a garantizar que solo los usuarios autorizados puedan acceder a la base de datos y que los datos estén protegidos de amenazas externas.

**Administración de recursos**: El sistema operativo es responsable de la administración de recursos del servidor, como la gestión de memoria y el control de procesos. Un DBA necesita comprender cómo se administran estos recursos para poder configurar la base de datos de manera eficiente y optimizar el uso de recursos.

**Solución de problemas**: Cuando ocurren problemas en la base de datos, el DBA debe poder identificar y solucionar el problema. Al conocer cómo funciona el sistema operativo, el DBA puede detectar problemas en el nivel del sistema operativo y tomar medidas para solucionarlos.

### La arquitectura de PostgreSQL

A lo largo del tiempo he visto la necesidad de que los desarrolladores y los DBA que he formado conozcan la arquitectura de PostgreSQL, es decir, los componentes que integran el sistema de la base de datos y cómo interactúan entre sí.

PostgreSQL utiliza una arquitectura del cliente/servidor, en la que un programa cliente se conecta a un proceso de servidor para comunicarse con la base de datos. El proceso del servidor administra la base de datos y maneja las solicitudes de clientes entrantes. El servidor puede manejar múltiples conexiones de cliente a la vez, y cada conexión de cliente está asociada con un proceso de backend separado.

Por otro lado, se utiliza un sistema de almacenamiento que se basa en un modelo de control de concurrencia de versiones múltiples (MVCC). Esto significa que múltiples versiones de una fila pueden existir al mismo tiempo, y diferentes transacciones pueden acceder a diferentes versiones de la misma fila sin interferir entre sí. Esto permite una alta concurrencia y escalabilidad.

Los procesos principales de la arquitectura son:

**Postmaster**: El proceso de postmaster es responsable de comenzar y detener el servidor PostgreSQL, así como la administración de conexiones del cliente. También genera los procesos de backend que manejan las solicitudes de los clientes.

**Escritor en segundo plano (background writer)**: el proceso backwriter escribe los datos de la memoria al disco para liberar espacio en la memoria. Esto ayuda a evitar que la base de datos se quede sin memoria.

**WAL Writer**: El proceso de escritura adelantada (WAL: Write Ahead Log) escribe cambios en el WAL, que es un registro de todos los cambios realizados en la base de datos. El WAL se usa para la recuperación de caídas y para replicación.

**Checkpointer**: el proceso de checkpointer escribe buffers sucios desde la memoria hasta el disco de manera periódica. Esto ayuda a garantizar que la base de datos sea duradera y pueda recuperarse de las caídas.

**Autovacuum**: el proceso Autovacuum limpia las filas muertas y libera el espacio en la base de datos. Esto ayuda a evitar que la base de datos se sature y se ralentize.

**Archiver**: El proceso de Archiver almacena los archivos WAL a una ubicación de archivo designada. Esto es útil para la recuperación de desastres y la replicación.

### La propuesta de consultoría

Para llevar a cabo esta tarea de manera efectiva es necesario planear adecuadamente el proyecto de consultoría. Es necesario definir los objetivos del proyecto, el plan de trabajo, el calendario y el presupuesto necesario.

Para definir los objetivos del proyecto, debemos conocer las necesidades específicas del equipo de desarrollo y establecer metas claras y alcanzables que les permitan mejorar su rendimiento y seguridad en sus sistemas. Estos objetivos pueden variar dependiendo de las necesidades de cada equipo, y pueden incluir desde optimización del rendimiento de la base de datos hasta la implementación de soluciones avanzadas de replicación y particionamiento de tablas.

Una vez definidos los objetivos del proyecto, es importante establecer un plan de trabajo detallado que incluya los pasos necesarios para alcanzarlos. Este plan de trabajo debe definir claramente las tareas a realizar, los plazos para completarlas, los recursos necesarios y los responsables de cada tarea. El plan de trabajo debe ser flexible y estar sujeto a modificaciones según las necesidades específicas del equipo de desarrollo.

En cuanto al calendario, es importante establecer un plazo razonable para completar el proyecto de consultoría. Este plazo debe tener en cuenta la complejidad de los objetivos establecidos y la disponibilidad de los recursos necesarios. Es importante tener en cuenta que un proyecto de consultoría bien planificado puede tomar varias semanas o incluso meses en completarse.

Por último, es necesario definir el presupuesto necesario para llevar a cabo el proyecto de consultoría. Este presupuesto debe incluir los costos de los recursos necesarios, como el tiempo del consultor, los costos de transporte, alojamiento y alimentación, así como los costos de los equipos necesarios para la capacitación y las pruebas de lo aprendido.

En este sentido, es fundamental contar con un equipo de cómputo y un cluster de PostgreSQL que permita al equipo de desarrollo realizar prácticas y pruebas de lo aprendido. Esto les permitirá familiarizarse con las herramientas y técnicas recomendadas, y posibilitará poner en práctica los conocimientos adquiridos en la consultoría.

En conclusión, para llevar a cabo una consultoría efectiva de PostgreSQL es necesario planificar adecuadamente el proyecto de consultoría, estableciendo objetivos claros, un plan de trabajo detallado, un calendario razonable y un presupuesto adecuado. Además, es necesario contar con los recursos necesarios, como un equipo de cómputo y un cluster de PostgreSQL, para que el equipo de desarrollo pueda practicar y poner en práctica lo aprendido. Con una planificación adecuada y los recursos necesarios, se puede llevar a cabo una consultoría exitosa que permita mejorar el rendimiento y seguridad de los sistemas de los equipos de desarrollo.

### **Fuentes**

[PostgreSQL Architecture Explained | by B.E. | Feb, 2023 | Dev Genius](https://blog.devgenius.io/postgresql-architecture-explained-2ce91aeffeba)

[PostgreSQL - System Architecture - GeeksforGeeks](https://www.geeksforgeeks.org/postgresql-system-architecture/)
