agosto 19, 2012

Un análisis crítico de las afirmaciones de Oracle sobre SAP HANA

By Sapdba's blog - David Hull

Quiero presentar mi apoyo al análisis que Perficient pronto hará público acerca de las afirmaciones de Oracle sobre las funcionalidades y capacidades de SAP HANA. Voy a tomarme unos momentos para exponer mi posición acerca de la verdad detrás de estas afirmaciones.
Por supuesto, todo esto está basado en el webcast de Oracle de Thomas Kurian. El webcast iba a anunciar funcionalidades de Exalytics, pero terminó dedicando más de la mitad de la hora a atacar a SAP HANA.
Ésta es simplemente una respuesta rápida en un blog. No tengo enlaces para justificar todo, pero todo lo que afirmo aquí con respecto a HANA puede ser verificado. Si alguien no me cree, que me interrogue todo lo que quiera, ¡y encontraré las pruebas!




Atributo Afirmación de Oracle Verdad
Caching de datos en memoria
TimesTen & SAP HANA
TimesTen hace caching de datos porque, como solución de base de datos, no es totalmente funcional. SAP HANA es una base de datos, de la misma manera que Oracle 11g, DB2 o SQL Server son bases de datos. No es solamente un cache de datos.
Almacenamiento en columnas en memoria
TimesTen & SAP HANA
SAP HANA implementa almacenamiento en columnas. Sin embargo, ¿puede alguien indicarme algún documento donde se muestre que TimesTen ofrece almacenamiento en columnas (no compresión de columnas)? Ah, ya me parecía que no.
Compresión en memoria de filas & columnas
Sólo TimesTen completamente (SAP HANA comprime sólo columnas)
Si bien es cierto que HANA no tiene compresión del almacenamiento en filas, el almacenamiento en filas está pensado para tablas dinámicas y pequeñas, de modo que la compresión realmente no es tan necesaria. La mayoría de los datos se guardan, idealmente, en el almacenamiento en columnas, que sí utiliza compresión. Oracle, en cambio, sólo ofrece almacenamiento en filas, y por eso no tiene características de rendimiento comunes a las soluciones con almacenamiento en columnas.
Índices en memoria
Sólo TimesTen
SAP HANA no solo tiene soporte para índices en memoria, sino que además son fáciles de usar: simplemente hay que dirigirse al manual de SQL y consultar la sintaxis que se usa para crearlos. Esto es fácil de verificar.
Optimizador de consultas en memoria (predictibilidad)
Sólo TimesTen
Por supuesto que SAP HANA tiene un optimizador de consultas basado en costo, para el almacenamiento en filas y en columnas, con soporte para planes de ejecución de consultas predecibles. (Asumo que están hablando de esto.)
Soporte en memoria para NUMA (para escalar verticalmente)
Sólo TimesTen
El soporte para NUMA depende de la arquitectura de hardware. Y, dado que HANA y Exalytics utilizan el mismo hardware (Intel CPU / 40 núcleos / 1TB RAM), es desconcertante oír a Oracle afirmar que TimesTen tiene soporte para NUMA y que HANA no lo tiene.
Cito del libro In-Memory Data Management: An Inflection Point for Enterprise Applications, de los Drs. Plattner y Zeier: "En sistemas ccNUMA, todos los caches de la CPU comparten la misma vista de la memoria disponible; la coherencia está asegurada por un protocolo implementado en hardware. Los sistemas NUMA que no tienen caches coherentes requieren capas de software para solucionar los conflictos en el acceso a memoria. Dado que la mayoría de los equipos disponibles de hardware estándar sólo provee ccNUMA, nos enfocaremos en esta forma." ("In ccNUMA systems, all CPU caches share the same view to the available memory and coherency is ensured by a protocol implemented in hardware. Non cache-coherent NUMA systems require software layers to take care of conflicting memory accesses. Since most of the available standard hardware only provides ccNUMA, we will solely concentrate on this form.")
Consultas paralelas en memoria (para escalar horizontalmente)
Sólo TimesTen
SAP HANA no solo tiene soporte para consultas paralelas / escalar horizontalmente, sino que SAP ya ha brindado pruebas y validación independiente de los resultados. Véase por ejemplo la prueba sobre el cluster de 16 nodos con 100TB de datos crudos. 100 mil millones de filas en una única fact table. Sin índices, sin agregados, sin cálculos previos ni caching. A diferencia de Exalytics, no hace falta conocer las consultas de antemano para empezar a armar estructuras tuneadas que les den soporte. Con todo, el total de las consultas de un mes de datos corrió en menos de .5 segundos, y 3 meses corrieron en alrededor de 1 segundo. Consulte el análisis en su totalidad aquí y un análisis de su impacto aquí.
Además, Oracle todavía tiene que presentar evidencia de que Exalytics tiene soporte para hacer consultas paralelas / escalar horizontalmente. Si alguien tiene alguna evidencia de esto, con gusto me retractaré de este enunciado, pero hasta donde conozco, uno puede instalar varios servidores Exalytics juntos y administrarlos de manera independiente, o usar balanceo de carga de red entre ellos, pero no puede administrarlos de manera cohesiva. HANA, por otro lado, actúa como una única base de datos, ya sea que esté instalada en 1 servidor o en 100 (como se puede apreciar en el cluster HANA de 100 nodos que se está probando en Santa Clara, California, y que se exhibió en la conferencia SAP Sapphire de mayo de 2012).
Tablas agregadas en memoria & conjuntos de resultados en memoria
Sólo TimesTen
Esta afirmación es graciosa. Las tablas agregadas son molestos mecanismos que bases de datos como Oracle 11g tienen que implementar, porque de otra manera no podrían alcanzar los requerimientos de alto rendimiento. ¿HANA puede armar tablas agregadas? ¡Claro! Pero no las necesita. Tome nota de las pruebas de rendimiento que se han hecho sin este tipo de tablas, para ver evidencia de que son innecesarias.
Con Exalytics, el modelo de Oracle es que el cliente mantenga sus datos en una base separada, arme tablas agregadas, y cachee esas tablas en TimesTen. Entonces, cada vez que los datos cambien en la base de datos fuente, uno no ve esos cambios en las consultas hasta que refresque las tablas agregadas. Y hace falta que sean refrescos totales, dado que Exalytics Summary Advisor no tiene soporte para refrescos incrementales. ¡Imagine cuánto tiempo tomará eso para conjuntos de datos grandes!
Para más pruebas de que HANA tiene un mejor rendimiento sin tablas agregadas, vea el nuevo "BW Extended Mixed Load benchmark" y sus resultados, obtenidos con SAP HANA sobre HP Appsystem. BW es una aplicación analítica que usa tablas agregadas para correr sobre Oracle, DB2, SQL Server, etc. Sin embargo, con HANA, se logró un rendimiento sobresaliente sin tablas agregadas, ni índices secundarios o datos pre-calculados, etc.
Me gustaría resaltar que Exadata salió hace 4 años, y Oracle todavía no corrió ni un benchmark. HANA salió el año pasado, y ya publicó resultados de benchmarks estándares, y tiene planeado hacer más :)
Funciones analíticas en memoria
Sólo TimesTen
¿Qué, como Predictive Analytics?
Datos no estructurados en memoria
Sólo TimesTen
SAP HANA de hecho tiene soporte para datos no estructurados. Lo ha tenido desde el comienzo, aunque no se expuso hasta SP4. Los detalles se pueden encontrar googleando "sap hana unstructured data" o mirando estas páginas.
Como el Dr. Vishal Sikka señala en su blog, esta afirmación es particularmente irónica, puesto que HANA se basa, en parte, en el motor de búsqueda de texto TREX.
Alto rendimiento en operaciones de escritura y actualización
Sólo TimesTen
En el webcast de Oracle donde se anunciaron estas afirmaciones, Thomas Kurian describió por qué piensa que el rendimiento de escritura de HANA es pobre. Dijo que cuando se insertan datos en HANA, se insertan en un almacenamiento por filas, y que después se migra al almacenamiento en columnas. Luego, cuando se hace una actualización sobre los datos almacenados en columnas, esos datos se tienen que llevar nuevamente a almacenamiento en filas, después se actualizan, y se llevan de nuevo al almacenamiento en columnas. Si Ud. oyera esto, ¿no pensaría también que el rendimiento de las actualizaciones en HANA es lento? ¡Claro! Pero no es así como funciona, para nada. Si Ud. quiere administrar sus datos en un almacenamiento en filas, puede guardarlos ahí. Si Ud. quiere administrar sus datos en un almacenamiento en columnas, puede guardarlos ahí y sólo ahí. Si quiere usar ambos, puede hacerlo. La decisión es suya.
Si quiere números, la prueba de escalabilidad de 16 nodos de HANA cargó 16 millones de filas por minuto, a través de SQL, directamente en la base de datos en memoria; en estos tiempos se incluye la escritura a disco para tener persistencia. He visto tiempos de carga incluso más rápidos que estos (uno de hasta 770.000 filas insertadas por segundo), pero no tengo los enlaces a mano.
Persistencia de datos en disco TimesTen & SAP HANA Sí, todos los datos en SAP HANA se administran completamente en HANA, y se persisten a disco de manera tal que, si hay un corte de energía eléctrica, por ejemplo, no se pierda ningún dato. Por supuesto, con TimesTen, no es la fuente de datos de todas maneras, sino sólo un cache que se refresca continuamente desde la base de datos fuente.
Corrección / Integridad transaccional TimesTen (se desconoce en SAP HANA) Sí, SAP HANA es una base de datos con soporte ACID completo. Esto significa que cuando se comitea una transacción, se puede asegurar que se escribió no solo en memoria, sino también a disco, de modo que si algo llegara a suceder, los datos no se pierden. Por supuesto, Oracle ni siquiera tiene soporte para transacciones en Exalytics; es para análisis sobre datos cacheados solamente.
Concurrencia multi-versión TimesTen (se desconoce en SAP HANA) Sí, SAP HANA tiene soporte para control de concurrencia multi-versión, como Oracle 11g. Si se ejecuta una consulta en SAP HANA, se puede asegurar que los datos devueltos son datos comiteados, y que son un snapshot en un punto en el tiempo de los datos, tal como eran cuando la consulta se ejecutó. Si algunos datos cambian durante la ejecución de una consulta, esos no se devuelven entre los resultados, sino que se devuelve una versión anterior de esos datos, tal como lo que Oracle implementa con los segmentos de rollback.

El blog de Perficient además reporta lo siguiente:
Oracle también afirma que, en comparación con Exalytics, SAP Hana tiene las siguientes limitaciones:
Reporting operacional

  • Fuentes de datos limitadas con Sybase Replication Server
  • Soporte limitado para 3ra forma normal en Business Objects

Lo gracioso sobre esta afirmación sobre las fuentes de datos es que SAP HANA ni siquiera tenía soporte para Sybase Replication Server cuando Oracle hizo su webcast. Ahora sí lo tiene, y este soporte se suma a la lista de tecnologías que interactúan con HANA, entre las cuales se cuentan SAP Landscape Transformation Services y Business Objects Data Services. Por supuesto, siempre se puede usar SQL, SQLScript, MDX, y otras tecnologías.
Con respecto al comentario sobre la 3ra forma normal, no tengo idea de cuál puede haber sido la motivación. Para citar a un colega, el SAP Mentor y experto en Business Objects Eric Vallo, de EV Technologies:
Ésa es una afirmación muy amplia para hacer sobre cualquier herramienta de reportes. La realidad es que los datos altamente normalizados harán que la base de datos trabaje más si el usuario intenta armar consultas complejas. Ahora bien, ¿es eso producto de la herramienta de reporte, de la base de datos, o del diseño de la aplicación? Para mí, 3NF por supuesto tiene su lugar en, por ejemplo, un sistema operacional/transaccional, muy optimizado para una aplicación web. Sin embargo, hacer reportes sobre esos datos transaccionales puede resultar una porquería si tengo que recorrer millones, o incluso miles de millones de registros de datos transaccionales en un RDBMS tradicional. De modo que nosotros, los equipos de BI, hacemos tablas agregadas y ETL para lidiar con esto y obtener algo sobre lo que podamos hacer reportes un poco más fácilmente, y con suerte de manera más eficiente. ¿HANA o IQ son la solución para esto? Me parece que sí, o al menos pronto lo serán. BOBJ genera SQL; puede ser tan eficiente o ineficiente como uno quiera.
Data Mart

  • No tiene soporte para consultas paralelas (para escalar horizontalmente) ni para NUMA (para escalar verticalmente); SQL limitado y no estándar
Eso ya fue tratado más arriba, con las pruebas que se corrieron sobre el cluster de 16 nodos. ¿SQL limitado y no estándar? Mira, Thomas, revisa el manual de HANA SQL (enlazado más arriba, también). Verás que sigue el estándar ANSI.
Data Warehouse

  • Posible en teoría, pero demasiado caro en la práctica si se desea usar algo por encima de 2-4 TB
¿Oracle previniéndonos de que una cosa es "demasiado cara"? Como alguien que fue cliente de Oracle durante mucho tiempo, cuando administré, durante muchos años, aplicaciones SAP que corrían sobre Oracle, me voy a permitir reírme un poco :)
La verdad es que el precio de SAP HANA baja a medida que uno compra más, y es la solución más rentable del mercado para las necesidades de análisis en tiempo real.
OLAP Multi-dimensional

  • Rendimiento limitado para operaciones de escritura al actualizar tablas agregadas, debido al esquema de almacenamiento en columnas en memoria
¿De nuevo con el rendimiento limitado para operaciones de escritura al actualizar tablas agregadas? HANA no necesita tablas agregadas. Oracle las necesita porque no tiene otra manera de obtener un buen rendimiento. Y para que no piensen que el rendimiento en operaciones de escritura se dificulta por el almacenamiento en columnas (ya sea al escribir tablas agregadas o no), los invito a que lean el paper de Vishal Sikka, et al: Transaction Processing in SAP HANA Database - The End of a Column Store Myth.
Planeamiento y presupuesto

  • Capas de tablas agregadas en SAP BW impactan sobre el planeamiento en BW sobre HANA, resultando en un rendimiento limitado en operaciones de escritura con almacenamiento en columnas.
Me gustaría saber de dónde sacaron esto. Thomas Kurian mencionó en su webcast las "capas de tablas agregadas" y dijo que BW sobre HANA requiere tablas agregadas en BW y tablas agregadas en HANA. La verdad es que: a) no hay tablas agregadas en la capa de aplicación de BW, y b) no hace falta tener tablas agregadas en la base de datos al correr la aplicación en memoria tradicional de SAP, el BW Accelerator, y tampoco al correr la solución actual, SAP HANA.
Descubrimiento no estructurado

  • No hay soporte en HANA para datos no estructurados; no hay capacidades para descubrimiento estructurado y no estructurado.
Sí, SAP HANA tiene soporte para datos no estructurados. No estoy seguro de a qué se refiere con "capacidades de descubrimiento". De hecho, algunas de las primeras implementaciones de HANA tenían datos no estructurados. El soporte para datos no estructurados está más formalizado ahora con HANA SP4, e incluye la funcionalidad de búsqueda de textos sobre datos estructurados y no estructurados. Los detalles se pueden encontrar aquí, por ejemplo: https://www.experiencesaphana.com/videos/1573
Aplicaciones empaquetadas y herramientas de BI

  • Todas las aplicaciones de análisis empaquetadas por Oracle, las aplicaciones empaquetadas EPM y cualquiera de sus herramientas de BI funcionan con Exalytics; HANA sólo funciona con herramientas SAP.
Entonces, lo que están diciendo acá es que Exalytics funciona con todas las aplicaciones de Oracle, pero SAP HANA sólo funciona con las herramientas de SAP. ¿Se ve la ironía?
Sí, HANA tiene soporte principalmente para herramientas SAP, pero SAP también está desarrollando HANA de una manera abierta. HANA va a funcionar con cualquier herramienta de terceros desarrollada para HANA a través de cualquier interfaz estándar
Además de lo ya dicho, Oracle también dice que Exalytics es más barato que SAP HANA:
Afirman que su Data Mart en memoria, con 512GB de datos comprimidos y 1TB de memoria costaría US$ 825.000, mientras que la solución equivalente de SAP HANA con hardware de IBM costaría US$ 4.100.000.
Oracle también dice que su paquete para Análisis en memoria para Enterprise DW, con 20TB de datos comprimidos y 40TB de memoria, que incluye 1 Exalytics + 1 Exadata, tendría un costo total de US$ 2.500.000
La misma funcionalidad, usando SAP HANA y hardware de IBM, en cambio, requeriría 40 servidores tamaño L para albergar los datos en memoria, lo cual redundaría en un costo total de US$ 126.500.000
Oracle también dice que lo que cobran por mantenimiento y actualización para las configuraciones mencionadas sería sustancialmente más barato.
No tengo mucho que decir sobre el esquema de precios, porque no lo entiendo del todo. Lo que sí diré es que, en primer lugar, estos precios son mucho más altos que cualquier cosa cercana a la realidad.
En segundo lugar, pero no por ello menos importante, quiero hacer notar que están comparando una base de datos HANA con 20TB de datos comprimidos y 40TB en total de RAM, con una base de datos Oracle 11g sobre Exadata, y una única appliance Exalytics (la cual tiene 1TB de RAM, aproximadamente 600GB de los cuales están disponibles para TimesTen, y sólo la mitad de eso puede contener datos). De modo que la comparación se reduce a:
HANA: base de datos de 40TB en memoria, vs. Oracle: base de datos con un cache para datos agregados de 600GB en memoria y 40TB en disco.
¿Se aprecia la diferencia?
Bueno, eso es realmente todo lo que tenía para decir. Simplemente quería dar una respuesta rápida para todos aquellos a quienes les interesa el tema.

Original in English: http://blog.sapdba.com/2012/06/critical-analysis-of-oracles-claims.html

No hay comentarios:

Publicar un comentario