En las bases de datos particionadas, cambiar algo de consistencia por

disponibilidad puede conducir a grandes mejoras en la escalabilidad.

Las aplicaciones web han crecido en popularidad durante la ltima dcada. No importa si usted est
construyendo una aplicacin para usuarios finales o para desarrolladores, es probable que espere
que su aplicacin encuentre amplia adopcin, y con la amplia adopcin vendr el crecimiento
transaccional. Si su aplicacin depende de la persistencia, el almacenamiento de datos,
probablemente se convertir en su cuello de botella.
Hay dos estrategias para escalar cualquier aplicacin. La primera, y por mucho, la ms fcil,
es la escalabilidad vertical: mover la aplicacin a equipos ms potentes. La escalabilidad vertical
funciona razonablemente bien para los datos, pero tiene varias limitaciones. La ms obvia es cundo
se supera la capacidad de los equipos ms grandes disponibles. La escalabilidad vertical tambin es
costosa, ya que la adicin de La capacidad transaccional por lo general requiere la compra del
siguiente sistema. La escalabilidad vertical a menudo crea bloqueo del proveedor, adems de aadir
costos.
La Escalabilidad horizontal ofrece ms flexibilidad, pero es considerablemente ms compleja. El
escalado horizontal de los datos se puede realizar a lo largo de dos enfoques. El escalamiento
funcional implica la agrupacin de datos por funcin y la difusin de los grupos funcionales a travs

de bases de datos. La divisin de los datos dentro de las reas funcionales a travs de mltiples
bases de datos, o particiones, aade la segunda dimensin de la escalabilidad horizontal. El
diagrama en la figura 1 ilustra las estrategias de datos la escala horizontal.
Como ilustra la figura 1, ambos enfoques del escalamiento horizontal se pueden aplicar a la
vez. Los usuarios, los productos y las transacciones pueden estar en bases de datos separadas.
Adems, cada rea funcional se puede dividir en varias bases de datos para la capacidad
transaccional. Como se muestra en el diagrama, las reas funcionales se pueden escalar
independientemente uno de otro.
PARTICIN FUNCIONAL
La particin funcional es importante para lograr altos grados de escalabilidad. Cualquier buena
arquitectura de base de datos descompondr el esquema en tablas agrupadas por funcionalidad. Los
usuarios, productos, transacciones, y la comunicacin son ejemplos de reas funcionales. El
Aprovechamiento de conceptos de bases de datos como claves externas, es un enfoque comn para
el mantenimiento de la coherencia entre estas reas funcionales.
Basndose en las limitaciones de la base de datos para garantizar la consistencia entre los
distintos grupos funcionales crea un acoplamiento del esquema de una estrategia implementacin de
la base de datos, lo que impide la escalabilidad horizontal a medida que aumentan las tasas de
transaccin. En muchos casos, la oportunidad ms fcil escalabilidad horizontal se mueve de los
grupos funcionales de los datos a los servidores de bases de datos discretos.

Los esquemas que pueden escalarse a muy altos volmenes de transacciones colocarn
datos funcionalmente distintos en diferentes servidores de bases de datos. Esto requiere quitar las
limitaciones de la base de datos y colocarlas en en la aplicacin. Esto tambin presenta varios
desafos que se tratan ms adelante en este artculo.
TEOREMA CAP
Eric Brewer, profesor en la Universidad de California y Berkeley, cofundador y director cientfico
de Inktomi, hizo la conjetura de que los servicios web no pueden asegurar las tres siguientes
propiedades a la vez (representado por el acrnimo CAP):
Consistencia. El cliente percibe que se ha producido un conjunto de operaciones a la vez.

Disponibilidad. Cada operacin debe terminar en una respuesta prevista.

Tolerancia de particin. Las operaciones se completan, incluso si los componentes individuales no
estn disponibles.
En concreto, una aplicacin web puede admitir, como mximo, slo dos de estas
propiedades con cualquier diseo de base de datos. Obviamente, cualquier estrategia de
escalamiento horizontal se basa en la particin de datos; Por lo tanto, los diseadores se ven
obligados a decidir entre la coherencia y la disponibilidad.
SOLUCIONES ACID
Las Transacciones de bases de datos ACID simplifican en gran medida el trabajo de los
desarrolladores de aplicaciones. El significado de la sigla ACID, est conformado por las siguientes
garantas:
Atomicidad. Todas las operaciones en la transaccin se completaran, o ninguna lo har.

Consistencia. La base de datos estar en un estado consistente cuando la transaccin inicie y

termine.
Aislamiento. La transaccin se comportar como si fuera la nica operacin en ejecucin en la base
de datos.
Durabilidad. Tras la finalizacin de la transaccin, la operacin no se invertir.
Los vendedores de bases de datos hace mucho tiempo reconocieron la necesidad de
particionar bases de datos e introdujeron una tcnica conocida como 2PC (commit en dos fases)
para proporcionar garantas ACID a travs de varias instancias de base de datos. El protocolo se
divide en dos fases:
En primer lugar, el coordinador de transacciones pide a cada base de datos involucrados a realizar
un pre-commit de la operacin e indicar si es posible hacer un commit. Si todas las bases de datos
estn de aceptan el commit puede proceder, y a continuacin, se inicia la fase 2.
El coordinador de transacciones pide a cada base de datos hacer un commit.
Si cualquier base de datos veta el commit, se les pide a todas las bases de datos que hagan
retroceder sus partes de la transaccin.

Cul es el inconveniente? Estamos obteniendo consistencia entre las particiones. Si Brewer tiene
razn, entonces debemos estar afectando la disponibilidad, pero cmo?
La disponibilidad de cualquier sistema es producto de la disponibilidad de los componentes
necesarios para la operacin. La ltima parte de esa declaracin es la ms importante. Los
componentes que pueden ser utilizados por el sistema pero no se requieren, no reducen la
disponibilidad del sistema. Una transaccin que involucra dos bases de datos en un 2PC commit
tendr la disponibilidad del producto de la disponibilidad de cada base de datos. Por ejemplo, si
suponemos que cada base de datos tiene 99,9 por ciento de disponibilidad, entonces, la
disponibilidad de la transaccin seria del 99,8 por ciento, o un tiempo de inactividad adicional de 43
minutos por mes.
UNA ALTERNATIVA A ACID.
Si ACID proporciona la opcin de consistencia para bases de datos particionadas,
entonces, cmo lograr la disponibilidad en su lugar? Una respuesta es BASE
(bsicamente disponibles, estado blando, eventualmente consistente).

BASE es diametralmente opuesta a ACID. Donde ACID es pesimista y fuerza la

consistencia
al final de cada operacin, BASE es optimista y acepta que la
la consistencia de la base de datos estar en un estado de flujo. Aunque esto suena
imposible hacer, en realidad es muy manejable y conduce a niveles de escalabilidad que
no se pueden obtener con ACID.
La disponibilidad en BASE se logra mediante el apoyo a los fracasos parciales sin
fallo total del sistema. Aqu est un ejemplo sencillo: si los usuarios se dividen en cinco
servidores de bases de datos, el diseo de BASE alienta la elaboracin operaciones de tal
manera que los impactos de fracaso en una base de datos de usuario sean solo slo del
20 por ciento de los usuarios de ese host en particular. No hay magia involucrada, pero
esto conduce a una mayor disponibilidad percibida del sistema.
As que, ahora que han descompuesto sus datos en grupos funcionales y se
reparti los grupos ms activos a travs de mltiples bases de datos, cmo incorporar en
BASE en su aplicacin? Base requiere un anlisis ms a fondo de las operaciones dentro
de una transaccin lgica del que normalmente se aplica en ACID. Qu debe usted
buscar? Las siguientes secciones proporcionan cierta direccin.
PATRONES DE CONSISTENCIA.
A raz de la conjetura de Brewer, si BASE permite la disponibilidad de una base de datos
particionada, entonces las oportunidades para relajar la consistencia deben ser
identificadas. Esto es a menudo difcil debido a la tendencia que tienen los interesados y
los desarrolladores de afirmar que la consistencia es de suma importancia para el xito de
la aplicacin. La Inconsistencia temporal no se puede ocultar al usuario final, por lo tanto a
los ingenieros y los propietarios del producto deben participar en la seleccin de las
oportunidades para relajar la consistencia.
La figura 2 es un esquema sencillo que ilustra las consideraciones de consistencia
para BASE. La tabla User contiene la informacin de los usuario, incluyendo el total de
compras y ventas. La tabla de transaction contiene cada transaccin, relaciona al vendedor, al
comprador y el total de la transaccin. Esta es una simplificacin exagerada del mundo real, pero
contienen los elementos necesarios para ilustrar varios aspectos de la consistencia.

En general, la consistencia entre los grupos funcionales es ms fcil de relajar que dentro
de ellos. El esquema del ejemplo tiene dos grupos funcionales: usuarios y transacciones.
Cada vez que se vende un artculo, se agrega una fila a la tabla de transacciones y los
contadores para el comprador y el vendedor se actualizan. Si se utilizara una transaccin
de tipo CID, el SQL sera como se muestra en la figura 3.