MultiChain-feeds voor database-integratie

Gegevens uit de blockchain halen en de wijdere wereld in

Met de eerste openbare release van MultiChain, al in 2015, zagen we vanuit een verrassende richting interesse in blockchain-applicaties. Hoewel we MultiChain oorspronkelijk hadden ontworpen om de uitgifte, overdracht en bewaring van digitale activa mogelijk te maken, waren steeds meer gebruikers geïnteresseerd in het gebruik ervan voor datageoriënteerde applicaties.

In deze use-cases is het doel van de blockchain om het opslaan en ophalen van algemene informatie mogelijk te maken, die niet financieel van aard hoeft te zijn. De motivatie om een ​​blockchain te gebruiken in plaats van een reguliere database is om te voorkomen dat u vertrouwt op een vertrouwde tussenpersoon om die database te hosten en te onderhouden. Om commerciële, regelgevende of politieke redenen willen de gebruikers van de database dat dit een gedistribueerde in plaats van een gecentraliseerde verantwoordelijkheid is.

De evolutie van stromen

Als reactie op deze feedback hebben we in 2016 geïntroduceerd MultiChain-streams, die een eenvoudige abstractie bieden voor het opslaan, indexeren en ophalen van algemene gegevens op een blockchain. Een ketting kan een onbeperkt aantal streams bevatten, die elk door bepaalde adressen kunnen worden beperkt voor schrijven. Elk stream-item is getagd door het adres van de uitgever en een optionele sleutel voor toekomstig ophalen. Elk knooppunt kan onafhankelijk beslissen of hij zich op elke stream abonneert, waarbij de items in realtime worden geïndexeerd voor snel ophalen op sleutel, uitgever, tijd, blok of positie. Streams waren meteen een hit bij de gebruikers van MultiChain en onderscheidden het sterk van andere enterprise blockchain-platforms.

In 2017 waren er streams uitgebreid ter ondersteuning van native JSON- en Unicode-tekst, meerdere sleutels per item en meerdere items per transactie. Met deze laatste wijziging kunnen meer dan 10,000 individuele gegevensitems per seconde worden gepubliceerd op geavanceerde hardware. Vervolgens hebben we in 2018 naadloze ondersteuning toegevoegd voor off-chain gegevens, waarin slechts een hash van sommige gegevens on-chain wordt gepubliceerd en de gegevens zelf off-chain worden geleverd aan knooppunten die het willen. En later dat jaar brachten we MultiChain 2.0 Community uit met Slimme filters, waardoor aangepaste JavaScript-code willekeurige validatie van stream-items kan uitvoeren.

In 2019 lag onze focus op MultiChain 2.0 Enterprise, de commerciële versie van MultiChain voor grotere klanten. De eerste Enterprise-demo maakte gebruik van off-chain gegevens in streams om leesrechten toe te staan, versleutelde gegevenslevering en het selectief ophalen en opschonen van individuele items. Zoals altijd is de onderliggende complexiteit verborgen achter een eenvoudige set API's met betrekking tot machtigingen en streamitems. Met streams is ons doel altijd geweest om ontwikkelaars te helpen zich te concentreren op de gegevens van hun applicatie, en geen zorgen te maken over de blockchain die achter de schermen draait.

Het databankdilemma

Aangezien MultiChain-streams zich blijven ontwikkelen, staan ​​we voor een constant dilemma. Moet MultiChain het pad bewandelen om een ​​volwaardige database te worden voor het lezen en analyseren van de gegevens in een stream? Moet het JSON-veldindexering, geoptimaliseerde query's en geavanceerde rapportage bieden? Zo ja, welk databaseparadigma moet het gebruiken - relationeel (zoals MySQL of SQL Server), NoSQL (MongoDB of Cassandra), zoeken (Elastic of Solr), tijdreeksen (InfluxDB) of in het geheugen (SAP HANA)? Er zijn tenslotte blockchain-use cases die geschikt zijn voor elk van die benaderingen.

Een optie die we hebben overwogen, is het gebruik van een externe database als de primaire gegevensopslag van MultiChain, in plaats van de huidige combinatie van ingesloten LevelDB- en binaire bestanden. Deze strategie is vastgesteld door Ketenkern (Stopgezet), Postketen (nog niet openbaar) en is beschikbaar als een optie in Hyperledger Fabric. Maar uiteindelijk kozen we voor deze aanpak, vanwege de risico's van afhankelijkheid van een extern proces. U wilt niet echt dat uw blockchain-knooppunt vastloopt omdat het zijn databaseverbinding heeft verloren of omdat iemand een complexe query op zijn gegevensarchief uitvoert.

Een andere factor waarmee rekening moet worden gehouden, is technologie- en integratie-agnosticisme. In een blockchain-netwerk dat meerdere organisaties omvat, heeft elke deelnemer zijn eigen voorkeuren met betrekking tot databasetechnologie. Ze zullen al applicaties, tools en workflows hebben gebouwd op de platforms die aan hun behoeften voldoen. Dus bij het kiezen van een bepaalde database, of zelfs bij het aanbieden van een paar opties, zouden we sommige gebruikers uiteindelijk ongelukkig maken. Net zoals elke blockchain-deelnemer zijn knooppunt op een breed scala aan Linux-smaken kan draaien, moeten ze in staat zijn om te integreren met hun database naar keuze.

Introductie van MultiChain-feeds

Vandaag zijn we verheugd om onze benadering van database-integratie uit te brengen - MultiChain Feeds. Een feed is een realtime binair logboek op de schijf van de gebeurtenissen met betrekking tot een of meer blockchain-streams, voor lezen door externe processen. We bieden ook de open source MultiChain-voedingsadapter die een feed kan lezen en de inhoud automatisch kan repliceren naar een Postgres-, MySQL- of MongoDB-database (of meerdere tegelijk). De adapter is geschreven in Python en heeft een liberale licentie, zodat hij gemakkelijk kan worden gewijzigd om extra databases te ondersteunen of om gegevensfiltering en transformatie toe te voegen. (We hebben ook de feed bestandsformaat voor degenen die een parser in een andere taal willen schrijven.)

Een knooppunt hoeft zich niet te abonneren op een stream om de gebeurtenissen naar een feed te repliceren. Hierdoor kan de ingebouwde streamindexering van MultiChain volledig worden omzeild, om tijd en schijfruimte te besparen. Feeds weerspiegelen ook het ophalen en opschonen van off-chain-gegevens en kunnen rapporteren over de komst van nieuwe blokken op de ketting. Om schijfruimte te besparen, kunt u precies bepalen welke gebeurtenissen naar een feed worden geschreven en welke velden voor elk van die gebeurtenissen worden geregistreerd. Bovendien worden feedbestanden dagelijks geroteerd en is er een eenvoudige opschoningscommando om bestanden na verwerking te verwijderen.

Waarom worden MultiChain-feeds naar de schijf geschreven in plaats van gestreamd tussen processen of via het netwerk? Omdat we willen dat ze dienen als een uiterst betrouwbaar replicatielogboek dat bestand is tegen database-downtime, systeemcrashes, stroomuitval en dergelijke. Door schijfbestanden te gebruiken, kunnen we duurzaamheid garanderen en de doeldatabase asynchroon bijwerken. Als deze database om de een of andere reden overbelast of losgekoppeld raakt, kan MultiChain zonder onderbreking blijven werken en zal de database de achterstand inhalen zodra alles weer normaal is.

Aan de slag met feeds

Feeds zijn geïntegreerd in de nieuwste demo / bèta van MultiChain Enterprise Beschikbaar voor download nu. Ga aan de slag door de documentatie voor de MultiChain-voedingsadapter, of het herzien van de feed-gerelateerde API's. We zouden graag hoor uw feedback over deze functie en hoe we deze in de toekomst kunnen uitbreiden.

Met de release van feeds is versie 2.0 van MultiChain Enterprise nu compleet - zie de Download en installeer pagina voor een volledige vergelijking tussen de Community- en Enterprise-edities. De komende maanden zullen we de tests en optimalisatie voltooien en verwachten dat het product rond het einde van het eerste kwartaal gereed zal zijn voor productie. In de tussentijd, voor informatie over MultiChain Enterprise-licenties of prijzen, aarzel dan niet om dat te doen Neem gerust contact op!.

Plaats eventuele opmerkingen op LinkedIn.

Bron: https://www.multichain.com/blog/2020/02/multichain-feeds-for-database-integration/