Jak skonstruować bardzo duży stół?

Question

Jest to bardziej pytanie koncepcyjne. Inspiracją jest użycie bardzo dużej tabeli, w której nawet proste zapytanie zajmuje dużo czasu (odpowiednio zindeksowane). Zastanawiam się, czy istnieje lepsza struktura, a po prostu pozwalam, by stół rósł nieustannie.

Przez duże mam na myśli 10 000 000 rekordów, które rosną każdego dnia o około 10 000 dziennie. Stół taki mógłby trafić 10 000 000 dodatkowych rekordów co 2,7 roku. Powiedzmy, że nowsze rekordy są dostępne najczęściej, ale starsze muszą pozostać dostępne. Mam dwie koncepcje koncepcyjne, aby przyspieszyć.

1) Zachowaj tabelę wzorcową, która przechowuje wszystkie dane, indeksowane według daty w odwrotnej kolejności. Utwórz oddzielny widok dla każdego roku, który zawiera tylko dane dla tego roku. Następnie, podczas odpytywania i powiedzmy, że zapytanie ma pobrać tylko kilka rekordów z trzyletniego okresu, mógłbym użyć połączenia, aby połączyć trzy widoki i wybrać z nich.

2) Inną opcją byłoby utworzenie oddzielnej tabeli na każdy rok. Następnie, ponownie używając unii, aby połączyć je podczas odpytywania.

Czy ktoś jeszcze ma inne pomysły lub koncepcje? Wiem, że to jest problem, z którym Facebook się zmierzył, więc jak myślisz, jak sobie z tym poradzili? Wątpię, że mają jedną tabelę (status_updates), która zawiera 100 000 000 000 rekordów.

Answer 1

głównymi dostawcami RDBMS wszyscy mają podobne koncepcje w zakresie partycjonowanych tabelach i podzielono poglądów (jak również kombinacje dwóch)

Jest jedna natychmiastowe korzyści, że dane jest teraz podzielona na wielu stołach koncepcyjnych , więc każde zapytanie, które zawiera klucz partycji w zapytaniu, może automatycznie zignorować każdą partycję, której nie będzie klucz.

Z perspektywy zarządzania RDBMS, podzielenie danych na oddzielne partycje pozwala na wykonanie operacji na partycji poziom, tworzenie kopii zapasowych/przywracanie/indeksowanie itp. Pomaga to zredukować czasy przestojów, a także pozwala na znacznie szybszą archiwizację, po prostu usuwając całość partycja na raz.

Istnieją również nierelacyjne mechanizmy magazynowania, takie jak nosql, map reduction etc, ale ostatecznie sposób ich użycia, załadowania i zarchiwizowania danych stają się czynnikiem decydującym o wyborze struktury.

10 milionów wierszy nie jest tak dużych w skali dużych systemów, systemy partycjonowane mogą i będą zajmować miliardy wierszy.

Answer 2

Często najlepszym planem jest posiadanie jednej tabeli, a następnie korzystanie z partycjonowania bazy danych.

Można również archiwizować dane i tworzyć widoki dla zarchiwizowanych i połączonych danych i przechowywać tylko aktywne dane w tabeli, do których odwołuje się większość funkcji. Będziesz musiał jednak mieć dobrą strategię archiwizowania (która jest zautomatyzowana) lub możesz stracić dane lub nie sprawić, by rzeczy były sprawnie przenoszone. Zazwyczaj jest to trudniejsze do utrzymania.

Answer 3

Twój drugi pomysł wygląda na partycjonowanie.

Nie wiem, jak to działa, ale nie ma wsparcia dla partycji w MySQL - patrz w swojej instrukcji: Chapter 17. Partitioning

Answer 4

Co mówisz jest poziomy podział lub sharding.

Answer 5

Dla tych tabel istnieje dobre podejście do skalowalności. Unia ma właściwą drogę, ale jest lepszy sposób.

Jeśli silnik bazy danych obsługuje "partycjonowanie semantyczne", można podzielić jedną tabelę na partycje. Każda partycja będzie obejmować pewien podzakres (powiedzmy 1 partycję na rok). Nie wpłynie to na nic w składni SQL, z wyjątkiem DDL. Silnik będzie w przejrzysty sposób uruchamiał ukrytą logikę połączeniową i partycjonowane skany indeksu z całym sprzętem równoległym, jaki posiada (procesor, I/O, pamięć masowa).

Na przykład Sybase zezwala na maksymalnie 255 partycji, ponieważ jest to limit unii. Ale nigdy nie będziesz potrzebować słowa kluczowego "union" w zapytaniach.