Algo de bases de datos en Linux...

[Rodrigo Fuentealba]

El 31/07/07, Germán Poó Caamaño <gpoo en ubiobio.cl> escribió:
> On Tue, 2007-07-31 at 15:35 -0400, Juan Martínez wrote:
> > Alvaro Herrera escribió:
> > [...]
> > > En estos casos, en MySQL se
> > > sugiere usar modelos menos normalizados (lo vi en algun manual), o
> > > extraer datos en dos pasadas y luego hacer un pseudo-join en el codigo
> > > de la aplicacion.  Quizas por esto uno pueda decir que es "menos
> > > relacional", porque te obliga a que uses modelos menos limpios.
> >
> > Exacto, o quizas casi nada relacional..
>
> Hay ocasiones, que por rendimiento se deben relajar las restricciones
> de integridad, relajar la normalización del modelo, no usar
> transacciones y todo lo que nos enseñaron que hacían los
> chicos buenos, obedientes y ordenados.

Sí, hablamos de relajar las restricciones de integridad, pero aún así
la integridad se mantiene a través de una gran aplicación (o se piensa
en diseñar la aplicación de tal manera que no requiera integridad), y
cuando hay aplicaciones pequeñas, difícilmente hay problemas. Por lo
demás, a simple vista pienso que ninguno de estos modelos es difícil
de mantener a nivel de aplicación  (al menos en el caso de Wikipedia,
con 3000 consultas por segundo), teniendo a lo sumo unas 40 tablas. Si
pensamos en aplicaciones distribuidas como las de Arauco, por ejemplo,
es con mucho mayor la cantidad de tablas (muchas de ellas son
paramétricas) y menor la cantidad concreta de datos; todavía es
posible usar índices sobre ciertos datos.

Como yo lo veo: la mejor manera de optimizar los datos cuando llegan a
una cierta cantidad de registros en una tabla son los índices. Por
ejemplo, sabemos que constantemente estamos yendo a la tabla usuario
para obtener el nombre de usuario y la contraseña del mismo.
Inclusive, podemos generar índices más específicos. Sin embargo, esos
índices también deben evaluarse al momento de efectuar una consulta.
Cuando ya la aplicación no se puede optimizar por esta vía, ni por
bueno que sea el gestor de bases de datos relacional...

> Digamos cuando hay miles de
> millones de tuplas involucradas y con acceso concurrentes.

De Wikipedia por ejemplo, hay un manejador de caché de los resultados.
Los datos se guardan, revisan, parsean, comprimen y se cachean, para
ser enviados como un vil archivo de datos (cuesta menos en términos
atómicos el hacer un fopen($archivo, "r") que un mysql_connect(), si
me permiten expresarme en pseudo-PHP).

> Joe Gregorio indica que allí las bases de datos relacionales pueden
> quedar chicas.
>

De hecho, quedan chicas.

> http://bitworking.org/news/158/ETech-07-Summary-Part-2-MegaData
>
> Allí se indica una referencia a como lo hacen en eBay:
> http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
> en donde la base de datos solo es un repositorio. El resto de la
> lógica se maneja arriba (Oracle de por medio).
>
> Interesante, aunque parezca básico, los problemas de utilizar
> 'autoincrement' y como se iba de guata MySQL en del.icio.us
> (por cierto, harto feo el sitio ese :-).

Hay quienes usaban OID's como campos identificadores únicos;
oid-as-key users should burn in hell.

> http://joshua.schachter.org/2007/01/autoincrement.html
>
> Aunque lo más entretenido se encuentra en:
> http://www.guardian.co.uk/g2/story/0,,1824525,00.html
> (citado en el sitio de Joshua Schachter) sobre la debilidad de
> exponer números en serie.
>
> Aunque como no estamos hablando de sitios como eBay o de sucesos
> como iLike (que pasó a crecer a una tasa de 300.000 usuarios/día),
> probablemente todo esto es pura ficción y la discusión sobre quien
> tiene la última palabra debiera seguir.
>

No, no es ficción; es otro punto de vista que hay que conocer.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas - Consultor UNIX - Database Administrator