"Año de la lucha contra la corrupción e impunidad"

Universidad Nacional de San Martín - T

Facultad de ingeniería de sistemas e informática

Tema: Rendimiento

Gestor: PostgreSQL

Curso: Administración de base de datos.

Docente: Ing. Andy H. Rucoba Reátegui.

Integrantes:
 Paredes Flores Luis Adolfo
 Mori Vilcachagua Jeorge Michael
 Ruby Carrasco Lopez
 ÍNDICE

RENDIMIENTO
7.1.-Control de concurrencia. ....................................................................................................... 3
7.2.- Optimización de consultas, Heurística, Creación de índices, Plan de
Ejecución de Consultas ................................................................................................................ 5
7.3.- Estimación de costos de Procesamiento de consultas. ......................................................... 7
7.4.- Balanceo de Carga................................................................................................................ 7
7.5.- Demostración de rendimiento en el gestor. .......................................................................... 8
Bibliografía ................................................................................................................................. 11

2
7.1.-Control de concurrencia.
Según Guerrero (2019), el término concurrencia se refiere al hecho de que los DBMS
(Sistemas de Administración de Bases de Datos) permiten que muchas transacciones
accedan a una misma base de datos a la vez. Como bien es sabido, en un sistema de
éstos se necesita algún tipo de mecanismo de control de concurrencia para asegurar
que las transacciones concurrentes no interfieran entre sí El control de accesos
concurrentes y específicamente de transacciones concurrentes es manejado por un
módulo del DBMS llamado "Schedule". Es importante recordar que muchos de los datos
de la base no se encuentran nada más en disco, sino también en los buffers de memoria,
de ahí que el Schedule interactúa con ellos y en su defecto solicita la lectura de los datos
del disco.

Scheduler del DBMS El calendarizador crea agendas, secuencias ordenadas de las

acciones tomadas por una o más transacciones. El siguiente ejemplo muestra 2
transacciones cuya única característica de consistencia es que A=B ya que ambas
operaciones son iguales para ambos elementos. Por otro lado, sabemos que si las
transacciones son ejecutadas aisladamente la consistencia se preservará.

Según Chavez Atienzo(2013), Técnicas de Bloqueo es una de las principales técnicas

para controlar la ejecución concurrente de las transacciones se base en el concepto de
bloquea elementos de información un candado es una variable asociada a un elemento
de información de la base de datos y describe el estado de ese elemento respecto a las
posibles operaciones que se pueden aplicar a él en general hay un candado por cada
elemento de información en la base datos usamos los candados como una forma de
sincronizar el acceso a los elementos de la base de datos por parte de las transacciones
concurrentes la idea básica es simple cuando una transacción deba asegurarse de que
algún objeto en el que está interesada por lo general, una tupia de base de datos no
cambiará de ninguna forma mientras lo esté usando, adquiere un bloqueo sobre ese
objeto el efecto del bloqueo es "inhibir todas las demás transacciones" en ese objeto y
por lo tanto impedir que lo cambien por lo tanto la primera transacción es capaz de
realizar todo su procesamiento con el conocimiento certero de que el objeto en cuestión
permanecerá en un estado estable durante todo el tiempo que ésta lo desee. Se exige
que toda transacción del sistema siga un conjunto de reglas llamado protocolo de
bloqueo, que indica el momento en que una transacción puede bloquear y desbloquear
cada uno de los elementos de datos. Los protocolos de bloqueo restringen el número
de planificaciones posibles. Existen muchos modos mediante los cuales se puede
bloquear un elemento de datos. En este apartado se centra la atención en dos de dichos
modos:

1. Compartido. Si una transacción Ti obtiene un bloqueo en modo compartido

(denotado por C) sobre el elemento Q, entonces Ti puede leer Q pero no lo puede
escribir.

2. Exclusivo. Si una transacción Ti obtiene un bloqueo en modo exclusivo (denotado

por X) sobre el elemento Q, entonces Ti puede tanto leer como escribir Q.

3
Marcas de Tiempo Una marca de tiempo es un identificador único que el SGBD crea
identifica una transacción por lo regular los valores de marca de tiempo se asigna en el
orden en que las transacciones se introducen en el sistema porque lo una marca de
tiempo puede considerarse como el tiempo de inicio de una transacción nos referimos
a la marce de tiempo de una transacción T como MT (T) las técnicas para el control de
concurrencia basadas en marcas de tiempo no usan bloqueos, por tanto no puede haber
bloqueos mortales. Las marcas de tiempo se pueden generar de diversas maneras una
posibilidad consiste en usar un cantador que se incremente cada vez que su valor se
asigna a una transacción las marcas de tiempo de las transacciones están numeradas
1,2,3…. Un cantador de computador tiene un valor máximo finito por lo que el sistema
deberá restablecer periódicamente a cero el contador cuando haya un lapso corto en el
que ninguna transacción se esté ejecutando otra forma de implementar las marcas de
tiempo consiste en emplear el valor actual.

del reloj del sistema y asegurar que no se generen dos valores de marca de tiempo
antes de que el reloj cambie En lugar de determinar el orden entre las transacciones en
conflicto en función del momento del acceso a los elementos, determinan por adelantado
una ordenación de las transacciones. El interbloqueo es imposible. Una marca de tiempo
es un identificador único asociado a cada transacción. Las actualizaciones físicas se
retrasan hasta la confirmación de las transacciones. No se puede actualizar ningún
elemento actualizado por otra transacción más reciente

Control de Concurrencia Multiversion

Este control de concurrencia los valores antiguos de un elemento de información cuando

este se actualiza estos se conocen como técnicas de control de concurrencia de
multiversión por que se mantienen varias versiones valores de un elemento cuando una
transacción requiere acceso a un elemento se elige una versión apropiada para
mantener la seriabilidad del plan que se está ejecutando si es posible la idea consiste
en que algunas operaciones de lectura que será rechazadas si se usaran otras técnicas
se pueden aceptar leyendo una versión anterior del elemento a fin de mantener la
seriabilidad cuando una transacción escribe un elemento escribe una nueva versión y
se conserva la versión anterior de dicho elemento. Una desventaja obvia de las técnicas
de multiversión es que se requiere más almacenamiento para mantener múltiples
versiones de elementos de la base de datos sin embargo es posible que de todos modos
sea necesario mantener versiones anteriores.

Control de concurrencia optimista En Las Técnicas de control de concurrencia optimista

también llamadas técnicas de validación o de certificación no se efectúa verificación
alguna durante la ejecución de las transacciones varios métodos de control de
concurrencia propuestos utilizan la técnica de validación las actualizaciones incluidas

4
en una transacción no se aplican directamente a los elementos de la base datos sino
hasta que la transacción llega a su fin mientras se ejecuta la transacción todas las
actualizaciones se aplican a copias locales de los elementos que se mantienen para la
transacción al final de la ejecución una fase de validación comprueba si cualquiera de
las actualizaciones viola la serialidad el sistema debe mantener cierta información que
necesita para la fase de validación sin o se viola la serialidad la transacción se confirma
y la base de datos se actualiza a partir de la copias locales en caso contrario la
transacción aborta y se reinicia posteriormente. El protocolo de control de concurrencia
comprende tres fases:

1. Fase de lectura una transacción puede leer valores de elementos de información a

partir de la base datos sin embargo las actualizaciones se aplican solo a copias de los
elementos las que se mantiene en el espacio de trabajo de la transacción.
2. Fase de validación se efectúa una verificación para asegurar de que no se violaría la
seriabilidad si las actualizaciones de la transacción se aplican a la base de datos.
3. Fase de Escritura si la fase de validación se realiza con éxito las actualizaciones de
la transacción se aplican a la base de datos si no las actualizaciones se desechan y la
transacción se reinicia. La fase de validación de T verifica que para cada una de esas
transacciones T que está confirmada o en su fase de validación se cumpla una de las
siguientes condiciones.

7.2.- Optimización de consultas, Heurística, Creación de índices, Plan de

Ejecución de Consultas

Optimización de consultas

Según Wikipedia (2019), Cuando hablamos de optimización de consultas nos referimos

a mejorar los tiempos de respuesta en un sistema de gestión de bases de datos
relacional, pues la optimización es el proceso de modificar un sistema para mejorar su
eficiencia o también el uso de los recursos disponibles.
En bases de datos relacionales el lenguaje de consultas SQL es el más utilizado por el
común de los programadores y desarrolladores para obtener información desde la base
de datos. La complejidad que pueden alcanzar algunas consultas puede ser tal, que el
diseño de una consulta puede tomar un tiempo considerable, obteniendo no siempre
una respuesta óptima.

Es el proceso de selección del plan de evaluación de las consultas más eficiente entre
las estrategias disponibles para el procesamiento de una consulta dada. A través del
álgebra relacional intenta hallar una expresión equivalente a la expresión dada Elección
de una estrategia detallada para el procesamiento de la consulta.
 Selección del algoritmo que se usará para ejecutar una operación.
 Selección de los índices concretos que se van a emplear.

5
Optimización Heurística
Aplicación de reglas de transformación y heurísticas para modificar la representación
interna de una consulta (Algebra Relacional o Árbol de consulta) a fin de mejorar su
rendimiento. • Varias expresiones del Álgebra Relacional pueden corresponder a la
misma consulta. • Lenguajes de consulta, como SQL permiten expresar una misma
consulta de muchas formas diferentes, pero el rendimiento no debe depender de cómo
sea expresada la consulta.

Creación de índices.
Un índice de la base de datos es una estructura de datos que mejora la velocidad de las
operaciones en una tabla.

Cada vez que la aplicación ejecute una consulta de base de datos, la base de datos
buscará todas las filas de su tabla para encontrar las que coincidan con la solicitud. A
medida que crecen las tablas de la base de datos, es necesario inspeccionar cada vez
un número mayor de filas que a la vez, disminuye el rendimiento general de la base de
datos y, respectivamente, la aplicación.

Los índices resuelven este problema tomando datos de una columna en su tabla y
almacenándolos alfabéticamente en una ubicación separada llamada índice.
Plan de Ejecución de Consultas.
Según SqlShack (2015), en Planes de ejecución de consultas SQL, describimos los
planes de ejecución de consultas en SQL Server y por qué son importantes para el
análisis de desempeño

Un plan de ejecución estimado es un plan de consultas SQL que es generado sin

realmente correr la consulta (o procedimiento almacenado) para el cual el plan es
creado. Está basado en una estimación de comportamiento esperado. Es útil para
analizar cómo se comportaría una consulta sin realmente correrla. Esto es muy útil para
propósitos de pruebas en ambientes donde el desempeño no debería ser afectado al
correr el código real (por ejemplo, correr una sentencia SELECT con uniones complejas
con tablas enormes), o cuando correr el código no es posible debido a los cambios en
los datos que hace (por ejemplo, ejecutar un UPDATE). Su desventaja es que puede
ser poco preciso en algunos escenarios.

Un plan de ejecución real es el plan de consultas SQL que es generado después de que
una consulta fuera ejecutada. Es más confiable, y está basado en la ejecución real, no
estimados. También provee más información y estadísticas, por lo que es mucho más
útil al resolver problemas.

6
7.3.- Estimación de costos de Procesamiento de consultas.

 Se basa en estimaciones de coste de las operaciones

 Busca la estrategia de menor coste (puede NO ser la
óptima)
 Es el enfoque más apropiado para consultas compiladas
 En consultas interpretadas: conviene reducir el nº de estrategias (puede llevar
demasiado tiempo)
Componentes del coste

 Bloques transferidos: depende de las estructuras de acceso y de la colocación

de los bloques (contiguos, mismo cilindro, dispersos)
 Ficheros intermedios generados
 Cómputos en memoria sobre los ficheros intermedios: búsqueda, ordenación,
fusión, cálculos
 Comunicación: envío de la consulta y recepción del resultado coste principal:
 BD grandes: bloques transferidos
 BD pequeños (entran en memoria): cómputos.
 BD distribuidos: comunicación

7.4.- Balanceo de Carga

Según va de bits (2018), los tipos de balanceo para operaciones de consultas son:
Solo Lectura: este es el balanceo más sencillo dado que podemos disponer de
múltiples bases de datos de lectura de una manera sencilla y balancear nuestras
consultas sin demasiada dificultad, incluso si necesitamos hacerlo en diversas
localizaciones geográficas.
Escritura / Lectura: implica diferenciar entre consultas de escritura y de lectura,
enviando dichas consultas al servidor apropiado (master o slave respectivamente). Si
no necesitamos disponer de varios servidores master, este balanceo no resulta
demasiado complicado, ahora bien, si necesitamos realizar esto en diversas
localizaciones geográficas o con varios servidores master la cosa se complica.
Solo Escritura: este balanceo es más difícil de conseguir y su implementación puede
resultar compleja puesto que implica múltiples servidores maestros, y muy cara si
utilizamos soluciones comerciales (aunque obtendríamos funcionalidad adicional que
conviene tener en cuenta). En realidad, no tendría mucho sentido balancear solo las
operaciones de escritura (aunque imagino que habrá casos en los que una parte de una
aplicación o micro servicio solo escriba datos) y dado que nos vamos a complicar la vida
mejor hacerlo para lectura y escritura.
Las diversas soluciones de las que disponemos se pueden aplicar a todos los casos
mencionados, aunque hay que tener en cuenta que cada una de ellas tiene sus propios
beneficios y limitaciones. Como ya he dicho, todo depende de lo que tu aplicación
necesite y, como no, del dinero que tu o tu empresa esté dispuesta a gastarse puesto

7
que tenemos desde soluciones gratuitas, a soluciones empresariales que nos ofrecen
SLAs (Service Level Agreements) para solucionar nuestros problemas en tiempo récord.

7.5.- Demostración de rendimiento en el gestor.

Demostración del Rendimiento en el Gestor (Identifique las herramientas u opciones

dentro del sistema que permiten optimizar el rendimiento de una base de datos)

Muchas personas piensan que el aumento de rendimiento de una Base de Datos es

sinónimo de CPU, es decir mientras mejor es la CPU mejor es el rendimiento. Esto no
es cierto porque existen variantes más importantes que considerar al momento de tratar
de sacar el mejor provecho a nuestra Base de Datos.
Para empezar, se debe usar Servidores Dedicados para Bases de Datos, muchas
pymes utilizan los Servidores como equipos de almacenamiento, lo cual hace que un
servidor llegue a ser Servidor de Archivo, Correo y Base de Datos al mismo tiempo,
cuando fallan los sistemas siempre el culpable es la Base de Datos.
Actualizar a la última versión de postgres, siempre es importante ir actualizando los
sistemas a la última versión de Postgres (8.3 para producción y 8.4 beta 2), para obtener
un mejor rendimiento, superara lo bug y no tener que lamentar problemas indeseados.
Levantar un Servidor en Linux, está comprobado que Postgres obtiene el mejor
rendimiento con los Sistemas Operativos LINUX, eso no quiere decir que en Windows
esto funcione mal.
La selección del tipo de disco a utilizar, es recomendable discos Duros de alto
rendimiento ojalas en RAID o para las empresas pequeñas SATA.
Utilizar la mayor cantidad de Memoria RAM posible.
Separar el fichero de Datos y Log, en unidades de Disco diferentes.
Para concluir es necesario que revisen los siguientes parámetros:
Max_connections: Aplica la cantidad máxima de conexiones de clientes.
Shared_buffers: Determina cuanta memoria está dedicada a PostgreSQL para datos
en caché.
Effective_cache_size: Este debe ser establecido en un monto estimado de cuanta
memoria está disponible para memoria intermedia en el disco para el sistema operativo.
Checkpoint_segments: PostgreSQL escribe las nuevas transacciones a la Base de
Datos en un archivo llamado segmentos del WAL que son de 16MB de tamaño.
7.6.- Trabajo elaboración o demostración.
Trabajo: Elaborar una base de datos con dos tablas(X) como mínimo y que estén
relacionadas, y que tengan un millón de registros (puede ser más), y luego haga
una consulta que involucre las tablas, ejecútelo y mida el tiempo de
procesamiento, luego optimice la consulta y haga una comparación de los
tiempos de procesamiento, explique los resultados.

8
 Información básica del equipo:

Figura 1. Edición y sistema. Fuente: Propia

 Consulta a ejecutar:
SELECT V.CodEmpleado,E.Descripcion AS Empleado, P.Descripcion AS
Producto,
DV.Cantidad, DV.Precio, DV.SubTotal
FROM Ventas V, Empleado E, DetalleVentas DV, Producto P
WHERE (V.TransVenta = DV.TransVenta) AND
(DV.CodProducto = P.CodProducto) AND
(V.CodEmpleado = E.CodEmpleado) AND
(V.FechaVenta>'01/01/2014') AND
(V.CodAlmacen IN ('001','002'))
 Al ejecutar la consulta sin ningún tipo de índice podemos observar que el
tiempo de procesamiento fue de 39 segundos.

Figura 2. Consulta sin índices. Fuente: Propia

 Luego procedemos a crear los respectivos índices para ayudar a optimizar la

consulta, en este caso serían 4:
create index idx_ventas_codempleado on ventas(codempleado);
create index idx_empleado_descripcion on empleado(descripcion);

9
 create index idx_detalleventas_cantidadpreciosubtotal on
detalleventas(cantidad, precio, subtotal);
create index idx_producto_descripcion on producto(descripcion);
 Volvemos a ejecutar la respectiva consulta con los índices ya creados y
observamos que el tiempo de procesamiento mejoró a 16 segundos:

Figura 3. Consulta con índices. Fuente: Propia

10
Bibliografía
Control de concurrencia (2019) Obtenido de blogspot Guerrero.

http://guerrero-guerreros.blogspot.com/

Rendimiento de base de datos (2013) obtenido de blogspot Chavez Atienzo

http://chavez-atienzo-2013.blogspot.com/2013/04/rendimiento-de-una-base-de-
datos.html

Optimización de consultas (2019) Obtenido de Wikipedia

https://es.wikipedia.org/wiki/Optimizaci%C3%B3n_de_consultas

Optimización de consultas (2019) Obtenido de SiteGround

https://www.siteground.es/kb/optimizacion-mysql-usando-indexes/

Plan de ejecución (2015) obtenido de sqlshack

https://www.sqlshack.com/es/planes-de-ejecucion-de-consultas-sql-server-viendo-los-
planes/

Balanceo de carga (2018) obtenido de va de bits

https://www.vadebits.com/mysql-balanceo-de-bases-de-datos/

11