Download Plantilla 2007

Consorcio SIU
Implementación de Tablespaces en Memoria (Sistemas
GNU/Linux - PostgreSQL).
Tablespaces en RAM (Linux)
mkdir /mnt/ram0
mount /dev/ram0 /mnt/ram0
Últimamente se manejó mucho el termino
mkdir /mnt/ram0/pgspace
de '''Bases de Datos en Memoria'''. Si bien
chown
postgres:postgres
existen versiones de Postgres que tienen esta /mnt/ram0/pgspace
forma de trabajo (FastDb es una de ellas),
puede resultar interesante ''jugar'' con un
Con esto anterior formateamos un espacio
pequeño servidor que tengamos para pruebas.
en RAM y lo montamos en un directorio de la
tabla de particiones. Cabe destacar que la
En este pequeño artículo mostraremos herramienta que utilizamos aca es para
como hacerlo de manera básica y práctica, junto formatear con el ext2. Podría, depende la
con algunos resultados. Cabe destacar que las situación, utilizar otra partición.
pruebas fueron realizadas sobre una maquina
virtual, por lo que pueden variar mucho en otros
Ahora nos queda por trabajar con la base
ambientes más dedicados.
de datos:
En general, este tipo de establecimientos
ubuntu=#
CREATE
TABLESPACE
(generalmente) se han dado en servidores ram_space LOCATION '/mnt/ram0/pgspace';
OLAP ya que requieren una buena capacidad
CREATE TABLESPACE
de procesamiento. Además, por lo general, son
ubuntu=# create table test_ram (i integer,
servidores separados del cluster de datos, por lo name text) tablespace ram_space;
que se los utiliza como servidores esclavos de
CREATE TABLE
una replicación y cuyos datos son sencillamente
ubuntu=# create temp table test_ram_temp
recuperables en caso de un abrupto apagado.
(i integer, name text) tablespace ram_space;
CREATE TABLE
Esta técnica permitiría de alguna manera,
ubuntu=# create temp table test_disk_temp
ocupar ese espacio con objetos como tablas (i integer, name text);
temporales, vistas materializadas, etc.
CREATE TABLE
ubuntu=# create table test_disk (i integer,
Primero, para facilitarnos las cosas, name text);
debemos enviar una parámetro al kernel, del
CREATE TABLE
tamaño de los discos en memoria. En este caso
los estamos estableciendo en 4 GB, pero
quizás, para hacer más ameno el manejo, nos
Hicimos un Tablespace en ese directorio y
gustaría armarlos de menos (2 o 1 GB):
luego creamos 2 tipos de tablas en 2
ubicaciones combinables: Temporales-Estándar
kernel
/vmlinuz-2.6.28-13-server y En Ram-En disco.
root=UUID=5ac65858-cdf5-4c26-8557220563f52901
ro
quiet
splash
ramdisk_size=4194304
Veamos los resultados parciales:
Si queremos esto permanente, podríamos
ubuntu=# explain analyze insert into
tocar el sysctl.conf:
test_ram
values
(generate_series(1,1000000),random()::text);
kernel.ramdisk_size=4194304
QUERY PLAN
--------------------------------------------------------Desde el shell, al inicio del sistema -----------------------------------operativo:
Result (cost=0.00..0.02 rows=1 width=0)
(actual time=0.019..9354.014 rows=1000000
mke2fs /dev/ram0
loops=1)
SIU
PÁGINA 1 DE 4
Consorcio SIU
Total runtime: 22836.532 ms
(2 rows)
Tabla temporal en disco: 13716.049
Puede resultar que en tu máquina, los
resultados sean distintos. En este caso lo hice
ubuntu=# explain analyze insert into con una máquina virtual (VBox) con un PGLive
test_ram_temp
values (Pgsql 8.3.5).
(generate_series(1,1000000),random()::text);
QUERY PLAN
---------------------------------------------------------Ideas
----------------------------------Result (cost=0.00..0.02 rows=1 width=0)
A prima facie, vemos que varia en el
(actual time=0.025..7507.349 rows=1000000 manejo de tipo de tabla (más allá de donde esté
loops=1)
alojada). Esto puede ser algo determinante a la
Total runtime: 12773.371 ms
hora de elegir.
(2 rows)
Quizás se puede combinar con una ''Vista
Materializada'' en memoria y de tipo temporal.
ubuntu=# explain analyze insert into
test_disk
values
Otra cosa a tener en cuenta es que
(generate_series(1,1000000),random()::text);
recuerden que cuando inicie el sistema
QUERY PLAN
operativo, borrará el contenido del tablespace,
---------------------------------------------------------- por lo que esta técnica solo serviría si usáramos
----------------------------------tablas ''temporales''.Inclusive si tuviésemos una
Result (cost=0.00..0.02 rows=1 width=0) actualización desde estas a las del disco, este
(actual time=0.025..7948.205 rows=1000000 sistema de trabajo es inconsistente, por lo que
loops=1)
siempre es conveniente grabar en disco y luego
Total runtime: 16902.042 ms
actualizar en memoria.
(2 rows)
Ideas 2
ubuntu=# explain analyze insert into
test_disk_temp
values
Pero, existe algo que proponen en
(generate_series(1,1000000),random()::text);
http://www.linux.com/feature/142658.
Y
es
QUERY PLAN
utilizar un SSD para almacenar los índices.
-------------------------------------------------------------------------------------------Esto es mucho más coherente y no es
Result (cost=0.00..0.02 rows=1 width=0) nada nuevo, ya que siempre se acostumbra a
(actual time=0.018..8135.287 rows=1000000 utilizar los medios más rápidos para almacenar
loops=1)
los índices. Además, en el caso de este artículo,
Total runtime: 13716.049 ms
si hay un corte abrupto del suministro o caída
(2 rows)
del servidor, lo único que deberíamos hacer es
reindizar.
Lo que hicimos fue, un insert con serie
sumado a la generación de un numero aleatorio
‘casteándolo’ a texto. En estas pequeñas
pruebas insertamos 1.000.000 de registros (lo
cual no es poco!).
Veamos el resumen:
Tabla estándar en ram: 22836.532
Tabla estándar en disco: 16902.042
En el caso del artículo referenciado, este
propone utilizar XFS para almacenar los
índices. En mi opinión se debería usar el
sistema de ficheros más liviano que nuestro
sistema operativo soporte, ya que buscamos
velocidad y no ''seguridad''.
Podemos crear índices en memoria (on en
un Pen o un SSD) así:
create index indice_ on tabla_ ( i )
tablespace ram_space;
Tabla temporal en ram: 12773.371
SIU
PÁGINA 2 DE 4
Consorcio SIU
Implementación de Tablespaces en Memoria (Sistemas
GNU/Linux - PostgreSQL).
Ideas 3
Otras de las ideas es, utilizar un Pen Drive
para almacenar la WAL. Esto se puede hacer
relativamente sencillo, creando un link simbólico
llamado pg_xlog que apunte al dispositivo en
cuestión (dentro del PGDATA encontraremos
este directorio). Copien el contenido del pg_xlog
original en el Pen Drive (o muevan), crean el link
y listo.
La idea es muy similar a los tablespaces en
memoria pero con la gran diferencia de que
hacerlo con la WAL es peligroso. Una
corrupción en la WAL podría generar varios
dolores de cabeza, por lo que una caída del
servidor nos dejaría sin WAL!! (a menos que
tengamos un backup sincronizado).
Para solventar la inestabilidad que puede
ocasionarse en un Pen Drive (ya sea porque
son más frágiles o por cualquier cosa que pueda
cooperar a perder la WAL), es sincronizar el
contenido del Pendrive en otro disco. De esa
manera el servidor Postgres escribirá sobre el
Pendrive pero el sistema operativo realizará un
Backup del contenido.
Para la WAL necesitamos como mínimo un
sistema de ficheros con log (ext3) por ejemplo.
Ideas 4
SIU
PÁGINA 3 DE 4