Toto číslo není tak vysoké, jak si myslíte. V současné práci ukládáme data metrik pro webové stránky a celkový počet řádků, které máme, je mnohem vyšší. A v předchozí práci jsem pracoval s pg databází, která sbírala metriky z mobilní sítě a sbírala ~2 miliardy záznamů denně. Nebojte se tedy miliardových záznamů.
Určitě budete muset rozdělit data - pravděpodobně podle dne. S tímto množstvím dat můžete najít indexy zcela zbytečné. Závisí na rovinách, které uvidíte v EXPLAIN příkazový výstup. Například tato telco aplikace nepoužívala vůbec žádné indexy, protože by jen zpomalily celý motor.
Další otázkou je, jak rychlé odpovědi na dotazy budete potřebovat. A jaké kroky v podrobnostech (součty za hodiny/dny/týdny atd.) pro dotazy uživatelům povolíte. Možná budete dokonce muset udělat nějaké agregace pro podrobnosti, jako je týden, měsíc nebo čtvrtletí.
Doplnění:
Tyto ~2 miliardy záznamů za den v té telco aplikaci zabraly ~290 GB za den. A to znamenalo vkládání ~23 000 záznamů za sekundu pomocí hromadného vkládání s příkazem COPY. Každý objem byl několik tisíc záznamů. Nezpracovaná data byla rozdělena po minutách. Aby se předešlo čekání na disk, měl db 4 tabulkové prostory na 4 různých discích/polích a přes ně byly rozděleny oddíly. PostreSQL to vše bez problémů zvládl. Měli byste tedy myslet i na správnou HW konfiguraci.
Dobrý nápad je také přesunout adresář pg_xlog na samostatný disk nebo pole. Ne jen jiný souborový systém. Vše musí být samostatný HW. SSD mohu doporučit pouze v polích s řádnou kontrolou chyb. V poslední době jsme měli problémy s poškozenou databází na jednom SSD.