Ta liczba nie jest tak wysoka, jak myślisz. W obecnej pracy przechowujemy dane metryk dla stron internetowych, a łączna ilość posiadanych przez nas wierszy jest znacznie większa. A w poprzedniej pracy pracowałem z bazą danych pg, która zbierała dane z sieci komórkowej i zbierała ~2 miliardy rekordów dziennie. Więc nie bój się miliardów w liczbie rekordów.
Na pewno będziesz musiał podzielić dane - najprawdopodobniej w dzień. Przy takiej ilości danych indeksy mogą być zupełnie bezużyteczne. Zależy od samolotów, które zobaczysz w EXPLAIN wyjście polecenia. Na przykład ta aplikacja telekomunikacyjna w ogóle nie używała żadnych indeksów, ponieważ spowalniałyby one cały silnik.
Kolejnym pytaniem jest to, jak szybko będziesz potrzebować odpowiedzi na zapytania. I jakie kroki szczegółowości (sumy godzin/dni/tygodni itp.) dla zapytań zezwolisz użytkownikom. Może być nawet konieczne wykonanie pewnych agregacji dla szczegółów, takich jak tydzień, miesiąc lub kwartał.
Dodatek:
Te ~2 miliardy rekordów dziennie w tej aplikacji telekomunikacyjnej zajmowały ~290 GB dziennie. Oznaczało to wstawianie ~ 23000 rekordów na sekundę przy użyciu wstawek zbiorczych z poleceniem COPY. Każda masa to kilka tysięcy rekordów. Surowe dane podzielono na minuty. Aby uniknąć oczekiwania na dysku, db miał 4 przestrzenie tabel na 4 różnych dyskach/macierzach, a partycje były na nich rozmieszczone. PostreSQL poradził sobie z tym wszystkim bez żadnych problemów. Powinieneś więc pomyśleć również o właściwej konfiguracji sprzętu.
Dobrym pomysłem jest również przeniesienie katalogu pg_xlog na osobny dysk lub macierz. Nie tylko inny system plików. To wszystko musi być osobnym sprzętem. Dyski SSD mogę polecić tylko w macierzach z odpowiednią kontrolą błędów. Ostatnio mieliśmy problemy z uszkodzoną bazą danych na jednym dysku SSD.
