Fast Distributed Transactions and Strongly Consistent Replication (Tema - Procesamiento de Transacciones de Base de Datos) (2) .En - Es

Fast transacciones distribuidas y la replicación Fuertemente consistente para sistemas OLTP de
base de datos
11
ALEXANDER THOMSON, THADDEUS DIAMOND, SHU-CHUN WENG, KUN REN, PHILIP SHAO, y DANIEL J.
ABADI, Universidad de Yale
A medida que más programas de gestión de datos está diseñado para el despliegue en nubes públicas y privadas, o en un clúster de servidores de conveniencia, los
nuevos sistemas de almacenamiento distribuido lograr el acceso cada vez más alto rendimiento de datos a través de la separación y la replicación. Con el fin de lograr
una alta escalabilidad, sin embargo, los sistemas actuales generalmente reducen soporte transaccional, no permitir transacciones que abarca individuales de varias
particiones.
Este artículo describe Calvin, una capa de replicación programación transacción práctico y de datos que utiliza una garantía de pedido determinista a
cativamente significantes reducir los costes de contención normalmente prohibitivas asociados con transacciones distribuidas. Esto permite una escalabilidad
casi lineal en un clúster de máquinas de las materias primas, sin eliminar garantías transaccionales tradicionales, la introducción de un punto único de fallo, o
que requieren los desarrolladores de aplicaciones para razonar sobre la partición de datos. Al replicar entradas de transacción en lugar de acciones
transaccionales, Calvin es capaz de soportar múltiples niveles, incluyendo la consistencia consistencia fuerte basada en Paxos través geográficamente
distantes réplicas-sin costo para el rendimiento transaccional.
Además, Calvin introduce un conjunto de herramientas que permitan a los desarrolladores de aplicaciones para obtener el rendimiento completo beneficio
de mecanismos de planificación transacción del lado del servidor de Calvino sin introducir la complejidad código adicional y la inconveniencia que normalmente
se asocian con el uso de DBMS procedimientos almacenados en lugar de ad hoc del lado del cliente actas. Categorías y descriptores de asunto: [C.2.4 Sistemas
distribuidos]: Bases de datos distribuidos; H.2.4 [ Gestión de base de datos]: Systems- Concurrencia, bases de datos distribuidas, procesamiento de
transacciones
Condiciones generales: Algoritmos, diseño, rendimiento y fiabilidad
Palabras clave adicionales y frases: determinismo, los sistemas de bases de datos distribuidas, replicación, el procesamiento de transacciones
Formato ACM Referencia:

Alejandro Thomson, Thaddeus diamante, Shu-ChunWeng, Kun Ren, Philip Shao, y Daniel J. Abadi. 2014. transacciones Fast distribuidos y replicación
fuertemente coherente para los sistemas de bases de datos OLTP. ACM Trans. Datab. Syst. 39, 2, artículo 11 (mayo de 2014), 39 páginas. DOI:
http://dx.doi.org/10.1145/2556685
1. INTRODUCCIÓN Y ANTECEDENTES
Muchos diseños de sistemas de base de datos distribuida recientemente introducidos se alejan de las transacciones ACID base de
datos de portabilidad tradicional SUP-. Algunos sistemas, tales como la Amazonia
Este trabajo fue realizado mientras que A. Thomson es actualmente fi af liated con Google; T. El diamante es actualmente fi af liated con Hadapt; K. Ren es
actualmente fi af liated con la Universidad Politécnica del Noroeste, China; y P. Shao es actualmente fi af liated con Microsoft.
Este trabajo fue patrocinado por la NSF en virtud de concesiones IIS-0845643 e IIS-1249722. K. Ren es apoyado por la Fundación Nacional de Ciencias
Naturales de China bajo la subvención 61033007 y 973 Proyecto Nacional en virtud de concesión 2012CB316203.
Direcciones de los autores: A. Thomson (autor correspondiente), Google; correo electrónico: thomson@cs.yale.edu ; T. Diamond, Hadapt; CAROLINA DEL
SUR. Weng, la Universidad de Yale; K. Ren, Universidad Politécnica del Noroeste, China; P. Shao, Microsoft; DJ Abadi, la Universidad de Yale.
Se permite hacer copias digitales o en papel de la totalidad o parte de este trabajo para uso personal o en el aula se concede sin siempre que las copias no se
hacen ni distribuido para bene fi cio o ventaja comercial y que las copias llevan este aviso y la cita completa en la primera página . Derechos de autor para los
componentes de este trabajo no sean propiedad de ACMmust ser honrados. Se permite abstraer con el crédito. Para copiar de otro modo, o volver a publicar,
para publicar en servidores o redistribuir en las listas, se requiere el permiso fi co antes y / o una tasa. Solicitar permisos de permissions@acm.org. C
© 2014 ACM 0362-5915 / 2014/05-ART11 $ 15.00 DOI:

http://dx.doi.org/10.1145/2556685
ACM Transactions on Database Systems, Vol. 39, N ° 2, el artículo 11, la fecha de publicación: May de 2014.
11: 2 A. Thomson et al.
Dynamo [Decandia et al. 2007], MongoDB [Plugge col. 2010], CouchDB [Anderson et al. 2010], y Cassandra [Lakshman y
Malik 2009] no proporcionan soporte transaccional en absoluto (en el momento de escribir esto). Otros proporcionar sólo
limitados actionality trans-, tal como de una sola fila actualizaciones transaccionales (por ejemplo, Bigtable [Chang et al.
2006]) o transacciones cuyos accesos se limitan a pequeños subconjuntos de una base de datos (por ejemplo, Azure
[Campbell et al. 2010] , Superalmacén [Baker et al. 2011], y la base de datos Oracle NoSQL [Seltzer 2011]). La razón
principal de que cada uno de estos sistemas no admite transacciones ACID es totalmente para proporcionar escalabilidad
hacia afuera lineal. Otros sistemas (por ejemplo, VoltDB [Stonebraker et al 2007;.. Jones et al 2010]) Compatibilidad
completa ACID,
Reduciendo en gran medida el apoyo transaccional simpli fi ca la tarea de construir scal- linealmente soluciones de bases
de datos distribuidas capaces. En particular, si no hay transacciones distribuidas, entonces no hay necesidad de coordinación
distribuida y protocolos de confirmación que limitan la escalabilidad del sistema mediante la ampliación de la cantidad de
tiempo que las cerraduras deben rendir (potencialmente la obstrucción del sistema) y mediante la introducción de los cuellos de
botella del ancho de banda de red . Algunas aplicaciones son naturalmente “vergonzosamente divisible”, y no tienen
necesidad de un sistema que admite transacciones distribuidas. Por ejemplo, si cada usuario de una aplicación cesos ac- sólo
sus propios datos de la cuenta privada (por ejemplo, un calendario privado o un servicio de carga foto), entonces es fácil de
particionar datos de la aplicación a través de muchas máquinas.
Muchas aplicaciones, sin embargo, no son naturalmente vergonzosamente divisible y se ven obligados a patrones de
acceso a particiones debido a los límites del sistema subyacente. Ejemplos de esto son los siguientes.
- Un cliente hacer un pedido de un sitio web de comercio electrónico. Puesto que los clientes pueden comprar cualquier
combinación arbitraria de artículos, es imposible garantizar que el inventario de informa- ción sobre los artículos que son
comprados serán todos situado en la samemachine. Por lo tanto la actualización de todos los inventarios de todos los artículos
que son comprados transaccionalmente es imposible para escalar de forma arbitraria y sin apoyo de las transacciones
distribuidas. En consecuencia, las grandes empresas minoristas como Amazon son forzadas a actualizaciones no
transaccionales de la información del inventario (y potencialmente clientes descontentos), como resultado de las limitaciones del
sistema de transacciones distribuidas.
- Una transacción de crédito-débito entre un par arbitrario de usuarios. Tan pronto como el sistema se ajusta al punto en el
que diferentes usuarios se almacenan en diferentes máquinas, la transferencia de dinero (o de otros controles) entre los
usuarios ubicados en diferentes máquinas re- manos de papel soporte para transacciones distribuidas. En la práctica, los
bancos suelen terminar haciendo un trabajo complicado fluye donde el débito y el crédito se producen en transacciones
separadas (con acciones compensatorias si uno de ellos falla), debido a la falta de apoyo al sistema para transacciones
distribuidas.
- Adición de un borde a un gráfico social para conectar dos usuarios. Tan pronto como el sistema se ajusta al punto en el
que diferentes usuarios se almacenan en diferentes máquinas, la adición de este borde requiere la participación de
ambas máquinas. En la práctica, las redes sociales se ven obligados a realizar estas acciones nontransctionally, y los
usuarios a veces pueden ver los efectos de la inconsistencia temporal que resulta.
- Otros ejemplos incluyen un usuario hacer una oferta en una subasta en línea, un jugador en un juego MMO de
interactuar con un objeto de juego virtual o con otro jugador, o un mensaje que está siendo enviado y recibido en una
aplicación de mensajería. Cada uno de estos incluye, naturalmente, varias máquinas diferentes, naturalmente, estar
involucrado en la transacción como las escalas de aplicación y el código de aplicación es forzado a trabajar alrededor de
las limitaciones de sistema de soporte transaccional distribuida.
Transacciones distribuidas Fast y la replicación consistente para sistemas de bases de datos OLTP 11: 3
Si bien estos ejemplos abarcan una amplia gama de dominios de aplicación (usamos el ejemplo de una Transferencia de
saldo en el resto de este artículo), tienen ciertas cosas en común.
- despliegues más importantes del mundo de este tipo de aplicaciones procesan un rendimiento extremadamente alto (a
menudo cientos de miles de millones de operaciones por segundo) para este tipo de operación en particular.
- Cuando los datos se reparte a través de muchas máquinas, los registros se accede por una de estas operaciones
pueden no siempre es de esperar que ser co-situado en la misma partición. Cada operación representa una interacción
entre un par (o pequeño grupo) de entidades lógicas, y una operación dada probable que abarcar varios particiones de
datos (dos es el más común).
- La correcta aplicación de estas operaciones es muy simpli fi cado por el apoyo de base de datos para transacciones ACID
arbitrarias. En caso contrario, soluciones complicadas deben ser implementado en la lógica de la aplicación.
sistemas de almacenamiento distribuidos con reducidas garantías transaccionales dejan la responsabilidad de garantizar la
atomicidad y aislamiento para el programador de aplicaciones para la clase precedentes de transacciones que resulta en mayor
complejidad del código, el desarrollo de aplicaciones más lento, de baja performance programación del lado del cliente de
transacciones y el usuario frente a inconsistencias en el comportamiento de la aplicación.
Calvin está diseñado para funcionar junto con un sistema de almacenamiento no transaccional, transformándolo en un
sistema de base de datos escalable linealmente compartición nula (casi) que proporciona una alta disponibilidad 1 y
transacciones ACID completos. Estas transacciones pueden abarcar potencialmente particiones múlti- ples repartidas por todo
el clúster no se comparte nada. Calvin logra esto proporcionando una capa por encima del sistema de almacenamiento que se
encarga de la programación de transacciones distribuidas, así como la comunicación de replicación y de la red en el sistema.
La característica técnico clave que permite la escalabilidad en la cara de transacciones distribuidas es un mecanismo de
bloqueo determinista que permite la eliminación de protocolos distribuidos cometer.
1.1. El Costo de transacciones distribuidas
Las transacciones distribuidas históricamente se han implementado por el comunidad base de datos de la manera por
primera vez por los arquitectos de Sistema R * [Mohan et al. 1986] en la década de 1980. El mecanismo principal por el cual
Sistema R * transacciones distribuidas al estilo de impedir el rendimiento y extender la latencia es el requisito de un protocolo
de acuerdo entre todas las máquinas que participan en dedicar tiempo para garantizar la atomicidad y durabilidad. Para
asegurar el aislamiento, todas las cerraduras de una transacción debe ser mantenida durante la duración completa de este
protocolo de acuerdo, que es típicamente de dos fases.
El problema con la celebración de las cerraduras durante el protocolo de acuerdo es que en dos fases requiere de red
múltiples viajes redondos entre todos los equipos participantes, y por lo tanto el tiempo requerido para ejecutar el protocolo a
menudo puede ser considerablemente mayor que el tiempo necesario para ejecutar toda la lógica de transacción local . Si
algunos registros que se accede popularmente son frecuentemente implicados en transacciones distribuidas, el tiempo extra
que resulta que los bloqueos se mantienen en estos registros puede tener un efecto muy perjudicial sobre todo exceso
rendimiento transaccional. Nos referimos a la duración total que mantiene una transacción
1 En este artículo se utiliza el término alta disponibilidad en el sentido coloquial común que se encuentra en la comunidad de base de datos en una base de datos
es altamente disponible si se puede conmutar por error a una réplica activa en-el-mosca sin tiempo de inactividad, en lugar de la de fi nición de alta disponibilidad
se utiliza en el teorema de la PAC, que requiere que incluso réplicas de las minorías siguen estando disponibles durante una partición de red.
sus cerraduras, que incluye la duración de cualquier requiere protocolo de confirmación-como la acción trans- de huella de
contención. Aunque la mayor parte de la discusión en este artículo se supone mecanismos de control de concurrencia
pesimista, los costos de extender la huella tention con- de una transacción son igualmente aplicables, y con frecuencia incluso
peor debido a la posibilidad de conexión en cascada aborta en esquemas optimistas.
Ciertos optimizaciones de confirmación en dos fases, tales como la combinación de múltiples transacciones simultáneas
cometer decisiones en una única ronda del protocolo, puede reducir la CPU y sobrecarga de la red de confirmación en dos
fases, pero no mejoran su coste de contención.
Permitiendo transacciones distribuidas también pueden introducir la posibilidad de interbloqueo distribuido en los sistemas de
aplicación de esquemas de control de concurrencia pesimista. Mientras TECCIÓN de- y bloqueo de puertas de corrección no
típicamente incurren en gastos indirectos del sistema prohibitivo, puede causar transacciones que ser abortado y reiniciado, el
aumento de la latencia y la reducción de rendimiento en cierta medida.
1.2. La replicación consistente
Una segunda tendencia en el diseño de sistema de base de datos distribuida ha sido hacia la reducción de garantías
consistencia con respecto a la replicación. Los sistemas tales como Dynamo, SimpleDB, Cassandra, Voldemort, Riak, y
PNUTS todo disminuyen las garantías de consistencia para datos replicados [Decandia et al. 2007; Lakshman y Malik 2009;
Cooper et al. 2008]. La razón dada típica para reducir la consistencia de replicación de estos sistemas es el teorema de
CAP [Gilbert y Lynch 2002] -en Para que el sistema para lograr una disponibilidad 24/7 global y permanecen disponibles
incluso en el caso de una red de parti- ción, la sistema debe proporcionar inferiores garantías de consistencia [Abadi 2012].
Sin embargo, durante el último año, esta tendencia se ha comenzado a revertir, tal vez en parte debido a la información
global en constante mejora de la infraestructura que hace particiones de red no triviales cada vez más raro, con varios
sistemas nuevos de apoyo ción replicativa fuertemente consistente. Megastore de Google y la llave inglesa [Baker et al.
2011; Corbett et al. 2012] y de IBM spinnaker [Rao et al. 2011], por ejemplo, se replican de forma sincrónica a través de
Paxos [Lamport 1998, 2001].
actualizaciones síncronas vienen con un costo de latencia fundamental para el proto-col acuerdo, el cual depende de la
latencia de red entre réplicas. Este costo puede ser signifi- signifi-, ya que las réplicas son a menudo separados
geográficamente para reducir las fallas correlacionadas. Sin embargo, esto solamente es intrínsecamente un coste de
latencia, y no tiene que necesariamente afecta tention con- o rendimiento.
1.3. Llegar a un acuerdo sin aumentar Contención
El enfoque de Calvino a la consecución de transacciones distribuidas de bajo costo y replicación sincrónica es la siguiente:
cuando varias máquinas necesitan ponerse de acuerdo sobre cómo manejar una transacción en particular, lo hacen fuera de
los límites de transacción, es decir, antes de que se adquieren bloqueos y comenzar la ejecución de la transacción.
Una vez que se ha llegado a un acuerdo sobre cómo manejar la transacción, que debe ejecutarse hasta su finalización
según el fallo plan de nodos y los problemas conexos no puede causar la transacción para abortar. Si un nodo falla, puede
recuperarse de una réplica que había sido ejecutando el mismo plan en paralelo, o, alternativamente, se puede reproducir
la historia de la actividad planificada para ese nodo. Tanto la ejecución de planes paralelos y reproducción del historial del
plan requieren la actividad planea ser determinista-réplicas de otro modo podrían divergir o la historia podría repetirse de
forma incorrecta.
Para apoyar esta determinismguarantee whilemaximizing concurrencia en la ejecución de transacciones, Calvin utiliza
un protocolo de bloqueo determinista basado en una introdujimos en trabajos anteriores [Thomson y Abadi 2010].
Dado que todos los nodos Calvin llegan a un acuerdo con respecto a lo transacciones para intentar y inwhat orden, es
capaz de comprometerse por completo eschewdistributed protocolos, reduciendo
las huellas de contención de transacciones distribuidas, permitiendo de ese modo el rendimiento a escala a cabo casi linealmente
a pesar de la presencia de las transacciones de varias particiones. Nuestros ex periments muestran que Calvin significativamente
supera a los diseños tradicionales de bases de datos distribuidas bajo cargas de trabajo de alta contención. Se encuentra que es
posible ejecutar transacciones de medio MIL león TPC-C por segundo en un clúster de máquinas de productos básicos en la nube
de Amazon, que se encuentra inmediatamente competitivos con los resultados récord mundial actualmente cado pu- en la web de
TPC-C sitio que se obtuvieron en el hardware tanto de gama más alta.
1.4. Mejorar la usabilidad de Calvino
garantía de determinismo de Calvin requiere toda la lógica de la transacción a ser declarada antes de la ejecución de transacciones y
luego ejecutado en su totalidad por el servidor de base de datos. procedimientos almacenados son un método bien conocido de lograr
exactamente esto, y son ampliamente compatibles con los sistemas de bases de datos comerciales. Sin embargo, la implementación de
transacciones como procedimientos almacenados en lugar de como transacciones del lado del cliente ad hoc a menudo introduce el
código signi fi cativo complejidad y molestias para los desarrolladores de aplicaciones.
Por lo tanto, se explora más opciones revelador-amistosas que transac- ción de formato nativo de fi nición de Calvino de
procedimientos almacenados C ++. En particular, se introduce un nuevo conjunto de técnicas que permiten transacciones
que se definen como funciones del lado del cliente para ser ejecutado no por el servidor de base de datos con poca o
ninguna instrumentación adicional requerida del desarrollador de la aplicación. Se describe un módulo de Python que
implementa una colección de estas técnicas.
1.5. Aportes
contribuciones principales de este artículo son las siguientes.
- Diseñamos una capa de programación de transacciones y replicación de datos que transforma un sistema de
almacenamiento no transaccional en una (casi) sistema de base de datos no se comparte nada linealmente escalable que
proporciona alta disponibilidad, consistencia fuerte y transacciones ACID completo.
- Le damos una implementación práctica de un protocolo de control de concurrencia determinista que es más escalable
que los enfoques anteriores, y no introduce un potencial punto de fallo.
- Nos presenta un mecanismo de captación previa de datos que aprovecha la fase de planificación per- formó antes de la
ejecución de la transacción para permitir transacciones para operar en los datos residentes en disco sin extender huellas de
contención de transacción para la du- ración completa de las búsquedas de disco.
- Ofrecemos un nuevo conjunto de herramientas que permite a los desarrolladores de aplicaciones para definir transacciones tan simple, ad hoc
funciones del lado del cliente, al tiempo que obtienen los beneficios de rendimiento de la ejecución del lado del servidor de código de
transacción.
- Le damos un esquema de puntos de comprobación rápida que, junto con el determinismo tizar ga- de Calvino, elimina
completamente la necesidad de tala REDO física y su sobrecarga asociada.
La siguiente sección discute más antecedentes sobre sistemas de bases de datos deterministas. En la sección 3 presentamos
diseño y la arquitectura de Calvin. Sección 4 trata Developer- extensiones amistosas a la API nativa de transacciones de
Calvin. En la Sección 5 abordamos cómo Calvin maneja transacciones que acceden a los datos residentes en disco. Sección 6
cubre el mecanismo de Calvin para tomar periódicamente instantáneas de base de datos completas. En la sección 7 se
presentan una serie de experimentos que exploran el rendimiento y la latencia de Calvin bajo diferentes cargas de trabajo. Se
presentan trabajos relacionados en la Sección 8, examinar la labor futura en la Sección 9, y concluir en la Sección 10.
2. Los sistemas de bases de DETERMINISTAS
En los sistemas de bases de datos tradicionales (Sistema R * -estilo) distribuida, la razón principal de que se necesita un
protocolo de acuerdo al confirmar una transacción distribuida es asegurar que todos los efectos de una transacción han
hecho con éxito para el almacenamiento duradero en un atómica de la moda, ya sea todo nodos implicados la transacción
se comprometen a “comprometerse” sus cambios locales o ninguno de ellos lo hacen. Los eventos que impiden un nodo de
cometer sus cambios locales (y por lo tanto hacen que toda la transacción para abortar) se dividen en dos categorías:
eventos deterministas (como fallos en los nodos) y eventos deterministas (como la lógica de transacción que obliga a un
aborto si, por ejemplo, una inventario nivel de stock caería por debajo de cero).
No hay ninguna razón fundamental de que una transacción debe abortar como resultado de cualquier evento no determinista;
cuando los sistemas decide abortar transacciones debido a eventos externos, que se debe a consideración práctica. Después de
todo, obligando a todos los demás nodos en un sistema que esperar a que el nodo que experimentó un evento no determinista
(por ejemplo, un fallo de hardware) para recuperar podría traer un sistema a una dolorosamente largo statu quo.
Si hay un nodo réplica de realizar las mismas operaciones exactas en paralelo a un nodo que ha fallado, sin embargo, a
continuación, otros nodos que dependen de la comunicación con el nodo af infligido a ejecutar una transacción no es
necesario esperar a que el nodo que ha fallado para recuperar de nuevo a su por el estado original, más bien se pueden
hacer peticiones al nodo de réplica de los datos necesarios para las operaciones actuales o futuras. Además, la transacción
puede ser cometido desde el nodo réplica fue capaz de completar la transacción, y el nodo que ha fallado el tiempo será
capaz de completar la transacción después de su recuperación. 2
Por lo tanto, si existe una réplica que está procesando las mismas transacciones en lel paralelismos al nodo que
experimenta el fracaso no determinista, el requisito para abortar operaciones en tales fracasos se elimina. El único
problema es que las réplicas tienen que estar pasando por la misma secuencia de estados de base de datos a fin de que
una réplica inmediatamente a sustituir a un nodo que ha fallado en medio de una transacción. Sincrónicamente replicar
cada cambio de estado de la base de datos tendría demasiado alto de una sobrecarga a ser factible. lugar In-, los sistemas
de base de datos deterministas sincrónicamente replicar lotes de transacción
peticiones. En una aplicación de base de datos tradicional, simplemente replicar de entrada transaccional generalmente no
es su fi ciente para asegurar que las réplicas no divergen, ya que las bases de datos garantizan que van a procesar las
transacciones de una manera que es lógicamente equivalente a algún orden en serie de transacciones de entrada, pero dos
réplicas pueden elegir para procesar la entrada de maneras equivalentes a diferentes órdenes de serie, por ejemplo debido
a diferente programación de subprocesos, las latencias de red, u otras limitaciones de hardware. Sin embargo, si la capa de
control de concurrencia de la base de datos es modi fi a adquirir bloqueos en el orden de la acordada de entrada
transaccional (y varias otras modificaciones menores a la base de datos se hacen [Thomson y Abadi 2010]), todas las
réplicas se pueden hacer para emular el mismo orden de ejecución en serie, y el estado de base de datos se puede
garantizar que no divergen. 3
Tales bases de datos deterministas permiten que dos réplicas para permanecer constante simplemente por la entrada de
base de datos cando imita- y, como se ha descrito antes, la presencia de estos nodos replicados activamente permite
transacciones distribuidas para cometer su trabajo en presencia de fallos terministic no destructiva (que potencialmente
puede ocurrir en el medio de una transacción). Esto elimina la principal justificación de un protocolo de acuerdo al final del
distribuida
2 Incluso en el caso improbable de que todas las réplicas experimentan el mismo fracaso no determinista, la transacción aún se puede confirmar si había
ningún código determinista en la parte de la transacción asignado a los nodos fallidos que podría causar la transacción para abortar, ya que la entrada
transaccional puede repetido después de la recuperación (ver la siguiente).
3 Más precisamente, los estados de las réplicas están garantizados para no aparecer divergente a las solicitudes externas de datos, a pesar de que su estado
físico no suelen ser idéntica a cualquier instantánea particular del sistema.
transacciones (la necesidad de comprobar para un fallo de nodo que podría causar la transacción para abortar). La otra
causa potencial de un aborto se mencionó anteriormente, la lógica a saber determinista en la transacción (por ejemplo, una
transacción debe ser abortado si el inventario es cero), no necesariamente tiene que ser realizado como parte de un
protocolo de acuerdo al final de una transacción. Más bien, cada nodo implicado en una transacción espera una sola vía
mensaje desde cada nodo que podrían potencialmente determinista abortar la transacción, y sólo se compromete una vez
que recibe estos mensajes. Estos mensajes pueden ser enviados tan pronto como un nodo sabe que tiene terminado fi con
cualquier lógica transaccional que posiblemente podrían causar la transacción para abortar (en lugar de al final de la
transacción durante un protocolo de cometer).
DISEÑO 3. SISTEMA
Hemos diseñado Calvin para su despliegue a través de grandes grupos de máqui- nas materias primas baratas. Para tolerancia a fallos,
Calvin se basa principalmente en la replicación. Aunque es posible desplegar casos no replicados de Calvin, en una con fi guración
tiempo de inactividad tal sistema será incurrido como resultado de cualquier fallo de nodo en el sistema, como un repeticiones del
proceso de recuperación de transacciones de entrada procedentes de un puesto de control con el fin de reparar el nodo que ha fallado.
Calvin está diseñado para servir como una capa transaccional escalable por encima de cualquier sistema de
almacenamiento que implementa una interfaz básica CRUD (Crear / inserto, Leer, Actualizar y Borrar). Aunque es posible
ejecutar Calvin en la parte superior de los sistemas de almacenamiento no transaccionales distribuidos como SimpleDB o
Casandra, es más sencillo para explicar la arquitectura de Calvin suponiendo que el sistema de almacenamiento no se
distribuye de la caja. En esta sección, se describe la arquitectura de una implementación estándar de Calvin en la que los
datos se reparte a través de sistemas de almacenamiento locales distribuidos a través de muchas máquinas ( “nodos”) - y
luego la base de datos completa se replica a través de múltiples grupos ( “réplicas”). Calvin orquesta todas las
comunicaciones de red que debe ocurrir entre réplicas (y entre los nodos dentro de cada réplica) en el curso de la ejecución
de la transacción.
La Figura 1 muestra un ejemplo de despliegue Calvin que replica la base de datos tres veces (réplicas una, si, y C), y
particiones cada réplica a través de seis máquinas, todo ello en un clúster de nada compartida por completo. Nos referimos
a cada máquina usando un identi fi cador METRO ij,
dónde yo indica la partición se almacena a la máquina, y j especi fi ca la réplica a la que pertenece la máquina.
La esencia de Calvin reside en separar el sistema en tres capas separadas de procesamiento, cada uno distribuidos a
través de cada máquina METRO ij participen en el despliegue.
- los capa de secuenciación ( o “secuenciador”) intercepta entradas transaccionales y los coloca en una entrada
transaccional secuencia global de esta secuencia será el orden de las operaciones a las que todas las réplicas se
garantice una equivalencia de serie durante su ejecu- ción. El secuenciador, por tanto, también se ocupa de la
replicación y la tala de esta secuencia de entrada.
- los capa de programación ( o “programador”) organiza la ejecución de transacciones utilizando un esquema de bloqueo
determinista para garantizar la equivalencia a la especificidad orden serial ed por la capa de secuenciación al tiempo que
permite las transacciones a ejecutar al mismo tiempo por un grupo de hilos de ejecución de la transacción. (A pesar de que
se muestran a continuación los componentes Scheduler en la Figura 1, estos hilos de ejecución conceptualmente
pertenecen a la capa de programación.)
- los capa de almacenamiento maneja toda la disposición física de datos. transacciones Calvin acceder a los datos mediante una interfaz
CRUD sencillo; cualquier motor de almacenamiento que soporta una interfaz similar puede ser enchufado en Calvin con bastante facilidad.
Al separar el mecanismo de replicación, la funcionalidad transaccional, y el control de concurrencia (en las capas de
secuenciación y programación) del sistema de almacenamiento, el diseño
Figura 1. Un despliegue de Calvin se distribuye a través de un clúster de no compartición de máquinas y se compone de varias réplicas del sistema, cada
repartió a través de muchos equipos. Cada máquina consta de un componente secuenciador, un componente de planificación, y un componente de
almacenamiento de datos.
de Calvin se desvía significativamente de la base de datos de diseño tradicional, que es altamente lítico mono-, con los
métodos de acceso físico, gestión de memoria intermedia, administrador de bloqueos, y el gerente ingrese altamente integrado
y cross-dependiente. Este desacoplamiento hace que sea imposible implementar ciertas técnicas de recuperación y control de
concurrencia populares, tales como el registro physiologi- cal en ARIES y siguiente tecla técnica de bloqueo de manejar
fantasmas (es decir, el uso de sustitutos físicas para las propiedades lógicas en el control de concurrencia). Calvin no es el
único intento de separar los componentes transaccionales de un sistema de base de datos de los datos de los componentes,
gracias a la computación en nube y sus servicios altamente modulares, ha habido un renovado interés dentro de la comunidad
de base de datos en la separación de estos lidades FunciÃ³n- en distinta y modular los componentes del sistema [Lomet et al.
2009].
3.1. Secuenciador y replicación
En los sistemas de WorkWith de base de datos determinista anteriores, se implementó la funcionalidad de la capa de
secuenciación como servidor de un simple eco único nodo que aceptó transac- solicitudes ción, ellos registrados en disco, y
las remitió en orden de llegada a los nodos de base de datos apropiadas dentro de cada réplica [Thomson y Abadi 2010].
Los problemas con secuenciadores de un solo nodo son: (a) que representan posibles puntos de fallo y (b) que a medida
que crecen los sistemas el caudal constante con destino de un secuenciador de un solo nodo trae escalabilidad general del
sistema a un alto rápido. capa de secuenciación de Calvin se distribuye en todas las réplicas del sistema, y también repartió
a través de cada máquina dentro de cada réplica.
Calvin divide el tiempo en épocas de 10 milisegundos durante el cual el componente secuenciador de cada máquina
recoge solicitudes de transacciones de los clientes. Al final de cada época, todas las solicitudes que han llegado a un nodo
secuenciador se compilan en un lote. Este es el punto en el que se produce la replicación de los insumos transaccionales
(discutido en breve).
En cada época, una vez cada secuenciador se ha replicado con éxito su proceso por lotes, todos los lotes se consideran
lógicamente haber sido anexado (en orden por ID secuenciador) a la secuencia de solicitud de transacción global. Tenga en
cuenta, sin embargo, que esta intercalación no se produce físicamente en cualquier máquina. En cambio, después de la
replicación de un lote, cada secuenciador envía amessage al planificador en cada partitionwithin su réplica que contiene: (1)
único ID de nodo del secuenciador, (2) el número de época (que se incrementa de forma sincrónica a través de todo el
sistema de una vez cada 10 ms) y (3) todas las entradas de transacción recogidos en la que tendrán que participar
destinatario. Esto permite que cada planificador de reconstruir su propia visión de un orden transacción global intercalando
(en una, de manera determinista de round-robin) lotes todos los secuenciadores para esa época.
Para ilustrar este proceso, vamos a considerar una máquina de seis Calvin consist- despliegue ción de tres réplicas, cada uno dividido en
dos nodos. Supongamos que los clientes presentan cinco transacciones (llamémosles UNA, SI, C, RE, y MI) a la capa secuenciador durante
una época determinada (específicamente, a los nodos METRO 2 C, METRO 1 una, METRO 1 una, METRO 2 si, y METRO 2 una, respectivamente). Al final
de aquella época, conjunto de réplicas de cada partición forja un acuerdo sobre lo que debe aparecer en el lote: secuenciadores en METRO 1 una,
METRO 1 si, y METRO 1 C ponerse de acuerdo sobre un lote, con tener si entonces C, y secuenciadores en METRO 2 una, METRO 2 si, y METRO 2 C ponerse
de acuerdo sobre un lote que contiene UNA entonces
re entonces MI.
Una vez que se alcanzan estos acuerdos, la de secuencia global se considera que incluye estos lotes, adjuntas con el fin
de la partición.
BCADE
En este momento, para cada transacción en un lote, cada nodo secuenciador deriva que las particiones contienen datos
que se accede por la transacción (véase la Sección 3.2.1), y envía a cada planificador dentro de la misma réplica como el
secuenciador una lista de transacción las solicitudes de todas las transacciones en ese lote que accedan a datos locales a
ese planificador. Por ejemplo, supongamos que los registros se dividen de tal manera que la partición 1 (máquinas METRO 1 una,
METRO 1 si, y METRO 1 C) almacena los registros en la gama alfabético [Aaron, Buffy] y particiones de 2
11:10 A. Thomson et al.
(máquinas METRO 2 una, METRO 2 si, y METRO 2 C) almacena los registros en el rango [Caleb, Zeus]; y supongamos que los cuatro transacciones son
transferencias de saldo de la siguiente manera.
UNA Alicia → Valle
si Mover → Alicia
C Charles → Elise
re Valle → Elise
mi Elise → Frances
Desde la transacción si sólo accede a los registros en la partición 1, sólo se reenvía a los programadores a METRO 1 una, METRO 1 si,
y METRO 1 C. Igualmente, las operaciones C, RE, y MI, que sólo los registros de acceso en la partición 2, solamente se reenvían a la
partición 2 de cada réplica. Transacción UNA,
Sin embargo, un registro de accesos en la partición 1 y un registro en la partición 2, por lo que la solicitud se reenvía a los
programadores a ambos particiones en cada réplica.
Aquí, vemos cómo los secuenciadores de réplica una Por lo tanto, enviar solicitud de transacción lotes de la época de los
componentes del planificador. El mismo proceso se lleva a cabo independientemente en réplicas si y C también.
3.1.1. La replicación síncrona y asíncrona. Actualmente Calvin soporta dos modos para la replicación de entrada
transaccional: replicación asíncrona y la replicación síncrona basada en Paxos. En ambos modos, los nodos se organizan
en grupos de replicación, cada uno de los cuales contiene todas las réplicas de una partición particular. En el despliegue en
la Figura 1, por ejemplo, la partición 1 en réplica A y partición 1 en réplica B sería formar juntos un grupo de replicación.
En el modo de replicación asíncrona, una réplica se designa como una réplica principal, y todas las peticiones de
transacción son enviados inmediatamente a secuenciadores situados en los nodos de esta réplica. Después de compilar cada
lote, el componente secuenciador en cada nodo maestro envía el lote a todos los otros secuenciadores (esclavos) en su grupo
de replicación. Esto tiene la ventaja de latencia extremadamente baja antes de una transacción puede comenzar siendo
ejecutado en la réplica principal, a costa de la complejidad signi fi cativo en la conmutación por error. En la falta de un
secuenciador principal, acuerdo tiene que ser alcanzado entre todos los nodos en la misma réplica
y todos los miembros del grupo de replicación del nodo que ha fallado en cuanto a: (a) qué lote fue el último lote válida
enviado por el secuenciador fallado y (b) exactamente lo que las transacciones
Transacciones distribuidas Fast y la replicación consistente para sistemas de bases de datos OLTP 11:11
Figura 2. latencia promedio de transacción bajo diferentes modos de replicación de Calvino.
que contenía lotes, ya que cada programador sólo se envía la vista parcial de cada lote que en realidad se necesita con el
fin de ejecutar.
Calvin también soporta la replicación síncrona basada en Paxos de insumos transaccionales. En este modo, todos los
secuenciadores en un grupo de replicación utilizan Paxos a un acuerdo sobre un lote combinado de las solicitudes de transacción
para cada época.
implementación actual de Calvino utiliza ZooKeeper, un servicio de coordinación distribuida nación altamente confiable menudo
utilizado por los sistemas de bases de datos distribuidas por los latidos del corazón, con fi guración de sincronización, y nombrando
[Hunt y cols. 2010]. ZooKeeper no está optimizado para el almacenamiento de grandes volúmenes de datos, y puede incurrir latencias
totales más altos que la mayoría de e fi cientes posible implementaciones Paxos. Sin embargo, ZooKeeper se encarga de la necesaria rendimiento
para replicar entradas transaccionales de Calvin para todos los experimentos llevados a cabo en este artículo y, desde este
paso de sincronización no se extiende huellas de contención, el rendimiento transaccional es completamente afectado por
esta etapa de preprocesamiento. La mejora de la base de código de Calvin mediante la implementación de un protocolo
más ágil acuerdo Paxos BE- tween Calvin secuenciadores que lo que sale de la caja con ZooKeeper podría ser útil para
aplicaciones sensibles a la latencia, pero no mejoraría el rendimiento transaccional de Calvin.
La Figura 2 presenta las latencias medias de transacción para la corriente de base de código Calvin bajo diferentes
modos de replicación. Los datos anteriores se recogió usando 4 máquinas EC2 High- CPU por réplica, corriendo 40000
transacciones microbenchmark por segundo (10000 por nodo), 10% de los cuales fueron de varias particiones (véase la
Sección 7 para obtener detalles adicionales en nuestra configuración experimental). Ambos latencias Paxos informaron
utilizaron tres réplicas (12 nodos en total). Cuando todas las réplicas se realizaron en un centro de datos, el tiempo de ping
entre réplicas fue de aproximadamente 1 ms. Al replicar a través de los centros de datos, una réplica se ha ejecutado en los
centros de datos de Amazon Este de Estados Unidos (Virginia), onewas ejecutar onAmazon'sWest Estados Unidos (norte
de California) del centro de datos, y uno se ha ejecutado en el centro de datos de la UE (Irlanda) de Amazon. tiempos de
ping entre réplicas variaron de 100 ms a 170 ms.
3.1.2. Bajo aislamiento Lee y Snapshot sola partición Lee. Algunas operaciones de bases de datos de sólo lectura no necesitan
ser procesadas por el secuenciador y se insertan en el orden mundial antes de la ejecución. En particular, cuando se
garantiza una operación de lectura para acceder sólo a los datos en una sola partición, no se requiere la sincronización
entre múltiples réplicas o varias particiones para asegurarse de que el cliente ve una imagen coherente de los datos, en
lugar,
el planificador (discutido en la Sección 3.2 en breve) puede elegir un punto arbitrario en el secuenciador en el orden en que
desea ejecutar la lectura con ácido semántica (snapshot).
Por otra parte, para los clientes cuya latencia requisitos son más estrictos que sus preocupaciones de consistencia,
operaciones de sólo lectura que abarcan múltiples particiones de datos pueden ser enviados directamente a los
programadores correspondientes. Cada planificador ejecutará su parte local de la operación con la consistencia de
instantáneas, pero dado que los programadores no han comu- nicated, cada uno puede optar por realizar la instantánea leer
a partir de una versión diferente. El nivel de aislamiento que resulta el cliente observará en este caso es lectura repetible.
Observe que si el backend de almacenamiento de datos proporciona fuertes semántica multiversioning (es decir, expone
instantáneas históricas arbitrarias de datos utilizando un número de secuencia de transacción para timestamp), los clientes
pueden especificar explícitamente el número de secuencia en la que se lee de varias particiones instantánea y enviar estos
directamente a los programadores, que realizarlas en la especi fi cada instantánea de la base de datos. Si un cliente específico
es una futuro
número de secuencia, los programadores va a esperar hasta que todas las transacciones que aparecen antes en el transcurso de la
transacción se han comprometido a realizar las lecturas.
3.2. Scheduler y control de concurrencia
Everymachine en la implementación aCalvin incluye un componente de planificación. Cada planificador acepta las peticiones
de transacción transmitidos por la capa de secuenciación y los ejecuta en amanner que es equivalente a la ejecución de serie
en el especificidad orden ed por el secuenciador. Esta sección describe el protocolo de bloqueo utilizado para lograr esto
mientras que el logro de alta concurrencia.
Cuando el componente transaccional de un sistema de base de datos es desagregado de la componente de

almacenamiento, ya no puede hacer ninguna suposición sobre la puesta en imple- física de la capa de datos, y no puede
referirse a estructuras de datos físicos, como páginas e índices, ni puede ser consciente de efectos secundarios de una
transacción en la disposición física de los datos en la base de datos. Tanto los protocolos de registro y de concurrencia
tienen que ser completamente lógico, sólo se refiere a las claves de registro en lugar de estructuras de datos físicos. Por
suerte, la incapacidad para llevar a cabo el registro fisiológico no es en absoluto un problema en los sistemas de bases de
datos deterministas; desde el estado de una base de datos se puede determinar por completo desde la entrada a la base
de datos, registro lógico es sencillo (la entrada se registra por la capa de secuenciación,
Sin embargo, sólo tener acceso a los registros lógicos es ligeramente más problemático para el control de la moneda con-,
ya que el bloqueo rangos de teclas y ser robusto a las actualizaciones de trazos típicamente requieren acceso físico a los datos.
Para manejar este caso, Calvino podría utilizar un enfoque propuesto recientemente para otro sistema de base de datos
desagregado mediante la creación de recursos virtuales que se puede bloquear de forma lógica en la capa transaccional [Lomet
y Mokbel 2009], aunque la implementación de esta función sigue siendo el trabajo futuro.
administrador de bloqueos determinista de Calvin se reparte a través de toda la capa de la programación, y el planificador de cada
nodo sólo es responsable de los registros que se almacenan en el almacenamiento de ese nodo componente, incluso para las
transacciones que acceden a los registros almacenados en otros nodos de bloqueo. El protocolo de bloqueo se asemeja estricta
bloqueo de dos fases, pero con dos invariantes añadido.
- Para cualquier par de las transacciones α y β solicitar que ambos bloqueos exclusivos en algunos discos local R, si la
transacción α aparece ante β en el orden de serie proporcionado por la capa de secuenciación entonces α debe solicitar su
bloqueo en R antes de β hace. En la práctica, Calvin implementa este serializando todas las solicitudes de bloqueo en un solo
hilo. El hilo escanea el orden transacción en serie enviada por la capa de secuenciación; para cada entrada de, solicita de
todos los bloqueos que necesitará la transacción en su vida. (Todas las transacciones son por lo tanto
requerido para declarar su completo de lectura / escritura conjuntos de antemano; Sección 3.2.1 discute las limitaciones entrañan.)
- El gestor de bloqueos debe conceder cada cerradura de solicitar transacciones estrictamente en el orden en que esas
solicitudes de transacciones de la cerradura. Así, en el ejemplo anterior, β
no podía ser otorgado su bloqueo en R hasta después de α ha adquirido la cerradura de R, ejecutado hasta su finalización, y
liberado el bloqueo.
Los clientes especifican lógica transacción como funciones de C ++ que pueden acceder a los datos utilizando una interfaz básica
CRUD. Código de transacción no tiene por qué ser en absoluto conscientes de partición (aunque el usuario puede especificar cómo
en otros lugares claves deben ser divididos a través de máqui- nas), ya que Calvin intercepta todos los accesos a datos que
aparecen en el código de transacción y realiza todo el resultado de lectura remota reenviar automáticamente.
Una vez que una transacción ha adquirido todos sus cerraduras bajo este protocolo (y por lo tanto puede ser ejecutado de
forma segura en su totalidad) se traspasa a un subproceso de trabajo a ser ejecutado. Tenga en cuenta que, dado que cada
programador sólo gestiona las cerraduras de sus propios datos locales, cada transacción distribuida en realidad pasa por el
proceso de programación completa de forma independiente en cada nodo participante, y todos los participantes ejecuten de forma
independiente de toda lógica en la transacción.
Cada ejecución real de la transacción por un trabajador procede de rosca en cinco fases.
(1) Leer / escribir el análisis conjunto. Lo primero que un hilo de ejecución de la transacción cuando se hace
entregado una solicitud de transacción es analizar leer y escribir conjuntos de la transacción, teniendo en cuenta: (a) los
elementos de la lectura y escritura conjuntos que se almacenan localmente (es decir, en el nodo en el que se está
ejecutando el hilo), y (b) el conjunto de nodos en los que se almacenan los elementos del conjunto de escritura
participantes. Estos nodos se denominan participantes activos en la transacción; nodos participantes en el que sólo se
almacenan elementos del conjunto de lectura son llamados participantes pasivos.
(2) Realizar lecturas local. A continuación, el subproceso de trabajo busca los valores de todos los registros de
el conjunto de lectura que se almacenan localmente. Dependiendo de la interfaz de almacenamiento, esto puede significar hacer
una copia del registro a un búfer local, o simplemente guardar un puntero a la ubicación en la memoria en la que el registro se
puede encontrar. (3) Servir a distancia lee. Todos los resultados de la fase de lectura locales se envían para contrarrestar
subprocesos de trabajo en cada terpart activamente nodo participante. Desde participantes pasivos no modifican los datos,
no es necesario ejecutar el código de transacción real, y por lo tanto no tienen que recoger ningún resultado lectura remota. Si
el subproceso de trabajo se está ejecutando en un nodo participar pasivamente, entonces es terminado después de esta fase.
(4) Recoger los resultados leídos a distancia. Si el subproceso de trabajo se está ejecutando en una forma activa partici-
nodo Pating, entonces debe ejecutar código de transacción, y por lo tanto primero debe adquirir la totalidad leer los
resultados tanto de los resultados de locales lee (adquirida en la segunda fase) y los resultados de remoto lee (transmitida
apropiadamente por cada nodo participante durante la tercera fase ). En esta fase, el subproceso de trabajo recoge el
segundo conjunto de resultados de lectura. (5) ejecución de la lógica de transacciones y escrituras que solicitan. Una vez que
el subproceso de trabajo tiene COL-
cionado Todos los leídos resultados, se procede a ejecutar toda la lógica de la transacción, la aplicación de cualquier local
escribe. escrituras no locales pueden ser ignoradas, puesto que serán vistos como escribe local por el hilo de
ejecución operación de contrapartida en el nodo apropiado, y se aplican allí.
Suponiendo una transacción distribuida comienza a ejecutar en aproximadamente el mismo tiempo en cada nodo
participante (que no es siempre el caso-esto se discute en mayor detalle en la Sección 7), todas las lecturas se producen en
paralelo, y todos los resultados leídos a distancia se suministran
en paralelo, así, sin necesidad de subprocesos de trabajo en diferentes nodos para solicitar datos de uno al otro en el tiempo
de ejecución de la transacción.
Para ilustrar esto, vamos a revisar el ejemplo hemos introducido en la Sección 3.1 anterior. 4 llamada re que cinco
transacciones de transferencia de saldo se presentaron y se les asigna la siguiente secuencia.
TXN secuencia leer escribir participativo

número carné de identidad conjunto particiones
1 si Bob, Alice 1
2 C Charles, Elise 2
3 UNA Alice, Dale 1, 2
4 re Dale, Elise 2
5 mi Elise, Frances 2
Por lo tanto, la partición de 1 programador ha recibido la solicitud por lotes
licenciado en Letras
para esta época, el planificador y la partición de 2 ha recibido el lote siguiente.
CADE
administrador de bloqueos de cada programador procesa estas solicitudes, sumando todas las solicitudes de bloqueo que va a
necesitar en cada transacción almacenado localmente archivos. En la partición 1, primer plano allí-, el primer gestor de bloqueo fi añade
solicitud de bloqueo para la transacción si en los registros de Alice y Bob, que se concedió inmediatamente. Transacción si se entrega a
un subproceso de trabajo para su ejecución. El gestor de bloqueos a continuación, añade la transacción UNA 'S bloqueo solicitud de
registro Alice- pero no para el registro Dale, también se accede por UNA, desde LockManager de cada nodo sólo se ocupa de bloqueo local
archivos. Ya que si ya tiene un bloqueo en Alice, UNA no se concede la cerradura, y por lo tanto todavía no comenzar la ejecución.
Mientras tanto, administrador de bloqueos partición de 2 añade solicitudes de bloqueo para C, UNA, RE, y mi como sigue.
- C 's solicitudes de bloqueo para Charles y Elise se conceden de inmediato, por lo C comienza ción ejecu- en un subproceso de
trabajo.
- UNA 's local solicitud de bloqueo para Dale se concede de inmediato, por lo que un subproceso de trabajo comienza a funcionar UNA también.
- re 's solicitudes de bloqueo para Dale y Elise tanto fallan, ya que estas cerraduras ya están en manos de UNA
y C, respectivamente. re aún no se traspasa a un subproceso de trabajo a ejecutar.
- mi solicitud de bloqueo 's por Frances se concede, mientras mi 'S solicitud de bloqueo para Dale falla. Dado que no ha adquirido todos los
bloqueos, mi También no comienza la ejecución de un subproceso de trabajo.
En este punto, si ha empezado a ejecutar en la partición 1, y C y UNA han empezado a ejecutar en la partición 2.
4 Dado que todas las réplicas ya han acordado solicitud de transacción de pedidos para la época en cuestión, el resto de la tubería de ejecución no requiere
comunicación entre réplica. Por lo tanto, examinamos aquí cómo avanza la ejecución dentro de una única réplica.
Veamos primero examinar lo que sucede en la partición 2 durante las cinco fases de ejecuciones
C y A.
- Transacción C. Fase 1 (leer el análisis conjunto / escritura) determina que la partición 2 es el único participante activo en
la transacción, y no hay participantes pasivos. En la fase 2 ( locales lee), C 'Hilo sworker lee registros Charles andElise.
Fases 3 y 4 (servir lee remoto, y recoger resultados de lectura a distancia) son no-ops, desde la partición 2 es C Es por
único participante. En la fase 5, C se ejecuta 's lógica transacción (utilización de los resultados de lectura de la fase 2), y
su escritura se instalan en la base de datos.
- Transacción A. Fase determina que las particiones 1 1 y 2 son dos participantes activos en A. En la fase 2, UNA 'S
subproceso de trabajo lee el local recordDale, y en la fase 3, difunde el valor de registro Dale a todos los demás participantes
-en este caso partición 1. En la fase 4, que recoge los resultados de lectura de registro Alice partición de 1. Pero recordar
que UNA no se ha iniciado la ejecución de embargo en la partición 1, porque si celebrada el bloqueo que necesitaba.
Partición de 2 bloques de los subprocesos de trabajo en este punto, a la espera de ese resultado. 5
En este punto, C haya ejecutado hasta el final en la partición 2. Por lo tanto, libera sus bloqueos en los registros de Carlos y Elisa.
Tenga en cuenta que tanto re y mi tienen pendientes solicitudes de bloqueo en expediente Elise. Nótese también que re también
se bloquea en espera de registro Dale, en tanto mi ya ha adquirido la totalidad de sus otras cerraduras y sería capaz de ejecutar
de inmediato si se concede un bloqueo en Elise. Por lo tanto, A (no determinista) administrador de bloqueos tradicional podría
conceder la cerradura de Elise mi con el fin de maximizar la concurrencia. Sin embargo, este comportamiento no sería emular
ejecución en serie en el orden determinado secuenciador BCADE, ya que mi
sería explícitamente leer, modificar, ficha andwrite Elise antes re hizo. Por lo tanto, el mecanismo de bloqueo determinista
de Calvin otorga el bloqueo de Elise a la siguiente transacción que ha solicitado, a saber, RE.
5 Si el resultado de leer a distancia no se ha recibido dentro de un intervalo de tiempo especi fi cado, la partición solicitará activamente. Partición 1 examinará
su reciente registro de red y vuelva a enviar el resultado. Si continúa no llegar (por ejemplo, porque la partición de la réplica local 1 se estrella), partición 2 lo
solicitará de la partición de otra réplica 1.
Ahora vamos a revisar la partición 1. Mientras C ejecutado hasta su finalización en partición 2 (y UNA
fue a través de sus tres primeras fases de ejecución), si comenzó de ejecución en la partición 1. si
ejecuta hasta su finalización, sin tener que coordinar con cualquier otro participante (así las fases 2 y 3 son no-ops) y libera
su cerraduras. UNA se concede entonces su bloqueo en Alice y se deja que comience a ejecutar en la partición 1 también.
En partición 1, UNA 'S subproceso de trabajo descubre en la fase 1 que es uno de los dos participantes activos. Se lee
registro de Alice en la fase 2, y envía el resultado a la partición 2 en la fase 3. En la fase 4, que recoge el resultado de
lectura remota que ya fue enviada a él por
UNA 'S subproceso de trabajo en la partición 2 en sus Fase 3. Ahora, con pleno conocimiento de UNA 'S Lectura del registro, se
procede con la fase 5 y ejecuta UNA 'S lógica transacción. Cuando se va a aplicar las escrituras (recordemos que UNA actualiza los
registros de Alicia y Dale), sólo se aplica a los que son locales: se actualiza el registro Alice y deja caer su escritura para grabar Dale.
Los comunicados de gestor de bloqueos UNA 'S cerradura de Alice, y UNA ahora se ha completado en la partición 1.
Cuando el UNA 'S subproceso de trabajo en la partición 2 recibe el valor de Alice que se acaba de enviar desde 1, que ahora tiene el
pleno conocimiento de UNA 'S Lectura del registro y puede correr fase 5. Desde UNA 'S lógica transacción es determinista dado la
misma lectura establecido, UNA 'S ejecución en la partición 2 será un reflejo de su ejecución a 1, pero a la partición 2 únicamente la
actualización del registro Dale será aplicado.
Una vez UNA cerradura 's en el registro de Dale se libera, re hereda y ejecuta hasta su finalización, después de lo cual mi finalmente
se concedió su bloqueo en el registro de Frances y ejecuta hasta su finalización, así.
3.2.1. Transacciones dependientes. performreads Transactionswhichmust con el fin de determinar sus completo de lectura /
conjuntos (que denominamos transacciones dependientes) no son compatibles de forma nativa en Calvin desde determinista
protocolo de bloqueo de Calvin requiere conocimiento previo de todas las transacciones de lectura / escribir conjuntos antes
de la ejecución de transacciones puede comenzar. En su lugar, Calvin apoya un esquema llamado bloqueo optimista
Ubicación Predicción (OLLP), que puede ser implementada a muy bajo coste de arriba modificando el cliente transac- ción
código en sí [Thomson y Abadi 2010]. La idea es que las transacciones dependientes a ser precedidas por una, bajo el
aislamiento de bajo costo, no replicado, de sólo lectura reconocimiento
consulta que realiza todas las lecturas del necesario descubrir conjunto de lectura / escritura de la transacción. los real transacción
se envía a continuación, que se añade a la secuencia global y ejecutados, utilizando los resultados de la consulta de
reconocimiento por su conjunto de lectura / escritura. Debido a que es posible que los registros leídos por la consulta de
reconocimiento (y por lo tanto conjunto de lectura / escritura de la transacción real) que han cambiado entre la ejecución de la
consulta reconocimiento y la ejecución de la transacción real, los resultados de lectura es necesario reanalizar y el proceso
puede tener que ser (de manera determinista) reinicia si el “reconnoitered” lectura del registro / escritura ya no es válida.
Particularmente común dentro de esta clase de transacciones son los que deben realizar búsquedas de índices
secundarios con el fin de identificar sus conjuntos de lectura / escritura. Dado que los índices secundarios tienden a ser
relativamente caro para modificar, rara vez se mantienen en campos cuyos valores se actualizan muy frecuentemente.
índices secundarios en “artículo de inventario
nombre ”O“de la Bolsa de Nueva York símbolo ”, Por ejemplo, sería común, mientras que sería inusual para mantener un
índice secundario en campos más volátiles, tales como“elemento de inventario cantidad ”O“valores NYSE precio ”. Uno por
lo tanto, espera que el esquema de OLLP rara vez se traduzca en transacciones repetidas cargas de trabajo se reinicia en
el mundo real bajo más comunes.
Tipo de “pago” transacción del punto de referencia TPC-C es un ejemplo de esta subclase de transacción. Y puesto que la
carga de trabajo de referencia TPC-C Nunca modi fi ca el índice en el que las transacciones de pago leen sistemas / escritura
puede depender, las transacciones de pago no tienen que ser reiniciado cuando se utiliza OLLP.
En la Sección 7.4, examinamos el rendimiento y las características de latencia cuando se utiliza OLLP en las cargas de trabajo que
contienen las transacciones dependientes bajo una serie de condiciones, en ticular par- cuando variamos la velocidad de actualización
del índice secundario en el que leen y escriben conjuntos dependen de las transacciones.
4. Transacciones del lado del servidor amistoso con el desarrollador
La mayoría de los sistemas de bases de datos comercialmente disponibles permiten transacciones a ser definido y ejecutado en la forma de
cualquiera de las transacciones del cliente especial o procedimientos almacenados en el servidor.
Incorporación de transacciones del lado del cliente en el código de la aplicación es muy conveniente para los desarrolladores
y por lo general lleva a código muy legible, fácil de mantener. Por ejemplo, el lado izquierdo de la Figura 3 muestra un simple
transacción de transferencia de equilibrio en una aplica- ción Python. Aquí, cuando la aplicación llama al Transferencia de saldo función,
una secuencia de interacciones sincrónicas con el sistema de base de datos se producen, a partir de una solicitud de “iniciar la
transacción”, y terminando con una acción de “confirmar la transacción”. Elegimos este sencillo
Transferencia de saldo transacción como un ejemplo aquí, ya que representa un transaccional modismo-an “interacción”
extremadamente comunes entre dos o más objetos bases de datos que no se espera que se almacene en el mismo partición en
la que los registros correspondientes a ambos objetos se leen, modi fi ed, y escrita. Es fácil imaginar las acciones trans muy
similares que aparecen en una aplicación de financiar (por ejemplo, como un comercio de valores), en una aplicación de
comercio electrónico (por ejemplo, como un cliente que paga un saldo pendiente), en un juego en línea multi-jugador masivo
(por ejemplo, como un jugador que compre una espada mágica de otro jugador), en una aplicación de mensajería (por ejemplo,
como un usuario envía un mensaje a otro) y así sucesivamente.
Alternativamente, la aplicación de una transacción tal como Transferencia de saldo como un procedimiento almacenado en un DBMS
probablemente resultaría en un rendimiento superior. Los procedimientos almacenados son generalmente más rápido que las transacciones
del cliente ad hoc, por dos razones.
(1) Los procedimientos almacenados están precompilados y se guardan por el DBMS. Cada invocación real
Por lo tanto, se salta los pasos tales como el análisis de SQL, la planificación de consulta, etc.
Fig. 3. Un ejemplo de transacción del lado del cliente (lado izquierdo). Una simplemethod de la ejecución de este lado del servidor de transacciones sería que el
desarrollador para poner el fragmento de código en una cadena y la cadena de enviar al servidor de base de datos, en el que podría ser interpretado como una
transacción (lado derecho).
(2) Las operaciones que involucran múltiples sentencias SQL con la lógica de aplicación en BE-
Tween no requieren múltiples mensajes de ida y vuelta entre el servidor de aplicaciones y el sistema de base de datos. Esto
disminuye la latencia global y cuesta-IO pero la red es más importante, que significativamente reduce la huella total de las
transacciones de contención. Sin embargo, los procedimientos almacenados vienen con costos adicionales con respecto a
codificar complejidad. La implementación de la transacción mencionada anteriormente como un procedimiento almacenado
requeriría los siguientes pasos adicionales.
(1) Traducir el código de transacción a cualquier lenguaje de programación se utiliza para

procedimientos almacenados en la DBMS siendo utilizados. (2) Registrar la
transacción con el sistema de base de datos.
(3) invocar el procedimiento almacenado utilizando el nombre y los argumentos de procedimiento almacenado.
Si bien esto suena bastante simple, cada uno de estos pasos puede implicar significantes complejidad. En primer lugar, las lenguas para
la implementación de los procedimientos almacenados varían drásticamente entre los sistemas de bases de datos, haciendo aplicaciones
que dependen de los procedimientos almacenados significativamente menos portable y requiere que los desarrolladores familiarizados con
los lenguajes fi cas especí-DBMS adicionales y características.
Fig. 4. El método natural de de fi nir una transacción de Calvin es extender el resumen Txn clase. Esto se traduce en un rendimiento muy alto, pero puede ser
difícil para los desarrolladores de razonar acerca y puede hacer que la depuración de aplicaciones más complejas.
El segundo paso, registrando el procedimiento debe llevarse a cabo cada vez que el apli- cación se modi fi cada,
construido, o desplegado. Esto puede introducir desafíos particulares en la implementación de aplicaciones a gran escala,
donde las actualizaciones de aplicaciones suceden de una manera “balanceo” en lugar de forma sincrónica a través de todo
el despliegue.
En tercer lugar, las pruebas de aplicaciones y depuración se puede hacer mucho más di fi culto cuando se utilizan procedimientos
almacenados en el lugar de realización del lado del cliente por varias razones. (1) los registros del lado del servidor error / excepción debe ser
fusionaron con los registros de salida de la aplicación para conseguir

una visión clara de los errores que se produjeron dentro de la transacción.
(2) Pruebas de lógica de la aplicación que aparece dentro de una transacción requiere un completo
implementación de base de datos. Esto puede hacer que la unidad de pruebas de aspectos individuales de transac- ción
comportamiento significativamente más duro que para las transacciones del cliente. (3) Cuando se ejecuta la aplicación en un depurador
(por ejemplo, AP para una aplicación Python),
código dentro del procedimiento almacenado no puede ser examinada en una ejecución paso a paso. Como se discutió en
la sección 2, el protocolo de ejecución de la transacción de Calvin requiere lógica transacción a ser definido antes de ejecutar la
transacción, y anotado con lectura de la transacción / escribir conjuntos (ya sea por el usuario, a través de análisis de código
estático, o como resultado de la fase de reconocimiento para la transacción dependiente). Con el fin de lograr este objetivo y
obtener las ventajas de rendimiento de los procedimientos almacenados, se implementó Calvin tal que el modo “nativo” para las
transacciones de fi nición es como una extensión de una clase de C ++; un módulo que contiene fi transacciones NED-de usuario
está vinculado con Calvin en la acumulación / hora del sistema de despliegue (Figura 4). Si bien estos procedimientos
almacenados son extremadamente rápida de ejecutar debido a su simplicidad, la implementación de las transacciones de esta
manera claramente viene con todos los inconvenientes de los procedimientos almacenados que se aplica en los DBMS
disponible en el mercado. De hecho, las restricciones y problemas con este modelo son considerablemente peor por varias
razones.
(1) La modificación o adición de clases de transacción requiere todo el sistema de base de datos para ser
derribados, reconstruido, y redistribuido. (2) Si un usuario-de fi nido MyTxn :: Execute () invoca la función de cualquier
programa no determinista
lógica (por ejemplo, generación de números aleatorios, el acceso reloj del sistema), estado de réplica puede divergir.
(3) código de transacción Buggy funcionamiento completamente sin zona de pruebas en C ++ puede bloquearse, parada,
o corrupto todo el sistema de base de datos. Hemos observado mientras se implementan los experimentos en este
artículo que el código de transacción malo puede interactuar con la lógica del sistema de base de datos para causar
problemas que son difíciles y requiere mucho tiempo de depurar. Tenga en cuenta, sin embargo, que el invariante
requerido por transacción de Calvin programación de protocolo no es que cada transacción debe ser un procedimiento
almacenado, sino más bien que la lógica de cada transacción y leer sistemas / escritura debe ser conocida de antemano
de inicio ejecu- ción de ese particular, transacción. Para demostrar que los sistemas de programación de transacciones y
replicación de Calvino se pueden hacer para trabajar en entornos en los que los desarrolladores de aplicaciones
normalmente prefieren a de las transacciones del cliente definir más simples, ideamos un conjunto de herramientas para
la toma de la ejecución de transacciones en el servidor menos dolorosa para los desarrolladores.
4.1. Las transacciones del lado del servidor sin procedimientos almacenados
La idea básica es la de permitir que las aplicaciones envíen fragmentos de código en el sistema de base de datos, que
puede ser interpretado y ejecutado en-el-mosca (por ejemplo, por un intérprete de Python ded embed-) en la base de datos
de servidor con plena replicación y la transacción garantías. La forma más obvia de la implementación de las transacciones
de fragmento sería proporcionar una llamada a la API
ExecAsTxn (<CODE-SNIPPET>)
permitiendo que el desarrollador de aplicaciones simplemente construir y presentar una cadena que contiene el fragmento de código
Python-exactamente como aparecería si se implementa como una transacción de cliente. El lado derecho de la Figura 3 muestra
cómo nuestro ejemplo Transferencia de saldo acción trans puede ser implementado utilizando este sistema. En este caso, se
requiere muy poco trabajo por parte de los desarrolladores para convertir una transacción de cliente en una transacción del lado del
servidor.
Este método de construcción y el envío de fragmentos de código para la ejecución del lado del servidor todavía viene con algunos
inconvenientes, sin embargo, como se detalla a continuación.
(1) No IO local o remoto (por ejemplo, la lectura / escritura de archivos, la comunicación con otros servidores,
etc.) se podría permitir en el fragmento de código.
(2) El fragmento de código no sería capaz de hacer referencia a las variables o funciones globales
de fi ne en la aplicación en otros lugares.
(3) El desarrollador de aplicaciones tendría que construir de forma explícita cadenas que contienen
fragmento de código en lugar de de fi nir las funciones directamente.
Algunos de estos temas (IO remotas limitaciones, en particular) son inherentes a la garantía determinismo de Calvin. Sin
embargo, es posible hacer frente a estos otros temas para que este esquema de ejecución de fragmentos de código como
transacciones más usables. En particular, hemos ideado un módulo de Python que utiliza re fl apoyo de Python reflexión
para acceder y analizar el código de la aplicación plena y enviar selectivamente la información adecuada para el sistema de
base de datos para su ejecución. Python expone explícitamente el código para cada función y método, por lo que siempre es
posible en tiempo de ejecución para buscar este código. Así que si una función
MyClass.MyFun se de fi nida
1: MyClass clase: 2:
MyFun def (self): 3:
imprimir 'Hola, mundo!'
en src / example.py, entonces, además de llamar a la función,
> > > MiClase (). MyFun () Hola,

mundo!
Transacciones distribuidas Fast y la replicación consistente para sistemas de bases de datos OLTP once y veintiún
también se puede buscar el fi precisa archivo y número de línea donde se de fi nida.
> > > MyClass.MyFun.func_code.co_filename 'src / example.py'
> > > MyClass.MyFun.func_code.co_firstlineno 2
Usamos esto para permitir a los desarrolladores de aplicaciones para escribir lo que parece ser una transacción de cliente que
todavía se puede ejecutar en el servidor. Para reanudar nuestro ejemplo anterior, el uso de esta biblioteca, se podría poner en
práctica el Transferencia de saldo transacción como se muestra a la izquierda en la Figura 3, pero que luego invocarlo llamando a la
siguiente.
ExecAsTxn (BalanceTransfer, "bob" "alice",, 10)
más bien que
BalanceTransfer ( "alice", "bob", 10)
Un pabellón mundial determina si el ExecAsTxn hace que el Transferencia de saldo función a ser llamada lado del cliente (es decir,
directamente por la máquina que ejecuta el código de aplicación) o del lado del servidor (es decir, por el servidor de base de datos).
Esto está diseñado para que sea muy fácil para cambiar entre las transacciones del lado del cliente (que puede ser más fácil de probar y
depurar) y las transacciones del lado del servidor. Si el pabellón se establece en la ejecución del lado del cliente, ExecAsTxn simplemente
llama a la función y vuelve fi cado. Si el pabellón se establece en la ejecución del lado del servidor, ExecAsTxn
realiza varias tareas.
(1) El apoyo de Python para La reflexión se utiliza para identificar la fuente de Python expediente en el que
el cuerpo de la función está definida de. 6
(2) El cuerpo de la función se analiza y se analizan en busca de la siguiente.
(una) Usos de Python hora o aleatorio módulos. Si cualquiera de estos parece, ExecAsTxn
graba la hora del sistema del servidor de aplicación actual para el servidor de base de datos para su uso
posterior en lugar de su propia hora del sistema (incluyendo el uso como la semilla determinista por defecto para la
generación de números pseudo). (si) no deterministas operaciones prohibidas como froma lectura fi l o realizar
red I / O. En este caso, se genera un error. (Tenga en cuenta que escritura a está permitido-cuando un fi le durante
una transacción de ejecución se produce en el servidor de base de datos, escribe puede ser tamponada a ser
devuelto al cliente y se aplica después.) (c) Las referencias a las variables globales y funciones nonbuilt-in que se
definen else-
lugar de la aplicación.
(3) Si el cuerpo de la función hace referencia a las variables globales, sus valores actuales son
registrado para enviar al servidor de base de datos. 7
(4) Si el cuerpo de la función llama cualquier función nonbuilt-in, ExecAsTxn per- recursiva
forma un similares de búsqueda-de análisis sintáctico-scan-analizar procedimiento en los cuerpos de esas funciones. (5) Otra
información contextual adicional, tal como la versión intérprete Python, activo
fl compilador banderas, etc., se registran entonces, y todos los datos necesarios para duplicar ejecución de la función se compila en una
secuencia de comandos de Python se envía al servidor de base de datos.
6 Esto es muy fácil de hacer en lenguajes interpretados como Python, Perl y Ruby debido al tiempo de ejecución de re fl exión de apoyo. Para aplicaciones
escritas en lenguajes compilados con muy diferentes entornos de ejecución, por ejemplo, C ++ y Java, estructuras de datos adicionales tendrían que ser
construido y guardado en la compilación ción y enlaces de tiempo con el fin de hacer esto posible. Si bien esto puede introducir adicional de aplicación di fi
cultad, el enfoque general sería el mismo para estos idiomas.
7 Esto sólo se garantiza que sea posible para las variables globales de tipo razonablemente simple como números enteros, cadenas, estructuras básicas, y
otros tipos que son explícitamente serializable. Esto podría representar una limitación significativa de este sistema cuando se aplica para los idiomas de
aplicación tales como Haskell, en los que la evaluación perezosa es comúnmente utilizado para construir en estructuras de datos finito.
La servidor de base de datos que recibe la petición puede entonces tratarlo como cualquier otra transacción dependiente, 8 excepto
que cuando las manos del programador de Calvino la transacción fuera de un hilo de ejecución, ese hilo pone en marcha un
intérprete de Python incrustado a ejecutar el código enviado por ExecAsTxn en vez de invocar un procedimiento almacenado.
Sobre la terminación de la transacción, la fi NotI sistema de base de datos ca el cliente de: (a) la confirmación / abortar estado de
la transacción, (b) cualquier fi le sucesos de salida que se han producido (tales como el registro de depuración), y (c) la fi estados
nales de las variables globales que eran modi fi cado por el código de transacción.
La Figura 5 ilustra este proceso dado una aplicación extendida de la

Transferencia de saldo transacción descrita antes, que tiene acceso a las variables globales y funciones externos, escribe
la salida a archivos, y hace uso de Python hora y aleatorio
módulos.
En general, encontramos que las transacciones de bases de datos fi nición que utilizan este esquema parece y se siente como el uso
de transacciones de bases de datos del lado del cliente estándar. Nuestra idea es que esto podría ser un útil conjunto de herramientas
en el diseño de futuros sistemas APIs- desarrollador de bases de datos, independientemente de si la ejecución del lado del servidor es
crítico para apoyar transacciones o simplemente deseables para mejorar el rendimiento.
5. Calvin las unidades de disco BASADOS
Nuestro trabajo previo en los sistemas de bases de datos deterministas llegó con la advertencia de que la ejecución
determinista sólo funcionaría para bases de datos residentes en su totalidad en la memoria principal [Thomson y Abadi 2010]. El
razonamiento era que una de las principales desventajas de los sistemas de bases de datos determinista con respecto a los
sistemas tradicionales no deterministas es que los sistemas no deterministas son capaces de garantizar la equivalencia de alguna
orden serial, y puede, por tanto, arbitraria reordenar las transacciones, mientras que un sistema como Calvin se ve obligado a
respetar el orden que el secuenciador elige.
Por ejemplo, si una transacción (llamémosla UNA) está estancado a la espera de un acceso al disco, un sistema tradicional
sería capaz de ejecutar otras operaciones ( si y C, decir) que no conflicto con las cerraduras ya posean A. Si si y C 'S escribir
conjuntos solapados con UNA 'S en las teclas que UNA aún no se ha bloqueado, entonces la ejecución puede proceder de
manera equivalente a la orden serial si - C - UNA más bien que UNA - si - C. En un sistema determinista, sin embargo, si y
C tendría que bloquear hasta UNA terminado. Peor aún, otras transacciones que con infligido con si y C -pero no con UNA También, no
tuvimos suerte quedó atrapado detrás A. En-el-mosca reordenamiento por lo tanto, es altamente eficaz en la maximización de la
utilización de recursos en los sistemas donde los puestos de disco más de 10 ms se pueden producir con frecuencia durante la ejecución
de la transacción.
Calvin evita este inconveniente de determinismo en el contexto de las bases de datos basadas en disco, siguiendo su
principio rector de diseño: se mueven tanto como sea posible el trabajo pesado a más temprano en el procesamiento de
transacciones tubería, antes de que se adquieren bloqueos.
En cualquier momento un componente secuenciador recibe una solicitud para una transacción que puede incurrir en una
cabina de disco, se introduce un retardo fi artificial antes de reenviar la solicitud de transacción a la capa de programación y
mientras tanto envía solicitudes para todo el almacenamiento relevante componentes para “calentar” el disco -Residente registros
que accederá a la transacción. Si el
8 Dado que la lectura y escritura conjuntos no son especí fi cado por el código Python presentado, por lo general se requiere una etapa de reconocimiento para
determinar su membresía antes de comenzar la ejecución de transacciones. Ver la Sección 3.2.1 para una discusión adicional del procedimiento OLLP utilizado
para el manejo de transacciones dependientes. En algunas transacciones donde los registros siempre son fi identificado por la clave primaria, cierto análisis
sintáctico puede ser ciente fi suf para permitir el paso de reconocimiento para ser omitido. En particular, existen herramientas desarrolladas en la comunidad de
investigación lenguajes de programación (principalmente para fines de veri fi cación de seguridad de código) que hacen un seguimiento de todas las dependencias
de variables. Si, mediante una herramienta de este tipo, las claves primarias de los registros que se accede pudieron determinarse no depender de los resultados
de la base de datos anterior accesos dentro de la transacción, pero sólo en cantidades conocidas a priori, como constantes de cadena explícitas y argumentos de la
función, entonces la lectura y escritura conjuntos podía deducirse a través del análisis puramente sintáctica. La plena aplicación de dicha herramienta permanece
como trabajo futuro, sin embargo.
Fig. 5. Una transformación de código ejemplo como se lleva a cabo por ExecAsTxn. El cuadro de la izquierda muestra una transacción (una versión más
compleja de la Transferencia de saldo transacción muestra en la Figura 3) definida como una función de Python de cliente que: (a) hace uso de variables y
funciones globales; (B) utiliza Python de hora y aleatorio módulos; y (c) escribe la salida a un archivo. Cuando la transacción se invoca utilizando ExecAsTxn, la
fuente de fi Python le es examinada y el fragmento de código en el cuadro de la derecha se produce y se envía al servidor de base de datos para ser
ejecutado.
arti fi cial de retardo es mayor que o igual al tiempo que se necesita para llevar a todos los registros de residentes en disco en la
memoria, a continuación, cuando la transacción se ejecuta realmente, se accederá únicamente los datos residentes en memoria.
Tenga en cuenta que con este esquema la latencia general de la transac- ción no debe ser mayor de lo que sería en un sistema
tradicional, donde el disco IO
se llevaron a cabo durante la ejecución (ya que exactamente el mismo conjunto de operaciones de disco se producen en cualquiera de los casos),
pero ninguno de la latencia de disco se suma a la huella de la afirmación de la transacción.
Para demostrar claramente la aplicabilidad (y dificultades) de esta técnica, hemos implementado un sencillo sistema de
almacenamiento basado en disco de Calvin en la que los registros “fríos” son POR ESCRITO a la fi sistema local LE y de
sólo lectura en la memoria-principal de Calvino residente tabla de clave-valor cuando sea necesario por una transacción. Al
ejecutar 10.000 transacciones microbenchmark por segundo por la máquina (véase la sección 7 para más detalles sobre la
configuración experimental), el rendimiento transaccional total del Calvin no se vio afectada por la presencia de las
transacciones que tienen acceso a almacenamiento basado en disco, siempre y cuando no más de 0,9% de transacciones
(90 de cada 10.000) están en el disco. Sin embargo, este número es muy dependiente del hardware en particular con fi
guración de los servidores que se utilizan. Nos encontramos con nuestros experimentos en el hardware de los productos
básicos com- gama baja, rendimiento de disco local (en lugar de huella de contención). Dado que la carga de trabajo
involucrado microbenchmark accesos aleatorios a una gran cantidad de diferentes archivos, 90 operaciones de disco por
segundo por el acceso a la máquina fue su fi ciente para convertir el disco de acceso aleatorio rendimiento en un cuello de
botella. Con matrices de discos de gama más alta (o con la memoria fl ash en lugar de disco magnético) muchas
transacciones más basados en disco podrían ser apoyados sin afectar rendimiento total en Calvin.
Para un mejor potencial de understandCalvin para interfacingwith otras configuraciones de disco fi, fl ash, almacenamiento de bloques
en red, etc., también implementado un motor de almacenamiento en el que los datos “fríos” se guardan en la memoria en una máquina
separada que podría ser con fi gurado para servir las peticiones de datos sólo después de una prespeci retardo fi ed (para simular la red o
latencia de acceso Storage-). Utilizando esta configuración, se encontró que cada máquina era capaz de soportar la misma carga de
10.000 de transacciones por segundos, sin importar howmany de estas transacciones accede a los datos de equilibrio “frías” bajo
extremadamente alta contención (índice de contención = 0,01). Se encontraron dos retos principales en la conciliación de la ejecución
determinista con el almacenamiento basado en disco. En primer lugar, las latencias de disco deben predecirse con precisión para que las
transacciones se de- nos extienden por la cantidad apropiada de tiempo. En segundo lugar, la capa secuenciador de Calvino debe acu-
rado un seguimiento de las teclas que se encuentran en la memoria a través de todos los nodos de almacenamiento con el fin de
determinar cuándo es necesaria la obtención previa.
5.1. / S de disco latencia Predicción
Predecir con precisión el tiempo necesario para buscar un registro del disco a la memoria no es un problema fácil. El tiempo que se
tarda en leer un residente de disco puede variar de forma significativa por muchas razones:
- distancia física variable para la cabeza y el husillo para mover;

- antes en cola / S de disco operaciones;
- latencia de la red para remoto lee;
- conmutación por error de los fallos de los medios de comunicación;
- múltiples operaciones de E / S requeridos debido a atravesar una estructura de datos basada en disco (por ejemplo, un B + árbol).
Por tanto, es imposible predecir la latencia a la perfección, y cualquier heurística utilizado a veces dar lugar a una
subestimación ya veces en una sobreestimación. S de disco mación latencia estimación resultó ser un parámetro
particularmente interesante y crucial cuando se sintoniza Calvin para un buen desempeño en los datos residentes en disco
bajo alta contención.
Encontramos que si el secuenciador elige una forma conservadora estimación alta y los retrasos de lucro alejar las
transacciones por más tiempo que es probable sea necesario, la contención de costes debido al acceso al disco se reduce al
mínimo (ya que ir a buscar casi siempre se completó antes de la transacción requiere el registro para ser leído) , pero a costa de
la latencia de transacción global. Excesivamente altas estimaciones podrían también resultar en la memoria del sistema de
almacenamiento de una sobrecarga de registros “en frío” en espera de las transacciones que se les pidió que se programe.
Sin embargo, si el secuenciador subestima / S de disco latencia y no retrasa la operación durante el tiempo suficiente,
entonces se programará demasiado pronto y de bloqueo durante la ejecución hasta que se complete todos ir a buscar. Dado que
los bloqueos se mantienen durante el tiempo, esto puede venir con un alto costo para la huella de contención y, por tanto, el
rendimiento global.
Por tanto, existe un equilibrio fundamental entre la latencia transaccional total y la contención en la estimación de la latencia
de disco E / S. En ambos experimentos descritos anteriormente, sintonizábamos nuestras predicciones de latencia por lo que al
menos el 99% de las transacciones de disco se programaron para acceder después de que sus solicitudes de precarga
correspondientes habían completado. Utilizando el motor de almacenamiento basado-le-sistema simple fi, esto significó la
introducción de un retardo artificial fi de 40 ms, pero esto era su fi ciente para mantener el rendimiento incluso bajo muy alta
contención (índice de contención = 0,01). Bajo la contención inferior (índice de contención ≤ 0.001), encontramos que no hay
retraso era necesario más allá de la demora por defecto causado por la recogida de transacción pide en lotes, con un promedio
de 5 ms. Una exploración más exhaustiva de este particular, la latencia de contención disyuntiva sería una vía interesante para
la investigación futura, especialmente en lo que experimentamos aún más con enganche Calvin hasta varios motores de
almacenamiento disponibles en el mercado.
5.2. Seguimiento a nivel mundial Records calientes
Para que el secuenciador para determinar con precisión qué transacciones para retrasar ing schedul- mientras que sus conjuntos de
lectura están calientes, componente secuenciador de cada nodo debe realizar un seguimiento de los datos que están actualmente en la
memoria a través de todo el sistema, no sólo los datos gestionados por los componentes de almacenamiento de co -situado en el nodo
del secuenciador. Aunque esto era via- ble para nuestros experimentos descritos en este artículo, esto no es una solución escalable. Si
las listas globales de teclas de acceso rápido no se realiza un seguimiento en cada secuenciador, una solución es retrasar todas las
transacciones de ser programado hasta que se haya permitido un tiempo adecuado para la obtención previa. Esto protege contra el disco
que se extienden busca huellas de contención, pero incurre en latencia en cada transac- ción. Otra solución (para transacciones de
partición única solamente) sería para programadores para realizar un seguimiento de sus datos de forma sincrónica caliente local en
todas las réplicas, y luego permitir que los programadores para decidir de forma determinista para retrasar cerraduras que solicitan para
transacciones de partición única que intentan leer datos fríos. Una exploración más completa de esta estrategia, incluyendo vestigation in-
de cómo implementarlo formultipartition transacciones, sigue siendo Futurework.
6. checkpointing
sistemas de bases de datos deterministas tienen dos propiedades que son útiles para asegurar tolerancia a fallos. En
primer lugar, se replican de forma activa, y la replicación activa permite a los clientes no logran instantáneamente a otra
réplica en el caso de un accidente.
En segundo lugar, sólo la entrada de transacción se registra-no hay necesidad de pagar los gastos generales de la tala REDO
física. La reproducción de la historia de la entrada transaccional es su fi ciente para recuperar el sistema de base de datos al
estado actual. Sin embargo, sería ine fi ciente (y ridícula) para reproducir toda la historia del banco de datos desde el principio del
tiempo tras cada fracaso. En su lugar, Calvin realiza periódicamente un puesto de control de estado de base de datos completa
con el fin de proporcionar un punto de partida para comenzar la reproducción durante la recuperación.
Calvin es compatible con tres modos de puntos de control: puntos de control síncrono ingenuo, una variación asíncrona
de algoritmo Zig-Zag Cao et al [Cao et al.. 2011], y un modo de instantánea asincrónico que sólo se admite cuando la capa
de almacenamiento soporta multiversioning completo.
El primer modo utiliza la redundancia inherente en un sistema replicado activamente con el fin de crear un punto de control del
sistema. El sistema puede congelar periódicamente una réplica de todo y producir una instantánea versionado completa del
sistema. Ya que esto sólo sucede en una réplica a la vez, el período durante el cual una réplica no está disponible se puede ocultar
desde el cliente mediante el enrutamiento de las peticiones de cliente a no congelado réplicas.
Fig. 6. Rendimiento con el tiempo durante un periodo de puntos de control típico que utiliza de Calvin modificados con el esquema de Zig-Zag.
Una problemwith este enfoque es que la réplica de tomar el puesto de control puede caer signi fi cativamente por detrás de
otras réplicas, que pueden ser problemáticos si se llama a la acción debido a un fallo de hardware en otra réplica. Además, es
posible que el tiempo de réplica signi fi cativo para que coger una copia de seguridad a otras réplicas, especialmente en un
sistema con mucha carga.
segundo modo de puntos de control de Calvin se basa estrechamente en Cao algoritmo Zig-Zag et al. [Cao et al. 2011]. Zig-Zag
almacena dos copias de cada registro de un almacén de datos dada, PEDIR] 0
y PEDIR] 1, más dos bits adicionales por registro, MR [K] y MW [K] ( dónde K es la clave del registro). MR [K] especi fi ca que
la versión registro se debe utilizar cuando la lectura de registro K a partir de la base de datos, y MW [K] especi fi ca que la
versión para sobrescribir al actualizar registro K. Así que los nuevos valores de registro K siempre se escriben en PEDIR] MW
y
[K],
MR [K] se fija igual a MW [K] cada vez K se actualiza.

Cada periodo de puesto de control en zigzag comienza con el establecimiento MW [K] igual a ¬ MR [K] para todas las
claves K en la base de datos durante un punto físico de la consistencia en la que la base de datos está inmovilizada por
completo. Así PEDIR] MW [K] siempre almacena la versión más reciente del registro, y PEDIR] ¬ MW [K] siempre almacena el último
valor escrito antes del inicio del período de punto de control más reciente. Por tanto, un hilo de puntos de control asíncrono
puede pasar con cada llave K, Inicio sesión PEDIR] ¬ MW [K] en el disco sin tener que preocuparse por el registro que se está
clobbered.
Aprovechando orden serial mundial de Calvino, hemos implementado una variante de zigzag que hace no requerir
quiescing la base de datos para crear un punto físico de consistencia. En su lugar, Calvin capta una instantánea con
respecto a una virtual punto de coherencia, que es simplemente un punto fi ed prespeci en el orden de serie global. Cuando
un punto de coherencia virtuales se acerca, capa de almacenamiento de Calvin comienza mantener dos versiones de cada
registro en el sistema de almacenamiento-un “antes” versión, que sólo puede ser actualizado por las transacciones que
preceden al punto de coherencia virtual, y un “después ”versión, que se escribe en las transacciones que aparecen
después de que el punto de coherencia virtual. Una vez que todas las transacciones anteriores al punto de coherencia
virtuales han completado su ejecución, el “antes” versiones de cada registro son efectivamente inmutable, y un hilo de
puntos de control asíncrono puede comenzar puntos de control en el disco. Una vez que se ha completado el puesto de
control, las versiones duplicadas son recolección de basura:
Mientras que el modo de puntos de control primera de Calvin descrito antes implica detener ejecución de la acción trans-
completamente durante la duración del puesto de control, este esquema incurre en gastos generales sólo moderada, mientras que
el hilo de puntos de control asíncrono está activo. La Figura 6 muestra el rendimiento máximo de Calvin largo del tiempo durante
un período de captura puesto de control típico. Esta medida fue tomada en un despliegue de Calvin-sola máquina que ejecuta
nuestro microbenchmark a baja contención (véase la sección 7 para más información sobre nuestra experimental
preparar). Sin embargo, cabe señalar que estos resultados sirven únicamente como una demostración de la viabilidad de la
durabilidad de Calvino en la cara de fallas en el sitio; más investigación está próxima.
Aunque hay algo de reducción en el rendimiento total debido a: (a) el costo de CPU de adquirir el puesto de control y (b)
una pequeña cantidad de contención de pestillo cuando se accede a los registros, escribiendo valores estables al
almacenamiento de forma asíncrona no aumenta la contención de bloqueo o transacción latencia.
Calvin es también capaz de tomar ventaja de los motores que hacen un seguimiento de almacenamiento de forma explícita todas las
últimas versiones de cada registro en adición a la versión actual. motores de almacenamiento multiversión permiten de sólo lectura
consultas para ser ejecutados sin adquirir ningún bloqueo, la reducción de la contención general y la sobrecarga total de control de
concurrencia a costa de un mayor uso de memoria. Cuando se ejecuta en este modo, el esquema de puntos de control de Calvino toma
la forma de una consulta ordinaria “SELECT *” sobre todos los registros, donde el resultado de la consulta se registra en un expediente
en el disco en lugar de regresar a un cliente.
7. rendimiento y escalabilidad
Para investigar las características de rendimiento y escalabilidad de Calvino bajo una variedad de condiciones, nos encontramos
con una serie de experimentos utilizando dos puntos de referencia: la C-TPC marca de evaluación comparativa y una
microbenchmark que hemos creado con el fin de tener más control sobre cómo parámetros de la marca banco- son variadas.
Excepto donde se indique lo contrario, todos los experimentos se realizaron en Amazon EC2 usando de alta CPU / instancias
extra grande, que prometen 7 GB de miem- ory y 20 EC2 Unidades-8 núcleos virtuales con 2,5 unidades EC2 cada uno. 9
7.1. TPC-C Benchmark
El punto de referencia TPC-C se compone de varias clases de transacciones, pero la mayor parte de la carga de trabajo,
incluyendo transacciones casi todos distribuidos que requieren alto aislamiento está constituido por la transacción nueva
orden, que simula un cliente realizar un pedido en un comercio electrónico solicitud. Desde el centro de nuestros
experimentos es en las transacciones distribuidas, hemos limitado nuestra aplicación TPC-C para las transacciones del
Nuevo Orden solamente. Es de esperar que, sin embargo, para lograr rendimiento y escalabilidad resultados similares si
tuviéramos que correr el completa prueba TPC-C.
La Figura 7 muestra (transacciones TPC-C New orden ejecutada por segundo) y el rendimiento total de per-máquina en
función del número de nodos de Calvin, cada uno de los cuales almacena una partición base de datos que contiene 10
almacenes TPC-C. Para investigar a fondo el manejo de transacciones distribuidas, transacciones multi-almacén de New
Order (alrededor del 10% de las transacciones totales del Nuevo Orden) de Calvin acceder siempre un segundo almacén
que es no en la misma máquina que el primero.
Debido a que cada partición contiene 10 almacenes y New Order actualiza uno de los 10 “distritos” hace algún almacén,
en la mayoría de 100 transacciones Nueva orden puede ser execut- ing simultáneamente en cualquier máquina (ya que no
hay más de 100 distritos únicos por partición, y cada Solicitar nueva transacción requiere un bloqueo exclusivo en un distrito).
Por lo tanto, es fundamental que el tiempo que se mantienen bloqueos isminimized, ya que la opción de venta pasante del
sistema está limitada por la rapidez con estas 100 transacciones simultáneas completa (y liberar los bloqueos) para que las
nuevas transacciones pueden agarrar los bloqueos exclusivos en los distritos y obtener empezado.
Si llegara a Calvin mantener bloqueos durante un protocolo de acuerdo de cometer tales como de dos fases para las
transacciones distribuidas del Nuevo Orden, el rendimiento se limitaría severamente (una comparación detallada de la
implementación de un sistema tradicional de confirmación en dos fases se da en la Sección 7.3). Sin el protocolo de acuerdo,
Calvin es capaz de alcanzar alrededor de 5.000
9 Cada unidad de sistemas EC2 proporciona al menos la capacidad de la CPU de un Opteron 2007 de 1,0 a 1,2 GHz o procesador Xeon 2007.
Fig. 7. (Nuevo Orden 100%) de rendimiento total y por nodo TPC-C, variando el tamaño de la implementación.
transacciones por segundo por nodo en grupos de más de 10 nodos, y las escalas de forma lineal. (La razón por Calvin
logra más transacciones por segundo por nodo en grupos más pequeños se discute en la siguiente sección.) Por tanto,
nuestra aplicación Calvin es capaz de alcanzar casi medio millón de transacciones TPC-C por segundo en un clúster
100-nodo. Es notable que el TPC-C poseedor del récord mundial actual (Oracle) se ejecuta 504,161 transacciones de
pedidos nuevos por segundo, a pesar de correr en un hardware mucho de gama más alta que las máquinas que utilizamos
para nuestros experimentos [2010] Carlile.
7.2. Los experimentos microbenchmark
Para examinar con mayor precisión los costes de una combinación de transacciones distribuidas y alta contención, se
implementó un microbenchmark que comparte algunas carac- terísticas con transacción nueva orden de TPC-C, al tiempo
que reduce los gastos generales globales y permitir ajustes más fina a la carga de trabajo. Cada transacción en el punto de
referencia lee 10 registros, realiza una comprobación de restricción en el resultado, y actualiza un contador en cada
registro, si y sólo si la restricción de comprobación pasó. De los 10 registros se accede por la transacción microbenchmark,
uno se elige de un pequeño conjunto de registros “calientes”, 10 y el resto son seleccionados entre un conjunto mucho mayor
de los registros, excepto cuando una transacción marca microbench- se extiende por dos máquinas, en cuyo caso los que
accede un registro “en caliente” en
cada máquina de participar en la transacción. Variando el número de registros “calientes”, podemos sintonizar finamente fi
contención. En la discusión subsiguiente, se utiliza el término Índice tention con- para referirse a la fracción del total de
registros “calientes” que se actualiza cuando una transacción se ejecuta en una máquina particular. Un índice de
contención de 0.001, por lo tanto significa que cada transacción elige uno de cada mil registros “calientes” para actualizar
en cada equipo de participantes (es decir, en la mayoría de 1.000 transacciones nunca podría ejecutando
10 Tenga en cuenta que este es un uso diferente del término “caliente” que la utilizada en la discusión de almacenamiento en caché en nuestra discusión anterior de memoria- frente a
los motores de almacenamiento en disco.
Fig. 8. rendimiento total y microbenchmark por nodo, variando el tamaño de la implementación.
al mismo tiempo), mientras que un índice de contención de 1 significaría que todos los toques de transacción
todas registros “calientes” (es decir, operaciones deben ejecutarse completamente en serie).
La Figura 8 muestra experimentos en los que una escala a la microbenchmark a 100 nodos Calvin bajo diferentes
configuraciones de contención y con un número variable de transacciones distribuidas. Al añadir máquinas de bajo muy
baja contención (índice de contención =
0,0001), el rendimiento por nodo gotas a una cantidad estable por alrededor de 10machines y luego se mantiene constante,
la escala linealmente a muchos nodos. Bajo mayor contención (índice de contención = 0.01, que es similar al nivel de la
afirmación del TPC-C), vemos se añaden a, más grad- degradación rendimiento ya ual por nodo como máquinas,
acercándose más lentamente una cantidad estable.
Múltiples factores contribuyen a la forma de esta curva de escalabilidad en Calvin. En todos los casos, la fuerte caída-off
entre una máquina y dos máquinas es el resultado de la costo de CPU de trabajo adicional que debe ser realizada para
cada transacción de varias particiones:
- serializar y deserializar resultados leídos a distancia;

- un contexto adicional de conmutación entre las transacciones a la espera de recibir los resultados leídos a distancia;
- establecer, ejecutar y la limpieza después de la transacción todas máquinas participantes, a pesar de que se cuenta sólo
una vez en el rendimiento total. Después de esta bajada inicial, la razón de nuevo descenso a medida que más nodos son
-añadió- incluso cuando tanto la contención y el número de máquinas de participar en cualquier transacción distribuida se
mantienen constantes-es bastante sutil. Supongamos que, bajo una carga de trabajo de alta contención, que la máquina A
comienza a ejecutar una transacción distribuida que requiere una lectura remota de la máquina B, pero B no ha llegado a esa
transacción todavía (B todavía puede estar trabajando en transacciones anteriores en la secuencia, y no se puede empezar a
trabajar en la transacción hasta las cerraduras han sido adquiridos por todas las transacciones anteriores en la secuencia).
Máquina A puede ser capaz de comenzar a ejecutar algunas otras transacciones contradictorios noncon fl, pero luego
simplemente tendrá que esperar a B para ponerse al día antes de que pueda confirmar la transacción distribuida en espera y
ejecutar transacciones contradictorios con fl posteriores. Por este mecanismo, hay un límite a lo lejos por delante o por detrás
de la manada cualquier máquina ular parti- puede conseguir. Cuanto mayor sea la contención, el más apretado de este límite.
A medida que se añaden máquinas, suceden dos cosas.
- máquinas lentas. No todas las instancias de EC2 producen un rendimiento equivalente, y en ocasiones un usuario EC2 se
atasca con una instancia lento. Dado que los resultados experimentales mostrados en la Figura 8 se obtuvieron utilizando
los mismos instancias de EC2 para las tres líneas y las tres líneas muestran una caída repentina entre 6 y 8 máquinas, es
claro que una máquina ligeramente lento se añadió cuando fuimos a partir de 6 nodos para 8 nodos.
- Ejecución de inclinación progreso. Cada máquina de vez en cuando se pone ligeramente por delante de o detrás de
otros debido factores tomany, tales como la programación OS hilo, latencias de red variables, y las variaciones
aleatorias en la contención entre secuencias de transacciones. Las máquinas más hay, más probable en un momento
dado habrá al menos uno que es un poco por detrás por alguna razón.
La sensibilidad del rendimiento general del sistema a skew progreso de la ejecución depende en gran medida de dos
factores.
- Número de máquinas. El menor número de máquinas que hay en el clúster, el más cada máquina adicional aumentará
inclinación. Por ejemplo, supongamos cada uno de norte máquinas pasa una cierta fracción k del tiempo que contribuye a
la ejecución progreso oblicua (es decir, quedando atrás el paquete). A continuación, en cada instante habría un 1 - ( 1 - k) norte
posibilidad de que al menos una máquina está desacelerando el sistema. Como norte crece, esta probabilidad se
aproxima a 1, y cada máquina adicional tiene menos y menos de un efecto de inclinación.
- Nivel de contención. Cuanto mayor sea la tasa de contención, las desaceleraciones al azar de cada máquina más
probable será que causa otro máquinas tengan que frenar su ejecu- ción también. En condiciones de baja contención
(índice de contención = 0,0001), vemos disminución rendimiento por nodo bruscamente sólo cuando la adición de la fi
pocas máquinas primeros, entonces aplanar a cabo a alrededor de 10 nodos, ya que la disminución aumentos en
ejecución progreso skew tienen relativamente poco efecto en el rendimiento total. Bajo mayor contención (índice de
contención = 0.01), vemos una caída inicial incluso más agudo, y luego se tarda muchas más máquinas se añaden antes
de que comience la curva para aplanar, ya que incluso pequeñas incremen- aumenta Tal en nivel de la ejecución
progreso skew pueden tener un efecto significativo en el rendimiento.
7.3. Manipulación de alta contención
La mayoría de las cargas de trabajo del mundo real tienen una baja contención mayor parte del tiempo, pero la aparición de un
pequeño número de extremadamente elementos de datos caliente no es infrecuente. Por lo tanto, hemos experimentado con Calvin
bajo el tipo de carga de trabajo que creemos que es la razón principal de que tan pocos sistemas prácticos tratan de apoyar las
transacciones distribuidas: la combinación de muchas de las transacciones de varias particiones con muy alta contención. En este
experimento, por tanto,
Transacciones distribuidas Fast y la replicación consistente para sistemas de bases de datos OLTP once y treinta y uno
Fig. 9. Desaceleración para 100% cargas de trabajo de varias particiones, variando índice de contención.
No se centre en la totalidad de una carga de trabajo realista, pero en cambio tenemos en cuenta sólo el subconjunto de una carga de trabajo
que consiste en transacciones de varias particiones de alta contención. Otras operaciones pueden todavía conflicto con estas transacciones
de alto conflicto (en registros, además de aquellas que son muy caliente), por lo que el rendimiento de este subconjunto de una carga de
trabajo (de lo contrario fácilmente escalable) pueden estar estrechamente acoplado al rendimiento general del sistema.
La Figura 9 muestra el factor por el que los sistemas de 4-nodo y 8-nodo Calvin se ralentizan (comparado con el que ejecuta una
versión perfectamente divisible, bajo la contención de la misma carga de trabajo) durante la ejecución de 100 transacciones% de
varias particiones, en función de índice de contención. Recordemos que el índice de contención es la fracción del conjunto total de
registros calientes cerradas por cada transacción, así que un índice de contención de 0,01 significa que hasta 100 de transacciones
puede ejecutar simultáneamente, mientras que un índice de contención de 1 transacciones fuerzas para ejecutar completamente
serie.
Debido a que las implementaciones modernas de sistemas distribuidos no implementan Sistema R * al estilo de
transacciones distribuidas con confirmación en dos fases, y las comparaciones con los sistemas de generaciones anteriores no
serían una comparación de manzanas con manzanas, incluimos para la comparación de un modelo simple de la desaceleración
basado en contención en que se incurriría por el este tipo de sistema. Asumimos que en el nonmultipartition, caso bajo este
sistema de contención conseguiría rendimiento similar a Calvin (alrededor de 27.000 transacciones por segundo
microbenchmark per máquina). Para calcular la desaceleración causada por transacciones ción multiparti-, consideramos que la
huella de contención prolongada causada por la confirmación en dos fases. Desde dado un índice de contención C como máximo
1 / C las transacciones se pueden ejecutar concurrentemente, un 2PC sistema en funcionamiento a cometer el tiempo nunca
puede ejecutar más de
1
C * re 2 ordenador personal
total de transacciones por segundo donde re 2 ordenador personal es la duración de la confirmación en dos fases protocolo.
Típica latencia de ping de ida y vuelta entre los nodos en el mismo centro de datos EC2 es de alrededor de 1 ms, pero
incluyendo retrasos de mensaje de multiplexación, la serialización / deserialización, y la programación de subprocesos,
unidireccionales latencias en nuestro sistema entre hilos de ejecución de transacción son casi nunca menos de 2 ms, y por lo
general más largo. En nuestro modelo de un sistema similar en cabeza de Calvino, por tanto, esperamos que los bloqueos que se
realizará por aproximadamente 8 ms en cada transacción distribuida. Tenga en cuenta que este modelo es algo ingenua, ya que
se supone que la huella de la contención de una transacción para incluir nada más que la latencia
de confirmación en dos fases. Otros factores que contribuyen a la desaceleración real de Calvin son completamente ignoradas
en este modelo, incluyendo:
- costes de CPU de transacciones de varias particiones;

- latencia de llegar a un local de comprometerse / abortar decisión antes de comenzar 2PC (que puede requerir remoto
adicional lee en un sistema real);
- skew progreso de ejecución (todos los nodos se supone que comenzar la ejecución de cada transacción y la 2PC
subsiguiente en perfecto unísono).
Por lo tanto, el modelo no establece un punto de comparación especí fi ca para nuestro sistema, pero un fuerte límite
inferior de la desaceleración para un sistema de este tipo. En un sistema al estilo * Sistema R real, uno podría esperar ver
mucho más de lo previsto por la desaceleración este modelo en el contexto de las transacciones distribuidas de alta
contención.
Existen dos características muy notables en los resultados mostrados en la Figura 9. En primer lugar, en condiciones de baja
contención, Calvin obtiene el mismo aproximadamente 5x 7x desaceleración de 27.000 a alrededor de 5000 (4 nodos) o 4.000 (8
nodos) transacciones por segundo, como se observa en el experimento anterior que va de 1 máquina para 4 u 8. para todos los
niveles de contención examinados en este experimento, la diferencia en el rendimiento casos entre las 4-nodo y de 8-nodo es un
resultado de una mayor inclinación en curso de ejecución carga de trabajo entre los diferentes nodos; como se podría predecir, el
efecto perjudicial de esta inclinación para el rendimiento es significativamente peor en los niveles de contención más altas.
En segundo lugar, como se esperaba, a muy altas contenciones, aunque ignoramos varios de los costos esperados, el
modelo del sistema que ejecuta en dos fases incurre significativamente mayor desaceleración de Calvin. Esto es evidencia
de que: (a) el distribuido protocolo de confirmación es importante motivo de los factores detrás del formost decisión sistemas
distribuidos modernos no apoyar las transacciones ACID y (B) Calvin alivia esta cuestión.
7.4. Transacciones dependientes
Para demostrar la eficacia de OLLP (descrito en la Sección 3.2.1) en presencia de transacciones dependientes en Calvin,
que Modi fi ed nuestra microbenchmark por lo que a veces ( RE% de las veces, por ejemplo) se requiere una búsqueda de
índice secundario para determinar el conjunto completo de lectura-escritura. Recordemos que en OLLP cada transacción
comienza con una etapa de reconocimiento (en la cual las operaciones de lectura y escritura conjuntos se predice a través
de búsquedas de índice bajo de aislamiento) antes de la solicitud de transacción se encamina al secuenciador. La latencia
entre la etapa de reconocimiento y la ejecución real de la transacción incluye por lo tanto la latencia del protocolo de
replicación Paxos. Esta latencia afecta a la probabilidad también de tener que abortar y reiniciar la operación. Después de
todo, a medida que pasa más tiempo entre la predicción optimista y el final de verificación, el índice será más probable que
se han actualizado. A examinar este efecto, nos encontramos con nuestra modi fi cada carga de trabajo microbenchmark 11
variando tres parámetros.
- El porcentaje D de transacciones que son transacciones dependientes. En particular, nos fijamos en las cargas de
trabajo que consta de 0%, 20%, 50% y 100% transacciones dependientes.
- Se espera la latencia de replicación. Para modelar los tres modos de replicación que fueron Desven- cussed en la
Sección replicación maestro-esclavo 3,1-asíncrona, dentro de-centro de datos Paxos, y WAN Paxos-nos introducido arti
fi retrasos ciales de 0, 100, y 500 milisegundos, respectivamente, durante la fase de secuenciación transacción . 12
11 Los experimentos en esta sección no se ejecutan en máquinas EC2, pero en un clúster local en Yale con similares de hardware general especí fi caciones a
las prometida por EC2 alta de CPU / Extra-Grande instancias: procesadores Intel Xeon X5550 núcleo quad- 2,6 GHz proporcionando 8 hardware hilos; 12 GB
de memoria.
12Hemos elegido utilizar retrasos fi artificial en lugar de ejecutar los protocolos de replicación reales con el fin de limitar la cantidad de variación aleatoria, para
hacer un análisis más claro. Por otra parte, por simplicidad hemos limitado los experimentos en esta sección para transacciones de una sola partición
solamente. Sin embargo, ya que la latencia de replicación generalmente
Fig. 10. rendimiento Per-máquina para cargas de trabajo microbenchmark con varias posiciones com- transacción dependiente y latencias de replicación, como
una función de la volatilidad de entrada de índice.
- Índice de volatilidad de entrada. Esta es la tasa promedio de actualización cada entrada en el índice. Esto significa que un
índice con un millón de entradas y una volatilidad entrada de índice de 0,1 se actualiza 100.000 veces por segundo.
En primer lugar, se analiza el rendimiento del caudal que se puede lograr en presencia de las transacciones dependientes. La
Figura 10 muestra el rendimiento total para diversas cargas de trabajo crobenchmark mi- dependientes. Aquí vemos que, con
latencias de replicación más altas, Mance perfor- es de hecho más sensibles a las altas tasas de actualización del índice, mientras
que la latencia de replicación es más bajo, se necesita una volatilidad mucho mayor entrada de índice para un signi fi efecto
adverso en el rendimiento no puede ser observada. Por ejemplo, para cargas de trabajo que consisten completamente de las
transacciones dependientes, se necesita una volatilidad entrada de índice de 1 para reducir el rendimiento al 50% retraso de
replicación de 500 ms, mientras que la volatilidad debe alcanzar 5 y 35 para causar 50% de rendimiento disminuye con retrasos de
replicación de 100 ms y 0 ms respectivamente.
Para entender mejor estos resultados, se examinó la cantidad de veces que las transacciones dependientes se ven obligados a
reiniciar debido a los controles fallidos optimistas. Por ejemplo, con una volatilidad de 1 y un retraso de replicación de 500 ms,
onewould esperar cerca de la mitad de los controles optimistas falle. Por lo tanto la mitad de todas las transacciones dependientes
sería reiniciar al menos una vez, entonces la mitad de estas transacciones renovadas (por lo que una cuarta parte de las
transacciones totales) se vería forzado a reiniciar vez más, y así sucesivamente. Así, podemos esperar para ver una tasa esperada
total de reinicio
( 1 2)
2 1.
12+1 Σ i=
4+1 8+···=∞
i=1
Del mismo modo, es de esperar aproximadamente una décima parte de los cheques optimistas a fallar con un índice de volatilidad de 1 y un
retraso de replicación de 100 ms, lo que resulta en una tasa de reinicio
( 1 10 ) 1
1 10 + 1 Σ i=
100 + 1 1000 + · · · = ∞ 9.
i=1
domina el retardo entre reconocimiento y de ejecución de pasos, se espera que el rendimiento global y los efectos de latencia a ser muy similares en presencia
de transacciones distribuidas.
Fig. 11. número medio de veces que una transacción dependiente tiene que reiniciar en función de la volatilidad de entrada de índice.
Fig. 12. Aquí mostramos 50a, 90a, y la latencia de percentil 99 de las transacciones microbenchmark dependientes en función de la volatilidad de entrada de
índice.
Con la replicación asíncrona, el momento entre la fase de reconocimiento y ejecución tual AC- es por lo general entre 10 y
20 milisegundos, lo que debería dar como resultado una tasa de reinicio esperada por debajo de 1/50 cuando la volatilidad
es 1.
La Figura 11 muestra el número de veces en promedio que una transacción dependiente reinicia debido a un cambio de
índice entre la fase de reconocimiento y la ejecución real de la transacción, en función de modo de replicación y la volatilidad
de entrada de índice. Como se predijo, los retrasos de replicación con alta resultan en un aumento de las tasas de reinicio.
De hecho, en la volatilidad 1 vemos sólo las tasas de reinicio predijeron previamente: aproximadamente 1 cuando retraso de
replicación es de 500 ms, aproximadamente 0,1 cuando la replicación es de 100 ms, y un poco más de 0,01 para la
replicación asíncrona.
La Figura 12 se extiende este análisis con latencias de transacciones reales. En particular, representamos el 50, 90, y
latencias percentil 99 para las transacciones dependientes como índice de volatilidad crece.
Una vez más, vemos el mismo efecto que da antes, pero “Magni ed fi” en cada caso por la latencia-nos replicación
impuesta vemos que la latencia total es generalmente igual al número de reinicios veces el retraso de replicación asociado
con cada reinicio. Una vez más los retrasos de replicación con alta hacen que el rendimiento más vulnerables a la
volatilidad de entrada de alto índice. Sin embargo, una vez más, la volatilidad debe ser más de 0.2 para ver los retrasos,
incluso más de 1 segundo para la latencia de percentil 99 al realizar Paxos través de una WAN.
Como se discutió en la Sección 3.2.1, las bases de datos del mundo real suelen mantener índices sólo en tablas con muy baja
volatilidad. Recordemos que la volatilidad entrada de índice se refiere aquí a los cambios totales por segundo para cada entrada de
índice. Por lo tanto, estos análisis no conozcan el caso inusual de extremadamente alto índice de tasas de actualización de entrada.
índices secundarios se commonlymaintained en campos tales como los nombres de usuario, direcciones, símbolos de acción y otros
atributos “estáticos” por el cual las aplicaciones son propensos a los registros de grupo y de referencia. Para este tipo de escenarios
reales comunes, se espera que los costos de reanudación de la ejecución de OLLP sobre las transacciones dependientes a ser
completamente insignificante.
8. TRABAJO RELACIONADOS
Muchas de las contribuciones de este artículo, incluyendo la introducción de la arquitectura general de Calvin y muchas de
las medidas de rendimiento discutidos aquí, han aparecido en nuestro trabajo previo [Thomson et al. 2012]. importantes las
contribuciones de este artículo que no aparecen en las publicaciones anteriores incluyen nuestro esquema para la
implementación de las transacciones del lado del servidor para desarrolladores con niños, introducidas en la Sección 4, y
nuestro análisis de los resultados de Calvino en la presencia de las transacciones dependientes, que aparece en la Sección
7.4.
Una contribución clave de la arquitectura de Calvin es que cuenta con replicación activa, donde la misma entrada
transaccional se envía a varias réplicas, cada una de las cuales Pro- entrada transaccional cesos de una manera
determinista a fin de evitar divergente. Ha habido varios intentos relacionados para replicar de forma activa los sistemas de
bases de datos de esta manera. Pacitti et al. [2003], Whitney et al. [1997], Stonebraker et al. [2007], y Jones et al. [2010]
Todos proponer realizar el procesamiento de transacciones en una base de datos distribuida con- a cabo el control de
concurrencia mediante la ejecución de las transacciones en serie y por lo tanto equivalente a una conocido orden en serie
un solo hilo en cada nodo (donde un nodo en algunos casos puede ser un solo núcleo de la CPU en un servidor de
múltiples núcleos [Stonebraker et al. 2007]). Por transacciones cuting eje- en serie, no determinismo debido a hilo
programación de transacciones simultáneas se elimina, y la replicación activa es más fácil de lograr. Sin embargo, las
transacciones alizing SERIAS pueden limitar el rendimiento transaccional, ya que si una transacción puestos (por ejemplo,
para una red de leer), otras transacciones son incapaces de tomar el relevo. Calvin permite transacciones simultáneas sin
dejar de garantizar la equivalencia lógica a una orden dada en serie. Además, no aunque estos sistemas eligen un orden
serial antes de la ejecución, la adhesión a ese orden se aplica tan estrictamente como en Calvin (por ejemplo, las
transacciones pueden ser abortado debido a fallos de hardware),
Cada uno de los trabajos mencionados implementa un componente del sistema análogo a la capa de secuenciación de
Calvin que elige el orden en serie. secuenciador de diseño de Calvin más se parece al diseño de H-store [Stonebraker y col.
2007], en el que los clientes pueden enviar transacciones a cualquier nodo del clúster. La sincronización de las entradas entre
difiere réplicas, sin embargo, en que Calvin puede utilizar ya sea la replicación asíncrona (armazón de envío) o basado en
Paxos replicación síncrona, fuertemente coherente, mientras que H-tienda replica entradas por estancamiento transacciones
por la latencia de red esperado de envío de una transacción a una réplica y, a continuación, utilizando un esquema
determinista para el pedido transacción suponiendo que todos los transacciones llegan de todas las réplicas dentro de esta
ventana de tiempo.
Bernstein et del al. Hyder [Bernstein et al. 2011] tiene similitudes conceptuales a pesar de Calvin extremadamente
diferentes diseños arquitectónicos y enfoques para lograr un alto
escalabilidad. En Hyder, las transacciones que presenten sus “intenciones” -buffered escribe-después de la ejecución sobre
la base de una vista de la base de datos obtenidos a partir de una instantánea reciente. Las intenciones se componen en
un orden global y se procesan por una función determinista “MELD”, que determina qué transacciones se comprometan y
qué transacciones deben ser abortados (por ejemplo, debido a una actualización de los datos que invalida la opinión de la
de transacción de la base de datos de AF ter la operación ejecutada, pero antes de la función MELD validado la
transacción). a nivel mundial de Hyder ordenó registro de las cosas-to-intento-determinista se compone de los efectos
después-de transacciones, mientras que el registro de análogo en Calvin contiene solicitudes de transacciones no
ejecutadas. No obstante, el esquema optimista de Hyder es conceptualmente muy similar al esquema Ubicación Predicción
bloqueo optimista (OLLP) discutió en la Sección 3.2.
Lomet et al. proponer componentes sistema de procesamiento de transacciones “de separación” en un entorno de nube
de una manera similar a la separación de las diferentes etapas de la tubería en diferentes subsistemas [Lomet et al Calvino.
2009]. Aunque Lomet et al. De mecanismos de control de la moneda y de replicación con- no se parecen a Calvin de, ambos
sistemas separar el componente transaccional (capa de programación) de la componente de datos (capa de
almacenamiento) para permitir backends de almacenamiento arbitrarias para servir el sistema de procesamiento de
transacciones en función de las necesidades de la aplicación. Calvin también toma la separación de un paso más, la
separación de la capa de secuenciación, que se ocupa de la replicación de datos.
Megastore de Google [Baker et al. 2011] y de IBM spinnaker [Rao et al. 2011] re-cientemente fue pionera en el uso del
algoritmo de Paxos [Lamport 1998, 2001] para la replicación de datos fuertemente consistente en bases de datos
transaccionales modernas, de alto volumen (aunque Paxos y sus variantes son ampliamente utilizados para llegar a un
acuerdo síncrono en un sinfín de otras aplicaciones). Como Calvin, spinnaker utiliza ZooKeeper [Hunt et al. 2010] para su
ejecución Paxos. Puesto que no son sistemas deterministas, tanto Megastore y Spinnaker deben utilizar Paxos para
replicar efectos transaccionales, mientras que Calvin solamente tiene que usar Paxos para replicar entradas
transaccionales.
9. TRABAJO FUTURO
En su implementación actual, Calvin se ocupa de los fallos de hardware mediante la recuperación de la máquina estrellado
desde su última instantánea completa y luego reproducir todas las transacciones más recientes. Aunque otros nodos dentro de
la misma réplica pueden depender de remoto lee desde el af infligido máquina, el rendimiento en el resto de la réplica es apto
para reducir la velocidad o detener hasta que la recuperación es completa.
En el futuro tenemos la intención de desarrollar un sistema de conmutación por error más fluida. Por ejemplo, los fallos
podrían hacerse completamente invisible con la siguiente técnica simple. El conjunto de todas las réplicas se puede dividir
en subgrupos de replicación-parejas o tríos de réplicas situados cerca uno de otro, generalmente en la misma red de área
local. Outgoingmessages relacionados con varias particiones ejecución de transacciones en un nodo de base de datos A en
una réplica se envían no sólo al nodo B previsto, dentro de la misma réplica, sino también para cada réplica del nodo B
dentro de la replicación subgrupo-sólo en caso de una de nodo del subgrupo A réplicas ha fallado.
Un buen compromiso entre estos dos enfoques podría ser integrar un componente que supervisa el estado de cada
nodo, lo que podría detectar fallos y orquestar cuidadosamente conmutación por error más rápido para una réplica con un
nodo fallido de dirección de otras réplicas de la AF infligido equipo para reenviar su remota leer mensajes apropiadamente.
tal
componente también estaría bien situado para supervisar el equilibrio de carga de consultas de sólo lectura, la migración de datos dinámica
y volver a crear particiones y monitorización de la carga.
Otra área de trabajo futuro implica investigación de bloqueo determinista manage- ment. La implementación actual del Calvin utiliza una estructura de datos de
gestión de bloqueo tradicional, con una tabla hash que mapea claves de tupla a las colas de las transacciones que han hecho las solicitudes de bloqueo en esa n.
Sin embargo, en un sistema determinista que es un punto muerto libre y garantiza la equivalencia a un orden serial dada, la transacción activa más antigua está
siempre garantiza que sea capaz de adquirir la totalidad de sus cerraduras. Por lo tanto, no es necesario realizar un seguimiento de la cual las operaciones están a
la espera para el que los artículos de todos los datos que se requiere es realizar un seguimiento de un simple recuento de cada elemento de datos de solicitudes
cuántas transacciones han hecho para que la cerradura, y este conteo se incrementa / decrementa cada vez transacciones hacen peticiones / fi nal que trabaja en
un elemento de datos particular. Cada vez que una transacción obtiene la condición de ser la transacción más antigua del sistema, se puede asumir de inmediato
que cualquier bloqueo que no pudieron adquirir inicialmente (porque el recuento de bloqueo era distinto de cero cuando se trató de adquirir el bloqueo) se ha
adquirido de forma automática, y puede proceder sin la preocupación por otras transacciones que también se han hecho peticiones en la misma cerradura. Este
enfoque significativamente reduce la sobrecarga de gestión de bloqueo en el costo de reducir potencialmente concurrencia debido a la incapacidad para una
transacción a mano directamente sobre la cerradura de un elemento de datos a la siguiente transacción que hace una solicitud para ello. Tenemos la intención de
investigar cuándo exactamente este enfoque es una buena idea. se puede asumir de inmediato que los bloqueos no logró adquirir inicialmente (porque el recuento
de bloqueo era distinto de cero cuando trataron de adquirir el bloqueo) se ha adquirido de forma automática, y puede llevarse a cabo sin la preocupación por otras
transacciones que también se han hecho solicitudes en la misma cerradura . Este enfoque significativamente reduce la sobrecarga de gestión de bloqueo en el costo
de reducir potencialmente concurrencia debido a la incapacidad para una transacción a mano directamente sobre la cerradura de un elemento de datos a la
siguiente transacción que hace una solicitud para ello. Tenemos la intención de investigar cuándo exactamente este enfoque es una buena idea. se puede asumir de
inmediato que los bloqueos no logró adquirir inicialmente (porque el recuento de bloqueo era distinto de cero cuando trataron de adquirir el bloqueo) se ha adquirido
de forma automática, y puede llevarse a cabo sin la preocupación por otras transacciones que también se han hecho solicitudes en la misma cerradura . Este enfoque significativamente reduce la sobrecarga de gestión de bloqueo en el co
Una tercera área de trabajo futuro implica la aplicación de ción transacción determinista ejecu- Para presentar sistemas
distribuidos. fi l de los sistemas distribuidos que almacenan todo nombre-espacio y expediente de metadatos en un único servidor
padecen tanto un potencial punto de fallo y un cuello de botella escalabilidad. Sin embargo, si fi l de metadatos se reparte a través de
la memoria de un clúster no se comparte nada de las máquinas de las materias primas, a continuación, fi l de cambios se convierten
en transacciones distribuidas tanto como espacio de nombres y fi l de información de metadatos deben ser actualizadas en una única
transacción atómica. Calvin se podría utilizar para escalar estas transacciones distribuidas (y por tanto también escalar la fi sistema le
distribuido), mientras que también la replicación de los metadatos para alta disponibilidad.
10. CONCLUSIONES
Este artículo presenta Calvin, una capa de procesamiento de transacciones y replicación diseñado para transformar a,
transaccional, almacén de datos unreplicated genérico en un totalmente ACID, sistema de base de datos distribuida
replicado de forma coherente. Calvin apoya la capacidad scal- horizontal de la base de datos y las transacciones
distribuidas ACID compatible no constreñidos mientras que el apoyo tanto asíncrono y la replicación síncrona basada en
Paxos, tanto dentro de un solo centro de datos y a través de los centros de datos separados geográficamente. Mediante el
uso de un marco determinista, Calvin es capaz de eliminar distribuido protocolos de confirmación, el mayor impedimento
escalabilidad Moderno de sistemas distribuidos. En consecuencia, Calvin escalas cerca linealmente y ha logrado el
rendimiento transaccional cerca-world-registro en una fi ed TPC-C de referencia simplificada.
Por otra parte, se introduce un conjunto de herramientas que podrían hacer acciones trans de fi nir del lado del servidor más fácil para
los desarrolladores. Esto es esencial para hacer que los sistemas deterministas como Calvin utilizable, ya que toda la ejecución de
transacciones debe ocurrir lado del servidor, pero esto con- tribución también podría utilizarse para mejorar la facilidad de uso de otros
sistemas de bases de datos en las que no se requiera la ejecución del lado del servidor, pero todavía puede aumentar transaccional el
rendimiento.
Referencias
DJ Abadi. 2012. Los intercambios de consistencia en el diseño moderno sistema de base de datos distribuida: Cap es sólo una parte de la historia. IEEE Comput. 45,
2.
JC Anderson, J. Lehnardt, y N. Slater. 2010. transacciones distribuidas rápida y fuertemente la replicación consistente para los sistemas de bases de datos
OLTP. En CouchDB: La guía definitiva fi De 1 S t Ed, O'ReillyMedia, 1337:. 35.
J. Baker, C. Bond, J. Corbett, JJ Furman, A. Khorlin, J. Larson, J.-M. Leon, Y. Li, A. Lloyd, ANDV. Yushprakh.
2011. Megastore: Proporcionar escalable de almacenamiento de alta disponibilidad para servicios interactivos. En Actas de la Conferencia sobre el innovador
Sistema de Investigación de Datos (CIDR'11). 223-234.
PA Bernstein, CW Reid, y S. Das. Hyder 2011.-Un gestor de registro de transacciones para las cenizas fl compartido. En
Actas de la Conferencia sobre el innovador Sistema de Investigación de Datos (CIDR'11). 9-20.
D. Campbell, G. Kakivaya, y N. Ellis. 2010. escala Extreme con soporte de lenguaje SQL completa en SQL Azure Microsoft. En Actas de la Conferencia
Internacional ACM SIGMOD sobre Gestión de Datos (SIGMOD'10). 1021-1024.
T. Cao, M. Vaz Salles, B. Sowell, Y. Yue, A. Demers, J. Gehrke, y W. White. 2011. rápidos algoritmos de recuperación de puntos de control para aplicaciones
de frecuencia consistentes. En Actas de la Conferencia Internacional ACM SIGMOD sobre Gestión de Datos (SIGMOD'11). 265-276.
B. Carlile. 2010. Tpc referencia c informe de la divulgación completa: Oracle SPARC supercúmulo T3-4 con los servidores utilizando la base de datos Oracle
11g versión 2 con grupos reales de aplicación de Oracle e ING partition-. http://c970058.r58.cf2.rackcdn.com/fdr/tpcc/Oracle SPARC SuperCluster con
T3-4s TPC-C FDR
120210.pdf.
F. Chang, J. Dean, S. Ghemawat, WC Hsieh, DA Wallach, M. Burrows, T. Chandra, A. Fikes, y
RE Gruber. 2006. Bigtable: Un sistema de almacenamiento distribuido para datos estructurados. En Actas de la 7 º
Simposio en los sistemas operativos Diseño e Implementación (OSDI'06). 205-218.
BF Cooper, R. Ramakrishnan, U. Srivastava, A. Silberstein, P. Bohannon, H.-A. Jacobsen, N. Puz, D. Weaver, y R. Yerneni. 2008. Pnuts: Yahoo 's alojado
datos que sirve de plataforma. Proc. VLDB Endow. 1, 2, 1277-1288.
JC Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, JJ Furman, S. Ghemawat, A. Gubarev, C. Heiser,
P. Hochschild, W. Hsieh, S. Kanthak, E. Kogan, H. Li, A. Lloyd, S. Melnik, D. Mwaura, D. Nagle,
S. Quinlan, R. Rao, L. Rolig, Y. Saito, M. Szymaniak, C. Taylor, R. Wang, y D. Woodford. 2012. Llave: base de datos globalmente distribuida de Google.
En Actas de la 10 º Conferencia USENIX en los sistemas operativos Diseño e Implementación (OSDI'12). 251-264.
G. Decandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian,

P. Vosshall, y W. Vogels. 2007. Dynamo: alta disponibilidad almacén de claves-valor de Amazon. ACM SIGOPS Oper. Syst. Rdo. 41, 6, 205-220.
S. Gilbert y N. Lynch. 2002. La conjetura de Brewer y la viabilidad de los servicios web, consistentes, disponibles partition- tolerantes. Noticias ACM SIGACT 33,
2, 51-59.
P. Hunt, M. Konar, FP Junqueira, y B. Reed. 2010. Zookeeper: coordinación Espera-libre para sistemas de escala de Internet. En Actas de la Conferencia
Técnica Anual USENIX.
EPC Jones, DJ Abadi, y SR Madden. 2010. El control de concurrencia para bases de datos particionados. En
Actas de la Conferencia Internacional ACM SIGMOD sobre Gestión de Datos (SIGMOD'10). 603-
614.
A. y P. Lakshman Malik. 2009. Cassandra: sistema de almacenamiento estructurado en una red p2p. En Actas
de la 21 S t Simposio Anual sobre Paralelismo en los algoritmos y arquitecturas (PODC'09). 47.
L. Lamport. 1998. El tiempo parcial parlamento. ACM Trans. Comput. Syst. 16, 2, 133-169.
L. Lamport. 2001. Paxos de forma sencilla. Noticias ACM SIGACT 34, 4, 18-25.
D. Lomet y MF Mokbel. 2009. El bloqueo intervalos de teclas con servicios de transacción desagregados. Proc. VLDB
Dotar. 2, 1, 265-276.
DB Lomet, A. Fekete, G. Weikum, y MJ Zwilling. 2009. Los servicios de transacción de desagregación en la nube. En Actas de la 4 º Conferencia bienal sobre
sistemas innovadores de Datos de Investigación (CIDR'09).
C. Mohan, BG Lindsay, y R. Obermarck. 1986. La gestión de transacciones en el ar * distribuido sistema de gestión de base de datos. ACM Trans. Syst base
de datos. 11, 4, 378-396.
E. Pacitti, MT Özsu, y C. Coulon. 2003. preventivo replicación multi-maestro en un grupo de bases de datos autónomas. En Actas de la 9 º Euro-Par Conferencia
sobre Procesamiento Paralelo. 318-327.
E. Plugge, T. Hawkins, y P. Membrey. 2010. La guía definitiva fi De a MongoDB: La base de datos NoSQL para
Nube y computación de escritorio. Apress, Berkeley, CA.
J. Rao, EJ Shekita, y S. Tata. 2011. El uso de paxos para construir un almacén de datos escalable, consistente y de alta disponibilidad. Proc. VLDB Endow. 4,
4, 243-254.
M. Seltzer. 2011. base de datos de Oracle NoSQL. http://www.oracle.com/webapps/dialogue/ns/dlgwelcome.jsp?p ext = Y & p id dlg = 14620894 & src = 7912319
y ACT = 63 & sckw = WWMK13067492MPP001.
Stonebraker M., SR Madden, DJ Abadi, S. Harizopoulos, N. Hachem, y P. Helland. 2007. El fin de una era arquitectónica (es el momento para una reescritura
completa). En Actas de la 33 rd Conferencia Internacional sobre Bases de datos muy grandes (VLDB'07). 1150-1160.
A. Thomson y DJ Abadi. 2010. El caso de determinismo en sistemas de bases de datos. Proc. VLDB. Dotar. 3, 1-2, 70-80.
A. Thomson, T. Diamond, S.-C. Weng, K. Ren, P. Shao, y DJ Abadi. 2012. Calvino: acciones trans rápido distribuidas para sistemas de bases de datos
particionadas. En Actas de la Conferencia Internacional ACM SIGMOD sobre Gestión de Datos (SIGMOD'12). 1-12.
A. Whitney, D. Shasha, y S. Apter. 1997. procesamiento de transacciones de volumen de alta sin control de concurrencia, en dos fases, sql o C ++. En Actas
del Taller Internacional sobre Sistemas de Alto Rendimiento de transacción (HPTS'97).
Recibido octubre de 2012; revisado en octubre de 2013; aceptado de diciembre de 2013

Fast Distributed Transactions and Strongly Consistent Replication (Tema - Procesamiento de Transacciones de Base de Datos) (2) .En - Es

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Fast Distributed Transactions and Strongly Consistent Replication (Tema - Procesamiento de Transacciones de Base de Datos) (2) .En - Es

Transféré par

Droits d'auteur :

Formats disponibles

Fast transacciones distribuidas y la replicación Fuertemente consistente para sistemas OLTP de

Condiciones generales: Algoritmos, diseño, rendimiento y fiabilidad

Formato ACM Referencia:

© 2014 ACM 0362-5915 / 2014/05-ART11 $ 15.00 DOI:

1.1. El Costo de transacciones distribuidas

1.2. La replicación consistente

1.3. Llegar a un acuerdo sin aumentar Contención

1.4. Mejorar la usabilidad de Calvino

contribuciones principales de este artículo son las siguientes.

2. Los sistemas de bases de DETERMINISTAS

físico no suelen ser idéntica a cualquier instantánea particular del sistema.

3.1. Secuenciador y replicación

UNA Alicia → Valle

Figura 2. latencia promedio de transacción bajo diferentes modos de replicación de Calvino.

3.2. Scheduler y control de concurrencia

Cuando el componente transaccional de un sistema de base de datos es desagregado de la componente de

TXN secuencia leer escribir participativo

Por lo tanto, la partición de 1 programador ha recibido la solicitud por lotes

para esta época, el planificador y la partición de 2 ha recibido el lote siguiente.

4. Transacciones del lado del servidor amistoso con el desarrollador

(1) Traducir el código de transacción a cualquier lenguaje de programación se utiliza para

fusionaron con los registros de salida de la aplicación para conseguir

en src / example.py, entonces, además de llamar a la función,

> > > MiClase (). MyFun () Hola,

también se puede buscar el fi precisa archivo y número de línea donde se de fi nida.

> > > MyClass.MyFun.func_code.co_filename 'src / example.py'

> > > MyClass.MyFun.func_code.co_firstlineno 2

ExecAsTxn (BalanceTransfer, "bob" "alice",, 10)

más bien que

BalanceTransfer ( "alice", "bob", 10)

realiza varias tareas.

La Figura 5 ilustra este proceso dado una aplicación extendida de la

5. Calvin las unidades de disco BASADOS

5.1. / S de disco latencia Predicción

- distancia física variable para la cabeza y el husillo para mover;

5.2. Seguimiento a nivel mundial Records calientes

MR [K] se fija igual a MW [K] cada vez K se actualiza.

7.1. TPC-C Benchmark

7.2. Los experimentos microbenchmark

los motores de almacenamiento en disco.

Fig. 8. rendimiento total y microbenchmark por nodo, variando el tamaño de la implementación.

- serializar y deserializar resultados leídos a distancia;

7.3. Manipulación de alta contención

- costes de CPU de transacciones de varias particiones;

7.4. Transacciones dependientes

variando tres parámetros.

G. Decandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian,

Recibido octubre de 2012; revisado en octubre de 2013; aceptado de diciembre de 2013

Vous aimerez peut-être aussi