Przetwarzanie transakcji online (OLTP)
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 tradycyjnym systemie zarządzania relacyjnymi bazami danych (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 hybrydowym przetwarzaniem transakcyjnym/analitycznym (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:
- Azure SQL Database
- Program SQL Server na maszynie wirtualnej platformy Azure
- Azure Database for MySQL
- Azure Database for PostgreSQL
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. |
Następne kroki
- Wprowadzenie do tabel zoptymalizowanych pod kątem pamięci
- Omówienie i scenariusze użycia OLTP w pamięci
- Optymalizowanie wydajności przy użyciu technologii w pamięci w usługach Azure SQL Database i Azure SQL Managed Instance
- Transakcje rozproszone w bazach danych w chmurze