Przetwarzanie transakcji online (OLTP)

  • Artykuł

Zarządzanie danymi transakcyjnych przy użyciu systemów komputerowych jest określane jako przetwarzanie transakcji online (OLTP). Systemy OLTP rejestrują interakcje biznesowe w miarę ich codziennego działania w organizacji i obsługują wykonywanie zapytań dotyczących tych danych w celu wnioskowania.

Dane transakcyjne

Dane transakcyjne to informacje, które śledzą interakcje związane z działaniami organizacji. Te interakcje są zazwyczaj transakcjami biznesowymi, takimi jak płatności otrzymane od klientów, płatności dokonane dla dostawców, produktów przechodzących przez zapasy, zamówienia podjęte lub dostarczone usługi. Zdarzenia transakcyjne, które reprezentują same transakcje, zwykle zawierają wymiar czasu, niektóre wartości liczbowe i odwołania do innych danych.

Transakcje zazwyczaj muszą być niepodzielne i spójne. Niepodzielność oznacza, że cała transakcja zawsze kończy się powodzeniem lub niepowodzeniem jako jedna jednostka pracy i nigdy nie pozostaje w stanie półukończonym. Jeśli nie można ukończyć transakcji, system bazy danych musi wycofać wszystkie kroki, które zostały już wykonane w ramach tej transakcji. W tradycyjnych systemach RDBMS to wycofywanie odbywa się automatycznie, jeśli nie można ukończyć transakcji. Spójność oznacza, że transakcje zawsze pozostawiają dane w prawidłowym stanie. (Są to bardzo nieformalne opisy niepodzielności i spójności. Istnieją bardziej formalne definicje tych właściwości, takie jak ACID.

Transakcyjne bazy danych mogą obsługiwać silną spójność transakcji przy użyciu różnych strategii blokowania, takich jak pesymistyczne blokowanie, w celu zapewnienia, że wszystkie dane są silnie spójne w kontekście przedsiębiorstwa, dla wszystkich użytkowników i procesów.

Najbardziej typową architekturą wdrażania korzystającą z danych transakcyjnych jest warstwa magazynu danych w architekturze 3-warstwowej. Architektura 3-warstwowa zwykle składa się z warstwy prezentacji, warstwy logiki biznesowej i warstwy magazynu danych. Powiązana architektura wdrażania to architektura N-warstwowa , która może mieć wiele warstw środkowych obsługujących logikę biznesową.

Typowe cechy danych transakcyjnych

Dane transakcyjne mają zwykle następujące cechy:

Wymaganie opis
Normalizacja Wysoce znormalizowane
Schemat Schemat zapisu, silnie wymuszony
Spójność Silna spójność, gwarancje ACID
Integralność Wysoka integralność
Używa transakcji Tak
Strategia blokowania Pesymistyczne lub optymistyczne
Można aktualizować Tak
Dołączanie Tak
Obciążenie Duże zapisy, umiarkowane odczyty
Indeksowanie Indeksy podstawowe i pomocnicze
Rozmiar dat Mały lub średni rozmiar
Model Relacyjne
Kształt danych Tabelaryczny
Elastyczność zapytań Wysoce elastyczna
Skaluj Małe (MB) do dużych (kilka mb/s)

Kiedy należy użyć tego rozwiązania

Wybierz usługę OLTP, gdy musisz efektywnie przetwarzać i przechowywać transakcje biznesowe i natychmiast udostępniać je aplikacjom klienckim w spójny sposób. Użyj tej architektury, gdy jakiekolwiek namacalne opóźnienie przetwarzania miałoby negatywny wpływ na bieżące działania firmy.

Systemy OLTP są przeznaczone do wydajnego przetwarzania i przechowywania transakcji, a także wykonywania zapytań dotyczących danych transakcyjnych. Celem efektywnego przetwarzania i przechowywania poszczególnych transakcji przez system OLTP jest częściowo normalizacja danych — czyli podzielenie danych na mniejsze fragmenty, które są mniej nadmiarowe. Obsługuje to wydajność, ponieważ umożliwia systemowi OLTP niezależne przetwarzanie dużej liczby transakcji i pozwala uniknąć dodatkowego przetwarzania wymaganego do zachowania integralności danych w obecności nadmiarowych danych.

Wyzwania

Implementowanie i używanie systemu OLTP może spowodować kilka wyzwań:

  • Systemy OLTP nie zawsze są dobre do obsługi agregacji w dużych ilościach danych, chociaż istnieją wyjątki, takie jak dobrze zaplanowane rozwiązanie oparte na programie SQL Server. Analiza danych, które opierają się na obliczeniach agregujących w milionach pojedynczych transakcji, są bardzo intensywnie obciążające zasoby w systemie OLTP. Mogą one być wykonywane wolno i mogą spowodować spowolnienie, blokując inne transakcje w bazie danych.
  • Podczas przeprowadzania analiz i raportowania danych, które są wysoce znormalizowane, zapytania są zwykle złożone, ponieważ większość zapytań wymaga anulowania normalizacji danych przy użyciu sprzężeń. Ponadto konwencje nazewnictwa obiektów bazy danych w systemach OLTP wydają się być zwięzłe i zwięzłe. Zwiększona normalizacja w połączeniu z bardziej szczegółowe konwencje nazewnictwa sprawia, że systemy OLTP są trudne dla użytkowników biznesowych do wykonywania zapytań bez pomocy administratora bazy danych lub dewelopera danych.
  • Przechowywanie historii transakcji na czas nieokreślony i przechowywanie zbyt dużej ilości danych w dowolnej tabeli może prowadzić do spowolnienia wydajności zapytań, w zależności od liczby przechowywanych transakcji. Typowym rozwiązaniem jest utrzymanie odpowiedniego przedziału czasu (na przykład bieżącego roku obrachunkowego) w systemie OLTP i odciążanie danych historycznych do innych systemów, takich jak magazyn danych lub magazyn danych.

OlTP na platformie Azure

Aplikacje, takie jak witryny internetowe hostowane w usłudze App Service Web Apps, interfejsy API REST uruchomione w usłudze App Service, aplikacje mobilne lub klasyczne komunikują się z systemem OLTP, zazwyczaj za pośrednictwem pośrednika interfejsu API REST.

W praktyce większość obciążeń nie jest czysto OLTP. Istnieje również składnik analityczny. Ponadto istnieje rosnące zapotrzebowanie na raportowanie w czasie rzeczywistym, takie jak uruchamianie raportów względem systemu operacyjnego. Jest to również nazywane HTAP (hybrydowym przetwarzaniem transakcyjnym i analitycznym). Aby uzyskać więcej informacji, zobacz Przetwarzanie analityczne online (OLAP) .

Na platformie Azure wszystkie następujące magazyny danych spełniają podstawowe wymagania dotyczące olTP i zarządzania danymi transakcji:

Kluczowe kryteria wyboru

Aby zawęzić opcje, zacznij od udzielenia odpowiedzi na następujące pytania:

  • Czy chcesz zarządzać usługą zarządzaną zamiast zarządzać własnymi serwerami?

  • Czy Twoje rozwiązanie ma określone zależności dotyczące zgodności z programem Microsoft SQL Server, MySQL lub PostgreSQL? Aplikacja może ograniczyć magazyny danych, które można wybrać na podstawie sterowników, które obsługuje do komunikowania się z magazynem danych, lub założeń, które określa, która baza danych jest używana.

  • Czy wymagania dotyczące przepływności zapisu są szczególnie wysokie? Jeśli tak, wybierz opcję, która udostępnia tabele w pamięci.

  • Czy twoje rozwiązanie jest wielodostępne? Jeśli tak, rozważ opcje, które obsługują pule pojemności, gdzie wiele wystąpień bazy danych pobiera się z elastycznej puli zasobów, zamiast stałych zasobów na bazę danych. Może to pomóc w lepszej dystrybucji pojemności we wszystkich wystąpieniach bazy danych i sprawić, że rozwiązanie będzie bardziej opłacalne.

  • Czy dane muszą być czytelne z małym opóźnieniem w wielu regionach? Jeśli tak, wybierz opcję, która obsługuje repliki pomocnicze z możliwością odczytu.

  • Czy baza danych musi być wysoce dostępna w regionach grafiki geograficznej? Jeśli tak, wybierz opcję, która obsługuje replikację geograficzną. Rozważ również opcje, które obsługują automatyczne przechodzenie w tryb failover z repliki podstawowej do repliki pomocniczej.

  • Czy baza danych ma określone potrzeby w zakresie zabezpieczeń? Jeśli tak, sprawdź opcje, które zapewniają możliwości, takie jak zabezpieczenia na poziomie wiersza, maskowanie danych i przezroczyste szyfrowanie danych.

Macierz możliwości

W poniższych tabelach podsumowano kluczowe różnice w możliwościach.

Ogólne możliwości

Możliwość Azure SQL Database Program SQL Server na maszynie wirtualnej platformy Azure Azure Database for MySQL Azure Database for PostgreSQL
Jest usługą zarządzaną Tak Nie Tak Tak
Działa na platformie Nie dotyczy Windows, Linux, Docker Brak Brak
Możliwość programowania 1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (wersja 8)

[1] Nie obejmuje obsługi sterowników klienta, co umożliwia wielu językach programowania nawiązywanie połączenia z magazynem danych OLTP i korzystanie z niego.

Możliwości skalowalności

Możliwość Azure SQL Database Program SQL Server na maszynie wirtualnej platformy Azure Azure Database for MySQL Azure Database for PostgreSQL
Maksymalny rozmiar wystąpienia bazy danych 4 TB 256 TB 16 TB 16 TB
Obsługuje pule pojemności Tak Tak Nie. Nie.
Obsługuje skalowanie klastrów w poziomie Nie. Tak Nie. Nie.
Dynamiczna skalowalność (skalowanie w górę) Tak Nie Tak Tak

Możliwości obciążeń analitycznych

Możliwość Azure SQL Database Program SQL Server na maszynie wirtualnej platformy Azure Azure Database for MySQL Azure Database for PostgreSQL
Tabele danych czasowych Tak Tak Nie. Nie.
Tabele w pamięci (zoptymalizowane pod kątem pamięci) Tak Tak Nie. Nie.
Obsługa magazynu kolumn Tak Tak Nie. Nie.
Adaptacyjne przetwarzanie zapytań Tak Tak Nie. Nie.

Możliwości dostępności

Możliwość Azure SQL Database Program SQL Server na maszynie wirtualnej platformy Azure Azure Database for MySQL Azure Database for PostgreSQL
Czytelne sekundy Tak Tak Tak Tak
Replikacja geograficzna Tak Tak Tak Tak
Automatyczne przechodzenie w tryb failover do pomocniczego Tak Nie. Nie. Nie.
Przywracanie do punktu w czasie Tak Tak Tak Tak

Możliwości zabezpieczeń

Możliwość Azure SQL Database Program SQL Server na maszynie wirtualnej platformy Azure Azure Database for MySQL Azure Database for PostgreSQL
Zabezpieczenia na poziomie wiersza Tak Tak Tak Tak
Maskowanie danych Tak Tak Nie. Nie.
Transparent Data Encryption Tak Tak Tak Tak
Ograniczanie dostępu do określonych adresów IP Tak Tak Tak Tak
Ograniczanie dostępu w celu zezwolenia tylko na dostęp do sieci wirtualnej Tak Tak Tak Tak
Uwierzytelnianie Microsoft Entra Tak Nie Tak Tak
Uwierzytelnianie za pomocą usługi Active Directory Nie. Tak Nie. Nie.
Uwierzytelnianie wieloskładnikowe Tak Nie Tak Tak
Obsługuje funkcję Always Encrypted Tak Tak Nie. Nie.
Prywatny adres IP Nie. Tak Nie. Nie.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

Następne kroki