Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Klaster ma pięć typów tabel. Każdy typ przechowuje dane inaczej w węzłach i służy do różnych celów.
Rozproszone tabele
Pierwszy typ i najbardziej typowy to tabele rozproszone. Dla instrukcji SQL wyglądają jak zwykłe tabele, ale są podzielone poziomo na węzłach roboczych. Taki podział oznacza, że wiersze tabel są przechowywane na różnych węzłach w tabelach fragmentowych zwanych shardami.
Klastry elastyczne uruchamiają nie tylko instrukcje SQL, ale także DDL (Data Definition Language) w klastrze. Gdy zmienisz schemat tabeli rozproszonej, zmiana zostanie propagowana kaskadowo, aktualizując wszystkie odłamki tabeli na wszystkich węzłach roboczych. Należy wykonać takie operacje za pośrednictwem połączenia przez port 5432.
Kolumna rozproszona
Klastry elastyczne używają algorytmicznego fragmentowania w celu przypisania wierszy do fragmentów. Przypisanie jest określane w sposób deterministyczny na podstawie wartości kolumny tabeli nazywanej kolumną dystrybucji. Administrator klastra musi wyznaczyć tę kolumnę podczas dystrybucji tabeli. Wybór właściwy jest ważny dla wydajności i funkcjonalności.
Tabele referencyjne
Tabela referencyjna jest typem rozproszonej tabeli, której cała zawartość znajduje się w jednym fragmentie. Klaster replikuje odłamek na każdym węźle roboczym. Zapytania dotyczące dowolnego procesu roboczego mogą uzyskiwać dostęp do informacji referencyjnych lokalnie bez konieczności żądania wierszy z innego węzła przez sieć. Tabele referencyjne nie mają kolumny rozkładu, ponieważ nie ma potrzeby rozróżniania oddzielnych fragmentów danych w każdym wierszu.
Tabele referencyjne są zwykle małe i przechowują dane istotne dla zapytań uruchomionych w dowolnym węźle roboczym. Przykładem są wyliczone wartości, takie jak stany zamówienia lub kategorie produktów.
Tabele lokalne
W przypadku korzystania z klastra elastycznego każdy węzeł jest zwykłą bazą danych PostgreSQL. Możesz tworzyć na nich zwykłe tabele i nie fragmentować ich.
Dobrym kandydatem na tabele lokalne są małe tabele administracyjne, które nie uczestniczą w zapytaniach typu JOIN. Przykładem jest users tabela logowania i uwierzytelniania aplikacji. Ten typ tabeli jest przydatny tylko wtedy, gdy nie planujesz równoważenia obciążenia połączenia między klastrem elastycznym przy użyciu portu 7432 lub 8432.
Lokalne tabele zarządzane
Klastry elastyczne mogą automatycznie dodawać tabele lokalne do metadanych, jeśli istnieje odwołanie klucza obcego między tabelą lokalną a tabelą referencyjną. Ponadto można ręcznie tworzyć tabele zarządzane lokalnie, wykonując citus_add_local_table_to_metadata funkcję w zwykłych tabelach lokalnych. Tabele obecne w metadanych są traktowane jako zarządzane tabele i mogą być odpytywane z dowolnego węzła. Citus wie, że należy skierować zapytanie do węzła, aby pobrać dane z lokalnej zarządzanej tabeli. Takie tabele są wyświetlane jako lokalne w citus_tables widoku.
Tabele schematów
W przypadku używania fragmentowania opartego na schemacie system automatycznie kojarzy rozproszone schematy z poszczególnymi grupami kolokacji. Gdy tworzysz tabele w tych schematach, system automatycznie przekształca je w kolokowane tabele rozproszone bez klucza shardowania. Te tabele są tabelami schematów i są wyświetlane jako schemat w citus_tables widoku.