Ci sono vantaggi nell'avere uno strato di database di sola lettura di tipo SQL su un libro mastro distribuito Blockchain? [chiuso]

Naviga le tue risposte
-2

I datastore Blockchain distribuiti forniscono inesigibilità alle transazioni registrate e consentono solo di aggiungere record accettati da un algoritmo di consenso in sequenza. È possibile memorizzare i dati sulla blockchain o avere riferimenti a dove i dati potrebbero vivere in altri archivi di dati. La blockchain non mi sembra una struttura dati ideale per eseguire query aggregate (supponendo che un client lo consenta) a cui serve un database di tipo SQL. Ad esempio, se desidero conoscere il reddito annuale per un determinato indirizzo nel libro mastro, un modo per farlo sarebbe creare una struttura piatta per tutti gli elementi nel campo elenco transazioni ed eseguire un gruppo per operazione per indirizzo e anno, e infine sommare il campo dell'importo. Una struttura appiattita si adatterebbe in un tavolo denormalizzato. Inoltre, ci sono dei libri mastri in grado di registrare campi complessi per ogni transazione, ad esempio i dati del dispositivo IoT. È assurdo pensare che i livelli di sola lettura di tipo SQL siano una buona soluzione per fare interrogazioni per estrarre informazioni dettagliate? Quali altri vantaggi o svantaggi mi mancano?

    
posta KJP 04.03.2018 - 18:55
fonte

2 risposte

2

Sì, e credo che tu abbia già identificato i vantaggi.

Una struttura blockchain non è una buona struttura per la ricerca dei dati: devi spesso cercare l'intera catena. Se si stanno facendo ricerche, è una buona idea avere qualche tipo di indicizzazione ausiliaria. Un modo per farlo sarebbe copiare tutti i dati dalla blockchain in un database SQL.

    
risposta data 04.03.2018 - 23:45
fonte
1

Viene fornito un avvertimento sull'impostazione di un DB di sola lettura SQL-Like per il registro blockchain. Per cominciare, non sono un esperto di blockchain ma ho le conoscenze di base per dirvi in termini di progettazione dei dati come questo sarebbe un incubo.

In primo luogo, un database SQL-like richiede dati ordinati, perché il libro mastro distribuito che recupera tutti i blocchi in una blockchain per impostare un DB di sola lettura sarebbe l'operazione più costosa.

In secondo luogo, non aggiornerai quel readOnly DB per transazione, se lo fai ci si pone il problema di ordinare i dati. In terzo luogo, l'informazione per identità dell'account è crittografata, di solito in 34 caratteri (per caso BTC) e dover ordinare le cose o anche una query "raggruppa per" per raggruppare i dati orientati alle stringhe sarebbe un'aggiunta alla strega malvagia che pende al rialzo giù dal tuo ventilatore a soffitto.

Potresti ottenere risultati migliori con NoSQL solo perché, anche se i dati sono organizzati, a lungo termine è altamente disorganizzato, e quindi se puoi semplicemente salvare i dati basati su blockchain-user-account-id e aggiungi di conseguenza dei valori o forse un oggetto "cronologico", che potrebbe rivelarsi un'opzione migliore per te.

Finora riesco a vedere la complessità di tale soluzione attraverso i tuoi occhiali come n ^ 2. Forse NoSQL potrebbe spremere le cose per te in questo scenario.

Il resto è tutto a tua scelta. Buona giornata. :)

    
risposta data 04.03.2018 - 21:51
fonte

Leggi altre domande sui tag

Opposto di mutare [chiuso] Qual è la complessità temporale delle permutazioni?