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 aplicaciones 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.

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.

Agrawal et al.

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 ahora
es 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 y
se 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 diversos 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

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 duescalabilidad y elasticidad. 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 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- multientidad 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.

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

Escalabilidad

Escalabilidad 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]:
Velocidadarriba =

1
+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-clave

Como 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 clavevalor 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 gestin 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 propueden 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 DBMS

Contrario 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].

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

1
0

Agrawal et al.

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

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.

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 colocalizar 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].

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. 169179 (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. 235240 (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., Sivasubramanian, 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
revisin
20.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/hamiltoneventual
(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)