BeOSmAn's Blooog

Qué desilusión. Mira que PosgreSQL había dado buenos resultados, muy buenos resultados, cuando nos íbamos de los tres millones de registros con relaciones y todo. Mantenía su integridad referencial, las inserciones y actualizaciones iban extremádamente rápido… vamos, profesional.

Pero, y realmente lo siento, no es aceptable que para hacer una consulta del número de filas de una tabla (un select count(*) from tabla;) se eternize. Vamos, en cuatro millones de registros tarda 1,5 segundos (en un Pentium D de doble núcleo a 2,8 GHz con 2 GB de RAM, que tampoco es mala máquina para hacer pruebas).

Incluso he leído por ahí que en una máquina con 8 procesadores y 16 GB de RAM tardaba 70 segundos en hacer un count en unos 64 millones de registros.

Y eso, dicen, es por la implementación del MVCC que tiene que recorrer la tabla entera cada vez que quiere contar las filas.

He encontrado una solución que da un valor aproximado de las filas en un tiempo aceptable (vamos, en menos de 1 segundo):

select reltuples from pg_class
join pg_namespace on (pg_class.relnamespace = pg_namespace.oid)
where nspname = ‘<espacio de nombres>‘
and relname = ‘<nombre de la tabla>‘;

El problema de esta solución es que da un valor aproximado y para que lo de exacto, cada vez que se hace un insert o un update hay que hacer un vacuum. Y tampoco es aceptable.

Y otra solución, como no, si lo que sobran son soluciones que nosotros podamos hacer, es añadir un trigger en inserción y borrado que actualice otra tabla con el conteo de filas. Pero esto es una chapuza. Hay que cambiar el motor de persistencia de tu framework para que use esas tablas en lugar del típico select count(*) ....

La cuestión es que, quizás, los de PostgreSQL deberían buscar una solución para resolver este problema. Quizás al estilo de MySQL (que guarda el número de registros de cada tabla) o quizás reimplementando el MVCC.

El caso es que ¿sigo con PostgreSQL o me vuelvo a MySQL? PosgreSQL 8 es muy buena, pero ¿estará MySQL 6 a la altura o será mejor? Las espectativas de la segunda prometen… habrá que esperar un poco.

Una pequeña configuración de MySQL, que hice hace tiempo ya, pero que no quiero que se me olvide para futuros sistemas.

Si estamos usando InnoDB, el motor de bases de datos de MySQL con el que tenemos integridad referencia y demás cosas interesantes, los datos se guardan en un sólo archivo generalmente llamado ibdata1 (en el directorio de datos de MySQL). Luego están las definiciones de las tablas y los índices en otro archivos, pero los datos principales están en este.

Lógicamente, esto puede crecer de forma descontrolada, bien sea porque metemos muchos datos, o bien porque queremos saber si nuestro Pentium II a 350 MHz puede con 50 millones de registros.

El caso es que cuando nos demos cuenta de que nuestra máquina va sobrada con tanto registro y borramos la base de datos, el espacio ocupado por estos datos no se libera. ibdata1 sigue ahí, grande y gordo, aunque casi vacío.

Pero esto tiene solución. En el archivo de configuración de MySQL, generalmente en /etc/mysql/my.cnf en Linux (en Windows no me acuerdo) hay que poner la siguiente línea de configuración:

innodb_file_per_table = 1

Con esto indicamos a MySQL que las tablas de InnoDB deben ir cada una en un archivo. Así, si las borramos, se borrará también el archivo con lo que liberaremos el espacio ocupado por los 50 millones de registros.

Eso sí, esto lo debemos hacer recién instalada la base de datos ya que si lo hacemos cuando ya tenemos bases de datos creadas, hasta que no se borren y se vuelvan a crear no usarán un archivo distinto (y el ibdata1 seguirá ocupando espacio).

Y, ya de paso, si tienes una máquina con 4 o más GB de memoria RAM, es interesante poner las propiedades key_buffer = 512M, query_cache_size = 512M, join_buffer_size = 16M, sort_buffer_buffer = 32M e innodb_buffer_pool_size = 512M para tener la máxima memoria posible para las queries, índices, ordenación y datos.

Ale, a partir de ahora, a probar qué tal van nuestras máquinas con MySQL aunque ahora yo voy a probar PostgreSQL que, digamos, es más serio que MySQL (al menos que las versiones de MySQL anteriores a la 5). Y promete que soporta muchos más registros que MySQL manteniendo los tiempos de acceso e inserción. A ver si es verdad.

Pues sí, otra vez me ha tocado instalar el Eclipse con el PDT en el ordenador de un compañero de trabajo. Pero al contrario que la vez anterior, ésta ha ido mucho mejor .

La vez anterior, para hacer el pequeño manual, lo instalé en una máquina virtual con Ubuntu 8.10 que tenía para hacer pruebas. Y quedó bien. De hecho ahora lo uso de vez cuando.

Por eso cuando tocó instalar de nuevo, se me ocurrió copiar directamente mediante scp todo el directorio de Eclipse con sus plugins (yo lo instalé en /opt/eclipse/) al mismo directorio del nuevo equipo y también el directorio .metadata del directorio de proyectos del Eclipse (el directorio .metadata del workspace).

Y ¡funcionó! Además a la primera. Lo único que pidió fue un nuevo directorio de workspace (entre los equipos no era el mismo usuario). Con su plugin de PDT, de Subversion y toda la movida de la instalación anterior.

Ya sabéis, en Eclipse (y creo que en pocos más) copiar los binarios de la instalación de un ordenador a otro funciona. Qué majos…