it-swarm-eu.dev

Jaké jsou platné scénáře použití pro tabulky HEAP?

V současné době provádím import některých dat do staršího systému a zjistil jsem, že tento systém nepoužívá jediný sdružený index. Rychlé vyhledávání na Googlu mě seznámilo s konceptem tabulek HEAP a teď jsem zvědavý, jaké scénáře použití by měla být tabulka HEAP upřednostňována před seskupenou tabulkou?

Pokud jsem pochopil, tabulka HEAP by byla užitečná pouze pro auditní tabulky a/nebo tam, kde se vkládání děje mnohem častěji než u výběrů. Ušetřilo by to místo na disku a diskové I/O, protože neexistuje žádný klastrovaný index, který by bylo možné udržovat, a další fragmentace by kvůli velmi vzácným čtením nebyla problém.

31
marc.d

Pouze platná použití jsou pro

  • pracovní tabulky používané v importu/exportu/ETL procesy.
  • ad-hoc, dočasné a krátkodobé zálohování tabulek pomocí SELECT * INTO..

Pracovní stoly jsou obvykle před použitím a po použití zkrácené.

Všimněte si, že seskupený index je ve srovnání s velikostí dat obvykle málo malý: data jsou nejnižší úroveň struktury indexu.

Hromadné tabulky mají také problémy. Alespoň tyto:

Viz také

22
gbn

Hlavní úvahy

Vidím jednu důležitou výhodu pro hromady a jednu pro seskupené tabulky, plus třetí ohled, který může jít obousměrně.

  • Hromada vám ušetří vrstvu přesměrování. Indexy obsahují ID řádků směřující přímo (dobře, ne ve skutečnosti, ale co nejpříměji) na umístění disku. Hledání indexu proti haldě by tedy mělo stát zhruba polovinu neúplného hledání indexu proti seskupené tabulce.

  • Seskupený index je sám o sobě tříděn díky (téměř) bezplatnému indexu. Protože index shlukování se odráží ve fyzickém pořadí dat, zabírá relativně málo místa na samotných skutečných datech, které samozřejmě musíte stejně uložit. Protože je to fyzicky nařízeno, skenování rozsahu proti tomuto indexu se může snažit hledat do počátečního bodu a pak velmi efektivně Zipovat do koncového bodu.

  • Indexy na haldy odkazují RID, které jsou 64 bitů. Jak již bylo zmíněno, neklastrované indexy v klastrové tabulce odkazují na klastrovací klíč, který může být menší (32bitový INT), stejný (64bitový BIGINT) nebo větší (48bitový DATETIME2() plus 32bitový INT nebo 128bitový GUID). Je zřejmé, že širší reference umožňuje větší a dražší indexy.

Požadavky na prostor

S těmito dvěma tabulkami:

CREATE TABLE TmpClustered
(
ID1 INT NOT NULL,
ID2 INT NOT NULL
)
ALTER TABLE TmpClustered ADD CONSTRAINT PK_Tmp1 PRIMARY KEY CLUSTERED (ID1)
CREATE UNIQUE INDEX UQ_Tmp1 ON TmpClustered (ID2)

CREATE TABLE TmpNonClustered
(
ID1 INT NOT NULL,
ID2 INT NOT NULL
)
ALTER TABLE TmpNonClustered ADD CONSTRAINT PK_Tmp2 PRIMARY KEY NONCLUSTERED (ID1)
CREATE UNIQUE INDEX UQ_Tmp2 ON TmpNonClustered (ID2)

... každý obydlený 8,7 M záznamy, potřebný prostor byl 150 MB pro data pro oba; 120 MB pro indexy seskupené tabulky, 310 MB pro indexy neslastované tabulky. To odráží, že klastrovaný index je užší než RID a že klastrovací index je většinou „freebie“. Bez jedinečných indexů na ID2, požadovaný indexový prostor klesl na 155 MB pro neslastovanou tabulku (polovina, jak byste očekávali), ale pouze 150 KB pro seskupený PK - téměř nic.

Neoklastovaný index 32bitového pole v seskupené tabulce s 32bitovým indexem (celkem 64 bitů, nominálně) tedy trvalo 120 MB, zatímco index 32bitového pole v haldě s 64bitovým RID (celkem 96 bitů, nominálně) trvalo 155 MB, což je o něco méně než 50% nárůst, který by člověk naivně očekával od 64-bitových po 96-bitové klíče, ale samozřejmě existuje režie, která snižuje efektivní rozdíl ve velikosti.

Naplnění dvou tabulek a vytvoření jejich indexů trvalo u každé tabulky stejné množství času. Při provádění jednoduchých testů, které zahrnují skenování nebo vyhledávání, jsem nenašel žádné rozdíly v materiálové výkonnosti mezi tabulkami, které by odpovídaly bílé knize společnosti Microsoft, kterou gbn užitečně propojil. Uvedený papír vykazuje významný rozdíl pro vysoce souběžný přístup; Nejsem si jistý, proč se to stane, doufejme, že někdo s více zkušenostmi než já s velkoobjemovým OLTP nám to mohou říct).

Přidání ~ 40 bajtů náhodných dat s proměnnou délkou tuto ekvivalenci výrazně nezměnilo. Nahrazení INTs širokými UUIDy také ne (každá tabulka byla zpomalena přibližně ve stejném rozsahu). Váš počet najetých kilometrů se může lišit, ale ve většině případů zda je index k dispozici, je důležitější než jaký druh.

Kousky

Provedení kontroly rozsahu proti indexu bez klastrů - buď proto, že tabulka je halda, nebo index není sdruženým indexem - zahrnuje skenování indexu a následné vyhledávání proti tabulce pro každý přístup. To může být velmi drahé, takže někdy je levnější skenovat pouze stůl. Můžete to však vyřešit pomocí indexu krytí. To platí bez ohledu na to, zda jste seskupili svůj stůl.

Jak @gbn zdůraznil, neexistuje jednoduchý způsob, jak zhutnit hromadu. Pokud se však vaše tabulka v průběhu času postupně zvyšuje - což je velmi běžný případ - bude málo odpadu, protože prostor uvolněný vymazáním bude vyplněn novými daty.

Několik diskusí o hromadných tabulkách s hromadami haldy versus seskupení, které jsem viděl, podivuje argument, že halda bez indexů je nižší než tabulka seskupená v tom, že vždy vyžaduje skenování tabulky. To je jistě pravda, ale smysluplnější srovnání je „velká dobře indexovaná klastrovaná tabulka“ vs „velká dobře indexovaná halda.“ Pokud je váš stůl velmi malý nebo vždy budete dělat skenování tabulky, pak na tom prostě nezáleží, pokud jej seskupíte nebo ne.

Protože každý index v seskupené tabulce odkazuje na seskupovací index, jsou ve skutečnosti všechny krycí indexy. Dotaz, který odkazuje na indexovaný sloupec a klastrovací sloupce, může provést indexové skenování bez vyhledávání v tabulce. To obecně není užitečné, pokud je váš klastrový index syntetický klíč, ale pokud je to obchodní klíč, který byste stejně potřebovali získat, je to pěkná funkce.

TL; DR

Jsem skladatel dat, ne odborník OLTP=================================================================================================== tabulky dimenzí, které shlukuji na PK, takže je přednastaveno pro sloučení spojení s tabulkami faktů.

Existuje několik důvodů pro použití indexů shlukování, ale pokud žádný z těchto důvodů neplatí, režijní náklady nemusí být užitečné. Mám podezření, že za lidmi, kteří všeobecně používají seskupené indexy, existuje spousta „vždy jsme to udělali“ a „je to jen nejlepší praxe“. Zkuste oba s vaše data a vaše načíst a uvidíte, co funguje nejlépe.

9

Myslím, že rčení „Jediné platné použití je pro pracovní stoly používané v importu/exportu/ETL procesy“, je přinejmenším omezující. Musíte vzít předpokládaný případ použití daného systému a poté zvolit na základě výhod haldy nebo indexovaných tabulek (já vím, výraz Oracle, ale pěkně to popisuje).

Náš sklad načítá ~ 1,5 miliardy řádků denně a musí podporovat vysoce souběžné zápisy a zpracování i čtení. Relační obchod podporuje databázi OLAP), a proto jsou čtení obvykle primárně skenováním tabulky. Sestavy a následné zdroje, které jsou generovány, také obecně nejsou dostatečně selektivní, takže by byl užitečný jakýkoli index. systém podporuje posuvné okno dat, a tak jakmile je tabulka načtena, do ní jen zřídka zapisujeme a vzhledem k poněkud špatné implementaci rozdělení tabulky vyžadující zámky Sch-M pro rozdělení oddílů, přepínače a slučování versus zámky Sch-S pro čtení atd., systém musel využívat mnoho tabulek, i když máme také některé tabulky s oddíly. Použití mnoha tabulek usnadňuje segmentaci dat a cykly čištění a zároveň snižuje soupeření.

Přidaná režie tabulky organizované indexem (seskupená tabulka) na některých libovolných sloupcích versus schopnost bcp do haldy zpracovat oddíly OLAP, provést některé dotazy prohledávání tabulky) a pak o 3 dny později pokles znamená, že to prostě nestojí za to. Všimněte si, že v našem případě se data vracejí z velkého clusteru mřížky, takže k datům také nedochází, takže vložení do tabulky se seskupeným indexem by mohlo představit další problémy, jako jsou "horká místa" a rozdělení stránky a podobně.

Také si myslím, že argument o rozptýlení stránek je trochu neobvyklý. U skupinových indexů mohou být jejich stránky rozptýleny v celém souboru. Je to jen to, že po přeindexování (za předpokladu, že více než 1 000 stránek) to může být lepší než hromada, ale také jste museli znovu provést indexaci.

Je také možné ušetřit místo pomocí řídkých sloupců a komprese, pokud se jedná o problém. Je pravda, že v některých případech může být výběr v tabulce se seskupeným indexem rychlejší, ale musíte to zvážit pomocí zdrojů potřebných k jeho načtení a údržbě.

[Upravit] Pravděpodobně bych měl objasnit, že pouze naše faktické tabulky bez oddílů jsou hromady. Rozdělené tabulky a tabulky rozměrů mají seskupené indexy pro podporu efektivního vyhledávání atd. [Upravit2] Opraveno 2,5 miliardy až 1,5 miliardy. Tut, ta dvě čísla jsou vedle sebe. Co se stane, když píšu odpovědi na telefonu, myslím ...

5
Phil Stephenson