MultiChain-feeds til databaseintegration

Få data ud af blockchain og ud i den bredere verden

Med den første offentlige udgivelse af MultiChain, helt tilbage i 2015, så vi interesse for blockchain-applikationer fra en overraskende retning. Mens vi oprindeligt havde designet MultiChain til at muliggøre udstedelse, overførsel og opbevaring af digitale aktiver, var et stigende antal brugere interesserede i at bruge det til dataorienterede applikationer.

I disse tilfælde er blockchainens formål at muliggøre lagring og genfinding af generelle formålsoplysninger, som ikke behøver at være af økonomisk karakter. Motivationen for at bruge en blockchain frem for en almindelig database er at undgå at stole på en betroet mellemmand til at hoste og vedligeholde denne database. Af kommercielle, regulatoriske eller politiske årsager ønsker databasens brugere, at dette skal være et distribueret snarere end et centraliseret ansvar.

Udviklingen af ​​strømme

Som svar på denne feedback har vi i 2016 introduceret MultiChain-streams, som giver en simpel abstraktion til lagring, indeksering og genfinding af generelle data på en blockchain. En kæde kan indeholde et hvilket som helst antal streams, som hver kan være begrænset til skrivning af bestemte adresser. Hvert stream-element er tagget af dens udgivers adresse samt en valgfri nøgle til fremtidig hentning. Hver node kan selvstændigt beslutte, om den skal abonnere på hver strøm, og indeksere dens elementer i realtid for hurtig hentning efter nøgle, udgiver, tid, blok eller position. Streams var et øjeblikkeligt hit hos MultiChains brugere og adskilte det stærkt fra andre enterprise blockchain-platforme.

I 2017 var streams udvidet til at understøtte indbygget JSON- og Unicode-tekst, flere nøgler pr. vare og flere elementer pr. transaktion. Denne sidste ændring gør det muligt at publicere over 10,000 individuelle dataelementer i sekundet på avanceret hardware. Så i 2018 tilføjede vi problemfri support til off-chain data, hvor kun en hash af nogle data publiceres på kæden, og selve dataene leveres off-chain til noder, der ønsker det. Og senere samme år udgav vi MultiChain 2.0 Community med Smarte filtre, der tillader tilpasset JavaScript-kode at udføre vilkårlig validering af stream-elementer.

I løbet af 2019 vendte vores fokus sig mod MultiChain 2.0 Enterprise, den kommercielle version af MultiChain til større kunder. Den første Enterprise Demo udnyttede off-chain data i strømme for at tillade læsetilladelser, krypteret datalevering og selektiv hentning og udrensning af individuelle elementer. Som altid er den underliggende kompleksitet skjult bag et simpelt sæt API'er relateret til tilladelser og stream-elementer. Med streams har vores mål konsekvent været at hjælpe udviklere med at fokusere på deres applikations data og ikke bekymre sig om, at blockchain kører bag kulisserne.

Databasedilemmaet

Efterhånden som MultiChain-streams er blevet ved med at udvikle sig, har vi stået over for et konstant dilemma. For at læse og analysere dataene i en strøm, bør MultiChain gå ned ad vejen til at blive en fuldgyldig database? Skal det tilbyde JSON-feltindeksering, optimeret forespørgsel og avanceret rapportering? Hvis ja, hvilket databaseparadigme skal den bruge - relationel (som MySQL eller SQL Server), NoSQL (MongoDB eller Cassandra), søgning (Elastic eller Solr), tidsserier (InfluxDB) eller in-memory (SAP HANA)? Der er trods alt blockchain-brugstilfælde, der passer til hver af disse tilgange.

En mulighed, vi overvejede, er at bruge en ekstern database som MultiChains primære datalager, i stedet for den nuværende kombination af indlejrede LevelDB og binære filer. Denne strategi blev vedtaget af Kædekerne (udgået), Postkæde (endnu ikke offentlig) og er tilgængelig som en mulighed i Hyperledger Fabric. Men i sidste ende besluttede vi os imod denne tilgang på grund af risikoen ved at være afhængig af en ekstern proces. Du ønsker ikke rigtig, at din blockchain-node fryser, fordi den mistede sin databaseforbindelse, eller fordi nogen kører en kompleks forespørgsel på dens datalager.

En anden faktor at overveje er teknologi- og integrations-agnosticisme. I et blockchain-netværk, der spænder over flere organisationer, vil hver deltager have deres egne præferencer med hensyn til databaseteknologi. De vil allerede have applikationer, værktøjer og arbejdsgange bygget på de platforme, der passer til deres behov. Så ved at vælge en bestemt database, eller endda ved at tilbyde nogle få muligheder, ville vi ende med at gøre nogle brugere utilfredse. Ligesom hver blockchain-deltager kan køre deres node på en bred vifte af Linux-varianter, bør de være i stand til at integrere med deres foretrukne database.

Introduktion af MultiChain Feeds

I dag er vi glade for at frigive vores tilgang til databaseintegration – MultiChain Feeds. Et feed er en real-time on-disk binær log over hændelser relateret til en eller flere blockchain streams, til læsning af eksterne processer. Vi tilbyder også open source Multikæde foderadapter som kan læse et feed og automatisk replikere dets indhold til en Postgres-, MySQL- eller MongoDB-database (eller flere på én gang). Adapteren er skrevet i Python og har en liberal licens, så den let kan ændres til at understøtte yderligere databaser eller tilføje datafiltrering og transformation. (Vi har også dokumenteret feed filformat for dem, der ønsker at skrive en parser på et andet sprog.)

En node behøver ikke abonnere på en strøm for at replikere dens begivenheder til et feed. Dette gør det muligt at omgå MultiChains indbyggede stream-indeksering fuldstændigt, for at spare tid og diskplads. Feeds afspejler også hentning og udrensning af off-chain-data og kan rapportere om ankomsten af ​​nye blokke på kæden. For at spare på diskplads kan du kontrollere præcis, hvilke hændelser der skrives til et feed, og hvilke felter der optages for hver af disse hændelser. Derudover roteres feed-filer dagligt, og der er en simpel rensekommando til at fjerne filer efter behandling.

Hvorfor skrives MultiChain-feeds til disk i stedet for at streames mellem processer eller over netværket? Fordi vi ønsker, at de skal fungere som en ultra-pålidelig replikeringslog, der er modstandsdygtig overfor databasenedetid, systemnedbrud, strømtab og lignende. Ved at bruge diskfiler kan vi garantere holdbarhed og tillade, at måldatabasen opdateres asynkront. Hvis denne database af en eller anden grund bliver overbelastet eller afbrudt, kan MultiChain fortsætte med at fungere uden afbrydelser, og databasen vil indhente det, når tingene vender tilbage til det normale.

Kom godt i gang med feeds

Feeds er integreret i den seneste demo/beta af MultiChain Enterprise, som er tilgængelig til download nu. Kom i gang ved at læse dokumentationen til Multikæde foderadapter, eller gennemgang af feed-relaterede API'er. Det vil vi gerne hør din feedback om denne funktion, og hvordan vi kan udvide den i fremtiden.

Med udgivelsen af ​​feeds er version 2.0 af MultiChain Enterprise nu funktion komplet – se Hent og installer side for en fuldstændig sammenligning mellem Community- og Enterprise-udgaverne. I løbet af de næste par måneder vil vi færdiggøre dens test og optimering, og forventer, at den er klar til produktion omkring slutningen af ​​1. kvartal. I mellemtiden, for information om MultiChain Enterprise-licenser eller priser, skal du ikke tøve med at komme i kontakt.

Skriv eventuelle kommentarer på LinkedIn.

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