¿Qué es un sistema de base de datos distribuidas? ¿Qué es una base de datos distribuida con ejemplos?

Cuando una organización posee sucursales distribuidas en lugares alejados geográficamente puede adoptar varios esquemas:

• Independiente:

sin conexión entre los SGBD de las distintas sucursales.

hay una sola base de datos en la casa matriz de la organización y las distintas sucursales se comunican de alguna forma con ella para acceder a los datos (ya que no tienen SGBD).

los diferentes SGBD de las sucursales pueden acceder a los datos de otra a través de un link que los dirige a la misma (autenticación mediante). Los datos a los que puede acceder y las acciones que se pueden realizar dependen de los permisos que posea el SGBD solicitante.

al esquema anterior se le añade una aplicación (web service) que recibe peticiones y envía respuestas a los SGBD de las distintas sucursales. Envía y recibe los datos que mandan los SGBD en respuesta a las solicitudes de los otros SGBD. El formato o estándar utilizado es el XML.

bases de datos en distintos lugares físicos (denominados nodos) que funcionan de forma paralela y que lógicamente se comportan como una sola base de datos. Tener varios nodos permite alta disponibilidad de los datos al dar mayor respuesta en caso de que se caiga uno de los nodos.

Los sistemas de bases de datos distribuidos están formados por sitios débilmente acoplados que no comparten ningún componente físico. Además, puede que los sistemas de bases de datos que se ejecutan en cada sitio sean sustancialmente independientes entre sí, ya que se clasifican en:

• Réplica: cada modificación en una de las bases (nodos) se copia y se graba en los restantes nodos.

Ventajas

Desventajas

• Disponibilidad: Si alguno de los sitios que contiene una relación falla, la misma puede hallarse en otro sitio distinto (los otros nodos cubren al nodo que se cayó). Por tanto, el sistema puede seguir procesando las consultas que impliquen esa relación, pese al fallo del sitio (posee mayor tolerancia a fallos).
• Paralelismo incrementado: En el caso en el que la mayoría de los accesos a una relación sólo resultaren en lecturas, diferentes sitios podrían procesar en paralelo las lecturas que impliquen a esa relación. Cuantas más réplicas de la misma existan, mayor será la posibilidad de que los datos necesarios se encuentren en el sitio en que se ejecuta la transacción. Por tanto, la réplica de los datos minimiza su transmisión entre los diferentes sitios.
• Sobrecarga incrementada en la actualización: El sistema debe asegurar que todas las réplicas de una relación sean consistentes; en caso contrario pueden producirse cálculos erróneos. Por tanto, siempre que se actualiza esa relación, hay que propagar la actualización a todos los sitios que contienen réplicas. El resultado es una sobrecarga incrementada.
• Fragmentación horizontal: en cada nodo se guardan rangos de registros de todas las tablas. En algunas situaciones esto reduce el tráfico de red en las inserciones, modificaciones o eliminaciones, pero las consultas pueden demorar bastante.
• Fragmentación vertical: en cada nodo se guardan atributos de las distintas tablas, identificados en todos los casos por la PK. Para eso es necesario un criterio de fragmentación. Es ventajoso cuando hay datos más consultados o propios de una región que de otra.

No se debe exigir a los usuarios de los sistemas distribuidos de bases de datos que conozcan la ubicación física de los datos ni el modo en que se puede acceder a ellos en cada sitio local concreto. Esta característica, denominada transparencia de los datos puede implicar que no conozcan el modo en que se fragmentaron las tablas ni que conozcan la ubicación física de los datos. Los usuarios ven cada objeto de datos como lógicamente único.

El acceso a los diferentes elementos de datos en los sistemas distribuidos se realiza mediante transacciones, que preservan las propiedades ACID. Las transacciones locales son las que acceden a los datos y los actualizan en una única base de datos local; las transacciones globales son las que acceden a los datos y los actualizan en varias bases de datos locales. En el caso de estas últimas, resulta más difícil garantizar las propiedades ACID dado que puede que participen en la ejecución varios sitios. El fallo de alguno de estos sitios, o el de alguno de los enlaces de comunicaciones que los conectan entre sí, puede dar lugar a cálculos erróneos.

La partición o fragmentación implica tener que buscar una respuesta a la posibilidad de que se caiga o haya problemas de conexión entre los nodos. La respuesta puede tener un impacto tanto en la disponibilidad como en la consistencia del sistema de datos.

Durante una actualización se generan estados inconsistentes que pueden ser incompatibles con lo que esté trabajando otro nodo. Si hay problemas de conexión, y no se puede validar o controlar en línea, se pueden adoptar como cursos de acción:

• Reducir las operaciones disponibles (no permitir la lectura y escritura de datos relacionados) y reducir la disponibilidad del sistema de datos.
• Permitir las operaciones, pero hay que tener recaudos adicionales respecto a cómo se resuelven problemas de inconsistencia que puedan surgir.

Los SGBD relacionales buscan asegurar más la consistencia. Cada nodo posee su gestor de transacciones, pero, además, al esquema se agrega un coordinador de transacciones:

Gestor de transacciones

Coordinador de transacciones

Cada sitio tiene su propio gestor local de transacciones, cuya función es garantizar las propiedades ACID de las transacciones que se ejecuten allí. Se encarga de:

• Mantener un registro histórico con fines de recuperación.
• Controlar la concurrencia del sitio.

Coordina la ejecución de las diferentes transacciones (tanto locales como globales) iniciadas en el sitio. Se encarga de:

• Iniciar la ejecución de la transacción.
• Dividir la transacción en las transacciones y distribuirlas a los sitios.
• Coordinar la terminación de la transacción (compromiso o aborto).

El coordinador puede ser un nodo independiente que sólo realice las tareas propias de coordinación o puede ser uno de los nodos de la base de datos distribuida el que asuma ese rol (en.: el que la inició).

Para asegurar la atomicidad y consistencia de todas las transacciones existen protocolos de compromiso que garantizan esta propiedad de consistencia, ya que en todos los sitios en los cuales se ejecuta una transacción, la misma se compromete o se abortará. Los protocolos más comunes son:

• Dos fases (C2F): es uno de los más sencillos y más utilizado en bases distribuidas.
• Tres fases (C3F): variante del anterior, evita ciertos inconvenientes de este, pero añade complejidad y sobrecarga.

Protocolo de 2 fases (C2F)

La idea en las bases de datos distribuidas es que aquellas transacciones distribuidas (es decir, que requieren datos de diferentes nodos) se ejecuten como una unidad. El protocolo de compromiso de 2 fases (C2F) divide en dos el proceso de ejecución de una transacción distribuida:

1. Fase 1. Ci añade el registro <preparar T> al registro histórico y obliga a que se guarde en un lugar de almacenamiento estable. Luego envía el mensaje preparar T a todos los sitios en los que se ha ejecutado T. Al recibir este mensaje, el gestor de transacciones de cada sitio determina si desea comprometer su parte de T. Si la respuesta es negativa, añade el registro <no T> al registro histórico y responde enviando a Ci el mensaje abortar T. Si la respuesta es positiva, añade el registro <Y preparada> al registro histórico y hace que se guarde (con todos los registros del registro histórico correspondientes a T) en un almacenamiento estable. El gestor de transacciones contesta entonces a Ci con el mensaje T preparada.
2. Fase 2. Cuando Se recibe de todos los sitios las respuestas al mensaje preparar T, o cuando ha transcurrido un intervalo de tiempo especificado con anterioridad desde que se envió el mensaje preparar T, Ci puede determinar si la transacción T puede comprometerse o abonarse. La transacción T se puede comprometer si Ci ha recibido el mensaje T preparada de todos los sitios participantes. En caso contrario, hay que abortar la transacción T. En función del resultado, se añade el registro <T comprometida> o <T abortada> al registro histórico, que se guarda en un almacenamiento estable. En ese momento, el destino de la transacción ya se ha sellado. A partir de este momento el coordinador envía a todos los sitios participantes el mensaje comprometer T o abortar T. Cuando un sitio recibe ese mensaje, lo guarda en el registro histórico

El gestor de transacciones de cada nodo gestionará las operaciones de la transacción que afecten los datos que se guardan en dicho nodo. Una vez que se llevaron a cabo esas operaciones, ninguno de los gestores involucrados puede comprometer la sub transacción sin antes informar al coordinador de transacciones que las operaciones ya se realizaron. Es ahí cuando el coordinador ordena comprometer las sub transacciones en cada nodo y cada gestor involucrado podrá comprometer las operaciones y la transacción en su totalidad estará comprometida.

Mientras esperan la orden del coordinador para comprometer, cada gestor registra en su registro histórico la línea . Este registro constituye, en realidad, un compromiso del sitio de acatar la orden del coordinador de comprometer o de abortar la transacción. Para establecer ese compromiso, primero hay que guardar en un almacenamiento estable la información necesaria. En caso contrario, si el sitio fallara tras enviar el mensaje , puede que no fuera capaz de cumplir su promesa. Además, los bloqueos adquiridos por la transacción deben mantenerse hasta que ésta se complete. Dicho registro es el paso previo a que el gestor informe al coordinador que está listo para comprometer la subtransmisión. Cuando éste reciba los

Dado que se exige la unanimidad para comprometer cada transacción, el destino de la transacción queda sellado en cuanto un sitio responda que se abortará la misma.

El rol del coordinador de transacciones en todo este proceso es:

1. Mandar datos de la transacción a los gestores.
2. Esperar a todos los .
3. Si todo está correcto, mandar la orden de compromiso.

En caso de producirse un fallo en alguno de los gestores puede ocurrir alguna de estas situaciones:

1. El gestor se cae cuando recibió la orden de comprometer: En este caso se rehace la transacción. Si el gestor que se cayó comprometió las operaciones significa que todos los gestores involucrados llegaron al estado de , lo cual implica que dichos gestores tienen en memoria secundaria los datos necesarios para rehacer la transacción.
2. El gestor se cae después de registrar <Tx preparada>: En este caso el gestor pregunta al coordinador de transacciones qué hacer luego de recuperarse. Esto es porque el gestor no sabe qué pasó con el resto de los gestores involucrados, ya que no recibió ninguna orden del coordinador cuando se cayó.
• Puede haber ocurrido que el coordinador no haya recibido el del gestor que se caypi y haya ordenado a todos los gestores hacer ROLLBACK. Cuando aquél se recupera, pregunta y el coordinador le ordena que haga ROLLBACK también, para lo cual el gestor tiene todos los datos.
• Puede haber ocurrido que el coordinador sí haya recibido el del gestor que se cayó. En ese caso, al recuperarse, pregunta y el coordinador le informará que debe rehacer todas las operaciones, para lo cual el gestor (como en el caso anterior) tiene todos los datos.
• El gestor se cae mientras realiza las operaciones: En este caso debe deshacerlas (ROLLBACK). El coordinador de transacciones supone que el gestor respondió que abortó la transacción.
• El gestor encuentra, al recuperarse, que había deshecho la sub transacción luego de informar que estaba preparada: En este caso se deshace la transacción (ROLLBACK) porque esto implica que el coordinador había informado que se deshiciera.
• El gestor encuentra un problema en una de las operaciones y realiza ROLLBACK: En este caso se deshace la transacción (ROLLBACK) ya que se trató de un problema local. Esto el gestor lo informa al coordinador de transacciones.

Si el que falla, en cambio, es el coordinador son los sitios participantes los que decidirán el destino de la transacción:

1. Si algún sitio activo contiene el registro <Tx preparada en su registro histórico: debe comprometer la transacción.
2. Si algún sitio activo contiene el registro <Tx abortada> en su registro histórico: se debe abortar la transacción.
3. Si algún sitio activo no contiene el registro <Tx preparada> en su registro histórico: el coordinador que ha fallado no puede haber decidido comprometer la transacción, ya que los sitios que no contienen el registro en su registro histórico no pueden haber enviado ese mensaje al coordinador. No obstante, puede que el coordinador haya decidido abortar la transacción, pero no comprometerla. En vez de esperar a que se recupere el coordinador, resulta preferible abortar la transacción.
4. Si no se da alguno de los casos anteriores: todos los sitios activos deben tener el registro problema del bloqueo, situación no deseable, ya que, en función del tiempo que dure la caída del coordinador, la transacción en ejecución mantiene sus bloqueos sobre los datos en diferentes sitios (inclusive en el del coordinador) y es posible que otras transacciones se vean obligadas a esperarla, además de que se siguen consumiendo recursos del sistema.

Consistencia eventual

La consistencia eventual tiene que ver con dividir el proceso de procesamiento de transacciones en diferentes fases con la certeza de que, en determinado momento, el resultado obtenido es consistente. Mientras el proceso está dividido, no hay consistencia, ya que cada fase opera de forma independiente. Es decir, en el lapso que dura el proceso, no se está en estado consistente todo ese tiempo, pero, eventualmente, se llega a la consistencia.

Este esquema busca asegurar la disponibilidad ante los problemas de conexión. Cuando se detecta un problema que hace que los nodos no estén conectados, se presume que cada uno de ellos está trabajando por su lado, es decir, particionado. Este estado dura mientras persista la desconexión entre los nodos. En este esquema trabaja Cassandra.

En algún momento el problema se resuelve y los nodos vuelven a estar conectados. Cuando esto ocurra, el sistema debe recuperarse, trabajando con los nodos en cuestión, buscando una nueva consistencia eventual. Para ello se trabaja con datos adicionales que se guardaron mientras duró la partición y con protocolos específicos.

La consistencia eventual:

• Permite aumentar la operatividad durante las particiones de datos.
• Requiere de protocolos particulares para detectar particiones y resolver potenciales inconsistencias.
• Debe almacenar y gestionar datos adicionales sobre las particiones.
• Resuelve los conflictos y vuelve a un estado consistente, una vez terminada la partición (la cual puede durar horas o milisegundos).

Bases de datos semiestructuradas distribuidas. MongoDB

El enfoque principal de las bases “nosql” está puesto en particionar los datos en múltiples nodos de almacenamiento, posibilitando distribuir y paralelizar los tiempos de escritura, lectura y procesamiento de los datos, así como asegurar mayor disponibilidad en base a la redundancia de los datos. Estos esquemas permiten escalar horizontalmente y lograr la disponibilidad deseada, agregando incrementalmente los nodos que se vayan necesitando. MongoDB tiene una estructura documental y distribuida.

MongoDB es una base de datos orientada a documentos. En vez de almacenar los datos en tablas y filas como en una base de datos relacional, los almacena en colecciones compuestas por documentos. Estos documentos son similares a objetos JSON, y los valores de los campos pueden ser simples combinaciones clave-valor o contener otros documentos, arrays o arrays de documentos. Específicamente almacena los registros de datos como documentos BSON. BSON es una representación binaria de documentos JSON. Además, BSON contiene extensiones que permiten la representación de tipos de datos que no son parte de la especificación de JSON. Los documentos se almacenan en colecciones.

Los índices tienen una estructura de Árbol B y pueden generarse de los siguientes tipos: Simples o Compuestos, Multi-clave (para el indexado del contenido almacenado en matrices o arrays), geoespaciales, texto (para búsquedas en cadenas de texto), Hash (indexa el hash del valor de un campo y se utiliza para admitir sharding basado en hash). MongoDB permite mantener múltiples copias de los datos en diferentes servidores. Un conjunto de réplicas (replica set) es un grupo de instancias monogod que mantienen el mismo conjunto de datos, y contiene varios nodos portadores de datos, y opcionalmente un nodo que funciona como árbitro. De los nodos que contienen datos, sólo uno de ellos es considerado primario, mientras que al resto se los considera nodos secundarios.

Las bases de datos semiestructuradas distribuidas se basan en un esquema de distribución con un nodo primario y réplicas en nodos secundarios.

La aplicación escribe y lee en el nodo primario al que esté conectada y éste replica los datos a los nodos secundarios. Se puede configurar que las lecturas se realicen también en los nodos secundarios para aumentar la disponibilidad.

La replicación en los nodos secundarios se realiza en forma asincrónica. Si se cae el nodo primario, se realiza un proceso de elección entre los nodos secundarios para que uno de ellos pase a ser primario. Los nodos secundarios se interconectan a través de un ping (heartbeat) que va y viene entre ambos. Cuando el nodo primario se recupere, deberá actualizar los datos que se perdió mientras estuvo fuera de servicio.

Si el que se cae es un nodo secundario no hay mayores problemas, ya que la aplicación trabaja con el nodo primario.

Para distribuir los documentos en una colección, se particiona la colección usando una clave shard o shard key, que consiste en un campo o campos inmutables que existen en cada documento de la colección de destino. Al determinar a través de qué atributos se van a fragmentar los datos, hace uso de fragmentación horizontal. Esta clave se elige cuando se fragmenta la colección y no puede modificarse luego de la fragmentación. Una colección fragmentada sólo puede tener una shard key.

Se pueden destacar los siguientes beneficios de la replicación (MongoDB Inc,2017):

 Proporciona redundancia y aumenta la disponibilidad de datos. Provee una tolerancia a fallos frente a la pérdida de un servidor de base de datos en particular.

En algunos casos, la réplica puede mejorar la capacidad de lectura dado que los clientes pueden enviar operaciones de lectura a distintos servidores.

 Puede aumentar la localidad de los datos (data locality) y la disponibilidad de las aplicaciones distribuidas.

 Recuperación de desastres, reporting, o backup.

Blockchain

Blockchain es una tecnología que plantea una arquitectura de datos que almacena determinados registros en forma distribuída siguiendo características que le dan gran seguridad y transparencia. Generalmente el registro de datos que se almacena es pequeño, de pocos campos, y da fe sobre algún hecho que ha ocurrido (por eso se lo suele llamar un “registro contable distribuido”). Las transacciones son solamente una transacción entre dos usuarios (un emisor y un receptor). En el caso de bitcoin, las mismas sólo consisten en una emisión de nuevas monedas o en la transferencia de dinero entre dos usuarios. No hay operaciones de modificación o eliminación, ya que la tecnología no está diseñada para ellas: sólo se permiten inserciones de nuevas transacciones (dichas operaciones podrían forzarse únicamente en un intento de fraude).

Para su funcionamiento utiliza una “red Blockchain” integrada por distintos nodos, que son responsables de asegurar el almacenamiento de copias de esos datos. Los distintos nodos (que suelen ser entidades distintas y funcionan bajo el criterio de que no pueden confiar entre sí) guardan una copia de esos registros (que podría denominarse la “base de datos”). Los registros de datos se incorporan mediante transacciones que generan un bloque (block), que se adicionan al final de la cadena de bloques (chain). Los datos que se incorporan a esta cadena son permanentes, y se guarda toda la historia.

Esta tecnología, entonces, es la de una base de datos distribuida que se sustenta en un protocolo que plantea la forma en que los datos deben ser ingresados, validados, almacenados y sincronizados las copias. Los datos se guardan encriptados, utilizando el concepto de firma digital, y su diseño evita la necesidad de terceras partes intermediarias que aseguren la veracidad, ya que la integridad está asegurada por el propio protocolo y los algoritmos de firma digital.

Todas las partes envueltas en una transacción deben proveer su aceptación (ingresando su clave privada). Todos los nodos de la red deben verificar que dichas partes tengan la capacidad de hacerlo. En la transferencia de un activo, uno debe acordar que lo transfiere y el otro que lo acepta. Luego debe conseguir que el bloque en el que fue incorporada este copiado en más de la mitad de los nodos de la red.

Arquitectura y componentes

La tecnología blockchain tiene los siguientes componentes:

• Registro: Es el elemento que se desea almacenar en la base de datos. Pueden ser o representar cualquier componente que pueda ser descrito en forma digital.
• Transacción: Es un movimiento de cambio de posesión de un registro entre dos propietarios, la adición o edición de un activo, o el registro de un hecho.
• Bloque: Conjunto de transacciones a registrar.
• Cadena: Es el conjunto de bloques que componen todos los datos y transacciones registradas en la base de datos. Los bloques se encuentran interrelacionados utilizando criptografía y asegurando una linealidad temporal. Toda blockchain es encabezada desde su inicio por un bloque especial denominado “Bloque Génesis”, que no tiene el código hash del bloque anterior aceptado.
• Protocolo: Son las reglas a través de los cuales se determina como las entradas son iniciadas, validadas, registradas y distribuidas.

Funcionamiento

Cuando se desea registrar una transacción, se la comunica a la mayor cantidad de nodos posibles, donde pasa por un proceso de verificación de origen e integridad y luego se la incluye junto con otras transacciones de un bloque. Ese bloque se agregará a la cadena y será comunicado a la mayor cantidad de nodos posibles.

La tecnología blockchain resuelve la necesidad de una autoridad certificante, es decir, la existencia de un tercero que prevenga la alteración de la transacción. Para eso, esta tecnología emplea el hash. Cada uno de los bloques que forman parte de una cadena, además de un hash que representa el contenido del propio bloque, tiene el hash del bloque anterior para asegurar el encadenamiento. Si se quisiera alterar el contenido de algún bloque de la cadena (lo que constituye un ataque) se alterarían todos los bloques siguientes: al modificar un bloque n se modifica su hash, contenido en el bloque n+1, lo que hace que éste se altere también y, por ende, su hash que, a su vez, está en el bloque n+2, y así sucesivamente. Cuanto más atrás en el tiempo se quiera alterar una transacción, más trabajo hay para recalcular los bloques.

Sin embargo, la tecnología blockchain le añade un salt ( random data) a cada bloque de la cadena. Este salto tiene la particularidad de no estar hecho al azar. Esto dificulta el proceso de calcular el hash ya que hay que encontrar un salto que cumpla una determinada condición(el hash debe comenzar con 00000). Esto es lo que le da seguridad. La única forma de encontrar ese salto es a través de la fuerza bruta, es decir, probar todas las combinaciones posibles de caracteres hasta encontrar uno que cumpla la condición. Por lo tanto, ya de por sí no es rápido calcular el hash de un solo bloque encontrando el salto que cumpla un criterio fijado; a eso se añade que hay que repetir el procedimiento para los bloques siguientes. Por más que se posea una gran capacidad computacional, durante ese lapso se realizan nuevas transacciones que implican el añadido de nuevos bloques a la cadena, retrasando la resolución del cálculo del hash.

Cuando un minero adiciona un bloque a esta cadena debe lograr ser aceptado por el resto de los nodos en un esquema de nodos que no confían entre sí. En el caso de bitcoin se trabaja en la búsqueda de una prueba de trabajo para el bloque. Estas pruebas de trabajo son los referidos cálculos matemáticos de fuerza bruta que los mineros deben resolver. Se prueban números hasta encontrar un hash (cálculo de una clave) que respete el criterio fijado. Cuando un nodo encuentra una prueba de trabajo, este debe transmitir el bloque a todos los nodos de la red (que también estaban buscando una prueba de trabajo), quienes pueden corroborar fácilmente que el cálculo está bien realizado. La aceptación por parte de los nodos involucrados se expresa trabajando en la creación del próximo bloque de la cadena, utilizando el hash del bloque aceptado como la clave anterior.

Los últimos bloques pueden ramificarse en el caso de que exista más de un bloque que haya logrado la prueba de trabajo. Estas bifurcaciones son transitorias, y se resuelven mediante la determinación de los nodos participantes respecto al bloque a ser asignado: siempre se acepta la cadena más larga. Así se aplica la consistencia eventual: cuando hay inconsistencias se trabaja en paralelo y, en algún momento, alguna de las regiones tendrá una cadena más larga que hará que se descarte la otra porque todos los nodos estarán de acuerdo en que ésa es la cadena de bitcoins.

La única forma de vulnerar este sistema es atacando y controlando a más del 50% de los nodos que estén minando. Al hacerlo, podría forzarse que dichos nodos elijan otra cadena que no sea la más larga. Sin embargo, al tener tanta cantidad de nodos en el mundo, se requiere de un poder computacional demasiado elevado para controlar a más de la mitad de los mismos, lo cual vuelve prácticamente imposible cualquier ataque. Por eso bitcoin es confiable. La fuerza de la blockchain está en la red que lo compone. Además, si efectivamente alguien posee semejante poder computacional, es más conveniente minar bitcoins para obtenerlos ya que el valor de esta moneda se mantiene a lo largo del tiempo. Otorga más dinero minar que alterar una transacción del pasado.

Estas ventajas de bitcoin no necesariamente son trasladables a otras implementaciones. Utilizarlo en ámbitos más reducidos que impliquen menos nodos vuelve más sencillo un ataque que controle más del 50% de los mismos (porque hay menos). Bitcoin tiene nodos distribuidos a lo largo del mundo, conectados en diferentes redes: implementar menos nodos en una misma red vuelve más vulnerable a la tecnología blockchain.

Tenemos nuevas propiedades ACID:

1. Autenticidad

C: confidencialidad

I- Integridad

D. disponibilidad

Beneficios

• Es prácticamente imposible que la información almacenada sea modificada una vez que ha sido validada. El hecho de que los datos sean inmutables aumenta la confiabilidad en la integridad de los datos y, a su vez, reduce la posibilidad de fraude.
• A pesar de ser un sistema abierto, es también semi-anónimo: los usuarios se identifican con claves públicas (seudónimos), en lugar de hacerlo con sus identidades reales.
• Los usuarios tienen la posibilidad de realizar transacciones y de transferir la propiedad de activos valiosos sin la necesidad de contar con la presencia de terceros, intermediarios o mediadores. De esta manera, blockchain tiene el potencial de reducir o inclusive eliminar los costos, retrasos y la complejidad en términos generales.
• Se caracteriza por su transparencia ya que, por un lado, almacena información relacionada con el origen de los activos y su cambio de propiedad a lo largo del tiempo, mientras que, por el otro, provee mecanismos que permiten verificar si la información relacionada con una transacción es válida.
• Al ser una red descentralizada y distribuida, únicamente dejará de funcionar si todos y cada uno de los nodos que la componen dejan de funcionar.
• Respecto de la recuperación ante fallos, dado que todos los nodos tienen una cadena y las transacciones sólo involucran una transacción, la recuperación es sencilla: el nodo dejará de funcionar hasta que se restaure y los otros nodos continuarán con su trabajo.

Gestión de datos

Operaciones de datos – actualizaciones y consulta de datos

Una transacción produce un nuevo registro en la base de datos de forma tal que se pueda identificar la transacción de manera unívoca. Esta transacción debe considerarse pendiente de confirmar hasta que la misma no forme un bloque validado, e inclusive podría considerarse no totalmente confirmada sin una cantidad n de bloques que la preceden.

El diseño de la tecnología blockchain asegura que ningún usuario de una entidad, responsable de un nodo, pueda modificar y borrar un registro, y tampoco podrá agregar un registro de datos sin el consenso del resto de los nodos de la red blockchain. Esto hace que se pueda asegurar la inmutabilidad de los datos.

Respecto del desempeño en la gestión de datos existe la necesidad de lograr mejoras para escalar el volumen de datos y de transacciones concurrentes si se quiere extender a diversas aplicaciones de negocio actuales. El protocolo de bitcoin de la prueba de trabajo para lograr el consenso es un método computacionalmente muy intensivo, y es parte del problema. Habiendo miles de computadoras minando bitcoins en el mundo y sólo una que encuentre una prueba de trabajo hace que haya un gran desperdicio de recursos. Sin embargo, es ese alto costo lo que le da su seguridad.

Por otro lado, un tema que impacta negativamente en la performance es la necesidad que impone esta tecnología de encriptar los datos. Finalmente, blockchain está diseñado principalmente como un repositorio de transacciones y no tiene resuelto cómo realizar tareas analíticas, así entonces las consultas sobre los datos con diversos operadores complejos y el uso de índices para optimizarlo necesita mayor evolución.

Modelo de gestión de datos

Si se toma la caracterización de bases de datos distribuidas, se puede plantear a blockchain como homogénea (los nodos utilizan el mismo software de gestión de datos), y de réplica completa (la totalidad de los datos tiene una copia en todos los nodos), y donde no existe la fragmentación (que implicaría distribuir el registro de los datos en distintos nodos según algún criterio). Se podría definir este enfoque como uno de “réplica completa eventual”, ya que las transacciones que formen parte de la cadena más larga tenderán a estar replicadas eventualmente en todos los nodos.

El desempeño de los bloques generados de blockchain es muy bajo, donde se generan unas pocas transacciones por segundo, y al mismo tiempo, no tienen la capacidad para manejar una cadena de bloques que vaya creciendo constantemente y que necesite una gran velocidad.

Propiedades ACID

Blockchain en general, y bitcoin en particular, no garantiza las propiedades ACID:

• No garantiza durabilidad de la misma forma que una base de datos transaccional. Si el nodo se cayó y no se replicó la transacción, no queda en la cadena (no espera a replicar antes de confirmar la transacción ingresada).
• No garantiza consistencia todo el tiempo, ya que trabaja con consistencia eventual. Al consultar dos nodos, puede que las cadenas sean distintas.
• Aislamiento y atomicidad sí están garantizadas ya que las transacciones que maneja son muy básicas.

Durante el proceso en que una transacción debe ser aceptada, hasta la replicación en todos los nodos una vez que el bloque es generado y agregado a la cadena, la base de datos queda en un estado inconsistente ya que se encuentra en un estado de cambio incorporando el nuevo bloque a la cadena. Por eso tiene una consistencia eventual.

Comparaciones, fortalezas y debilidades para la gestión de datos

Una de las desventajas reconocida en la réplica de datos es la sobrecarga (en performance) al momento de realizar una actualización. Este punto no aplica directamente a las bases de datos basadas en blockchain ya que las actualizaciones no requieren estar replicadas en todos los nodos para estar disponibles. En la tecnología blockchain que soporta a la moneda bitcoin el concepto de operación confirmada no existe, y existen reglas informales que determinan cuántos bloques deben ser posteriores al que incluye la operación para considerarla confirmada. Esta ausencia de una verdadera confirmación es una característica bastante distintiva de esta tecnología versus otras.

Otra característica distintiva es que se gastan valiosos recursos de cómputo y en forma redundante por parte de todos los nodos para obtener la prueba de trabajo, en lugar de usarse para mejorar la performance de la gestión de datos. Esta característica resulta en un bajísimo desempeño de la tecnología blockchain si se la compara con medidas de bases de datos tradicionales. Mayor cantidad de nodos implica mayor seguridad y disponibilidad, pero menor desempeño del sistema en su conjunto.

Los puntos fuertes para destacar son la seguridad y confianza que ofrece con respecto a la integridad de los datos, la confidencialidad y la disponibilidad de estos. También es destacable la tolerancia a fallos debido a la cantidad de nodos involucrados, robustez frente a manipulación, y cuando es una implantación pública, la transparencia. La característica de que los datos sean inalterables o inmutables es un aspecto incomparable frente a otras tecnologías.