Nowoczesne bazy danych, czyli przetwarzanie in-memory

Transkrypt

1 Nowoczesne bazy danych, czyli przetwarzanie in-memory

2 1. Dlaczego przetwarzanie w pamięci? 2. Komercyjne bazy danych in-memory 3. Zwykła baza danych, a baza w pamięci różnice 4. Wymiarowanie sprzętu 5. Wysoka dostępność i skalowanie 6. Wydajność (porównanie przykładowych transakcji) 7. Na czym polega projekt migracji platformę SAP HANA? 8. Jak się przygotować do migracji 9. Optymalizacja systemu po migracji na SAP HANA

3 Dlaczego przetwarzanie w pamięci Pyt 1: Dlaczego przetwarzanie w pamięci? Odp: Wydajność Pyt 2: Dlaczego tak późno? Odp: Najpierw niewystarczająca, a następnie droga technologia

4 Komercyjne bazy danych in-memory Aplikacja Aplikacja SQL In-memory processing In-memory database In-memory cache SQL In-memory processing HDD/SSD HDD/SSD Sieć Oracle, DB2, Sybase, SQL Server Database engine SQL HDD/SSD Buffers

5 Komercyjne bazy danych in-memory 1. SAP HANA, 2. Oralce TimesTen In-Memory Database (Exalogic), Oracle In- Memory Database Cache 3. IBM soliddb, IBM soliddb Universal Cache

6 Zwykła baza danych a baza w pamięci DB Buffer Cache (niewielka część danych z bazy) DATA (cała baza w pamięci) Column Row Log Volume Data Volumes Log Volume Data Volumes Disk Storage Persistence Layer

7 Zwykła baza danych a baza w pamięci W tradycyjnej bazie danych odczyt lub zapis dużej ilości danych jest kosztowny ze względu na operacje dyskowe W bazie SAP HANA przetwarzanie dużej ilości danych odbywa się w pamięci w przypadku odczytów lub z wykorzystaniem logu (który opiera się na szybkich kartach dyskowych np. iodrive) w przypadku zapisu Tradycyjnie Przetwarzanie Warstwa aplikacji Warstwa bazy danych Przetwarzanie SAP HANA

8 Zwykła baza danych a baza w pamięci Konwencjonalna baza danych A 100 $ B 120 C 50 $ D 45 E 210 Mapowanie w pamięci A 100 $ B 120 C 50 $ D 45 E 210 Adresacja pamięci

9 Zwykła baza danych a baza w pamięci Baza SAP HANA A 100 $ B 120 C 50 $ D 45 E 210 Mapowanie w pamięci A 100 $ B 120 C 50 $ D 45 E 210 mapowanie wierszowe Adresacja pamięci A B C D E $ $ mapowanie kolumnowe Adresacja pamięci

10 Zwykła baza danych a baza w pamięci SAP HANA zalety przechowywania danych kolumnowo: Szybka agregacja danych 525 A B C D E $ $ mapowanie kolumnowe Adresacja pamięci Jeden typ danych w kolumnie pozwala na wysoką kompresję (10x) Dane nieskompresowane Kompresja słownikowa Kowalski Bartoszewski Orłowski Kowalski Zaorski Kowalski N 1 Słownik 0 Bartoszewski 1 Kowalski 2 Orłowski N Zaorski

11 Zwykła baza danych a baza w pamięci Tabele typu cluster i pool zostają zamienione na tabele transparentne, a więc dane w nich zawarte są dostępne z poziomu bazy danych łatwe raportowanie z zewnętrznych narzędzi Indeksy secondary domyślnie nieunikalne indeksy dodatkowe są usuwane, aby zwiększyć wydajność operacji wstawiania danych (insert) i zredukować wykorzystanie pamięci W niektórych przypadkach indeksy secondary mogą zwiększyć wydajność, dlatego należy przeanalizować system

12 Zwykła baza danych a baza w pamięci Wolna pula Pula pamięci bazy Obliczenia tymczasowe Tabele kolumnowe Tabele wierszowe Tabele Pamięć wykorzystywana Tabele systemowe Kod i stok

13 Co charakteryzuje sprzęt dla HANA? Architektura wieloprocesorowa (np. 8 x 10 core) Wymiarowanie sprzętu Przestrzeń adresowa 64bit (2TB danych w RAM) Przepustowość 100GB/s Szybkie karty do zapisu logu bazy (np. Fusion-io iodrive2, >100 tys. IOPS) System operacyjny Linux SLES 11 Zainstalowana platforma SAP HANA

14 Wymiarowanie sprzętu Podstawowe kryterium wyboru sprzętu to RAM Procesory oraz dyski dostosowane do wielkości pamięci RAM. 128GB 256GB 512GB 1TB 2TB 4TB

15 Wymiarowanie sprzętu Certyfikowane, kompletne rozwiązania sprzętowe sprzedawane przez partnerów SAP: Dell Fujitsu HP IBM Cisco Hitachi Huawei NEC VCE

16 Wymiarowanie sprzętu Wymiarowanie sprzętu HANA dla systemów hurtowni danych

17 Wymiarowanie sprzętu Wymiarowanie sprzętu HANA dla systemów ERP: Quick Sizer wymiarowanie początkowe

18 Wymiarowanie sprzętu Wymiarowanie sprzętu HANA dla systemów ERP: Parametr Sposób kalkulacji RAM HANA DB size (uncompressed "well-maintained") / % CPU HANA Disk space HANA 3-4 x CPU Power of disk DB (classic DB) (provides a buffer for running OLTP and OLAP load simultaneously) Persistence = 4 * RAM Log = 1 * RAM CPU App server Tak jak dotychczas (1:1) RAM App server Tak jak dotychczas (1:1)

19 Wymiarowanie sprzętu Wymiarowanie sprzętu HANA dla systemów ERP: Inne spotykane metody kalkulacji: Parametr Sposób kalkulacji RAM HANA CPU HANA DB SAPS * 4 Disk space HANA (DB size / compression factor ) * temporary memory usage Compression factor for ERP: ~ 4 Temporary memory usage: 2 Persistence = 4 * RAM Log = 1 * RAM CPU App server Tak jak dotychczas (1:1) RAM App server Tak jak dotychczas (1:1)

20 Wymiarowanie sprzętu Sprzęt do HANA wykorzystujemy tylko dla baz danych serwery aplikacyjne instalujemy na osobnych serwerach (lub wirtualnych maszynach) Dla systemów rozwojowych oraz testowych SAP wspiera wykorzystanie wirtualizacji (wmware) lub uruchomienie kilku baz na jednym serwerze HANA Dla systemów produkcyjnych wykorzystujemy tylko fizyczny sprzęt (wirtualizacja nie jest wpierana przez SAP)

21 Wymiarowanie sprzętu

22 Wymiarowanie sprzętu

23 Wysoka dostępność i skalowanie Możliwość skalowania SAP HANA na kilku węzłach w przypadku dużych systemów: Master System Tables Master node tabele systemowe (ABAP), metadane, wykonywanie operacji DDL, zarządzanie blokadami Slave 1 Slave n BW Data BW Data Slave nodes dane (master, cubes/dsos/psas), wykonywanie zapytań OLAP, ładowanie i przetwarzanie danych Standby Standby node (opcjonalny) może zastąpić węzeł Master lub Slave

24 Wysoka dostępność i skalowanie Skalowanie systemów ERP z wykorzystaniem kilku węzłów HANA nie jest jeszcze dostępne, ale możemy zastosować rozwiązania sprzętowe Dla systemów ERP możemy korzystać z węzła standby SAP HANA (ERP) Primary node (baza danych systemu ERP) Standby Standby node (opcjonalny) może zastąpić węzeł podstawowy

25 Optymalizacja systemu Deklarowane przez SAP zmiany wydajności

26 Optymalizacja systemu Deklarowane przez SAP zmiany wydajności w finansach

27 Optymalizacja systemu Funkcjonalności aplikacji jest zoptymalizowana po kątem przetwarzania w pamięci Aby wykorzystać w pełni możliwości bazy danych in-memory aplikacje powinny być napisane dla tego typu bazy danych Tradycyjnie Przetwarzanie Warstwa aplikacji Warstwa bazy danych Przetwarzanie SAP HANA

28 Optymalizacja systemu Główne zasady modelowania danych Aplikacja Calculation Views Unikanie transferu dużej ilości danych pomiędzy aplikacją a baząd danych Obliczenia po agregacji, Unikanie skomplikowanego kodu (IF, CASE, ) Attribute View Analitical View Redukcja transferu danych pomiędzy widokami Agregacja danych (klauzula group by, redukcja kolumn) Łączenie tabel po kolumnach kluczowych bądź indeksowanych Unikanie obliczeń przed agregacją Tabela kolumnowa Filtrowanie danych tak wcześnie jak to jest możliwe na najniższym poziomie (ograniczenia, klauzula where, autoryzacje)

29 Wydajność (porównanie przykładowych transakcji) Przykładowy system demonstracyjny ERP: Klasyczna baza danych: ~120GB Baza danych na HANA: (120GB / 4) * 2 = 60GB

30 Wydajność (porównanie przykładowych transakcji) Rzeczywisty system testowy: Klasyczna baza danych: ~2,5TB Baza danych na HANA: <600GB

31 Wydajność (porównanie przykładowych transakcji) Porównanie przykładowych transakcji z systemu przeniesionego na platformę HANA Transakcja Przed migracją (sek.) HANA (sek.) FBL FBL FBL FS10n KE KOB KOB1N - (>600) 28 KSB1N - (>600) 28 Porównanie zostało wykonane zaraz po migracji, bez optymalizacji.

32 Wydajność (porównanie przykładowych transakcji) Przykładowe zapytanie do klasycznej bazy danych Tabela: COEP Rekordy: Zapytanie: suma wartości jednego z pól Czas wykonania: ms (395sek.)

33 Wydajność (porównanie przykładowych transakcji) Przykładowe zapytanie do bazy danych HANA Tabela: COEP Rekordy: Zapytanie: suma wartości jednego z pól Czas wykonania: 78ms Porównanie: ms / 78ms = 5072

34 Linki SAP HANA SAP HANA Trial (30 dniowa wersja demonstracyjna HANA) Raport korzyści z wdrożenia HANA na podstawie wykorzystywanych transakcji

35 Na czym polega projekt migracji na SAP HANA Przygotowanie Migracja Kroki po migracji Optymalizacja

36 Jak się przygotować do migracji? Utworzenie listy wymaganych komponentów i informacji konfiguracyjnych (pliki xml), które wykorzystywane są podczas aktualizacji systemu Archiwizacja i czyszczenie systemu warto rozważyć zmniejszenie bazy danych poprzez archiwizację lub czyszczenie zbędnych danych, ponieważ wielkość bazy danych przekłada się na wymagane zasoby sprzętu dla HANA (RAM, dyski) Migracja na platformę SAP HANA może wymagać dostosowania własnego kodu: dostosowania wynikające z migracji na Unicode dostosowania wynikające z wykorzystania funkcjonalności HANA

37 Na czym polega projekt migracji na SAP HANA Migracja na SAP HANA to klasyczna zmiana platformy bazy danych i systemu operacyjnego OS/DB migration Korzystamy ze sprawdzonej metodologii i narzędzi, tych samych, które stosuje się przy migracji na inne platformy np. Oracle -> DB2 Eksport bieżącej bazy danych -> Import do bazy HANA System źródłowy np. SAP ERP System docelowy: np. SAP ERP Eksport Import Baza danych* np. Oracle Baza danych SAP HANA Pliki eksportu (system plików) Równoległy eksport/import (TCP) * Oracle 11.2; MS SQL Server 2008; IBM DB for Linux, UNIX, and Windows V9.7; SAP MaxDB 7.8; SAP Sybase ASE 15.7; IBM DB2 for i 6,1, 7.1; IBM DB2 for z/os V9, V10

38 Optymalizacja systemu po migracji na SAP HANA Narzędzia: standardowe narzędzia do analizy zapytań, wydajności, śledzenia systemu, analizy kodu: DB02, ST03N, STAD, ST05, SCI Przetwarzanie

39 Pytania