Una sola copia Serializabilidad con aislamiento de instantánea
bajo el capó
Mihaela A. Bornea 1, Orion Hodson 2, Sameh Elnikety 2, Alan Fekete 3
1 Atenas U. de Econ y Negocio
2 microsoft Research
3 Universidad de Sydney
Abstracto -Este documento presenta un método que permite una imita-
sistema de base de datos cado para proporcionar un nivel de aislamiento global más
fuerte que el nivel de aislamiento proporcionado en cada réplica de base de datos
individual. Proponemos una nueva versión multi-control de concurrencia gorithm
al-llamada, serializable generalizado de aislamiento de instantánea (SGSI), que se dirige
a los sistemas de bases de datos de middleware replicado. Cada réplica se ejecuta el
aislamiento de instantánea a nivel local y el middleware de replicación garantiza
serializabilidad mundial de una sola copia. Introducimos nuevas técnicas para
proporcionar un nivel de aislamiento global más fuerte, es decir, la extracción y el
aumento de readset certi fi cación que impide lectura-escritura y la escritura escribir los
conflictos en un entorno replicado. Se prueba la corrección del algoritmo propuesto, y
construimos un tipo de base de datos replicada sistema proto para evaluar el
desempeño SGSI experimentalmente.
I. INTRODUCCIÓN
En muchos sistemas de servidores de replicación se utiliza para lograr un mayor
rendimiento y la disponibilidad de un servidor centralizado. ción replicativa en los sistemas
de bases de datos es, sin embargo, particularmente desafiante porque las semántica
transaccional tienen que ser mantenidos. Los efectos de una transacción de actualización
en una réplica tienen que ser fi ciente propagado y sincronizada con todas las demás
réplicas, mientras se mantiene la consistencia para todos actualización y transacciones de
sólo lectura. Este reto ha sido reconocida [18], lo que lleva a varios protocolos de
replicación que el comercio explícitamente fuera consistencia a lograr un mayor
rendimiento: Un sistema de base de datos replicada puede proporcionar un nivel de
aislamiento inferior a un sistema de base de datos centralizada.
Se demuestra, contrariamente a la creencia común, que un sistema de base de datos
replicada puede e fi cientemente proporcionar un nivel de aislamiento global más fuerte que el
nivel de aislamiento proporcionado por las réplicas constitutivos. Aquí nos centramos en los
sistemas de bases de datos aislados de instantáneas y presentamos un algoritmo de control
de concurrencia que garantiza serializabilidad una sola copia mundial (1SR), mientras que
cada réplica garantiza el aislamiento de instantánea (SI), que es más débil que la
secuencialidad. Apoyamos esta afirmación, proponiendo un gorithm al-, lo que demuestra su
corrección, su aplicación, y la construcción de una base de datos replicada prototipo para
evaluar experimentalmente.
los motores de bases de datos como PostgreSQL y Oracle apoyo de la IS, ya que
proporciona un rendimiento atractivo para una clase importante de las cargas de trabajo
transaccionales que tienen ciertas propiedades, por ejemplo, INANZAS dom- de sólo lectura
transacciones, cambios cortos y ausencia de escritura hot-spots. Para aprovechar las ventajas
de esta ganancia de rendimiento, algunos motores de bases de datos soportan Si, además de
combinaciones de bloqueo tradicionales. Por ejemplo, Microsoft SQL Server es compatible con
SI y 2PL. La ganancia de rendimiento de la utilización de SI tiene un costo corrección: SI no es
serializable.
978-1-4244-8960-2 / 11 / $ 26.00 © IEEE 2011
Con un cuidadoso diseño y la ingeniería, los motores SI pueden replicarse para
obtener un rendimiento aún mayor con una forma replicada de SI tales como
Generalizado aislamiento de instantánea (GSI) [13], que también no es serializable. El
objetivo de este documento es proporcionar un algoritmo de control de concurrencia
para bases de datos SI replicados que alcanza casi el mismo rendimiento que GSI
mientras que proporciona uno-copy-seriabilidad mundial (1SR).
Para garantizar la secuencialidad, algoritmos de control de concurrencia suelen
requerir el acceso a los datos leídos y escritos en las transacciones de actualización. El
acceso a esta información es especialmente difícil en un sistema de base de datos
replicada ya incorporados en instalaciones dentro de un DBMS centralizado, como el
administrador de bloqueos, no están disponibles a nivel mundial. Además, los sistemas
replicados se enfrentan al reto icio ad- de cómo se extrae, se representó y se comunica
entre las réplicas de estos datos. Observe que los algoritmos de serialización para un
sistema centralizado, tales como bloqueo de dos fases (2PL) y aislamiento de instantánea
serializable (SSI) [7], no son su fi ciente en los sistemas de base de datos replicada:
mientras que cada réplica de cumplir seriabilidad localmente para las transacciones
locales, el sistema de base de datos replicada no proporciona 1SR.
Se propone un nuevo algoritmo de control de concurrencia, llamado Serializable
Generalizado aislamiento de instantánea (SGSI), para los sistemas de bases de datos
replicadas dleware media. Cada réplica utiliza el aislamiento tiro Snap, mientras que el
middleware de replicación se aplica SGSI para asegurar una sola copia serializabilidad.
SGSI valida tanto la writeset y readset de transacciones de actualización.
Normalmente, el readset es mucho más grande que el writeset y el desafío es
identificar y representar. Nuestro trabajo es el primero para hacer frente a este reto
en un entorno replicado. Se introduce una técnica para extraer el readset aplicando
la transformación automática de consultas para cada SQL declaración en una
transacción de actualización. Describimos cómo readsets son certi fi cado y
demostrar la corrección fi cación. Sorprendentemente, encontramos que readset
certi fi cación remplaza writeset certi fi cación: Writeset certi fi cación ya no es
necesaria. Al contrario de trabajo previo, writeset se extraen para la propagación de
actualización y durabilidad,
no mundial para la prevención de escritura escribir los conflictos a través writeset certi fi cación.
Mostramos cómo implementar SGSI en la replicación mediados dleware, que
proporciona varias ventajas prácticas. Cambiar el middleware de replicación es
más fácil que cambiar el motor de base de datos, que es más complejo que
consta de líneas de código fuente a millones y podría ser de código cerrado como
Microsoft SQL Server y Oracle. La aplicación middleware es más fácil de
implementar; Puede ser utilizado con motores de diferentes fabricantes, y no tiene
que ser cambiado con mejoras en el motor.
625 Conferencia ICDE 2011
 Las principales contribuciones de este trabajo son las siguientes:
• Proponemos SGSI, un nuevo algoritmo de control de concurrencia para bases de
datos replicadas con SI réplicas. SGSI asegura 1SR, un nivel de aislamiento más
fuerte que el nivel de componentes individual y específico. Se demuestra
formalmente SGSI corrección;
• Somos los primeros en abordar el problema de agement hombre-readset
en un entorno replicado. Se introduce un marco de trabajo que proporciona
técnicas para extraer, representar y comunicar la readset entre las réplicas
en el sistema;
• Mostramos cómo implementar SGSI y construir un sistema replicado prototipo
de middleware. Proporcionamos soluciones ciones concretas para extraer el
readset de transacción de actualización y por su certi fi cación en el modelo
relacional;
• Llevamos a cabo extensos experimentos que muestran SGSI se ticas
corrección garantizando tical a un costo bajo rendimiento. El documento está
estructurado como sigue. Sección II proporciona información básica sobre el
aislamiento de instantánea y su anoma- reside. Definimos SGSI en la Sección III,
mientras que en la sección IV se muestra cómo SGSI se utiliza en un sistema
replicado. Se presenta el marco fi cación readset cado para un DBMS relacional en
la Sección V y readset catión fi cado en la Sección VI. Se discute la aplicación de
prototipos y evaluación experimental en la Sección VII. El documento termina con el
trabajo relacionado en la Sección VIII y conclusiones en la Sección IX.
II. segundo ANTECEDENTES
En esta sección se presenta una breve introducción a SI, GSI, 1SR y
proporcionamos ejemplos que muestran ciones ejecu- no serializables. SGSI evita
todas estas anomalías.
A. Control de concurrencia
Aislamiento de instantánea (SI). aislamiento de instantánea (SI) [5] proporciona a cada
transacción con una instantánea de la base de datos en el momento de inicio de la
transacción. aislamiento de instantánea está disponible en varios motores de bases de
datos, como Oracle, PostgreSQL y Microsoft SQL Server. Por otra parte, en algunos
sistemas que no implementen bloqueo de dos fases esquemas (2PL), incluyendo Oracle y
Post-greSQL, SI es el nivel de aislamiento más fuerte disponible. aislamiento de instantánea
tiene atractivas propiedades de rendimiento en comparación con bloqueo de dos fases
(2PL), en particular para las cargas de trabajo de lectura dominados: Bajo SI, las
transacciones de sólo lectura no puede ni bloque, ni abortar, y que no bloqueen las
transacciones de actualización concurrentes. Sin embargo, la IS permite un comportamiento
no serializable y puede provocar incoherencias.
Aislamiento de instantánea Generalizado (GSI). Aislamiento Generalizado Snapshot (GSI)
[13] se extiende SI a bases de datos replicadas. GSI permite transacciones a usar
instantáneas locales de la base de datos en cada réplica y proporciona las mismas
propiedades deseables no bloqueante y no abortan como SI para las transacciones de
sólo lectura. GSI tiene las mismas anomalías serializabilidad como SI.
Una sola copia Serializabilidad (1SR). La corrección principal cri- terion para bases de
datos replicadas es Uno-Copy Serializabilidad (1SR) [6]. El efecto es que las
transacciones realizadas en las réplicas de base de datos tienen un ordenamiento
que es equivalente a un ordenamiento obtenido cuando las transacciones se realizan
secuencialmente en una sola base de datos centralizada.
626
B. La serialización Anomalías Bajo SI
Dado que SI es más débil que la secuencialidad, permite que ciertas anomalías. Estas
anomalías también están autorizados por GSI ya que el Si es un caso especial de GSI.
SGSI impide que todas las anomalías de serialización.
Escribe inclinación de anomalías. El siguiente escenario puede introducir el sesgo de
escritura anomalía [5]. Asumir dos transacciones T 1 y
T 2 que retirar dinero de dos cuentas bancarias X y Y.
El banco impone la restricción de que la suma de X y Y es positivo. Actas T 1 y T 2
se ejecutan concurrentemente en una base de datos donde cada cuenta, X y Y, contiene
un saldo inicial de 50. La siguiente historia no es serializable, pero puede ser
generado en virtud de SI:
h 1 = R 1 ( X 0, 50), R 1 ( Y 0, 50), R 2 ( X 0, 50), R 2 ( Y 0, 50),
W 1 ( X 1, - 40), W 2 ( Y 1, - 40). Al final de esta historia se viola la restricción
impuesta por el banco.
Fantasma de anomalías. Phantoms [14] son ​causados ​por inserciones o
deleciones de elementos de datos. El efecto de este tipo de anomalía se muestra
en la siguiente historia no serializable:
h 2 = R 1 ( X 0, 50), R 1 ( Y 0, 50), R 2 ( X 0, 50), R 2 ( Y 0, 50),
W 2 ( Z 0, - 20), W 1 ( X 2, - 40). X y Y son cuentas ser- anhelo de un mismo grupo en
el que el banco debe cumplir un balance positivo. mientras que la transacción T 1 retira
90 de la cuenta X, transacción T 2 crea una nueva cuenta Z con una cuota de 20.
Estas operaciones dan lugar a un balance negativo de grupo.
Solo lectura Transacción Anomalía. los leer-
solamente transacción anomalías [17] resultado en en-
consistente salida de solo lectura actas.
h 3 = R 2 ( X 0, 0), R 2 ( Y 0, 0), R 1 ( Y 0, 0), W 1 ( Y 1, 20), do 1,
R 3 ( X 0, 0), R 3 ( Y 1, 20), do 3, W 2 ( X 2, - 11), do 2. Transacción T 1
20 depósitos en una cuenta de ahorros Y, transacción T 2 10 se retira de la cuenta
de cheques y paga menos 1 pena de sobregiro. Transacción T 3 simplemente da
salida a la balanza para el cliente. La anomalía en este ejemplo es que el usuario
ve valores 0 y 20 mientras que los valores fi nales son -11 y 20. Tales valores no se
informaron en una historia serializable.
III. SGSI C ONCURRENCY do CONTROL METRO ODELO
Aquí definimos SGSI y demostrar que garantiza rializability SE-. Primero se
introduce una versión multi-modelo de control de concurrencia para
formalmente definen SGSI y luego se prueba su corrección.
A. Base de datos y modelo de transacciones
Suponemos que una base de datos es una colección de elementos de datos fi ed única
identi. Varias versiones de cada elemento de datos pueden coexistir simultáneamente en la
base de datos, pero no hay un orden total entre las versiones de cada elemento de datos. UN instantánea
de la base de datos es un estado comprometido de la base de datos.
UN transacción T yo es una secuencia de lectura y escritura de elementos de datos,
seguido de una confirmación o un aborto. denotamos T yo 'S escribir sobre el tema X por W
yo( X yo). Si T yo ejecuta W yo( X yo)
y se compromete, a continuación, una nueva versión de X, denotado por X yo, se añade a la base de datos.
Por otra parte, denotamos T yo 'S de lectura sobre el tema
Y por R yo( Y j), Lo que significa que T yo lee la versión del tema Y
producido por transacción T j. T yo 'S confirmar o anular se denota
por do yo o UN yo, respectivamente. Para simplificar la presentación, se supone que las • R2. (SGSI No Escribir regla de impacto)
transacciones no contienen operaciones redundantes 1: ∀ T yo, T j de tal manera que do yo, do j ∈ h:

Una transacción lee cualquier artículo como máximo una vez y escribe cualquier artículo como 4- ¬ ( T j escribir-impactos T yo).
máximo una vez, y si una transacción escribe un artículo, que no ha leído ese artículo después. • R3. (SGSI No Lea regla de impacto)
∀ T yo, T j de tal manera que do yo, do j ∈ h:

Una transacción es solo lectura si contiene ninguna operación de escritura, y es actualizar de 5- ¬ ( T j lea-impactos T yo).
otra manera. El readset de transacción T yo, denotado
La regla de lectura R1 asegura que cada transacción lee sólo los datos confirmados, es
readset (T yo), es el conjunto de elementos de datos que T yo lee. Del mismo modo, la writeset de
decir, cada transacción observa una instantánea comprometida de la base de datos. Esta
transacción T yo, denotado writeset (T yo), es el conjunto de elementos de datos que T yo escribe.
instantánea podría ser cualquier instantánea que se ha tomado antes de que comience la
Añadimos información adicional a los writeset para incluir los viejos y nuevos valores de los
operación, que puede ser proporcionada fi eficientemente en un sistema distribuido.
elementos de datos escritos.

Reglas R2 y R3 límite que las transacciones pueden cometer. Este proceso

Una historia h sobre un conjunto de transacciones T = { T 1, T 2, ..., T norte}
se llama certi fi cación y veremos en la siguiente sección que requieren readsets
es un orden parcial ≺ tal que ( un) h contiene las operaciones de cada transacción en T; ( segundo)
comunicantes y writeset. La norma de no-escritura impacto R2 impide cualquier
para cada T yo ∈ T, y todas las operaciones
transacción de actualización T yo de cometer si se trata de escritura impactado por
O yo y O ' yo en T yo: Si O yo precede O ' yo en T yo, entonces O yo ≺ O ' yo en h;
otra transacción de actualización comprometida. Regla R3 es similar, evitando T yo
y C) Si T yo lee X de T j, entonces W j ( X j) ≺ R yo( X j) en h
de cometer si es impactado a leer.
[6]. Para simplificar fi niciones, asignamos un momento distinto a cada operación de base de
datos, lo que resulta en un orden total en consonancia con el orden parcial ≺.

C. SGSI corrección Teorema 1: (Serializabilidad.) R1, R2 y R3 aseguran uno

En SGSI, cada transacción T yo observa una instantánea de la base de datos que se copia serialización.
toma en algún momento, denotado instantánea (T yo).
Esta instantánea incluye las actualizaciones de todas las transacciones que se han
comprometido antes instantánea (T yo). Para discutir sobre las relaciones de tiempo entre Prueba: Dejar h ser una historia que satisface fi ca R 1, R 2, y R 3.

transacciones, utilizamos las siguientes de fi niciones de transacción T yo: Se demuestra que cada vez que hay una dependencia pag → q en h,
dónde pag es una operación en T yo y q es una operación en T j
en el mismo elemento de datos, y donde T yo y T j tanto cometer, entonces cometer (T yo)
• instantánea (T yo): el momento en que T yo 'S instantánea se toma.
precede cometer (T j). Esto implica que h
• cometer (T yo): el momento de la do yo, Si T yo comete. Definimos la relación impactos para
es una vista serializable, con el fin de serialización propuesta por el orden de los eventos
las transacciones de actualización.
cometer [31] (véase también el teorema 3.13 de [32]). Tenga en cuenta los posibles tipos de
• T j escribir-impactos T yo si y sólo si
dependencia.
writeset (T yo) ∩ writeset (T j) 6 = ∅, y
1) wr verdadera dependencia. Supongamos por algún artículo X, p =
instantánea (T i) < cometer (T j) < cometer (T yo).
W yo( X yo) y q = R j ( X yo). R 1 da directamente que
• T j lea-impactos T yo si y sólo si
cometer (T i) < instantánea (T j) y instantánea (T j) es antes cometer (T j). Por lo
readset (T yo) ∩ writeset (T j) 6 = ∅, y
tanto todo el intervalo de ejecución de T yo viene antes de que el intervalo
instantánea (T i) < cometer (T j) < cometer (T yo).
de ejecución de T j, y en particular cometer (T i) < cometer (T j).
Sólo las transacciones de actualización comprometidos puede impacto transacción de

actualización T yo. De sólo lectura transacciones y las transacciones no confirmadas no pueden impacto
2) ww salida-dependencia. Supongamos por algún artículo X, p = W yo( X yo), q
T yo. Cuando cometer una transacción de actualización activa T yo, decimos " T j impactos T yo ”En el
= W j ( X j) y X yo precede X j en el orden de la versión X. Ya que X ∈ writeset
sentido de que si T yo eran para cometer ahora, entonces T j impactaría T yo.
(T yo) ∩
writeset (T j), la intersección de writeset es no vacía. Ya que R 2 dice que ¬
B. SGSI De fi nición ( T j escribir-impactos T yo), vemos que, o bien cometer (T j) < instantánea (T yo)
si no
SGSI tiene tres reglas: R1 regula las operaciones de lectura, mientras que R2 y R3
cometer (T i) < cometer (T j). En el primer caso tenemos que todo el intervalo de
regulan cometer operaciones. Para cualquier historia h creado por SGSI, las siguientes
ejecución de T j viene antes de que el intervalo de ejecución de T yo, que
propiedades (índices yo, j, y k son diferentes):
contradice la colocación de la orden versión X yo antes de X j. Por lo tanto nos
quedamos con el último caso, es decir, cometer (T i) < cometer (T j).
• R1. (SGSI Leer Regla)
∀ T yo, X j de tal manera que R yo( X j) ∈ h:
3) rw anti-dependencia. Supongamos por algún artículo X, p =
1- W j ( X j) ∈ h y do j ∈ h;
R yo( X k), q = W j ( X j) y X k precede X j en el orden de la versión X. Ya que X ∈ readset
2- cometer (T j) < instantánea (T yo);
(T yo) ∩
3- ∀ T k de tal manera que W k ( X k), do k ∈ h:
writeset (T j), la intersección de readset (T yo) con
[ cometer (T k) < cometer (T j) o
writeset (T j) es no vacío. Ya que R 3 dice que
instantánea (T i) < cometer (T k)].
¬ ( T j lea-impactos T yo), vemos eso cometer (T j) <
1 Este supuesto no es restrictiva: Estas operaciones redundantes pueden ser añadidos al modelo, instantánea (T yo) o cometer (T i) < cometer (T j). En el primer caso tenemos
sino que complican la presentación. (por la regla R 1 y el hecho de que

627
 R yo( X k) ∈ h) ese cometer (T j) < cometer (T k) lo que contradice la colocaciónsido ejecutado en otras réplicas y han sido certi fi. Estos se aplican directamente a la
versión de pedido X k antes de
X j. Por lo tanto nos quedamos con el último caso, es decir,
cometer (T i) < cometer (T j).
IV. SGSI EN UN re ISTRIBUTED S SISTEMA
Réplica
Proxy
DBMS
equilibrador
equilibrador
de carga
de carga
Réplica
Proxy
Actualizar Transacciones
las transacciones de actualización
Actualizar y de sólo lectura DBMS Las solicitudes de certificación para
Actas
Fig. 1. Arquitectura del sistema de base de datos replicada SGSI.
SGSI se define en el apartado anterior. Aquí nos centramos en cómo utilizar SGSI en
el sistema distribuido. Se introduce un modelo de sistema distribuido y presentamos la
arquitectura de base de datos replicada. Proponemos un algoritmo de certi fi cación para
hacer cumplir las normas de SGSI R2 y R3. Nos remitimos a los aspectos aplicación a los
motores de bases de datos relacionales a la siguiente sección.
A. Modelo de Sistema Distribuido
Asumimos un sistema distribuido asíncrono compuesto por un conjunto de sitios
de bases de datos Réplica 1. . . Réplica norte que com- municar con un mensaje fiable
que pasa protocolo. No hay suposiciones se garantiza el tiempo necesario para los
mensajes a transmitir o posteriormente procesado. Cada sitio tiene una copia
completa de la base de datos.
B. Arquitectura del Sistema replicada
La arquitectura del sistema (Figura 1) se compone de tres tipos de componentes:
equilibrador de carga, de réplica y er fi cado. El diseño es consistente con el estado de
la técnica para middleware- sistemas basados ​en replicados de base de datos [9],
[11], [20], [21], [24].
Equilibrador de carga. El equilibrador de carga recibe transacciones de aplicaciones de
cliente y los pasa a las réplicas utilizando una estrategia de equilibrio de carga como de
round robin o menor número de conexiones. También transmite las respuestas de las
réplicas a los clientes.
er fi cado. El er certi fi realiza las siguientes tareas: (a) detecta y previene todo el sistema
de conflictos, y asigna un orden total para actualizar las transacciones que se
comprometen, (b) asegura la durabilidad de sus decisiones y transacciones
comprometidas, y (c) reenvía el writeset de cada transacción de actualización
comprometido con las réplicas en forma de la actualización de las transacciones.
Réplica. Cada réplica se compone de un proxy y un DBMS independientes que
emplean aislamiento de instantánea. El proxy recibe
las transacciones del cliente desde el equilibrador de carga y transacciones de actualización Del er
fi cado. transacciones de actualización son los que tienen
base de datos. Para las transacciones del cliente, el proxy se aplica la instrucción
SQL dentro de cada transacción a la base de datos, y envía la respuesta al cliente a
través del equilibrador de carga. Para instrucciones de actualización, el proxy extrae
el writeset parcial de la transacción para principios fi cación cado [11]. Se comprueba
si esta writeset parcial conflictos con cualquier writeset pendiente de las operaciones
de actualización para evitar el problema de interbloqueo oculto [33]. En el caso de
conflicto, transacción de actualización del cliente se aborta. Cuando el cliente solicita
a cometer una transacción, el proxy se compromete de inmediato si la transacción es
de sólo lectura. Para las transacciones de actualización, el proxy envía una solicitud
de certi fi cación para el ampli fi cado y espera una decisión. Cuando se recibe la
decisión de certi fi cador, el proxy se compromete (o aborta) la transacción a la base
de datos y envía el resultado al cliente.
certificador
certificador
certificador
Tolerancia a fallos. El sistema asume que el modelo de fallo de recuperación Crash
estándar [2]. En este modelo el fracaso, un anfitrión puede bloquearse de manera
independiente y posteriormente recuperarse. El ampli fi cado es ligero y determinista, y
puede ser replicado disponibilidad [11] utilizando el enfoque de máquina de estados [27]. El
equilibrador de carga es ligera, ya que mantiene sólo una pequeña cantidad de estado
suave y una conmutación por error (equilibrador de carga en espera) se puede utilizar para
la disponibilidad. El estado duro (persistente) en el sistema es mantenido por las réplicas de
bases de datos, y este estado es varios órdenes de magnitud mayor que el estado del
equilibrador de carga. Después de un fallo, el componente que ha fallado puede recuperar
usando enfoques estándar como se discute en el trabajo previo [11]. Este diseño no tiene
ningún punto único de fallo, ya que cada componente se replica.
En nuestra implementación, las réplicas de bases de datos se replican para un mayor
rendimiento. Utilizamos un solo equilibrador de carga y un ampli fi cado, que ambos también
pueden ser replicadas para una mayor disponibilidad. Como se muestra en el trabajo previo
[10], [11], [12], un solo equilibrador de carga y un solo er fi cado son su fi ciente para que
coincida con un sistema de base de datos replicada de hasta 16 réplicas.
C. SGSI Certi Algoritmo fi cación
Se presenta el algoritmo de cationes certi fi SGSI para el modelo distribuido
asíncrona. El objetivo del algoritmo es para cometer transacciones cuando satisfagan
SGSI gobierna R2 y R3. Con el fin de detectar y prevenir conflictos, el ampli fi cado
gestiona los writeset producidas por las transacciones confirmadas junto con la orden
de cometer. En términos generales, para cometer un transacción de actualización, la
réplica envía una solicitud de certi fi cación que contiene el readset transacción y
writeset. El ampli fi cado asegura que no hay ninguna transacción de actualización
comprometida que está impactando lectura (es decir, la readset sigue siendo válida) o
que impacta contra escritura (es decir, no hay escritura-escritura conflicto).
Base de datos de versiones. Cuando una operación de actualización se compromete, se crea una
nueva versión de la base de datos, identificados por un número de versión asignado por el ampli fi
cado formando el orden mundial comprometerse. Inicialmente, la base de datos se inicia en la
versión 0. Una réplica evoluciona a partir de la versión V yo a la versión V i + 1 aplicando el writeset de
transacción de actualización T que se compromete en la versión i + 1.
Sustitución de las marcas de tiempo. para la transacción T, ambos instantánea (T)
y cometer (T) se han definido en el modelo transaccional
628
algoritmo 1 Certificación Algorithm. teorema equivalente, Teorema 3: Certi fi cación en el modelo relacional, ya que
1- Cuando Réplica j envía ( V Reps j, writeset (T), readset (T)), es más relevante para nuestra aplicación en el modelo relacional.
certificador recibe y ejecuta:
Si validar( V Reps j, writeset (T), readset (T)) == falso entonces
enviar ( abortar,-,-) a Réplica j
V. C ERTIFICACIÓN F MARCO PARA R ELATIONAL DBMS
más
V dominar ← V master + 1 A. Modelo de transacción y Query Language
h ← T; gestionar writeset (T)
enviar ( cometer, V dominar) a Réplica j Empleamos un modelo de transacción relacional en el que cada transacción se inicia
enviar actualización ( V dominar, writeset (T)) a Réplica yo, yo 6 = j.
con una EMPEZAR declaración y termina con una
2- Cuando esté listo para comprometerse T, Réplica yo ejecuta:
COMETER o ABORTAR. Lectura y escritura se expresan a través de las consultas
enviar ( V Reps yo , writeset (T), readset (T)) a certificador
esperar hasta recibir ( resultado, V nuevo) de certificador SQL. Apoyamos un gran subconjunto de consultas SQL en una transacción. Las
Si resultado == cometer entonces notaciones utilizadas en el modelo de transacciones de SQL se resumen en la
db-aplicar-writeset ( writeset (T)) V yo ← V nuevo
Tabla I.
db-commit ( T)
más Las consultas SQL dentro de una transacción
db-abort ( T). A. SELECCIONAR lista expr DE R yo DÓNDE pred (R yo)
3- Cuando certificador envía refrescar ( V dominar, writeset (T j)), SEGUNDO. INSERTAR EN R yo VALORES ( valores)
Réplica k recibe y ejecuta: DO. ACTUALIZAR R yo CONJUNTO attr j = valor j DÓNDE pred (R yo)
db-aplicar-writeset ( writeset (T j)) RE. CANCELACIÓN de R yo DÓNDE pred (R yo)
V Reps k ← V dominar. MI. AGG SELECT ( attr) DE R yo DÓNDE pred (R yo)
AGRUPAR POR grupo attr
TENIENDO pred ( AGG ( attr))
F. SELECCIONAR lista attr

DE R 1 ... R yo... R norte

en cuanto a las marcas de tiempo. No podemos usar las marcas de tiempo en el
DÓNDE pred (R 1) LOP LOP ... pred (R yo)
modelo distribuido asíncrona, ya que requiere el acceso a LOP LOP ... pred (R norte)
tiempo global. En cambio, usamos versiones, de la siguiente manera: PODAR unirse a pred (R yo, R j)

• instantánea (T): la versión de la base de datos que T observa.

• cometer (T): la versión de cometer T.
Descripción del algoritmo. Tal como se presenta en el algoritmo 1, la er fi cado TABLA I
recibe una solicitud de certi fi cación que contiene el writeset, la readset y la versión S SÍMBOLOS T SED en SQL Q uery S UBSET.

Símbolo Descripción
de instantánea réplica. Dada una solicitud de certi fi cación de Réplica j para una
R yo Relación que pertenece al esquema de base
transacción T con
lista expr Lista de atributos y expresiones proyectadas como se utiliza en SQL
instantánea (T) = V Reps j, el ampli fi cado accede a todos los writeset comprometidos con SELECT declaración
valores Lista de valores de atributos como se usa en el SQL INSERT
una versión mayor que instantánea (T). Writeset con número de versión más pequeña o
declaración
igual a instantánea (T) pertenecer a las transacciones que se cometieron antes de la attr atributo de la relación R
pred (R yo) SQL predicado selección en atributos de la relación R yo
instantánea de T fue tomada y transacción T ve sus efectos. Para cada elemento
writeset visitada X, los controles certi fi er si X ∈ writeset (T) o unirse a pred (R yo, R j) SQL unirse predicado en la unión de los atributos R yo y R
j

pk Clave primaria
X ∈ readset (T), en ese caso T es abortado desde su comprometerse introduciría una @ pk valor de la clave primaria

transacción impactado en la historia y un mensaje de aborto se envía a Réplica j. Si certi AGG ( attr) Agregar( SUM, AVG, MIN, MAX, COUNT, TOP K)
aplicado en el atributo attr de la relación R
fi cación es exitosa, se confirma la transacción y el ampli fi cado asigna un orden grupo attr Atributo de relación R incluido en el
global de la operación que se convierte en la versión de la base de datos. Un mensaje AGRUPAR POR cláusula

pred ( AGG ( attr)) un predicado general sobre el valor de la suma incluida en el TENIENDO
de confirmación de respuesta se envía a Réplica j, y un mensaje de actualización que cláusula
contiene el writeset recién añadido se envía a todas las demás réplicas en el sistema. PODAR un operador lógico: O, Y, NO

La segunda parte de Algoritmo 1 se describen las acciones de la réplica cuando se
recibe una solicitud para cometer una transacción de actualización T. La versión réplica
de instantáneas, la writeset y la readset se envían a la ampli fi cado. Las esperas de
réplica para la respuesta fi cación cado para confirmar o anular T. En la tercera parte de
Algoritmo 1, cada réplica se aplica la writeset recibido en un mensaje de actualización
de su base de datos local.
Nuestro modelo básico incluye SQL declaraciones acceso una relación: SELECT,
UPDATE, DELETE, y INSERTAR. ING y agregados grupo- ( AGG es decir MIN, MAX,
AVG, SUM) son parte de nuestro modelo. También apoyamos las consultas que
implican más de una relación. Por último, nuestro lenguaje de consulta también
incorpora subconsultas, así como UNION, INTERSECT, SALVO, ORDER BY y DISTINTO,
cuyos detalles se han omitido debido a la falta de espacio.

Declaramos lo siguiente teorema para la corrección del algoritmo.

Teorema 2: (catión fi cado con versiones.) El algoritmo de Certificación (que
utiliza versiones) satisface SGSI reglas R2 y R3 (que se expresan en las marcas B. writeset

de tiempo). Writeset se utilizan para la certi fi cación y de propaga- ción de actualización.

Omitimos la demostración del Teorema 2, pero demuestran la prueba de una Suponemos que cada tupla en la base de datos es identi fi cados

629
por su valor de clave primaria. Tuplas de la writeset pueden introducirse por ACTUALIZAR, es órdenes de magnitud más pequeño que el tamaño de la base de datos en cada réplica.
INSERTAR o DELETE de SQL declaraciones en una transacción.
Un writeset es una lista de tuplas, incluyendo los antiguos y nuevos valores para
cada atributo de la tupla.
Si certi fi cación es exitosa, el ampli fi cado añade tanto a los viejos y nuevos
valores de la writeset a su base de datos y envía los nuevos valores de la writeset a las
réplicas para la propagación de actualización. El writeset de una transacción no es certi
fi. Como se muestra en la Sección VI-B es su fi ciente para certificar la readset.
Existen varios enfoques para extraer writeset, incluyendo activadores, Entrar ng fi
snif o apoyo directo del motor de base de datos (por ejemplo, en Oracle) [11], [21]. En
nuestro prototipo del writeset se extrae mediante la aplicación de los predicados de las
instrucciones de actualización en la base de datos de réplica ya que PARSE sentencias
SQL para extraer los readset. Se demuestra en la siguiente sección que readset certi fi
cación subsume writeset certi fi cación.
C. Readsets
Readset identificación es difícil y, hasta donde sabemos, este trabajo es el
primero a considerar este problema en un entorno replicado. En contraste con
writeset, identificando readsets utilizando las tuplas que son leídos por una
transacción basada en las claves primarias es una mala elección: En primer lugar, la
readset de una transacción es típicamente mucho más grande que el writeset, y es,
por lo tanto, caro enviar el conjunto de filas leídas en una transacción de la réplica a
la er fi cado. En segundo lugar, sin capturar predicados en el readset, fantasmas
podrían introducirse, obviando 1SR.
Nuestro enfoque se basa en la observación de que la readset de un SQL consulta
se define por su predicado. El readset es una lista de predicados expresados ​como SQL
consultas. Explicamos cómo extraer el readset en la Sección VI.
D. Gestión Writeset al Certi fi cador
El ampli fi cado gestiona dos estructuras de datos: un registro persistente (estado duro) y una base
de datos de la memoria principal (-estado blando). Los writeset de todas las transacciones de
actualización comprometidos se almacenan en el registro. Después de un accidente, certi fi cador utiliza
el registro para recuperar su estado.
El contenido de writeset comprometidos recientes se mantiene en una base de datos
en memoria llamado base de datos de cationes certi fi
(Certdb). El certdb se utiliza para certificar las transacciones de actualización
mediante la validación de sus writeset y readsets, y no es duradero como sus
contenidos pueden ser recuperados desde el registro de archivo. Certdb tiene un
esquema similar a la de la base de datos replicada, aumentada con un atributo de
versión en cada relación. Después de cometer un éxito, cada tupla en writeset de la
transacción se extiende con la versión cometer de la transacción y se inserta en la
relación correspondiente en certdb. Certdb contiene tanto los antiguos y los nuevos
valores de una tupla actualizada con el fin de apoyar a base de predicado certi fi
cación.
Certi fi cación debe ser ejecutado de forma rápida, ya que se requiere para cada
transacción de actualización. Esto se consigue manteniendo certdb pequeña y en
memoria. La cantidad de espacio que necesita el certdb es pequeño, ya que es
proporcional a la suma de todas las transacciones de actualización activas multiplicado por
el número de elementos de base de datos que las actualizaciones de transacción. tamaño
certdb
630
El ampli fi cado periódicamente la basura recoge sus estructuras de datos, manteniendo
un tamaño pequeño para certdb. writeset viejos se eliminan del registro fi l para limitar su
tamaño. Cuando el er fi cado recibe una solicitud de certi fi cación para una transacción
con una versión instantánea que es más antigua que certdb (es decir, cuando las
versiones anteriores han sido purgado de certdb), la transacción es abortada. Esto no
suele suceder desde certdb mantiene suficientes versiones para que este evento
improbable.
VI. R EADSET do ERTIFICACIÓN
Readset certi fi cación es una de las principales contribuciones de este trabajo. El
readset se extrae mediante la aplicación de una transformación automática de
consultas a cada sentencia SQL dentro de una transacción de fecha UP. La
transformación crea la consultas certi fi cación que son evaluados durante el proceso
de certi fi cación. En primer lugar introducimos básica certi fi cación y al lado del
mayor certi fi cación. Presentamos certi fi cación prueba de corrección para cada tipo
de transformación. Además, se muestra que readset certi fi cación subsume writeset
certi fi cación.
Certificamos los readsets para las transacciones de actualización. Transacciones de
sólo lectura no necesitan certi fi cación. En términos generales, para certificar la readset de
una transacción queremos asegurarnos de que si la transacción se ejecuta en la versión
más reciente se leería los mismos valores; es decir, no hay ninguna transacción
actualización simultánea cometido escribe en el readset.
Observamos que la INSERT, UPDATE y BORRAR mentos por el estado tienen
readsets desde cada SQL declaración en nuestro modelo tiene un predicado que define
la readset.
Para llevar a cabo la transformación de consulta y extraer el readset, la
réplica identi fi ca el predicado de cada ción estatal. La consulta fi cación cado el
resultado de la transformación incluye el predicado de la consulta original, así
como aa predicado versión que restringe certi fi cación a transacciones
simultáneas. El er fi cado ejecuta las consultas de certi fi cación de una
transacción dada T en certdb. El resultado de las consultas de certi fi cación
constituye el conjunto fl icto, denotado CS (T), de transacción
T. Si CS (T) 6 = φ, a continuación, la transacción T aborta; de lo contrario, no hay ninguna
transacción de impacto y T comete.
Teorema 3: (catión fi cado en el modelo relacional.) Cuando la certificación de transacción T
con aire conjunto conflicto CS (T), si hay una lectura impactante o transacciones de escritura
impactando en la historia, a continuación, CS (T) 6 = φ.
Se demuestra el teorema para cada tipo de declaración y exponer las consultas de
certi fi cación.
A. consultas SELECT
El readset de un SELECCIONAR declaración incluye cualquier tupla que coincide
con el predicado de selección pred (R yo) en los atributos de relación R yo. La réplica
construye la consulta fi cación cado usando el original SQL declaración mediante la
combinación de los siguientes componentes: (a) SELECCIONAR DE; ( b) la tabla de
destino de la SQL consulta; (C) el contenido de DÓNDE cláusula, y (d) la versión de
predicado.
Cados consultas fi cación: SELECCIONAR
A. SELECCIONAR DE R yo DÓNDE pred (R yo) Y
 versión> instantánea (T) Ya que t ∈ writeset (T j), T j modi fi ca tupla t. Usando el mismo razonamiento que en

ORDER BY y las proyecciones se ignoran porque no hacen influir en el el caso anterior, le comunicamos que el valor de t en la instantánea de T j También

funcionamiento del predicado. satisface el predicado de eliminación pred (R). Por lo tanto, tupla t está en certdb
y el valor de su atributo es la versión V j> instantánea (T yo).
Demostración del Teorema 3: Dejar T yo denotar una transacción de actualización para ser
certi fi, con su versión instantánea instantánea (T yo) y
Por otra parte, después de las consultas de certi fi cación de T yo se ejecutan en el er fi
readset (T yo) capturado en la consulta fi cación cado anteriormente. Dejar T j
cado, t ∈ CS (T yo) y T yo aborta.
ser una transacción que impactan lectura que creó la versión de base de datos
• INSERTAR declaración. En este caso transacción T yo intenta introducir tupla t en la
V j. Se demuestra que la CS (T yo) 6 = φ, cuales causas T yo abortar.
base de datos. La consulta certi fi cación de
Ya que T j lea-impactos T yo, T j escribe una tupla que coincide con el predicado T yo contiene un predicado en la clave principal de t. Dejar
de la SELECCIONAR if T yo serían ex ecuted en la versión V j. Dejar t ∈ R ser una T j ser una transacción de escritura-impactando que también inserta (o modi fi ed) t en
esta tupla. En este caso t ∈ certdb y V j> instantánea (T). Cuando el ampli fi cado
la base de datos en la versión V j. Ya que T j
ejecuta las consultas de certi fi cación de T yo, t partidos, tanto el predicado de comprometido, t existe en certdb y su atributo es la versión V j> instantánea (T yo). t
selección y la versión de predicado. Así desencadena las consultas de certi fi cación y t ∈ CS (T yo) y T yo aborta.

t ∈ CS (T yo).

Declaraciones B. Actualizar
C. Grupos y agregados
En esta sección se muestra cómo extraer y certificar la readset de instrucciones de
consultas agregadas tienen predicados especi fi cado por el DÓNDE
actualización. Un resultado importante de esta sección es que la certificación de la readset de
cláusula. Tales predicados determinan la readset. Cuando está presente en un agregado, el TENIENDO
instrucciones de actualización también detecta
cláusula restringe los grupos de agregación que aparecen en los resultados de la consulta.
ww conflictos y es, por lo tanto, no es necesario para certificar la writeset. Esta
Lo quitamos de la consulta de certi fi cación con el fin de validar los resultados para todos
afirmación se apoya en la demostración del Teorema 3.
los grupos. consultas agregadas se transforman de la siguiente manera:
El readset de una SQL ACTUALIZACIÓN declaración incluye cualquier PLE tu- que
coincide con el predicado en la tabla de destino. Del mismo modo, la readset de una BORRAR
declaración contiene ninguna tupla que coincide con la eliminación predicado. El readset de Agregados Certificación
MI. SELECCIONAR DE R yo DÓNDE pred (R yo) Y
una INSERTAR declaración es identi fi cado por la clave principal de las nuevas tuplas
versión> instantánea (t)
insertadas, basado en el hecho de que la base de datos comprueba la unicidad de la clave
El resultado de los agregados como AVG y SUMA depende del valor de
primaria. Estas condiciones son capturados por las siguientes consultas de certi fi cación:
cada tupla contenida en el conjunto sobre el que se evalúan. Sin embargo, el
resultado de MIN y MAX
se determina por el valor de una tupla; introducimos una optimización para este caso.
Certi fi cación de consultas: consultas de actualización
Considera el MAX donde el agregado AGRUPAR POR declaración no se encuentra.
SEGUNDO. SELECCIONAR DE R yo DÓNDE pk = @pk Y
Con el fin de determinar el valor máximo, la réplica DBMS lee todos los valores de la
versión> instantánea (T)
DO. SELECCIONAR DE R yo DÓNDE pred (R yo) Y relación. Si la transacción concurrente (a distancia) modi fi ca cualquiera de las tuplas
versión> instantánea (T) de la relación, hace que el agregado de abortar durante readset certi fi cación, incluso
RE. SELECCIONAR DE R yo DÓNDE pred (R yo) Y
si una transacción modi fi ca tuplas que no lo hacen influir en el resultado de MAX. En el
versión> instantánea (T)
momento en que las consultas cationes fi- cados se construyen el valor de la MAX agregado
Demostración del Teorema 3: Se demuestra que la hora de certificar T yo, Si a lo largo
T j escribir-impactos T yo, entonces CS (T yo) 6 = φ. Considere tupla t ∈ R
de tal manera que t ∈ writeset (T yo) y t ∈ writeset (T j). Consideramos que todos los casos que attr Ya se sabe y se supone que es igual a val max.
causan t ∈ writeset (T yo): Por otra parte, el resultado de los cambios globales si las transacciones concurrentes escribir
una de las tuplas R yo con attr ≥ val max. Sobre la base de la observación anterior, la consulta
• ACTUALIZAR declaración. En este caso transacción T yo modi fi ca tupla t lo que
de certi fi cación se puede re- escribirse como:
satisface el predicado actualización pred (R).
Ya que t ∈ writeset (T j), T j modi fi ca tupla t. El valor de t en la instantánea de T j También
satisface la actualización predicado pred (R). ( De lo contrario existe otra Agregados Certificación
transacción impactando contra escritura que modi fi ca t a partir de un valor que MI. SELECCIONAR DE R yo DÓNDE pred (R yo) Y
attr ≥ max val Y versión> instantánea (T)
satisface pred (R) a un valor que no lo hace. Esta transacción se confirma después
de la instantánea de T yo fue tomada y antes de la instantánea de T j fue tomada).
D. une
Por lo tanto, tupla t está en certdb y el valor de su atributo es la versión V j> instantánea
(T yo). Las uniones tienen SELECCIONAR consultas que implican a varios destinatarios
laciones re- R yo, i = 1 .. norte. Hay dos tipos de predicados, combinados por operadores
Por otra parte, después de las consultas de certi fi cación de T yo se ejecutan en el er fi lógicos conjuntivas y / o disyuntivos, que definen la readset. En primer lugar, los
cado, t ∈ CS (T yo) y T yo aborta. predicados de selección implican solamente atributos de una sola relación R yo y se denota
• BORRAR declaración. En este caso transacción T yo modi fi ca tupla t lo que por
satisface el predicado de eliminación pred (R). pred (R yo). En segundo lugar, los predicados de unión implican atributos que

631
definen la unión entre dos pares de relaciones R yo y R j y se denota por unirse a
pred (R yo, R j).
Hasta ahora, el er fi cado mantiene certdb, que contiene los writeset de
transacciones cometidos recientemente. Certdb no es suficiente para evaluar todos
los predicados y para certificar la readset. Se presenta una aproximación aquí y en
la siguiente subsección mostramos cómo mejorar el ampli fi cado para realizar re fi
ne certi fi cación para las uniones.
La certificación de un superconjunto de la readset. El ampli fi cado puede comprobar si
hay actualizaciones en cada relación individual que participa en la unión usando las
siguientes consultas certi fi cación:
Únete Certificación
para cada relación R yo:
F. SELECCIONAR DE R yo DÓNDE versión> instantánea (T)
Es fácil demostrar que estas consultas de certi fi cación garantizan el acierto ya que
ningún writeset comprometidos pertenen- ing a cualquiera de las R yo las relaciones de
destino.
E. Extended catión fi cado
Datos gestionados en Certi fi cador. Certi fi cación ideal debe satisfacer dos
propiedades: solidez (corrección, es decir, cuando una transacción es certi fi ed
con éxito, no hay lectura de impacto o escribir-impactando transacción
confirmada), y la integridad (precisión, es decir, si no hay lectura de impacto o
escribir impactando transacción, la solicitud de certi fi cación siempre tiene éxito).
El er fi cado mantiene solidez en todo momento, pero Ness COMPLETE- es una
función de la cantidad de datos mantenidos en el er fi cado. En un extremo del espectro,
el mantenimiento de los writeset recientes en el ampli fi cado, puede requerir el uso de
un superconjunto de la readset consulta. Este caso puede dar lugar a una interrupción
innecesaria. En el otro extremo del espectro, el mantenimiento de la base de datos
completa en el er fi cado logra integridad pero tiene el máximo por encima.
Innecesaria aborta puede suceder cuando el ampli fi cado no mantiene
información suficiente para evaluar los readset predicados de unión. Una alternativa
sería tener la réplica enviar esta información a la ampli fi cado; este enfoque es, sin
embargo, no es práctico, ya que es probablemente demasiado costoso enviar los
datos necesarios de la réplica a la ampli fi cado.
Otra alternativa es la de almacenar y mantener los datos necesarios para evaluar
los predicados de unión en el ampli fi cado. En esencia, esto es similar a mantener
una vista materializada en un sistema de base de datos. Aquí el ampli fi cado gestiona
una copia de las relaciones de referencia en la consulta y que denotan éstos respecto
de
R 1 C. . . R norte C. Relaciones utilizados en transacciones que son abortados con frecuencia son
buenos candidatos. El costo principal de mantener una relación en certdb es la memoria
necesaria para almacenar la relación, así como un aumento en el procesamiento de
consultas de certi fi cación.
Para mantener una relación en el ampli fi cado, lo extendemos con las versiones de
inicio y final ( V comienzo y V Fin) para determinar la visibilidad de cada tupla, similar a la forma
en versiones están controlados en un motor de almacenamiento fila multi-versión, por
ejemplo como en Postgres [29]. La versión más reciente de una tupla tiene V fin = - 1.
Para certificar la transacción T que contiene una consulta con un predicado arbitraria pred
consulta sobre las relaciones de destino R 1 ... R norte, introducimos dos predicados adicionales.
Con el fin de detectar las tuplas
632
que se actualizan después de la instantánea de T fue tomada, los cados cheques fi er
que V comenzar> instantánea (T) O V fin> instantánea (T).
A esto le llamamos el predicado actualización, denotado UPD (R yo C), y lo empleamos al
acceder a cualquier relación R yo do en el ampli fi cado. Con el fin de detectar las tuplas
que son visibles a la transacción T, las cados cheques fi er que NO( V terminar < instantánea
(T) Y V Fin 6 = - 1). A esto le llamamos el predicado visibilidad, denotado vis (R yo C),
y lo usamos para el acceso a cualquier relación R yo do en el ampli fi cado.
Todas SQL Las consultas se pueden certi fi cado en la copia fi cador cado de la base de datos
con el fin de reducir el superconjunto de la readset.
Unirse a la certi fi cación. Mostramos a continuación las consultas certi fi cación extendidas
para la combinación. Certi fi cación tiene éxito si no hay tupla devuelta, mostrando la ausencia
de cualquier transacción de impacto.
Certificación de consulta: se une
F. SELECCIONAR DE R 1 C ... R yo C ... R norte do
DÓNDE ( consulta pred)
Y ( UPD (R 1 C) ... O UPD (R yo C) ... O UPD (R norte C))
Y ( vis (R 1 C) ... Y vis (R yo C) ... Y vis (R norte C))
Prueba de Integridad de Certi fi cación:
Dejar T yo sea ​una operación que necesita ser certi fi y su readset es fi identificado
por la consulta de certi fi cación anterior. Se demuestra que si no hay ninguna
transacción de impacto, la solicitud de certi fi cación siempre tiene éxito.
Asume esta transacción es abortada, mientras que no hay ninguna transacción de ING a
los golpes. Si se cancela la transacción, la consulta de certi fi cación devuelve al menos una
tupla. Considere el conjunto de instancias
t R yo ∈ R yo que satisfagan pred consulta y producir esta tupla en el resultado unirse.
Esto implica que hay al menos un caso tupla t R ∈ R en este conjunto que coincide
con el predicado versión UPD (R). Por lo tanto, tenemos V comenzar> instantánea (T yo) o
V fin> instantánea (T yo). Esto implica, además, que existe una transacción que cometió
después de la instantánea de T yo fue tomada y modi fi tupla ed t R. Dado que todos los
componentes t R yo que satisfagan las pred consulta son visibles a T yo, nuestra hipótesis
inicial de que no hay ninguna transacción de impacto se contradice.
Prueba de Certi fi cación Solidez:
Dejar T yo sea ​una operación que necesita ser certi fi y su readset es fi identificado
por la consulta de certi fi cación anterior. dejar que la transacción T j ser una transacción
de impactar que modi fi ca tupla
t R ∈ R y se crea la versión V j.
Se demuestra que las consultas de certi fi cación de T yo informe al menos un resultado y
transacción T yo aborta.
Desde la actualización de la tupla t R en la transacción T j hace que la modi fi cación de
un artículo leído por transacción T yo, hay un conjunto de tuplas t R yo ∈ R yo, i = 1 .. norte y t R influye
en la capacidad de este sistema para satisfacer el predicado pred consulta. Esto implica
además que todas las tuplas t R yo son visibles para la transacción T yo.
Además, t R pueden influir en el resultado de la pred consulta
evaluación si: (a) que era parte de un conjunto de tuplas que coincidía con el predicado y
se modi fi ed por T j, o (b) se trata de una nueva instancia creado por T j que completa un
conjunto de tuplas tales que satisfacen el predicado. El mismo conjunto de tuplas se
mencionó anteriormente satisface la pred consulta y los predicados de visibilidad vis (R yo),
i = 1 .. norte de las consultas de certi fi cación cuando se evalúan en la copia certi fi
cador de la base de datos. Sin embargo, en el caso (a),
tupla t R tiene V fin = V j mientras que en el caso (b), V start = V j.
V j> instantánea (T yo) y en ambos casos el predicado actualización
UPD (R) también es satisfecha. Por lo tanto, la consulta de certi fi cación tiene al menos una
respuesta y T yo aborta.
VII. PAG ROTOTYPE yo Y APLICACIÓN mi VALUACIÓN
Construimos un sistema replicado para la evaluación experimental. La arquitectura
del sistema se describe en la Sección IV. Extendemos el prototipo con un front-end
servidor web.
A. Aplicación
Cada réplica se ejecuta una aplicación multiproceso C # como el proxy y se ejecuta
una instancia local de Microsoft SQL Server 2008 como la base de datos. SQL Server
es con fi gurado para ejecutar transacciones a nivel de aislamiento de instantánea con
el bloqueo de filas. Réplicas reciben las transacciones del cliente a través de la interfaz
web y extraer el readset y writeset de cada transacción. El readset es auto-
máticamente fi identificado por la réplica del texto de SQL consultas. Nos analizar este
texto y localizar las relaciones de destino, así como los predicados de la consulta.
Entonces, construimos las consultas de certi fi cación como se explica en las secciones
VI, incluyendo extendido certi fi cación en la Subsección VI-E. El writeset se extrae de la UPDATE,
DELETE y INSERTAR declaraciones. Extraemos el predicado de ACTUALIZAR y BORRAR
declaraciones y generar consultas para capturar los writeset. Nótese que en el caso de ACTUALIZAR,
capturamos tanto los nuevos y viejos valores.
El ampli fi cado se implementa como una aplicación C #. Utiliza una base de datos
en memoria SQLite.NET para la detección de conflicto. SQLite.NET limita la
aplicación a una sola ción conexiones a la base de datos en memoria, la serialización
de detección de conflicto.
Los lotes fi cados er compromete a la base de datos en memoria para mitigar los
costos de cometer. Experimentalmente se encontró compromiso ting después de 32 lotes
de certi fi caciones proporciona una mejor pasante poner y descamación. El ampli fi cado
también limpia periódicamente el estado antiguo de la base de datos en memoria para
limitar el uso de memoria y mejorar el rendimiento. En las mediciones presentó el periodo
de limpieza era cada 5000 cationes fi cados y registros mayores de 1000 versiones son
eliminados.
El prototipo implementa la consistencia de sesiones [8], donde cada cliente ve el aumento
de las versiones del sistema de base de datos, y después de un cliente se compromete una
transacción de actualización, la siguiente transacción cliente observa los efectos de esta
actualización.
El componente de cliente web y equilibrador de carga es una aplicación de C #
ASP.NET se ejecuta bajo IIS 7.0. El Ator gene- carga emula clientes que impulsan
la parte delantera. Cada cliente emulado se une a una sesión y genera peticiones,
ya que es impulsado a través del modelo cliente. Las solicitudes se envían a las
réplicas con la política de equilibrio de carga round-robin.
El generador de carga implementa el de- navegador emulador trazada en la especi
fi cación TPC-W [30] y es no modificada fi ed de proyectos de investigación anteriores
[11], [13].
B. Componentes hardware
Las máquinas utilizadas para el ampli fi cados y base de datos réplicas son Dell Optiplex 755
funcionamiento de 64 bits de Windows Server 2008. Cada
633
tiene un procesador Intel Core 2 Duo corriendo a 2,2 GHz con 2 GB de memoria
DDR2, y una unidad de 250 GB 7200 RPM SATA.
El generador de carga y la interfaz web (y equilibrador de carga) se ejecutan en
Dell T3500 con procesadores Intel Xeon E5520 y 4 GB de memoria que ejecutan
Windows Server 2008. El generador de carga, front-end web y el equilibrador de
carga están bien aprovisionados de manera que no se conviertan en un cuello de
botella en cualquier experimento. Todas las máquinas tienen una única interfaz gigabit
Ethernet y están conectados a un conmutador Gigabit Ethernet.
C. TPC-W Benchmark
TPC-W modelos de un sitio de comercio electrónico, en forma de una librería en
línea. La especi fi cación TPC-W requiere 14 interacciones dife- rentes, cada uno de los
cuales debe ser invocados con una frecuencia particular. De estas interacciones, ocho
iniciar transacciones de actualización, mientras que los otros seis generan
transacciones de sólo lectura. Cada interacción también puede implicar múltiples
solicitudes de imágenes incrustadas para artículos en el inventario.
Mezclas. TPC-W tiene tres mezclas de carga de trabajo que varían en la fracción de transacciones de
actualización. los mezcla de navegación carga de trabajo tiene un 5% en actualizaciones, las mezcla
comercial carga de trabajo tiene 20% actualizaciones y la mezcla de pedidos carga de trabajo tiene un
50% actualizaciones. los mezcla comercial es la mezcla principal, pero hemos explorado todas las
mezclas en nuestros experimentos. Durante la propagación de actualización, el tamaño medio de
writeset es de unos 300 Bytes.
Tamaño de base de datos. En nuestros experimentos, los parámetros de escala base de
datos de TPC-W 200 son EBS (navegadores emulados) y 10000 artículos. Cada
experimento comienza con la misma base de datos inicial de 850 MB. Los bene fi base
de datos dentro de la memoria disponible en cada réplica (2 GB). Esta opción maximiza
la demanda de recursos de procesador en la réplica y en el ampli fi cado. Una base de
datos más grande tendría un mayor componente de E / S y plantean un reto menor
rendimiento.
Intervalo de medición. Cada experimento corrió con un periodo de calentamiento de 3
minutos seguido de un intervalo de medición 5 minutos.
Benchmark D. SmallBank
La referencia SmallBank [3] modelos de una base de datos de banca sencilla. Se
compone de tres tablas: Cuenta (nombre, ID del cliente), verano (ID del cliente, el
equilibrio) y de control (ID del cliente, el equilibrio). Contiene cinco tipos de transacción
para Ance equili- (Bal), depósito de comprobación (DC), retirar-from-comprobación
(WC), transferencia a ahorros (TS) y amalgamar (GAS) que se asignan de manera
uniforme a los clientes. La transacción Bal es de sólo lectura, mientras que CC, WC,
TS y AMG son las transacciones de actualización. SmallBank no es serializable en
virtud de SI y GSI.
Utilizamos una base de datos que contiene 1000 clientes generados aleatoriamente y
sus cuentas corrientes y de ahorro (como em- pleados en trabajo previo [7]). El piloto de
pruebas ejecuta las cinco posibles transacciones con distribución uniforme, creando una
carga de trabajo con las transacciones de actualización 80%. El controlador utiliza un hilo
por cliente. El tiempo de ejecución para cada experimento es de 300 segundos. Cada
experimento se repite 10 veces y las barras de error en la Figura 8 muestran la
desviación estándar.
 60000 400
1-réplica SGSI 8-réplica GSI
1-réplica GSI 8-réplica SGSI
350
50000 2-réplica SGSI
2-réplica GSI
300
4-réplica SGSI
40000
4-réplica GSI
8-réplica SGSI 250

Tiempo de respuesta, ms
0 8-réplica GSI
Rendimiento, TPM

200

30000
150

20000
100

10000
50

0
0 150 300 450 600 750 900 1050 10000 20000 30000 40000 50000

Número de clientes Rendimiento, TPM

Fig. 2. Rendimiento de TPC-W Compras Mix (20% actualizaciones). Fig. 4. Escalabilidad de TPC-W Compras Mix (20% actualizaciones).
4500 100
1-réplica SGSI 8-réplica GSI

4000 1-réplica GSI 8-réplica SGSI

2-réplica SGSI
2-réplica GSI 80
3500
4-réplica SGSI

3000 4-réplica GSI

Certificador utilización de la CPU,%

8-réplica SGSI
Tiempo de respuesta, ms

60
2500 8-réplica GSI

2000
40

1500

1000
20

500

0 0
0 150 300 450 600 750 900 1050 10000 20000 30000 40000 50000

Número de clientes Rendimiento, TPM

Fig. 3. Resp. Tiempo de TPC-W Compras Mix (20% actualizaciones). Fig. 5. Certi util fi er CPU., Compras TPC-W (20% actualizaciones).

E. TPC-W Evaluación del Desempeño
Nuestro objetivo es mostrar que SGSI es un algoritmo de replicación práctica con un
rendimiento competitivo. Investigamos su escalabilidad y los gastos generales. Utilizamos
el punto de referencia TPC-W para evaluar el rendimiento SGSI ya que se utiliza
ampliamente para evaluar los sistemas de base de datos replicada [11], [22], [33], [20].
1) El escalado de SGSI con replicación Grado: Utilizamos la carga de trabajo
principal de TPC-W, la mezcla comercial (de 20% actualizaciones) para evaluar la
escalabilidad del sistema bajo SGSI en las Figuras 2 y 3. variar el número de clientes a
partir de 150 a 1050 a lo largo del eje X, y representamos gráficamente cuatro curvas
para los sistemas 1, 2, 4 y 8 réplica SGSI (y se discute curvas GSI en siguiente
subsección). El eje Y es o bien el rendimiento en TPM (transacciones por minuto) o el
tiempo medio de respuesta en ms (milisegundos). Replicación aumenta el rendimiento
pico, en particular el sistema 8-réplica llega a 51.000 TPM, que es 4X la sola actuación
réplica. La replicación también se utiliza para reducir el tiempo de respuesta promedio;
en los 1050 clientes, el tiempo de respuesta se reduce de 4000 ms a 1 réplica a 230 ms
a 8 réplicas. Llegamos a la conclusión de que el sistema SGSI ofrece una buena
escalabilidad con el número de réplicas para aumentar el rendimiento o reducir el
tiempo de respuesta promedio.
contra el tiempo de respuesta para un sistema de 8-replica utilizando la Cesta de la Mix
TPC- W para ambos SGSI y GSI Certificación.
La curva SGSI es ligeramente por debajo de GSI, lo que demuestra que no tienen
casi el mismo rendimiento. Para explicar la diferencia entre las curvas de SGSI y GSI,
estudiamos la sobrecarga de SGSI certi fi cación, en términos de tiempo de respuesta
certi fi er y abortar tasa. La CPU es el cuello de botella de los recursos en el ampli fi
cado. La Figura 5 muestra que la utilización de la CPU fi er cado es menos del 60% y
43% para SGSI y GSI respectivamente. tiempo de respuesta Certi fi er para SGSI varía
de 7-20 ms y para GSI varía de 4-6 ms como la carga en el er fi cado varía de
8000-51000 TPM.
Las tasas de abortar que observamos para SGSI en nuestros periments ex TPC-W son
bajos: la mezcla de compras tiene un máximo de 8% de las transacciones abortadas. Para
todas las mezclas, vemos el número de aumento se interrumpe con la tasa de certi fi
caciones. Un estudio más detallado de los tipos de abortar se presenta en la Sección VII-F.
En las figuras 2 y 3, el rendimiento de GSI y SGSI se muestran para diferentes
grados de replicación. El rendimiento de SGSI y GSI son casi idénticos en rendimiento y
tiempo de respuesta para todos los grados de replicación. Llegamos a la conclusión de
que SGSI introduce una pequeña sobrecarga en comparación con GSI debido al
procesamiento adicional necesario para garantizar una sola copia serializabilidad.

2) Comparando SGSI a GSI: El rendimiento de GSI representa un límite 3) Modificar la sensibilidad a la Relación de Transacción: Pasamos ahora a estudiar cómo
superior en el rendimiento de SGSI. SGSI certi fi ca readsets y writeset para SGSI escalas en diferentes proporciones de las transacciones de actualización. Si es de sólo

proporcionar serializabilidad, mientras que sólo GSI certi fi ca writeset. La Figura lectura de la carga de trabajo, la replicación debe ceder escalabilidad lineal. Actualizar dominada

4 muestra el rendimiento cargas de trabajo de la

634
 90000
TPC-W Navegación Mix 8-réplica de ww conflicto rw
80000 TPC-W Compras Mix Mix TPC-W Orden de conflictos
8 réplicas de 8 réplicas pivotes
70000

60000
14

50000

Los conflictos,%
Rendimiento, TPM

12
40000

0 10

30000
68

20000
24
10000

0 250 500 750 1000 1250 1500

10 25 50 100 150 200 250 300

Número de clientes Nivel de múltiples Programación

Fig. 6. SGSI Throughput de TPC-W mezclas. Fig. 8. Los conflictos con SmallBank (80% actualizaciones).
900
TPC-W Navegación Mix 8-réplica de

800 TPC-W Compras Mix Mix TPC-W Orden de

8 réplicas de 8 réplicas
La Figura 8 muestra el aumento de las tasas de abortar como el nivel de
700

tiprogramming ples aumenta de 10 a 300. SGSI y GSI tanto abortar ww conflictos,

600
mientras rw conflictos solamente son abortados bajo SGSI para garantizar una sola copia
Tiempo de respuesta, ms

500
serializabilidad. El adicional aborta desde rw conflictos bajo SGSI son estrictamente
400
inferior a la línea de base ww conflicto aborta. Esto sugiere que SGSI tiene un ligero
300 efecto sobre las tasas observadas para abortar. Esto es importante ya que las cargas de

200 trabajo de los motores SI tienen tasas bajas para abortar.

100

Al examinar la rw conflictos, la cuestión que se plantea es el número que conduce a

0
0 250 500 750 1000 1250 1500 errores de serialización. Las pruebas para detectar dad serializabil- es un conocido
Número de clientes
problema NP-completo, y todas las técnicas de control de concurrencia serializables

Fig. 7. SGSI Tiempo de Respuesta de TPC-W mezclas.

prácticos abortar transacciones que podrían ser serializado. La figura 8 muestra el
número de pivotes como un límite superior sobre los posibles errores de serialización.
Un pivote tiene una entrada y una salida rw- dependencia en el gráfico seriabilidad [7]
que indica una estructura peligroso que podría ser unserializable [16]. Nuestros
replicación puede dar poca mejora del rendimiento, o incluso una degradación,
resultados muestran hasta un 2,5% de
como el número de aumentos de réplicas, ya que los cambios tienen que ser certi
fi y se aplican en cada réplica.
rw conflictos son pivotes y sugieren que la mayoría de rw
Utilizamos las tres mezclas TPC-W para caracterizar la perfor- mance del SGSI
conflictos sería serializable íbamos a construir la gráfica de múltiples versión
de las cargas de trabajo de lectura dominada para actualizar las cargas de trabajo
serializabilidad y que no haya ciclo.
intensivas. Las figuras 6 y 7 muestran el rendimiento y tiempos medios de
respuesta para un sistema de SGSI 8-replica como el número de clientes TPC-W
VIII. R EXALTADO W TRABAJO
varía. El Browsing Mix (5% actualizaciones) se lee dominado y las figuras muestran
El trabajo relacionado con el aislamiento de instantánea (SI) y aislamiento
que su rendimiento escalas casi linealmente hasta 88.000 TPM, que es 7X la sola
Generalizado Snapshot (GSI) se ha discutido en la sección II-A. Aquí presentamos el
actuación réplica. Bajo la mezcla comercial (20% actualizaciones) el rendimiento
trabajo en serializabilidad y replicación emparentados.
alcanza un pico de 51.000 TPM: 4X la sola actuación réplica. El Mix de pedido (50%
Serializabilidad. Serializabilidad [6], [23] es el criterio más comunes de corrección de
actualizaciones) alcanza un rendimiento de 19.500 TPM en 8 réplicas, que es 2
base de datos. Los investigadores han investigado seriabilidad garantizando en sistemas
veces el rendimiento de una única réplica. Como era de esperar, los beneficios de
centralizados tanto al usar niveles de aislamiento más débiles y cuando se utiliza el
la replicación depende de la relación de cambios.
conocimiento fi específico de la aplicación. Adya et al. [1] han proporcionado una base
teórica para especificar formalmente los niveles de aislamiento prácticas para bases de
datos comerciales. Atluri et al. [4] han estudiado la alizability SERIAS de los niveles de
aislamiento más débiles tales como los niveles de aislamiento ANSI SQL para bases de
Análisis Abort F. vía SmallBank
datos centralizadas. Shasha et al. [28] han presentado las condiciones que permiten que
Se analiza el impacto sobre las tasas de SGSI abortar bajo diferentes niveles de una transacción se divide en pequeños sub-transacciones que liberan los bloqueos antes
multiprogramación. Las tarifas de abortar reportados para TPC- W en la sección VII-E2 son de la transacción original con las políticas de bloqueo tradicionales.
bajos y otros han informado de hallazgos similares [10], [33]. Utilizamos el punto de
referencia SmallBank como su carga de trabajo se compone de 80% actualizaciones y es
compatible con un número variable de clientes. SmallBank se utilizó para evaluar haciendo Serializabilidad bajo SI. Varios investigadores [15], [16], [13] han demostrado
SI serializable tanto dentro de, y fuera de, los motores SI [3], [7]. recientemente que, bajo ciertas condiciones en la carga de trabajo, las transacciones
que se ejecuta en una base de datos con SI

635
producir historias serializables. Aislamiento de instantánea Serializable (SSI) [7] es un
mecanismo de control de concurrencia que impone seriabilidad mediante la corrección de
anomalías permitidos por SI. SSI se lleva a cabo en el interior del motor de base de datos
y se detecta y previene las anomalías en tiempo de ejecución.
Replicados Database Systems. Gray et al. [18] tienen clasifi- fi replicación de bases de datos
ed en dos esquemas: ansiosos y perezoso. replicación Eager proporciona consistencia a costa
de escalabilidad limitada. Lazy replicación aumenta el rendimiento al permitir réplicas para
divergen, la exposición de los clientes a los estados inconsistentes de la base de datos. El
prototipo que utilizamos tiene características de ambos sistemas (por ejemplo, se necesita
cada vez hay reconciliación) vago (por ejemplo, en la propagación de actualización) y
ansiosos.
SI replicado Database Systems. Kemme et al. aplicar Postgres-R [19], e integrar la
gestión de réplica con el control de concurrencia base de datos [21], [33] en
Postgres-R (SI). Plattner et al. [24] presente Ganymed, un esquema maestro-esclavo
para la replicación de bases de datos de instantánea aislados en grupos de máqui-
nas. Tashkent [11], [12] es un sistema de base de datos replicada que proporciona
GSI y Pangea [22] utiliza la propagación de actualización ansioso. Ninguno de estos
sistemas garantiza serializabilidad.
SI federados Database Systems. Schenkel et al. [26] discutir el uso de la IS en bases de datos
federadas donde los datos de acceso a las transacciones globales distribuidos a través de
múltiples sitios. Sus protocolos garantizan la IS a nivel de federación en lugar de
serializabilidad. En un trabajo posterior [25], un algoritmo de emisión de billetes garantiza
serialización en bases de datos federadas SI. transacciones de actualización globales se eje-
cuta secuencialmente en orden de boletos. Por el contrario, SGSI aborda el problema de la
replicación en lugar de la federación, y las transacciones de actualización ejecutar
simultáneamente en las réplicas.
IX. do CONCLUSIONES
Este estudio investiga proporcionar un nivel de aislamiento global en sistemas de
bases de datos replicadas más fuerte que el nivel previsto a nivel local por las réplicas
individuales. Introducimos SGSI, una técnica de control rencia concurrente que asegura
una sola copia seriabilidad en sistemas replicados en el que cada réplica es aislado
instantánea. Empleamos técnicas novedosas para extraer readsets de transacción y
realizar mejorada catión fi cado. Implementamos SGSI y construir un prototipo de
sistema replicado y evaluamos su desempeño para demostrar que SGSI es práctico. Los
resultados de rendimiento en virtud de las mezclas de carga de trabajo del TPC-W
muestran que el rendimiento del sistema replicado escala con el número de réplicas.
UN GRADECIMIENTOS
Estamos muy agradecidos a Konstantinos Krikellas por sus contribuciones ciones a
nuestro sistema experimental, Tim Harris por sus interesantes comentarios, Zografoula
Vagena que participaron en las primeras etapas de este trabajo, y M. Tamer ¨
Özsu por sus sugerencias.
Mohammad Alomari nos proporcionó marca el pequeño banco evaluación
comparativa. Fernando Pedone y Willy Zwaenepoel sugirieron la posibilidad de
construir un sistema GSI que proporciona 1SR.
R EFERENCIAS
[1] A. Adya, B. Liskov, y PE O'Neil. Generalizado nivel de aislamiento
De fi niciones. En ICDE 2000.
636
[2] MK Aguilera, W. Chen y S. Toueg. detección de fallos y
consenso en el modelo de choque de recuperación. En Proc. 12 Intl. Simposio sobre computación
distribuida, 1998.
[3] M. Alomari, M. Cahill, A. Fekete, y U. Rohm. El costo de
serializabilidad en plataformas que utilizan el aislamiento de instantánea. ICDE 2008.
[4] V. Atluri, E. Bertino, y S. Jajodia. Una formulación teórica para
Grados de aislamiento en las bases de datos.
[5] H. Berenson, P. Bernstein, J. Gray, J. Melton, E. O'Neil, y P. O'Neil.
Una crítica de los niveles de aislamiento ANSI SQL. En SIGMOD, páginas 1-10, Nueva York,
NY, USA, 1995. ACM. [6] P. Bernstein, V. Hadzilacos, y N. Goodman. Control de concurrencia y
Recuperación de Bases de Datos. Addison-Wesley, 1987. [7] MJ Cahill,
U. r ohmios, y AD Fekete. Aislamiento Serializable para
Bases de datos de instantánea. En SIGMOD'08.
[8] K. Daudjee y K. Salem. La replicación de bases de datos perezoso con pedidos
Garantías. En ICDE '04, páginas 424-436, 2004. [9] K. Daudjee y K. Salem. La replicación de bases
de datos perezoso con instantáneas
Aislamiento. En VLDB '06, páginas 715-726, 2006. [10] S. Elnikety, S. Dropsho, E. Cecchet, y
W. Zwaenepoel. predecir
Replicado escalabilidad de base de datos de base de datos independiente pro fi ling. En
EuroSys 2009.
[11] S. Elnikety, S. Dropsho, y F. Pedone. Tashkent: Uniendo Durabilidad
con la Orden de Transacción de alto rendimiento de replicación de bases de datos escalable. En EuroSys
2006.
[12] S. Elnikety, S. Dropsho, y W. Zwaenepoel. Tashkent +: Memory-
Consciente de equilibrio de carga y actualización de bases de datos de filtrado en replicados. En EuroSys 2007.
[13] S. Elnikety, W. Zwaenepoel, y F. Pedone. La replicación de bases de datos utilizando
Aislamiento de instantánea generalizada. SRD 2005.
[14] K. Eswaran, J. Gray, R. Lorie, y I. Traiger. Las nociones de consistencia
Cerraduras y predicado en un sistema de base de datos. Comm de la ACM 1976.
[15] A. Fekete. La asignación de los niveles de aislamiento de transacciones. En VAINAS 2005.
[16] A. Fekete, D. Liarokapis, E. O'Neil, P. O'Neil, y D. Shasha. Fabricación
Aislamiento de instantánea Serializable. ACM Trans. Db. Sys., 30 (2), 2005. [17] A. Fekete, E.
O'Neil, y P. O'Neil. Una transacción de sólo lectura anomalía
bajo el aislamiento de instantánea. SIGMOD Rec., 33 (3): 12-14, 2004. [18] J. Gray, P.
Helland, P. O'Neil, y D. Shasha. Los peligros de
Replicación y una solución. En SIGMOD 1996.
[19] B. Kemme y G. Alonso. No sea perezoso, Sea consistente: Postgres-R,
Una nueva forma de implementar la replicación de bases de datos. En VLDB 2000.
[20] K. Krikellas, S. Elnikety, Z. Vagena, y O. Hodson. Muy en consonancia
La replicación de una ganga. ICDE 2010.
[21] Y. Lin, B. Kemme, M. Patino-Mart'ınez, y R. Jim' enez-Peris. Medio-
cerámica basada en la replicación de datos que proporciona aislamiento de instantánea. SIGMOD
2005.
[22] T. Mishima y H. Nakamura. Pangea: Una base de datos de replicación con ganas
middleware garantizando el aislamiento de instantánea sin modi fi cación de los servidores de base de
datos. En VLDB 2009.
[23] CH Papadimitriou. La Teoría de la base de datos de simultaneidad de control. W.
H. Freeman & Co., Nueva York, Nueva York, EE.UU., 1986.
[24] C. Plattner y G. Alonso. GANYMED: Replicación escalable para Trans-
Aplicaciones Web accionales. Middleware 2004.
[25] R. Schenkel y G. Weikum. La integración de aislamiento de instantánea en
Federación transaccional. En CooplS 2002.
[26] R. Schenkel, G. Weikum, N. Weienberg, y X. Wu. Federated
gestión de transacciones con aislamiento de instantánea. En Octavo Int. Taller sobre
Fundamentos de modelos y lenguajes de datos y objetos - Operaciones y Dinámica de bases
de datos, 1999.
[27] FB Schneider. Gestión de la replicación mediante la máquina de estados
Enfoque. ACM Press / Addison-Wesley Publishing Co., 1993. [28] D. Shasha, F. Llirbat, E.
Simon, y P. Valduriez. Picar la transacción:
Algoritmos y Estudios de Performance. ACM Trans. Db. Sys., 20 (3). [29] M. Stonebraker. El diseño
del sistema de almacenamiento de postgres. VLDB 1987.
[30] El Consejo de Procesamiento de Transacciones (TPC). El punto de referencia TPC-W.
http://www.tpc.org/tpcw.
[31] W. Weihl. Propiedades: Atomicidad locales modular el control de concurrencia
para los tipos de datos abstractos. ACM Trans. Prog. Lang. Syst., 11 (2), 1989. [32] G. Weikum y
G. Vossen. Sistemas de información transaccional: Teoría,
Algoritmos, y la práctica del control de concurrencia y recuperación.
Morgan Kaufmann Publishers Inc., San Francisco, CA, EE.UU., 2001. [33] S. Wu y B. Kemme.
Postgres-R (SI): La combinación de control de la reproducción con
Control de concurrencia basado en el aislamiento de instantáneas. En ICDE 2005.