Nowoczesne bazy danych, czyli przetwarzanie in-memory
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
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
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
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
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
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
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
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 100 120 50 45 210 $ $ mapowanie kolumnowe Adresacja pamięci
Zwykła baza danych a baza w pamięci SAP HANA zalety przechowywania danych kolumnowo: Szybka agregacja danych 525 A B C D E 100 120 50 45 210 $ $ 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 1 0 2 1 N 1 Słownik 0 Bartoszewski 1 Kowalski 2 Orłowski N Zaorski
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
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
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
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
Wymiarowanie sprzętu Certyfikowane, kompletne rozwiązania sprzętowe sprzedawane przez partnerów SAP: Dell Fujitsu HP IBM Cisco Hitachi Huawei NEC VCE http://service.sap.com/pam
Wymiarowanie sprzętu Wymiarowanie sprzętu HANA dla systemów hurtowni danych
Wymiarowanie sprzętu Wymiarowanie sprzętu HANA dla systemów ERP: Quick Sizer wymiarowanie początkowe https://service.sap.com/sizing
Wymiarowanie sprzętu Wymiarowanie sprzętu HANA dla systemów ERP: Parametr Sposób kalkulacji RAM HANA DB size (uncompressed "well-maintained") / 2 + 20% 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)
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)
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)
Wymiarowanie sprzętu
Wymiarowanie sprzętu
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
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
Optymalizacja systemu Deklarowane przez SAP zmiany wydajności
Optymalizacja systemu Deklarowane przez SAP zmiany wydajności w finansach
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
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)
Wydajność (porównanie przykładowych transakcji) Przykładowy system demonstracyjny ERP: Klasyczna baza danych: ~120GB Baza danych na HANA: (120GB / 4) * 2 = 60GB
Wydajność (porównanie przykładowych transakcji) Rzeczywisty system testowy: Klasyczna baza danych: ~2,5TB Baza danych na HANA: <600GB
Wydajność (porównanie przykładowych transakcji) Porównanie przykładowych transakcji z systemu przeniesionego na platformę HANA Transakcja Przed migracją (sek.) HANA (sek.) FBL1 188 3 FBL3 135 2 FBL5 353 2 FS10n 60 22 KE24 465 87 KOB1 362 208 KOB1N - (>600) 28 KSB1N - (>600) 28 Porównanie zostało wykonane zaraz po migracji, bez optymalizacji.
Wydajność (porównanie przykładowych transakcji) Przykładowe zapytanie do klasycznej bazy danych Tabela: COEP Rekordy: 99 556 431 Zapytanie: suma wartości jednego z pól Czas wykonania: 395656ms (395sek.)
Wydajność (porównanie przykładowych transakcji) Przykładowe zapytanie do bazy danych HANA Tabela: COEP Rekordy: 92 117 614 Zapytanie: suma wartości jednego z pól Czas wykonania: 78ms Porównanie: 395656ms / 78ms = 5072
Linki SAP HANA http://help.sap.com/hana_platform SAP HANA Trial (30 dniowa wersja demonstracyjna HANA) http://scn.sap.com/docs/doc-28191 Raport korzyści z wdrożenia HANA na podstawie wykorzystywanych transakcji http://www.suiteonhana.com
Na czym polega projekt migracji na SAP HANA Przygotowanie Migracja Kroki po migracji Optymalizacja
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
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
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
Pytania