Base de datos MySQL... u otra?

[Rodrigo Fuentealba]

El 16/02/08, Aldrin Martoq <amartoq en dcc.uchile.cl> escribió:
> On Feb 14, 2008 10:52 AM, Nelson <nelson.urbani en gmail.com> wrote:
> > Hola, necesito migrar una base SQL SERVER a otro motor (necesidades de
> > Performance)
>
> He visto bases de datos MSQL volar consumiendo muchos registros (no se
> cuantos, digamos el año completo de datos desde SAP de un tema
> específico de una empresa _grande_) en tan solo segundos. SQL Server
> no es para nada una mala base de datos.

Por otro lado (y me lo recordaste cuando mencionaste a SAP), MySQL con
todos los registros de un mes de SAP se cayó varias veces en distintos
sistemas operativos cuando estuve haciendo algunas asesorias en una
forestal, y PostgreSQL tomó poquísimos segundos en resolver las mismas
consultas. (Ya he comentado esto anteriormente en la lista).

[...]

> > El sistema en si sería de solo consulta, pero tengo que importar 10 años de
> > antiguedad, mas los mensuales.... La pregunta es: será que se bancará
> > "manejar" tanto volumen de datos MySQL o no?
>
> De las respuestas que hemos recibidos, todos cuentan maravillas de uso
> en: google, facebook, y otras empresas grandes; pero por lo visto
> nadie a trabajado con tantos Gigas por acá y por lo tanto nadie te
> puede contar la parte negra del asunto.

No con MySQL. Pero de lo que he visto sobre cómo se usa MySQL en
Wikipedia (vi el modelo y lo analicé varias veces); es un modelo en el
que las relaciones se implementan a nivel de software, no a nivel de
bases de datos (vuelta a lo que decía siempre: MySQL /no/ es un
RDBMS); realmente no se hacen tantas consultas a la base de datos
(comparadas con el número de visitas), solamente inserciones,
comparaciones y luego regeneración de la página que está en caché. Y
por lo tanto, MySQL se preocupa de crecer, crecer, crecer y mantener
un índice de texto; nada difícil de implementar en COBOL (que sería
mucho más rápido, además).

Apoyando esto, en varias implementaciones de sistemas de control de
documentos gigantescas en que se usa MySQL para llevar un índice del
estado (una empresa de ingeniería en que hay 24 Terabytes de
documentos entre Word, Excel, AutoCAD y otros), la tabla de revisiones
no alcanza realmente a los 200 Mb, es decir, algo despreciable. Pero
la propaganda fue "this software has MySQL: the most popular database
engine.". Sí, Hasefroch también es popular, ¿y qué?.

Y en general, mi experiencia con MySQL es que para muchas consultas a
una sola tabla es muy rápido, pero su nivel de inconsistencias me hace
pensar en que: "MySQL es un software que te da respuestas erróneas,
pero en el mínimo de tiempo posible".

Ahora, la cosa cambia con PostgreSQL: yo a lo sumo he manejado bases
de datos de texto que tienen de 100 a 120 Gb en esta base de datos
(nada parecido a los 250 Gb que mencionabas). Tuve una muy buena
experiencia con lo que hizo TSearch2 en esa oportunidad.

Los pocos problemas de lentitud que tuve se solucionaron haciendo
buenos índices de acuerdo a las consultas que hacía (una planificación
muy a conciencia, me tomó una semana y media) y no a "las tincadas de
que por este dato se indexa mejor" como suele hacerse. También tuve
algunos problemas con el respaldo (tamaña base de datos es difícil de
respaldar), y en general ninguna consulta se demoraba más allá de 3
minutos.

Eso sí, y antes de recomendarte algo: SQL Server no es para nada de
malo (sobretodo MSSQL2005, que yo personalmente lo prefiero a MySQL).
Todo depende de las consultas y realmente de lo que quieras obtener de
la base de datos; es posible que haya una falta de configuración nada
más, y eso no te lo podrían responder por acá pues sería OT.

> tan solo algunas consultas que has preparado para contestar
> ciertas preguntas.

Eso es, en base, OLAP.

> De ser así, a vuelo de pájaro se me ocurre que si
> generas mas tablas con datos "premasticados" (posiblemente durante la
> carga con un "DTS") y con los índices correctos sería la solución a tu
> problema, independiente de la base de datos.

Interesante sería saber qué versión de SQL Server estás usando también.

-- 
Rodrigo Fuentealba