Almacenamiento físico de Postgresql: diseño de archivos de base de datos

Esta sección describe el formato de almacenamiento a nivel de archivos y directorios.

Tradicionalmente, los archivos de configuración y datos utilizados por un clúster de base de datos se almacenan juntos dentro del directorio de datos del clúster, comúnmente conocido como PGDATA (después del nombre de la variable de entorno que se puede usar para definirla). Un lugar común para PGDATA es /var/lib/pgsql/data. Pueden existir varios clústeres, administrados por diferentes instancias de servidor, en la misma máquina.

los PGDATA El directorio contiene varios subdirectorios y archivos de control, como se muestra en la Tabla 68.1. Además de estos elementos necesarios, los archivos de configuración del clúster postgresql.conf, pg_hba.conf, y pg_ident.conf se almacenan tradicionalmente en PGDATA, aunque es posible colocarlos en otro lugar.

Tabla 68.1. Contenido de PGDATA

Para cada base de datos del clúster hay un subdirectorio dentro PGDATA/base, llamado así por el OID de la base de datos en pg_database. Este subdirectorio es la ubicación predeterminada para los archivos de la base de datos; en particular, los catálogos de su sistema se almacenan allí.

Tenga en cuenta que las siguientes secciones describen el comportamiento de la función incorporada. heapmétodo de acceso a la tabla y el métodos de acceso al índice. Debido a la naturaleza extensible de PostgreSQL, otros métodos de acceso pueden funcionar de manera diferente.

Cada tabla e índice se almacena en un archivo separado. Para las relaciones ordinarias, estos archivos reciben el nombre de la tabla o índice filenode número, que se puede encontrar en pg_class.relfilenode. Pero para las relaciones temporales, el nombre del archivo tiene la forma tBBB_FFF, dónde BBB es el ID de backend del backend que creó el archivo, y FFF es el número de nodo de archivo. En cualquier caso, además del archivo principal (a / k / a main fork), cada tabla e índice tiene un mapa del espacio libre (ver Sección 68.3), que almacena información sobre el espacio libre disponible en la relación. El mapa de espacio libre se almacena en un archivo llamado con el número de nodo de archivo más el sufijo _fsm. Las tablas también tienen mapa de visibilidad, almacenado en un tenedor con el sufijo _vm, para rastrear qué páginas se sabe que no tienen tuplas muertas. El mapa de visibilidad se describe con más detalle en la Sección 68.4. Las tablas e índices no registrados tienen una tercera bifurcación, conocida como bifurcación de inicialización, que se almacena en una bifurcación con el sufijo _init (consulte la Sección 68.5).

Precaución

Tenga en cuenta que si bien el nodo de archivo de una tabla a menudo coincide con su OID, esto es no necesariamente el caso; algunas operaciones, como TRUNCATE, REINDEX, CLUSTER y algunas formas de ALTER TABLE, puede cambiar el nodo de archivo conservando el OID. Evite asumir que filenode y table OID son iguales. Además, para ciertos catálogos de sistemas, incluidos pg_class sí mismo, pg_class.relfilenode contiene cero. El número de nodo de archivo real de estos catálogos se almacena en una estructura de datos de nivel inferior y se puede obtener utilizando la pg_relation_filenode() función.

Cuando una tabla o índice supera 1 GB, se divide en gigabytes segmentos. El nombre de archivo del primer segmento es el mismo que el del nodo de archivo; los segmentos posteriores se denominan filenode.1, filenode.2, etc. Esta disposición evita problemas en plataformas que tienen limitaciones de tamaño de archivo. (En realidad, 1 GB es solo el tamaño de segmento predeterminado. El tamaño del segmento se puede ajustar mediante la opción de configuración --with-segsize al construir PostgreSQL.) En principio, el mapa de espacio libre y las bifurcaciones del mapa de visibilidad también podrían requerir múltiples segmentos, aunque es poco probable que esto suceda en la práctica.

Una tabla que tiene columnas con entradas potencialmente grandes tendrá un BRINDIS tabla, que se utiliza para el almacenamiento fuera de línea de valores de campo que son demasiado grandes para mantenerlos en las filas de la tabla. pg_class.reltoastrelid enlaces de una tabla a su tabla TOAST, si la hubiera. Consulte la Sección 68.2 para obtener más información.

El contenido de las tablas y los índices se analiza con más detalle en la Sección 68.6.

Los espacios de tabla hacen que el escenario sea más complicado. Cada espacio de tabla definido por el usuario tiene un enlace simbólico dentro del PGDATA/pg_tblspc directorio, que apunta al directorio del espacio de tabla físico (es decir, la ubicación especificada en el espacio de tabla CREATE TABLESPACE mando). Este enlace simbólico lleva el nombre del OID del espacio de tabla. Dentro del directorio del espacio de tabla físico hay un subdirectorio con un nombre que depende de la versión del servidor PostgreSQL, como PG_9.0_201008051. (La razón para usar este subdirectorio es para que las versiones sucesivas de la base de datos puedan usar el mismo CREATE TABLESPACE valor de ubicación sin conflictos.) Dentro del subdirectorio específico de la versión, hay un subdirectorio para cada base de datos que tiene elementos en el espacio de tabla, nombrados según el OID de la base de datos. Las tablas y los índices se almacenan dentro de ese directorio, utilizando el esquema de nomenclatura de filenode. los pg_default no se accede al tablespace a través de pg_tblspc, pero corresponde a PGDATA/base. Del mismo modo, el pg_global no se accede al tablespace a través de pg_tblspc, pero corresponde a PGDATA/global.

los pg_relation_filepath() La función muestra la ruta completa (relativa a PGDATA) de cualquier relación. Suele ser útil como sustituto de recordar muchas de las reglas anteriores. Pero tenga en cuenta que esta función solo da el nombre del primer segmento de la bifurcación principal de la relación; es posible que deba agregar un número de segmento y / o _fsm, _vm, o _init para encontrar todos los archivos asociados con la relación.

Los archivos temporales (para operaciones como ordenar más datos de los que caben en la memoria) se crean dentro de PGDATA/base/pgsql_tmp, o dentro de un pgsql_tmp subdirectorio de un directorio de espacio de tabla si un espacio de tabla que no sea pg_default se especifica para ellos. El nombre de un archivo temporal tiene la forma pgsql_tmpPPP.NNN, dónde PPP es el PID del backend propietario y NNN distingue diferentes archivos temporales de ese backend.