"Nyní – jak byste popsaný problém řešili?"
S jednoduchými plochými soubory.
Zde je důvod
Máte 2 000 000 subjektů. Oddíl na základě čísla entity:
level1= entity/10000
level2= (entity/100)%100
level3= entity%100
Každý soubor dat je level1/level2/level3/batch_of_data
Poté můžete přečíst všechny soubory v dané části adresáře a vrátit vzorky ke zpracování.
Pokud někdo chce relační databázi, načte soubory pro dané entity_id do databáze pro jeho použití.
Upravit V počtech dnů.
-
date_id
/entity_id
pravidlo jedinečnosti není něco, co se musí zvládnout. Je to (a) triviálně uvalené na názvy souborů a (b) irelevantní pro dotazování. -
date_id
"převrácení" nic neznamená -- není zde žádný dotaz, takže není potřeba nic přejmenovávat.date_id
by měl jednoduše růst bez omezení od data epochy. Pokud chcete vymazat stará data, smažte staré soubory.
Protože žádný dotaz nespoléhá na date_id
, nikdy se s tím nemusí nic dělat. Může to být název souboru všeho, na čem záleží.
Chcete-li zahrnout date_id
ve výsledkové sadě jej zapište do souboru s dalšími čtyřmi atributy, které jsou v každém řádku souboru.
Upravit na otevřít/zavřít
Pro zápis musíte nechat soubor(y) otevřené. Provádíte pravidelné vyplachování (nebo zavřete/znovu otevřete), abyste se ujistili, že věci skutečně půjdou na disk.
Máte dvě možnosti pro architekturu vašeho spisovatele.
-
Mít jeden proces „zapisovatele“, který konsoliduje data z různých zdrojů. To je užitečné, pokud jsou dotazy relativně časté. Platíte za sloučení dat v době zápisu.
-
Mějte několik souborů otevřených současně pro zápis. Při dotazování sloučte tyto soubory do jednoho výsledku. To je užitečné, protože dotazy jsou relativně vzácné. Platíte za sloučení dat v době dotazu.