Ten rozmiar stawia Cię na terytorium VLDB (bardzo duże bazy danych). Na tej wysokości sytuacja wygląda zasadniczo inaczej.
Na Twoje pytanie nie można odpowiedzieć bez pełnych wymagań dotyczących zakresu odpowiedzialności Twojej aplikacji. Musisz zaprojektować pod kątem wydajności w odniesieniu do tego, co Twoja aplikacja powinna ZROBIĆ z danymi.
Moja rada jest taka, aby wziąć na pokład kogoś, kto ma wcześniejsze doświadczenie lub jesteś blisko 100% gwarancji, że poniesiesz porażkę.
Jeśli zdecydujesz się na Oracle, zapewnia on kilka rodzajów partycjonowania, z których będziesz chciał korzystać bardzo ostrożnie. Potrzebujesz partycji do celów administracyjnych (przenoszenie danych, budowanie indeksów, odzyskiwanie danych), a także do wydajności zapytań:
- Podział według zakresu, na przykład według zakresu dat
- Partycjonowanie listy, do przechowywania fragmentów danych, powiedzmy dla kraju ('SE', 'US', 'GB')
- Partycjonowanie haszujące. Przechowuje twoje dane na jednej z partycji w oparciu o funkcję skrótu
- Lub dowolna kombinacja powyższych
Potrzebujesz również kogoś, kto wie, jak zbudować i skonfigurować maszynę typu monster z naprawdę niesamowitą przepustowością I/O. Potrzebujesz więcej niż 1 GB/s, co nie jest zbyt tanie, gdy musisz również przechowywać 200 TB. W rzeczywistości, jeśli te 200 TB to tylko dane tabeli, będziesz musiał podwoić lub potroić tę liczbę, aby móc tworzyć indeksy, agregować tabele, kopie zapasowe itp.
Przepraszam, że nie mogłem dać Ci rozwiązania gotowego do użycia, ale chciałem się upewnić, że rozumiesz, że nie budujesz tylko bazy danych o ponadprzeciętnej wielkości. Jest ogromny!
