junio 04, 2012

Columnas, filas y cajas móviles

By Stefan Schaffer

La mayor diferencia entre la base de datos SAP HANA™ y los sistemas tradicionales de bases de datos relacionales es el hecho de que se pueden almacenar los datos en columnas, mientras que las bases de datos tradicionales almacena los datos en filas. Comprender las diferencias entre estos dos tipos de almacenamiento es de fundamental importancia, no sólo para decidir que tablas modelar en filas y cuales en columnas, sino también para comprender que problemas o en que escenarios SAP HANA™ puede ofrecer una extraordinaria mejora de rendimiento y aquellos escenarios en los cuales no es posible.
En este post, me gustaría explicar almacenamiento en filas y columnas utilizando una metáfora del mundo real del almacenamiento físico.
Si Ud. ya está familiarizado con el tema, puede dejar de leer acá - a menos que este interesado en la metáfora propiamente dicha para explicar los conceptos de una manera sencilla para los novatos.

Almacenando y Moviendo Cosas

La gestión de los datos digitales tiene mucho que ver con a dónde poner las cosas (en este caso bits y bytes), de manera que puedan dejarse guardarse, moverse de un lado a otro y, finalmente, encontrar y recuperarse de manera fácil y rápida - al igual que en el mundo del almacenamiento físico. Suponga que usted es responsable de vaciar una oficina de 100 personas que será pintada en un fin de semana. Usted puede recoger todas las piezas (laptops, teclados, mouse, ...) y colocarlas en un camión, llevarlas a un almacén, guardarlas y recogerlas nuevamente para llevarlas a la oficina una vez que esta se encuentre en condiciones. Pero seguramente que Ud. no lo haría de esa manera, ya que no resulta muy eficiente. Lo que seguramente haría es poner los artículos en cajas, mover y almacenar las cajas y recuperar los artículos que se desplazaron una vez que los necesite -después de que la pintura se haya terminado.

Almacenamiento en filas

La forma en que, probablemente, se asignen artículos a cajas es una caja (o varias, pero vamos a quedarnos con uno en aras de simplicidad) por empleado. Así que la caja de Jon Smith contiene su computadora portátil, su teclado, su mouse, etc.
Ud. haría esto porque es fácil: pone la caja vacía a su oficina, la llena con sus artículos, la cierra y la envía. Después de la mudanza, todo lo que tiene que hacer es poner la caja en la oficina de John y vaciarla. Esto es más o menos cómo funcionan los sistemas RDBMS tradicionales. Toman los diferentes datos -campos - que se encuentran relacionados entre si, por ejemplo por una transacción financiera, y los almacena en forma de filas cercanas entre si.
Lo hacen de esta manera por las mismas razones que usted empacaría los artículos de John en la misma caja: el sistema esta optimizado para mantener las cosas que tienen el mismo origen juntas ya que usualmente se recuperan al mismo tiempo y en el mismo lugar. Empacar y desempacar/ lectura y escritura son muy rápidos para este tipo de necesidad.

Almacenamiento en columnas

Supongamos ahora que Ud. ha empacado los artículos en cajas de la manera descripta y se han alamcenado. Ahora el Director de Administración y Finanzas se acerca y le dice: "Lo siento mucho, pero necesito de inmediato una lista de todos los números de serie de las laptops almacenadas ". Esto significa que usted tiene que abrir cada caja, sacar la laptop de manera de poder crear esta lista para su Director.
¡Qué pesadilla! Esto seguramente le llevará más que todo el fin de semana!. Vamos a suponer que sabía de antemano que esta solicitud podía ser requerida. 
¿Cómo podría entonces organizar el almacenamiento de forma diferente para acceder de manera más fácil a la información y completar la solicitud de su Director?
Bueno, se podrían almacenar todas las laptops en una caja (o varias), todos los mouse en otra y todos los teclados en una tercera caja. En este caso, obtener una lista de todos los números de serie (o la búsqueda de una laptop con un número de serie específico) sería facilísimo. Sólo tiene que abrir la caja identificada como “laptops” y buscar sus números de serie. De esto se trata el almacenamiento en columnas.

Los beneficios del almacenamiento columnar

Es cierto que este es un escenario muy poco habitual y artificial para una mudanza. Sin embargo, es un escenario muy común en el mundo de la informática empresarial. Buscar todos los pedidos de los clientes por encima de un valor determinado, requerir el total de los pedidos ingresados para este trimestre, etc. Los sistemas RDBMS son malos en la concreción de este tipo de pedidos, razón por la cual los sistemas agrupan / sumarizan estos datos y los almacenan de forma redundante, tratando de anticiparse a la necesidad. Cuando los datos se organizan en columnas, estas agrupaciones ya no son necesarias dado que resulta fácil y rápido abrir solo unas pocas cajas / leer algunas columnas y proporcionar luego las respuestas correctas. Esto puede hacer una gran diferencia en relación a la complejidad de los sistemas y volúmenes de datos. Pero ¿dónde están los inconvenientes?
Las Desventajas
Desafortunadamente, existen desventajas en el concepto de almacenamiento columnar. Mientras que los requerimientos sobre artículos de la misma naturaleza (columnas) se pueden cumplir rápidamente, el tiempo de respuesta es muy lento cuando se trata de recuperar datos de todos los artículos que se corresponden a una transacción financiera o a John Smith, ya que esto significa la apertura de muchas cajas. También el embalaje de las cajas es algo más complejo. Todo tiene un precio y el almacenamiento en columnas no es la mejor elección para todos los casos de uso. Pero, por fortuna, también hay buenas noticias. Como el almacenamiento en columnas permite una mejor compresión de datos, almacenar todos los datos en la memoria principal se hace más accesible, compensando algunas de las desventajas. Además, muchos menos agregados son necesarios, por ende el volumen de escritura también disminuye. De esta manera, los desarrolladores pueden obtener un mejor rendimiento mediante una mínima proyección donde sea posible.

Proyección mínima

Cuando nos fijamos en el código fuente de la mayoría de los sistemas de negocios, se encuentran muchas operaciones del tipo SELECT * FROM. Esto seria el equivalente a " deme todos los artículos de John Smith” en nuestro ejemplo anterior, y aun cuando no todos los artículos son realmente necesarios en este momento.
En el almacenamiento en filas esto es bastante mas sencillo: sólo tienes que traer la caja de John. E incluso, si no es necesario cada artículo de John, es muy eficaz en la mayoría de los casos. La recuperación de datos es simple. La única sobrecarga es que se están transportando elementos innecesarios que están en la caja, lo cual lleva a una carga de red ligeramente mayor, lo que en la mayoría de los casos es aceptable. Esta es la razón por la cual los desarrolladores optan por aprovechar la comodidad y flexibilidad de utilizar las funciones SELECT * FROM demasiado a menudo.
Pero la situación es diferente en el almacenamiento en columnas. Para cada articulo, inclusive para aquellos que no son necesarios, una caja adicional debe ser abierta. De esta manera, el rendimiento de la base de datos depende de manera lineal con el número de columnas solicitadas. Y como en los sistemas empresariales rara vez todos los campos de un registro son necesarios en el mismo momento, solicitar solamente los campos necesarios puede significar una gran diferencia. Acá es donde entra en acción la proyección mínima: es de suma importancia que los desarrolladores eviten los SELECT * FROM y los reemplacen por SELECT Field 1, FIELD 2,…, FIELD N FROM siempre que sea posible. Limitar el número de campos solicitados a un 20% -que es un número realista en muchos casos- puede reducir el tiempo de ejecución de una consulta en un porcentaje similar.

Entonces, ¿qué nos han enseñado las cajas?

Los ejemplos anteriores nos muestran como la manera en que pensamos recuperar la información debería impactar en el diseño de un modelo de datos en SAP HANA™ (que tablas almacenar en filas) y como los desarrolladores pueden optimizar el código para obtener un rendimiento óptimo cuando se utiliza el almacenamiento en columnas.  Además, esto nos permite vislumbrar el esfuerzo necesario para que un sistema de gestión –ERP- se encuentre disponible en SAP HANA™.

Sinceramente,
Stefan Schaffer



No hay comentarios:

Publicar un comentario