HP ORACLE DATABASE MACHINE: tras las huellas de Teradata.

Oracle ha anunciado su “HP Oracle Database Machine“. Se trata de una solución “hardware/software” para ofrecer un alto rendimiento en sistemas de “Data Warehousing” (“I/O-intensive“) con grandes volúmenes de datos.

Oracle afirma que el sistema “is a complete, optimized and preconfigured package of software, servers, and storage” (completo, optimizado y preconfigurado paquete de software, servidores y almacenamiento). Está basado en lo que llaman “Exadata Storage Servers” que son sistemas de almacenamiento ‘inteligentes’ que efectúan algunas labores de preproceso de las búsquedas (SELECTs…) antes de enviárselos al motor de Base de Datos en sí (Oracle RAC). Con esto se consigue mejorar el rendimiento y ,sobre todo, los I/O bottlenecks.

La solución auna hardware de HP y Software Oracle.

Pues bien, este sistema es básicamente igual en arquitectura a los servidores Teradata: Teradata, aunque es conocido como un sistema de bases de datos para “Data Warehousing”, es mucho más: la solución Teradata engloba software y hardware. Teradata corre básicamente en servidores Teradata específicamente diseñados para ejecutar el software Teradata de la manera más eficiente y con máximo rendimiento. El diseño “hardware” del almacenamiento, comunicaciones, memoria, procesadores… está pensado por y para conseguir máximo rendimiento con este software específico.

Así pues: Oracle está siguiendo un camino que Teradata empezó hace muchos años…

Saludos.

Carlos.

16 respuestas a HP ORACLE DATABASE MACHINE: tras las huellas de Teradata.

  1. […] Data Warehouse Appliance. Sun ha sacado su contraparte a la HP Oracle Database Machine: Sun Data Warehouse Appliance, se trata de un “join venture” con Greenplum, un (no […]

  2. membider dice:

    “… este sistema es basicamente igual en arquitectura a los servidores Teradata”.

    Ummmm no puedo estar de acuerdo. Share nothing share every thing.

    El modo de resolver es radicalmente distinto.

    Yo diría Teradata MPP puro
    Oracle mezcla SMP por arriba MPP para I/O.

    En mi opinión ni de lejos es lo mismo.

    Saludos

  3. carlosal dice:

    Por supuesto que la gran diferencia (y ventaja en entornos DW) entre Teradata y Oracle es que Teradata es ‘share nothing’ y Oracle no lo es (lo he dicho más de una vez en este ‘blog’).

    A lo que me refería es que el conjunto ‘complete, optimized and preconfigured package of software, servers, and storage’ y el incluir una capa de ‘inteligencia’ en el sistema de almacenamiento es algo que Teradata viene haciendo desde el principio.

    Siento si me he explicado mal…

    Saludos.

    Carlos.

  4. membider dice:

    ¿Es ventajoso un share nothing?. Particionando por hashing como hace Teradata. ¿Como resuelves un count distinct por una clave no hashing?. ¿Quien resuelve mejor estas consultas un share nothing o un SMP sobre un MPP.

    Yo no tengo claro que un puro MPP como Teradata sea mejor. Y sí tengo claro que el gran problema de Oracle era el I/O.

    ¿Como se resuelven mejor las consultas analíticas con un MPP o SMP con IO MPP?.

    Saludos. Siento discrepar.

    • carlosal dice:

      Por supuesto que es ventajoso un ‘share nothing’ en entornos DW. Mira si no los problemas que tuvo oracle cuando lanzó RAC con los bloqueos y actualizaciones entre instancias. Tuvo que sacar el ‘Cache Fusion’ y al principio lo hacía a base de IO en disco…

      ‘Share nothing’ es ‘parallel’ de forma natural. Si has trabajado con Oracle sabrás que para conseguir que el paralelismo funcione no basta con el ‘hint’ PARALLEL. Además la famosa ‘escalabilidad horizontal’ que preconizaba Oracle con su RAC en Teradata es también algo natural: más AMP’s significa más nivel de paralelismo y rendimiento general (normalmente esto es lineal). En Oracle esto no es así: añadir más nodos a RAC no consigue un aumento de rendimiento lineal.

      >>”¿Como resuelves un count distinct por una clave no hashing?”
      No importa si el ‘count distinct’ es por lo que tu llamas ‘clave hashing’ (en Teradata se llama ‘primary index’) o no (o al menos no demasiado). El ‘distinct’ se ejecuta en paralelo y sólo al final hay un algoritmo ‘sort merge’ optimizado sin redistribución a una ‘sort area’.

      >>”¿Como se resuelven mejor las consultas analíticas con un MPP o SMP con IO MPP?”

      Las consultas ‘analíticas’ y agregaciones en general también se realizan en paralelo, con lo que creo que está claro cómo se resuelven mejor.

      El gran ‘pro’ de Teradata es su concepción ‘en paralelo’, aunque esta puede ser su gran ‘contra’ en ocasiones, pero en general en entornos DW con tablas muy grandes es una ventaja.

      Saludos.

      Carlos.

      • membider dice:

        Buenas:

        En el tema del cache fusion tienes toda la razón, pero Oracle pasito a pasito van mejorando y en la 11 ha cambiado bastante.

        También tienes razón que la linealidad famosa sólo se consigue en MPP, pero ojo, la linealidad sólo es cierto cuando las consultas entran por la primary index como tu dices.
        Sino, la teoría dice que la velocidad de un MPP es la velocidad del nodo más lento. Es decir si hago una consulta que al final la resuelve un nodo, e incremento los datos no hay linealidad.

        El count distinct que te comento no es ninguna tonteria.

        Tenemos una tabla de 100 millones de filas, lo cual para un DW no es raro. Sobre esta tabla le tienes hecho un hashing en Teradata sobre el campo C.
        Haces un cálculo de select D, count(distinct F) sobre este conjunto.

        En Teradata cada nodo no puede hacer una agregación sobre D y calcular un count distinct. Tienes que obtener todos los valores de D, con todos los posibles valores de F
        y a través de su famosa bynet pasarse todos los datos unos a otros para realizar el cálculo. Porque la única manera de hacer esto es hacer una clave hashing ficticia.

        Te puedo decir, que en una demo que me hicieron, cometieron el error de darme a elegir la consulta, me fuí de la demo sin que una consulta de esta se hubiera resuelto.

        Ojo que para mí Teradata es una pasada, máxime en las épocas en que surgió. Pero valorando la arquitectura hoy en día, yo creo que se podía estudiar una mejora en ese aspecto.
        Oracle está haciendo el camino al revés, y hace 2 años Teradata era el líder indiscutible, hoy en día puede seguir siéndolo, y pensando en las posibilidades de futuro no lo tengo claro. Si a esto sumas precio (y otras funcionalidades) se me incrementan las dudas.

        A disfrutar.

        • carlosal dice:

          >>”También tienes razón que la linealidad famosa sólo se consigue en MPP, pero ojo, la linealidad sólo es cierto cuando las consultas entran por la primary index como tu dices.
          Sino, la teoría dice que la velocidad de un MPP es la velocidad del nodo más lento. Es decir si hago una consulta que al final la resuelve un nodo, e incremento los datos no hay linealidad.”

          No. En absoluto. El paralelismo (y la linealidad en el rendimiento) no depende de que las consultas sean por ‘primary index’ o no. Paralelismo es paralelismo es paralelismo.
          Ni siquiera es cierto de que se consiga con MPP. Si a un NODO SIMPLE Teradata le agregas AMP’s (con sus recursos correspondientes) también mejoras el rendimiento de forma lineal. El paralelismo no funciona a nivel de ‘nodo’, sino a nivel de AMP (aunque, claro, si añades nodos estás añadiendo AMP’s).

          En cuanto a la SELECT DISTINCT que dices, sólo decirte que seguramente el que hizo la prueba debería haber utilizado GROUP BY en su lugar, ya que (como en Oracle con el IN y el EXISTS) para unos casos es mejor uno que el otro y viceversa. Tampoco conozco la confihguración de la máquina en la que corría.

          >>”Tenemos una tabla de 100 millones de filas, lo cual para un DW no es raro. Sobre esta tabla le tienes hecho un hashing en Teradata sobre el campo C.
          Haces un cálculo de select D, count(distinct F) sobre este conjunto.”

          Supongo que te refieres a un HASH INDEX, pero no termino de ver el ejemplo.

          El número de filas, aun siendo importante, no es lo único importante. La ‘profundidad’ de las filas, la distribución y demografía de los datos, la estructura interna, índices secundarios, ‘join indexes’, etc, etc… son factores a tener muy en cuenta.

          Saludos.

          Carlos.

  5. carlosal dice:

    ‘membinder’:

    >>”Es que un AMP es un nodo MPP.”

    Otra vez no. Parece que en Teradata has oído campanas, pero no sabes muy bien de dónde.

    SMP=Symmetric Multi-Processing. Se refieren a sistemas con un solo nodo Teradata.

    MPP=Massively Parallel Processing systems. Son sistemas multinodos Teradata comunicados por BYNET física.

    AMP=Access Module Processor. Es el ‘alma’ de Teradata. Los AMP’s existen tanto en sistemas de un solo nodo (SMP) como en sistemas de varios nodos (MPP). Corren bajo Parallel Database Extensions (PDE). De ahí que el paralelismo no sea a nivel de nodo, sino de AMP.

    Saludos.

    Carlos.

    • membider dice:

      Vamos a dejar el tema. Pero perdona, una cosa es teoría de arquitectura de sistemas y otra cosa es cómo Teradata implementa esa arquitectura. A mí me da la sensación que tú te quedas en el último punto.

      Saludos

      • carlosal dice:

        Vale.

        Si quieres, lo dejamos.

        Pero los AMP’s no pueden ser nunca ‘nodos MMP’ ya que comparten memoria y procesador entre sí (en un nodo = SMP). Los sistemas MMP deben ser independientes en cuanto a memoria y procesador. Y esto no es la ‘implementación Teradata’, es la definición de SMP y MMP.

        Decir que un AMP es un nodo MMP es no saber qué es ninguna de las dos cosas.

        Yo sólo estaba intentando sacarte de la confusión en la que parecías estar. Ahora veo que tú sólo estabas intentando demostrar cuánto sabes. Y lo has hecho sin ningún lugar a dudas.

        Saludos.

        Carlos.

  6. […] Respecto a esto, hay muchas ideas preconcebidas y bastante desconocimiento de como Teradata implementa el paralelismo, como por ejemplo, aquí. […]

  7. […] ha reconstruído su HP ORACLE DATABASE MACHINE con tecnología (léase servidores) Sun: pasa de los servidores Exadata (con los HP Proliant) a los […]

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: