Actualmente estoy trabajando en dApps para una cadena de bloques privada basada en ethereum. Si bien funciona bien y las dApps realmente muestran el poder de la cadena de bloques, carece de la velocidad y la versatilidad de una base de datos SQL. (¡Sé que conozco blockchain! = base de datos).
Ejemplo donde falta es obtener datos específicos. Debido a que no tiene consultas similares a SQL, necesita recorrer una gran cantidad de datos. O si tiene una matriz de una estructura que desea recuperar, esto también plantea un problema.
Así que estaba pensando en un mecanismo de almacenamiento en caché para almacenar en caché datos verificados por la red en una base de datos local para consultas rápidas.
Google falló al buscar esto, así que mi pregunta, ¿realmente no existe algo como esto? Si no existe, ¿qué debo tener en cuenta si quiero diseñar un sistema como este yo mismo?
Una respuesta en dos partes.
"necesitas hacer un bucle" : esto me llama la atención y merece un comentario. Los contratos inteligentes no le brindan almacenamiento indexado, pero esto no implica que un contrato deba recorrer datos desorganizados. De hecho, los contratos no deben pasar por conjuntos ilimitados. En cambio, significa que los contratos son responsables de organizar los datos internamente. Organice punteros/índices para admitir el acceso aleatorio y la interacción según sea necesario. Algunos ejemplos aquí. Consulte Estructura asignada con índice: ¿Existen patrones de almacenamiento sencillos y bien resueltos para Solidity?
Los contratos no deben pasar por filas/instancias porque eso tenderá a aumentar el costo de transacción. Más viajes de ida y vuelta = mayor costo. En el límite de gas del bloque, todas las transacciones fallarán . No es bueno.
DB Cache : es perfectamente válido crear una base de datos fuera de la cadena que esté vinculada a una fuente en la cadena. La fuente en cadena generalmente se considera autorizada. Si sigue la práctica de que todos los cambios de estado significativos deben ir acompañados de un evento emitido, entonces un servidor puede escuchar las operaciones de creación, actualización y eliminación. Cuando esto se hace con diligencia, debería ser posible iniciar una base de datos vacía y recrear todo el historial de estado del contrato: la base de datos debería ponerse al día con el estado en vivo.
Sitios como etherscan.io y los intercambios utilizan enfoques similares. Los visitantes realmente "acceden" a las bases de datos, por razones de rendimiento, y no a la cadena de bloques real.
Espero eso ayude.
solo_intentando_cosas
Rob Hitchens
solo_intentando_cosas
Rob Hitchens