Comparación de búsquedas Full text search

El claro vencedor es Sphinx pero MyISAM es la solución más simple y unos resultados nada despreciables.

Discusión sobre InnoDB Flush - MySQL

El parámetro de configuración innodb_flush_method puede tomar los valores O_DSYNC y O_DIRECT.
Es importante tunear la BBDD, y uno de los parámetros clave es innodb_buffer_pool_size, el cual debe rondar entre el 50% y el 80% de la RAM del sistema.
Leí en un post sobre performance de MySQL que explicaba que en algunos casos, era conveniente evitar el doble cacheo (uno por parte de MySQL y otro por parte del S.O).
Para evitar el cacheo del S.O, se puede especificar el método de flush como O_DIRECT, el cual dice al Kernel que haga el DMA directamente evitando overhead de cacheo.
Pero leyendo un artículo del mismísimo Linus Torvalds, no se si es buena idea realizar éste tipo de tuning. Supongo que dependerá de cada caso. Aquí lo dejo.

A thread on the lkml began with a query about using O_DIRECT when opening a file. An early white paper written by Andrea Arcangeli [interview] to describe the O_DIRECT patch before it was merged into the 2.4 kernel explains, "with O_DIRECT the kernel will do DMA directly from/to the physical memory pointed [to] by the userspace buffer passed as [a] parameter to the read/write syscalls. So there will be no CPU and memory bandwidth spent in the copies between userspace memory and kernel cache, and there will be no CPU time spent in kernel in the management of the cache (like cache lookups, per-page locks etc..)." Linux creator Linus Torvalds was quick to reply that despite all the claims there is no good reason for mounting files with O_DIRECT, suggesting that interfaces like madvise() and posix_fadvise() should be used instead, "there really is no valid reason for EVER using O_DIRECT. You need a buffer whatever IO you do, and it might as well be the page cache. There are better ways to control the page cache than play games and think that a page cache isn't necessary."

Linus went on to explain, "the only reason O_DIRECT exists is because database people are too used to it, because other OS's haven't had enough taste to tell them to do it right, so they've historically hacked their OS to get out of the way. As a result, our madvise and/or posix_fadvise interfaces may not be all that strong, because people sadly don't use them that much. It's a sad example of a totally broken interface (O_DIRECT) resulting in better interfaces not getting used, and then not getting as much development effort put into them."

Preparando LAMP en Ubuntu

Apache
sudo apt-get install apache2
Configurar: /etc/apache2/
Root: /var/www/

PHP
sudo apt-get install php5 libapache2-mod-php5
sudo /etc/init.d/apache2 restart

MySQL
sudo apt-get install mysql-server
sudo apt-get install libapache2-mod-auth-mysql php5-mysql phpmyadmin
Configurar: /etc/mysql/

Restaurar contraseña de root en MySQL:
sudo /etc/init.d/mysql stop
sudo /usr/sbin/mysqld --skip-grant-tables --skip-networking &
mysql -u root
>SET PASSWORD FOR root@'localhost' = PASSWORD('password');
Y para restaurar un usuario con permisos de conexión remota podemos:
>UPDATE mysql.user SET Password=PASSWORD('newpwd') WHERE User='root';
Y posteriormente aplicar los privilegios y reiniciar MySQL
>FLUSH PRIVILEGES;
sudo /etc/init.d/mysql stop
sudo /etc/init.d/mysql start

PHP BUG: MySQL Query case sensitive?

Programando un portal web me he encontrado con un problema que me ha dado bastantes dolores de cabeza, ahora ya está solucionado pero no acabo de darle una explicación lógica... también es cierto que no he recopilado información suficiente ni me he dedicado muchas horas a investigar la razón...

La cosa es que en local con php5, mysql5 y apache 2.2 sobre windows xp un listado de registros de la BBDD cuya MySQL Query era algo así ("SELECT `campo` from TABLA WHERE...) me funcionaba perfectamente.
El bug ocurría al subir la web al servidor contratado que corre sobre Linux (podría ser el motivo pero ya vereis por que no acabo de tenerlo claro...) y php5 y mysql5 también. Dicha query no retornaba resultados para una tabla X, pero sin embargo si los retornaba bien con exáctamente la misma consulta pero cambiando la tabla por Y en otro script...

Es decir, que una cosa exacta funcionaba en local, y en remoto menos en un script que tenia unos 30 registros a mostrar.
Como se ha solucionado? He cambiado a minúsculas la Query.. "select `campo` from..."

Cual es la gracia? Pues que en los demás Script sigue estando en mayúsculas y funciona bien!!?!?!... No se, dolores de cabeza raros y sin sentido.
Si alguien sabe exactamente el motivo de ésto (sin especular, explicación comprobada y clara con documentación que lo avale) que me eche un cable..

Salu2

BenchMark - Gestión de coordenadas en MYSQL

Quería comprobar que sistema era mejor para almacenar registros en MySQL cuya clave principal fuera una coordenada en el plano (componentes X,Y).

El BenchMark comprueba la velocidad de búsqueda en dos modelos:

Modelo 1: Creamos una tabla con dos campos INT (X,Y) los dos Primary Key
CREATE TABLE coord (x int, y int, primary key (x,y));
Modelo 2: Creamos una tabla con un campo VARCHAR(21) primary key para un formato X:Y de 10 digitos por coordenada
CREATE TABLE coord2 (xy varchar(21) primary key);

Los tests realizados a continuación están ejecutados desde PHP en local mediante el script Benchmark.php
RESUMEN DE TESTS (Los tests completos y el codigo fuente de Benchmark.php estan a continuación del resumen)

TEST1: (modelo 1: 168% más eficiente)
Repeticiones: 10000
Registros: 18

TEST2: (modelo 1: 128% más eficiente)
Repeticiones: 20000
Registros: 22

TEST3: (modelo 1: 158% más eficiente)
Repeticiones: 30000
Registros: 22

TEST4: (modelo 1: 45% más eficiente)
Repeticiones: 1000
Registros: 1000

TEST5: (modelo 1: 27% más eficiente)
Repeticiones: 10000
Registros: 10000

TEST6: (modelo 1: 11% más eficiente)
Repeticiones: 10
Registros: 10000

TEST DE CARGA EXHAUSTIVA: (modelo 1: 32% más eficiente)
Repeticiones: 1000
Registros: 100000

CONCLUSIONES:
El modelo de dos campos de tipo ENTERO X,Y es más eficiente que el de texto en todas las situaciones probadas
Las situaciones más reales serían las del TEST 6 y 7 con mas numero de registros que de repeticiones de busqueda.
En ambas gana el modelo 1 y parece que las repeticiones dañan considerablemente al modelo 2
Es previsible una eficiencia similar a partir de un millon de registros de información con menos de 10 repeticiones