mente los DBMS relacionales almacenan tuplas completas de datos tabulares, junto con índices auxiliares que identifican el B-tree de los atributos de la tabla. Estos índices pueden ser primarios, en el que las filas de la tabla se almacenan lo más cerca posible de forma ordenada en el atributo especifico, o secundarios, en cuyo caso no se hace ningún intento de mantener los registros subyacentes en el orden que esta el atributo indexado. Estos índices son eficaces en un OLTP, pero no funcionan bien en un mundo de lectura optimizada. En este último caso, otras estructuras de datos son ventajosas, incluidos los índices de mapa de bits [58], los índices de mesa en cruz [59], y las vistas materializadas [60]. En un DBMS de lectura optimizada se puede explorar el almacenamiento de datos utilizando sólo estas estructuras de lectura óptimas. Por lo tanto, C-Store almacena físicamente una colección de columnas, cada una asignada a algún atributo. A los Grupos de columnas ordenados en el mismo atributo se les conoce como "proyecciones", la misma columna puede existir en múltiples proyecciones, posiblemente ordenadas en atributos diferentes. Se espera que las técnicas planteadas por los autores de esta propuesta referentes a la compresión agresiva les permitan dar soporte a múltiples órdenes de distribución de columnas, sin una explosión en el espacio. Claramente, las colecciones de “off-the-shelf” y "blade" o computadoras en "red" serán la arquitectura de hardware más barata para aplicaciones de cómputo y de almacenamiento intensivo tales como DBMS [61]. Por lo tanto, cualquier nueva arquitectura DBMS debe asumir un ambiente de red en el que hay nodos de G (ordenadores), cada uno con disco de memoria privada. Se propone la partición de datos horizontalmente a través de los discos de los distintos nodos como en la arquitectura [62]. En un futuro próximo puede tener decenas o cientos de nodos, y cualquier nuevo sistema debería ser diseñado para las redes de este tamaño. Por supuesto, los nodos de una red informática pueden ser físicamente co-localizados o divididos en grupos de nodos co-localizados. Puesto que los administradores de bases de datos se ven en apuros para optimizar un entorno de red, es fundamental que se asignen las estructuras de datos a los nodos de la red de forma automática. Además, dentro de la consulta se ve facilitada por el paralelismo de la división horizontal al almacenar estructuras de datos, y seguir el ejemplo de Gamma [61] en la ejecución de esta construcción. Sin embargo, el almacenamiento de copias idénticas, no necesariamente se hace igual. C-Store permite a los objetos redundantes se almacenen con criterios de ordenación diferentes, lo que proporciona un mayor rendimiento de recuperación, además de alta disponibilidad. En general, el almacenamiento de proyecciones superpuestas mejora aún más el rendimiento, siempre y cuando la redundancia vaya de la mano. Es sin duda esencial, para llevar a cabo las actualizaciones transaccionales, un entorno principalmente de lectura. Los almacenes tienen la necesidad de realizar actualizaciones on-line para corregir errores. Además, existe una creciente presión hacia los almacenes en tiempo real. El deseo final es la actualización on-line de los almacenes de datos de una manera eficiente. Obviamente, para mundos como el CRM, es necesario realizar las actualizaciones on-line. Hay una tensión entre el suministro de actualizaciones y la optimización de las estructuras de datos para la lectura. Por ejemplo, en el KDB y el Addamark, las columnas de datos se mantienen en el orden de entrada de secuencia. Esto permite la inserción eficiente de los nuevos elementos de datos, ya sea en lotes o de forma transaccional, al final de la columna. Sin embargo, el costo es una estructura de recuperación de menos factibilidad de ser óptima, dado que la mayoría de las cargas de trabajo de consulta se ejecutará más rápido con los datos de otro orden. Sin embargo, las columnas almacenadas que no entren de manera secuencial harán inserciones más difíciles y costosas. C-Store se acerca a este dilema desde una nueva perspectiva. Combina en una sola pieza de software, tanto un almacenamiento en columna orientado a la lectura optimizada, como la actualización / inserción de los almacenamientos orientados a la escritura, conectados por un motor tupla, como se observa en la Figura 10. En el nivel superior, hay un pequeño almacén de escritura (WS), componente, que está diseñado para soportar inserciones de alto rendimiento y actualizaciones. También hay un componente mucho más grande llamado almacén de Lectura optimizada (RS), que es capaz de soportar grandes cantidades de información. RS, como su nombre lo indica, está optimizado para leer y sólo admite una forma muy restringida de inserción. Figura 10. Arquitectura de C-Store Fuente: C-Store: A Column-oriented DBMS. (op.cit) Por supuesto, las consultas deben tener acceso a datos en sistemas de almacenamiento de ambos. Las inserciones se envían a WS, las que se eliminan debe ser marcadas en RS para su posterior depuración por el motor de tuplas. Las actualizaciones se implementan como una inserción y luego una eliminación. A fin de apoyar un motor tupla de alta velocidad, se utiliza una variante del concepto de LSM-tree [63], que apoya una fusión con el proceso que mueve tuplas de WS a RS a granel por un método eficiente de la fusión de los objetos de datos con grandes bloques de RS, lo que resulta en una nueva copia de RS que se instala cuando finaliza la operación. La arquitectura de la Figura 10 debe ser compatible con las transacciones en un ambiente de muchas de las grandes consultas ad-hoc, las transacciones de actualización más pequeñas, y tal vez las que se insertan continuamente. Generaran un gran conflicto de lectura-escritura y la degradación del rendimiento debido a la concurrencia y callejones sin salida. En su lugar, se esperan consultas de sólo lectura que se ejecutan en modo historia. En este modo, la consulta selecciona una marca de tiempo T, menor que el de la mayoría de las transacciones que se han comprometido recientemente, y la consulta es semánticamente una garantía para producir la respuesta correcta a partir de ese momento de la historia. Proporcionar aislamiento instantáneo [64] requiere que C-Store soporte datos de tipo “timestamp”. Por último, los optimizadores de la mayoría de los sistemas comerciales están orientados a las filas, obviamente construido para almacenes en línea que predominan actualmente en el mercado. Ya que ambos RS y WS son orientados a columnas, tiene sentido construir un optimizador orientado a columnas. Como se muestra, este software no se parece en nada a los diseños tradicionales que hoy prevalecen. A continuación se expone con detalle el diseño de la plataforma tecnológica de almacenamiento de datos orientado a columnas, C-Store. El cual es un DBMS orientado a columnas que está diseñado para reducir el número de accesos al disco por consulta. Las características innovadoras de la C-Store son: 1. Una arquitectura híbrida con componentes optimizados tanto para insertar y actualizar con frecuencia (WS), como para el alto rendimiento de la consulta (RS). 2. El almacenamiento redundante de los elementos de una tabla en varias proyecciones superpuestas en diferentes órdenes, de modo que una consulta se pueda resolver mediante la proyección más ventajosa. 3. Columnas con alto nivel de compresión mediante el uso de uno o varios sistemas de codificación. 4. Un optimizador orientado a columnas. 5. Alta disponibilidad y un rendimiento mejorado a través de K-seguridad usando un número suficientemente grande de proyecciones superpuestas. 6. El uso de aislamiento instantánea para evitar 2PC o el bloqueo de consultas. Cabe destacar que si bien muchos de estos temas tienen un paralelismo con las cosas que se han estudiado de forma aislada en el pasado, es su combinación en un sistema real, las que hacen de C-Store una plataforma tecnológicamente interesante y única. 5.2 EL MODELO DE DATOS C-Store es compatible con el modelo de datos relacional, en donde una base de datos se compone de una colección de tablas con el nombre, cada una compuesta por una colección de nombres de atributos (columnas). Como en la mayoría de los sistemas relacionales, los atributos (o conjuntos de atributos) de las tablas de almacenamiento en C-Store se pueden formar diferenciando cada tupla por medio de una clave primaria única, o por medio de una clave externa que hace referencia a una clave primaria en otra tabla. El lenguaje de consulta C-Store es SQL, con la semántica estándar SQL. Sin embargo los datos en C-Store no están almacenados físicamente con este modelo de datos lógico. Considerando que la mayoría de los almacenes fila implementan directamente tablas físicas y luego añaden varios índices para acelerar el acceso, C-Store implementa sólo proyecciones. En concreto, una proyección de C-Store se basa en una tabla determinada lógica, T, y contiene uno o más atributos de esta tabla. Además, la proyección puede contener cualquier número de otros atributos de las tablas de otros