Stel je voor dat je een enorme digitale bibliotheek in de lucht beheert, een plek waar miljoenen foto's, liedjes en video's worden opgeslagen zodat computers ervan kunnen leren. Dit is de wereld van "cloud storage" (cloudopslag), een gigantisch magazijn waar data leeft op servers ver weg van je computer. Maar hier komt het lastige deel bij: alleen omdat de boeken op de planken staan, betekent niet dat je ze snel kunt pakken. Hoe die boeken op de plank zijn gerangschikt—of ze nu verspreid liggen als losse exemplaren, gestapeld zijn in nette dozen, of aan elkaar geplakt zijn in één gigantische dikke tome—verandert alles. Als de ordening rommelig is, is je computer de hele tijd heen en weer aan het rennen naar de bibliothecaris, wat tijd en geld verspilt bij elke rit. Dit is het probleem van "storage layout" (opslagindeling): de fysieke organisatie van data die bepaalt hoe snel en goedkoop een computer de informatie kan ophalen die hij nodig heeft om zijn werk te doen.

In de wereld van machine learning zijn computers als hongerige studenten die proberen te studeren voor een groot examen. Ze moeten miljoens afbeeldingen "opeten" om te leren hoe een kat of een auto eruitziet. Maar als het voedsel (de data) op een manier wordt geserveerd die moeilijk door te slikken is, wordt de student moe, duurt het examen eeuwig en schiet de rekening van de kantine (de cloudkosten) omhoog. Tot nu toe moesten experts raden wat de beste manier was om deze digitale boeken te stapelen, waarbij ze vertrouwden op regels die gemaakt waren voor verschillende soorten bibliotheken. Dit artikel, LayoutBench, stapt in om de discussie te beslechten. Het zet een gigantisch racecircuit op om drie verschillende manieren om multimedia-data in de cloud te organiseren te testen, waarbij exact wordt gemeten hoe snel ze zijn, hoeveel data ze verplaatsen en hoeveel ze kosten. Het doel is simpel: de opslagstrategie vinden waarmee de computer het snelst kan leren zonder een gat in de portemonneees te branden.

De Drie Uitdagers: De Verspreide, De Gestreepte en De Gelijmd

Om de race te begrijpen, moeten we eerst de drie hardlopers, of "layouts", ontmoeten die de onderzoekers aan de test hebben gelegd. Ze gebruikten een enorme dataset genaamd ImageNet, die meer dan een miljoen afbeeldingen bevat, en vroegen de computers om specifieke plaatjes te vinden op basis van regels (zoals "zoek alle foto's van zebra's" of "zoek foto's kleiner dan 500 KB").

1. Layout 1 (L1): De "Eén-voor-één" Verspreide Aanpak.
   Stel je een bibliotheek voor waar elk boek op zijn eigen kleine, aparte plank staat. Om 10 boeken te vinden, moet je naar de bibliotheek lopen, vragen om het eerste boek, wachten tot het je wordt overhandigd, teruglopen, om het tweede boek vragen, enzovoort. In de cloud betekent dit dat elke afbeelding zijn eigen individuele bestand is. De computer moet voor elke afbeelding een apart verzoek sturen. Het is simpel, maar het is traag omdat de computer veel tijd besteedt aan alleen maar zeggen "Hallo, ik zou graag dit bestand willen" en wachten op het "Hallo" terug.

2. Layout 2 (L2): De "Tar Archive" Doos-Aanpak.
   Stel je nu voor dat de bibliothecaris 100 boeken in een enkele kartonnen doos doet. Om een boek te krijgen, vraag je om de doos, en de bibliothecaris geeft je het hele pakket, maar je neemt alleen de specifieke pagina's die je nodig hebt. In de cloud betekent dit dat veel afbeeldingen worden verpakt in één groot bestand (een zogenaamd "tar"-archief). Wanneer de computer een afbeelding wil, vraat hij om een specifiek deel van het bestand. Omdat de computer de verbinding met de doos open kan houden, kan hij veel stukjes snel pakken zonder dat hij voor elk stukje opnieuw "Hallo" hoeft te zeggen.

3. Layout 3 (L3): De "Columnar" Gelijmde Aanpak.
   Dit is de meest complexe methode. Stel je voor dat alle boeken zijn gesmolten en zijn omgevormd tot een gigantisch, massief blok plastic waar elke pagina van elk boek in een specifieke volgorde aan elkaar is geplakt. Om een pagina te vinden, zoek je niet naar het boek; je vraxt een superintelligente robot (een database-engine) om door het gigantische blok heen te snijden. De robot weet precies waar de informatie zit en snijdt een stuk uit. Echter, omdat de pagina's aan elkaar geplakt zitten, moet de robot vaak een enorme brok plastic uit snijden om slechts een paar pagina's te krijgen, waarbij hij veel extra gewicht meesleept waar je niet om hebt gevraagd.

De Resultaten van de Race: Snelheid, Data en de Prijskaart

De onderzoekers hebben 11 verschillende soorten zoekopdrachten uitgevoerd op deze drie layouts met verschillende computerformaten (sommige snel, sommige met veel geheugen). Dit is wat ze vonden, en het is een beetje een verrassing.

De Snelheidswedstrijd
Voor zeer kleine verzoeken—zoals het vinden van slechts één of twee afbeeldingen—was de Doos-aanpak (L2) het snelst. Het versloeg de Verspreide aanpak (L1) omdat het geen tijd verspilde aan het zeggen van "Hallo" tegen de cloudserver voor elk afzonderlijk bestand. Het hergebruikte dezelfde verbinding, net als een vaste klant die niet steeds in de rij hoeft te staan.

Echter, naarmate de verzoeken groter werden, begon de Verspreide aanpak (L1) even te winnen, omdat de dozen te zwaar werden om efficiënt te beheren. Maar daarna, voor de enorme verzoeken—het vinden van honderdduizenden afbeeldingen—pakte de Gelijmde aanpak (L3) de kroon. De superintelligente robot kon ongelooflijk snel door het gigantische blok data snijden, maar alleen als de computer genoeg geheugen had om het stuk te bevatten.

De Data-Sleep
Hier komt de Gelijmde aanpak (L3) in de problemen. Omdat het enorme stukken van het datablok uitsnijdt, sleept het vaak veel meer informatie mee dan nodig is. Het paper vond dat bij kleine zoekopdrachten L3 ongeveer 57 MB aan data transporteerde om een enkele afbeelding te krijgen, terwijl de andere methoden minder dan 1 MB transporteerden. Zelfs bij grote zoekopdrachten verplaatste L3 3 tot -4 keer meer data dan de anderen. Het is alsof je een enkele punt pizza bestelt en de bezorger brengt de hele diepvriesverpakking, de saus, de kaas en de extra korst mee om alleen die ene punt te krijgen.

De Kosten van het Bedrijf
De meest schokkende bevinding ging over geld. In de cloud betaal je voor twee dingen: hoe lang je computer draait en hoeveel data je downloadt. De onderzoekers ontdekten dat de kosten voor gegevensoverdracht meer dan 98% van de totale rekening uitmaakten. De kosten voor het huren van de computer waren bijna verwaarloosbaar.

Omdat de Gelijmde aanpak (L3) zoveel extra data verplaatste, kostte het uiteindelijk 11,5 keer meer dan de Doos-aanpak (L2). Sterker nog, voor een standaard reeks queries kostte L2 ongeveer $0,80, terwijl L3 meer dan $9,20 kostte. De Verspreide aanpak (L1) was ook goedkoop, maar iets trager dan L2 bij grote taken.

Het Eindoordeel

Het paper concludeert dat er geen enkele "perfecte" layout is voor elke situatie, maar er is een duidelijke winnaar voor de meeste beeldgerelateerde taken.

• De Doos-aanpak (L2) is het ideale middenpad. Het biedt de beste balans tussen snelheid en kosten. Het is snel genoeg voor de meeste taken en houdt de gegevensoverdracht laag, wat je een fortuin bespaart.
• De Verspreide aanpak (L1) is oké voor kleine klusjes, maar wordt traag en inefficiënt naarmate je opschaalt.
• De Gelijmde aanpak (L3) is een tweesnijdend zwaard. Het is ongelooflijk snel voor enorme, complexe zoekopdrachten, maar het vereist veel computergeheugen en brengt een steile prijs met zich mee voor de extra data die het meesleept. Het is alleen de moeite waard als je zwaar, intensief werk doet waarbij snelheid belangrijker is dan de rekening.

De auteurs suggereren dat voor de meeste mensen die met afbeeldingen in de cloud werken, het vasthouden aan de Doos-aanpak (L2) de slimste zet is. Het is alsof je je lunch inpakt in een nette Tupperware-bak: het is makkelijk te pakken, verspilt geen ruimte en je betaalt niet voor de hele keuken alleen om een broodje te krijgen. De studie merkt ook op dat deze resultaten specifief zijn voor afbeeldingen; als je met enorme videobestanden werkt, kunnen de regels veranderen, maar voor nu wint de doos de race.