BEST S.A. CASE STUDY: DROGA DO IN MEMORY

Transkrypt

1 BEST S.A. CASE STUDY: DROGA DO IN MEMORY Cezary Ołtuszyk Kierownik Działu Administracji Systemów

2 Agenda spotkania 1. Wprowadzenie 2. Obliczenia czas start (rok 2012) 3. Podwojenie wolumenu (rok 2013) 4. Dane x 3 (rok 2014) 5. Kolejne partie danych In Memory ( ) 6. Podsumowanie

3 Wprowadzenie Czy prawo Moore a nadąża za rozwojem państwa firmy?

4 Wprowadzenie Zagramy w grę Obliczenia na czas

5 Obliczenia czas start (rok 2012)

6 Obliczenia czas start (rok 2012)

7 Podwojenie wolumenu (rok 2013)

8 Podwojenie wolumenu (rok 2013)

9 Podwojenie wolumenu (rok 2013) Na co warto zwrócić uwagę: 1. Dobry projekt to podstawa rozwiązań wielowątkowych 2. Efektywne pobieranie danych z tabel 3. Podział danych (paczkowanie) 4. Problemy z wielodostępem 5. Efektywny zapis na dysk 6. Obsługa błędów 7. Gdzie leży maksimum? 8. Czas i koszt implementacji ( i zmian )

10 Dane x 3 (rok 2014)

11 Dane x 3 (rok 2014) Na co warto zwrócić uwagę: 1. Pobieramy dane tylko raz 2. Obliczenia poza silnikiem SQL 3. Większa ilość wątków = zmiana w kodzie SSIS

12 Kolejne partie danych In Memory ( )

13 Kolejne partie danych In Memory ( ) ZMNIEJSZENIE ILOŚCI ODCZYTANYCH DANYCH Z DYSKU ZMNIEJSZENIE ILOŚCI ZAPISANYCH DANYCH NA DYSK DOKUPIENIE PAMIĘCI RAM + MODEL TRADYCYJNY TAK NIE DOKUPIENIE PAMIECI RAM + IN MEMORY OLTP ZDECYDOWANIE TAK TAK (OPCJA) BRAK ZAKLESZCZEŃ NIE TAK NATYWNIE KOMPILOWANY KOD TSQL NIE TAK INDEKSY HASZUJĄCE NIE TAK

14 Kolejne partie danych In Memory ( ) Feature/Limit SQL Server 2014 SQL Server 2016 Maximum size of durable table 256 GB 2 TB LOB (varbinary(max), [n]varchar(max)) Not supported Supported* Transparent Data Encryption (TDE) Not supported Supported Offline Checkpoint Threads 1 1 per container ALTER PROCEDURE / sp_recompile Not supported Supported (fully online) Nested native procedure calls Not supported Supported Natively-compiled scalar UDFs Not supported Supported ALTER TABLE Not supported Partially supported (DROP / re-create) (offline details below) DML triggers Not supported Partially supported (AFTER, natively compiled) Indexes on NULLable columns Not supported Supported Non-BIN2 collations in index key columns Not supported Supported Non-Latin codepages for [var]char columns Not supported Supported Non-BIN2 comparison / sorting in native modules Not supported Supported Foreign Keys Not supported Supported Check/Unique Constraints Not supported Supported Parallelism Not supported Supported OUTER JOIN, OR, NOT, UNION [ALL], DISTINCT, EXISTS, IN Not supported Supported Multiple Active Result Sets (MARS) (Means better Entity Framework support.) Not supported Supported SSMS Table Designer Not supported Supported

15 Kolejne partie danych In Memory ( ) In-Memory OLTP (In-Memory Optimization) Implementation Scenario Implementation Scenario Benefits of In-Memory OLTP High data insertion rate from multiple concurrent connections. Read performance and scale with periodic batch inserts and updates. Primarily append-only store. Unable to keep up with the insert workload. High performance read operations, especially when each server request has multiple read operations to perform. Unable to meet scale-up requirements. Eliminate contention. Reduce logging. Eliminate contention when new data arrives. Lower latency data retrieval. Minimize code execution time. Intensive business logic processing in the database server. Low latency. Session state management. Insert, update, and delete workload. Intensive computation inside stored procedures. Read and write contention. Require low latency business transactions which typical database solutions cannot achieve. Frequent insert, update and point lookups. High scale load from numerous stateless web servers. Eliminate contention. Minimize code execution time for reduced latency and improved throughput. Eliminate contention. Minimize code execution time. Low latency code execution. Efficient data retrieval. Eliminate contention. Efficient data retrieval. Optional IO reduction or removal, when using non-durable tables

16 Kolejne partie danych In Memory ( ) Applying In-Memory OLTP Shock Absorber In this scenario, Shock Absorber refers to the table you create as memory-optimized to absorb an input rate. This is the shock to the system.

17 Kolejne partie danych In Memory ( ) Compute Heavy Data Processing This scenario consists of ingesting data, similar to the High Data Insert Rate. However, this scenario requires other attributes including updates, deletions, and additional data processing to quickly make data available to readers

18 Podsumowanie 1. Prawo Moore a nie koniecznie musi iść w parze z rozwojem firmy (dla biznesu to dobrze, pole do popisu dla IT) 2. Niektóre operacje bazodanowe mogą być zrównoleglone jedynie przez odpowiednio napisany kod 3. W momencie gdy procesor nie jest wąski gardłem, to zwiększa się znaczenie dysku i pamięci RAM 4. Co zrobić gdy sam sprzęt nie wystarczy? 5. Wchodzenie w trendy nie koniecznie, tworzenie trendów TAK!!!

19 Dziękuję za uwagę