Maksymalna pojemność tabeli w SQL Server 2008

11

Mam aplikację, która wstawia ponad 1 miliard wierszy rocznie do tabeli. Tabela ta zawiera jedne varchari bigintkolumny i jedną kolumnę blob również.

1 miliard wierszy składa się z danych historycznych, które są przechowywane w celu śledzenia. Zastanawiałem się więc, czy nie będzie ograniczenia pojemności tabeli, jeśli będę kontynuować tę strukturę zgodnie z tym artykułem MSDN na temat maksymalnego rozmiaru tabeli .

Czy rozmiar pliku danych wymieniony w tym łączu odnosi się do grupy plików danych tabeli?

LUKA
źródło
@marc_s dzięki za złapanie tego. dołącz do nas w The Heap, gdzie między innymi skupiamy na nich uwagę
JNK
Jaki jest maksymalny rozmiar każdego wiersza?
Nick Chammas

Odpowiedzi:

6

Nie ma praktycznego ograniczenia oprócz miejsca na dysku. Przeczytałem całkowicie tabelę, z którą się połączyłeś, i sprawdziłem ją.

Jeśli chcesz przekroczyć 16 TB, potrzebujesz wielu plików (prosta procedura).

usr
źródło
Myślę, że można to osiągnąć poprzez partycjonowanie tabeli i brak partycjonowania w celu użycia różnych grup plików, jeśli mam rację?
GAP,
1
To nawet nie jest konieczne. Po prostu dodaj nowy plik (do istniejącej grupy plików). SQL Server zacznie równomiernie wypełniać wszystkie pliki. Jeśli jeden plik nie może już rosnąć, po prostu powiększy drugi plik.
usr
2

Tabela w SQL Server 2008 może obsługiwać dużą liczbę rekordów i jak wspomniano w @usr, zależy to od miejsca na dysku, ale zaleca się, aby jeśli tabela ma wiele wierszy i stale się powiększała, należy używać tabeli partycjonowanej http://technet.microsoft. com / en-us / library / dd578580 (v = sql.100) .aspx

Gdy tabela bazy danych powiększa się do setek gigabajtów lub więcej, ładowanie nowych danych, usuwanie starych danych i utrzymywanie indeksów może być trudniejsze

więcej informacji na ten temat

http://msdn.microsoft.com/en-us/library/ms190787.aspx

i jak go wdrożyć http://blog.sqlauthority.com/2008/01/25/sql-server-2005-database-table-partitioning-tutorial-how-to-horizontal-partition-database-table/

AmmarR
źródło
Musisz jednak bardzo uważać na partycjonowanie. Należy dokładnie rozważyć funkcję i klucz, a także przypadek użycia. Pole logiczne do partycjonowania nigdy nie może być użyte w żadnym zapytaniu, co mogłoby obniżyć wydajność.
JNK,
To prawda, ale miliardy wierszy w jednej tabeli również wpłyną na wydajność, istnieje również opcja podziału danych w wielu tabelach, na przykład osobna tabela na każdy rok, a jeśli chcesz wyświetlić wszystkie dane, możesz użyć widoku, ale w przy każdym stole będzie co najmniej unsert i aktualizacja
AmmarR
wstawki na ogromnym stole niekoniecznie są wolne, zależy to od kluczy i indeksów. Robię miesięczne ładunki około 30 milionów wierszy w tabeli zawierającej 700 milionów istniejących wierszy i nie wykonujemy żadnego podziału na partycje. Próbowałem partycjonowania, ale spowodowało więcej problemów niż rozwiązane. To jest właściwie pytanie, czy chcesz to sprawdzić.
JNK
Zastanawiałem się nad przeniesieniem moich danych historii do osobnej tabeli i utworzeniem widoku unii, aby mógł być używany przez aplikację, gdy potrzebujesz historii zapytań + najnowszych danych, co stanowi około 25% zapytań, które mam w systemie. Czy będzie to bardziej wydajne niż posiadanie wielu plików danych lub dzielenie tabeli na partycje na podstawie kolumny oznaczającej dane jako najnowsze? Z operacji IO, które będą bardziej wydajne? ponieważ mam wątpliwości, że będzie to samo z perspektywy IO w obu rozwiązaniach.
GAP
każde przyjęte podejście ma swoje najlepsze praktyki, które mogą uczynić go dobrym lub złym, to znaczy, jeśli masz wiele tabel, twoje zapytanie będzie skomplikowane i będzie trudne do utrzymania, jeśli masz jedną tabelę i używasz partycjonowania tabel, istnieją względy dotyczące różnic, takie jak twoja wersja sql powinna być dla przedsiębiorstw itp., posiadanie wielu plików danych jest zalecane dla lepszych operacji we / wy, ale ma także swoje najlepsze praktyki, dla wydajności sql nie ma prostego sposobu ...
AmmarR
0

Być może działałby widok podzielony na partycje .

Z widoku Korzystanie z partycjonowania Artykuł MSDN :

Widoki podzielone na partycje umożliwiają podzielenie danych z dużej tabeli na mniejsze tabele elementów. Dane są dzielone między tabele członków na podstawie zakresów wartości danych w jednej z kolumn. Zakresy danych dla każdej tabeli elementów są zdefiniowane w ograniczeniu CHECK określonym w kolumnie partycjonowania. Następnie definiowany jest widok, który używa UNION ALL do łączenia selekcji wszystkich tabel elementów w jeden zestaw wyników. Gdy instrukcje SELECT odwołujące się do widoku określają warunek wyszukiwania w kolumnie partycji, optymalizator kwerendy używa definicji ograniczeń CHECK do określenia, która tabela elementów zawiera wiersze.

Nie jestem pewien, czym różni się od tabeli podzielonej na partycje, o której AmmarR podał informacje w swojej odpowiedzi.

Adam Porad
źródło