Download OPTIMIZACIÓN DE LA BASE DE DATOS DEL SISTEMA XAVIA HIS

OPTIMIZACIÓN DE LA BASE DE DATOS DEL SISTEMA XAVIA
HIS
OPTIMIZATION’S OF THE DATA BASE OF XAVIA HIS SYSTEM
Yosvany Arrastia Machin1, Gladilis de la Caridad Barrera Garrido2, Rosnel Venero Acosta3
1 Universidad de las Ciencias Informáticas, Cuba,[email protected], Carretera a San Antonio de los Baños Km 2 ½ Torrens.
Boyeros, Ciudad de La Habana.
2 Universidad de Sancti Spíritus “José Martí Pérez”, Cuba, [email protected]
3 Universidad de las Ciencias Informáticas, Cuba, [email protected]
RESUMEN: El Sistema de Información Hospitalaria (Xavia HIS) se encarga de la gestión médica de hospitales
y centros de salud, el personal médico tiene a su alcance una plataforma que le permite la gestión clínica y
administrativa. Este sistema puede manejar gran volumen de datos por lo que se puede ver afectado el
rendimiento del mismo, la disponibilidad y gestión de los datos. En la presente investigación se propone
optimizar el servidor de la base de datos postgresSQLdel sistema Xavia HIS y realizar el particionado de sus
tablas más críticas. En la primera parte se hace un análisis de las posibles técnicas de particionado a utilizar,
eligiéndose la horizontal y se ilustra mediante un ejemplo cómo quedan las tablas particionadas. Luego se
ajustan los parámetros de configuración del servidor de la base de datos y se reduce la cantidad de índices
existentes en las tablas. Finalmente se obtiene una base de datos optimizada con sus tablas más críticas,
particionadas por grupos de selección, lo cual reduce considerablemente el tiempo de respuesta del servidor
propiciando que el usuario pueda acceder de forma más rápida a cualquier servicio que brinda el sistema
mejorando así el rendimiento del mismo.
Palabras Clave: base de datos, optimización, particionado.
ABSTRACT: The Hospital Information System (HIS Xavia) is responsible for the medical management of
hospitals and health centers, medical personnel have at its disposal a platform that allows the clinical and
administrative management. This system can handle large volumes of data that can be affected in its
performance, availability, and data management. In this research it is proposed to optimize the PostgresSQL
data base server of Xavia HIS system and perform partitioning of critical tables. In the first part of the paper the
authors perform an analysis of the techniques of partitioning possible to use, it is chose the horizontal
partitioning and illustrated by an example how are partitioned tables. Also is adjusted the configuration
parameters of data base server and is reduced the amount of existing indexes on tables. Finally, an optimized
database with partitioned tables by selection groups is obtained, which considerably reduces the response time
of the server causing that the user can access more quickly to any service provided by the system and improving
the performance.
KeyWords: database, optimization, partitioned.
1. INTRODUCCIÓN
El Sistema de Información Hospitalaria (Xavia HIS),
es una solución integral en un único producto para
“XI Congreso Internacional de Informática en Salud 2016”
Arrastia, Y.;Barrera, G.;Venero, R.| “OPTIMIZACIÓN
la gestión médica de hospitales y centros de salud.
La misma permite la recolección, almacenamiento,
procesamiento y comunicación de información
relacionada con la atención al paciente, así como
información administrativa del hospital.
Tiene como propósito, poner a disposición del
profesional médico una plataforma de herramientas
de gestión clínica y administrativa para dar
respuesta a sus necesidades reales. Sitúa al
paciente como referencia y centro del sistema
manejando su información de forma integrada y
única mediante una Historia Clínica Electrónica
para facilitar la realización del proceso de
diagnóstico, tratamiento y otros programas de
cuidados y seguimientos.
Xavia HIS comprende una estructura modular que
integra las funciones de las diferentes áreas dentro
de una institución hospitalaria así como la
convergencia de varias entidades de salud dentro
de un mismo sistema para el intercambio de
información sobre pacientes y servicios.
En sistemas de estas características, la gestión y
disponibilidad de los datos es de vital importancia
para el correcto funcionamiento e integración con
otros sistemas o módulos.
En la actualidad la gestión de reportes en las
diferentes áreas que abarca el sistema es un tema
crítico. La obtención de los reportes necesarios se
dificulta si presentan gran volumen de datos debido
a que el tiempo de respuesta es lento, evidenciando
problemas de configuración en el servidor de Base
de Datos (BD) lo que provoca problemas de
rendimiento y latencia en el servicio.
La gestión de pacientes, órdenes de análisis de
laboratorio, entre otros aspectos necesarios en una
institución hospitalaria presentan problemas debido
a la lentitud de respuesta por parte del servidor.
Esto se debe al exceso de información en tablas
únicas de la BD, que a su vez son tablas críticas
para la centralización e integración de los datos en
el sistema.
A nivel de BD la mala utilización y el exceso de
índices atenta contra el rendimiento alargando los
tiempos de respuesta en las transacciones
realizadas.
Atendiendo a la situación planteada con
anterioridad, el objetivo de la presente investigación
es mejorar el rendimiento del sistema Xavia HIS y
la disponibilidad de los datos mediante la
optimización del servidor de la base de datos
postgres SQL y el particionado de sus tablas
críticas.
2. MATERIALES Y MÉTODOS
2.1 Particionado de tablas
DE LA BASE DE DATOS DEL SISTEMA XAVIA HIS”
Las técnicas de particionado de una tabla, intentan
disminuir los accesos a disco, ordenando
físicamente los datos por un factor en común. El
particionado genera una pequeña sobrecarga de
procesamiento proporcional, en comparación con la
tabla sin esta técnica. Existen dos tipos de
particionados: el horizontal y el vertical. Ambos
tipos son distintos y se logran de diferentes formas,
el horizontal es por rango de datos atendiendo a un
campo que sea criterio de selección y el vertical
divide una tabla por columnas. [1]
2.2.1
Particionado Horizontal
En el particionado horizontal, el acceso a disco
disminuye si la consulta que se realiza, no busca en
todo el set de datos, sino que busca solamente
unos pocos elementos del conjunto de rangos por
selección. El particionado debe ser pensado de
acuerdo a las consultas que se van a realizar y
teniendo en cuenta cual es el criterio de selección
por el que se van a agrupar los datos. Este tipo de
particionado se manifiesta como herencia de
tablas[1].
2.2.2
Particionado Vertical
El particionado vertical busca disminuir los accesos
a disco a través de la selección de columnas.
Puede ser considerado desde el diseño (dos o más
tablas, unidas por una llave con cardinalidad 1:1).
Evidenciándose en el diseño de BD mediante la
normalización de las tablas. El modo de simular
esto es crear ambas tablas y una vista global de las
mismas, que incluyan todas las columnas. [1].
En la presente investigación se escoge como
técnica de particionado el horizontal, partiendo de
que la necesidad existente es la selección de datos
en grupos de más pequeños, teniendo como campo
de selección la fecha, campo presente en cada una
de las tablas críticas [1].
2.2 Plpsql
PL/pgSQL
(Procedural
Language/PostgreSQLStructuredQueryLanguage)
es un lenguaje imperativo soportado por el gestor
de base de datos PostgreSQL. Para poder utilizarlo
primero se debe instalar en la base de datos.
Permite ejecutar comandos SQL mediante un
lenguaje de sentencias imperativas y uso de
funciones. Con este lenguaje se pueden realizar
cálculos complejos y crear nuevos tipos de datos de
usuario.Dispone de estructuras de control
repetitivas y condicionales, además de la
posibilidad de creación de funciones que pueden
ser llamadas en sentencias SQL normales o
“XI Congreso Internacional de Informática en Salud”
Arrastia, Y.;Barrera, G.;Venero, R.| “OPTIMIZACIÓN
ejecutadas en eventos de tipo disparador (trigger).
[2]
DE LA BASE DE DATOS DEL SISTEMA XAVIA HIS”
PHPy muchos otros. [3] [4]
2.3 Postgresql 8.4
PostgreSQL es un Sistema de gestión de bases de
datos relacional orientado a objetos y libre,
publicado bajo la licencia PosgreSQL 1
Entre algunas de sus características se encuentra
que permite la alta concurrencia, mientras que un
proceso escribe en una tabla se puede
perfectamente acceder a la misma sin necesidad de
bloqueos. Además provee soporte para una amplia
variedad de tipos por ejemplo números de precisión
arbitraria, texto de tamaño ilimitado, figuras
geométricas, entre otros. Permite crear una amplia
funcionalidad a través de su sistema de activación
de disparadores (triggers).Garantiza la integridad
referencial y la herencia de tablas. Tiene múltiples
métodos de autentificación. Contiene funciones o
procedimientos almacenados en algunos lenguajes
de programación como PL/pgSQL, PL/Perl,
PL/Python. Soporta el almacenamiento de objetos
binarios grandes, por ejemplo gráficos, videos,
sonido. Cuenta con las APIs para programar en
C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC,
1PostgreSQL
Figura 1: Función de creación de particiones
Global Development Group
“XI Congreso Internacional de Informática en Salud”
Arrastia, Y.;Barrera, G.;Venero, R.| “OPTIMIZACIÓN
DE LA BASE DE DATOS DEL SISTEMA XAVIA HIS”
3. RESULTADOS Y DISCUSIONES
3.1 PARTICIONADO DE TABLA.
Atendiendo a la necesidad de mejorar el
rendimiento de la BD del Xavia HIS, se hace
necesario realizar el particionado de tablas, que por
el volumen de datos que tienen y su frecuencia de
uso en el sistema, se consideran críticas.
La solución que se desarrolla, comprende el
particionado de las tablas hc_local.persona,
hc_local.recipe y publico.solicitud_analisis_lab.
Para lograr el particionado de las tablas, se crean
funciones correspondientes a cada una de ellas,
encargadas de buscar y crear los intervalos de
años entre los cuales se van a distribuir los datos
existentes en dichas tablas. Con la ejecución de
estas funciones se logra crear de forma automática
la estructura final de la BD, así como los trigger y
funciones trigger correspondientes a cada una de
las tablas padres.
A continuación en la figura se muestra un
fragmento de código en lenguaje plpgsql de la
función encargada de hacer el particionado de la
tabla hc_local.persona. Se generan intervalos de 20
años a partir del primer año encontrado en la tabla
persona. Con estos rangos de selección se crea el
trigger y su función correspondiente en la tabla.
“XI Congreso Internacional de Informática en Salud”
Arrastia, Y.;Barrera, G.;Venero, R.| “OPTIMIZACIÓN
Ejecutando estas funciones en la BD, se generan
nuevas tablas, creándose un particionado
horizontal.
DE LA BASE DE DATOS DEL SISTEMA XAVIA HIS”
tabla hc_local.persona.
En la siguiente figura se muestra la estructura que
adquiere la BD después de particionada la tabla
persona. Es importante señalar que en el caso de
esta tabla específica, el criterio de selección de los
datos, es el campo fecha_nacimiento. Para lograr
un correcto funcionamiento, se decide agrupar las
personas en tablas, en un intervalo de 20 años.
Figura 3: Consulta realizada antes de optimizar el
servidor.
Figura 2: Ejemplo de particionado horizontal de tabla.
En la figura 4 se muestra de forma visual la
consulta realizada a la BD en la tabla
hc_local.persona.En la cual se evidencia que la
operación realizada es un escaneo secuencial
sobre todos sus datos.
En el caso de las otras tablas a particionar el
criterio de selección es el campo fecha y teniendo
en cuenta el volumen de datos generados por cada
paciente, se decidió que el rango de selección fuera
anual. De esta forma queda creada una tabla hija
por cada año, para el almacenamiento de los datos
en el año correspondiente.
3.2 Configuración del servidor PostgreSQL
Para utilizar el servidor de BD PostgreSQL, solo es
necesario su instalación, pero si se necesita
utilizarlo en sistemas que gestionen gran volumen
de datos es imprescindible hacer una configuración
personalizada para lograr un rendimiento óptimo.
En cualquier servidor, no solo en PostgreSQL, las
BD generan un considerable número de
transacciones y volumen de datos, el cual va
creciendo en el tiempo. Esto significa que una
configuración que funcione bien con ciertos valores,
puede que no funcione de forma óptima después de
un tiempo de uso determinado y se debe ajustar
nuevamente para que funcione óptimamente.
Debido a esto, es que se hace necesario realizar
ajustes en los parámetros de configuración para
lograr una optimización del servidor de BD.
El fichero principal de configuración de PostgreSQL
es el postgresql.conf, en el cual se encuentran los
parámetros que se ajustan para laoptimización de
acuerdo a los requerimientos e infraestructura de
despliegue.
Con la configuración inicial del servidor, las
consultas en la BD, devolvían los datos en un
tiempo prolongado. En la figura 3 se muestran los
resultados para la ejecución de una consulta a la
Figura 4: Visualización de operación realizada por el
servidor en consulta, antes de optimizar el servidor
3.2.1 Parámetros de configuración
Los parámetros de configuración de PostgreSQL se
configuran en el archivo postgresql.conf. Los
cambios para la mayoría de estas configuraciones
requieren reiniciar el clúster de BD de PostgreSQL.
[5] [6]
shared_buffers: este valor, de tipo entero, indica el
número de bloques de memoria o buffers de 8KB
(8192 bytes) que postgresql reservará como zona
de trabajo, en el momento del arranque para
procesar las consultas.El valor por defecto es
32MB, sin embargo, como esta es la memoria
utilizada para trabajo del servidor, el parámetro de
configuración se ajustó teniendo en cuenta la
disponibilidad de memoria, quedando asignado
“XI Congreso Internacional de Informática en Salud”
Arrastia, Y.;Barrera, G.;Venero, R.| “OPTIMIZACIÓN
2510 MB para la memoria de trabajo del servidor
PostgreSQL.
Se modificó la memoria compartida del sistema
operativo, que se encuentra en el fichero de
configuración /etc/sysctl.conf.
• SHMMAX: tamaño máximo de un segmento
de memoria compartida (bytes). Quedando
asignado el valor de 2147483648 bytes, 2
GB según la memoria del servidor.
•
SHMMIN: tamaño mínimo de un segmento
de memoria compartida (bytes). El valor
asignado es de 4096 bytes.
• SHMALL: cantidad máxima de memoria
compartida disponible (bytes): Se decidió
asignarle 262144 como valor atendiendo a
cantidad de memoria del servidor.
work_mem: parámetro usado en operaciones que
contengan ORDER BY, DISTINCT, JOINS,indica la
cantidad de memoria que puede utilizar
PostgreSQL antes de crear archivos temporales
para el procesamiento de los resultados
intermedios. Se decidió asignar 64 MB para la
ejecución de estas operaciones en el servidor de
BD.
effective_cache_size:es utilizado por el planeador
del motor de BD para optimizar la lectura de datos.
En un servidor dedicado se puede empezar con un
50% del total de la memoria. Atendiendo a la
disponibilidad de memoria del servidor, se decidió
asignarle el valor de 4730 MB.
geqo o GenericQueryOptimization: con este
parámetro se activa o desactiva el algoritmo que
utiliza PostgreSQL para optimizar las consultas al
sistema. El valor por defecto es activado (on), se
decidió dejar el valor establecido por defecto del
servidor en activado.
maintenance_work_mem: parámetro usado en
operaciones del tipo: VACUUM, ANALYZE,
CREATE INDEX, REINDEX, ALTER TABLE, entre
otras. Esta es la cantidad de memoria que utilizará
PostgreSQL para este tipo de tareas de
mantenimiento. Su valor dependerá mucho del
tamaño de las bases de datos aunque, se decidió
utilizar 350 MB en el ajuste de la configuración
atendiendo a la memoria dedicada en el servidor.
checkpoint_segments:este
parámetro
es
importante en BD con numerosas operaciones de
escritura (insert, update, delete). No obstante, un
aumento excesivo del mismo implica una
recuperación más lenta ante un fallo en cualquiera
de las transacciones, por esta razón, para sistemas
de escritura masiva, valores desde 32 (punto de
chequeo cada 512 MB) a 256 (cada 128 GB) son
los más populares. Se decidió asignar 64 MB.
random_page_cost: determina la forma en que el
planeador considera los accesos no secuenciales a
disco. Un valor bajo favorecerá el uso de índices;
DE LA BASE DE DATOS DEL SISTEMA XAVIA HIS”
un valor alto, las lecturas secuenciales. Se decide
asignarle 4.0 como valor de configuración.
cpu_operator_cost: este parámetro fija la
estimación del planificador del costo de procesar
cada operador o función ejecutada durante una
consulta. Se le asigna 0.5 como valor, que ofrece
un mejor plan para el sistema.
constraint_exclusion: permite al planeador
considerar las restricciones de chequeo en la tabla
al determinar el plan de ejecución, permite
optimizar las búsquedas en las tablas heredadas.
Se asigna el valor activado, para favorecer el
particionado de las tablas hc_local.persona,
hc_local.recipe y publico.solicitud_analisis_lab.
Después de la optimización del servidor de BD y el
particionado de las tablas críticas, se procede a la
ejecución de consultas con el objetivo de evaluar el
impacto en cuanto a los tiempos de ejecución de
las consultas y respuestas de la BD.
Figura 5: Consulta realizada después de optimizar el
servidor de BD y realizar el particionado
En la siguiente imagen se evidencia que el tiempo
de respuesta luego de optimizar el servidor y
realizar el particionado, en comparación con el
tiempo antes de realizarlo, disminuyó en 122 ms, lo
cual se considera adecuado para la respuesta del
servidor.
Figura 6: Visualización de operación realizada por el
servidor en consultas, después de optimizar el
servidor y realizar el particionado
“XI Congreso Internacional de Informática en Salud”
Arrastia, Y.;Barrera, G.;Venero, R.| “OPTIMIZACIÓN
Como se muestra en la imagen anterior, con el
particionado de tablas, se mejora el rendimiento del
sistema pues se logra reducir el tiempo de
ejecución debido a que la consulta solo se ejecuta
en un rango de datos y no en su totalidad.
Partiendo de las restricciones de chequeo que
existen para los rangos de datos, el sistema busca
directamente en la tabla que contiene los datos
requeridos. De igual forma se logra una reducción
de tiempo significativa en la demás tablas críticas
del sistema.
Además con el particionado de tablas se mejora la
gestión de la información pues cuando se realizan
transacciones como buscar, insertar y actualizar
datos se hace de manera más rápida ya que
aumenta la velocidad en tiempo de respuesta.
En fin la optimización del servidor de BD
postgresSQL junto al particionado de las tablas más
críticas, es una solución inmediata que resuelve los
problemas existentes en las instituciones médicas
que utilizan el Xavia HIS.
Por consiguiente el paciente podrá disfrutar de
todos los beneficiosque brinda el sistema, los
cuales se listan a continuación:

Dispone de un sistema que tiene como
centro de referencia al paciente, dando
respuesta a sus necesidades de salud
pública y de asistencia médica, facilitando
su acceso a los recursos de salud.

Atención al paciente como un cliente único
de la red de salud.

Existencia de un Expediente Clínico
Electrónico único por paciente, que puede
ser consultado desde cualquier institución
de salud autorizada.

Calidad en los informes médicos que se le
entregan a los pacientes.

Seguridad y confidencialidad
información de salud del paciente.
en
la

Calidad en la atención médica y
disminución de los tiempos de espera para
acceder a un servicio.
Para los profesionales de la salud, el correcto
funcionamiento del sistema también aporta grandes
beneficios, entre los cuales se encuentran:

Se pone a disposición del profesional
médico herramientas de gestión clínica
que dan respuesta a sus necesidades
reales.

Se dispone y accede a información
única e integrada del paciente para
DE LA BASE DE DATOS DEL SISTEMA XAVIA HIS”
facilitar los procesos de diagnóstico,
tratamiento y otros programas de
cuidados y seguimiento.

Se brindan herramientas que facilitan
acceder y compartir conocimiento
científico.

Permite la revisión de diagnóstico de
pacientes atendidos con anterioridad.

Control del suministro de medicamentos
a los pacientes y la generación
automática de la solicitud de los mismos
de acuerdo a las necesidades.
4. CONCLUSIONES
La velocidad en tiempos de respuesta en los
sistemas que manejan gran volumen de datos
es un elemento decisivo, es por ello que se
busca la rapidez en las transacciones que se
realicen. Estos sistemas necesitan estar lo más
óptimo posible para la correcta gestión y
disponibilidad de los datos y una de las formas
de lograrlo es precisamente optimizando el
servidor de la BD. Luego de analizar los
problemas existentes en el sistema Xavia HIS en
cuanto al rendimiento se llega a la conclusión de
que es necesario realizar una optimización del
servidor de la BD y a su vez realizar las
particiones correspondientes a las tablas más
críticas, utilizando la técnica de particionado
horizontal.
Para la optimización del servidor de la BD se
ajustaron los principales parámetros de
configuración, además se redujo la cantidad de
índices existentes en las tablas, eliminando
todos aquellos que son innecesarios para el
correcto funcionamiento del sistema. Una vez
realizada la optimización del servidor y el
particionado de las tablas se evidencian
beneficios muy favorables en cuanto al acceso
al sistema tanto para el paciente como para el
personal médico autorizado a la gestión de
datos. Con esto se logra reducir el tiempo de
espera del servidor lo que trae consigo que el
usuario pueda acceder a cualquier servicio del
sistema de forma más rápida, a su vez
haciéndose más atractivo y funcional para su
frecuente uso Además la obtención de reportes
y la gestión de información dígase buscar,
actualizar e insertar datos se realiza de forma
más ágil, haciendo más sencillo el proceso.
“XI Congreso Internacional de Informática en Salud”
Arrastia, Y.;Barrera, G.;Venero, R.| “OPTIMIZACIÓN
DE LA BASE DE DATOS DEL SISTEMA XAVIA HIS”
5. REFERENCIAS BIBLIOGRÁFICAS
1. postgres, comunidad de. 5.9. Partitioning.
[En
línea]
http://www.postgresql.org/docs/8.4/static/ddlpartitioning.html.
2. —. Chapter 40. PL/pgSQL - SQL Procedural
Language.
[En
línea]
http://www.postgresql.org/docs/current/static/plpgsql
.html.
3. —. E.23. Release 8.4. [En línea] 2009.
http://www.postgresql.org/docs/8.4/static/release-84.html.
4.
—.
[En
línea]
http://www.postgresql.org/about/featurematrix.
5. —. Chapter 17. Server Configuration. [En
línea]
http://www.postgresql.org/docs/8.4/interactive/config
-setting.html.
6. —. 18.4. Resource Consumption, Memory.
[En línea]
6. SÍNTESIS
CURRICULARES
DE
LOS
AUTORES
Yosvany Arrastia Machin, nacido el 20 de septiembre de 1986 en
Pinar del Río. Ingeniero en Ciencias Informáticas en la Universidad
de las Ciencias Informáticas, en julio del 2010, La Habana, Cuba.
En el periodo comprendido entre el 2010 y 2012 se destacó como
especialista de Inteligencia de Negocios en proyectos con Oficina
Nacional de Estadísticas e Información (ONEI) de Cuba. Además
como especialista de integración de datos, durante el proceso de
desarrollo del Sistema Informático para las Elecciones en Cuba y
participó en el proceso electoral como miembro del equipo de
gestión y análisis de la información. Entre 2013 y 2014, tuvo el rol
de especialista de Integración en PDVSA, Venezuela, en el
Sistema de Contratación y Administración de Contratos (SICAC).
En la actualidad se desempeña como especialista de base de datos
y consultor en el Centro de Tecnologías de Gestión de Datos
(DATEC) en la Universidad de las Ciencias Informáticas. Se
encuentra investigando sobre temas genéticos y enfermedades
genéticas, mediante la confección y análisis de árboles
genealógicos. Se encuentra desarrollando un sistema para la
representación gráfica de los árboles genealógicos y posterior
análisis de la información con R.
“XI Congreso Internacional de Informática en Salud”