Scaling out with Azure SQL Database (Skalowanie w poziomie za pomocą usługi Azure SQL Database)
Dotyczy:Azure SQL Database
Bazy danych w poziomie można łatwo skalować w poziomie w usłudze Azure SQL Database przy użyciu narzędzi Elastic Database . Te narzędzia i funkcje umożliwiają korzystanie z zasobów bazy danych usługi Azure SQL Database do tworzenia rozwiązań dla obciążeń transakcyjnych, a zwłaszcza aplikacji SaaS (Software as a Service). Funkcje elastycznej bazy danych składają się z następujących elementów:
- Biblioteka klienta elastycznej bazy danych: biblioteka klienta to funkcja umożliwiająca tworzenie i konserwowanie baz danych podzielonych na fragmenty. Zobacz Wprowadzenie do narzędzi elastycznej bazy danych.
- Narzędzie do dzielenia i scalania elastycznej bazy danych: przenosi dane między bazami danych podzielonych na fragmenty. To narzędzie jest przydatne do przenoszenia danych z wielodostępnej bazy danych do bazy danych z jedną dzierżawą (lub odwrotnie). Zobacz Samouczek narzędzia Split-Merge dla elastycznej bazy danych.
- Zadania elastycznej bazy danych (wersja zapoznawcza): użyj zadań do zarządzania dużą liczbą baz danych w usłudze Azure SQL Database. Łatwe wykonywanie operacji administracyjnych, takich jak zmiany schematu, zarządzanie poświadczeniami, odwołania do aktualizacji danych, zbieranie danych wydajności lub zbieranie danych telemetrycznych dzierżawy (klienta) przy użyciu zadań.
- Zapytanie elastycznej bazy danych (wersja zapoznawcza): umożliwia uruchamianie zapytania Transact-SQL obejmującego wiele baz danych. Umożliwia to połączenie z narzędziami raportowania, takimi jak Excel, Power BI, Tableau itp.
- Transakcje elastyczne: ta funkcja umożliwia uruchamianie transakcji obejmujących kilka baz danych. Transakcje elastycznej bazy danych są dostępne dla aplikacji .NET korzystających z platformy .NET ADO i integrują się ze znanym środowiskiem programowania przy użyciu klas System.Transaction.
Na poniższej ilustracji przedstawiono architekturę obejmującą funkcje elastycznej bazy danych w odniesieniu do kolekcji baz danych.
Na tej ilustracji kolory bazy danych reprezentują schematy. Bazy danych o tym samym kolorze współużytkuje ten sam schemat.
- Zestaw baz danych SQL jest hostowany na platformie Azure przy użyciu architektury fragmentowania.
- Biblioteka klienta elastic database służy do zarządzania zestawem fragmentów.
- Podzbiór baz danych jest umieszczany w elastycznej puli. (Zobacz Co to jest pula?).
- Zadanie elastycznej bazy danych uruchamia zaplanowane lub ad hoc skrypty T-SQL dla wszystkich baz danych.
- Narzędzie split-merge służy do przenoszenia danych z jednego fragmentu do innego.
- Zapytanie Elastic Database umożliwia napisanie zapytania obejmującego wszystkie bazy danych w zestawie fragmentów.
- Elastyczne transakcje umożliwiają uruchamianie transakcji obejmujących kilka baz danych.
Dlaczego warto używać narzędzi?
Osiągnięcie elastyczności i skalowania aplikacji w chmurze było proste w przypadku maszyn wirtualnych i magazynu obiektów blob — wystarczy dodać lub odjąć jednostki albo zwiększyć moc. Pozostaje jednak wyzwaniem dla stanowego przetwarzania danych w relacyjnych bazach danych. W tych scenariuszach pojawiły się wyzwania:
- Rosnąca i zmniejszająca się pojemność dla części relacyjnej bazy danych obciążenia.
- Zarządzanie hotspotami, które mogą mieć wpływ na określony podzestaw danych , na przykład zajęty klient końcowy (dzierżawa).
Tradycyjnie scenariusze takie jak te zostały rozwiązane przez inwestowanie w serwery o większej skali w celu obsługi aplikacji. Ta opcja jest jednak ograniczona w chmurze, w której wszystkie operacje przetwarzania odbywają się na wstępnie zdefiniowanym sprzęcie towarów. Zamiast tego dystrybucja danych i przetwarzania w wielu identycznych strukturalnych bazach danych (wzorzec skalowania w poziomie nazywany "fragmentowaniem") stanowi alternatywę dla tradycyjnych metod skalowania w górę zarówno pod względem kosztów, jak i elastyczności.
Skalowanie w poziomie i w pionie
Na poniższej ilustracji przedstawiono poziomy i pionowy wymiar skalowania, które są podstawowymi sposobami skalowania elastycznych baz danych.
Skalowanie w poziomie odnosi się do dodawania lub usuwania baz danych w celu dostosowania pojemności lub ogólnej wydajności, nazywanej również "skalowaniem w poziomie". Fragmentowanie, w którym dane są partycjonowane w kolekcji identycznych ustrukturyzowanych baz danych, jest typowym sposobem implementowania skalowania w poziomie.
Skalowanie w pionie odnosi się do zwiększania lub zmniejszania rozmiaru obliczeniowego pojedynczej bazy danych, nazywanej również "skalowaniem w górę".
Większość aplikacji baz danych w skali chmury używa kombinacji tych dwóch strategii. Na przykład aplikacja Oprogramowanie jako usługa może używać skalowania w poziomie do aprowizowania nowych klientów końcowych i skalowania w pionie, aby umożliwić każdej bazie danych klienta końcowego zwiększanie lub zmniejszanie zasobów zgodnie z potrzebami obciążenia.
- Skalowanie w poziomie jest zarządzane przy użyciu biblioteki klienta elastic Database.
- Skalowanie w pionie odbywa się przy użyciu poleceń cmdlet programu Azure PowerShell w celu zmiany warstwy usługi lub umieszczania baz danych w elastycznej puli.
Dzielenie na fragmenty
Fragmentowanie to technika dystrybucji dużej ilości danych o identycznej strukturze do wielu niezależnych baz danych. Jest to szczególnie popularne wśród deweloperów rozwiązań w chmurze tworzących oferty saas (Software as a Service) dla klientów końcowych lub firm. Ci klienci końcowi są często nazywani "dzierżawami". Fragmentowanie może być wymagane z dowolnej liczby powodów:
- Łączna ilość danych jest zbyt duża, aby zmieścić się w ograniczeniach pojedynczej bazy danych
- Przepływność transakcji ogólnego obciążenia przekracza możliwości pojedynczej bazy danych
- Dzierżawy mogą wymagać fizycznej izolacji od siebie, więc oddzielne bazy danych są potrzebne dla każdej dzierżawy
- Różne sekcje bazy danych mogą wymagać przechowywania w różnych lokalizacjach geograficznych ze względów zgodności, wydajności lub geopolitycznych.
W innych scenariuszach, takich jak pozyskiwanie danych z urządzeń rozproszonych, fragmentowanie może służyć do wypełniania zestawu baz danych, które są zorganizowane czasowo. Na przykład oddzielna baza danych może być dedykowana dla każdego dnia lub tygodnia. W takim przypadku klucz fragmentowania może być liczbą całkowitą reprezentującą datę (obecną we wszystkich wierszach tabel podzielonych na fragmenty), a zapytania dotyczące pobierania informacji dla zakresu dat muszą być kierowane przez aplikację do podzbioru baz danych obejmujących kwestionowany zakres.
Fragmentowanie działa najlepiej, gdy każda transakcja w aplikacji może być ograniczona do pojedynczej wartości klucza fragmentowania. Dzięki temu wszystkie transakcje są lokalne dla określonej bazy danych.
Wielodostępna i pojedyncza dzierżawa
Niektóre aplikacje używają najprostszego podejścia do tworzenia oddzielnej bazy danych dla każdej dzierżawy. Takie podejście jest wzorcem fragmentowania pojedynczej dzierżawy, który zapewnia izolację, możliwość tworzenia kopii zapasowych/przywracania i skalowanie zasobów na poziomie szczegółowości dzierżawy. W przypadku fragmentowania pojedynczej dzierżawy każda baza danych jest skojarzona z określoną wartością identyfikatora dzierżawy (lub wartością klucza klienta), ale ten klucz nie zawsze musi być obecny w samych danych. Jest to odpowiedzialność aplikacji za kierowanie każdego żądania do odpowiedniej bazy danych — a biblioteka kliencka może to uprościć.
Inne scenariusze pakują wiele dzierżaw razem w bazy danych, a nie izolują je do oddzielnych baz danych. Ten wzorzec jest typowym wzorcem fragmentowania wielu dzierżaw — i może to być spowodowane faktem, że aplikacja zarządza dużą liczbą małych dzierżaw. W przypadku fragmentowania wielodostępnego wiersze w tabelach bazy danych są przeznaczone do przenoszenia klucza identyfikującego identyfikator dzierżawy lub klucz fragmentowania. Ponownie warstwa aplikacji jest odpowiedzialna za kierowanie żądania dzierżawy do odpowiedniej bazy danych i może być obsługiwana przez elastyczną bibliotekę klienta bazy danych. Ponadto zabezpieczenia na poziomie wiersza mogą służyć do filtrowania wierszy, do których wierszy może uzyskać dostęp każda dzierżawa — aby uzyskać szczegółowe informacje, zobacz Wielodostępne aplikacje z elastycznymi narzędziami bazy danych i zabezpieczeniami na poziomie wiersza. Ponowne dystrybuowanie danych między bazami danych może być konieczne przy użyciu wzorca fragmentowania z wieloma dzierżawami i jest obsługiwane przez elastyczne narzędzie do dzielenia i scalania bazy danych. Aby dowiedzieć się więcej na temat wzorców projektowych dla aplikacji SaaS wykorzystujących pule elastyczne, zobacz artykuł Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database (Wzorce projektowe dla wielodostępnych aplikacji SaaS korzystających z usługi Azure SQL Database).
Przenoszenie danych z wielu do baz danych z jedną dzierżawą
Podczas tworzenia aplikacji SaaS typowe jest oferowanie potencjalnym klientom wersji próbnej oprogramowania. W takim przypadku opłacalne jest użycie wielodostępnej bazy danych dla danych. Jednak gdy perspektywa staje się klientem, baza danych z jedną dzierżawą jest lepsza, ponieważ zapewnia lepszą wydajność. Jeśli klient utworzył dane w okresie próbnym, użyj narzędzia split-merge, aby przenieść dane z wielu dzierżaw do nowej bazy danych z jedną dzierżawą.
Uwaga
Przywracanie z wielodostępnych baz danych do jednej dzierżawy nie jest możliwe.
Następne kroki
Aby zapoznać się z przykładową aplikacją, która demonstruje bibliotekę klienta, zobacz Wprowadzenie do narzędzi elastycznej bazy danych.
Aby przekonwertować istniejące bazy danych na użycie narzędzi, zobacz Migrowanie istniejących baz danych w celu skalowania w poziomie.
Aby wyświetlić szczegóły puli elastycznej, zobacz Zagadnienia dotyczące cen i wydajności dla elastycznej puli lub utwórz nową pulę z elastycznymi pulami.
Dodatkowe zasoby
Jeszcze nie korzystasz z narzędzi elastycznych baz danych? Zapoznaj się z naszym przewodnikiem Wprowadzenie. W przypadku pytań skontaktuj się z nami na stronie pytań i odpowiedzi dotyczących usługi SQL Database oraz w przypadku żądań funkcji, dodaj nowe pomysły lub zagłosuj na istniejące pomysły na forum opinii usługi SQL Database.
Opinia
https://aka.ms/ContentUserFeedback.
Już wkrótce: w ciągu 2024 r. będziemy stopniowo usuwać problemy z usługą GitHub jako mechanizm opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla