INSTITUTO TECNOLOGICO SUPERIOR DE ARANDAS

INGENIERIA EN SISTEMAS COMPUTACIONALES

ROCIO PARRA

Sistemas Gestores de Base de Datos

MAURICIO SANCHEZ BARAJAS

TRABAJO:

Arquitectura de 3 SGBD

FECHA: 09 de Marzo de 2015

Arquitectura de PostgreSQL

El siguiente gráfico muestra de forma esquemática las entidades involucradas en el funcionamiento normal del gestor de bases de datos:

PostgreSQL está basado en una arquitectura cliente-servidor. El programa servidor se llama postgres y entre los muchos programas cliente tenemos, por ejemplo, pgaccess (un cliente gráfico) y psql (un cliente en modo texto).

Un proceso servidor postgres puede atender exclusivamente a un solo cliente; es decir, hacen falta tantos procesos servidor postgres como clientes haya. El proceso postmaster es el encargado de ejecutar un nuevo servidor para cada cliente que solicite una conexión.

Se llama sitio al equipo anfitrión (host) que almacena un conjunto de bases de datos PostgreSQL. En un sitio se ejecuta solamente un proceso postmaster y

múltiples procesos postgres. Los clientes pueden ejecutarse en el mismo sitio o en equipos remotos conectados por TCP/IP.

Es posible restringir el acceso a usuarios o a direcciones IP modificando las opciones del archivo pg_hba.conf, que se encuentra en /etc/postgresql/pg_hba.conf.

Este archivo, junto con /etc/postgresql/postgresql.conf son particularmente importantes, porque algunos de sus parámetros de configuración por defecto provocan multitud de problemas al conectar inicialmente y porque en ellos se especifican los mecanismos de autenticación que usará PostgreSQL para verificar las credenciales de los usuarios.

Para habilitar la conexión a PostgreSQL desde clientes remotos, debemos verificar el parámetro tcpip_socket = true en el fichero /etc/postgresql/postgresql.conf.

A continuación, para examinar los métodos de autenticación y las posibilidades de conexión de clientes externos, debemos mirar el fichero /etc/postgresql/ pg_hba.conf, donde se explicita la acción que hay que emprender para cada conexión proveniente de cada host externo, o grupo de hosts.

ARQUITECTURA LÓGICA DEL MySQL

¿QUE ES SQL?

• Por sus siglas en inglés, structured query language.• El lenguaje de consulta estructurado o SQL es un lenguaje declarativo de

acceso a base de datos relacionales que permite especificar diversos tipos de operaciones en ellas.

• Una de sus características es el manejo del algebra y el cálculo relacional que permiten efectuar consultas con el fin de recuperar de forma sencilla información de interés de bases de datos, así como hacer cambios en ella.

TIPO DE DATOS

Los tipos datos básicos de SQL son:

• Date: una fecha de calendario que contiene el año (de cuatro cifras), el mes y el día.

• Time: La hora del día en horas minutos segundos (el valor predeterminado es 0).

• Timestamp: la combinación de Date y Time.

MOTORES DE ALMACENAMIENTO

Para el diseño físico del MySQL es necesario ver por sobretodo un buen motor de almacenamiento que es única en el mundo de las bases de datos.

Ahora veremos los elementos que esta puede implementar:

• Concurrencia: es necesario tener una política de bloqueo o ninguna, sin embargo esta causa de que el tiempo de procesamiento se vuelva mucho mas lento por lo cual la concurrencia no es alta.

• Soporte de transacciones

• Indexado: las diferentes técnicas de indexado pueden influir drásticamente es el rendimiento de una base de datos.

• Transacciones: dota de fiabilidad a los datos mientras se realizan• operaciones, te permite utilizar los datos pero sólo te permite guardarlos• cuando se comprueba que las otras condiciones que pudiesen requerirse

se• han cumplido.• Comprobación de la integridad referencial: incluye detalles detalles de la

representación en disco de información, sin embargo esta parte se cumple mas en lo que es almacenamiento físico.

• Soporte de índices, depende mucho de los detalles del almacenamiento físico, cada motor de almacenamiento proporciona sus propios métodos de indexación.

• Cachés de memoria, depende mucho de cómo procesan los datos las aplicaciones.

• Algunos motores pueden ser:• El motor InnoDB, soporta transacciones a cambio de un sacrificio de la

velocidad de lectura y escritura en un factor 1:10.• El motor MyISAM, este se caracteriza principalmente por ofrecer una

lectura y escritura rápidas. Además, es el único motor que posibilita la búsqueda fulltext.

Además de InnoDB y MyISAM existen los siguientes motores con unas características muy especiales:

• MEMORY: Mantiene los datos en memoria, lo que permite obtener una velocidad muy alta. Por contra, los datos se pierden al apagar el servidor.

• MERGE: Posibilita acceder a varias tablas con la misma estructura como si se tratase de una misma tabla.

• BLACKHOLE: Procesa todas las consultas pero no almacena los datos en ningún sitio. Es como un agujero negro.

CONECTORES

• MySQL ofrece conectividad controlador estándar de base de datos MySQL para utilizar con aplicaciones y herramientas que sean compatibles con estándares de la industria ODBC y JDBC. Cualquier sistema que trabaja con ODBC o JDBC puede usar MySQL.

• Los conectores MySql son los drivers que utilizan los programas cliente para conectarse al servidor, están disponibles para Windows y Unix.

• Para utilizar un conector debe instalarse en la máquina cliente. No es necesario que la maquina cliente y el servidor corran bajo el mismo sistema operativo.

GESTOR DE CONEXIONES

• Un gestor de conexión representa una agrupación de conexiones, en lugar de una única conexión de red cliente-servidor de MySQL.

• La agrupación de conexiones consiste en una conexión maestra, y opcionalmente cualquier número de conexiones esclavas.

• El gestor de conexiones de MySQL puede configurarse para limitar el número de conexiones concurrentes.

PROCESADOR DE CONSULTAS

• El procesamiento de consultas tiene varias etapas a seguir para resolver una consulta SQL, las características del modelo relacional permiten que cada motor de base de datos elija su propia representación que, comúnmente, resulta ser el álgebra relacional. La optimización de consultas es una de estas etapas.

• Cuando una consulta llega al gestor de MySQL, se analiza detalladamente y se produce una representación intermedia de la misma consulta.

• Posteriormente MySQL toma una serie de decisiones, que pueden incluir el determinar el orden de lectura de las tablas, el uso de ciertos índices, o la re-escritura de la consulta en una forma más eficiente.

OPTIMIZADOR DE CONSULTAS

• MySQL utiliza un optimizador basado en costos para determinar la mejor manera de resolver una consulta.

En muchos casos, MySQL puede calcular el mejor plan de consulta posible, pero a veces MySQL no tiene suficiente información sobre los datos a mano y tiene que hacer suposiciones “educadas” sobre los datos.

• EXPLAIN, mediante esta podemos obtener toda la información sobre el modo en el que una consulta SQL se ejecutaría en el servidor. Es extremadamente útil para conocer la configuración de índices en las tablas, los índices que podrían ser configurados para mejorar su rendimiento, el número de filas que se revisan, el tipo de query, etc.

CACHE DE CONSULTAS

• La caché de consultas es muy útil en un entorno donde tiene tablas que no cambian frecuentemente y donde el servidor recibe muchas consultas idénticas.

• La caché de consultas no devuelve datos antiguos, después de haber hecho una modificación en las tablas.

• La caché de consultas no se usa para comandos preparados en la parte del servidor.

• Actualmente para MySQL 5.0 Server se proporciona una query cache. Cuando se usa, la query cache almacena el texto de una consulta SELECT junto con el resultado que se le envió al cliente.

CONTROL DE CONCURRENCIA

• El acceso simultáneo descrito puede dar como resultados información incorrecta, dependiendo de la suerte que tengamos en la intercalación de las lecturas y escrituras simultáneas. Esta problemática ha llevado a diseñar e implementar diferentes estrategias de control de concurrencia, que se encargan de evitar todos esos problemas, de modo que los desarrolladores de las aplicaciones pueden “olvidarse” de ellos al escribir su código.

• MySQL tiene un apoyo limitado para el control de concurrencia. Como en la versión 3.0, no hay soporte para transacciones y, por lo tanto, no hay nivel de aislamiento de transacción. Tampoco es posible revertir transacciones.

GESTOR DE RECUPERACIÓN

• El gestor de recuperación es responsable de restaurar la base de datos a su estado estable pasado.

• Tal operación lo realiza usando el registro para la base de datos, que se adquiere del encargado del almacenador intermediario, y ejecutando cada operación en el registro.

Desde los registros del encargado del registro todas las operaciones realizadas en la base de datos (del principio de la vida de la base de datos), ejecutando cada comando en el fichero de diario recuperarían la base de datos a su estado estable pasado.

GESTOR DE TRANSACCIONES

Una transacción es una sola unidad del trabajo que tiene unos o más comandos de MySQL en ella. El gestor de transacciones es responsable de cerciorarse de que la transacción está registrada y ejecutada atómico.

Si existiera algún error, estas podrías ser por:

• Error lógico (violación de restricciones, tipos incompatibles, etc.).• Error del sistema (interbloqueos, espacio insuficiente,etc.).

Arquitectura de Bases de Datos SQL Server

La arquitectura interna de las bases de datos en SQL Server está compuesta por 2 tipos de estructura, la estructura lógica y la estructura física. Es muy importante conocer cómo es que estas estructuras están compuestas y cuál es la relación que tienen los objetos de base de datos con cada una de estas estructuras.

Estructura Lógica:

Desde el punto de vista lógico, la base de datos debe tener al menos 1 “FileGroup” el cual contiene a toda la metadata de la misma base de datos, es decir tablas y vistas de sistema, a este “FileGroup” inicial se le conoce como “Primario” y está presente en todas las bases de datos. Todos los objetos de usuario que contengan data, ya sean tablas o índices, deben estar ligados a un “FileGroup”, esto se puede definir al momento de ejecutar la sentencia DDL de creación del objeto, si no se indica a que “FileGroup” estará ligado ese objeto, este pertenecerá al “FileGroup” por defecto definido en la base de datos. La base de datos solo puede tener definido 1 solo default “FileGroup”.

Las bases de datos pueden tener hasta 32767 “FileGroups” definidos, según los límites establecidos para la última versión de SQL Server, la cual es SQL Server 2008 R2. Uno de los propósitos de los “FileGroups” es poder distribuir la data a través de varios discos duros físicos, de esta manera se puede obtener mayor

rendimiento en las operaciones de I/O debido a que más de un disco trabajara al mismo tiempo. Otro de los propósitos es poder esconder la ubicación física real de la información a los programadores, ya que para ellos la tabla “X” pertenece al “FileGroup” “A”, pero no saben en que data files físicamente se encuentra la información de la tabla “X”.

Los “FileGroups” pueden contener 1 o más “Datafiles”, y cada uno de estos datafiles se pude encontrar en un discos diferentes, lo cual también agilizara las consultas y los ingresos de información a las tablas que se encuentren asignadas a este “FileGroup”, debido a que SQL Server distribuirá la información uniformemente a través de todos los “DataFiles” del “FileGroup”.

Estructura Física:

Desde el punto de vista físico, como ya hemos visto, tenemos los “DataFiles” que los en realidad los archivos de datos, es decir donde se guarda toda la información de la base de datos. Un “DataFile” solo puede pertenecer a 1 “FileGroup”.

Internamente los “DataFiles” están divididos en “Extends” y estos a su vez en “Pages”. Las “Pages” son la unidad minima de almacenamiento dentro de la base de datos. Un “Page” tiene 8 Kb de tamaño en espacio de disco. Un “Extend” tiene 8 “Pages” contiguas que lo conforman, es decir, un “Extend” tiene como tamaño 64 Kb de espacio en disco.

En un “Page” solo puede haber información de 1 sola tabla, es decir el espacio de un “Page” no es compartido entre tablas o índices. En el caso de los “Extends”, estos pueden ser de dos tipos:

• “Mixed”: Los cuales son compartidos hasta por 8 objetos, uno por cada “Page”.

• “Uniform”: Los cuales solo pertenecen a un solo objeto, es decir que todos los “Pages” pertenecen a un solo objeto.

Normalmente cuando se crea una nueva tabla esta es asignada a un “Extend” de tipo “Mixed”, hasta alcanzar la utilización de hasta 8 “Pages”, a partir de ese momento se asignan “Extends” de tipo “Uniform” para optimizar el uso del espacio en la tabla.

Los “DataFiles” normalmente tienen 2 extensiones de archivo, las cuales son estandar mas no obligarias, la extencion “mdf” que se utiliza para el primer “Datafile” perteneciente al “FileGroup” primario, y la extension “ndf” que se utiliza

para los demas datafiles que se agregan posteriormente a los demas “FileGroups” de la base de datos.

En el caso del “LogFile”, este no pertenece a un “FileGroup” en especifico, en cambio archivo esta ligado directamente a la base de datos. Las bases de datos de SQL Server solo pueden tener un solo “LogFile” activo al mismo tiempo, si bien se pueden crear multiples “LogFiles” en la base de datos, solo uno podra ser escrito, ya que solo uno puede estar activo, cuando este archivo se llene, la base de datos pasara a escribir al siguiente archivo de transacciones, y asi sucesivamente. Por esta razon no es muy conveniente ni util tener mas de un “LogFile”.

En conclusión espero que sea de ayuda estas explicaciones sobre la arquitectura de una base de datos de SQL Server, si desean temas por favor no duden en solicitarlo, haré lo posible para poder cubrir los temas solicitados en el mas corto tiempo.