Effektiv lagring af 7.300.000.000 rækker

"Nu - hvordan ville du tackle det beskrevne problem?"

Med simple flade filer.

Her er hvorfor

Du har 2.000.000 enheder. Partition baseret på enhedsnummer:

level1= entity/10000
level2= (entity/100)%100
level3= entity%100

Hver fil med data er level1/level2/level3/batch_of_data

Du kan derefter læse alle filerne i en given del af mappen for at returnere prøver til behandling.

Hvis nogen ønsker en relationsdatabase, skal du indlæse filer for et givet entity_id i en database til deres brug.

Rediger På dagnumre.

1. date_id /entity_id entydighedsreglen er ikke noget der skal håndteres. Det er (a) trivielt pålagt filnavnene og (b) irrelevant for forespørgsler.

2. date_id "rollover" betyder ikke noget - der er ingen forespørgsel, så der er ingen grund til at omdøbe noget. date_id skal blot vokse ubundet fra epokedatoen. Hvis du vil slette gamle data, skal du slette de gamle filer.

Da ingen forespørgsel er afhængig af date_id , der skal aldrig gøres noget ved det. Det kan være filnavnet for alt, hvad det betyder noget.

For at inkludere date_id i resultatsættet skal du skrive det i filen med de andre fire attributter, der er i hver række af filen.

Rediger på åben/luk

For at skrive skal du lade filen/filerne være åbne. Du laver periodiske skylninger (eller lukker/genåbner) for at sikre, at ting virkelig kommer på disken.

Du har to valgmuligheder for din forfatters arkitektur.

1. Har en enkelt "skribent"-proces, der konsoliderer dataene fra de forskellige kilder. Dette er nyttigt, hvis forespørgsler er relativt hyppige. Du betaler for at flette dataene på skrivetidspunktet.

2. Hav flere filer åbne samtidigt til skrivning. Når du forespørger, flet disse filer til et enkelt resultat. Dette er nyttigt, fordi forespørgsler er relativt sjældne. Du betaler for at flette dataene på forespørgselstidspunktet.