Buckets of Bits

18 augustus 2022

De ‘bit-emmer’ was de informele naam van de bak waar de kleine perfo­ra­ties van papier van pons­ma­chines werden opge­vangen. De term ‘bit-emmer’ werd ook gebruikt als grap voor de plaats waar ‘verdwenen data’ of ‘nutteloze bits’ terecht kwamen. Het werd zelfs als computer-concept bekend als het nulap­pa­raat of /​dev/​null: de bitstroom die geen compu­ter­bronnen zoals CPU of geheugen gebruikt. Alle data die daarop wordt ‘geschreven’, mag uitein­de­lijk als onnodig worden wegge­gooid (System.IO.Stream.Null).

Ook werd het vaak gebruikt in aller­hande grappen om een data-opslag­plek aan te duiden waar niets met de data zou worden gedaan. Zoals ‘stuur alstu­blieft uw klachten naar /​dev/​null’. Op 1 april 1972 werd zelfs WORN gepre­sen­teerd, de ‘bit-emmer’ voor: ‘Write Once, Read Never’.

Emmertjes data

Als we over data-opslag spreken, is ‘buckets of bits’ een analogie. Bits van een dataset worden als file – fysiek gezien – in een emmertje bewaard. Die emmertjes worden ‘ergens’ neergezet en bewaard. Of gedu­pli­ceerd, gelabeld, over meer emmers verdeeld etc. Vooral voor niet data-onder­legde personen zijn ‘buckets of bits’ een mooie analogie om data-opslag en ‑repli­catie concepten en om het begrip metadata uit te leggen. Mijn vorige blog ging over content addres­sable storage, een cryp­to­gra­fisch concept waarbij de ‘inhoud’ van het emmertje de hashcode en dus de ‘iden­ti­fi­catie’ op het label aan het hengsel bepaalt: de metadata van de file.

Data­op­slag kan men verge­lijken met het slim bij elkaar houden in een omhulling van een set bits, hier dus de emmer. Zo’n emmer kan klein zijn, maar ook grotere propor­ties aannemen. Voordeel van een emmer is dat het de inhoud op een simpele wijze bij elkaar houdt, zich aan de hengsel laat optillen en vervoeren en men de inhoud ook over andere emmers kan verdelen of over­gieten. Nadeel van een emmer is dat je kunt morsen, hij kan omvallen, de inhoud vervuilt of wordt gestolen. Je moet er voor­zichtig mee omgaan. Daarnaast kun je emmers met identieke inhoud niet makkelijk uit elkaar houden; welke is de master en welke de slave?

Emmers dubbelen

Om het gevaar van omvallen te vermin­deren, kan een tweede identieke emmer met dezelfde inhoud op een andere plek worden weggezet. De kans dat beide emmers tege­lij­ker­tijd omvallen, is een stuk geringer. Bij twijfel kan zelfs een derde emmer worden toege­voegd. In feite doen we dit met onze data ook. We repli­ceren realtime het emmertje met data en zetten het in een tweede data­cen­trum in de buurt. Finan­ciële instel­lingen maken zelfs een derde emmer die ze op honderden kilo­me­ters afstand plaatsen.

Natuur­lijk moet zo’n emmertje wel voor­zichtig naar de locatie worden vervoerd waar hij vervol­gens wordt opge­slagen. Data­re­pli­catie staat en valt bij een goed geregeld vervoer. Daarvoor ontstonden speciale storage netwerken. We onder­scheiden hierbij SAN (Storage Area Network) en NAS (Network Attached Storage) om betrouw­baar emmertjes over grotere afstanden uit te wisselen, te gebruiken en te repli­ceren. Een SAN werkte met een FC (fibre channel) protocol, NAS met een IP (Internet) protocol, in feite tech­ni­sche afspraken over de wijze waarop we emmertjes uitwis­selden. Tegen­woordig is het met nieuwe proto­collen mogelijk geworden beide vormen van repli­catie over hetzelfde netwerk te laten gaan. In dat kader is het met de komst van internet allemaal wat makke­lijker geworden, hoewel een bericht van bewezen data-ontvangst nog steeds essen­tieel is voor de kwaliteit.

Gestructureerd of ongestructureerd

Een emmertje met data is lastig te herkennen. De storage systemen nummerden daarom de emmertjes zelf en regi­streerden waar ze het emmertje opborgen. Als een emmertje weer werd opge­vraagd, kon het systeem het op die wijze terug­zoeken. Echter het bleven voor het storage systeem ‘anonieme’ emmertjes met onbekende inhoud. De appli­catie, die het emmertje had gevuld, wist natuur­lijk wel wat in het emmertje zat, het storage systeem niet. We noemen dit ook wel ‘gestruc­tu­reerde data’. Data die bij een speci­fieke appli­catie hoort.

In het begin was bijna alle data gestruc­tu­reerd. Dat wil zeggen dat de inhoud een serie velden van een database was, die door een appli­catie op een speci­fieke volgorde was wegge­schreven. Dus eigenlijk was er weinig behoefte om de inhoud van de emmer te kennen, want de inhoud was alleen voor de gebruikte appli­catie leesbaar. Maar in de loop der tijd ontstond meer en meer onge­struc­tu­reerde data. Infor­matie die in gene­rie­kere appli­ca­ties werd gecreëerd en bepaalde herken­bare interne struc­turen kent. Denk aan tekst­ver­wer­king, spread­sheets, e‑mails, presen­ta­ties en allerlei social media appli­ca­ties. Infor­matie waarvan een deel of alles door iedereen te lezen is. Tegen­woordig is bijna alle data onge­struc­tu­reerde data, volgens het recente IDC onderzoek over datagroei zelfs meer dan 90%.

Labels aan het hengsel

Maar voor een storage systeem blijft een emmertje een emmertje, ongeacht de data die men erin heeft gestopt. Ook in onge­struc­tu­reerde data blijft het lastig zoeken. Het ‘hoort’ niet bij een appli­catie en aan de buiten­kant is ook weinig verschil te zien. De oplossing hiervoor – beslist niet nieuw – is aan elke emmer een label te hangen met infor­matie over de inhoud. We noemen dat meta-data: data over de data. Dat vraagt wel weer disci­pline en inspan­ning. Het liefst vóórdat men een emmertje gaat vullen, zou je het hoe, wat en waarom van dat emmertje willen weten. Is het project­in­for­matie? Welk project? Wie heeft het gemaakt? Is het bevei­ligde data? Is het gekoppeld in een workflow? Kortom, alle relevante infor­matie op het label van het emmertje opdat we in de data­op­slag makke­lijker die data kunnen terugvinden.

Document mana­ge­ment of content mana­ge­ment systemen zijn gebaseerd op het aanmaken en bijhouden van deze meta-data tijdens de levens­cy­clus van een emmertje data. Een garantie dat een emmertje data aan bepaalde compli­ance eisen voldoet. Want op basis van het label weet men precies waar die data vandaan komt en wat er met die data gebeurd is. Wat men er wel en niet mee mag doen. Hoewel Content Mana­ge­ment Systemen al ruim 30 jaar bestaan, zien we de laatste jaren weer een opbloei. Wereld­wijde gover­nance en compli­ance dwingen steeds meer orga­ni­sa­ties tot het gecon­tro­leerd maken, opslaan, beheren en gebruiken van hun data.

Datacentrisch transformeren

Data in al die emmertjes is de basis voor infor­matie en kennis voor speci­fieke gebrui­kers. Met appli­ca­ties, algo­ritmes en workflows zorgen we dat de juiste data tot de gewenste infor­matie wordt gevormd. Of dat nu data vanuit een centrale cloud, een decen­trale node, een edge-device of uit een data-sensor is, maakt niet uit. Infor­matie mana­ge­ment is die juiste data, samen­ge­steld tot infor­matie op het gewenste moment bij de speci­fieke gebruiker te krijgen. Het beheren en managen van al die emmertjes data is daarvoor wel een must. Niet alleen van de actuele data, maar ook de (tijdelijk) slapende data en formeel gear­chi­veerde data.

Soms val ik in presen­ta­ties nog wel eens terug op het ‘oude’ verhaal van de data-emmertjes. Infor­ma­tie­tech­niek is inge­wik­keld en abstract. Virtu­a­li­satie, multi-cloud en decen­tra­li­satie maakt het allemaal nog diffuser. Soms is het goed om met beide benen op de grond te staan en het te hebben over hoe en wat van die simpele ‘buckets of bits’ die altijd ‘ergens’ zullen moeten staan. In je eigen data­center, in een eigen server, in een cloud van derden of verdeeld over verschil­lende nodes in een grid. Decen­tra­li­satie, edge-computing en grid-computing maakt dat data weer makke­lijker niet in verre clouds, maar dichtbij in bekende nodes wordt opge­slagen. Maar het blijven emmertjes, dichtbij of ver weg en op één plek of verspreid. Dat blijft de basis van data mana­ge­ment: ‘ergens‘ staat uw data in emmertjes hopelijk veilig opgeslagen…

Pin It on Pinterest

Share This