BEST S.A. - Cezary Ołtuszyk · CASE STUDY: DROGA DO IN MEMORY Podwojenie wolumenu (rok 2013) Na co...
Transcript of BEST S.A. - Cezary Ołtuszyk · CASE STUDY: DROGA DO IN MEMORY Podwojenie wolumenu (rok 2013) Na co...
BEST S.A.
CASE STUDY: DROGA DO IN MEMORY
Cezary Ołtuszyk Kierownik Działu Administracji Systemów
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” (2016-2017)
6. Podsumowanie
CASE STUDY: DROGA DO IN MEMORY
Agenda spotkania
CASE STUDY: DROGA DO IN MEMORY
Wprowadzenie
Czy prawo Moore’a nadąża za rozwojem państwa firmy?
CASE STUDY: DROGA DO IN MEMORY
Wprowadzenie
Zagramy w grę „Obliczenia na czas”
CASE STUDY: DROGA DO IN MEMORY
Obliczenia czas start (rok 2012)
CASE STUDY: DROGA DO IN MEMORY
Obliczenia czas start (rok 2012)
CASE STUDY: DROGA DO IN MEMORY
Podwojenie wolumenu (rok 2013)
CASE STUDY: DROGA DO IN MEMORY
Podwojenie wolumenu (rok 2013)
CASE STUDY: DROGA DO IN MEMORY
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 )
CASE STUDY: DROGA DO IN MEMORY
Dane x 3 (rok 2014)
CASE STUDY: DROGA DO IN MEMORY
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
CASE STUDY: DROGA DO IN MEMORY
Kolejne partie danych … „In Memory” (2016-2017)
CASE STUDY: DROGA DO IN MEMORY
Kolejne partie danych … „In Memory” (2016-2017)
DOKUPIENIE PAMIĘCI RAM + MODEL TRADYCYJNY
DOKUPIENIE PAMIECI RAM + IN MEMORY OLTP
ZMNIEJSZENIE ILOŚCI
ODCZYTANYCH DANYCH Z
DYSKU
TAK ZDECYDOWANIE TAK
ZMNIEJSZENIE ILOŚCI
ZAPISANYCH DANYCH NA
DYSK
NIE TAK (OPCJA)
BRAK ZAKLESZCZEŃ NIE TAK
NATYWNIE
KOMPILOWANY KOD TSQL
NIE TAK
INDEKSY HASZUJĄCE NIE TAK
CASE STUDY: DROGA DO IN MEMORY
Kolejne partie danych … „In Memory” (2016-2017)
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
(DROP / re-CREATE)
Partially supported
(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
CASE STUDY: DROGA DO IN MEMORY
Kolejne partie danych … „In Memory” (2016-2017)
In-Memory OLTP (In-Memory Optimization)
Implementation Scenario Implementation Scenario Benefits of In-Memory OLTP
High data insertion rate from multiple concurrent connections.
Primarily append-only store. Unable to keep up with the insert workload.
Eliminate contention. Reduce logging.
Read performance and scale with periodic batch inserts and updates.
High performance read operations, especially when each server request has multiple read operations to perform. Unable to meet scale-up requirements.
Eliminate contention when new data arrives. Lower latency data retrieval. Minimize code execution time.
Intensive business logic processing in the database server.
Insert, update, and delete workload. Intensive computation inside stored procedures. Read and write contention.
Eliminate contention. Minimize code execution time for reduced latency and improved throughput.
Low latency. Require low latency business transactions which typical database solutions cannot achieve.
Eliminate contention. Minimize code execution time. Low latency code execution. Efficient data retrieval.
Session state management. Frequent insert, update and point lookups. High scale load from numerous stateless web servers.
Eliminate contention. Efficient data retrieval. Optional IO reduction or removal, when using non-durable tables
CASE STUDY: DROGA DO IN MEMORY
Kolejne partie danych … „In Memory” (2016-2017)
https://msdn.microsoft.com/library/dn673538.aspx
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.
CASE STUDY: DROGA DO IN MEMORY
Kolejne partie danych … „In Memory” (2016-2017)
https://msdn.microsoft.com/library/dn673538.aspx
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
CASE STUDY: DROGA DO IN MEMORY
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 !!!