julio 20, 2012

SAP HANA vs. Oracle Ex-box: Parte 1

By Sapdba's blog - David Hull

Ésta es la primera de una serie de entradas que van a comparar SAP HANA y lo que llamaré la solución Ex-box de Oracle, que es una combinación de Exalytics y Exadata. Elijo este nombre así (un poco en broma, seguro), pero mi intención es presentar una evaluación técnica basada en hechos para medir estas plataformas competidoras. Agradeceré profundamente que me hagan llegar sus opiniones a favor o en contra a través de los comentarios. Puedo asegurarles esto: lo que más me gusta es una verdadera discusión fáctica sobre estas tecnologías.
Empecemos por la arquitectura de datos. Oracle afirma que puede ofrecer análisis "a la velocidad del pensamiento"; es decir, puede responder sus preguntas antes de que las hagan. ¿Es realmente así?
En caso de que sean de esas personas que prefieren el resumen al principio, he aquí un resumen de mi posición acerca de la comparación entre estas dos soluciones con respecto a la arquitectura de datos. Más abajo voy a entrar en detalles sobre cada uno de los puntos.
  
Atributo
Solución SAP
Solución Oracle
Latencia de datos


Mantenimiento


Rendimiento en estructuras cacheadas


Rendimiento en estructuras no cacheadas





Una de las diferencias más importantes entre estas dos soluciones es que HANA, como base de datos totalmente en memoria (in-memory), permite obtener rápidamente resultados sobre datos transaccionales detallados, sin necesidad de recurrir a engorrosas y lentas operaciones de 'tuneado', tales como armar tablas agregadas y cargar motores de caching, lo cual sigue estando en el núcleo de la solución de Oracle. Esto está confirmado no solo por testimonios de clientes, sino también por muchas pruebas publicadas, incluido el HANA Scalability Testing, así como los resultados del SAP NetWeaver BW EML Benchmark. Ambos tests alcanzaron un rendimiento formidable sin necesidad de índices secundarios, vistas materializadas, tablas agregadas, resultados pre-calculados o caching de ningún tipo.
La solución óptima de SAP para análisis, que hoy se está usando en ambientes de producción de clientes, incluye la réplica de datos transaccionales 'crudos' directamente desde SAP ERP u otros sistemas transaccionales hacia HANA, a través del Landscape Transformation Software de SAP, o bien a través de su BusinessObjects Data Services. Por lo tanto, apenas uno crea una orden de compra, o publica un ítem en un sistema ERP, los datos están disponibles para análisis en HANA.
La capacidad de analizar datos inmediatamente es la clave fundamental de la historia de éxito de HANA, que nos permite hacer "negocios en tiempo real".
La solución preferida de Oracle, en cambio, es mantener los datos transaccionales detallados en una base de datos Oracle 11g sobre Exadata, después hacer ETL (extracción, transformación y carga) de esos datos en una base de datos Oracle 11g data warehouse, también sobre Exadata. Después de eso hay que llevar el rastro de las consultas en el data warehouse a través de una herramienta de Oracle, que recomienda qué tablas agregadas armar, las cuales a su vez se pueden cargar en la base de datos TimesTen sobre Exalytics, para mejorar el rendimiento de las consultas. Las tablas agregadas son resúmenes de los datos en el data warehouse a un momento dado, y se deben refrescar completamente (Exalytics no tiene soporte para refrescar datos de manera incremental) cada vez que uno quiera que los datos actualizados se reflejen en el ambiente Exalytics. Las consultas sobre los datos que no están cacheados en una appliance Exalytics vuelven al data warehouse que está por debajo para poder obtener resultados.
Entonces, ¿cómo es que todo esto puede responder preguntas antes de que las pensemos? Muy por el contrario, uno tiene que haber hecho la pregunta, y encima varias veces, antes de que las herramientas de Oracle nos alerten de los beneficios de tener esos datos cacheados en Exalytics.
Los clientes de SAP que están usando la combinación de SAP NetWeaver BW con el BW Accelerator están bastante familiarizados con este tipo de solución. Es prácticamente la misma que SAP ha estado vendiendo desde hace muchos años. Para los clientes con BWA, los datos transaccionales se guardan en una base de datos ERP, y luego se cargan en una base de datos BW (para ambas se puede elegir Oracle 11g, DB2, SQL Server, Sybase ASE, etc.). Los datos del cubo se cachean en el BW Accelerator, el cual es una appliance multi-nodo en memoria diseñada para agilizar el acceso de las consultas.
Nótese que en el caso de la solución BWA de SAP, la appliance en memoria carga los datos del cubo directamente, no desde tablas agregadas, de modo que no se pierde tiempo en armar dichas tablas agregadas (aunque, para ser justos, toma un cierto tiempo cargar el motor de caching). Oracle ha elegido cargar solamente tablas agregadas en su base de datos en memoria TimesTen para Exalytics, así que tanto armar las tablas agregadas como cargarlas a TimesTen lleva algo de tiempo (se pueden combinar ambos pasos en uno solo, pero lógicamente hay que ejecutar ambas operaciones).
El problema con estas soluciones es que:
  • La latencia de los datos puede volverse significativa debido a la cantidad de tiempo entre la transacción y la disponibilidad del análisis.
  • Para poder cachear consultas, hay que poder anticiparlas. Esto impide una verdadera capacidad de consulta ad-hoc, o al menos la vuelve impracticable, por razones de rendimiento.
  • Los datos disponibles en el sistema de análisis son agregados, por lo que el significado de los detalles 'crudos' se puede perder.
Además, los problemas de la implementación específica de Oracle a la fecha (si la comparamos con el BW Accelerator de SAP) son:
  • Las tablas agregadas que se cargan en Exalytics sólo se pueden refrescar todas al mismo tiempo, y no de manera incremental. De modo que cada vez que cambien sus datos en el data warehouse, tendrán que borrar y recrear sus tablas manualmente (o programáticamente, mediante scripts). Para grandes conjuntos de datos esto puede ser una enorme pérdida de tiempo y un proceso de mantenimiento muy exigente. Me imagino que el mantenimiento y el tiempo que esto insume debe hacer que los clientes refresquen sus datos con menor frecuencia.
  • Exalytics está diseñada para cachear sólo las tablas agregadas, las cuales son resúmenes de los datos en el cubo. En cada uno de los ejemplos que he visto, muchas tablas agregadas sobre un único cubo tienen muchos campos duplicados. Esto es similar a las tablas individuales que tienen múltiples índices secundarios con columnas superpuestas, cada una diseñada para responder a consultas similares pero no idénticas de los usuarios, y que por lo tanto sólo se pueden crear una vez que las consultas se conocen. BWA, en cambio, puede cachear un cubo entero en memoria, y por eso puede responder cualquier consulta sobre datos del cubo.
Si les cuesta creer lo que afirmé sobre la solución de Oracle, no hay problema, no me voy a ofender. Los invito, sí, a que miren el video que sigue, donde un consultor experto de Exalytics muestra consultas que corren con bastante lentitud sobre Exalytics. Luego trata de arreglar eso mediante un proceso medio complejo y rebuscado, en el cual el Summary Advisor de Oracle le recomienda tablas agregadas basadas en el uso (donde el 'uso' se limita a las consultas que acaba de hacer); a continuación guarda las definiciones del agregado como un script, y ejecuta el script para crear las tablas agregadas.




(Debería mencionar aquí que el Summary Advisor existe desde hace ya un tiempo como una herramienta que ayuda a los DBA a construir vistas materializadas en un RDBMS estándar de Oracle, aunque estoy seguro de que ha sido actualizado desde entonces.)
Sin embargo, no estamos comparando la solución de Oracle con SAP BWA; estamos comparándola con SAP HANA. En cuyo caso, los puntos siguientes son los que más se destacan a la hora de elegir entre una y otra (de nuevo, si nos enfocamos en la problemática de la administración de datos):
  • La solución Ex-box de Oracle apunta a hacer más rápido el análisis, a través de varias capas de hardware redundante (lo cual implica costos redundantes), pero esto también resulta en datos redundantes, ya que se copian datos de una base de datos OLTP a una OLAP y a un cache Exalytics, lo cual suma una mayor latencia entre transacciones y análisis. El objetivo de HANA es simplificar el stack reduciendo capas. Por supuesto, todavía hay duplicación al pasar de OLTP a HANA, pero cuando SAP ERP tenga soporte sobre HANA a fin de año, entonces los clientes podrán ir a una única base de datos para correr sus análisis directamente sobre sus tablas transaccionales de datos.
  • Dar soporte a todas las capas de la solución de Oracle requiere tareas de mantenimiento y ajuste de estructuras tales como índices, vistas materializadas, tablas agregadas, etc. Cada una de éstas requiere mantenimiento, ajuste, tiempo y recursos. Y, hablando ahora como ex-empleado de Oracle, me consta que se pierde una cantidad enorme de tiempo en tratar de solucionar cada cuello de botella que aparece en un DBMS de Oracle (es decir, un juego de "bottleneck whack-a-mole").
  • Parece que la estrategia de Oracle para escalar horizontalmente usando múltiples appliances Exalytics exige mantener datos duplicados en varios nodos. (Me baso en el siguiente comentario: "Si Ud. tiene varios equipos Exalytics conectados a través de InfiniBand para alta disponibilidad, debería ingresar entradas para cada uno de ellos aquí, y el Summary Advisor entonces podrá llenarlos como mirrors, de tal manera que haya uno disponible si otro se cae".). Me parece que eso agrega más complejidad a la administración de esta solución, porque requiere un seguimiento de qué datos están duplicados a lo largo de varios servidores para soporte de redundancia y balanceo de carga, sobre la base de que múltiples appliances Exalytics son, de hecho, múltiples bases de datos TimesTen distintas. HANA, en cambio, corre como una única base de datos repartida en varios nodos, de modo que no necesita duplicación de datos dentro de la base de datos.
En resumen, SAP HANA brinda la capacidad de obtener rendimiento en tiempo real sobre prácticamente cualquier conjunto de datos, ya sea en cubos estructurados, simples tablas transaccionales, o ambos. Oracle afirma que puede responder instantáneamente sus preguntas, antes de que las hagan, pero en mi opinión está claro que eso sólo es posible si el DBA o los desarrolladores han anticipado sus pensamientos y armaron tablas agregadas para darles soporte, o si mucha gente que está usando su sistema ya hizo las mismas preguntas.


No hay comentarios:

Publicar un comentario