base datos

La escalabilidad de base de datos, la elasticidad y laautonomía en la Nube⋆ [Resumen Extendido] Divyakant Agrawal, Amr El Abbadi, Sudipto Das, y Aarón J. Elmore Departamento de Ciencias de la Computación de la Universidad de California en Santa Bárbara Santa Bárbara, CA 93106, EE.UU. {Agrawal, amr, Sudipto, aelmore} @ cs.ucsb.edu http://www.cs.ucsb.edu/~dsl Resumen. La computación en nube se ha convertido en un paradigma de gran éxito para el despliegue de aplicaciones web. Escalabilidad, la elasticidad, la fijación de precios de pago por uso, y las economías de escala de las operaciones a gran escala son las principales razones para la adopción exitosa y generalizada de infraestructuras de nube. Desde la mayoría de aplicaciones en la nube son impulsados de datos, sistemas de gestión de bases de datos (DBMS) poderes Ering estas aplicaciones forman un componente crítico en la pila de software en la nube. En este artículo, presentamos una visión general de nuestro trabajo en inculcar estos anteriormente se ha mencionado "características de las nubes" en un sistema de base de datos diseñada para soportar una variedad de aplicaciones desplegadas en la nube: el diseño de gestión de base de datos escalable arquitecturas de uso de los conceptos de la fisión y la fusión de datos de datos, lo que permite la elasticidad ligera usando bajo costo de migración de base de datos en vivo, y el diseño de controladores inteligentes y autonómicas para la gestión del sistema sin intervención humana. Palabras clave: La computación en nube, la escalabilidad, elasticidad, sistemas autonómicos. 1 Introducción La proliferación de la tecnología en las últimas dos décadas ha creado una dicotomía interesante para los usuarios. Hay muy poco desacuerdo en que la vida de un individuo es notablemente enriquecido como resultado de un fácil acceso a la información y servicios que utilizan un amplio espectro de plataformas informáticas, tales como estaciones de trabajo personales, ordenadores portátiles y dispositivos portátiles como teléfonos inteligentes, PDAs, y tabletas (por ejemplo, los iPads de Apple). Los facilitadores tecnológicos son de hecho los avances en la creación de redes y los paradigmas de servicios basados en la Web que permiten a los usuarios obtener información y servicios de datos ricos en cualquier momento borrando la distancia geográfica o física entre el usuario final y el servicio. Como proveedores de la red continúan mejorando la capacidad de sus infraestructuras inalámbricas y de banda ancha, este paradigma seguirá alimentando la invención de nuevos servicios imaginativos tivas que simplifican y enriquecer las vidas profesionales y personales de los usuarios finales. Sin embargo, algunos argumentan que las mismas tecnologías que han enriquecido la vida de ⋆ Este trabajo es financiado parcialmente por subvenciones NSF III 1018637 y 1053594 del SNC y un Premio de Relaciones NEC Labs de América Universidad. Los ingredientes clave de este éxito se debe a muchos ofrecen funciones DBMS: funcionalidad global (modelado diversos tipos de aplicación utilizando el modelo relacional que es intuitiva y relativamente simple). Anteriormente.ponente en la arquitectura global del servicio. disponible y escalable. etc. la tendencia actual es la tecnología para alojar aplicaciones de usuario. consistencia (que trata de cargas de trabajo simultáneas sin preocuparse por los datos convertirse en fuera de -sync). cualquier perturbación tiene consecuencias globales Making el servicio no esté disponible para una comunidad de usuarios de todo. así como del proveedor de servicios o la perspectiva del sistema. Ahora.dad se puede aumentar mediante la adición de recursos de hardware adicionales siempre que esté justificado por las fluctuaciones de carga. La otra fuente de variación de la carga se debe al crecimiento impredecible (o disminución) en el uso. rendimiento (tanto de alto rendimiento. los datos y por lo tanto el sistema de gestión de base de datos (DBMS) es una tecnología integral com. La fiabilidad es un requisito clave para asegurar el acceso continuo a un servicio y se define como la probabilidad de que una aplicación o sistema dado estarán funcionando cuando sea necesario como se mide durante un período determinado de tiempo. La razón de la proliferación de DBMS. los usuarios tienen que navegar a través de una red de cómputo múltiple y plataformas de almace. durante la última década .de usuarios 24 × 7 a través de Internet utilizando una gran cantidad de tecnologías basadas en la web modernos.namiento para hacer su trabajo. Relational DBMS han tenido en el modelado de una amplia variedad de aplicaciones. La experiencia adquirida en la última década de algunos de los líderes de la tecnología que proporcionan servicios a través de Internet (por ejemplo.2 Agrawal et al. baja latencia y más de 25 años de ingeniería). Ebay. Del mismo modo.prácticamente unlim. En resumen. una aplicación o servicio de interrupción fue típicamente limita a un pequeño número de usuarios. semanal y durante períodos más largos. los usuarios. en el espacio de computación en la nube es debido a la DBMS éxito y. el reto ahora es el desarrollo de plataformas de aplicaciones centradas en servidor que están disponibles para un número limi.) indican que las infraestructuras de aplicaciones en el contexto de nubes deben ser altamente fiable. La justificación es que a medida que las tecnologías de redes maduran. La transformación anterior que se ha traducido en las aplicaciones y servicios para el usuario están migrando de los dispositivos de los usuarios a la nube ha dado lugar a iCal y de investigación desafíos nológicos sin precedentes. A pesar de este éxito. y la fiabilidad (garantía de la seguridad y la persistencia de los datos en la presencia de diferentes tipos de fallas). en particular. Un reto para el usuario final importante es hacer un seguimiento de todas las aplicaciones y servicios de información en sus / sus múltiples dispositivos y mantenerlos sincronizados. Por lo tanto.tración de la mayoría de las aplicaciones y servicios al núcleo de la red. Una solución natural para superar esta complejidad y simplificar la vida computacionalmente y ricos en datos de un usuario final es impulsar la gestión y adminis. la escalabilidad tanto ha surgido como un requisito crítico. también han dado subir a algunos desafíos y complejidades. El requisito de escalabilidad surge debido a las fluctuaciones de carga constante que son comunes en el contexto de los servicios basados en la Web. desde la perspectiva de un usuario que accede a una aplicación en su / su dispositivo personal será indistinguible de acceso a la aplicación a través del cable de banda ancha o red inalámbrica. La necesidad de un diseño escalable es asegurar que el sistema de capaci. De hecho se producen estas fluctuaciones de carga a diferentes frecuencias: diaria. así como un desafío fundamental en el contexto de la nube. Amazon. En particular. En el contexto de la mayor parte de aplicaciones basadas en la nube y las implementaciones de servicios. tanto desde la perspectiva del usuario. servicios y datos en el núcleo de la red que se denomina metafóricamente como la nube. Desde el punto de vista-del usuario. Google. la disponibilidad es el porcentaje de veces que un sistema dado estará funcionando como se requiere. y Mi. En los entornos de cloud computing. Otro requisito que está estrechamente relacionado con la escalabilidad y la elasticidad de software de gestión de datos es la de la gestión autonómica. Las nubes). Esto es porque. tenemos que apoyar propiedad adicional de que tal la escalabilidad se puede aprovisionar dinámicamente sin causar ningún tipo de interrupción en el servicio. la atomicidad de aplicaciones y accesos de usuarios están garantizados sólo a nivel de una sola tecla. De hecho. El requisito de hacer aplicaciones web escalables en plataformas de cloud computing surge principalmente para apoyar número virtualmente ilimitado de usuarios finales. Almacenes de claves y valores en relación con los marcos de cloud computing han trabajado muy bien y un gran número de aplicaciones web han desplegado la combinación de esta tecnología cloud computing. Por lo tanto. Tiendas de valores clave como BigTable y PNUTS han sido diseñados para que puedan ser elástico o pueden ser aprovisionado dinámicamente en presencia de fluctuaciones de carga. La principal distinción es que en los DBMS tradicional. En el nivel de infraestructura de hardware. En el contexto de las tiendas de valores clave de esta relación está completamente cortado en los valores fundamentales en que cada entidad se considera una unidad independiente de datos o información y por lo tanto se puede mover libremente de una máquina a otra. los datos de administración es una tarea altamente manual en un entorno empresarial donde entrenó altamente un .crosoft han demostrado que los centros de datos proporcionan economías de escala sin precedentes desde múltiples aplicaciones pueden compartir una infraestructura común. Más líderes tecnológicos recientes. Otro de los retos en la nube que está estrechamente vinculada a la cuestión de la escalabilidad es desarrollar mecanismo para responder a las fluctuaciones bruscas de carga en una aplicación o un servicio debido a los aumentos repentinos de demanda o valles de los usuarios finales. son en general previsto para una infraestructura empresarial que se aprovisiona de forma estática. Tradicionales sistemas de gestión de base de datos cionales. como Facebook también se han beneficiado de este paradigma en la creación de aplicaciones complejas que son altamente escalable. que pueden escalar fácilmente de unas pocas máquinas a cientos o incluso miles de máquinas). la tecnología DBMS actual no proporciona herramientas y orientaciones adecuadas si una implementación de base de datos existente necesita para escalar hacia fuera de unas pocas máquinas a un gran número de máquinas. Por otra parte. Amazon. Tradicionalmente. AppEngine de Google y Microsoft Azure para alojar aplicaciones de terceros en sus respectivas infraestructuras de centros de datos (es decir. Por otra parte. Las tres empresas han tomado esta idea de compartir más allá de sus aplicaciones internas y proporcionar marcos como AWS de Amazon. La escalabilidad de un sistema sólo nos ofrece una te garantiza que un sistema puede ser ampliado desde unas pocas máquinas a un mayor número de máquinas. a diferencia de otros componentes de la tecnología para servicio en la nube. todos los datos dentro de una base de datos se trata como un "todo" y es la responsabilidad de los DBMS para garantizar la consistencia de los datos completos. el objetivo principal de los DBMS es realizar el más alto nivel de rendimiento para un determinado hardware e infraestructura de servidor. la mayoría de estos líderes de la tecnología han abandonado el DBMS tradicional y tecnologías de gestión de datos de propiedad en lugar han desarrollado denominadas tiendas de clave-valor. Los líderes tecnológicos como Google. los DBMS no puede escalarse fácilmente. Este tipo de provisiones dinámicas donde un sistema se puede escalar en marcha de forma dinámica mediante la adición de más nodos o se puede escalar hacia abajo mediante la eliminación de los nodos se denomina dad como elasticidad. la necesidad para albergar sistemas escalables ha sitated sario el surgimiento de centros de datos a gran escala que comprende miles a cientos de miles de nodos de computación. como los servidores web y servidores de aplicaciones.ha habido una preocupación creciente de que los DBMS y RDBMS no están en la nube de usar. por el contrario. multientidad sincronización muchas veces en el software de aplicación. el enfoque manual de la administración de bases de datos ya no es factibles. consistencia. Este problema se hace especialmente aguda en el contexto de las plataformas de cloud-computing de pago por uso que alojan aplicaciones multitenant. En este artículo. hay dos opciones para escalar la capa de gestión de datos. Debido a las propiedades deseables por encima de las tiendas de valores clave en el contexto de la computación en nube y centros de datos a gran escala. 2 La escalabilidad de base de datos en la nube En esta sección. vamos a argumentar que el éxito de la computación en nube es forma determinante en la fabricación de los DBMS escalable. la responsabilidad de garantizar la atomicidad y consistencia de múltiples entidades de datos recae sobre los desarrolladores de aplicaciones. De hecho. y explorar las formas en que estos sistemas pueden ser enriquecidos para proporcionar la funcionalidad de base de datos de alto nivel. En el contexto de los paradigmas de computación en nube. la duescalabilidad y elasticidad. primero establecer formalmente el concepto de escalabilidad. rendimiento. este problema también ha sido reconocido por los arquitectos superiores de Amazónica [23] y Google [16]. especialmente cuando se trata de proporcionar acceso transaccional a múltiples datos y de información entidades. Este documento resume el estado de la técnica actual. La primera opción es comenzar con los almacenes de claves y valores. que están siendo ampliamente utilizados como los datos de gestión de nivel ción para las aplicaciones web en la nube habilitado. En este modelo. como se reconoce en general que los programas concurrentes son altamente vulnerables a fallos y errores sutiles. nos centraremos en el problema de hacer que la tecnología DBMS nube de usar. Además.en los próximos años. que tienen la escalabilidad casi ilimitada. el proveedor de servicios está interesado en minimizar su costo operacional mediante la consolidación de múltiples inquilinos en el menor número de máquinas como sea posible durante los períodos de baja actividad y la distribución de estos inquilinos en un mayor número de servidores durante el uso máximo. Esto resulta en la duplicación de los mecanismos de sincroni. En cambio. y fiabilidad. dando lugar a sistemas como MegaStore que ofrecen garantías de transacciones en las tiendas de valores clave [3]. La otra opción es comenzar con una convencional . Hay dos principales obstáculos tecnológicos que nos enfrentamos en el despliegue de aplicaciones en infraestructuras de cloud computing: DBMS escalabilidad dad y seguridad DBMS. La realización de proporcionar atomicidad más allá de las entidades individuales es ampliamente discutido en los blogs de desarrolladores [28]. así como identifica las áreas donde se necesita urgentemente progreso de la investigación. En tales casos. está surgiendo evidencia que indica que en muchos escenarios de aplicación esto no es suficiente. elástica y autónomo. A medida que avanzamos a la arena de cloud computing que típicamente comprende centros de datos con miles de servidores. Recientemente. La computación en nube y el concepto de centros de datos a gran escala se convertirá en una tecnología sive perva. este enfoque afecta a la fiabilidad de las aplicaciones negativamente. Aunque se afirma que la atomicidad en una única clave es adecuada en el contexto de las muchas aplicaciones orientados a la Web.personal de ingeniería monitorear continuamente la salud de todo el sistema y tomar acciones para asegurar que la plataforma operativa sigue llevando a cabo de manera eficiente y efectiva. que se suma a las otras propiedades conocidas de las tecnologías de gestión de bases de datos: alto nivel de funcionalidad. hay una creciente necesidad de hacer que la subyacente capa de gestión de datos autonómica o de autogestión en especial cuando se trata de cargar la redistribución. Normalmente hay dos maneras en el que un sistema puede escalar mediante la adición de recursos de hardware. Como los precios de computadoras caen y demanda de rendimiento siguen aumentando.1 Escalabilidad Escalabilidad es una propiedad deseable de un sistema. El otro enfoque de la ampliación de un sistema es mediante la adición de recursos de hardware horizontalmente denominados scale-out. un conjunto de entrada de datos grandes o gran número de nodos participantes en el caso de un sistema distribuido). Para escalar verticalmente (o ampliar) significa añadir recursos a un solo nodo en un sistema. En general. Un ejemplo de aprovechamiento de estos recursos compartidos es mediante el aumento del número de procesos demonio Apache corriendo. 2. ya que proporciona más recursos para el conjunto organizado de los módulos del sistema y de las aplicaciones ing operativos para compartir. La complejidad adicional introducida por el diseño de la escala de salida es la complejidad general de mantener y administrar un gran número de nodos de almacenamiento y computación. Si el algoritmo no puede realizar cuando los recursos aumentan entonces no escala. de forma proporcional a la capacidad añadida. La escala máxima o aceleración de un sistema de este tipo utilizando N CPUs está acotada que establezca la ley de Amdahl [1]: Velocidadarriba = 1 α +1-α N . Un ejemplo podría ser escalado horizontal de un sistema web-servidor a un sistema con tres servidores web. La maqueta de salida también crea una mayor demanda de almacenamiento de datos compartido con el rendimiento de E / S muy alto yo especialmente donde se requiere un procesamiento de grandes cantidades de datos. se dice que un algoritmo para escalar si es adecuadamente eficiente y práctico cuando se aplican a situaciones de gran tamaño (por ejemplo. tales como la adición de un nuevo equipo para una aplicación de software distribuido. En particular. se dice que es un sistema escalable. Dicha escala vertical de los sistemas existentes también les permite utilizar la tecnología de virtualización más efectiva. Este modelo ha sido impulsado por la disponibilidad de interconexiones de alto rendimiento. Cientos de pequeños ordenadores se pueden configurar en un clúster para obtener potencia de cálculo agregado que a menudo supera a la de los superordenadores solo tradicional procesador RISC basados. Para escalar horizontalmente (u horizontal) significa añadir más nodos a un sistema.α es paralelizable y por lo tanto pueden beneficiarse de múltiples procesadores. El primer enfoque es cuando el sistema escalas vertical y se conoce como aumento de escala. el paradigma de escalabilidad horizontal ha servido como el paradigma de diseño fundamental para los centros de datos de hoy en gran escala. Tenga en cuenta que la escalabilidad de un sistema está estrechamente relacionado con el algoritmo de cálculo o subyacente. lo que indica su capacidad de manejar bien el creciente volumen de trabajo de una manera graciosa o su capacidad para mejorar el rendimiento cuando se agregan recursos adicionales (típicamente hardware). sistemas de "productos básicos" de bajo coste que se pueden usar para la construcción de infraestructuras computacionales compartidos para el despliegue de aplicaciones de alto rendimiento. Del mismo modo. Ahora exploramos estas dos opciones en detalle. Un sistema cuyo rendimiento mejora después de añadir hardware. dado un algoritmo si hay una fracción α que es inherentemente secuencial entonces que significa que el resto 1 . .Arquitectura DBMS y el apalancamiento de las tiendas arquitectónico características de diseño clave-valor para hacer el DBMS altamente escalable. que suele implicar la adición de procesadores o de memoria a un solo ordenador. tales como búsqueda en la web y otros servicios basados en la web. ya sea que tenga que recurrir a las bases de datos tradicionales. como en dos fases o colas persistentes puede ser necesario. mientras que con 8 procesadores que está a sólo 2.Por ejemplo si sólo el 70% de la computación es paralelizables entonces el aumento de velocidad con 4 CPU es 2. Sin embargo. a un nivel de consistencia débil o flojo. Esta necesidad ha sido reconocida por empresas como Google. de Amazon Dynamo [17]. si el grupo de entidades se distribuye a través de múltiples nodos. tiene que estar en el grupo para el resto de su . pero la propiedad común a todos los sistemas es el valor-clave de abstracción en que los datos se ve como pares clavevalor y el acceso atómica sólo se admite en la granularidad de teclas individuales. y la incursión en el espacio de múltiples accesos clave [2].581. la pregunta que surge es cómo apoyar atomicidad multi-clave en las tiendas de valores clave como Bigtable de Google [7]. y proporciona la base para la escalabilidad y la disponibilidad de estos sistemas. Por otro lado. sin embargo. disponibilidad y garantías de consistencia.0 aplicaciones (tales como los basados en la colaboración) ir más allá de la semántica de acceso a una sola tecla. los nuevos requisitos de la aplicación están surgiendo que requieren múltiples entidades (o equivalencia teclas lently) para acceder atómicamente. Con el fin de hacer frente a este desafío. Esta única semántica clave de acceso atómica permite naturalmente eficiencia partición de datos horizontal ciente. Ante esta necesidad. y estas aplicaciones. Megastore ofrece un mayor nivel de rendimiento cuando el grupo de entidad es co-localizado en un solo nodo. Añadiendo ciegamente los recursos de hardware pueden no producir necesariamente la escalabilidad deseada en el sistema. aunque las tiendas de clave y valor proporcionan escalabilidad casi infinito en que cada entidad puede (potencialmente) ser manejado por en el nodo independiente. y PNUTS de Yahoo [9]. Las diversas tiendas de valores clave difieren en términos de modelo de datos. A pesar de que la mayoría de las aplicaciones web actuales tienen patrones individuales claves de acceso [17]. El consolidado mencionado en la ampliación claramente establece la necesidad de diseñar algoritmos y mecanismos que están inherentemente escalable. ya que las teclas no se pueden actualizar en su lugar. muchas aplicaciones actuales. Datos escalables actuales sistemas de gestión de lo que no pueden atender directamente a las necesidades de estas aplicaciones modernas.arrancó permite entidades para ser distribuidos de manera arbitraria a través de múltiples nodos. Nos referimos a este enfoque como una arquitectura de fusión de datos de atomicidad multi-clave al tiempo que garantiza la escalabilidad. MegaStore de Google toma un paso más allá de los patrones de acceso clave individuales. Google ha diseñado un sistema llamado MegaS. así como en el contexto de los juegos multi-jugador. el rendimiento global puede sufrir ya que los mecanismos de sincronización más complejas. una vez que se crea una clave como parte de un grupo. 2. Los diseñadores también postulan que los accesos a través de múltiples grupos de entidades también son compatibles. favoreciendo el acceso transaccional para los grupos de entidades. Aunque Megas. Algunas de estas aplicaciones se encuentran en el dominio del trabajo cooperativo. 32] y en dos fases [21] como los bloques de construcción para apoyar transacciones ACID en grupos de entidades definidas estáticamente . La idea básica de MegaStore es permitir a los usuarios agrupar varias entidades en una sola colección y luego utiliza escritura anticipada registro [22. y un gran número de Web 2.105.arrancó [3] que se basa en Bigtable como un sistema subyacente y crea la noción de grupos de entidades en la parte superior de la misma.2 Fusión de datos: Multi-clave Atomicity en las tiendas de valores-clave Como se ha indicado anteriormente en la sección anterior. que han ampliado su cartera de aplicaciones de Web-búsqueda a aplicaciones más elaboradas tales como documentos de Google y otros. en ese caso. o depender de varias soluciones ad-hoc. El protocolo Agrupación Clave utiliza la abstracción Grupo Clave para transferir la propiedad. Conceptualmente. Para evitar este inconveniente. el apoyo a la semántica de aplicación diferentes. y del líder de los seguidores durante el borrado grupo. tolerancia a fallos y alta disponibilidad. Este enfoque de fusión de datos proporciona el bloque de construcción para el diseño de sistemas de datos escalables con garantía de consistencia en los gránulos de datos de diferentes tamaños. grupos con miles a cientos de miles de llaves se puede apoyar de manera eficiente. pero desde una perspectiva de las aplicaciones. en el caso de una solicitud de casino en línea donde los diferentes usuarios corresponden a diferentes pares de valores de teclado. por otra parte. se necesitan múltiples garantías de acceso clave sólo durante el curso de un juego. Intuitivamente. el objetivo del protocolo Agrupación Clave propuesta es transferir la propiedad de clave de forma segura de los seguidores del líder durante la formación del grupo. que no se solapan de claves utilizando un almacén de claves-valor como un sustrato subyacente. Por ejemplo. Además de ser el único que las nociones de atomicidad y consistencia se extienden desde una única clave para un grupo de teclas. Nuestro supuesto es que el número de teclas en un grupo es suficiente para ser propiedad de un solo nodo pequeña. es decir. la semántica de las operaciones en el líder no es diferente de la de los seguidores.mite el acceso de múltiples escalable clave es la abstracción Grupo Clave que define un gránulo de acceso bajo demanda transaccional.vida. no hay ningún elemento de datos es sin dueño indefinidamente. requiere que. son en muchos casos insuficiente y restrictivo. G-Store hereda el modelo de datos. la fase de creación del grupo de Agrupación Clave transferencias protocolo propiedad de teclas seguidor al nodo que alberga actualmente el líder clave. Protocolo La Agrupación Clave propueden tolerar mensaje y fallos en los nodos. pero viven el tiempo suficiente para amortizar el coste de la formación de grupos. solicitudes de creación de grupo concurrente. así como detectar grupo superposición crear solicitudes [14]. Un grupo clave consiste en una clave de líder y un juego de llaves de seguidor. Teniendo en cuenta el tamaño y la capacidad de la actual hardware de consumo. Además. . además de la exigencia de que las llaves sean contiguos en orden de clasificación. Una vez que el juego termina. Liveness. el exclusivo acceso de lectura / escritura a las claves-para todas las claves en un grupo de un solo nodo que luego ejecuta de manera eficiente las operaciones en el Grupo Clave. de manera que las transacciones ex ejecutora en el grupo pueden ejecutarse localmente. Los dos diseños alternativos han resultado en los sistemas con diferentes características y comportamiento. Una vez que la aplicación especifica el Grupo Clave. y por lo tanto inherente iting su escalabilidad. las teclas de seguidores están bloqueadas durante la vida del grupo. Seguridad o corrección requiere que nunca debería haber un caso en más de un nodo reclama la propiedad de un elemento. diferentes usuarios pueden moverse a diferentes instancias del juego lo que requiere garantías de grupos dinámicos de teclas de una característica no la apoya MegaStore. así como mensajes nuevos pedidos. el sistema puede escalar de salida de decenas a cientos de nodos de las materias primas para soportar millones de Grupos Principales. un almacén de datos escalable que proporciona transaccionales múltiples garantías de acceso clave más dinámicos grupos. El líder es parte de la identidad del grupo. hemos diseñado G-Store [14]. La innovación básica que per. Esta naturaleza estática de los grupos de entidades. Este diseño es adecuado para aplicaciones que requieren acceso transaccional a grupos de teclas que son de naturaleza transitoria. así como el conjunto de las operaciones de la tienda subyacente de valor-clave. en ausencia de fallos repetidos. un esquema tiene exactamente una tabla principal cuya principal actos clave como la clave de particionamiento. La tabla principal forma la raíz del árbol. hay un grupo de filas relacionadas en las tablas secundarias. Sin embargo. un esquema puede tener varias tablas secundarias y mundiales. 2. un enfoque conocido como partición nivel de esquema. Por ello. Todas las filas en el mismo grupo de filas son . donde múltiples gránulos pequeños de datos se combinaron para proporcionar garantías de transacciones estrictas en gránulos más grandes de datos a escala. muchos sistemas modernos dividen el esquema de tal manera que la necesidad de transacciones distribuidas se reduce al mínimo. Dividir el esquema de base de datos. Esta estructura implica que corresponde a cada fila de la tabla principal. Un ejemplo popular de particionamiento surge cuando el esquema es un "esquema de árbol". Haciendo referencia a la Figura 1 (a). una estructura llamada un grupo de filas [4]. Desde las ineficiencias que resultan de transacciones distribuidas son bien conocidos (ver [11] para algunos números de rendimiento). transacciones sólo acceden a un pequeño número de filas relacionadas que pueden ser potencialmente propagan a través de una serie de mesas. Este enfoque de la partición de la base de datos y la ampliación con el particionamiento es popularmente utilizado para escalar aplicaciones web. una encuesta de aplicaciones reales dentro de una empresa comercial muestra que un gran número de aplicaciones. Este esquema es compatible con tres tipos de tablas: Tablas Primarias. Nos re. Cada tabla secundaria en un esquema de base de datos tendrá la llave de la tabla principal como una clave externa. Fig. el kp clave de la tabla principal aparece como una clave externa en cada una de las tablas secundarias. El fundamento de particionamiento nivel de esquema es que en un gran número de esquemas de bases de datos y aplicaciones. 1: Esquema de particionamiento de base de datos de nivel. permite apoyar una rica funcionalidad incluso cuando la limitación acciones más transparentes a una sola partición. en lugar de dividir tablas individuales. Las transacciones que acceden a una única partición se pueden ejecutar de manera eficiente sin ningún tipo de dependencia y la sincronización entre los servidores de base de datos al servicio de las particiones.a este enfoque como datos fisión. Secundarias Tablas y tablas mundiales.unos servi. por lo que permiten una alta escalabilidad y disponibilidad.(a) Árbol Esquema. ya sea tiene un patrón de esquema tal inherente o se puede adaptar fácilmente a él [4] . otra aproximación a la escalabilidad es dividir una unidad de base de datos de gran tamaño en fragmentos o particiones relativamente independientes y proporcionar transaccional garantiza sólo en estos fragmentos.3 Datos Fisión: particionamiento de base de datos de soporte en DBMS Contrario al enfoque de fusión de datos. la elección de una buena técnica de partición es fundamental apoyar una funcionalidad flexible al tiempo que limita las operaciones a una sola partición. Figura 1 (a) proporciona una ilustración de un tipo de esquema tal. A pesar de que tal esquema no abarca todo el espectro de las aplicaciones OLTP. Este patrón se puede utilizar para agrupar los datos relacionados juntos en la misma partición. (B) TPC-C como un esquema de árbol. En particular. Por otro lado. por otro lado. así como de carga. Un esquema tal forma la base del diseño de un número de sistemas tales como MS SQL Azure [4]. una operación en una transacción sólo puede leer una tabla global. estas tablas se replican en todos los nodos. De hecho. ElasTraS [12]. Se extiende técnicas desarrolladas para tiendas de valor-clave para escalar a un gran número de particiones distribuidas en decenas a cientos de servidores. escalable y altamente disponible que el sistema a escala de salida. tanto en términos de datos. En contraste con estos dos tipos de tablas. Se han hecho esfuerzos últi. como GFS [20] o HDFS [25]. Para un DBMS desplegado en una nube de pago por uso . ElasTraS. Desde tablas globales no se actualizan con frecuencia. que luego se pueden escalar hacia fuera en un grupo de nodos. bien conocido técnicas de migración VM [6.garantizado ser colocalizarse y una transacción sólo puede filas de acceso en un grupo de filas en particular. 3 Elasticidad de base de datos en la nube Uno de los principales factores para el éxito de la nube como una Infraestructura de TI es su pago por uso modelo de precios y elasticidad. El intercambio de recursos eficaces y la consolidación de múltiples inquilinos en un único servidor permite que el sistema para hacer frente de manera eficiente con los inquilinos con pequeñas necesidades de datos y de recursos. ElasTraS es la culminación de dos grandes filosofías de diseño: sistemas tradicionales de bases de datos relacionales (RDBMS) sistemas que permitan una ejecución eficiente de las cargas de trabajo OLTP y proporcionan garantías ACID para pequeñas bases de datos y las tiendas de valor-clave que están elástica. Esta partición nivel de esquema de grandes bases de datos se divide en gránulos más pequeños. La característica deseable del diseño ElasTraS es que soporta la elasticidad de los datos de una manera mucho más integrada. 8. Una partición de base de datos es una colección de tales grupos de filas. El diseño ElasTraS por otra parte utiliza el modelo de almacenamiento compartida basada en sistemas de archivos de agregación de sólo distribuido.ción de la nube se basan en el modelo de almacenamiento de nada compartido donde cada instancia DBMS en un nodo es independiente y una capa de integración se proporciona en la parte superior para encaminar consultas y transacciones a un servidor de base de datos adecuada. 13]: utiliza este concepto de la fisión de datos a escala de salida los sistemas de bases de datos. mientras que la base de datos avanzada particionamiento y la escala de salida le permite servir inquilinos que crecen grandes. 27] puede ser fácilmente adoptada en el caso de ElasTraS [15]. Los diseños MS SQL Azure y Rela. ambos diseños MS SQL Azure y relacional de la nube necesitan para ser ampliado mediante mecanismos de migración de base de datos para apoyar la elasticidad donde la migración de particiones de base consiste en mover los dos datos de estado de base de datos y residentes en disco residentes en memoria. cada partición actúa como una base de datos independiente. Elastómeros Trás Nuestro llamado sistema prototipo [12. Figura 1 (b) muestra una representación del esquema TPC-C [29] como un esquema de árbol. y la nube relacional [10]. puede soportar la elasticidad de base de datos para la reubicación de las particiones de base de datos simplemente migrar el estado de la memoria de la base de datos que es considerablemente más simple. Además de acceder a un solo grupo de filas. El enfoque de partición descrito aquí puede ser considerado como partición estática. Esta estructura de esquema también permite la división dinámica eficiente y fusión de particiones. ElasTraS opera en la granularidad de estos gránulos de datos llamados particiones. tablas globales son tablas de consulta que en su mayoría son de sólo lectura. ElasTraS utiliza tecnología desarrollada para las bases de datos relacionales [22] para ejecutar transacciones de manera eficiente en estas particiones.mos para lograr partición de base de datos en tiempo de ejecución mediante el análisis de los patrones de acceso de datos de consultas de los usuarios y transacciones sobre la marcha [11]. mientras que el sistema está en funcionamiento. La escalabilidad es una propiedad estática del sistema que especifica su comportamiento en una configuración estática.pendiente de la capa de almacenamiento de la lógica DBMS. todo en un sistema vivo sin interrupción del servicio. Un sistema puede tener cualquier combinación de estas dos propiedades. un diseño de sistema es elástica si se puede escalar desde 10 servidores a 20 servidores (o viceversa) a la carta. Permite la consolidación del sistema de consumir menos recursos y por lo tanto minimizar el costo de operación durante los periodos de baja carga. una nada compartida arquitectura multi-tenant utiliza conectada localmente almacenamiento . nos centramos nuestros esfuerzos en el desarrollo de la migración en vivo para las dos arquitecturas más comunes de base de datos en la nube común: disco compartido y no se comparte nada. Si bien es elástico. infraestructura. A pesar de que la infraestructura se aprovisiona estáticamente. es decir efecto insignificante en el rendimiento y escaso servicio in interrupción el inquilino va a migrar. sin embargo. un objetivo añadido es optimizar el costo de operación del sistema. Bigtable [7]. un diseño del sistema puede escalar a cientos o incluso miles de nodos. La elasticidad es también deseable en este tipo de escenarios donde se permite la realización de la eficiencia energética. la capacidad para hacer frente a las variaciones de carga mediante la adición de más recursos durante la alta carga o consolidar los inquilinos a menos nodos cuando la carga disminuye. Por otro lado. Por otro lado. Esto. la elasticidad es fundamental para minimizar los costos de operación al tiempo que garantiza un buen rendimiento durante cargas elevadas. En nuestro contexto de un sistema de base de datos. Por ejemplo. ahorros significativos pueden ser alcanzados por la consolidación del sistema de una manera que algunos servidores pueden ser alimentados por la reducción del uso de energía y los costes de refrigeración. un interruptor o una unidad de fuente de alimentación) pueden dar lugar a una interrupción del servicio entero resultante de un solo fallo. ya que apagar los servidores al azar no reduce necesariamente el uso de energía. es un tema de investigación abierta en su propio mérito. es de importancia crítica para estos sistemas. las infraestructuras empresariales a menudo se aprovisionan estáticamente. la migración en vivo debe tener un bajo impacto. tales como la infraestructura como servicio (IaaS) la extracción. Por otra parte. la tolerancia a fallos. la migración de las partes de un sistema mientras el sistema está en funcionamiento es importante para lograr una elasticidad-operación llamada migración de base de datos en vivo bajo demanda. Dado que la migración es una primitiva necesaria para lograr elasticidad. Arquitecturas de discos compartidos se utilizan por su capacidad de replicación abstracto. es decir. así como otros inquilinos co-localizados en el origen y destino de la migración. la crianza de los servidores apagados es más caro. HBase [24] y ElasTraS [12. Para un sistema desplegado en un servicio en la nube de pago por uso. La elasticidad. También hay que considerar el impacto de apagar la disponibilidad. la coherencia. Por lo tanto. Por ejemplo. tolerancia a fallos. por lo que la pena por una operación de apagado miss-predicho es mayor. Por ejemplo. y la escala inde. el sistema también debe garantizar los acuerdos de nivel de servicio de los inquilinos (SLA). la elasticidad es la propiedad dinámica que permite la escala del sistema para aumentar bajo demanda.1 0 Agrawal et al. mientras permitiendo ción a escalar dinámicamente su tamaño que la carga disminuye. Elasticidad es una propiedad deseable e importante de sistemas de gran escala. Por otra parte. existe una sutil diferencia entre la elasticidad y escalabilidad cuando se utiliza para expresar el comportamiento de un sistema. para ser utilizado con eficacia para la elasticidad. Es necesaria una planificación cuidadosa para seleccionar los servidores que apagar tal que bastidores enteros y callejones en un centro de datos son impulsados hacia abajo para que un importante ahorro en refrigeración se puede lograr. 13] son ejemplos de bases de datos que utilizan una arquitectura de disco compartido. la consolidación del sistema a un conjunto de servidores de todo dentro de un único punto de fallo (por ejemplo. A pesar de que la elasticidad se asocia a menudo con la escala del sistema. Optimista (OCC) [26] planificador. Para la mayoría de los motores de bases de datos comunes [22]. Para facilitar la presentación.cionar el destino de la migración. iterativo Copia centra en la transferencia de la estado de la memoria principal de la partición. que podría o no tener réplica del inquilino. y el estado de ejecución de la transacción (estado de transacción). proporcionando así una mayor flexibilidad en selec. En la arquitectura nada común. para un control de divisas Con. y minimizar la ventana indisponibilidad del inquilino. garantías secuencialidad. se utiliza la partición término para representar un gránulo autónomo de la base de datos que se van a migrar de la elasticidad. incluyendo los archivos de almacenamiento físico. hay un sistema de tiempo de inactividad. Zephyr minimiza la interrupción del servicio para el inquilino va a migrar mediante la introducción de una fase sincronizada que permite tanto el origen como de destino para ejecutar simultáneamente transacciones para el inquilino. Sin embargo. En la arquitectura DBMS almacenamiento compartido. permitiendo al mismo tiempo el destino para ejecutar nuevas transacciones. Zephyr no se basa en la replicación en la capa de base de datos. minimiza datos transferidos entre los nodos. la imagen persistente de la base de datos también se debe migrar. de modo que la partición comienza "caliente" en el nodo de destino resulta en un impacto mínimo sobre las transacciones en el destino. Para minimizar la interrupción del servicio y para asegurar una baja sobrecarga de la migración. Zephyr permite al nodo de origen para completar la ejecución de las operaciones activas. El estado de la memoria principal de una partición está conformada por el estado en caché de base de datos (estado DB).para almacenar la imagen de base de datos persistente. Copia iterativo garantiza la secuencialidad de transacciones activas durante la migración y garantiza la corrección durante las fallas. Un análisis detallado de esta técnica. los datos persistentes de una partición se almacenan en el NAS y no necesita la migración. una técnica para la migración en vivo en un nada común transaccional arquitectura de base de datos [19]. Zephyr garantiza que no habrá interrupción del servicio por otros inquilinos. permitiendo así que sea utilizada en una variedad de implementaciones de DBMS. lo que permite transacciones activas durante la migración a continuar la ejecución al destino. y se asegura el nivel más fuerte de aislamiento de la transacción. Hemos diseñado Zephyr. el estado de la transacción consiste en la tabla de bloqueos. En una arquitectura DBMS almacenamiento compartido la imagen persistente de la base de datos se almacena en un almacenamiento conectado a red (NAS). garantiza una migración segura en presencia de fallos. Usando una combinación de tracción a la carta y empuje asíncrono de datos. y una evaluación detallada puede encontrarse en [15]. Sincronización de peso ligero entre el origen y el destino. Hemos diseñado Copiar iterativo para la migración de base de datos activa en una arquitectura de almacenamiento compartido. este estado consiste en la lectura y escritura de conjuntos de transacciones activas y un subconjunto de las transacciones comprometidas. La migración en vivo para una nada compartida arquitectura de requiere que todos los componentes de base de datos se migran entre nodos. . Como resultado. una considerable mejora del rendimiento es posible en presencia de la replicación cuando un inquilino se migra a una de las réplicas. el Estado DB incluye las páginas de base de datos en caché o alguna variante de esto. que es típicamente mucho más grande que la memoria caché de base de datos migrada en la arquitectura de disco compartido. Utiliza índices basados árbol estándar y bloquear el control de concurrencia basado. sólo durante el corto modo de funcionamiento sincronizado. optimizaciones. Para un bloqueo de dos fases (2PL) programador basado en [22]. se necesita un enfoque diferente de iterativo Copiar. mientras viating observado la necesidad de dos fases [21]. para minimizar el costo de operación para maximizar las ganancias. .cursos de los diferentes inquilinos de aplicación para permitir el escalado elástico al tiempo que garantiza un buen rendimiento inquilino y asegurar que se cumplan los inquilinos de nivel de servicio los acuerdos (SLA).30]. las responsabilidades de este controlador autonómica se incluyen el control de la conducta y el rendimiento del sistema. Este modelo supone que una vez que el comportamiento de un inquilino se modela y una colocación inquilino determinado. El componente dinámico complementa este modelo estático mediante la detección de un cambio dinámico en el comportamiento de la carga y el uso de recursos. 31]. el sistema continuará a comportarse de la manera en que se modeló la carga de trabajo. un controlador de sistema inteligente también debe considerar varios aspectos adicionales. Modelado del comportamiento de un ajuste del sistema de base de datos y el rendimiento ha sido un área activa de investigación en el último par de décadas. Una vez más. es decir. El objetivo de este algoritmo colocación inquilino es terio mizar la utilización total de los recursos y. Un controlador de sistema autónomo e inteligente es esencial para gestionar adecuadamente este tipo de sistemas grandes. la selección de los cambios mínimos en la colocación inquilino necesaria para contrarrestar el comportamiento dinámico. y el uso de la técnicas de migración de base de datos en vivo para volver a equilibrar los inquilinos. cada inquilino paga por el servicio prestado y diferentes inquilinos en el sistema puede tener objetivos contrapuestos.mentarios de recursos. reducir al mínimo los costos de operación al tiempo que garantiza el cumplimiento de los SLAs inquilinos. En el contexto de los sistemas de bases de datos. y por lo tanto se llama el componente estático. Para activar la autonomía en una base de datos en nube. también es importante para predecir el costo de migración de tal manera que una migración para reducir al mínimo el costo de operación no viola SLA de un inquilino. el aprovisionamiento y la colocación en grandes sistemas distribuidos [5. modelando el comportamiento del sistema en su conjunto para determinar el momento oportuno para que el equilibrio de carga elástica. Un gran cuerpo de trabajo se centra en el ajuste de los parámetros apropiados para optimizar el rendimiento de la base de datos [18. el proveedor de servicios debe compartir recursos entre los inquilinos. se necesita una autonomía considerable en la administración de tales sistemas.4 Autonomía de base de datos en la nube La gestión de grandes sistemas plantea retos importantes en la supervisión. específicamente en el caso en que el sistema de base de datos se implementa en una infraestructura cloud de pago por uso mientras servía aplicación múltiple de diez casos de hormigas. principalmente en el contexto de un único servidor de base de datos. En tal sistema multiusuario. utilizamos modelos de aprendizaje de máquina para predecir el costo de migración de los inquilinos y las cuentas modelo re-colocación para este costo cuando se determina que el inquilino de migrar. para reducir el costo de operación. Un controlador para un sistema de este tipo debe ser capaz de modelar las características dinámicas y los requisitos de re. Además de modelar el comportamiento inquilino. la escala elástica y balanceo de carga basado en patrones de uso dinámico. Además. por tanto. Nuestro trabajo actual utiliza una combinación de máquina de aprendizaje ing técnicas para clasificar el comportamiento inquilino seguido de algoritmos de colocación de empresa para determinar inquilino co-ubicación y consolidación óptima. siempre que sea posible. un sistema de base de datos en nube multiusuario. la gestión y el funcionamiento del sistema. el comportamiento de modelos para predecir los picos de carga de trabajo y tomar medidas proactivas para manejar estos picos. El componente estático es responsable de modelar el comportamiento de los inquilinos y su uso de los recursos para determinar la colocación inquilino para colocalizar a los inquilinos con los requisitos comple. cuándo migrar y dónde emigrar [15]. Un controlador autónomo consta de dos componentes lógicos: el componente estática y la componente dinámica. Otra línea de trabajo se ha centrado en la predicción de los recursos. Por otra parte. S .. R. Curino. J. Referencias 1. T. Balakrishnan. HA. Rep. H. L. I.. Agrawal. P. Ramakrishnan. P. Fox. Srivastava... 37 (1). Bernstein.F. A. Malviya. En: IESO. D. D.: La migración de base de datos en vivo para la elasticidad en una base de datos multiusuario para plataformas en la nube. pp. Dani. F....: PNUTS: acogió Yahoo 's de datos que sirve de plataforma!. D. En: INDE. J.. VLDB Endow. Agrawal. Cseri. G. Warfield. P.. 169179 (2007) 7. J . Agrawal. Lloyd. Limpach. A. Baker. S.. H . R. S. Kotsovinos. y el control autónomo para reducir al mínimo el costo de operación.Das. 205-218 (2006) 8.. A. El Abbadi.. En: ACM SOCC. Kalhan. T . V. Agarwal. pp. 49-52 (2008) 3. Rep. C. Madden.Curino.. Proc.: Megastore: Proporcionar Escalable.Das. Feldmann. N.. 1 (2). G. Talius.. En: VEE. UCSB (2010) 13. A. Nishimura. Yushprakh.. SIGMOD Rec. S. R . Jacobsen.. Alonso. DA. como se trata de operaciones a gran escala. Dovich Zel-. 483. Amdahl. G .. K. S. pp. Li. Jones. Jones. El Abbadi. En: AFIPS Conferencia.5 Comentarios finales Sistemas de bases de datos desplegados en una infraestructura de cloud computing se enfrentan a muchos nuevos retos. CS. 2010-09.. A. N. Kossmann. pp. A . Bond. JG. En: USENIX HotCloud (2009) 14. A.. presentamos una visión general de algunas de nuestras actividades de investigación en curso para hacer frente a los desafíos mencionados en el diseño de una capa de gestión de datos escalable en la nube.. Markl. C. 223-234 (2011) 4.. Ellis. Madden. 2010-04.. Ghemawat. Bradford. Mano. Amer-Yahia. Hansen... Y.. Yerneni..: En vivo en toda la zona de migración de máquinas virtuales que incluyen estado persistente local. C. G .: Las bases de datos y el panel de la Web 2.: Hilighter: construir automáticamente firmas sólidas de comportamiento de rendimiento para sistemas de pequeña y gran escala.. Silberstein. Estos retos son.A. 1277-1288 (2008) 10. A . Tecnología. En: CIDR. N ... 163-174 (2010) 15. JM. J. Burrows. J. Hsieh... Larson. WC.: Relacional Nube: Un servicio de base de datos para la nube. Bohannon.. D. U. 273-286 (2005) 9.. Doan.. Fikes..Das.Das. la elasticidad de peso ligero. Chandra. Furman.0 en VLDB 2007..: La adaptación de Microsoft SQL Server para Cloud Computing.. S.. El Abbadi. V . Wallach. Wu. p. Halevy. En: SysML (2008) 6. El Abbadi. Puz.. Pratt. En este artículo.. M. Bod'ık. S. manera. E. RE: Bigtable: Un sistema de almacenamiento distribuido de datos estructurados. S.. Chang. S. R. C.: G-Store: Un almacén de datos escalable para Transaccional Multi Tecla de acceso en la Nube. J..... A . Novik. Goldszmidt. En: ICDE (2011) 5... E. B.. A . Corbett. A .: ElasTraS: Un almacén de datos transaccional elástico en la Nube. C. Schio¨berg.: La migración en vivo de máquinas virtuales.... Dean. D.. Tecnología. Cooper. D. DB. León. A.485 (1967) 2. En: CIDR. Weikum. Gruber... M. 48-57 (2010) 12. Fraser. almacenamiento de alta disponibilidad para los servicios interactivos. S. CS.... Kakivaya. E. PVLDB 3 (1). Zhang..: Charla en la Cumbre Facultad Google (2010) . A .. N..Dean.: La validez del enfoque único procesador para el logro de las capacidades de computación a gran escala. 235240 (2011) 11. Weaver. julio. Agrawal. pp. A. escalable y Auto Gestión Transaccional para la nube...: Cisma: un enfoque impulsado por la carga de trabajo para la replicación de bases de datos y la partición. N. Lomet.: ElasTraS: Una base de datos elástica. S. Khorlin. E. pp. R. además de hacer los sistemas tolerantes a errores y alta disponibilidad. Y. UCSB (2010) 16. EPC.. Popa. Clark. I.. Agrawal. pp. Moenkeberg. J. Pilchin.. Reino Unido (1978) 22...Elmore. disponibilidad en sistemas distribuidos. 205-220 (2007) 18. PJ: colocación de aplicaciones en un clúster de servidores...apache. Kakulapati. (2001) .: Puesta a punto con ituned.Gray.: La migración en vivo de máquinas virtuales basadas en rastro de todo el sistema y la reproducción. Syst Database. H. ACM Trans. H.ly/4J0Zm (2009) 29.. W .org/hbase/ 25. algoritmos y la práctica del control de concurrencia y recuperación. Robinson. A. Hastorun. J . et al . 2. encontrado. A . G. Jampani.apache.Kung. Weikum. Thummala... A.:: del optimismo a ultranza a la ingeniería viable. pp. Das. los parámetros de configuración de base de datos S . Int. 18 (5).: Zephyr: Migración de base de datos en vivo para Elasticidad Ligera en Plataformas Multitenant nube.Gray. AL. M.. Proc. Lakshman. 1023-1041 (2007) 31.. En: SOSP. http://hadoop. Londres. valor clave de Amazon tienda. G. El Abbadi. D .. Morgan Kaufmann Publishers Inc. ST: El sistema de archivos de Google. Comput. bajo presentación para su revisión 20.. VLDB Endow. P. S. un curso avanzado. G..Weikum.: Cuando las bases de datos se encuentran: Consistencia vs. 101-110 (2009) 28. B.. 6 (2).10. HT. HDFS: Un sistema de archivos distribuido que proporciona un alto rendimiento de acceso a datos de aplicación (2010). JT: En métodos optimistas para el control de concurrencia.. Hasse. A... V.: transaccionales información: teoría. En: HPDC.1) (2009) 30. En: SOSP.: Me encanta la consistencia eventual pero . D. Sci. A . C. Leung.. S. Rosenberg. pp. 393-481. http://bit. (1992) 23. pp.ly/hamiltoneventual (Abril de 2010) 24. En: VLDB. J. 20-31 (2002) 32.Duan.Decandia.HBase: Bigtable-likestructuredstorageforHadoopHDFS (2010).. Zabback. http://bit.. sistemas G . Morgan Kaufmann Publishers Inc. tecnología de base de datos auto-tuning y servicios de información P . Vossen.: Dynamo: alta disponibilidad.Liu. 213-226 (1981) 27. Shenoy. Gobioff. G. S.: Notas sobre los sistemas operativos de base de datos. http://hadoop. Babu.El Transaction Processing Performance Council: TPC-C de referencia (Versión 5.org/hdfs/ 26. 29-43 (2003) 21.: Procesamiento de Transacciones: Conceptos y Técnicas. Vosshall. 1246-1257 (agosto de 2009) 19.. En: Sistemas operativos.17.. Sivasubramanian. J . pp. Springer-Verlag. Vogels.. Hamilton..Urgaonkar. D.Obasanjo. S. A. Reuter.Ghemawat.