Trabajo_Final_de_Grado_GATTO_

1
BASES DE DATOS Y TRANSACCIONES DE
COMERCIO ELECTRÓNICO
Sebastián Leandro Gatto Pereyra - Pablo Genoud
Profesora: Ana Darcacha

Abstract--Basic guidelines for the preparation of a technical
work for the IEEE
I. INTRODUCCION
El presente trabajo analizará los principios básicos del
comercio electrónico, así como la realización de una
comparación entre los diferentes modelos de transacciones,
tratando de evaluar sus pros y sus contras.
II. OBJETIVOS
E
l trabajo se encargará de demostrar que las transacciones
que cumplen con las propiedades ACID (Atomicidad,
Consistencia, Aislamiento y Durabilidad) son las apropiadas
para el correcto manejo del comercio electrónico del tipo B2C
(Business-to-Consumer).
Debido al alto crecimiento de los últimos años del comercio
electrónico es de suma utilidad entender que modelo en
necesario utilizar al gestionar un negocio que sea rentable y
con una buena respuesta al cliente.
III. MARCO TEORICO
El Comercio es el proceso y los mecanismos utilizados,
necesarios para colocar las mercancías, que son elaboradas en
las unidades de producción, en los centros de consumo en
donde se aprovisionan los consumidores, último eslabón de la
cadena de comercialización. Es comunicación y trato.
El comercio electrónico se entiende como cualquier forma
de transacción comercial en la cual las partes involucradas
interactúan de manera electrónica y no de la manera
tradicional por medio de intercambios físicos o trato físico
directo.
Actualmente la manera de comerciar se caracteriza por el
mejoramiento constante en los procesos de abastecimiento, y
como respuesta a ello los negocios a nivel mundial están
cambiando tanto su organización como sus operaciones. El
comercio electrónico es el medio de llevar a cabo dichos
cambios dentro de una escala global, permitiendo a las
compañías ser más eficientes y flexibles en sus operaciones
internas, para así trabajar de una manera más cercana con sus
proveedores y estar más pendiente de las necesidades y
expectativas de sus clientes. Además permiten seleccionar a
los mejores proveedores sin importar su localización
geográfica para que de esa forma se pueda vender a un
mercado global
Jaime Neilson dice que: "El comercio electrónico es
cualquier actividad de intercambio comercial en la que las
órdenes de compra - venta y pagos se realizan a través de un
medio telemático, los cuales incluyen servicios financieros y
bancarios suministrados por Internet. El comercio electrónico
es la venta a distancia aprovechando las grandes ventajas que
proporcionan las nuevas tecnologías de la información, como
la ampliación de la oferta, la interactividad y la inmediatez de
la compra, con la particularidad que se puede comprar y
vender a quién se quiera, y, dónde y cuándo se quiera. Es toda
forma de transacción comercial o intercambio de información,
mediante el uso de Nueva Tecnología de Comunicación entre
empresas, consumidores y administración pública."
¿Qué es una transacción?
Una transacción es una colección de acciones que hacen
transformaciones consistentes de los estados de un sistema
preservando la consistencia del mismo. Una base de datos está
en un estado consistente si obedece todas las restricciones de
integridad definidas sobre ella.
Las transacciones o terminan con éxito y son grabadas en la
base o bien fracasan y debe ser restaurado el estado anterior de
la BD.
Resuelve los problemas de que una operación compleja se
interrumpa en un momento indeterminado y que varios
usuarios concurrentemente traten de hacer operaciones sobre
los mismos datos.
Tipo Transacciones en el Comercio Electrónico
“B2B” (Business to business): las empresas pueden
intervenir como compradoras o vendedoras, o como
proveedoras de herramientas o servicios de soporte para el
comercio electrónico, instituciones financieras, proveedores de
servicios de Internet, etc.
“B2C” (Business to consumers): las empresas venden sus
productos y prestan sus servicios a través de un sitio Web a
clientes que los utilizarán para uso particular.
C2C (Consumers to consumers): es factible que los
consumidores realicen operaciones entre sí, tal es el caso de
2
los remates en línea.
C2A (Consumers to administrations): los ciudadanos
pueden interactuar con las Administraciones Tributarias a
efectos de realizar la presentación de las declaraciones juradas
y/o el pago de los tributos, obtener asistencia informativa y
otros servicios.
B2A (Business to administrations): las administraciones
públicas actúan como agentes reguladores y promotores del
comercio electrónico y como usuarias del mismo.
Propiedades ACID
garantiza que el resto de usuarios no observen los cambios
intermedios.
El gestor de transacciones es la parte del gestor de base de
datos que se asegura de mantener la atomicidad, durabilidad y
aislamiento de las transacciones. Si no hay ningún error, al
acabar la transacción esta se da por definitiva. Si se produce
un error durante la transacción, el sistema debe restaurar la
base de datos al estado en que estaba justo antes de que
empezara la transacción. Este proceso se denomina
recuperación de fallos
Estas cuatro características de los sistemas gestores de bases
de datos se suelen resumir con el acrónimo ACID, que
corresponde con las iniciales en ingles de Atomicidad
(Atomicity),
Consistencia
(Consistency),
Aislamiento
(Isolation) y Durabilidad (Durability)
Teorema CAP:
Tome DOS
Uno de los objetivos de usar una base de datos es el de
garantizar la atomicidad de un conjunto de operaciones (Se
utiliza la palabra atómico haciendo referencia al latín atomus,
y éste del griego άτομος, con el significado de indivisible). La
atomicidad es la garantía que da el sistema de que, ante la
ejecución de una serie de operaciones englobadas en lo que se
denomina una transacción, o bien se ejecutan todas las
operaciones, o bien no se efectúa ninguna.
El conjunto de operaciones se ejecuta en su totalidad o no
se ejecuta en absoluto, no dejando ningún efecto sobre el
sistema. Una vez empezada una transacción, por tanto, esta
puede acabar con una confirmación que la hace definitiva
(Commit) o puede ser cancelada en su totalidad (Rollback)
La atomicidad facilita mantener la consistencia de los datos.
Una base de datos es consistente si se garantiza que siempre se
verifican unas determinadas condiciones. Las condiciones
deben cumplirse obligatoriamente antes y después de la
transacción (pero pueden incumpliese transitoriamente dentro
de la misma).
Otra característica destacable de una transacción es que
debe ser durable. Esta garantiza que, en el instante en el que se
finaliza la transacción, esta perdura. Incluso en el caso de fallo
en el sistema, este deberá ser capaz de recuperarse y controla
todas la transacciones que hayan sido completadas.
Finalmente, un sistema de transacciones debe garantizar el
aislamiento. El aislamiento es la garantía de que los cambios
hechos dentro de cualquier transacción son invisibles al resto
de las transacciones, mientras esta no haya concluido. Así se
Con el teorema CAP se pueden implementar dos de las
siguientes tres propiedades, pero no las tres a la vez:
Consistency o Consistencia fuerte: En el sentido de las
transacciones ACID. Todos los clientes ven la misma versión
de los datos, incluso en presencia de actualizaciones, de forma
consistente.
Availability o Disponibilidad: El sistema está disponible y
responde en un tiempo adecuado a todos los clientes. Este
concepto está muy relacionado con el tiempo de respuesta. Si
el tiempo de respuesta excede un umbral, el sistema se
considera no disponible. Este umbral puede ser el timeout de
un socket, pero también puede ser la paciencia del usuario.
Partition Tolerance o Tolerancia a fallos: Incluso en
presencia de fallos en el servidor, todos los clientes pueden
tener servicio y poder acceder a los datos. Un sistema tolerante
a fallos sigue funcionando aunque uno de sus servidores se
caiga o se corten algunas de las conexiones de red entre
servidores. Un sistema completamente tolerante a fallos sólo
puede dejar de funcionar si caen todos los servidores o se
pierde el contacto con todos ellos.
En los siguientes gráficos se puede observar dos nodos con
3
valores iguales inicializados en cero. Luego uno de los nodos,
el N1 actualiza su valor. Para que luego en el siguiente paso el
valor correspondiente al nodo N1 se traslade al nodo N2. Este
lee el valor. Sin la tolerancia a fallos habría partes de la red
que no se comunicarían y los valores serian diferentes en los
distintos nodos.
4º Paso:
1º Paso:
Falta de tolerancia a fallos:
2º Paso:
3º Paso:
En el teorema CAP
se debe seleccionar bien las
propiedades que se quieran utilizar. Hay que enfatizar que no
tiene que ser una decisión de todo o nada. Se puede sacrificar
algo de consistencia en vez de toda la consistencia. También
se puede sacrificar un poco de disponibilidad, que en la
práctica es permitir que se degrade el tiempo de respuesta e
incluso que algunos clientes pierdan disponibilidad por un
tiempo limitado. O bien se puede decidir perder algo de
tolerancia a fallos, que en la práctica significa tolerar una
cantidad limitada determinada de fallos pero nada por encima
de un límite.
La forma en que podemos conseguir tolerancia a fallos es
tener muchos nodos por si se cae uno, haya otro capaz de
tomar su lugar. Si se quiere un sistema tolerante a fallos y que
además tenga consistencia absoluta, se debe replicar los datos
4
entre los nodos cada vez que hagamos una escritura. Al
escribir, todos los nodos deben replicarse y se debe esperar
hasta que este hecho suceda para poder dar por terminada la
operación. Esto como es normal hace que la operación sea
tanto más lenta cuanto más nodos existan, lo que degrada el
tiempo de respuesta y por lo tanto la disponibilidad. Otro
efecto negativo es que aumenta la probabilidad de que la
operación no se produzca con éxito, ya que debe escribir en
todos los nodos, y alguno puede estar caído, y para que la
operación sea exitosa debe escribir en todos los nodos. La
probabilidad de que al menos un nodo esté caído aumenta con
el número de nodos totales del sistema, con lo que cuanto más
nivel de replicación tenemos, más probabilidad de fallar en la
operación y por lo tanto de falta de disponibilidad. Esto va en
contra de la disponibilidad del sistema. Como contrapartida
sólo se necesita leer de un nodo, con lo que en la lectura tiene
gran rendimiento, disponibilidad y tolerancia a fallos. Las
bases de datos tradicionales suelen usar el enfoque
anteriormente expuesto como mecanismo de tolerancia a
fallos.
Si se quiere aumentar la disponibilidad, la operación debe
terminar antes, lo que implica que no se puede esperar a que se
repliquen todos los nodos, sino sólo uno o quizás unos cuantos
pero no todos. El hecho de que la operación termine antes de
que todos los nodos se repliquen aumenta la disponibilidad
pero a su vez degrada la consistencia al no tener todos los
nodos la misma información. Así si un cliente lee de un nodo
que pudo ser replicado no tendrá problema, pero si lee de un
nodo que aún no ha sido replicado se producirá una lectura
inconsistente con la escritura anterior. Normalmente los
sistemas que permiten sacrificar consistencia por
disponibilidad, tiempo de respuesta y tolerancia a fallos
implementan un modelo de consistencia llamado eventually
consistency (consistencia eventual).
En sistemas con consistencia eventual, si bien al terminar
una operación el sistema puede estar inconsistente, se
garantiza que al cabo de un tiempo el sistema quedará en un
estado consistente, es decir, que eventualmente se conseguirá
un estado consistente. Cuanto más tiempo pase entre la
escritura y la lectura más probabilidad habrá de que el sistema
sea consistente. No se puede especificar un tiempo mínimo
para que se produzca esta consistencia ya que el sistema puede
sufrir algún fallo
El hecho de que pueda existir inconsistencia complica la
lógica de los clientes
La inconsistencia también puede presentarse en la escritura,
en el caso en el que se intentase escribir en varios nodos, cada
uno con una versión diferente. En sistemas con grados de
consistencia no estricto, el cliente tiene la posibilidad de
detectar inconsistencias, pero por contra le queda la papeleta
de resolver el conflicto entre varias versiones.
Esto quiere decir que la resolución de conflictos queda en
mano de reglas de negocio en vez de en algoritmos genéricos.
Otro hecho a considerar sobre este tipo de sistemas es que
se puede especificar un grado de consistencia diferente a las
operaciones de lectura y escritura. Esto permite optimizar el
rendimiento de las escrituras o de las lecturas en función de lo
que nos interese.
También puede tener una vía alternativa: sacrificar la
tolerancia a fallos y tener sólo un nodo. De esta forma sólo se
necesita escribir y leer del único nodo del sistema, con lo que
se consigue consistencia y disponibilidad mientras el nodo no
se caiga. Estos sistemas tienen tolerancia a fallos cero. Este es
el enfoque clásico de una base de datos tradicional sin
tolerancia a fallos.
Este enfoque no está totalmente libre de la degradación del
tiempo de respuesta o de la disponibilidad aunque no se haya
producido ningún fallo.
En el caso de que ocurra que dos clientes quieren ejecutar
dos transacciones concurrentes que afectan al mismo dato, se
produce un conflicto. Si se utiliza ACID estricto, se invoca la
propiedad de aislamiento transaccional y serializan las
transacciones ya que intentan acceder al mismo dato. Para ello
se suele implementar un mecanismo de bloqueo a nivel de fila,
aunque también es típico bloqueo a nivel de tabla. Este
mecanismo se suele llamar concurrencia pesimista, y puede
llevar a la degradación del tiempo de respuesta o incluso a la
indisponibilidad del sistema con alta carga de transacciones
concurrentes. Esto ocurre en un sistema con un único nodo, es
decir con tolerancia a fallos cero.
Los fabricantes de base de datos saben esto y por ello
permiten relajar la consistencia mediante una disminución en
el grado de aislamiento de las transacciones. Si se relaja el
grado de aislamiento, se puede usar concurrencia optimista,
que consiste en no bloquear filas y al escribir comprobar si la
versión que está en la DDBB es la misma que la versión que
leímos al principio de la transacción. En caso de que sea así no
hay conflicto. En caso de que sean distintas versiones se
produce un conflicto y hay que solucionarlo. Los algoritmos
para solucionarlos son: fallar, sobrescribir, fusionar
automáticamente o fusión manual por parte del usuario.
Si se tiene un sistema de persistencia tradicional, no
tolerante a fallos, y se quiere escalar, se tiene que bajar el
aislamiento transaccional y usar concurrencia optimista, lo que
lleva a la necesidad de gestionar conflictos e inconsistencias
en la aplicación.
El objetivo de diseño de un sistema tradicional siempre ha
sido favorecer la consistencia sobre las otras propiedades del
sistema. Esto lleva al dilema de o bien sacrificar la
disponibilidad o la tolerancia a fallos. Es decir, se quiere un
sistema disponible y consistente, que responda a todos los
clientes en un tiempo razonable, no puede ser tolerante a fallos
y por lo tanto no se puede caer ningún servidor o línea de
comunicación. Si se tiene un sistema tolerantes a fallos y
consistente, y se produjera un fallo de red o la caída de una
máquina, el sistema seguiría funcionando, pero o bien el
tiempo de respuesta se degradaría o algunos clientes perderían
el servicio temporalmente.
Estos compromisos entre disponibilidad y tolerancia a
fallos pueden ser aceptables en aquellas aplicaciones donde la
consistencia es crítica, y el coste de un fallo en la consistencia
es mayor que el coste de estar un tiempo sin servicio o que el
5
sistema responda muy lentamente.
Concepto BASE:
software, videojuegos, electrónica, ropa, muebles, comida,
libros, etc.
La misma ha absorbido numerosas empresas, al igual que
Google o Microsoft. Algunas de estas adquisiciones son:
Audible (una empresa de audiolibros), BookSurge (dedicada a
los libros de baja demanda), Mobipocket (la cual crea ebooks
y dispositivos para libros electrónicos) o Fabric.com (una
empresa de costura).
Además, ha lanzado sus propios productos como el
AmazonKindle, lectura de libros electrónicos.
Dynamo es un producto interno de Amazon. Esta orientado
a AP (Availability, Partition Tolerance). Sacrificando la
consistencia. Adopta Eventual Consistency. Muchos servicios
internos de Amazon necesitan acceder por Clave a un Valor.
Los Datos son particionados y replicados
Cientos de Servicios en Amazon
BASE: (Basic Available, Soft state, Eventually consistent)
Es diametralmente opuesto a ACID. ACID es pesimista,
fuerza la consistencia al final de cada operación.
BASE es optimista, acepta que el estado de la base esté en
cambio. Provee disponibilidad soportando fallas parciales,
por ejemplo: Tener la base de usuarios particionada en 5
servidores. Si falla uno, sólo afecta al 20% de los usuarios
CASO PRÁCTICO:
AMAZON:
El caso especifico de Amazon es uno de los pioneros del
área de comercio electrónico B2C últimamente este tipo de
mercado se ha venido consolidando debido a la extrema
competencia que ya existe en el medio, siendo el mismo
comparado con dos áreas que utilizan establecimientos físicos
para el consumidor final.
Fundada como Cadabra.com por Jeff Bezos en 1994 y
lanzada en 1995, comenzó como una librería online. Tenía
más de 200.000 títulos y estos se podían pedir por e-mail.
Tiempo después la bautizó Amazon (río sudamericano) y ya
que en ese momento circulaban listas ordenadas
alfabéticamente, posicionándose en los primeros lugares. El
15 de mayo de 1997 amazon.com salió a la bolsa,
específicamente a la NASDAQ con el símbolo AMZN y a un
precio de 18 dólares la acción.
El primer plan económico era inusual: La compañía no
cambió nada en 4 o 5 años; tiempo después, pensando en
retrospectiva, la estrategia funcionó bien. En 2002 logró un
beneficio de 3900 millones de dólares, 5300 millones en 2003,
6900 millones en 2004, 8500 millones en 2005 y 10700
millones en 2006.
Además, la prestigiosa revista Time Magazine calificó a
Bezos como la persona del año en 1999, por ser dueño de
Amazon, que se había vuelto muy popular.
En la actualidad está totalmente diversificada en diferentes
líneas de productos, ofreciendo DVDs, CDs de música,
Las Operaciones: Cada clave tiene un nodo coordinador
asignado. La clave-valor se replica en otros servidores.
Put(key, value, context): Hay una clave, valor. Siempre
toma el “write”. El contexto tiene información como la
versión. Y puede pedir que se escriba en W nodos
Get(key): Dado la clave, recupera el valor Y el contexto.
Puede dar un valor, o una lista de valores en conflicto. La
aplicación decide qué hacer con los conflictos. Puede pedir
valores de R nodo
Utiliza anillos de nodos. Si alguno de los nodos se cae. pasa
a usar otro para manejar la clave K
6
GOOGLE BIGTABLE
Google creo Bigtable porque los sistemas de bases de datos
tradicionales no le permitían crear sistemas lo suficientemente
grandes.
Las
bases
de
datos
relacionales,
(MySQL,PostgreSQL, Firebird u Oracle) que se diseñaron
pensando que se ejecutarían en una solo servidor con mucha
potencia Nunca imaginaron que podrian distribuirse en miles
de servidores distintos.
El pilar basico de BigTable es que se diseña para almacenar
una gran cantidad de datos , del orden de los PetaBytes. Cada
tabla esta dividida en "Tablets" que tienen como maximo 200
Mb. En el caso de que se supere esa cantidad automaticamente
se divide, comprimen y son enviadas a mas maquinas usando
un sistema de compresion propietario de Google
Bigtable posee algunas particularidades, aunque se parezca
a una base de datos relacional rompe con algunas de sus
premisas. Por ejemplo, las tablas se dividen en conjuntos de
columnas y estos en columnas. Es posible añadir columnas a
una tabla en cualquier momento y no es posible borrar filas,
solo podemos reemplazarlas por unas nuevas que ocultan las
anteriores. Los datos se localizan usando tres llaves, la fila , la
columna y un timestamp (Fecha+Hora) Asi acceder a filas
borradas consiste en hacer referencias a ellas con un timestamp
de la fecha anterior al borrado.
Cada celda almacena una cadena de texto sin tipo, por
consideraciones de rendimiento se suelen almacenar los datos
de forma binaria, es decir, como volcados de la memoria que
los contenían. Como crear columnas es tan sencillo, la
columna en sí es un nuevo almacén.
Bigtable prioriza de CAP, la consistencia y la
disponibilidad. No tiene replicación a nivel de base de datos,
esta misma la hace el Google File System.
Es utilizado en Web indexing, Google Earth, Google
Finance, Google Analytics, etc. Estas aplicaciones manejan
datos desde simples URLs a fotos satelitales, desde batch hasta
datos para usuarios finales en el momento
CASSANDRA
Cassandra es una base de datos de código abierto cuya
principal característica es que fusiona Dynamo, de Amazon
con BigTable, de Google, siendo ambas implementaciones de
código cerrado.
El desarrollo de Cassandra fue iniciado por Facebook, para
intentar solventar la problemática relacionada con el
rendimiento del motor de búsquedas, concretamente con las
relacionadas en la comunicación entre usuarios. Esta
funcionalidad implica un gran volumen de datos a almacenar,
con una perpectiva de crecimiento muy alta (el boom de las
redes sociales se produjo después de la implementación de
Cassandra) y la necesidad de ofrecer un nivel de calidad de
servicio fijado.
Debido a la verticalidad de soluciones de datos relacionales
y a la necesidad de ajustar el coste de la implementación, se
diseñó Cassandra para que las configuraciones de explotación
fuesen altamente escalables, horizontales y relativamente
económicas. Con este objetivo en mente, se amplió el espectro
de funcionalidades de la plataforma Facebook a las que daría
servicio, y no únicamente la “Inbox Search” como se
provisionó en un inicio.
En 2008 Cassandra fue liberada por Facebook, pasando a
ser de código abierto, y actualmente es la gente de Apache
quien la mantiene. Esta característica es la que hace de
Cassandra una base de datos NoSQL realmente interesante, ya
que aparte de combinar lo mejor de Dynamo (consistencia
eventual) con lo mejor de BigTable (familias de columnas) es
gratuita y de libre uso y distribución. Está desarrollada en
Java, un lenguaje de programación Multi-plataforma.
Las características del modelo de datos de Cassandra es el
siguiente:
Una tabla de datos por cada instancia de Cassandra.
Cada familia de columnas puede contener o bien columnas
o bien supercolumnas. Las supercolumnas son columnas son la
agrupación de n-columnas.
Cada columna contiene elementos de la forma “ClaveValor-Tiempo”, donde el valor del campo tiempo es definible
por el usuario.
Cada fila de una tabla puede tomar valores en columnas
distintas de una familia de columnas que otra fila, es decir, si
se dispone de una familia de 5 columnas (A, B, C, D, E), la
fila R1 puede tener valores en A y B mientras que la fila R2
puede tenerlos en A, C, D y E.
Cassandra comparte con Dynamo el mecanismo de
membresía de los nodos, siendo ésta comunicada mediante un
mecanismo de Gossiping, así como la alta disponibilidad
conseguida mediante replicación de nodos, mientras que por
otra parte implementa un mecanismo de estimación/detección
de fallos mediante acumulación.
IV. DESARROLLO
La principal causa del abandono de las empresas a las bases
de datos que cumplen con las propiedades ACID es la falta de
tolerancia a fallos. Además de esta propiedad la otra utilizada
es la disponibilidad por lo que los websites más importantes
del planeta avalan y ponen en evidencia la utilización del
Teorema de Bower. Si funciona para ellos no hay razón para
que no sea considerada para el comercio electrónico B2C.
La implementación de las características ACID se torna
bastante dificultoso ya que para el proceso de una transacción
solicita una gran cantidad de reducidos cambios.
También se debe mantener al día los índices que el motor
utilizar para poder realizar búsquedas dentro de tiempos
aceptables por los usuarios que utilizan la herramienta
Por otro lado estas cantidades de operaciones que se
utilizan dentro de una transacción con propiedades ACID
pueden fallar por diferentes razones. Un caso típico es la
7
sobrecarga del CPU asignado al motor.
Es difícil poder garantizar las características que componen
ACID en un ambiente de red. Las conexiones de red pueden
fallar. Teniendo en cuenta que la mayoría de las base de datos
se utilizan en entornos multi-usuario, en los que muchos
clientes utilizando la misma aplicación muchos clientes
acceden a la misma base de datos y dos usuarios al mismo
tiempo.
Existen varias técnicas en ACID para controlar la concurrencia
simultanea a los datos. Los bloqueos es una de ellas utilizada
en la mayoría de las base de datos relacionales. Pero también
existe otras como el control Muli-Version o las marcas
Timestamp.
Para poder tener un proyecto web con tolerancia a fallos y
disponibilidad se necesita incorporar a la arquitectura un
determinado numero de nodos o servidores de forma que si
uno de ellos cae haya otro capaz de tomar el control del nodo
caído. Hay dos tipos de escalabilidad, la vertical y la
horizontal. La escalabilidad vertical, es utilizar CPUs,
memoria RAM y discos, aunque esto implica un aumento
elevado de presupuesto. En cambio la escalabilidad horizontal,
se utilizan más servidores en forma paralela, teniendo la
información en forma distribuida.
Utilizar solamente tanto la disponibilidad como la
consistencia, dejando de lado la tolerancia a fallos seria un
desaprovechamiento de las propiedades CAP. El tomar esta
decisión implica que únicamente se necesita escribir y leer del
único nodo del sistema consiguiendo por un lado consistencia
y disponibilidad, pero por otro lado hay un alto riesgo
presente.
Para poder evitar la tolerancia a fallos es necesario poner
todo lo relacionado con la operación en una maquina o en una
unidad como por ejemplo un rack. No esta garantizado en un
100 % porque se puede tener fallas parciales, pero reduce que
se obtengan efectos secundarios. Aunque hay limites de
escalamiento por lo que la tolerancia a fallos es muy
importante.
Tener un sistema no disponible implica la imposibilidad de
realizarse muchas transacciones. El volumen de negocio
generado por el comercio electrónico B2C en 2009 se sitúa en
un incremento del 15,9% respecto a 2008.
En los últimos años hay un crecimiento en los pagos
mediante tarjeta de crédito, aunque el pago en efectivo sigue
siendo el más utilizado por los usuarios de comercio
electrónico de Argentina.
Uno de cada cuatro usuarios compra mediante alguna
modalidad online, lo que representa unos 5,4 millones de
personas. El mayor uso de estos medios de pago es en el
interior del país. Tanto el mayor uso de las tarjetas de crédito,
como el factor confianza y que haya más gente bancarizada
influye mucho en este tipo de comercio.
Los usuarios que deben realizar pagos de elevados montos,
los realizan mas con tarjeta de crédito y hacen un uso más
sofisticado de las opciones de la banca online
El monto anual de compras electrónicas B2C ascendería
alrededor de $ 11000 millones. Durante 2010 las ventas online
crecieron un 48% en el país, lo que se tradujo en movimientos
por $ 7.755 millones, según datos de la Cámara Argentina de
Comercio Electrónico. Del total de 26,5 millones de usuarios
de Internet, el 49,3% consulta la Web para la toma de
decisiones sobre la compra de un producto o servicio. Para
2011, se espera que el negocio crezca a 11000 millones.
Este incremento en el volumen de negocio está relacionado
principalmente con sistemas disponibles, además de con el
aumento del porcentaje de internautas y del porcentaje de
aquellos
internautas
que
realizan
comercio
electrónico/compras. Todo ello, unido a un gasto medio por
comprador explica el volumen de negocio resultante en 2009 y
su crecimiento en relación al año anterior.
Con respecto a la disponibilidad se debe garantizar que el
cliente tenga una respuesta aceptable del sistema cuando esté
realizando operaciones tanto sea de compra y/o de venta. De
otra manera el sistema seria demasiado lento y el mismo
abandonaría la transacción. Un dato que se puede mencionar
para sustentar la necesidad de esta característica es la edad de
los compradores. La misma va de una franja de 25 a 49 años,
especialmente en la franja de 35 a 49 años. Son residentes en
hábitats urbanos; con estudios universitarios; de un nivel
socioeconómico alto y medio alto y trabajadores activos de
tiempo completo. Se vive en una época en donde hay muchas
ofertas de un mismo producto entonces si una pagina no tiene
un tiempo de respuesta rápido el usuario sin dudarlo cambiara
de lugar en donde realizar la operación, ya sea buscar el
mismo en otro portal, mediante un producto sustituto o ir
directamente al local en donde se encuentra físicamente.
V.
CONCLUSION
Para el correcto manejo de comercio electrónico del tipo
B2C no es recomendable la utilización de las propiedades
ACID debido a que se utiliza grandes aplicaciones de escritura
escalables, por lo que las bases relacionales no es la mejor
opción. La normalización de datos, los joins, y las
transacciones ACID son anti-patrones para la escritura
escalable. La opción más apropiada es la utilización del
Teorema CAP, que permite usar dos de las tres opciones según
la necesidad. En el comercio electrónico B2C se deberá dar
prioridad a la disponibilidad, bajo tiempo de respuesta y
tolerancia a fallos.
Muchas de las compañías mundialmente conocidas utilizan
este teorema como por ejemplo Amazon, Google, Yahoo,
eBay, Mercado Libre dado que no pueden permanecer sin
servicio por mucho tiempo. Tanto Amazon como eBay no
tienen problemas de escalabilidad. Los han tenido pero ahora
tienen las herramientas para solucionarlo. Una décima de
segundo más, cuesta 1% de las ventas. En Google medio
segundo de latencia, baja el tráfico en un quinto.
Otros gigantes como Linkedin, Facebook o Twitter pueden
soportar grados de inconsistencia en los datos que muestra
pero no admite una caída o degeneración del rendimiento. Es
por esto las empresas citadas anteriormente dejaron de lado las
8
transacciones que cumple con las propiedades ACID.
El teorema de CAP se utiliza en diversas bases de datos
Cassandra, MongoDb, CouchDB y Riak entre otras. Estas
mismas también son las más indicadas para la utilización en
software como servicio, cloud computing con millones de
usuarios. Todo esto trae aparejado problemas de alta
escalabilidad que las bases de datos tradicionales pueden
adaptarse para hacerlos escalar en los escenarios mas
complejos pero a veces se empiezan a utilizar triples y
cuádruples joins en las consultas que no necesariamente son
altamente performantes. También se trata de utilizar
almacenamiento en cache para la aceleración de estas
consultas complejas y asi poder evitar la ejecución de todas las
pesadas operaciones que resulta una carga excesiva para el
CPU.
Los sistemas NoSQL tratan de atacar estos problemas que
surgen a medida que nuevos paradigmas van apareciendo
mediante una estructura interna más versátil pero distinta al
almacenamiento de las base de datos relacionales. Puede
llegarse a perder funcionalidades como las transacciones que
engloban operaciones en más de una colección de datos, o
tener la incapacidad de ejecutar el producto cartesiano de dos
tablas teniendo que recurrir a la desnormalización de datos.
En ambientes en donde el escalamiento se da de forma
repentina, el teorema de cap da una solución robusta, sobre
todo por el altísimo rendimiento que propone.
Actualmente además de utilizarse como almacenamiento
primario, se implementan en entornos de persistencia para
guardar caches y otros datos los cuales la velocidad juega un
papel principal.
Se darán ejemplos de grandes empresas tales como
Amazon, Google y Cassandra.
Se indicara el porque del uso del Teorema de Brewer de las
principales empresas en vez de las propiedades ACID. Siendo
la falta de tolerancia a fallos la principal causa del abandono.
Technical Reports
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
ABSTRACT
[12]
El comercio electrónico va teniendo un crecimiento
exponencial a medida que pasa los años. El monto anual de
compras electrónicas B2C ascendería alrededor de $ 11000
millones. Durante 2010 las ventas online crecieron un 48% en
el país, lo que se tradujo en movimientos por $ 7.755 millones.
Para 2011, se espera que el negocio crezca a 11000 millones.
Por lo que en este documento se describirá tanto las
propiedades ACID, el teorema CAP, el concepto BASE.
Se denomina ACID a un conjunto de características
necesarias para que una serie de instrucciones puedan ser
consideradas como una transacción. En concreto ACID es un
acrónimo de: Atomicidad, Consistencia, Aislamiento y
Durabilidad.
El Teorema CAP, también llamado Teorema de Brewer,
establece que solo se pueden satisfacer hasta dos de las tres
características al mismo tiempo, pero nunca las tres:
Consistencia, Disponibilidad, Tolerancia a Fallos. El sistema
sigue funcionando a pesar de algunas pérdidas arbitrarias de
información o fallas parciales del sistema.
El concepto BASE es diametralmente opuesto a ACID, es
optimista, acepta que el estado de la base esté en cambio.
Provee disponibilidad soportando fallas parciales.
[13]
[14]
[15]
Euribates “Base de datos – Gestion de transacciones ACID” Marzo
2008
Available: http://databas.blogspot.com/2008/03/16-gestin-detransacciones-acid.html
Enrique Amodeo “noSQL (2): No necesitas ACID” May 2010
Available: http://eamodeorubio.wordpress.com/2010/05/17/nosql-2-nonecesitas-acid/
Leonardo De Seta “NoSQL y varias alternativas a las bases de datos”
March 2010
Available: http://www.dosideas.com/noticias/base-de-datos/864-nosqluna-alternativa-a-las-bases-de-datos.html
Beatriz Carreño, “Comercio Electrónico” July 2009 Available:
http://www.monografias.com/trabajos15/comercioelectronico/comercio-electronico.shtml#TIPOS
Angel Java Lopez, “Introduccion a NoSQL” Marzo2009 Available:
http://altnet-hispano.pbworks.com/f/NoSqlVan2010.pptx
G.Bracho ,M.Bracho, E.Cotte ,C.Haydon, M.Molina, “Modelos de
Negocios B2C” Available:
http://www.slideshare.net/guest94631/modelo-de-negocio-b2cpresentation
Cristian
Requena,
“Cassandra”
April
2010.
Available:
http://www.nosql.es/blog/nosql/cassandra.html
Wikipedia “ACID” Available: http://es.wikipedia.org/wiki/ACID
Wikipedia
“Teorema
CAP”
Available:
http://es.wikipedia.org/wiki/Teorema_CAP
GNOSS “Teorema de Brewer o CAP” March 2010 Available:
http://www.gnoss.com/comunidad/nextweb/recurso/Basicos-deInternet-Teorema-de-Brewer-o-CAP/0ae5ad19-8f63-422d-98d634bec3eba38a
Víctor S. Manzhirova , “Comercio electrónico, las transacciones a
través de Internet baten récords de facturación” March 2010
Available:
http://www.tuexpertoit.com/2011/03/18/comercioelectronico-las-transacciones-a-traves-de-internet-baten-records-defacturacion/
Estergio Artigas , “Las Alternativas NoSQL” , July 2010 Available:
http://sartigas.blogspot.com/2010/07/la-alternativa-nosql.html
Carlos Sanchez , “Base de Datos RDBMS vs NoSQL” February 2011
Available: http://carlosanchezperez.wordpress.com/2011/02/14/basesde-datos-rdbms-vs-no-sql-una-r-evolucion/
Moises Vazquez, “Big Table & GFS”October 2010 Available:
http://docencia.etsit.urjc.es/moodle/mod/forum/discuss.php?d=11268
ONTSI “Estudio B2C 2010”Octubre 2010 Available:
http://www.ontsi.red.es/articles/detail.action?id=4877&request_locale=e
s
Papers Presented at Conferences (Unpublished):
[16] Julian Browne, “Brewer's CAP Theorem - The kool aid Amazon and
Ebay have been drinking” Jan 2009 Available:
http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
[17] J.Arias, G. Brey, G. Coco, Nicolas Passerini, “Arquitectura de
Persistencia” January 2005 Available: http://apit.wdfiles.com/local-files/start/03_apit_persistencia.pdf
VI.
GLOSARIO
ACID: En bases de datos se denomina ACID a un conjunto de
características necesarias para que una serie de instrucciones
puedan ser consideradas como una transacción. Así pues, si un
sistema de gestión de bases de datos es ACID compliant quiere
9
decir que el mismo cuenta con las funcionalidades necesarias
para que sus transacciones tengan las características ACID.
Amazon: Es una compañía estadounidense de comercio
electrónico con sede en Seattle, Estado de Washington. Su
lema es and you're done (Traducido al español: «y listo»). Fue
una de las primeras grandes compañías en vender bienes a
través de Internet. Amazon también posee Alexa Internet,
a9.com, Shopbop, Kongregate, Internet Movie Database
(IMDb), Zappos.com y DPreview.com.
BigTable: Es un motor de bases de datos creado por Google
con las características de ser: distribuido, de alta eficiencia y
propietario construído sobre GFS (Google File System),
Chubby Lock Service, y algunos otros servicios y programas
de Google.
CAP: El Teorema CAP, también llamado Teorema de Brewer,
establece que es imposible para un sistema de computo
distribuido dar simultaneamente las siguientes tres garantías:
Consistencia, Disponibilidad y Tolerancia a fallos.
Cassandra: Apache Cassandra es una Base de Datos no
relacional (NO SQL), distribuida y basada en un modelo de
almacenamiento de Clave-Valor, escrita en Java
Cloud Computing: Modelo de prestación de servicios de
negocio y tecnología, que permite al usuario acceder a un
catálogo de servicios estandarizados y responder a las
necesidades de su negocio, de forma flexible y adaptativa, en
caso de demandas no previsibles o de picos de trabajo,
pagando únicamente por el consumo efectuado
Commit: En el contexto de la Ciencia de la computación y la
gestión de datos, commit (acción de cometer) se refiere a la
idea de consignar un conjunto de cambios "tentativos, o no
permanentes". Un uso popular es al final de una transacción de
base de datos.
CouchDB: Base de datos documental sin schema, consultable
al estilo MapReduce, accesible por REST y con una
funcionalidad de replicación integrada.
Dynamo: Es una base de datos NoSQL propietaria y de
código cerrado, por lo que su uso es exclusivo de la empresa
que la implementó: Amazon.
Facebook: Facebook es un sitio web de redes sociales creado
por Mark Zuckerberg y fundado por Eduardo Saverin, Chris
Hughes, Dustin Moskovitz y Mark Zuckerberg. Originalmente
era un sitio para estudiantes de la Universidad Harvard, pero
actualmente está abierto a cualquier persona que tenga una
cuenta de correo electrónico. Los usuarios pueden participar
en una o más redes sociales, en relación con su situación
académica, su lugar de trabajo o región geográfica.
Google: Google Inc. es la empresa propietaria de la marca
Google, cuyo principal producto es el motor de búsqueda del
mismo nombre. Dicho motor es resultado de la tesis doctoral
de Larry Page y Sergey Brin (dos estudiantes de doctorado en
Ciencias de la Computación de la Universidad de Stanford)
para mejorar las búsquedas en Internet
Linkedin: Es un sitio web orientado a negocios, fue fundado
en diciembre de 2002 y lanzado en mayo de 2003[1]
(comparable a un servicio de red social), principalmente para
red profesional.
Mercado Libre: Es la tienda on line más grande de
Latinoamérica donde millones de personas se encuentran para
comprar y vender sus artículos cada día.
MongoDB: Es una base de datos NoSQL. Abandona el
enfoque relacional por bases de datos mas orientadas a objetos
y de esta manera es como se procesa la información.
Rollback: En tecnologías de base de datos, un rollback es una
operación que devuelve a la base de datos a algún estado
previo. Los Rollbacks son importantes para la integridad de la
base de datos, a causa de que significan que la base de datos
puede ser restaurada a una copia limpia incluso después de que
se han realizado operaciones erróneas. Son cruciales para la
recuperación de crashes de un servidor de base de datos;
realizando rollback(devuelto) cualquier transacción que
estuviera activa en el tiempo del crash, la base de datos es
restaurada a un estado consistente.
Tiempo de Respuesta: El tiempo de respuesta se define como
el tiempo que pasa desde que se envía una comunicación y se
recibe la respuesta.
Transaccion: Una transacción es una interacción con una
estructura de datos compleja, compuesta por varios procesos
que se han de aplicar uno después del otro. La transacción
debe ser equivalente a una interacción atómica. Es decir, que
se realice de una sola vez y que la estructura a medio
manipular no sea jamás alcanzable por el resto del sistema
hasta que haya finalizado todos sus procesos.
Twitter: Es una red social basada en el microblogging. La red
permite mandar mensajes de texto plano de bajo tamaño con
un máximo de 140 caracteres, llamados tweets, que se
muestran en la página principal del usuario. Los usuarios
pueden suscribirse a los tweets de otros usuarios – a esto se le
llama "seguir" y a los suscriptores se les llaman
"seguidores"[11] o tweeps.
Yahoo: Yahoo! Inc. es una empresa global de medios con
sede en Estados Unidos, cuya misión es "ser el servicio global
de Internet más esencial para consumidores y negocios". Posee
un portal de Internet, un directorio web y una serie de
servicios, incluido el popular correo electrónico Yahoo!.