No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Cloudbreak

9/15
Recursos

Tal vez te hayas preguntado en d贸nde almacena una Blockchain su informaci贸n. A medida que se validan transacciones, a cada segundo el peso de toda esa informaci贸n aumenta.

Bases de datos en una Blockchain

En la actualidad, tanto la Blockchain de Bitcoin como la de Ethereum rondan los 350 GB de informaci贸n almacenada. Un n煤mero que sin dudas continuar谩 creciendo con el tiempo.

Toda esta informaci贸n tiene que estar siendo escrita y le铆da continuamente, por lo que se necesita de un proceso r谩pido que permita esto.

La Blockchain de Bitcoin y Ethereum utilizan una base de datos NoSQL clave/valor llamada LevelDB para almacenar la informaci贸n. Se trata de un popular sistema para el guardado y acceso r谩pido a la informaci贸n que es desarrollado y mantenido por Google y otras importantes bases de datos como IndexedDB lo utilizan.

Pero LevelDB, a pesar de sus interesantes prestaciones, no es lo suficientemente 贸ptima para el prop贸sito de una Blockchain. Permite aproximadamente 5000 transacciones por segundo (TPS), no permite hacer escrituras y lecturas en simult谩neo.

Otra opci贸n podr铆a ser almacenar la informaci贸n en memoria RAM, pero no es lo m谩s 贸ptimo trat谩ndose de muchos gigas de informaci贸n.

Tal vez una buena opci贸n ser铆a guardar la informaci贸n en una memoria SSD, si bien es m谩s lenta que una RAM, pero SSD modernos pueden alcanzar los 32 subprocesos simult谩neos, lo que significa 370.000 lecturas por segundo o 185.000 TPS.

Si bien tanto GPU como SSD son r谩pidas, el problema siempre se encuentra en la CPU que suele ser m谩s lenta formando as铆 un cuello de botella.

Manejo de informaci贸n en Solana

Solana se diferencia de otras Blockchains al no utilizar una base de datos como LevelDB. En su lugar, implementa una l贸gica de guardado de la informaci贸n utilizando tanto de memoria RAM como la SSD para diferentes prop贸sitos, el cual se denomin贸 como Cloudbreak.

La informaci贸n se registra utilizando dos t茅cnicas:

  • Archivos mapeados en memoria.
  • Operaciones secuenciales en vez de aleatorias.
    • El 铆ndice de cuentas y bifurcaciones se almacena en la RAM.
    • Las cuentas se almacenan en archivos en memoria de hasta 4 MB de tama帽o.
    • Cada mapa de memoria solo almacena cuentas de una 煤nica bifurcaci贸n propuesta.
    • Los mapas se destruyen aleatoriamente en tantos SSD como est茅n disponibles.
    • Se utiliza sem谩ntica de copy on writes.
    • Las escrituras se agregan a un mapa de memoria aleatorio para la misma bifurcaci贸n.
    • El 铆ndice se actualiza despu茅s de que se completa cada escritura.

Todos estos procesos permiten que las actualizaciones de la cuenta se copien en la escritura y se agreguen a un SSD aleatoria, escalando tanto serialmente como horizontalmente.

Otra optimizaci贸n que implementa Solana es un Garbage Collector o recolector de basura que libera los espacios en memoria de las bifurcaciones que no fueron confirmadas y llevan mucho tiempo de retraso con respecto al estado actual de la red.

Enti茅ndase por bifurcaci贸n a la cadena de transacciones que continuamente los nodos crean al validar nuevas transacciones y proponen a la red para alcanzar el consenso sobre cu谩l de todas ellas es la correcta. La gran mayor铆a de las bifurcaciones se descartan y ese espacio en memoria debe liberarse para no consumir recursos de la red.

Conclusi贸n

Tal vez uno de los temas m谩s complicados de comprender sobre el funcionamiento de Solana. Su base de datos y persistencia de los mismos. En s铆ntesis, Solana hace uso de todos los recursos disponibles en el sistema entre todos los nodos de la red para poder registrar la informaci贸n.

La misma se encuentra en todo momento replicada en las memorias RAM o SSD de los nodos de la red y se busca optimizar la lectura a esta informaci贸n mapeando la misma y de manera secuencial.


Contribuci贸n creada por: Kevin Fiorentino (Platzi Contributor).

Aportes 12

Preguntas 2

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

Les dejo mis apuntes por si alguna persona le son 煤tiles entre algunos p谩rrafos pueden pegar las im谩genes de las diapositivas mostradas en la clase

Cloudbreak: Base de datos de escalado de cuenta horizontal

Level Db basa de datos tradicional que utilizan varias blockchain pero tiene un inconveniente y es que la base de datos no puede hacer uso de lecturas y escrituras simultaneas, por esta raz贸n tiene un m谩ximo de 5000 transacciones por segundo

Esta Imagen muestra el datasheet de una Samsung que es una ssd del mercado, a pesar de que la ssd tiene 30 veces menos costo por byte es mil veces mas lenta que una RAM. En la imagen podemos ver que este ssd tiene 500mil IOPS que son lecturas y escrituras simultaneas.

1 Subproceso que tiene un solo ssd con una capacidad m谩xima de 15 lecturas por segundo tendr铆amos m谩ximo 7500 transacciones por segundo

Los SSD modernos admiten 32 subprocesos simult谩neos, por lo que pueden admitir 370000 lecturas por segundo aproximadamente 185mil tps sin embargo organizar la base de datos en cuentas de manera que sea posible lecturas y escrituras simultaneas entre estos 32 subprocesos es un desaf铆o.

Hasta este punto en las blockchain tradicionales se ha generado un cuello de botella a pesar de que la GPU y la SSD tengan un mayor rendimiento la CPU no lo tiene.

Por esta raz贸n Solana no hace uso de una base de datos tradicional para resolver el problema al contrario utiliza los siguientes procedimientos:

1. Archivos Mapeados en memoria
2. Utiliza operaciones secuenciales en vez de aleatorias
	a. El 铆ndice de cuentas y bifurcaciones se almacena en RAM
	b. Las cuentas se almacenan en archivos asignados en memoria de hasta 4MB de tama帽o
	c. Cada mapa de memoria solo almacena cuentas de una 煤nica bifurcaci贸n propuesta
	d. Los mapas se destruyen aleatoriamente en tantos SSD como est茅n disponibles
	e. Se utiliza sem谩ntica de copy on writes
	f. Las escrituras se agregan a un mapa de memoria aleatorio para la misma bifurcaci贸n.
	g. El 铆ndice se actualiza despu茅s de que se completa cada escritura.

Todos estos procesos permiten que las actualizaciones de la cuenta se copien en la escritura y se agregen a un SSD aleatorio escalando tanto serialmente como horizontalmente

Otra de las optimizaciones que hace Solana es tener un recolector de basura que b谩sicamente lo que hace es eliminar las bifurcaciones que llevan mucho tiempo atrasadas, Bifurcaciones que ya no tienen confirmaciones sobre sus transacciones.

En conclusi贸n solana no usa una base de datos. Solana hace uso de las SSD disponibles en el sistema para poder registrar la informaci贸n de dos maneras una es los archivos mapeados en memoria y la segunda es las operaciones secuenciales en vez de aleatorias.

" LevelDB se utiliza como base de datos de backend para IndexedDB de Google Chrome y es uno de los backends compatibles con Riak. Adem谩s, Bitcoin Core y go-ethereum almacenan los metadatos de la cadena de bloques utilizando una base de datos LevelDB. Minecraft Bedrock Edition utiliza una versi贸n modificada para el almacenamiento de datos de fragmentos y entidades. Autodesk AutoCAD 2016 tambi茅n utiliza LevelDB. "

Solana hace uso de:

  • Archivos mapeados en memoria.
  • Operaciones secuenciales en vez de aleatorias.
  • Recolector de basura de bifurcaciones atrasadas.

En conclusi贸n, no hace uso de base de datos, sino de todas las SSDs disponibles para guardar la informaci贸n.

鈥淪olana no usa una base de datos. Hace uso de las SSD disponibles para registrar la informaci贸n gracias a los Archivos Mapeados en memoria y las Operaciones secuenciales en vez de aleatorias 鈥

CloudBreak

Base de datos de escalado de cuentas horizontal.

RESUMEN CLASE 9:
CLOUDBREAK

CLOUDBREAK
Base de datos de escalado de cuentas horizontal.

I.- DB PREDESESORES

II.- SSD

Los SSD modernos admiten 32 subprocesos simult谩neos, por lo que pueden admitir 370.000 lecturas por segundo, o aproximadamente 185.000 tps.

III.- CUELLO DE BOTELLA EN LOS PREDECESORES

IV.- SOLANA UTILIZA SSD DISPONIBLES DEL SISTEMA CON LAS SIGUIENTES OPTIMIZACIONES:

  • Archivos mapeados en memoria.

  • Operaciones secuenciales en vez de aleatorias.

V.- COMO SE HACER LAS OPERACIONES SECUENCIALES:

  1. El 铆ndice de cuentas y bifurcaciones se almacena en la RAM.

  2. Las cuentas se almacenan en archivos asignados en memoria de hasta 4 MB de tama帽o.

  3. Cada mapa de memoria solo almacena cuentas de una 煤nica bifurcaci贸n propuesta.

  4. Los mapas se distribuyen aleatoriamente en tantos SSD como est茅n disponibles.

  5. Se utiliza sem谩ntica de copy on writes.

  6. Las escrituras se agregan a un mapa de memoria aleatorio para la misma bifurcaci贸n.

  7. El 铆ndice se actualiza despu茅s de que se completa cada escritura.

VI.- Las actualizaciones de la cuenta se copian en escritura y se agregan a un SSD aleatorio.

VII.- RECOLECTOR DE BASURA

  • Elimina las bifurcaciones que llevan mucho tiempo atrazadas.

  • Bifurcaciones que ya no tienen confirmaciones de sus transacciones.

CASI TODAS LAS BLOCKCHAIN USAN LA BASE DE DATOS LEVELDB鈥

Es la soluci贸n implementada en Solana para gestionar la escritura y lectura de los datos: Hacer el uso de archivos mapeados en memoria y operaciones secuenciales en vez de aleatorias

Personalmente, la clase que m谩s me cost贸 compreder hasta ahora. muy bueno, les comparto un material que creo es el original desde el cual la profesora prepar贸 la clase.

Un datasheet, tambi茅n conocido como una hoja de datos o ficha t茅cnica, es un documento que se suele utilizar para la comunicaci贸n tecnol贸gica que describe las especificaciones, explica el rendimiento y las caracter铆sticas t茅cnicas de un producto, material, componente, m谩quina, etc.

Me hizo recordar mi 茅poca leyendo datasheet en la universidad de microchips que nunca termin茅 de entender.

Muy interesante, al ser nuevo en el mundo del manejo de base de datos esto implica una novedad total, espero despues conocer estos elementos de base de datos en los otros cursos de platzi.

LevelDB es una biblioteca de almacenamiento r谩pido de c贸digo abierto basada en pares clave-valor con almacenamiento en disco