MultiChain-flöden för databasintegration

Få ut data ur blockkedjan och ut i världen

Med den första offentliga utgåvan av MultiChain, långt tillbaka 2015, såg vi intresse för blockkedjeapplikationer från ett överraskande håll. Medan vi ursprungligen hade designat MultiChain för att möjliggöra utfärdande, överföring och förvaring av digitala tillgångar, var ett ökande antal användare intresserade av att använda den för dataorienterade applikationer.

I dessa användningsfall är blockkedjans syfte att möjliggöra lagring och hämtning av allmän information, som inte behöver vara ekonomisk till sin natur. Motivationen för att använda en blockchain snarare än en vanlig databas är att undvika att förlita sig på en pålitlig mellanhand för att vara värd för och underhålla databasen. Av kommersiella, regulatoriska eller politiska skäl vill databasens användare att detta ska vara ett distribuerat snarare än ett centraliserat ansvar.

Strömmarnas utveckling

Som svar på denna feedback har vi 2016 introducerade MultiChain-strömmar, som ger en enkel abstraktion för lagring, indexering och hämtning av allmän data på en blockkedja. En kedja kan innehålla valfritt antal strömmar, som var och en kan begränsas för skrivning av vissa adresser. Varje strömobjekt är taggat av adressen till dess utgivare samt en valfri nyckel för framtida hämtning. Varje nod kan självständigt bestämma om den ska prenumerera på varje ström, indexera dess objekt i realtid för snabb hämtning efter nyckel, utgivare, tid, block eller position. Strömmar var en omedelbar hit bland MultiChains användare och skilde den starkt från andra blockkedjeplattformar för företag.

Under 2017 var strömmar förlängas för att stödja inbyggd JSON- och Unicode-text, flera nycklar per objekt och flera objekt per transaktion. Denna sista ändring tillåter att över 10,000 2018 individuella dataposter publiceras per sekund på avancerad hårdvara. Sedan XNUMX lade vi till sömlöst stöd för data utanför kedjan, där endast en hash av vissa data publiceras i kedjan, och själva data levereras utanför kedjan till noder som vill ha det. Och senare samma år släppte vi MultiChain 2.0 Community med Smarta filter, vilket tillåter anpassad JavaScript-kod att utföra godtycklig validering av strömobjekt.

Under 2019 fokuserade vi på MultiChain 2.0 Enterprise, den kommersiella versionen av MultiChain för större kunder. Den första Enterprise Demo utnyttjade off-chain-data i strömmar för att möjliggöra läsbehörighet, krypterad dataleverans och selektiv hämtning och rensning av enskilda objekt. Som alltid är den underliggande komplexiteten gömd bakom en enkel uppsättning API:er som relaterar till behörigheter och strömobjekt. Med strömmar har vårt mål konsekvent varit att hjälpa utvecklare att fokusera på sin applikations data och inte oroa sig för att blockkedjan kör bakom kulisserna.

Databasdilemmat

Eftersom MultiChain-strömmar har fortsatt att utvecklas har vi ställts inför ett konstant dilemma. För att läsa och analysera data i en ström, bör MultiChain gå på vägen mot att bli en fullfjädrad databas? Ska det erbjuda JSON-fältindexering, optimerad sökning och avancerad rapportering? Om så är fallet, vilket databasparadigm ska den använda - relationell (som MySQL eller SQL Server), NoSQL (MongoDB eller Cassandra), sökning (Elastic eller Solr), tidsserier (InfluxDB) eller in-memory (SAP HANA)? Det finns trots allt blockchain-användningsfall som passar var och en av dessa tillvägagångssätt.

Ett alternativ vi övervägde är att använda en extern databas som MultiChains primära datalager, istället för den nuvarande kombinationen av inbäddade LevelDB och binära filer. Denna strategi antogs av Kedjekärna (Utgångna), Postkedja (ännu inte offentlig) och är tillgänglig som ett alternativ i Hyperledger Fabric. Men till slut beslutade vi oss för detta tillvägagångssätt, på grund av riskerna med att vara beroende av en extern process. Du vill egentligen inte att din blockchain-nod ska frysa för att den tappade sin databasanslutning eller för att någon kör en komplex fråga på dess datalager.

En annan faktor att ta hänsyn till är teknologi- och integrations-agnosticism. I ett blockchain-nätverk som spänner över flera organisationer kommer varje deltagare att ha sina egna preferenser när det gäller databasteknik. De kommer redan att ha applikationer, verktyg och arbetsflöden byggda på de plattformar som passar deras behov. Så genom att välja en viss databas, eller till och med erbjuda några alternativ, skulle vi sluta göra vissa användare missnöjda. Precis som varje blockchain-deltagare kan köra sin nod på en mängd olika Linux-smaker, bör de kunna integreras med sin valbara databas.

Vi introducerar MultiChain Feeds

Idag är vi glada över att släppa vår strategi för databasintegration – MultiChain Feeds. Ett flöde är en binär logg i realtid på disken över händelser relaterade till en eller flera blockchain-strömmar, för läsning av externa processer. Vi erbjuder även öppen källkod Multikedjematningsadapter som kan läsa ett flöde och automatiskt replikera dess innehåll till en Postgres-, MySQL- eller MongoDB-databas (eller flera samtidigt). Adaptern är skriven i Python och har en liberal licens, så den kan enkelt modifieras för att stödja ytterligare databaser eller för att lägga till datafiltrering och transformation. (Vi har också dokumenterat flödesfilformat för de som vill skriva en parser på ett annat språk.)

En nod behöver inte prenumerera på en stream för att replikera dess händelser till ett flöde. Detta gör att MultiChains inbyggda streamindexering helt kan kringgås, för att spara tid och diskutrymme. Flöden återspeglar också hämtning och rensning av data utanför kedjan och kan rapportera om ankomsten av nya block i kedjan. För att spara på diskutrymme kan du kontrollera exakt vilka händelser som skrivs till en feed och vilka fält som registreras för var och en av dessa händelser. Dessutom roteras flödesfiler dagligen och det finns ett enkelt rensningskommando för att ta bort filer efter bearbetning.

Varför skrivs MultiChain-flöden till disk istället för att streamas mellan processer eller över nätverket? Eftersom vi vill att de ska fungera som en ultratillförlitlig replikeringslogg som är motståndskraftig mot databasstopp, systemkrascher, strömavbrott och liknande. Genom att använda diskfiler kan vi garantera hållbarhet och tillåta att måldatabasen uppdateras asynkront. Om databasen av någon anledning blir överbelastad eller kopplad ur, kan MultiChain fortsätta att fungera utan avbrott, och databasen kommer ikapp när allt återgår till det normala.

Komma igång med flöden

Flöden är integrerade i den senaste demo/betan av MultiChain Enterprise, dvs tillgängliga för nedladdning nu. Kom igång genom att läsa dokumentationen för Multikedjematningsadapter, eller granska flödesrelaterade API:er. Vi vill gärna hör din feedback om den här funktionen och hur vi kan utöka den i framtiden.

Med lanseringen av flöden är version 2.0 av MultiChain Enterprise nu funktionen komplett – se Hämta och installera sida för en fullständig jämförelse mellan Community- och Enterprise-utgåvorna. Under de kommande månaderna kommer vi att slutföra dess testning och optimering, och förväntar oss att den är klar för produktion i slutet av Q1. Under tiden, för information om MultiChain Enterprise-licenser eller prissättning, tveka inte att göra det komma i kontakt.

Skicka eventuella kommentarer på Link.

Källa: https://www.multichain.com/blog/2020/02/multichain-feeds-for-database-integration/