Dlaczego NIE partycjonować?

Kiedy NIE chcesz partycjonować bazy danych? (myśląc o partycjonowaniu MySQL )

W moim przypadku

Zacznę od kilku milionów rzędów, od tego powinno wyrosnąć.
Klucz podstawowy w polu znaku, który służy jako najczęstsze ograniczenie zapytania (i wyszukiwania są częste - co najmniej kilka na sekundę).
Klucz podstawowy zostałby zaszyfrowany, aby służył jako klucz partycji
Aktualizacje będą dokonywane w każdym wierszu, który jest pobierany w częstych zapytaniach wymienionych powyżej
Rzadziej wyszukiwane (względem kolumn daty lub innych) będą musiały trafić na wszystkie partycje

Nawet jeśli chodzi o ostatni punkt, czy wyszukiwanie nie przebiega równolegle, więc czy we wszystkich przypadkach jest to wygrana ? Jakie są wady partycjonowania? Dlaczego nie jest to coś, czego KAŻDY używa domyślnie, przynajmniej gdy patrzysz na ponad milion rekordów?

AKTUALIZACJA - wybrałem odpowiedź zgguy, ale zauważam, że dodałem własną odpowiedź z wynikami moich własnych badań, w tym link do naprawdę dobrej odpowiedzi na podobne pytanie, które było dla mnie bardzo przydatne.

mysql database-design partitioning chell
źródło

Odpowiedzi:

Nie ma srebrnego punktu na problemy z wydajnością, a partycjonowanie też nie jest jednym.

Każda partycja jest w zasadzie tabelą dla siebie. Dlatego zapytania, które są napisane w sposób umożliwiający bazie danych wyszukiwanie wierszy tylko w jednej partycji, stają się szybsze. Różnica może być ogromna w przypadku zapytań, które wymagałyby przeskanowania całej dużej tabeli, ale mogą ograniczyć się do skanowania tylko jednej partycji w podzielonej na partycje tabeli. W przypadku unikalnych wyszukiwań kluczowych różnica jest znacznie mniejsza.

Jednak zapytania wykorzystujące wyszukiwanie indeksów w sposób, który wymaga, aby baza danych odwiedziła wszystkie lub większość partycji tabeli (indeksu), będą działać znacznie wolniej.

Równoległe wykonywanie jest tematem samym w sobie. Jeśli uruchamiasz duże partie na noc i masz całą maszynę do wykonania tego pojedynczego zadania, to równoległość jest dobra. Jednak w systemie OLTP, w którym baza danych stale obsługuje zapytania od wielu współbieżnych użytkowników, nie chcesz, aby jeden użytkownik zajął wszystkie zasoby.

zgguy
źródło

Tak więc wyszukiwanie unikalnych / kluczowych kluczy w rzeczywistości nie zobaczy dużej (jeśli w ogóle?) Poprawy, ponieważ indeks PK jest szybszy? Czy jest tak ogólnie - czy są czasy, kiedy indeks PK jest wolniejszy? Co jeśli wyszukiwania są wypaczone do ostatnio dodanych PK? Czy partycja oparta na PK (myślę, że klucz klucza partycji musiałby być modułowy lub podobny, a NIE hash, prawda?), Która powoduje, że większość działań trafia tylko na jedną partycję?

chell,

Podstawowe / unikalne wyszukiwania kluczy w najlepszym wypadku dostrzegą niewielką poprawę wydajności. Z drugiej strony, jeśli Twoim celem jest zmniejszenie niezgodności instrukcji DML, powinieneś podzielić na partycje w taki sposób, aby DML był równo rozłożony na wszystkie partycje, zamiast koncentrować się na kilku z nich.

zgguy

przepraszam, że wracam 10 dni później, ale podnosisz kluczową kwestię - Podałeś dobry powód, aby widzieć, że partycjonowanie nie jest konieczne, jednak mój scenariusz obejmuje aktualizację każdego rekordu po jego odczytaniu (kilka na sekundę). Czy potrzeba tak wielu zapisów jest bardziej przekonującym argumentem dla partycji (z równomierną dystrybucją), aby obciążenie zapisu było rozłożone?

chell

Próbuję również zrozumieć Twój komentarz na temat zapytań, które trafiają na wiele partycji (które są wolniejsze). Jeśli zapytania dotyczą PK, który jest również używany (hashowany) jako klucz partycji, to czy DB nie od razu wie, do której partycji należy przejść na podstawie skrótu wyszukiwania? Dzięki za pomoc!

chell

Niestety, ostatnio nie mogłem odwiedzić wymiany stosów. Odpowiedź, do której linkujesz, jest świetna. Wierzę, że to odpowiada na oba pytania.

zgguy,

Odpowiedź tutaj jest dobrze napisana i upodabnia argumenty do odpowiedzi zgguy , że partycjonowanie nie kupuje wiele, jeśli w ogóle, korzyści dla scenariusza na jednym komputerze, w którym najczęstsze wyszukiwania są oparte na kluczu podstawowym lub czymś podobnym (ponieważ indeksowane wyszukiwania powinny być tak samo szybkie).

W rzeczywistości wspólnym wątkiem wydaje się być to, że główny powód podziału jest styczny i głównie związany z zarządzaniem: np. Segreguj dane według daty, jeśli musisz czyścić stare rekordy od czasu do czasu. Chociaż zauważono, że może to również poprawić wydajność wyszukiwania, jeśli dane są takie, że większość wszystkich zapytań trafi tylko do ostatnio dodanych rekordów.

Widziałem też wspomnienie, że MySQL nigdy nie robi niczego równolegle (fajnie byłoby zobaczyć jakieś linki lub więcej wyjaśnień na ten temat).

Nie widziałem, żeby ktokolwiek mówił o tym, czy pisanie aktywności dodaje innych względów.

chell
źródło

Nie sądzę, że pisma zmieniają twoją odpowiedź. Wspomniałeś o 2 z 4 przypadków użycia , które znalazłem. Nadal brak równoległości, nawet w wersji 8.0.

Rick James

Najpierw przychodzi mi na myśl przycinanie partycji ; jeśli nie jest to coś, czego mogą użyć twoje zapytania.

Czy będziesz potrzebować usunięcia dużej ilości danych ze stołu, ponieważ partycjonowanie pomogłoby ci. Choć stary, ale ten post od Piotra ma kilka punktów do rozważenia.

a kolejną rzeczą, o której można pomyśleć, jest łatwość użycia w przypadku prostych tabel ... partycjonowanie wymaga dodatkowej pracy i konserwacji.

mysql_user
źródło

Nowsze wersje mają składnię umożliwiającą jawne ograniczenie zapytania do partycji. Nie mogę wymyślić żadnego ważnego powodu, aby kiedykolwiek tego używać.

Rick James