SQL SERVER 2016 IN MEMORY 4 Pytania, które boimy się zadać Cezary Ołtuszyk Blog: coltuszyk.wordpress.com
Kilka słów o mnie Kierownik Działu Administracji Systemami w firmie BEST S.A. (warstwa bazodanowa i aplikacyjna) Konsultant z zakresu SQL Server (projektowanie infrastruktury, tuning, troubleshooting) Posiadacz serii certyfikatów z dziedziny SQL Server, HYPER-V, Windows Server, Red Hat Prelegent na konferencjach informatycznych i spotkaniach grup pasjonackich Autor artykułów i blogger (wss.pl, technet, coltuszyk.wordpress.com)
Plan spotkania I. Wprowadzenie do tematu II. III. IV. Po co pliki, przecież miało być w RAM? I tak mam wszystko w RAM, czy opłaca się zmienić kod? Ile koszyków dla indeksu wybrać? V. Jakie są wady mechanizmu In Memory? VI. Podsumowanie
Wprowadzenie do tematu Ile czasu chciałbyś czekać na swoje dane? 42 godziny vs 1 sekunda http://queue.acm.org/detail.cfm?id=1563874
Wprowadzenie do tematu
Po co pliki, przecież miało być w RAM? Przykładowy kod tworzący bazę wspierającą tabele In Memory : CREATE DATABASE InMemDB ON PRIMARY ( NAME = [InMemDB_data], FILENAME = 'Q:\data\InMemDB_data.mdf', SIZE = 500MB ), FILEGROUP [SampleDB_mod_fg] CONTAINS MEMORY_OPTIMIZED_DATA ( NAME = [InMemDB_mod_dir], FILENAME = 'R:\data\InMemDB_mod_dir ' ), ( NAME = [InMemDB_mod_dir], FILENAME = 'S:\data\InMemDB_mod_dir' ) LOG ON ( NAME = [InMemDB_log], FILENAME = 'L:\log\InMemDB_log.ldf', SIZE = 500MB ) ; Pliki dla tabel InMemory!!!
Po co pliki, przecież miało być w RAM?
I tak mam wszystko w RAM, czy opłaca się zmienić kod?
I tak mam wszystko w RAM, czy opłaca się zmienić kod?
I tak mam wszystko w RAM, czy opłaca się zmieniać kod?
Ile koszyków wybrać? CREATE TABLE [dbo].[tbllookuphash] ( [message_id] [int] NOT NULL, [language_id] [smallint] NOT NULL, [severity] [tinyint] NULL, [is_event_logged] [bit] NOT NULL, [text] [nvarchar](2048) NOT NULL, [testid] int NOT NULL INDEX IX_tblLookupMem_testID, CONSTRAINT PK_tblLookupHash PRIMARY KEY NONCLUSTERED HASH (message_id, language_id) WITH (BUCKET_COUNT = 250000) ) WITH (MEMORY_OPTIMIZED = ON) Jak wybrać tę liczbę?!
Ile koszyków wybrać?
Ile koszyków wybrać?
Jakie są wady mechanizmu 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 DML triggers Not supported (DROP / re-create) Not supported Partially supported (offline details below) 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
Podsumowanie W momencie, gdy nasze tabele in memory mają przechowywać dane po restarcie serwera, to tworzone są pliki data i delta Przy odpowiednich zapytaniach opłaca się skorzystać z baz danych w pamięci Dla indeksów haszujących ustawmy nie mniej koszyków niż wynosi ilość przewidywanych unikalnych wierszy Wraz z SQL 2016 ilość niedogodności w modelu in memory spada