Scalability, Elasticity, and Autonomy for a Database in the Cloud

La escalabilidad de base de datos, la elasticidad y la autonoma en la Nube[Resumen Extendido]

Divyakant Agrawal, Amr El Abbadi, Sudipto Das, y Aarn J. Elmore

Departamento de Ciencias de la Computacin de la Universidad de California en Santa Brbara Santa Brbara, CA 93106, EE.UU.{Agrawal, amr, Sudipto, aelmore} @ cs.ucsb.edu http://www.cs.ucsb.edu/~dsl

Resumen. La computacin en nube se ha convertido en un paradigma de gran xito para el despliegue de aplicaciones web. Escalabilidad, la elasticidad, la fijacin de precios de pago por uso, y las economas de escala de las operaciones a gran escala son las principales razones para la adopcin exitosa y generalizada de infraestructuras de nube. Desde la mayora de aplicaciones en la nube son impulsados de datos, sistemas de gestin de bases de datos (DBMS) poderes Ering estas aplicaciones forman un componente crtico en la pila de software en la nube. En este artculo, presentamos una visin general de nuestro trabajo en inculcar estos anteriormente se ha mencionado "caractersticas de las nubes" en un sistema de base de datos diseada para soportar una variedad de aplica- ciones desplegadas en la nube: el diseo de gestin de base de datos escalable arquitecturas de uso de los conceptos de la fisin y la fusin de datos de datos, lo que permite la elasticidad ligera usando bajo costo de migracin de base de datos en vivo, y el diseo de controladores inteligentes y autonmicas para la gestin del sistema sin intervencin humana.

Palabras clave: La computacin en nube, la escalabilidad, elasticidad, sistemas autonmicos.

1 Introduccin

La proliferacin de la tecnologa en las ltimas dos dcadas ha creado una dicotoma interesante para los usuarios. Hay muy poco desacuerdo en que la vida de un individuo es notablemente enriquecido como resultado de un fcil acceso a la informacin y servicios que utilizan un amplio espectro de plataformas informticas, tales como estaciones de trabajo personales, ordenadores porttiles y dispositivos porttiles como telfonos inteligentes, PDAs, y tabletas (por ejemplo, los iPads de Apple). Los facilitadores tecnolgicos son de hecho los avances en la creacin de redes y los paradigmas de servicios basados en la Web que permiten a los usuarios obtener informacin y servicios de datos ricos en cualquier momento borrando la distancia geogrfica o fsica entre el usuario final y el servicio. Como proveedores de la red continan mejorando la capacidad de sus infraestructuras inalmbricas y de banda ancha, este paradigma seguir alimentando la invencin 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 tecnologas 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 Amrica Universidad.

los usuarios, tambin han dado subir a algunos desafos y complejidades, tanto desde la perspectiva del usuario, as como del proveedor de servicios o la perspectiva del sistema. Desde el punto de vista-del usuario, los usuarios tienen que navegar a travs de una red de cmputo mltiple y plataformas de almace- namiento para hacer su trabajo. Un reto para el usuario final importante es hacer un seguimiento de todas las aplicaciones y servicios de informacin en sus / sus mltiples dispositivos y mantenerlos sincronizados. Una solucin natural para superar esta complejidad y simplificar la vida computacionalmente y ricos en datos de un usuario final es impulsar la gestin y adminis- tracin de la mayora de las aplicaciones y servicios al ncleo de la red. La justificacin es que a medida que las tecnologas de redes maduran, desde la perspectiva de un usuario que accede a una aplicacin en su / su dispositivo personal ser indistinguible de acceso a la aplicacin a travs del cable de banda ancha o red inalmbrica. En resumen, la tendencia actual es la tecnologa para alojar aplicaciones de usuario, servicios y datos en el ncleo de la red que se denomina metafricamente como la nube.La transformacin anterior que se ha traducido en las aplicaciones y servicios para el usuario estn migrando de los dispositivos de los usuarios a la nube ha dado lugar a iCal y de investigacin desafos nolgicos sin precedentes. Anteriormente, una aplicacin o servicio de interrupcin fue tpicamente limita a un pequeo nmero de usuarios. Ahora, cualquier perturbacin tiene consecuencias globales Making el servicio no est disponible para una comunidad de usuarios de todo. En particular, el reto ahoraes el desarrollo de plataformas de aplicaciones centradas en servidor que estn disponibles para un nmero limi- prcticamente unlim- de usuarios 24 7 a travs de Internet utilizando una gran cantidad de tecnologas basadas en la web modernos. La experiencia adquirida en la ltima dcada de algunos de los lderes de la tecnologa que proporcionan servicios a travs de Internet (por ejemplo, Google, Amazon, Ebay, etc.) indican que las infraestructuras de aplicaciones en el contexto de nubes deben ser altamente fiable, disponible y escalable. La fiabilidad es un requisito clave para asegurar el acceso continuo a un servicio yse define como la probabilidad de que una aplicacin o sistema dado estarn funcionando cuando sea necesario como se mide durante un perodo determinado de tiempo. Del mismo modo, la disponibilidad es el porcentaje de veces que un sistema dado estar funcionando como se requiere. 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. De hecho se producen estas fluctuaciones de carga a diferentes frecuencias: diaria, semanal y durante perodos ms largos. La otra fuente de variacin de la carga se debe al crecimiento impredecible (o disminucin) en el uso. La necesidad de un diseo escalable es asegurar que el sistema de capaci- dad se puede aumentar mediante la adicin de recursos de hardware adicionales siempre que est justificado por las fluctuaciones de carga. Por lo tanto, la escalabilidad tanto ha surgido como un requisito crtico, as como un desafo fundamental en el contexto de la nube.En el contexto de la mayor parte de aplicaciones basadas en la nube y las implementaciones de servicios, los datos y por lo tanto el sistema de gestin de base de datos (DBMS) es una tecnologa integral com- ponente en la arquitectura global del servicio. La razn de la proliferacin de DBMS, en el espacio de computacin en la nube es debido a la DBMS xito y, en particular, Relational DBMS han tenido en el modelado de una amplia variedad de aplicaciones. Los ingredientes clave de este xito se debe a muchos ofrecen funciones DBMS: funcionalidad global (modelado di- versos tipos de aplicacin utilizando el modelo relacional que es intuitiva y relativamente simple), consistencia (que trata de cargas de trabajo simultneas sin preocuparse por los datos convertirse en fuera de -sync), rendimiento (tanto de alto rendimiento, baja latencia y ms de 25 aos de ingeniera), y la fiabilidad (garanta de la seguridad y la persistencia de los datos en la presencia de diferentes tipos de fallas). A pesar de este xito, durante la ltima dcada

2Agrawal et al.

La escalabilidad de base de datos, la elasticidad y la Autonoma en la Nube3

ha habido una preocupacin creciente de que los DBMS y RDBMS no estn en la nube de usar. Esto es porque, a diferencia de otros componentes de la tecnologa para servicio en la nube, como los servidores web y servidores de aplicaciones, que pueden escalar fcilmente de unas pocas mquinas a cientos o incluso miles de mquinas), los DBMS no puede escalarse fcilmente. De hecho, la tecnologa DBMS actual no proporciona herramientas y orientaciones adecuadas si una implementacin de base de datos existente necesita para escalar hacia fuera de unas pocas mquinas a un gran nmero de mquinas.En el nivel de infraestructura de hardware, 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 computacin. Los lderes tecnolgicos como Google, Amazon, y Mi- crosoft han demostrado que los centros de datos proporcionan economas de escala sin precedentes desde mltiples aplicaciones pueden compartir una infraestructura comn. Las tres empresas han tomado esta idea de compartir ms all de sus aplicaciones internas y proporcionar marcos como AWS de Amazon, AppEngine de Google y Microsoft Azure para alojar aplicaciones de terceros en sus respectivas infraestructuras de centros de datos (es decir. Las nubes). Por otra parte, la mayora de estos lderes de la tecnologa han abandonado el DBMS tradicional y tecnologas de gestin de datos de propiedad en lugar han desarrollado denominadas tiendas de clave-valor. La principal distincin es que en los DBMS tradicional, 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. En el contexto de las tiendas de valores clave de esta relacin est completamente cortado en los valores fundamentales en que cada entidad se considera una unidad independiente de datos o informacin y por lo tanto se puede mover libremente de una mquina a otra. Por otra parte, la atomicidad de aplicaciones y accesos de usuarios estn garantizados slo a nivel de una sola tecla. Almacenes de claves y valores en relacin con los marcos de cloud computing han trabajado muy bien y un gran nmero de aplicaciones web han desplegado la combinacin de esta tecnologa cloud computing. Ms lderes tecnolgicos recientes, como Facebook tambin se han beneficiado de este paradigma en la creacin de aplicaciones complejas que son altamente escalable.El requisito de hacer aplicaciones web escalables en plataformas de cloud computing surge principalmente para apoyar nmero virtualmente ilimitado de usuarios finales. Otro de los retos en la nube que est estrechamente vinculada a la cuestin de la escalabilidad es desarrollar mecanismo para responder a las fluctuaciones bruscas de carga en una aplicacin o un servicio debido a los aumentos repentinos de demanda o valles de los usuarios finales. La escalabilidad de un sistema slo nos ofrece una te garantiza que un sistema puede ser ampliado desde unas pocas mquinas a un mayor nmero de mquinas. En los entornos de cloud computing, tenemos que apoyar propiedad adicional de que tal la escalabilidad se puede aprovisionar dinmicamente sin causar ningn tipo de interrupcin en el servicio. Este tipo de provisiones dinmicas donde un sistema se puede escalar en marcha de forma dinmica mediante la adicin de ms nodos o se puede escalar hacia abajo mediante la eliminacin de los nodos se denomina dad como elasticidad. Tiendas de valores clave como BigTable y PNUTS han sido diseados para que puedan ser elstico o pueden ser aprovisionado dinmicamente en presencia de fluctuaciones de carga. Tradicionales sistemas de gestin de base de datos cionales, por el contrario, son en general previsto para una infraestructura empresarial que se aprovisiona de forma esttica. Por lo tanto, el objetivo principal de los DBMS es realizar el ms alto nivel de rendimiento para un determinado hardware e infraestructura de servidor. Otro requisito que est estrechamente relacionado con la escalabilidad y la elasticidad de software de gestin de datos es la de la gestin autonmica. Tradicionalmente, los datos de administracin es una tarea altamente manual en un entorno empresarial donde entren altamente un

personal de ingeniera 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. A medida que avanzamos a la arena de cloud computing que tpicamente comprende centros de datos con miles de servidores, el enfoque manual de la administracin de bases de datos ya no es factibles. En cambio, hay una creciente necesidad de hacer que la subyacente capa de gestin de datos autonmica o de autogestin en especial cuando se trata de cargar la redistribucin, la du- escalabilidad y elasticidad. Este problema se hace especialmente aguda en el contexto de las plataformas de cloud-computing de pago por uso que alojan aplicaciones multi-tenant. En este modelo, el proveedor de servicios est interesado en minimizar su costo operacional mediante la consolidacin de mltiples inquilinos en el menor nmero de mquinas como sea posible durante los perodos de baja actividad y la distribucin de estos inquilinos en un mayor nmero de servidores durante el uso mximo.Debido a las propiedades deseables por encima de las tiendas de valores clave en el contexto de la computacin en nube y centros de datos a gran escala, que estn siendo ampliamente utilizados como los datos de gestin de nivel cin para las aplicaciones web en la nube habilitado. Aunque se afirma que la atomicidad en una nica clave es adecuada en el contexto de las muchas aplicaciones orientados a la Web, est surgiendo evidencia que indica que en muchos escenarios de aplicacin esto no es suficiente. En tales casos, la responsabilidad de garantizar la atomicidad y consistencia de mltiples entidades de datos recae sobre los desarrolladores de aplicaciones. Esto resulta en la duplicacin de los mecanismos de sincroni- multi-entidad sincronizacin muchas veces en el software de aplicacin. Adems, como se reconoce en general que los programas concurrentes son altamente vulnerables a fallos y errores sutiles, este enfoque afecta a la fiabilidad de las aplicaciones negativamente. La realizacin de proporcionar atomicidad ms all de las entidades individuales es ampliamente discutido en los blogs de desarrolladores [28]. Recientemente, este problema tambin ha sido reconocido por los arquitectos superiores de Amaznica [23] y Google [16], dando lugar a sistemas como MegaStore que ofrecen garantas de transacciones en las tiendas de valores clave [3].La computacin en nube y el concepto de centros de datos a gran escala se convertir en una tecnologa sive perva- en los prximos aos. Hay dos principales obstculos tecnolgicos que nos enfrentamos en el despliegue de aplicaciones en infraestructuras de cloud computing: DBMS escalabilidad dad y seguridad DBMS. En este artculo, nos centraremos en el problema de hacer que la tecnologa DBMS nube de usar. De hecho, vamos a argumentar que el xito de la computacin en nube es forma determinante en la fabricacin de los DBMS escalable, elstica y autnomo, que se suma a las otras propiedades conocidas de las tecnologas de gestin de bases de datos: alto nivel de funcionalidad, consistencia, rendimiento, y fiabilidad. Este documento resume el estado de la tcnica actual, as como identifica las reas donde se necesita urgentemente progreso de la investigacin.

2 La escalabilidad de base de datos en la nube

En esta seccin, primero establecer formalmente el concepto de escalabilidad. En el contexto de los paradigmas de computacin en nube, hay dos opciones para escalar la capa de gestin de datos. La primera opcin es comenzar con los almacenes de claves y valores, que tienen la escalabilidad casi ilimitada, y explorar las formas en que estos sistemas pueden ser enriquecidos para proporcionar la funcionalidad de base de datos de alto nivel, especialmente cuando se trata de proporcionar acceso transaccional a mltiples datos y de informacin entidades. La otra opcin es comenzar con una convencional

Arquitectura DBMS y el apalancamiento de las tiendas arquitectnico caractersticas de diseo clave-valor para hacer el DBMS altamente escalable. Ahora exploramos estas dos opciones en detalle.

2.1 EscalabilidadEscalabilidad es una propiedad deseable de un sistema, 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 (tpicamente hardware). Un sistema cuyo rendimiento mejora despus de aadir hardware, de forma proporcional a la capacidad aadida, se dice que es un sistema escalable. Del mismo modo, se dice que un algoritmo para escalar si es adecuadamente eficiente y prctico cuando se aplican a situaciones de gran tamao (por ejemplo, un conjunto de entrada de datos grandes o gran nmero de nodos participantes en el caso de un sistema distribuido). Si el algoritmo no puede realizar cuando los recursos aumentan entonces no escala.Normalmente hay dos maneras en el que un sistema puede escalar mediante la adicin de recursos de hardware. El primer enfoque es cuando el sistema escalas vertical y se conoce como aumento de escala. Para escalar verticalmente (o ampliar) significa aadir recursos a un solo nodo en un sistema, que suele implicar la adicin de procesadores o de memoria a un solo ordenador. Dicha escala vertical de los sistemas existentes tambin les permite utilizar la tecnologa de virtualizacin ms efectiva, ya que proporciona ms recursos para el conjunto organizado de los mdulos del sistema y de las aplicaciones ing operativos para compartir. Un ejemplo de aprovechamiento de estos recursos compartidos es mediante el aumento del nmero de procesos demonio Apache corriendo. El otro enfoque de la ampliacin de un sistema es mediante la adicin de recursos de hardware horizontalmente denominados scale-out. Para escalar horizontalmente (u horizontal) significa aadir ms nodos a un sistema, tales como la adicin de un nuevo equipo para una aplicacin de software distribuido. Un ejemplo podra ser escalado horizontal de un sistema web-servidor a un sistema con tres servidores web.Como los precios de computadoras caen y demanda de rendimiento siguen aumentando, sistemas de "productos bsicos" de bajo coste que se pueden usar para la construccin de infraestructuras computacionales compartidos para el despliegue de aplicaciones de alto rendimiento, tales como bsqueda en la web y otros servicios basados en la web. Cientos de pequeos ordenadores se pueden configurar en un clster para obtener potencia de clculo agregado que a menudo supera a la de los superordenadores solo tradicional procesador RISC basados. Este modelo ha sido impulsado por la disponibilidad de interconexiones de alto rendimiento. La maqueta de salida tambin 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. En general, el paradigma de escalabilidad horizontal ha servido como el paradigma de diseo fundamental para los centros de datos de hoy en gran escala. La complejidad adicional introducida por el diseo de la escala de salida es la complejidad general de mantener y administrar un gran nmero de nodos de almacenamiento y computacin.Tenga en cuenta que la escalabilidad de un sistema est estrechamente relacionado con el algoritmo de clculo o subyacente. En particular, dado un algoritmo si hay una fraccin que es inherentemente secuencial entonces que significa que el resto 1 - es paralelizable y por lo tanto pueden beneficiarse de mltiples procesadores. La escala mxima o aceleracin de un sistema de este tipo utilizando N CPUs est acotada que establezca la ley de Amdahl [1]:1

Velocidadarriba =

+1- .

N

Por ejemplo si slo el 70% de la computacin es paralelizables entonces el aumento de velocidad con 4 CPU es 2,105, mientras que con 8 procesadores que est a slo 2.581. El consolidado mencionado en la ampliacin claramente establece la necesidad de disear algoritmos y mecanismos que estn inherentemente escalable. Aadiendo ciegamente los recursos de hardware pueden no producir necesariamente la escalabilidad deseada en el sistema.

2.2 Fusin de datos: Multi-clave Atomicity en las tiendas de valores-claveComo se ha indicado anteriormente en la seccin anterior, aunque las tiendas de clave y valor proporcionan escalabilidad casi infinito en que cada entidad puede (potencialmente) ser manejado por en el nodo independiente, los nuevos requisitos de la aplicacin estn surgiendo que requieren mltiples entidades (o equivalencia teclas lently) para acceder atmicamente. Algunas de estas aplicaciones se encuentran en el dominio del trabajo cooperativo, as como en el contexto de los juegos multi-jugador. Esta necesidad ha sido reconocida por empresas como Google, que han ampliado su cartera de aplicaciones de Web-bsqueda a aplicaciones ms elaboradas tales como documentos de Google y otros. Ante esta necesidad, la pregunta que surge es cmo apoyar atomicidad multi-clave en las tiendas de valores clave como Bigtable de Google [7], de Amazon Dynamo [17], y PNUTS de Yahoo [9].Las diversas tiendas de valores clave difieren en trminos de modelo de datos, disponibilidad y garantas de consistencia, pero la propiedad comn a todos los sistemas es el valor-clave de abstraccin en que los datos se ve como pares clave-valor y el acceso atmica slo se admite en la granularidad de teclas individuales. Esta nica semntica clave de acceso atmica permite naturalmente eficiencia particin de datos horizontal ciente, y proporciona la base para la escalabilidad y la disponibilidad de estos sistemas. A pesar de que la mayora de las aplicaciones web actuales tienen patrones individuales claves de acceso [17], muchas aplicaciones actuales, y un gran nmero de Web 2.0 aplicaciones (tales como los basados en la colaboracin) ir ms all de la semntica de acceso a una sola tecla, y la incursin en el espacio de mltiples accesos clave [2]. Datos escalables actuales sistemas de ges- tin de lo que no pueden atender directamente a las necesidades de estas aplicaciones modernas, y estas aplicaciones, ya sea que tenga que recurrir a las bases de datos tradicionales, o depender de varias soluciones ad-hoc.Con el fin de hacer frente a este desafo, Google ha diseado un sistema llamado MegaS- arranc [3] que se basa en Bigtable como un sistema subyacente y crea la nocin de grupos de entidades en la parte superior de la misma. La idea bsica de MegaStore es permitir a los usuarios agrupar varias entidades en una sola coleccin y luego utiliza escritura anticipada registro [22, 32] y en dos fases [21] como los bloques de construccin para apoyar transacciones ACID en grupos de entidades definidas estticamente . Los diseadores tambin postulan que los accesos a travs de mltiples grupos de entidades tambin son compatibles, sin embargo, a un nivel de consistencia dbil o flojo. Aunque Megas- arranc permite entidades para ser distribuidos de manera arbitraria a travs de mltiples nodos, Megastore ofrece un mayor nivel de rendimiento cuando el grupo de entidad es co-localizado en un solo nodo. Por otro lado, si el grupo de entidades se distribuye a travs de mltiples nodos, en ese caso, el rendimiento global puede sufrir ya que los mecanismos de sincronizacin ms complejas, como en dos fases o colas persistentes puede ser necesario. Nos referimos a este enfoque como una arquitectura de fusin de datos de atomicidad multi-clave al tiempo que garantiza la escalabilidad.MegaStore de Google toma un paso ms all de los patrones de acceso clave individuales, favoreciendo el acceso transaccional para los grupos de entidades. Sin embargo, ya que las teclas no se pueden actualizar en su lugar, una vez que se crea una clave como parte de un grupo, tiene que estar en el grupo para el resto de su

vida. Esta naturaleza esttica de los grupos de entidades, adems de la exigencia de que las llaves sean contiguos en orden de clasificacin, son en muchos casos insuficiente y restrictivo. Por ejemplo, en el caso de una solicitud de casino en lnea donde los diferentes usuarios corresponden a diferentes pares de valores de teclado, se necesitan mltiples garantas de acceso clave slo durante el curso de un juego. Una vez que el juego termina, diferentes usuarios pueden moverse a diferentes instancias del juego lo que requiere garantas de grupos dinmicos de teclas de una caracterstica no la apoya MegaStore.

Para evitar este inconveniente, hemos diseado G-Store [14], un almacn de datos escalable que proporciona transaccionales mltiples garantas de acceso clave ms dinmicos grupos, que no se solapan de claves utilizando un almacn de claves-valor como un sustrato subyacente, y por lo tanto inherente iting su escalabilidad, tolerancia a fallos y alta disponibilidad. La innovacin bsica que per- mite el acceso de mltiples escalable clave es la abstraccin Grupo Clave que define un grnulo de acceso bajo demanda transaccional. El protocolo Agrupacin Clave utiliza la abstraccin Grupo Clave para transferir la propiedad, es decir, 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. Este diseo es adecuado para aplicaciones que requieren acceso transaccional a grupos de teclas que son de naturaleza transitoria, pero viven el tiempo suficiente para amortizar el coste de la formacin de grupos. Nuestro supuesto es que el nmero de teclas en un grupo es suficiente para ser propiedad de un solo nodo pequea. Teniendo en cuenta el tamao y la capacidad de la actual hardware de consumo, grupos con miles a cientos de miles de llaves se puede apoyar de manera eficiente. Adems, el sistema puede escalar de salida de decenas a cientos de nodos de las materias primas para soportar millones de Grupos Principales. G-Store hereda el modelo de datos, as como el conjunto de las operaciones de la tienda subyacente de valor-clave; Adems de ser el nico que las nociones de atomicidad y consistencia se extienden desde una nica clave para un grupo de teclas.

Un grupo clave consiste en una clave de lder y un juego de llaves de seguidor. El lder es parte de la identidad del grupo, pero desde una perspectiva de las aplicaciones, la semntica de las operaciones en el lder no es diferente de la de los seguidores. Una vez que la aplicacin especifica el Grupo Clave, la fase de creacin del grupo de Agrupacin Clave transferencias protocolo propiedad de teclas seguidor al nodo que alberga actualmente el lder clave, de manera que las transacciones ex ejecutora en el grupo pueden ejecutarse localmente. Intuitivamente, el objetivo del protocolo Agrupacin Clave propuesta es transferir la propiedad de clave de forma segura de los seguidores del lder durante la formacin del grupo, y del lder de los seguidores durante el borrado grupo. Conceptualmente, las teclas de seguidores estn bloqueadas durante la vida del grupo. Seguridad o correccin requiere que nunca debera haber un caso en ms de un nodo reclama la propiedad de un elemento. Liveness, por otra parte, requiere que, en ausencia de fallos repetidos, no hay ningn elemento de datos es sin dueo indefinidamente. Protocolo La Agrupacin Clave pro- pueden tolerar mensaje y fallos en los nodos, as como mensajes nuevos pedidos, solicitudes de creacin de grupo concurrente, as como detectar grupo superposicin crear solicitudes [14].

Este enfoque de fusin de datos proporciona el bloque de construccin para el diseo de sistemas de datos escalables con garanta de consistencia en los grnulos de datos de diferentes tamaos, el apoyo a la semntica de aplicacin diferentes. Los dos diseos alternativos han resultado en los sistemas con diferentes caractersticas y comportamiento.

(a) rbol Esquema. (B) TPC-C como un esquema de rbol.

Fig. 1: Esquema de particionamiento de base de datos de nivel.

2.3 Datos Fisin: particionamiento de base de datos de soporte en DBMSContrario al enfoque de fusin de datos, donde mltiples grnulos pequeos de datos se combinaron para proporcionar garantas de transacciones estrictas en grnulos ms grandes de datos a escala, otra aproximacin a la escalabilidad es dividir una unidad de base de datos de gran tamao en fragmentos o particiones relativamente independientes y proporcionar transaccional garantiza slo en estos fragmentos. Nos re- unos servi- a este enfoque como datos fisin. Este enfoque de la particin de la base de datos y la ampliacin con el particionamiento es popularmente utilizado para escalar aplicaciones web. Desde las ineficiencias que resultan de transacciones distribuidas son bien conocidos (ver [11] para algunos nmeros de rendimiento), la eleccin de una buena tcnica de particin es fundamental apoyar una funcionalidad flexible al tiempo que limita las operaciones a una sola particin. Por ello, muchos sistemas modernos dividen el esquema de tal manera que la necesidad de transacciones distribuidas se reduce al mnimo, un enfoque conocido como particin nivel de esquema. Las transacciones que acceden a una nica particin se pueden ejecutar de manera eficiente sin ningn tipo de dependencia y la sincronizacin entre los servidores de base de datos al servicio de las particiones, por lo que permiten una alta escalabilidad y disponibilidad. Dividir el esquema de base de datos, en lugar de dividir tablas individuales, permite apoyar una rica funcionalidad incluso cuando la limitacin acciones ms transparentes a una sola particin. El fundamento de particionamiento nivel de esquema es que en un gran nmero de esquemas de bases de datos y aplicaciones, transacciones slo acceden a un pequeo nmero de filas relacionadas que pueden ser potencialmente propagan a travs de una serie de mesas. Este patrn se puede utilizar para agrupar los datos relacionados juntos en la misma particin.Un ejemplo popular de particionamiento surge cuando el esquema es un "esquema de rbol". A pesar de que tal esquema no abarca todo el espectro de las aplicaciones OLTP, una encuesta de aplicaciones reales dentro de una empresa comercial muestra que un gran nmero de aplicaciones, ya sea tiene un patrn de esquema tal inherente o se puede adaptar fcilmente a l [4] . Figura 1 (a) proporciona una ilustracin de un tipo de esquema tal. Este esquema es compatible con tres tipos de tablas: Tablas Primarias, Secundarias Tablas y tablas mundiales. La tabla principal forma la raz del rbol; un esquema tiene exactamente una tabla principal cuya principal actos clave como la clave de particionamiento. Sin embargo, un esquema puede tener varias tablas secundarias y mundiales. Cada tabla secundaria en un esquema de base de datos tendr la llave de la tabla principal como una clave externa. Haciendo referencia a la Figura 1 (a), el kp clave de la tabla principal aparece como una clave externa en cada una de las tablas secundarias. Esta estructura implica que corresponde a cada fila de la tabla principal, hay un grupo de filas relacionadas en las tablas secundarias, una estructura llamada un grupo de filas [4]. Todas las filas en el mismo grupo de filas son

garantizado ser colocalizarse y una transaccin slo puede filas de acceso en un grupo de filas en particular. Una particin de base de datos es una coleccin de tales grupos de filas. Esta estructura de esquema tambin permite la divisin dinmica eficiente y fusin de particiones. En contraste con estos dos tipos de tablas, tablas globales son tablas de consulta que en su mayora son de slo lectura. Desde tablas globales no se actualizan con frecuencia, estas tablas se replican en todos los nodos. Adems de acceder a un solo grupo de filas, una operacin en una transaccin slo puede leer una tabla global. Figura 1 (b) muestra una representacin del esquema TPC-C [29] como un esquema de rbol. Un esquema tal forma la base del diseo de un nmero de sistemas tales como MS SQL Azure [4], ElasTraS [12], y la nube relacional [10]. Los diseos MS SQL Azure y Rela- cin 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 integracin se proporciona en la parte superior para encaminar consultas y transacciones a un servidor de base de datos adecuada. El diseo ElasTraS por otra parte utiliza el modelo de almacenamiento compartida basada en sistemas de archivos de agregacin de slo distribuido, como GFS [20] o HDFS [25]. La caracterstica deseable del diseo ElasTraS es que soporta la elasticidad de los datos de una manera mucho ms integrada. En particular, ambos diseos MS SQL Azure y relacional de la nube necesitan para ser ampliado mediante mecanismos de migracin de base de datos para apoyar la elasticidad donde la migracin de particiones de base consiste en mover los dos datos de estado de base de datos y residentes en disco residentes en memoria. ElasTraS, por otro lado, puede soportar la elasticidad de base de datos para la reubicacin de las particiones de base de datos simplemente migrar el estado de la memoria de la base de datos que es considerablemente ms simple. De hecho, bien conocido tcnicas de migracin VM [6, 8, 27] puede ser fcilmente adoptada en el caso de ElasTraS [15].Esta particin nivel de esquema de grandes bases de datos se divide en grnulos ms pequeos, que luego se pueden escalar hacia fuera en un grupo de nodos. Elastmeros Trs Nuestro llamado sistema prototipo [12, 13]: utiliza este concepto de la fisin de datos a escala de salida los sistemas de bases de datos. ElasTraS es la culminacin de dos grandes filosofas de diseo: sistemas tradicionales de bases de datos relacionales (RDBMS) sistemas que permitan una ejecucin eficiente de las cargas de trabajo OLTP y proporcionan garantas ACID para pequeas bases de datos y las tiendas de valor-clave que estn elstica, escalable y altamente disponible que el sistema a escala de salida. El intercambio de recursos eficaces y la consolidacin de mltiples inquilinos en un nico servidor permite que el sistema para hacer frente de manera eficiente con los inquilinos con pequeas necesidades de datos y de recursos, mientras que la base de datos avanzada particionamiento y la escala de salida le permite servir inquilinos que crecen grandes, tanto en trminos de datos, as como de carga. ElasTraS opera en la granularidad de estos grnulos de datos llamados particiones. Se extiende tcnicas desarrolladas para tiendas de valor-clave para escalar a un gran nmero de particiones distribuidas en decenas a cientos de servidores. Por otro lado, cada particin acta como una base de datos independiente; ElasTraS utiliza tecnologa desarrollada para las bases de datos relacionales [22] para ejecutar transacciones de manera eficiente en estas particiones. El enfoque de particin descrito aqu puede ser considerado como particin esttica. Se han hecho esfuerzos lti- mos para lograr particin de base de datos en tiempo de ejecucin mediante el anlisis de los patrones de acceso de datos de consultas de los usuarios y transacciones sobre la marcha [11].

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. Para un DBMS desplegado en una nube de pago por uso

infraestructura, un objetivo aadido es optimizar el costo de operacin del sistema. La elasticidad, es decir, la capacidad para hacer frente a las variaciones de carga mediante la adicin de ms recursos durante la alta carga o consolidar los inquilinos a menos nodos cuando la carga disminuye, todo en un sistema vivo sin interrupcin del servicio, es de importancia crtica para estos sistemas.A pesar de que la elasticidad se asocia a menudo con la escala del sistema, existe una sutil diferencia entre la elasticidad y escalabilidad cuando se utiliza para expresar el comportamiento de un sistema. La escalabilidad es una propiedad esttica del sistema que especifica su comportamiento en una configuracin esttica. Por ejemplo, un diseo del sistema puede escalar a cientos o incluso miles de nodos. Por otro lado, la elasticidad es la propiedad dinmica que permite la escala del sistema para aumentar bajo demanda, mientras que el sistema est en funcionamiento. Por ejemplo, un diseo de sistema es elstica si se puede escalar desde 10 servidores a 20 servidores (o viceversa) a la carta. Un sistema puede tener cualquier combinacin de estas dos propiedades.Elasticidad es una propiedad deseable e importante de sistemas de gran escala. Para un sistema desplegado en un servicio en la nube de pago por uso, tales como la infraestructura como servicio (IaaS) la extraccin, la elasticidad es fundamental para minimizar los costos de operacin al tiempo que garantiza un buen rendimiento durante cargas elevadas. Permite la consolidacin del sistema de consumir menos recursos y por lo tanto minimizar el costo de operacin durante los periodos de baja carga, mientras permitiendo cin a escalar dinmicamente su tamao que la carga disminuye. Por otra parte, las infraestructuras empresariales a menudo se aprovisionan estticamente. La elasticidad es tambin deseable en este tipo de escenarios donde se permite la realizacin de la eficiencia energtica. A pesar de que la infraestructura se aprovisiona estticamente, ahorros significativos pueden ser alcanzados por la consolidacin del sistema de una manera que algunos servidores pueden ser alimentados por la reduccin del uso de energa y los costes de refrigeracin. Esto, sin embargo, es un tema de investigacin abierta en su propio mrito, ya que apagar los servidores al azar no reduce necesariamente el uso de energa. Es necesaria una planificacin 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 refrigeracin se puede lograr. Tambin hay que considerar el impacto de apagar la disponibilidad. Por ejemplo, la consolidacin del sistema a un conjunto de servidores de todo dentro de un nico punto de fallo (por ejemplo, un interruptor o una unidad de fuente de alimentacin) pueden dar lugar a una interrupcin del servicio entero resultante de un solo fallo. Por otra parte, la crianza de los servidores apagados es ms caro, por lo que la pena por una operacin de apagado miss-predicho es mayor.En nuestro contexto de un sistema de base de datos, la migracin de las partes de un sistema mientras el sistema est en funcionamiento es importante para lograr una elasticidad-operacin llamada migracin de base de datos en vivo bajo demanda. Si bien es elstico, el sistema tambin debe garantizar los acuerdos de nivel de servicio de los inquilinos (SLA). Por lo tanto, para ser utilizado con eficacia para la elasticidad, la migracin en vivo debe tener un bajo impacto, es decir efecto insignificante en el rendimiento y escaso servicio in interrupcin el inquilino va a migrar, as como otros inquilinos co-localizados en el origen y destino de la migracin.Dado que la migracin es una primitiva necesaria para lograr elasticidad, nos centramos nuestros esfuerzos en el desarrollo de la migracin en vivo para las dos arquitecturas ms comunes de base de datos en la nube comn: disco compartido y no se comparte nada. Arquitecturas de discos compartidos se utilizan por su capacidad de replicacin abstracto, tolerancia a fallos, la coherencia, la tolerancia a fallos, y la escala inde- pendiente de la capa de almacenamiento de la lgica DBMS. Bigtable [7], HBase [24] y ElasTraS [12, 13] son ejemplos de bases de datos que utilizan una arquitectura de disco compartido. Por otro lado, una nada compartida arquitectura multi-tenant utiliza conectada localmente almacenamiento

10Agrawal et al.

La escalabilidad de base de datos, la elasticidad y la Autonoma en la Nube11

para almacenar la imagen de base de datos persistente. La migracin en vivo para una nada compartida arquitectura de requiere que todos los componentes de base de datos se migran entre nodos, incluyendo los archivos de almacenamiento fsico. Para facilitar la presentacin, se utiliza la particin trmino para representar un grnulo autnomo de la base de datos que se van a migrar de la elasticidad.

En una arquitectura DBMS almacenamiento compartido la imagen persistente de la base de datos se almacena en un almacenamiento conectado a red (NAS). En la arquitectura DBMS almacenamiento compartido, los datos persistentes de una particin se almacenan en el NAS y no necesita la migracin. Hemos diseado Copiar iterativo para la migracin de base de datos activa en una arquitectura de almacenamiento compartido. Para minimizar la interrupcin del servicio y para asegurar una baja sobrecarga de la migracin, iterativo Copia centra en la transferencia de la estado de la memoria principal de la particin, de modo que la particin comienza "caliente" en el nodo de destino resulta en un impacto mnimo sobre las transacciones en el destino, lo que permite transacciones activas durante la migracin a continuar la ejecucin al destino, y minimizar la ventana indisponibilidad del inquilino. El estado de la memoria principal de una particin est conformada por el estado en cach de base de datos (estado DB), y el estado de ejecucin de la transaccin (estado de transaccin). Para la mayora de los motores de bases de datos comunes [22], el Estado DB incluye las pginas de base de datos en cach o alguna variante de esto. Para un bloqueo de dos fases (2PL) programador basado en [22], el estado de la transaccin consiste en la tabla de bloqueos; para un control de divisas Con- Optimista (OCC) [26] planificador, este estado consiste en la lectura y escritura de conjuntos de transacciones activas y un subconjunto de las transacciones comprometidas. Copia iterativo garantiza la secuencialidad de transacciones activas durante la migracin y garantiza la correccin durante las fallas. Un anlisis detallado de esta tcnica, optimizaciones, y una evaluacin detallada puede encontrarse en [15].

En la arquitectura nada comn, la imagen persistente de la base de datos tambin se debe migrar, que es tpicamente mucho ms grande que la memoria cach de base de datos migrada en la arquitectura de disco compartido. Como resultado, se necesita un enfoque diferente de iterativo Copiar. Hemos diseado Zephyr, una tcnica para la migracin en vivo en un nada comn transaccional arquitectura de base de datos [19]. Zephyr minimiza la interrupcin del servicio para el inquilino va a migrar mediante la introduccin de una fase sincronizada que permite tanto el origen como de destino para ejecutar simultneamente transacciones para el inquilino. Usando una combinacin de traccin a la carta y empuje asncrono de datos, Zephyr permite al nodo de origen para completar la ejecucin de las operaciones activas, permitiendo al mismo tiempo el destino para ejecutar nuevas transacciones. Sincronizacin de peso ligero entre el origen y el destino, slo durante el corto modo de funcionamiento sincronizado, garantas secuencialidad, mientras viating observado la necesidad de dos fases [21]. Zephyr garantiza que no habr interrupcin del servicio por otros inquilinos, hay un sistema de tiempo de inactividad, minimiza datos transferidos entre los nodos, garantiza una migracin segura en presencia de fallos, y se asegura el nivel ms fuerte de aislamiento de la transaccin. Utiliza ndices basados rbol estndar y bloquear el control de concurrencia basado, permitiendo as que sea utilizada en una variedad de implementaciones de DBMS. Zephyr no se basa en la replicacin en la capa de base de datos, proporcionando as una mayor flexibilidad en selec- cionar el destino de la migracin, que podra o no tener rplica del inquilino. Sin embargo, una considerable mejora del rendimiento es posible en presencia de la replicacin cuando un inquilino se migra a una de las rplicas.

4 Autonoma de base de datos en la nube

La gestin de grandes sistemas plantea retos importantes en la supervisin, la gestin y el funcionamiento del sistema. Adems, para reducir el costo de operacin, se necesita una autonoma considerable en la administracin de tales sistemas. En el contexto de los sistemas de bases de datos, las responsabilidades de este controlador autonmica se incluyen el control de la conducta y el rendimiento del sistema, la escala elstica y balanceo de carga basado en patrones de uso dinmico, el comportamiento de modelos para predecir los picos de carga de trabajo y tomar medidas proactivas para manejar estos picos. Un controlador de sistema autnomo e inteligente es esencial para gestionar adecuadamente este tipo de sistemas grandes.Modelado del comportamiento de un ajuste del sistema de base de datos y el rendimiento ha sido un rea activa de investigacin en el ltimo par de dcadas. Un gran cuerpo de trabajo se centra en el ajuste de los parmetros apropiados para optimizar el rendimiento de la base de datos [18, 31], principalmente en el contexto de un nico servidor de base de datos. Otra lnea de trabajo se ha centrado en la prediccin de los recursos, el aprovisionamiento y la colocacin en grandes sistemas distribuidos [5,30]. Para activar la autonoma en una base de datos en nube, un controlador de sistema inteligente tambin debe considerar varios aspectos adicionales, especficamente en el caso en que el sistema de base de datos se implementa en una infraestructura cloud de pago por uso mientras serva aplicacin mltiple de diez casos de hormigas, es decir, un sistema de base de datos en nube multiusuario. En tal sistema multiusuario, cada inquilino paga por el servicio prestado y diferentes inquilinos en el sistema puede tener objetivos contrapuestos. Por otra parte, el proveedor de servicios debe compartir recursos entre los inquilinos, siempre que sea posible, para minimizar el costo de operacin para maximizar las ganancias. Un controlador para un sistema de este tipo debe ser capaz de modelar las caractersticas dinmicas y los requisitos de re- cursos de los diferentes inquilinos de aplicacin para permitir el escalado elstico al tiempo que garantiza un buen rendimiento inquilino y asegurar que se cumplan los inquilinos de nivel de servicio los acuerdos (SLA). Un controlador autnomo consta de dos componentes lgicos:el componente esttica y la componente dinmica.El componente esttico es responsable de modelar el comportamiento de los inquilinos y su uso de los recursos para determinar la colocacin inquilino para co-localizar a los inquilinos con los requisitos comple- mentarios de recursos. El objetivo de este algoritmo colocacin inquilino es terio mizar la utilizacin total de los recursos y, por tanto, reducir al mnimo los costos de operacin al tiempo que garantiza el cumplimiento de los SLAs inquilinos. Nuestro trabajo actual utiliza una combinacin de mquina de aprendizaje ing tcnicas para clasificar el comportamiento inquilino seguido de algoritmos de colocacin de empresa para determinar inquilino co-ubicacin y consolidacin ptima. Este modelo supone que una vez que el comportamiento de un inquilino se modela y una colocacin inquilino determinado, el sistema continuar a comportarse de la manera en que se model la carga de trabajo, y por lo tanto se llama el componente esttico. El componente dinmico complementa este modelo esttico mediante la deteccin de un cambio dinmico en el comportamiento de la carga y el uso de recursos, modelando el comportamiento del sistema en su conjunto para determinar el momento oportuno para que el equilibrio de carga elstica, la seleccin de los cambios mnimos en la colocacin inquilino necesaria para contrarrestar el comportamiento dinmico, y el uso de la tcnicas de migracin de base de datos en vivo para volver a equilibrar los inquilinos. Adems de modelar el comportamiento inquilino, tambin es importante para predecir el costo de migracin de tal manera que una migracin para reducir al mnimo el costo de operacin no viola SLA de un inquilino. Una vez ms, utilizamos modelos de aprendizaje de mquina para predecir el costo de migracin de los inquilinos y las cuentas modelo re-colocacin para este costo cuando se determina que el inquilino de migrar, cundo migrar y dnde emigrar [15].

5 Comentarios finales

Sistemas de bases de datos desplegados en una infraestructura de cloud computing se enfrentan a muchos nuevos retos, como se trata de operaciones a gran escala, la elasticidad de peso ligero, y el control autnomo para reducir al mnimo el costo de operacin. Estos retos son, adems de hacer los sistemas tolerantes a errores y alta disponibilidad. En este artculo, presentamos una visin general de algunas de nuestras actividades de investigacin en curso para hacer frente a los desafos mencionados en el diseo de una capa de gestin de datos escalable en la nube.

Referencias

1. Amdahl, G .: La validez del enfoque nico procesador para el logro de las capacidades de computacin a gran escala. En: AFIPS Conferencia. p. 483.485 (1967)2. Amer-Yahia, S., Markl, V., Halevy, A., Doan, A., Alonso, G., Kossmann, D., Weikum, G .: Las bases de datos y el panel de la Web 2.0 en VLDB 2007. SIGMOD Rec. 37 (1), 49-52 (2008)3. Baker, J., Bond, C., Corbett, J., Furman, J., Khorlin, A., Larson, J., Len, JM, Li, Y., Lloyd, A., Yushprakh, V .: Megastore: Proporcionar Escalable, almacenamiento de alta disponibilidad para los servicios interactivos. En: CIDR. pp. 223-234 (2011)4. Bernstein, P.A., Cseri, I., Dani, N., Ellis, N., Kalhan, A., Kakivaya, G., Lomet, DB, manera, R., Novik, L., Talius, T .: La adaptacin de Microsoft SQL Server para Cloud Computing. En: ICDE (2011)5. Bod'k, P., Goldszmidt, M., Fox, A .: Hilighter: construir automticamente firmas slidas de comportamiento de rendimiento para sistemas de pequea y gran escala. En: SysML (2008)6. Bradford, R., Kotsovinos, E., Feldmann, A., Schioberg, H .: En vivo en toda la zona de migracin de mquinas virtuales que incluyen estado persistente local. En: VEE. pp. 169-179 (2007)7. Chang, F., Dean, J., Ghemawat, S., Hsieh, WC, Wallach, DA, Burrows, M., Chandra, T., Fikes, A., Gruber, RE: Bigtable: Un sistema de almacenamiento distribuido de datos estructurados. En: IESO. pp. 205-218 (2006)8. Clark, C., Fraser, K., Mano, S., Hansen, JG, julio, E., Limpach, C., Pratt, I., Warfield, A .: La migracin en vivo de mquinas virtuales. En: INDE. pp. 273-286 (2005)9. Cooper, B.F., Ramakrishnan, R., Srivastava, U., Silberstein, A., Bohannon, P., Jacobsen, HA, Puz, N., Weaver, D., Yerneni, R .: PNUTS: acogi Yahoo 's de datos que sirve de plataforma!. Proc. VLDB Endow. 1 (2), 1277-1288 (2008)10. Curino, C., Jones, E., Popa, R., Malviya, N., Wu, E., Madden, S., Balakrishnan, H., Dovich Zel-, N .: Relacional Nube: Un servicio de base de datos para la nube. En: CIDR. pp. 235-240 (2011)11. Curino, C., Zhang, Y., Jones, EPC, Madden, S .: Cisma: un enfoque impulsado por la carga de trabajo para la replicacin de bases de datos y la particin. PVLDB 3 (1), 48-57 (2010)12. Das, S., Agarwal, S., Agrawal, D., El Abbadi, A .: ElasTraS: Una base de datos elstica, escalable y Auto Gestin Transaccional para la nube. Tecnologa. Rep. 2010-04, CS, UCSB (2010)13. Das, S., Agrawal, D., El Abbadi, A .: ElasTraS: Un almacn de datos transaccional elstico en la Nube. En: USENIX HotCloud (2009)14. Das, S., Agrawal, D., El Abbadi, A .: G-Store: Un almacn de datos escalable para Transaccional Multi Tecla de acceso en la Nube. En: ACM SOCC. pp. 163-174 (2010)15. Das, S., Nishimura, S., Agrawal, D., El Abbadi, A .: La migracin de base de datos en vivo para la elasticidad en una base de datos multiusuario para plataformas en la nube. Tecnologa. Rep. 2010-09, CS, UCSB (2010)16. Dean, J .: Charla en la Cumbre Facultad Google (2010)

17. Decandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Siva- subramanian, S., Vosshall, P., Vogels, W .: Dynamo: alta disponibilidad, valor clave de Amazon tienda. En: SOSP. pp. 205-220 (2007)18. Duan, S., Thummala, V., Babu, los parmetros de configuracin de base de datos S .: Puesta a punto con ituned. Proc. VLDB Endow. 2, 1246-1257 (agosto de 2009)19. Elmore, A., Das, S., Agrawal, D., El Abbadi, A .: Zephyr: Migracin de base de datos en vivo para Elasticidad Ligera en Plataformas Multitenant nube. bajo presentacin para su revisin20. Ghemawat, S., Gobioff, H., Leung, ST: El sistema de archivos de Google. En: SOSP. pp. 29-43 (2003)21. Gray, J .: Notas sobre los sistemas operativos de base de datos. En: Sistemas operativos, un curso avanzado. pp. 393-481. Springer-Verlag, Londres, Reino Unido (1978)22. Gray, J., Reuter, A .: Procesamiento de Transacciones: Conceptos y Tcnicas. Morgan Kaufmann Publishers Inc. (1992)23. Hamilton, J .: Me encanta la consistencia eventual pero ... http://bit.ly/hamilton-eventual(Abril de 2010)24. HBase: Bigtable-likestructuredstorageforHadoopHDFS(2010),http://hadoop.apache.org/hbase/25. HDFS: Un sistema de archivos distribuido que proporciona un alto rendimiento de acceso a datos de aplicacin (2010), http://hadoop.apache.org/hdfs/26. Kung, HT, Robinson, JT: En mtodos optimistas para el control de concurrencia. ACM Trans.Syst Database. 6 (2), 213-226 (1981)27. Liu, H., et al .: La migracin en vivo de mquinas virtuales basadas en rastro de todo el sistema y la reproduccin. En: HPDC. pp. 101-110 (2009)28. Obasanjo, D .: Cuando las bases de datos se encuentran: Consistencia vs. disponibilidad en sistemas distribuidos.http://bit.ly/4J0Zm (2009)29. El Transaction Processing Performance Council: TPC-C de referencia (Versin 5.10.1) (2009)30. Urgaonkar, B., Rosenberg, AL, Shenoy, PJ: colocacin de aplicaciones en un clster de servidores. Int. J. encontrado. Comput. Sci. 18 (5), 1023-1041 (2007)31. Weikum, G., Moenkeberg, A., Hasse, C., Zabback, tecnologa de base de datos auto-tuning y servicios de informacin P .:: del optimismo a ultranza a la ingeniera viable. En: VLDB. pp. 20-31 (2002)32. Weikum, G., Vossen, sistemas G .: transaccionales informacin: teora, algoritmos y la prctica del control de concurrencia y recuperacin. Morgan Kaufmann Publishers Inc. (2001)