Projektowanie bazy danych - miliardy rekordów w jednym stole?

Question

Załóżmy, że tworzysz bazę danych do przechowywania wiadomości dla aplikacji do pokojów rozmów. Istnieje nieskończona liczba pokojów rozmów (są one tworzone w czasie rzeczywistym na żądanie), a wszystkie wiadomości muszą być przechowywane w bazie danych.

Czy błędem byłoby stworzenie jednego gigantycznego stołu do przechowywania wiadomości dla wszystkich pokojów rozmów, wiedząc, że w tym jednym stole może znajdować się miliard płyt?

Czy byłoby rozsądniej dynamicznie tworzyć tabele dla każdego utworzonego pokoju i przechowywać wiadomości tego pokoju tylko w tym stole?

Answer 1

Właściwe byłoby posiadanie jednego stołu. Gdy masz n tabel, które rosną według użycia aplikacji, opisujesz używanie samej bazy danych jako tabeli tabel, co nie jest sposobem w jaki RDBMS ma działać. Miliardy rekordów w jednej tabeli są banalne w nowoczesnej bazie danych. Na tym poziomie jedynymi problemami z wydajnością są dobre indeksy i sposób łączenia.

Answer 2

Podczas gdy można wykonać tabelę na czacie, każda baza danych ma ograniczenia w stosunku do liczby tabel, które mogą zostać utworzone, więc biorąc pod uwagę nieskończoną liczbę pokojów rozmów, musisz utworzyć nieskończoną liczbę tabel, która jest nie pójdzie do pracy.

Z drugiej strony można przechowywać miliardy wierszy danych, a przechowywanie nie jest normalnie problemem z uwagi na przestrzeń - odzyskanie informacji w rozsądnym okresie czasu wymaga jednak starannego planowania.

Wiadomości można podzielić na partycje według zakresu dat, a jeśli są zaplanowane, można użyć migracji LUN, aby przenieść starsze dane do wolniejszej pamięci, pozostawiając bardziej aktualne dane na temat szybszego przechowywania.

Answer 3

Miliardy rekordów?

Zakładając, że masz stale 1000 aktywnych użytkowników z 1 komunikatem na minutę, daje to 1,5 miliona wiadomości dziennie i około 500 milionów wiadomości rocznie.

Jeśli nadal chcesz przechowywać wiadomości na czacie przez kilka lat (po co?), Możesz je zarchiwizować w tabelach rocznych.

Zdecydowanie sprzeciwiłbym się dynamicznemu tworzeniu stołów w pokoju.

Answer 4

Ściśle mówiąc, Twój projekt ma rację, pojedynczy stół. pola o niskiej entropii {np. userid '- chcesz połączyć się z tabelami identyfikatorów, tj. po normalnych wzorcach normalizacji bazy danych)

możesz chcieć pomyśleć o partycjonowaniu na podstawie zakresu. np. "kopie" twojej tabeli z prefiksem roku. A może nawet po prostu "aktualna" i archiwalna tabela. Oba te podejścia oznaczają, że semantyczne zapytanie jest bardziej złożone (rozważmy, czy ktoś wykonał wyszukiwanie przez wiele lat), musiałoby zapytać wiele tabel.

Jednak pozytywnym aspektem jest to, że twoja "aktualna" tabela pozostanie na mniej więcej stałym rozmiarze, a archiwizacja będzie prostsza. - {można po prostu upuść tabeli 2005_Chat gdy chcesz zarchiwizować dane 2005}

-Ace