IBM compró Netezza: una taxonomía y algunos comentarios

El primero tiene que ver con coches. En el ascensor, en las conversaciones que oigo en el ascensor, que es donde pulso los intereses de mis cotidianos coadláteres, soy mudo testigo de multitud de conversaciones. Las más tratan de coches. Es increíble cómo la gente está al día de marcas, modelos, motores y potencias. Aunque luego les preguntas por lo de su oficio y te das cuenta de que, sorprendentemente, no saben por dónde les pega el aire. Así, nuestro teórico máximo sabedor sobre la base de datos con la que trabajamos ni siquiera estaba al corriente de que existía una cosa llamada Postgres. (Le tuve que deletrear el nombre, lo apuntó en un papel y me dijo que lo buscaría en internet; cualquier día le pregunto hasta dónde lo ha llevado su afán de saber).

Escuchándolos, cualquiera diría que no existe otro DBMS que Oracle.  Y Teradata, en nuestro peculiar contexto.

No me gustaría que los lectores de mi blog estuviesen tan intelectualmente desarmados como tanto consultor advenedizo y renuente y, para ello, les voy a regalar una mínima taxonomía de los DBMSs que abra su apetito, despierte su curiosidad y los anime a visitar la Wikipedia para consultar los detalles.

Del año 68 para acá impera —salvo un número sorprendentemente elevado de mentes retrógradas— el llamado modelo relacional. Los más de los DBMS modernos siguen tal esquema. Aunque existe un reciente interés por paradigmas noSQL, por no divagar, sobre ellos no añadiré cosa alguna más allá de unas frases copiadas de aquí:

Google, Facebook, Amazon, Digg and other vested web properties didn’t turn to classic enterprise technology (such as RDBMs) to address their non-classical challenges of availability and scalability. Instead, they turned towards the core of the problem, and invented novel theories, concepts and solutions to cope with their enormous growth and subsequent demand. These solutions are now becoming available in the software commons, such as column-oriented databases, messaging queues and highly scalable infrastructure management tools.

Por simplificar, los DBMS relacionales, se encuadran en cuatro grandes grupos:

  • Los tradicionales, con una arquitectura diseñada hace treinta años o más y que funcionan decentemente en contextos más o menos típicos (conjuntos de datos pequeños o medianos). Entre ellos se cuentan los más conocidos de los diletantes:
    • MySQL —y sus forks, como MariaDB— que es el motor de, entre otros, este blog.
    • SQL Server, para los amigos de los productos de Microsoft.
    • Oracle, que se administra tan fácilmente como se resuelve un sudoku ninja. Y que no es particularmente barato.
    • Postgres y sus derivados, como EnterpriseDB, que podrían sustituir a Oracle en el 95% de las instalaciones generando únicamente el 10% de los dolores de cabeza que produce este último. Y gratis, claro.
    • Otros como DB2 y similares, que tienen un tufillo a sobaco de dinosaurio que echa para atrás.
  • Los orientados a columnas. Porque todos los anteriores almacenan información en tablas y en dichas tablas, los contenidos de una fila se almacenan de modo contiguo. Los orientados a columnas guardan de manera contigua los contenidos de las columnas. Es prácticamente como si almacenasen cada columna en un fichero distinto. Esta orientación a columnas les permite beneficiarse de una serie importante de ventajas técnicas: pueden leer únicamente un porcentaje de los datos en cada consulta (las columnas involucradas) obviando el resto, pueden incorporar mecanismos de compresión más avanzados y simples, etc. He visto alguna que otra comparación entre DBMS de ambos paradigmas (almacenamiento por filas y por columnas) y los primeros suelen ser más rápidos en operaciones de carga masiva, mientras que los segundos son mucho más rápidos a la hora de resolver consultas.
  • Los DBMS MPP (massively parallel processing), aptos para instalaciones grandes. Entre ellos, se cuentan:
    • Teradata, que me hace sentir como todo un máster del universo cuando completa en dos minutos consultas que en otras instalaciones llevarían una tarde (o se caerían); o cuando ejecuta en unas horas 300.000 consultas que le lanzo —programáticamente, claro está— cuando me aburro y quiero jugar al gato y al ratón con los administradores.
    • Netezza, similar pero, aparentemente, más barata y recientemente adquirida por IBM.
  • Finalmente, MPP y orientada a columnas, como Vertica, el DBMS emergente del que nunca han oído hablar nuestros carlossainz de ascensor.

En este contexto se explica bien el interés que puede tener IBM en adquirir Netezza. No es, como se lee en otros sitios, que IBM haya de alguna manera traicionado a sus antiguos clientes de DB2 o que haya particular riesgo de que le haga dormir el sueño de los justos. Es, más bien, que hay tantos DBMS como problemas de negocio y que IBM quiere un trozo del pastel que ahora tan rica (en varias acepciones) y monopolísticamente está disfrutando Teradata en este país nuestro en el que reina, más que Juan Carlos I, además de una irritante pereza intelectual, una enervante inapetencia por lo nuevo.

6 comentarios sobre “IBM compró Netezza: una taxonomía y algunos comentarios

  1. Carlos 11 octubre, 2010 7:00

    ‘En otros sitios’ lo que se dice es que si -como viene diciendo IBM durante años- DB2 funciona tan bien en entornos DataWarehouse ¿por qué la compra de Netezza? (A otro nivel, lo mismo podría decirse de MicroSoft con DATAllegro)

    Durante muchos años hemos visto como compañías grandes compran compañías más pequeñas para, tras incorporar de una u otra forma funcionalidades de las que la empresa grande carecía, dejarlas morir lentamente.

    ¿Alguien se acuerda de Foxpro, cuyo motor -o gran parte de él – se incorporó a Access? ¿RDB, que fue absorbida por Oracle -y su tecnología de bitmap indexes-? Por no hablar de Scopus, Siebel, JD Edwards, Peoplesoft…

    La lista sería interminable.

    Saludos.

    Carlos.

  2. esmm 11 octubre, 2010 7:50

    «¿Column oriented massively parallel processing?!!! Mira dejate de inventos que a mi con el excel/word/access me ha funcionado siempre el departamento» – Comentario extraido al azar de una muestra de respuestas con las que se encuentra un consultor en la negociacion para la implantación de alguna tecnologia «nueva».

  3. datanalytics 11 octubre, 2010 15:57

    @esmm
    Hasta que quieras almacenar y procesar cotizaciones de empresas en tiempo real. O posiciones y velocidades de GPS’s de vehículos circulando por París. O los tickets de compra de Tesco. O las operaciones de las tarjetas de crédito de Bancomer. O registrar las entradas y salidas de mercancías por las aduanas españolas. O el censo de la República Popular China. O…

  4. rvaquerizo 11 octubre, 2010 20:42

    Comparar Postgres con Oracle es como comparar a Pepín Blanco con Obama, siendo Obama Oracle. Los dos hacen lo mismo (nada) y uno es más barato que otro. Pero en el fondo sabes que uno no es infinitamente mejor al otro.

  5. datanalytics 11 octubre, 2010 22:30

    @rvaquerizo
    Una comparación más afortunada, tal vez, sería la que compararía Audi con Renault.

Los comentarios están desabilitados.