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 MEMORYAgenda spotkania

CASE STUDY: DROGA DO IN MEMORYWprowadzenie

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

CASE STUDY: DROGA DO IN MEMORYWprowadzenie

Zagramy w grę„Obliczenia na czas”

CASE STUDY: DROGA DO IN MEMORYObliczenia czas start (rok 2012)

CASE STUDY: DROGA DO IN MEMORYObliczenia czas start (rok 2012)

CASE STUDY: DROGA DO IN MEMORYPodwojenie wolumenu (rok 2013)

CASE STUDY: DROGA DO IN MEMORYPodwojenie wolumenu (rok 2013)

CASE STUDY: DROGA DO IN MEMORYPodwojenie 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 MEMORYDane x 3 (rok 2014)

CASE STUDY: DROGA DO IN MEMORYDane 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 MEMORYKolejne partie danych … „In Memory” (2016-2017)

CASE STUDY: DROGA DO IN MEMORYKolejne 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 TAKNATYWNIE KOMPILOWANY KOD TSQL

NIE TAK

INDEKSY HASZUJĄCE NIE TAK

CASE STUDY: DROGA DO IN MEMORYKolejne partie danych … „In Memory” (2016-2017)

Feature/Limit SQL Server 2014 SQL Server 2016Maximum size of durable table 256 GB 2 TBLOB (varbinary(max), [n]varchar(max)) Not supported Supported*Transparent Data Encryption (TDE) Not supported SupportedOffline Checkpoint Threads 1 1 per containerALTER PROCEDURE / sp_recompile Not supported Supported (fully online)Nested native procedure calls Not supported SupportedNatively-compiled scalar UDFs Not supported SupportedALTER 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 SupportedNon-BIN2 collations in index key columns Not supported SupportedNon-Latin codepages for [var]char columns Not supported Supported

Non-BIN2 comparison / sorting in native modules Not supported SupportedForeign Keys Not supported SupportedCheck/Unique Constraints Not supported SupportedParallelism Not supported SupportedOUTER 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 MEMORYKolejne 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 MEMORYKolejne 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 MEMORYKolejne 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 MEMORYPodsumowanie

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 !!!

Dziękuję za uwagę