Tal\u00e1n a legnagyobb durran\u00e1ssal kezdem a sorozatot: a mem\u00f3ria t\u00e1bl\u00e1kkal.
\nA nagyon kem\u00e9ny OLTP (CUD, insert, update, delete) forgalommal terhelt t\u00e1bl\u00e1kat meg lehet jel\u00f6lni, mint mem\u00f3ria t\u00e1bl\u00e1kat. A mem\u00f3ria t\u00e1bl\u00e1k \u00e9pp\u00fagy garant\u00e1lj\u00e1k az ACID jellemz\u0151ket, mint a norm\u00e1l t\u00e1bl\u00e1k. Azaz Atomic, Consistent, Isolated, Durable. Atomic: t\u00e1mogatja a tranzakci\u00f3kat. Consistent: ha egy tranzakci\u00f3 el\u0151tt konzisztensek voltak az adatok, akkor a tranzakci\u00f3 lez\u00e1r\u00e1sa ut\u00e1n is azok lesznek. Isolated: az egym\u00e1ssal verseng\u0151 tranzakci\u00f3k nem hatnak egym\u00e1sra (pontosabban pontosan specifik\u00e1lt, mennyire hatnak egym\u00e1sra). Durable: ha egyszer azt mondja, elmentett egy adatot, akkor az t\u00e9nyleg tart\u00f3san el lesz t\u00e1rolva, akkor is, ha pont elmegy az \u00e1ram a commit ut\u00e1n. Ez ut\u00f3bbit gondoln\u00e1, hogy nem teljes\u00fck a mem\u00f3ria t\u00e1bl\u00e1k eset\u00e9n, de ez nem igaz, ez is teljesen Durable, mint a diszk alap\u00fa t\u00e1bl\u00e1k.
\nA tranzakci\u00f3k dolgozhatnak egyszerre diszk \u00e9s mem\u00f3ria t\u00e1bl\u00e1kon is. R\u00e1ad\u00e1sul a csak mem\u00f3ria t\u00e1bl\u00e1kat el\u00e9r\u0151 t\u00e1rolt elj\u00e1r\u00e1sokat le lehet ford\u00edtani nat\u00edv k\u00f3dra is, err\u0151l majd k\u00fcl\u00f6n r\u00e9szben \u00edrok.
\nMit v\u00e1rhatunk t\u0151le? A dokument\u00e1ci\u00f3 szerint 5-20-szor gyorsabbak lesznek a m\u0171veletek, mint a diszk alap\u00fa t\u00e1bl\u00e1kn\u00e1l. Ezt majd ki is m\u00e9rj\u00fck, hogy l\u00e1ssuk a saj\u00e1t szem\u00fcnkkel.
\nMire j\u00f3k a mem\u00f3ria t\u00e1bl\u00e1k?<\/p>\n
Az In-Memory t\u00e1bl\u00e1k TELJESEN M\u00c1S architekt\u00fara ment\u00e9n vannak fel\u00e9p\u00edtve, mint a diszk alap\u00fa t\u00e1bl\u00e1k. Val\u00f3j\u00e1ban az SQL Servert\u0151l f\u00fcggetlen\u00fcl fejlesztett\u00e9k ki, k\u00e9rd\u00e9s volt, hogy k\u00fcl\u00f6n term\u00e9k legyen vagy integr\u00e1lj\u00e1k bele az SQL Serverbe. Ut\u00f3bbi mellett d\u00f6nt\u00f6ttek, ami nek\u00fcnk nagyon k\u00e9nyelmes, csak a fejleszt\u0151knek volt iszonyatos munka az integr\u00e1ci\u00f3. De mi j\u00f3l j\u00e1rtuk vele, mivel k\u00e9nyelmes, megszokott m\u00f3don haszn\u00e1lhatjuk, mint a diszk alap\u00fa t\u00e1bl\u00e1kat, r\u00e1ad\u00e1sul egym\u00e1s mellett \u00e9l a k\u00e9tf\u00e9le t\u00e1blat\u00edpus, \u00edgy lehet \u0151ket joinolni, stb. \u00cdgy a nagyon er\u0151sen terhelt t\u00e1bl\u00e1kat \u00e1t lehet tervezni mem\u00f3ria alap\u00fara, a t\u00f6bbi meg maradhat diszk alap\u00fa. Ez \u00f3ri\u00e1si fegyvert\u00e9ny.<\/p>\n
Az \u00faj engine kifejleszt\u00e9s\u00e9re az volt a motiv\u00e1ci\u00f3, hogy az SQL Server architekt\u00far\u00e1ja az ut\u00f3bbi legal\u00e1bb 20 \u00e9vben nem sokat v\u00e1ltozott. Az alap felt\u00e9telez\u00e9s az volt, hogy minden adat diszken van, \u00e9s csak egy r\u00e9szhalmazuk van benn a mem\u00f3ri\u00e1ban, mivel dr\u00e1ga \u00e9s korl\u00e1tos a RAM, illetve a t\u00e1roland\u00f3 adathalmaz m\u00e9rete sokkal nagyobb, mint a RAM m\u00e9rete. Ez ma m\u00e1r sokszor nem igaz. Emiatt minden szinkroniz\u00e1ci\u00f3s \u00e9s t\u00e1rol\u00e1si adatszerkezet ebb\u0151l az el\u0151felt\u00e9telez\u00e9sb\u0151l lett kialak\u00edtva. Sok processzor \u00e9s mem\u00f3riaintenz\u00edv feldolgoz\u00e1s eset\u00e9n azonban az eddigi adatstrukt\u00far\u00e1k elkezdenek bajba ker\u00fclni. Egyre t\u00f6bb id\u0151 megy el v\u00e1rakoz\u00e1ssal, amit Latch Contentionk\u00e9nt illetve Lock Contentionk\u00e9nt l\u00e1tunk a monitoring eszk\u00f6z\u00f6kben. A MEMORY_OPTIMIZED = ON miatt lesz mem\u00f3ria \u00e9s nem diszk alap\u00fa a t\u00e1bla. A SCHEMA_AND_DATA miatt marad meg restart ut\u00e1n. A k\u00f6vetkez\u0151 r\u00e9szben a hash indexeket r\u00e9szletezem ki. Ha tetszett a cikk, \u00f6r\u00fcl\u00f6k a like-nak, \u00f6szt\u00f6n\u00f6z, hogy hamar meg\u00edrjam a t\u00f6bbi r\u00e9szt is. :)<\/p>\n","protected":false},"excerpt":{"rendered":" Tal\u00e1n a legnagyobb durran\u00e1ssal kezdem a sorozatot: a mem\u00f3ria t\u00e1bl\u00e1kkal. A nagyon kem\u00e9ny OLTP (CUD, insert, update, delete) forgalommal terhelt t\u00e1bl\u00e1kat meg…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-1455","post","type-post","status-publish","format-standard","hentry","category-szakmai-elet"],"_links":{"self":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1455","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1455"}],"version-history":[{"count":5,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1455\/revisions"}],"predecessor-version":[{"id":1504,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1455\/revisions\/1504"}],"wp:attachment":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1455"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1455"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1455"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nAz \u00faj engine k\u00f3dneve Hekaton volt, ami g\u00f6r\u00f6g\u00fcl 100-at jelent. Az\u00e9rt ez a k\u00f3dneve, mert az volt a c\u00e9l, hogy 100-szor gyorsabb motort rakjanak \u00f6ssze. Nyilv\u00e1n ez magas l\u00e9c, de mint motiv\u00e1l\u00f3 er\u0151 j\u00f3 a fejleszt\u0151knek.
\nEgyetlen egy critical section van csak benne, \u00e9s az is 1 utas\u00edt\u00e1s hossz\u00fa, ami egy n\u00f6vel\u00e9s m\u0171velet, a timestamp gener\u00e1l\u00e1shoz haszn\u00e1lj\u00e1k (b\u0151vebben k\u00e9s\u0151bb). A t\u00f6bbi t\u00f6bbsz\u00e1l\u00fa m\u0171veletet a processzor \u00e1ltal t\u00e1mogatott, \u00edgy nagyon gyors interlock compare exchange m\u0171velettel val\u00f3s\u00edtj\u00e1k meg. (.NET-ben ez az Interlocked.CompareExchange<\/a>-re van kivezetve.) Egy lock a norm\u00e1l adatb\u00e1zisban t\u00f6bb 10000 \u00f3rajelciklust ig\u00e9nyel, egy latch t\u00f6bb ezret, egy compare exchange csak 10-20-at. Sz\u00e9p, mi?
\nAz \u00faj motor term\u00e9szetesen sok korl\u00e1tot is mag\u00e1val hoz. Ezek egy r\u00e9sze term\u00e9szetes, pl. nem t\u00e1mogatnak blobokat (nvarchar(max)), m\u00e1s r\u00e9sz\u00fck meg lehet csak az 1.0 miatt van, pl. nincsenek check contraintek (ez csak az \u00e9n v\u00e9lem\u00e9nyem). Ahogy az egyik SQL fejleszt\u0151 mondta, hi\u00e1ba akarunk felh\u0151karcol\u00f3t \u00e9p\u00edteni, el\u0151bb az alapokat kell stabilra \u00e9p\u00edteni. Err\u0151l sz\u00f3l ez az iter\u00e1ci\u00f3, az SQL Server 2014 RTM.
\nA mem\u00f3ria t\u00e1bl\u00e1kat lehet SCHEMA_ONLY durability-vel is megjel\u00f6lni, ekkor a szerver \u00fajraindul\u00e1sa ut\u00e1n elveszik bel\u0151le minden adat, de cser\u00e9be t\u00e9nyleg nem ny\u00fal diszkhez, mivel nem is \u00edg\u00e9r tart\u00f3ss\u00e1gi garanci\u00e1kat. De veszett gyors lesz.
\nHogy l\u00e1ssunk valami konkr\u00e9tabbat, \u00edgy n\u00e9z ki egy durable mem\u00f3ria t\u00e1bla, azaz, ami restart ut\u00e1n is megtartja az adatokat:<\/p>\n\r\nCREATE TABLE [Person].[Person_InMem]\r\n(\r\n\t[BusinessEntityID] [int] NOT NULL,\r\n\t[PersonType] [nchar](2) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,\r\n\t[NameStyle] [bit] NOT NULL CONSTRAINT [DF_Person_InMem_NameStyle] DEFAULT ((0)),\r\n\t[Title] [nvarchar](8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,\r\n\t[FirstName] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,\r\n\t[MiddleName] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,\r\n\t[LastName] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,\r\n\t[Suffix] [nvarchar](10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,\r\n\t[EmailPromotion] [int] NOT NULL CONSTRAINT [DF_Person_InMem_EmailPromotion] DEFAULT ((0)),\r\n\t[rowguid] [uniqueidentifier] NOT NULL CONSTRAINT [DF_Person_InMem_rowguid] DEFAULT (newid()),\r\n\t[ModifiedDate] [datetime] NOT NULL CONSTRAINT [DF_Person_InMem_ModifiedDate] DEFAULT (getdate()),\r\n\r\nCONSTRAINT [PK_Person_InMem_BusinessEntityID] PRIMARY KEY NONCLUSTERED HASH \r\n(\r\n\t[BusinessEntityID]\r\n)WITH ( BUCKET_COUNT = 1048576)\r\n)WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA )\r\n<\/pre>\n
\nHa m\u00f3dosulnak az adatok, csak a tranzakci\u00f3 lez\u00e1r\u00e1sakor \u00edrja ki a m\u00f3dos\u00edt\u00e1sokat diszkre a szerver. Az indexek m\u00f3dos\u00edt\u00e1sait NEM logolja, mivel \u00fajraindul\u00e1skor \u00fajra l\u00e9trehozza \u0151ket a recovery f\u00e1zisban. Ezzel sokkal kevesebb \u00e9s hat\u00e9konyabb IO-val oldja meg a tart\u00f3s adatt\u00e1rol\u00e1st a norm\u00e1l t\u00e1bl\u00e1khoz viszony\u00edtva.<\/p>\n