Fragmentowanie bazy danych a partycjonowanie

Ostatnio czytałem o skalowalnych architekturach. W tym kontekście dwa słowa, które ciągle pojawiają się w odniesieniu do baz danych, to sharding i partycjonowanie . Sprawdziłem opisy, ale nadal byłem zdezorientowany.

Czy eksperci ze stackoverflow mogą mi pomóc we właściwym opanowaniu podstaw?

• Jaka jest różnica między fragmentowaniem a partycjonowaniem ?
• Czy to prawda, że „wszystkie podzielone na fragmenty bazy danych są zasadniczo podzielone na partycje (w różnych węzłach), ale wszystkie podzielone na partycje bazy danych niekoniecznie są podzielone na fragmenty” ?

Partycjonowanie jest bardziej ogólnym terminem określającym podział danych między tabelami lub bazami danych. Fragmentowanie to jeden konkretny typ partycjonowania, część tak zwanego partycjonowania poziomego.

Tutaj replikujesz schemat na (zazwyczaj) wielu instancjach lub serwerach, używając jakiejś logiki lub identyfikatora, aby wiedzieć, która instancja lub serwer mają szukać danych. Identyfikator tego rodzaju jest często nazywany „kluczem odłamkowym”.

Powszechną logiką bez klucza jest używanie alfabetu do dzielenia danych. AD to instancja 1, EG to instancja 2 itd. Dane klienta są do tego odpowiednie, ale ich rozmiar będzie nieco fałszywie reprezentowany w instancjach, jeśli partycjonowanie nie uwzględni, że niektóre litery są bardziej powszechne niż inne.

Inną powszechną techniką jest użycie systemu synchronizacji kluczy lub logiki, która zapewnia unikalne klucze we wszystkich instancjach.

Dobrze znanym przykładem, który możesz zbadać, jest sposób, w jaki Instagram rozwiązał ich partycjonowanie na początku (patrz link poniżej). Zaczęli od partycjonowania na bardzo niewielu serwerach, używając Postgres do dzielenia danych od samego początku. Wydaje mi się, że było to kilka tysięcy odłamków logicznych na tych kilku fizycznych. Przeczytaj ich niesamowity artykuł z 2012 roku: Inżynieria Instagrama - fragmenty i identyfikatory

Zobacz także tutaj: http://www.quora.com/Whats-the-difference-between-sharding-and-partition

Wygląda na to, że to odpowiada na oba Twoje pytania:

Partycjonowanie poziome dzieli jedną lub więcej tabel według wiersza, zwykle w ramach jednej instancji schematu i serwera bazy danych. Może to być korzystne dzięki zmniejszeniu rozmiaru indeksu (a tym samym wysiłku wyszukiwania) pod warunkiem, że istnieje jakiś oczywisty, niezawodny, niejawny sposób identyfikacji, w której tabeli zostanie znaleziony określony wiersz, bez konieczności uprzedniego przeszukiwania indeksu, np. Klasycznego przykład tabel „CustomersEast” i „CustomersWest”, gdzie ich kod pocztowy wskazuje już, gdzie zostaną znalezione.

Sharding wykracza poza to: dzieli problematyczne tabele w ten sam sposób, ale robi to na potencjalnie wiele wystąpień schematu. Oczywistą zaletą byłoby to, że obciążenie wyszukiwania dla dużej tabeli partycjonowanej można teraz podzielić na wiele serwerów (logicznych lub fizycznych), a nie tylko na wiele indeksów na tym samym serwerze logicznym.

Źródło: Wiki-Shard .

Sharding to proces przechowywania rekordów danych na wielu komputerach i jest podejściem MongoDB do sprostania wymaganiom wzrostu ilości danych. Wraz ze wzrostem rozmiaru danych pojedynczy komputer może nie być wystarczający do przechowywania danych ani do zapewnienia akceptowalnej przepustowości odczytu i zapisu. Sharding rozwiązuje problem ze skalowaniem poziomym. Dzięki fragmentowaniu dodajesz więcej maszyn w celu obsługi wzrostu danych oraz wymagań operacji odczytu i zapisu.

Źródło: MongoDB .

Zagłębiłem się w to również i chociaż jestem zdecydowanie punktem odniesienia w tej sprawie, jest kilka kluczowych faktów, które zebrałem i którymi chciałbym się podzielić:

Przegroda jest podział logiczny danych lub jego elementów składowych na osobne niezależne części. Partycjonowanie bazy danych jest zwykle wykonywane ze względu na łatwość zarządzania, wydajność lub dostępność, na przykład w celu równoważenia obciążenia.

https://en.wikipedia.org/wiki/Partition_(database)

Sharding to rodzaj partycjonowania, taki jak partycjonowanie poziome (HP)

Istnieje również pionowe partycjonowanie (VP), w którym dzielisz tabelę na mniejsze, odrębne części. Normalizacja obejmuje również podział kolumn między tabelami, ale partycjonowanie pionowe wykracza poza to i dzieli kolumny nawet wtedy, gdy są już znormalizowane.

https://en.wikipedia.org/wiki/Shard_(database_architecture)

Bardzo podoba mi się odpowiedź Tony'ego Baco na Quora, gdzie zmusza cię do myślenia w kategoriach schematu (a nie kolumn i wierszy). On uważa, iż...

„ Partycjonowanie poziome ” lub fragmentacja to replikacja [kopiowanie] schematu, a następnie dzielenie danych na podstawie klucza fragmentu.

„ Partycjonowanie pionowe ” polega na podzieleniu schematu (a dane są przesyłane do przejazdu).

https://www.quora.com/Whats-the-difference-between-sharding-DB-tables-and-partitioning-them

Poradnik Oracle dotyczący partycjonowania baz danych zawiera kilka fajnych liczb. Skopiowałem kilka fragmentów artykułu.

https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm

Kiedy dzielić tabelę

Oto kilka sugestii, kiedy podzielić tabelę:

• Tabele większe niż 2 GB należy zawsze traktować jako kandydujące do partycjonowania.
• Tabele zawierające dane historyczne, w których nowe dane są dodawane do najnowszej partycji. Typowym przykładem jest tabela historyczna, w której można aktualizować tylko dane z bieżącego miesiąca, a pozostałe 11 miesięcy tylko do odczytu.
• Gdy zawartość tabeli musi być dystrybuowana na różne typy urządzeń magazynujących.

Przycinanie partycji

Przycinanie partycji jest najprostszym i jednocześnie najważniejszym sposobem na poprawę wydajności przy użyciu partycjonowania. Czyszczenie partycji może często poprawić wydajność zapytań o kilka rzędów wielkości. Załóżmy na przykład, że aplikacja zawiera tabelę zamówień zawierającą historyczne rekordy zamówień i że tabela ta została podzielona według tygodni. Zapytanie żądające zamówień na jeden tydzień miałoby dostęp tylko do jednej partycji tabeli Zamówienia. Gdyby tabela Zamówienia zawierała dane historyczne z 2 lat, to zapytanie uzyskałoby dostęp do jednej partycji zamiast 104 partycji. To zapytanie mogłoby potencjalnie zostać wykonane 100 razy szybciej po prostu z powodu czyszczenia partycji.

Strategie partycjonowania

• Zasięg
• Haszysz
• Lista

Możesz czytać ich tekst i wizualizować ich obrazy, które wyjaśniają wszystko całkiem dobrze.

I wreszcie, ważne jest, aby zrozumieć, że bazy danych są niezwykle zasobochłonne:

• procesor
• Dysk
• I / O
• Pamięć

Wiele DBA będzie partycjonować na tej samej maszynie, gdzie partycje będą współużytkować wszystkie zasoby, ale zapewnią poprawę dysku i operacji we / wy poprzez podzielenie danych i / lub indeksu.

Podczas gdy inne strategie będą wykorzystywać architekturę „nic wspólnego”, w której fragmenty będą znajdować się w oddzielnych i odrębnych jednostkach obliczeniowych (węzłach), mając 100% procesora, dysku, we / wy i pamięci. Zapewnienie własnego zestawu zalet i złożoności.

https://en.wikipedia.org/wiki/Shared_nothing_architecture

Rozważ tabelę w bazie danych z 1 milionem wierszy i 100 kolumnami W przypadku partycjonowania możesz podzielić tabelę na 2 lub więcej tabel o właściwościach takich jak:

1. 0,4 miliona wierszy (tabela1), 0,6 miliona wierszy (tabela2)

2. 1 milion wierszy i 60 kolumn (tabela 1) oraz 1 milion wierszy i 40 kolumn (tabela 2)

   Takich przypadków może być wiele

To jest ogólne partycjonowanie

Ale Sharding odnosi się tylko do pierwszego przypadku, w którym dzielimy dane na podstawie wierszy. Jeśli dzielimy tabelę na wiele tabel, musimy zachować wiele podobnych kopii schematów, ponieważ teraz mamy wiele tabel.

Fragmentowanie w szczególnym przypadku partycjonowania poziomego , gdy partycje obejmują wiele wystąpień bazy danych. Jeśli baza danych jest podzielona na fragmenty, oznacza to, że jest podzielona na partycje z definicji.

Mówiąc o partycjonowaniu, nie używaj replikacji terminów ani replikacji. Replikacja to inna koncepcja i poza zakresem tej strony. Kiedy mówimy o partycjonowaniu, lepsze słowo jest dzielone, a kiedy mówimy o dzieleniu na fragmenty, to lepsze słowo jest dystrybuowane. W partycji (zwykle i w powszechnym rozumieniu nie zawsze) wiersze dużej tabeli zestawu danych są podzielone na dwie lub więcej rozłącznych (nie dzielących żadnego wiersza) grup. Możesz nazwać każdą grupę partycją. Te grupy lub wszystkie partycje pozostają pod kontrolą jednej instancji RDMB i to wszystko jest logiczne. Podstawą każdej grupy może być hash, zakres itp. Jeśli masz dane z dziesięciu lat w tabeli, możesz przechowywać dane z każdego roku w oddzielnej partycji i można to osiągnąć, ustawiając granice partycji na podstawie niezerowa kolumna CREATE_DATE. Po zapytaniu o bazę danych, jeśli określisz datę utworzenia między 01-01-1999 a 31-12-2000, trafią tylko dwie partycje i będą one sekwencyjne. Zrobiłem podobnie na DB dla miliarda + rekordów, a czas sql doszedł do 50 milis z 30 sekund przy użyciu indeksów itp. Sharding polega na tym, że hostujesz każdą partycję na innym węźle / maszynie. Teraz wyszukiwanie wewnątrz partycji / fragmentów może odbywać się równolegle.

Partycja pozioma po przeniesieniu do innej instancji bazy danych * staje się fragmentem bazy danych .

Instancja bazy danych może znajdować się na tym samym komputerze lub na innym komputerze.