Lagrar effektivt 7 300 000 000 rader

"Nu - hur skulle du tackla det beskrivna problemet?"

Med enkla platta filer.

Här är varför

Du har 2 000 000 enheter. Partition baserad på enhetsnummer:

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

Varje fil med data är level1/level2/level3/batch_of_data

Du kan sedan läsa alla filer i en given del av katalogen för att returnera prover för bearbetning.

Om någon vill ha en relationsdatabas, ladda sedan filer för ett givet entity_id till en databas för deras användning.

Redigera På dagnummer.

1. date_id /entity_id unikhetsregeln är inte något som måste hanteras. Det är (a) trivialt påtvingat filnamnen och (b) irrelevant för sökning.

2. date_id "rollover" betyder ingenting -- det finns ingen fråga, så det finns ingen anledning att byta namn på någonting. date_id bör helt enkelt växa utan bunden från epokdatumet. Om du vill rensa gamla data, radera sedan de gamla filerna.

Eftersom ingen fråga bygger på date_id , ingenting behöver någonsin göras med det. Det kan vara filnamnet för allt det spelar roll.

För att inkludera date_id i resultatuppsättningen, skriv det i filen med de andra fyra attributen som finns på varje rad i filen.

Redigera på öppna/stäng

För att skriva måste du lämna filen/filerna öppna. Du gör periodiska tömningar (eller stänger/öppnar igen) för att försäkra dig om att saker verkligen kommer till disken.

Du har två val för din författares arkitektur.

1. Ha en enda "skrivar"-process som konsoliderar data från de olika källorna. Detta är användbart om frågor är relativt frekventa. Du betalar för att slå samman data vid skrivtid.

2. Ha flera filer öppna samtidigt för skrivning. När du frågar, slå samman dessa filer till ett enda resultat. Detta är användbart eftersom frågor är relativt sällsynta. Du betalar för att slå samman data vid frågetillfället.