PostgreSQL: arquitectura del sistema

PostgreSQL es un sistema de gestión de bases de datos de código abierto que tiene una naturaleza relacional de objetos. PostgreSQL es un sucesor de uno de los primeros sistemas, es decir, el sistema POSTGRES. Es uno de los sistemas de gestión de bases de datos de código abierto más utilizados.

PostgreSQL tiene un modelo de arquitectura cliente-servidor. En el término más simple, un servicio PostgreSQL tiene 2 procesos:

• Proceso del lado del servidor: esta es la aplicación «Postgres» que administra conexiones, operaciones y activos estáticos y dinámicos.
• Proceso del lado del cliente (aplicaciones front-end): estas son las aplicaciones que los usuarios usan para interactuar con la base de datos. Generalmente tiene una interfaz de usuario simple y se usa para comunicarse entre el usuario y la base de datos generalmente a través de API.

Proceso del lado del cliente:

Cuando el usuario ejecuta consultas en PostgreSQL, la aplicación del cliente puede conectarse al servidor de PostgreSQL (proceso de Postmaster Daemon) y enviar consultas a través de una de las muchas interfaces del programa de la aplicación del cliente de la base de datos compatibles con PostgreSQL como JDBC, Perl DBD, ODBC, etc. que ayuda a proporcionar bibliotecas del lado del cliente. En el proceso del cliente, la comunicación entre la aplicación del cliente y la biblioteca de la aplicación del cliente se produce con la ayuda de la API de la biblioteca, como se muestra en la siguiente figura:

1. Proceso del Demonio Postmaster:

La arquitectura del sistema de PostgreSQL se basa en el modelo de proceso por transacción (modelo de cliente/servidor). Un sitio de PostgreSQL en ejecución es administrado por Postmaster , que es un proceso de coordinación central. También se conoce como Proceso de Servidor.

El proceso del demonio postmaster es responsable de:

• Inicializando el servidor
• Apagar el servidor
• Manejo de requests de conexión de nuevos clientes.
• Realizar Recuperación.
• Ejecutar procesos en segundo plano.

Memoria compartida:  la memoria compartida es la memoria a la que varios programas acceden simultáneamente para proporcionar resultados rápidos y eficientes con menos redundancia. Esta es la memoria que está reservada para el almacenamiento en caché de la base de datos y el almacenamiento en caché del registro transaccional. En PostgreSQL se utilizan el búfer de disco compartido y las tablas compartidas, cuyo funcionamiento se explica a continuación:

Búfer de disco compartido: el propósito del búfer de disco compartido es minimizar la entrada/salida del disco. Si no se usa, la entrada/salida del disco lleva más tiempo, lo que provoca redundancia y un sistema ineficiente. Las ventajas de utilizar un búfer compartido son:

• Reducir el tiempo.
• Puede acceder a una gran cantidad de datos fácilmente.
• Minimice el calentamiento cuando varios usuarios acceden al mismo tiempo.

Tablas compartidas: este enfoque implica el uso del mismo conjunto de tablas para alojar varios datos de clientes. Las principales ventajas de utilizar este enfoque son:

• El costo de hardware más bajo
• El costo de copia de seguridad más bajo
• Permite trabajar con grandes datos en una única base de datos.

Sistema UNIX: en el búfer de disco del núcleo del sistema UNIX, mantenga un búfer de memoria y proporcione almacenamiento físico a los datos en el almacenamiento en disco. Además, los comandos de PostgreSQL se verifican que la sintaxis escrita es correcta y proporcionan un mensaje de error con el motivo de que falta en el comando, etc.

2. Proceso de fondo:

El Postmaster es responsable de manejar las conexiones iniciales del cliente. Para esto, escucha constantemente nuevas conexiones como un puerto conocido. Después de realizar un proceso de inicialización, como la autenticación del usuario, el postmaster dará lugar a un nuevo proceso de servidor backend para manejar el nuevo cliente. El cliente interactúa solo con el proceso del servidor backend, como enviar consultas y recibir el resultado de las consultas. Esto mostrará que PostgreSQL realmente usa el modelo de proceso por transacción.

El servidor backend es responsable de ejecutar las consultas enviadas por el cliente mediante la realización de operaciones específicas. Cada servidor backend manejará solo una consulta a la vez. A la vez, varios clientes están conectados al sistema, por lo tanto, varios servidores back-end ejecutan consultas al mismo tiempo. Los datos de acceso del servidor back-end del grupo de búfer de la memoria principal que se coloca en la memoria compartida.

Luego de eso, el resultado obtenido es proporcionado al Proceso del Cliente por el Proceso de Back-end.

Escritor de WAL (registro de escritura anticipada)	Este proceso escribe y vacía los datos WAL en el búfer WAL
colector de registro	Este proceso también se llama registrador. Escribirá un mensaje de error en el archivo de registro.
Lanzador de vacío automático	Cuando el vacío automático está habilitado, este proceso tiene la responsabilidad del daemon de vacío automático para realizar operaciones de vacío en tablas infladas. Este proceso se basa en el proceso de recopilación de estadísticas para un análisis de tabla perfecto.
archivador	Cuando Achiever está habilitado, el proceso tiene la responsabilidad de copiar el archivo de registro WAL en el directorio especificado.
colector de estadísticas	En estas estadísticas se recopila información como pg_stat_activity  y pg_stat_all_tables
punto de control	Cuando se produce un punto de control, el búfer sucio escribe en el archivo.
escritor	Periódicamente escribirá el búfer sucio en el archivo.

3. Piscina compartida:

El grupo compartido es un área de RAM dentro del montón de RAM que se crea durante el tiempo de inicio. Un grupo compartido es un componente de SGA (Área global del sistema). Si Shared Pool no está disponible en la RAM o no se usa, entonces resulta en recargas altas de caché de biblioteca, recargas altas de caché de fila. El grupo compartido es un área de RAM dentro del montón de RAM que se crea durante el tiempo de inicio. Un grupo compartido es un componente de SGA (Área global del sistema). Si Shared Pool no está disponible en la RAM o no se usa, entonces resulta en recargas de caché de biblioteca altas, recargas de caché de fila alta. 

¿Por qué PostgreSQL no usó Shared Pool?

PostgreSQL no proporciona un grupo compartido, aunque la mayoría de los sistemas de bases de datos como Oracle, el grupo compartido es un componente importante de su estructura. No es así porque PostgreSQL proporcionará una característica para compartir información de SQL a nivel de proceso en comparación con Shared Pool. Simplemente, si el usuario ejecutará la misma consulta SQL varias veces en un proceso, analizará de forma exhaustiva solo una vez, lo que es ventajoso sobre otros sistemas de base de datos porque, en otro sistema de base de datos que utiliza un grupo compartido, el análisis exhaustivo ocurre para un declaración SQL única que se carga desde el grupo compartido. Si el usuario ejecuta simultáneamente una sola consulta SQL varias veces, causará más carga.

4. OID en PostgreSQL:

OID significa tipos de identificadores de objetos. PostgreSQL utiliza OID como clave principal para varias tablas del sistema. Se implementa como un entero de cuatro bytes sin signo. También podemos tener una opción para usar OID en la tabla definida por el usuario como «CON OIDS», pero se desaconseja su uso porque no es lo suficientemente grande como para proporcionar unicidad en una tabla grande definida por el usuario. Los OID generalmente se adaptan mejor a las tablas del sistema. Básicamente, proporciona una identificación integrada para cada fila, contenida en la columna del sistema.

En la versión PostgreSQL 12, la característica de OID para las tablas de usuario se eliminó indirectamente, es decir, podemos usar OID explícitamente.

Méritos de PostgreSQL:

• PostgreSQL es una base de datos altamente tolerante al riesgo y requiere un bajo costo de mantenimiento.
• Utiliza la pila LAMP (Linux, Apache, MySQL, PHP) para ejecutar un sitio web dinámico y una aplicación web.

Deméritos de PostgreSQL:

• Es un poco lento en comparación con una base de datos comercial.
• No es compatible con las diversas aplicaciones de código abierto en comparación con MYSQL.