dzielenie bazy danych serwera SQL - co zrobić ze wspólnymi danymi / danymi niepodzielonymi

Posiadamy bardzo dużą bazę danych na poziomie przedsiębiorstwa. W ramach naszego modelu biznesowego wszyscy użytkownicy sieci odwiedzają nasze serwery internetowe o tej samej porze każdego miesiąca, co z kolei hamuje działanie naszej skrzynki SQL. Ruch uliczny jest bardzo duży i rośnie, im większa jest firma. Optymalizacja proc sql została wykonana, a sprzęt został już skalowany do bardzo wysokiego poziomu.

Chcemy teraz oddzielić bazę danych, abyśmy mogli poradzić sobie z rozwojem firmy i przyszłymi obciążeniami.

Zdecydowaliśmy, które konkretne dane powinny zostać podzielone. Jest to podzbiór naszej bazy danych, który jest wysoce wykorzystywany.

Moje pytanie dotyczy jednak danych niedzielonych, które są wspólne / uniwersalne. Przykładem takich danych może być na przykład tabela zapasów lub ewentualnie tabela pracowników, tabela użytkowników itp.

Widzę dwie opcje do obsługi tych wspólnych / uniwersalnych danych:

1) projekt 1 - Umieść wspólne / uniwersalne dane w zewnętrznej bazie danych. Wszystkie zapisy pojawią się tutaj. Dane te będą następnie replikowane w dół do każdego niezależnego fragmentu, umożliwiając każdemu niezależnemu odczytanie tych danych i wewnętrzne połączenie z tymi danymi w procesach t-sql.

2) projekt 2 - Daj każdemu odłamkowi własną kopię wszystkich wspólnych / uniwersalnych danych. Pozwól każdemu niezależnemu zapisywać lokalnie w tych tabelach i użyj replikacji scalającej SQL do aktualizacji / synchronizacji tych danych we wszystkich innych niezależnych fragmentach.

obawy dotyczące projektu nr 1

1) Problemy transakcyjne: Jeśli masz sytuację, w której musisz zapisać lub zaktualizować dane w odłamku, a następnie zapisać / zaktualizować tabelę wspólną / uniwersalną na przykład w 1 przechowywanym proc, nie będziesz już w stanie tego łatwo zrobić. Dane istnieją teraz w osobnych instancjach SQL i bazach danych. Konieczne może być zaangażowanie MS DTS, aby sprawdzić, czy można zapakować te zapisy w transakcję, ponieważ znajdują się one w osobnej bazie danych. Wydajność jest w tym przypadku istotna i w przypadku procesorów, które zapisują dane podzielone i wspólne, mogą być zaangażowane możliwości ponownego zapisu.

2) utrata integralności referencyjnej. Nie można wykonać integralności referencyjnej między bazami danych.

3) Przekodowanie dużych obszarów systemu, aby wiedział, że może zapisywać wspólne dane w nowej uniwersalnej bazie danych, ale odczytywać wspólne dane z odłamków.

4). zwiększone przejazdy do bazy danych. Podobnie jak w punkcie 1 powyżej, gdy natrafisz na sytuację, w której musisz zaktualizować dane podzielone i wspólne dane, będziesz musiał wykonać wiele podróży w obie strony, aby to osiągnąć, ponieważ dane znajdują się teraz w osobnych bazach danych. Trochę opóźnień w sieci tutaj, ale nie martwię się o ten problem tak bardzo jak powyższe 3.

obawy dotyczące projektu nr 2

W projekcie nr 2 każdy fragment otrzymuje własną instancję wszystkich wspólnych / uniwersalnych danych. Oznacza to, że cały kod dołączający lub aktualizujący wspólne dane nadal działa / działa tak jak dzisiaj. Zespół programistów potrzebuje bardzo mało przepisywania / przepisywania. Jednak ten projekt całkowicie zależy od replikacji scalania, aby zachować synchronizację danych we wszystkich fragmentach. dbas są wysoko wykwalifikowani i są bardzo zaniepokojeni tym, że replikacja scalająca może nie być w stanie sobie z tym poradzić i jeśli scalenie replikacji zakończy się niepowodzeniem, odzyskanie po awarii nie jest duże i może mieć na nas bardzo negatywny wpływ.

Ciekawe, czy ktoś poszedł z opcją projektowania # 2. Jestem również ciekawy, czy przeoczam trzecią lub czwartą opcję projektowania, której nie widzę.

z góry dziękuję.

Twoje pytanie dotyczyło tego:

Moje pytanie dotyczy jednak danych niedzielonych, które są wspólne / uniwersalne. Przykładem takich danych może być na przykład tabela zapasów lub ewentualnie tabela pracowników, tabela użytkowników itp.

Gdy wykonujesz sharding i masz dane, które wszystkie fragmenty muszą zobaczyć, musisz sklasyfikować te dane za pomocą kilku atrybutów:

Czy to często się zmienia? W swoich przykładach wymieniono zapasy, pracownika i użytkownika. Zazwyczaj zapasy zmieniają się bardzo szybko, ale rekordy pracowników zmieniają się tylko okresowo (powiedzmy kilkaset aktualizacji dziennie).

Ile opóźnień może tolerować każdy odłamek?Mimo, że Zapasy mogą się ciągle zmieniać, zazwyczaj możesz tolerować duże opóźnienia (minuty lub nawet godziny) na takim stole. Jeśli sprzedajesz unikatowe przedmioty o bardzo ograniczonej ilości, których nigdy nie możesz uzupełnić (pomyśl oryginalne dzieła sztuki), to w ogóle nie dzielisz tych danych - przeszukujesz tylko oryginalną bazę danych. Jednak w większości sklepów internetowych nie sprzedajesz każdego przedmiotu każdego dnia, i tak i tak będziesz szybko uzupełniał zapasy, więc tak naprawdę nie potrzebujesz zapasów do milisekundy. W rzeczywistości w większości przypadków potrzebujesz tylko flagi In stock, która ma wartość 0 lub 1, a centralny proces aktualizuje tę flagę. W ten sposób nie musisz przesuwać każdego uderzenia w górę / w dół liczenia przedmiotów na każdy odłamek. Z drugiej strony dane pracownika lub użytkownika,

Czy dołączysz ze stolików odłamkowych do stolików nieskórowanych? Idealnie, odpowiedź tutaj jest przecząca - powinieneś zrobić dwa osobne zapytania, aby uzyskać dane, a następnie dołączyć je po stronie aplikacji. Z punktu widzenia aplikacji jest to o wiele trudniejsze, ale daje możliwość uzyskania najświeższych danych z każdego źródła.

Czy to oryginalne dane, czy skopiowane?Inny sposób myślenia o tym pytaniu: co i jak często należy wykonywać kopię zapasową? Zazwyczaj w środowisku dzielenia dużych woluminów kopie zapasowe powinny być tak szybkie i jak najmniejsze. (W końcu musisz chronić każdy węzeł i chcesz, aby wszystkie odłamki przełączyły się awaryjnie na DR w tym samym momencie - nie mają niektórych odłamków z nowszymi danymi niż inne.) Oznacza to, że dane podzielone i inne podzielone dane powinny znajdować się w całkowicie oddzielnych bazach danych - nawet jeśli znajdują się na tym samym serwerze. Mogę potrzebować ciągłych kopii zapasowych dzienników transakcji moich odłamanych (oryginalnych) danych, ale może nie być konieczne tworzenie kopii zapasowej danych nieciętych. Prawdopodobnie łatwiej mi po prostu odświeżyć tabelę Pracowników lub Użytkowników z jednego źródła prawdy, niż tworzyć kopie zapasowe na każdym fragmencie. Jeśli jednak wszystkie moje dane znajdują się w jednej bazie danych,

Teraz o twoich obawach:

„Problemy transakcyjne ... nie będziesz już w stanie tego łatwo zrobić”. Poprawny. W scenariuszach podzielonych wyrzuć pojęcie transakcji przez okno. Jest również gorzej - w przypadku danych podzielonych możesz mieć jeden fragment niezależny i online, a drugi tymczasowo wyłączony z powodu przełączenia awaryjnego lub ponownego uruchomienia instancji klastra. W dowolnym momencie musisz zaplanować awarię dowolnej części systemu.

„Niemożliwe jest zapewnienie integralności referencyjnej między bazami danych”. Poprawny. Kiedy dzielisz jedną tabelę na wiele serwerów, zakładasz spodnie dla dużych chłopców i mówisz serwerowi bazy danych, że przejmujesz się trudnymi zadaniami, takimi jak tworzenie kopii zapasowych w określonym momencie, relacje między tabelami i łączenie danych z wiele źródeł. Teraz jest na tobie i twoim kodzie.

„Przekodowywanie dużych obszarów systemu, aby wiedział, że może zapisywać wspólne dane w nowej uniwersalnej bazie danych, ale odczytywać wspólne dane z odłamków”. Tutaj również poprawne. Nie ma na to łatwego przycisku, ale po wbudowaniu go w aplikację możesz skalować się jak szalony. Twierdzę, że najłatwiejszym sposobem jest podzielenie połączeń aplikacji na odczyty .

„zwiększona ilość podróży do bazy danych”. - Tak, jeśli podzielisz dane na wiele serwerów, aplikacja będzie musiała bardziej docierać do sieci. Kluczem jest także wdrożenie buforowania, aby niektóre z tych danych mogły być przechowywane w tańszych, szybszych systemach bez blokady. Najszybsze zapytanie jest tym, którego nigdy nie wykonałeś.

Przedstawiłem też więcej zalet i wad podziału tu baz danych dla wielu dzierżawców , takich jak dostrajanie wydajności poszczególnych fragmentów, różne strategie tworzenia kopii zapasowych / odzyskiwania dla fragmentów i wyzwania związane ze wdrażaniem schematu.

Na wysokim poziomie typowym sposobem dzielenia (lub dzielenia w poziomie) danych jest dzielenie tabel transakcyjnych i replikowanie tabel na poziomie głównym. Podobnie jak większość rozwiązań technologicznych, to oczywiście rozwiązuje jeden zestaw problemów i stwarza zupełnie nowy zestaw problemów ... ale wszyscy jesteśmy już do tego przyzwyczajeni, prawda? ;-)

Chciałbym jednak zapytać, czy SQLServer jest najlepszym rozwiązaniem. Czy obciążenie bardziej przypomina OLTP, czy bardziej jak DW / BI?

Pozdrawiam, Dave Sisk

Możliwa trzecia opcja. Korzystając z relacyjnego dzielenia (zamiast dzielenia czarnych skrzynek), powinieneś być w stanie podzielić i rozpowszechniać całą bazę danych. Ponieważ bazuje na tradycyjnym relacyjnym modelu danych, baza danych wie, jakie dane są przechowywane na poszczególnych serwerach, a zatem gdzie je znaleźć, dzięki czemu wszystkie dane można uznać za „wspólne / uniwersalne”. Sprawdź dbShards jako możliwość, aby cały proces dzielenia był łatwiejszy.