Index rozsahu bloků - Block Range Index
Block Rozsah Index nebo BRIN je databáze indexování techniky. Jsou určeny ke zlepšení výkonu s extrémně velkými tabulkami.
BRIN indexy poskytují podobné výhody jako horizontální dělení nebo dělení, ale bez nutnosti explicitně deklarovat oddíly.
BRIN je použitelný pro index v tabulce, která je velká a kde je hodnota klíče indexu snadno tříděna a vyhodnocena pomocí funkce MinMax .
BRIN původně navrhl Alvaro Herrera z 2. kvadrantu v roce 2013 jako „indexy Minmax“. Dosavadní implementace jsou úzce spojeny s interními technikami implementace a ukládání pro databázové tabulky. Díky tomu jsou efektivní, ale omezují se na konkrétní prodejce. Zatím PostgreSQL je jediným dodavatelem, který oznámily živý produkt s touto specifickou funkci, v PostgreSQL 9.5. Jiní prodejci popsali některé podobné funkce, například Oracle , „mapy zón“ Netezza , „datové balíčky“ Infobright , MonetDB a Apache Hive s ORC / Parquet.
Design
BRIN funguje tak, že „shrnuje“ velké bloky dat do kompaktní podoby, kterou je možné efektivně testovat, aby bylo možné je hned na začátku vyloučit z databázového dotazu. Tyto testy vylučují velký blok dat pro každé srovnání. Tím, že tak brzy snížíte objem dat, a to jak reprezentací velkých bloků jako malých n-tic, tak eliminací mnoha bloků, BRIN podstatně sníží množství podrobných dat, která musí být prozkoumána uzlem databáze na základě jednotlivých řádků.
Úložiště dat ve velkých databázích je vrstvené a blokované a úložiště tabulky je uspořádáno do „bloků“. Každý blok obsahuje možná 1 MB v každém bloku a jsou načteny požadováním konkrétních bloků z diskové úložné vrstvy. BRIN jsou lehká souhrnná vrstva v paměti nad tímto: každá n-tice v indexu shrnuje jeden blok, pokud jde o rozsah v nich obsažených dat: jeho minimální a maximální hodnoty, a pokud blok obsahuje nenulová data pro sloupec ( s) zájmu.
Na rozdíl od tradičního indexu, který lokalizuje oblasti tabulky obsahující hodnoty zájmu, působí BRIN jako „negativní indexy“, zobrazující bloky, které rozhodně nejsou zajímavé, a proto není nutné je dále zpracovávat.
Některé jednoduché měřítka naznačují pětinásobné zlepšení výkonu vyhledávání pomocí indexového skenování ve srovnání s neindexovanou tabulkou. Ve srovnání s B-stromy se vyhýbají režii údržby.
Jelikož jsou BRIN tak lehké, mohou být drženy zcela v paměti, čímž se během skenování zabrání režii disku. Totéž nemusí platit o B-stromu: B-strom vyžaduje uzel stromu pro každých přibližně N řádků v tabulce, kde N je kapacita jednoho uzlu, takže velikost indexu je velká. Jelikož BRIN vyžaduje pouze n-tici pro každý blok (mnoha řádků), index se stane dostatečně malým, aby vytvořil rozdíl mezi diskem a pamětí. U „úzké“ tabulky se objem indexu B-stromu blíží objemu samotné tabulky; BRIN může tvořit pouze 5–15%.
Výhody
Vyhledávání a indexování
Velký databázový index by obvykle používal algoritmy B-stromu . BRIN není vždy náhradou za B-strom, jedná se o vylepšení sekvenčního skenování indexu, se zvláštními (a potenciálně velkými) výhodami, když index splňuje určité podmínky pro objednání a pro cíl vyhledávání je úzká sada tyto hodnoty. Obecně platí, že s náhodnými daty může být B-strom stále lepší.
Zvláštní výhodou techniky BRIN, sdílené s inteligentním skenováním Oracle Exadata, je použití tohoto typu indexu s aplikacemi Big Data nebo datovými sklady , kde je známo, že téměř celá tabulka je pro rozsah zájmu irelevantní. BRIN umožňuje v takových případech dotazovat tabulku pouze načítáním bloků, které mohou obsahovat zajímavá data, a vyloučením těch, které jsou jasně mimo rozsah, nebo neobsahují žádná data pro tento sloupec.
Vložit
Pravidelným problémem při zpracování velkých tabulek je, že načítání vyžaduje použití indexu, ale udržování tohoto indexu zpomaluje přidávání nových záznamů. Typickým postupem bylo seskupení přidání a přidání jako jedné hromadné transakce nebo zrušení indexu, přidání dávky nových záznamů a opětovné vytvoření indexu. Obě tyto funkce narušují simultánní operace čtení a zápisu a v některých nepřetržitě fungujících podnicích nemusí být možné.
U BRINu je zpomalení z udržování indexu ve srovnání s B-stromem mnohem menší. Wong uvádí, že B-strom zpomalil přírůstky neindexovaného 10GB stolu o 85%, ale srovnatelný BRIN měl pouze režii 11%.
Vytvoření indexu
BRIN může být vytvořen pro extrémně velká data, kde by B-strom vyžadoval horizontální rozdělení.
Vytvoření BRINU je také mnohem rychlejší než u B-stromu, a to o 80%. To by bylo užitečné vylepšení refaktorování existujících databázových aplikací, které používají přístup drop-add-reindex, bez nutnosti změn kódu.
Implementace
Závislost na objednání stolu
Vícenásobný BRIN může být definován pro různé sloupce v jedné tabulce. Existují však omezení.
BRIN jsou efektivní pouze v případě, že pořadí klíčových hodnot sleduje organizaci bloků v úložné vrstvě. V nejjednodušším případě by to mohlo vyžadovat fyzické uspořádání tabulky, což je často pořadí vytváření řádků v ní, aby odpovídalo pořadí klíče. Pokud je tímto klíčem datum vytvoření, může to být triviální požadavek.
Pokud jsou data skutečně náhodná nebo pokud existuje velká změna klíčových hodnot v „horké“ databázi, mohou se základní předpoklady BRIN rozložit. Všechny bloky obsahují položky „zajímavé“, a tak může být brzy filtrem BRIN vyloučeno jen málo z nich.
Ve většině případů je BRIN omezen na jeden index na tabulku. Lze definovat více BRIN, ale pouze jeden pravděpodobně bude mít vhodné uspořádání. Pokud mají dva (nebo více) indexy podobné chování při objednávání, může být možné a užitečné definovat více BRIN ve stejné tabulce. Zřejmým příkladem je situace, kdy se jak datum vytvoření, tak sloupec record_id zvyšují monotónně se sekvencí vytváření záznamu. V ostatních případech nemusí být klíčová hodnota monotónní, ale za předpokladu, že ve fyzickém pořadí záznamu stále existuje silné seskupení, je BRIN efektivní.
Indexy úložiště Exadata
BRIN mají určité podobnosti s „ Indexy úložiště “ Oracle Exadata . Exadata má v zásobníku architektury silný koncept „úložné vrstvy“. Data tabulky jsou uchovávána v blocích nebo „úložných buňkách“ na úložných serverech. Tyto úložné buňky jsou pro úložný server neprůhledné a na požádání se vrací do databázového stroje podle jejich identifikátoru. Dříve uzly databáze musí pro jejich skenování vyžadovat všechny buňky úložiště.
Storage Indexes poskytuje prořezávání dat v této vrstvě: efektivně označující sekce, které již nemají žádný další zájem. Index úložiště se načte do paměti na úložném serveru, takže když je vydán požadavek na buňky, může být predikován hodnotami vyhledávání. Porovnávají se s indexem úložiště a do uzlu databáze je třeba vrátit pouze příslušné buňky.
Výhody výkonu s indexem úložiště jsou nejzřetelnější, když indexovaný sloupec obsahuje mnoho hodnot null . Při skenování napříč řídkými daty se získají výhody velkého výkonu .
Rozvoj
Vývoj pro PostgreSQL byl prováděn v rámci projektu AXLE (Advanced Analytics for Extremely Large European Database). Tato práce byla částečně financována ze sedmého rámcového programu Evropské unie (FP7 / 2007-2013).
PostgreSQL
Implementace pro PostgreSQL byla poprvé patrná v roce 2013. BRIN se objevil ve verzi 9.5 PostgreSQL na začátku roku 2016.
