Този брой не е толкова голям, колкото си мислите. В текущата работа съхраняваме данни за показатели за уебсайтове и общият брой редове, които имаме, е много по-голям. А в предишната си работа работих с pg база данни, която събираше показатели от мобилната мрежа и събираше ~2 милиарда записа на ден. Така че не се страхувайте от броя на милиардите записи.
Определено ще трябва да разделите данните - най-вероятно по дни. С това количество данни можете да намерите индекси за доста безполезни. Зависи от самолетите, които ще видите в EXPLAIN команден изход. Например това приложение на телекомуникационната компания изобщо не използва никакви индекси, защото те просто биха забавили целия двигател.
Друг е въпросът колко бързи отговори на запитвания ще ви трябват. И кои стъпки на детайлност (суми за часове/дни/седмици и т.н.) за заявки ще разрешите за потребителите. Може дори да се наложи да направите някои обобщения за подробности като седмица, месец или тримесечие.
Допълнение:
Тези ~2 милиарда записи на ден в това приложение на телекомуникационните компании отнемаха ~290GB на ден. И това означаваше вмъквания на ~23000 записа в секунда с помощта на групови вмъквания с командата COPY. Всеки обем беше няколко хиляди записа. Суровите данни бяха разделени по минути. За да избегне изчакване на диска, db имаше 4 таблични пространства на 4 различни диска/масиви и дяловете бяха разпределени върху тях. PostreSQL успя да се справи с всичко без никакви проблеми. Така че трябва да помислите и за правилната HW конфигурация.
Добра идея също е да преместите директорията pg_xlog на отделен диск или масив. Няма просто различна файлова система. Всичко трябва да е отделно HW. Мога да препоръчам SSD само в масиви с правилна проверка за грешки. Напоследък имахме проблеми с повредена база данни на един SSD.
