Ich arbeite derzeit an dApps für eine private Blockchain auf Basis von Ethereum. Während es gut funktioniert und die dApps wirklich die Leistungsfähigkeit der Blockchain zeigen, fehlt es ihr an der Geschwindigkeit und Vielseitigkeit einer SQL-Datenbank. (Ich weiß, dass ich Blockchain kenne! = Datenbank).
Ein Beispiel, wo es fehlt, ist das Erhalten spezifischer Daten. Da Sie keine SQL-ähnlichen Abfragen haben, müssen Sie viele Daten durchlaufen. Oder wenn Sie ein Array einer Struktur haben, die Sie zurückhaben möchten, stellt dies ebenfalls ein Problem dar.
Also dachte ich über einen Caching-Mechanismus nach, um Daten, die vom Netzwerk überprüft werden, in einer lokalen Datenbank für schnelle Abfragen zwischenzuspeichern.
Google hat bei der Suche danach versagt, also meine Frage, gibt es so etwas wirklich nicht? Wenn es nicht existiert, was muss ich beachten, wenn ich selbst ein System wie dieses entwerfen möchte.
Eine zweiteilige Antwort.
"you need to loop" : Das fällt mir gerade auf und verdient einen Kommentar. Smart Contracts geben Ihnen keinen indizierten Speicher, aber das bedeutet nicht, dass ein Vertrag unorganisierte Daten durchlaufen sollte. Tatsächlich dürfen Verträge keine unbegrenzten Mengen durchlaufen. Stattdessen bedeutet dies, dass Verträge für die interne Organisation der Daten verantwortlich sind. Organisieren Sie Zeiger/Indizes, um den wahlfreien Zugriff und die Interaktion nach Bedarf zu unterstützen. Einige Beispiele hier. Siehe Mapped Struct with Index: Gibt es gut gelöste und einfache Speichermuster für Solidity?
Verträge dürfen Zeilen/Instanzen nicht durchlaufen, da dies tendenziell zu steigenden Transaktionskosten führt. Mehr Hin- und Rückfahrten = höhere Kosten. Am Blockgaslimit schlagen alle Transaktionen fehl . Nicht gut.
DB-Cache : Es ist vollkommen gültig, eine Off-Chain-Datenbank zu erstellen, die an eine On-Chain-Quelle gebunden ist. Die On-Chain-Quelle wird normalerweise als maßgebend angesehen. Wenn Sie der Praxis folgen, dass alle signifikanten Statusänderungen von einem ausgegebenen Ereignis begleitet werden sollten, kann ein Server auf Erstellungs-, Aktualisierungs- und Löschvorgänge lauschen. Wenn dies sorgfältig durchgeführt wird, sollte es möglich sein, eine leere Datenbank zu booten und den gesamten Statusverlauf des Vertrags neu zu erstellen – die Datenbank sollte den Live-Status einholen.
Seiten wie etherscan.io und Börsen verwenden ähnliche Ansätze. Besucher "schlagen" aus Leistungsgründen wirklich auf Datenbanken und nicht auf die eigentliche Blockchain.
Ich hoffe es hilft.
just_trying_stuff
Rob Hitchens
just_trying_stuff
Rob Hitchens