Podrobný přehled o tabulkách Oracle In-Memory a úplném ukládání databáze do mezipaměti

Home » PYTHON » Podrobný přehled o tabulkách Oracle In-Memory a úplném ukládání databáze do mezipaměti

Práce s rozsáhlými tabulkami plně uloženými v mezipaměti Oracle se může zdát jako řízení vozu Formule 1: neuvěřitelně rychlé, když je vše naladěno, a bolestně neúprosné, když něco není v pořádku. S tím, jak se databáze vyvíjejí směrem ke schématům se stovkami nebo dokonce tisíci sloupců, se musí změnit i náš přístup k modelování, ukládání do mezipaměti a dotazování dat. Oracle nabízí výkonné funkce pro ukládání do mezipaměti v paměti a vyrovnávací paměti, ale ty se osvědčí pouze tehdy, pokud pochopíme, jak zacházejí s malými, středními a velkými tabulkami a jak to souvisí s návrhem širokých tabulek.

Tato příručka se dozvíte, jak Oracle zpracovává formáty v paměti, plné ukládání databáze do mezipaměti a praktické důsledky velmi širokých tabulek pro analytiku, úlohy OLTP a operace. Během toho uvidíte, jak se algoritmy mezipaměti vyvinuly za hranice jednoduchého LRU, proč Oracle zachází s velkými tabulkami odlišně, kdy má smysl plné ukládání databáze do mezipaměti a jak to vše ovlivňuje strategii indexování, dělení, úlohy umělé inteligence/analytiky a dokonce i rozsáhlé mazání za přísných bezpečnostních omezení.

Sloupcový formát v paměti a skenování SIMD v Oracle

Oracle Database In-Memory zavádí sloupcovou reprezentaci navrženou speciálně pro bleskově rychlé prohledávání, spojení a agregace v paměti. Místo čtení celých řádků z bloků orientovaných na disk může Oracle ukládat vybrané objekty do úložiště sloupců v paměti, kde je každý sloupec komprimován a optimalizován pro analytické dotazy, které se dotýkají mnoha řádků, ale relativně malého počtu sloupců.

Kromě toho Oracle využívá vektorové zpracování SIMD (Single Instruction, Multiple Data) na úrovni CPU ke zpracování miliard řádků za sekundu na jádro pro vhodné pracovní zátěže. Pokud jsou dotazy z velké části určeny pouze pro čtení a zahrnují filtry rozsahu, agregace a analytické funkce, může databáze vyhodnocovat více hodnot paralelně v rámci jedné instrukce CPU, což dramaticky zvyšuje propustnost ve srovnání s konvenčním prováděním řádek po řádku.

U širokých tabulek je to velmi důležité, protože tradiční formát založený na řádcích umožňuje, aby každé čtení zahrnovalo všechny sloupce v bloku, i když se dotaz dotkne jen hrstky z nich. Pokud jsou pro úložiště sloupců v paměti povoleny určité široké tabulky nebo oddíly, může Oracle zcela přeskočit irelevantní sloupce, čímž se sníží využití šířky pásma paměti a zátěž CPU, což je zásadní pro analýzy a dashboardy v reálném čase.

V praxi to znamená, že analýzy, které dříve trvaly hodiny, lze často zkrátit na sekundy, což umožňuje rozhodování o provozních datech téměř v reálném čase. Zprávy o rozsáhlých tabulkách faktů, ad-hoc vyšetřování telemetrie a dotazy business intelligence těží z kombinace komprese, sloupcového přístupu a vektorizovaného zpracování, pokud jsou správně nakonfigurovány.

Od základního LRU k chytřejším algoritmům buffer cache

Než se pustíme do úplného ukládání databáze do mezipaměti, je užitečné pochopit, jak Oracle historicky rozhodoval, které bloky zůstanou v mezipaměti vyrovnávací paměti a které budou odstraněny. V raných verzích se Oracle spoléhal na jednoduchý seznam LRU (Last Recently Used): když se vyrovnávací paměť zaplnila, nejméně naposledy použité bloky na konci seznamu byly zahozeny, aby se uvolnilo místo pro nové.

Problém s naivním přístupem LRU spočívá v konfliktech a nespravedlnosti při smíšených úlohách OLTP. Pokaždé, když se bloku někdo dotkl, musel být přesunut na „horký“ konec seznamu. Za intenzivního souběžného přístupu mnoho relací soupeřících o povýšení bloků proměnilo tuto oblast seznamu v hotspot. Navíc úplné skenování velké tabulky mohlo vytlačit obrovskou vlnu bloků na začátek seznamu a rychle vytlačit skutečně horké bloky z často navštěvovaných menších tabulek.

Aby se tento problém vyřešil, společnost Oracle vyvinula algoritmus pro ukládání do vyrovnávací paměti přidáním čítače využití a časového razítka ke každému bloku, namísto slepého přesouvání každého dotknutého bloku úplně nahoru. Pokaždé, když je k bloku přistupováno, jeho čítač se zvýší a aktualizuje se čas jeho posledního použití. Vysoká hodnota čítače naznačuje, že blok je populární, ale aktuálnost časového razítka stále záleží; blok, který byl před hodinou hojně používán, ale od té doby už ne, nemusí být tak cenný jako něco, co bylo v posledních několika sekundách neustále používáno.

Rozhodnutí o vystěhování je proto založeno na kombinaci toho, jak často a jak nedávno byl blok používán. Oracle tyto dva rozměry vyvažuje tak, aby bloky intenzivně čtené ve velmi krátkém období ne vždy dominovaly nad bloky, které mají mírnější, ale trvalejší přístupový vzorec. Tato hybridní strategie vyhlazuje patologické případy vytvořené rozsáhlými skenováními a snižuje soupeření o „horký“ konec mezipaměti.

Jak Oracle zachází s malými, středními a velkými tabulkami v mezipaměti vyrovnávací paměti

Protože paměť není nekonečná, Oracle používá různé strategie ukládání do mezipaměti v závislosti na relativní velikosti tabulky v porovnání s celkovou velikostí mezipaměti. To je klíčové, pokud pracujete s rozsáhlými tabulkami nebo s velmi rozsáhlými tabulkami faktů, které snadno zaplní dostupnou paměť.

Pro malé tabulky je Oracle velmi šetrný k mezipaměti. Pokud je celková velikost tabulky menší než zhruba 2 % mezipaměti vyrovnávací paměti, Oracle obvykle ukládá všechny své bloky po jejich načtení do mezipaměti a celou tabulku uchovává v paměti. Do této kategorie často spadají malé vyhledávací tabulky a referenční data, což je ideální, protože se k nim často přistupuje a z plného ukládání do mezipaměti značně profitují.

Středně velké tabulky spadají do jemnější kategorie, často někde mezi 2 % a přibližně 10 % mezipaměti vyrovnávací paměti, i když přesné prahové hodnoty se mohou lišit. U těchto případů Oracle před rozhodnutím, zda má bloky agresivně ukládat do mezipaměti, zvažuje několik signálů: kdy byla tabulka naposledy kompletně prohledána, jak nedávno byly použity bloky, které jsou již v mezipaměti, kolik volného místa je v mezipaměti a velikost tabulky. Jinými slovy, střední tabulky jsou zpracovávány na základě poměru nákladů a přínosů, a to jak na základě velikosti objektu, tak i vzorců přístupu.

S velkými tabulkami, zejména s těmi, jejichž velikost daleko přesahuje 10 % mezipaměti vyrovnávací paměti, se ve výchozím nastavení zachází velmi konzervativně. Oracle se obecně vyhýbá naplňování mezipaměti vyrovnávacích pamětí všemi svými bloky po úplném skenování, protože by to mohlo vymazat skutečně žádaná data z menších, často navštěvovaných tabulek. V mezipaměti se mohou zobrazit některá metadata nebo hrstka datových bloků, ale velké tabulky se nebudou plně ukládat do mezipaměti, pokud Oracle explicitně neurčíte toto pomocí mechanismů, jako je buffer pool KEEP nebo jiné direktivy.

Tato strategie je obzvláště důležitá při práci s rozsáhlými tabulkami faktů, které mohou zabírat gigabajty nebo terabajty. Jedno týdenní nebo měsíční skenování takové tabulky by nemělo vyhodit veškerou pracovní sadu OLTP z paměti. Oracle místo toho upřednostňuje objekty, které poskytují největší přínos pro většinu dotazů.

Úplné ukládání databáze do mezipaměti: když se vše vejde do paměti

Úplné ukládání databáze do mezipaměti, zavedené v Oracle Database 12.1.0.2, je navrženo pro prostředí, kde je mezipaměť vyrovnávací paměti dostatečně velká pro uložení logické velikosti celé databáze. V tomto scénáři již nedává smysl používat složitá pravidla pro vyřazování pro velké versus malé stoly; pokud vše sedí, cílem je to tam udržet.

Pokud je povoleno úplné ukládání do mezipaměti databáze, Oracle předpokládá, že všechny bloky čtení z uživatelských dat mohou a měly by zůstat v paměti. Klasické rozlišení mezi malými, středními a velkými objekty se v souvislosti s ukládáním do mezipaměti do značné míry ignoruje; každá tabulka, kterou si přečtete, bez ohledu na její šířku nebo velikost, bude mít své bloky uchovávány v mezipaměti vyrovnávací paměti při přístupu k nim, a to až do fyzických limitů paměti.

Je důležité si uvědomit, že povolení úplného ukládání databáze do mezipaměti nenačte okamžitě všechny bloky všech objektů do paměti. Místo toho se chová oportunisticky: když aplikace dotazují tabulky a segmenty, přístupné bloky se ukládají do mezipaměti a poté se zachovávají, místo aby byly nahrazovány na základě starší heuristiky. Postupem času, jak se pracovní zátěže dotýkají stále více databáze, se vyrovnávací paměť mezipaměti dostává do stavu, kdy je celá datová sada rezidentní v paměti.

V prostředí s více klienty, pokud povolíte úplné ukládání databáze do mezipaměti na úrovni CDB, toto chování se rozšíří na všechny PDB v dané kontejnerové databázi. To znamená, že každá připojitelná databáze v daném kontejneru může tuto funkci využívat a nelze ji selektivně povolit nebo zakázat pro každou instanci v rámci konfigurace RAC; jedná se o vlastnost databáze typu „všechno nebo nic“.

Dalším nenápadným, ale důležitým efektem je, že i segmenty označené jako NOCACHE, včetně segmentů LOB, se při vynucení úplného ukládání do mezipaměti databáze ukládají do mezipaměti. Databáze efektivně přepisuje obvyklé rady pro ukládání do mezipaměti na úrovni objektů, protože globální předpoklad je, že paměť je dostatečná pro uložení všeho.

Pravidla pro dimenzování a kontroly pro úplné ukládání databáze do mezipaměti

Než zapnete plnou mezipaměť databáze, musíte ověřit, zda je vaše mezipaměť vyrovnávací paměti skutečně dostatečně velká pro databázovou zátěž. Oracle při kontrole proveditelnosti rozlišuje mezi databázemi s jednou instancí a klastry reálných aplikací (RAC).

Pro databázi bez RAC by logická velikost databáze měla být menší než celková velikost mezipaměti bufferu. Logická velikost se zde vztahuje k datům, která je realisticky nutné ukládat do mezipaměti pro vaši pracovní zátěž, ne nutně k poslednímu bajtu zřídka používaných archivních informací. V praxi však chcete mít dostatečnou rezervu, aby růst a prudké zvýšení aktivity náhle nenarušily předpoklad, že „všechno se vejde“.

V prostředích RAC je pravidlo přísnější a musí platit jak na úrovni instance, tak na úrovni clusteru. Velikost logické databáze musí být menší než velikost mezipaměti bufferu každé jednotlivé instance a také menší než přibližně 80 % součtu mezipamětí bufferu všech instancí v clusteru. Toto dvojí omezení zajišťuje, že se žádná jednotlivá instance nestane úzkým hrdlem, zatímco cluster jako celek bude i nadále těžit z výhod této funkce.

Aktuální velikost mezipaměti vyrovnávací paměti můžete rychle zkontrolovat pomocí dotazu v zobrazení V$SGAINFO. Běžně používaný dotaz dělí velikost v bajtech mocninami 1024 a prezentuje výsledek v gigabajtech, což usnadňuje porovnání s velikostí databáze a prognózami růstu. Podobné dotazy na zobrazení datového slovníku vám umožňují odhadnout logickou velikost vašich uživatelských dat.

Chcete-li ověřit, zda je aktuálně aktivní úplné ukládání do mezipaměti databáze, můžete se dotazovat na V$DATABASE a zkontrolovat sloupec FORCE_FULL_DB_CACHING. Hodnota ANO znamená, že databáze byla spuštěna s povolenou funkcí, zatímco NE znamená, že mezipaměť pracuje s obvyklou heuristikou pro malé, střední a velké tabulky.

Chování bez úplného ukládání databáze do mezipaměti: rozsáhlé prověřování a vzorce vyřazování

Uvažujme scénář se třemi tabulkami ve stejném schématu: dvě velmi velké tabulky a jedna malá. Každá velká tabulka spotřebovává přibližně 1.1 TB, zatímco malá tabulka má jen asi 1 MB. Samotná mezipaměť bufferu má jen několik gigabajtů, takže každá velká tabulka je zjevně výrazně nad 10 % mezipaměti, zatímco malá tabulka je výrazně pod prahovou hodnotou 2 %.

Po restartu nebo vyprázdnění SGA obvykle neuvidíte žádné uložené bloky pro žádnou z těchto tabulek při dotazování na záhlaví bloků z pohledů, jako je V$BH připojený k DBA_OBJECTS. Jakmile provedete úplné skenování první velké tabulky, očekává se u výchozího algoritmu, že databáze se vyhne zaplnění mezipaměti svými bloky.

Po tomto skenování si skutečně můžete všimnout, že v mezipaměti je uloženo pouze několik bloků z velké tabulky, často jen několik bloků souvisejících s metadaty. I přes zpracování milionů nebo miliard řádků se Oracle rozhodne tyto datové bloky neuchovávat, protože tabulka je vzhledem k mezipaměti rozpoznána jako „velká“ a jejich uchovávání by bylo škodlivé pro častěji používané segmenty.

Pokud pak prohledáte druhou velkou tabulku, objeví se podobný vzorec: v mezipaměti zůstává pouze malý počet jejích bloků. Databáze nadále používá svá pravidla pro práci s velkými tabulkami, čímž brání tomu, aby kterékoli z velkých tabulek dominovaly v mezipaměti. Tím je chráněna pracovní sada menších tabulek, které jsou pravděpodobně mnohem důležitější pro každodenní výkon OLTP.

Když ale konečně prohledáte malou tabulku o velikosti 1 MB, chování se dramaticky změní. Protože velikost tabulky je pod 2% prahovou hodnotou mezipaměti, Oracle dychtivě ukládá do mezipaměti všechny své bloky, takže každý budoucí přístup k této tabulce představuje čistý dopad na paměť. Z hlediska výkonu je to ideální pro malé vyhledávací tabulky a konfigurační data sdílená mezi mnoha transakcemi.

Chování s povoleným úplným ukládáním databáze do mezipaměti

Nyní si představte, že povolíte úplné ukládání databáze do mezipaměti ve stejném prostředí připojením databáze a vydáním příkazu FORCE FULL DATABASE CACHING. Po otevření databáze můžete znovu pomocí V$DATABASE ověřit, že je funkce aktivní, a poté zopakovat stejnou sekvenci skenování.

Na začátku, hned po restartu, stále nejsou k dispozici žádné bloky v mezipaměti pro tři tabulky, stejně jako předtím. Při spuštění úplného skenování první velké tabulky však nyní uvidíte téměř všechny její bloky uložené v mezipaměti vyrovnávací paměti. Místo pouhého tokenu bude v paměti uloženo prakticky všech 1.1 TB přečtených dat.

Skenování druhé velké tabulky přidá do mezipaměti vyrovnávací paměti dalších 1.1 TB bloků, aniž by došlo k odstranění dříve uložených bloků z první tabulky. Při plném ukládání databáze do mezipaměti systém efektivně „hromadí“ každý přečtený blok a pracuje za předpokladu, že paměť je pro toto chování dimenzována a že vyřazení by nemělo být nutné.

Když konečně prohledáte malou tabulku, všechny její bloky se také uloží do mezipaměti a opět se žádné bloky velkých tabulek nezahodí. Postupem času, jak se dotazy dotýkají více objektů, databáze vytváří paměťový obraz celé aktivní datové sady. Pro úlohy s velkým objemem čtení nebo smíšené úlohy, kde paměť skutečně překračuje velikost logických dat, to může zajistit vynikající výkon a vysoce předvídatelné chování mezipaměti.

Co se stane, když je povoleno úplné ukládání databáze do mezipaměti, ale není dostatek paměti

Zajímavý okrajový případ nastává, když je vynuceno úplné ukládání databáze do mezipaměti, ale mezipaměť vyrovnávací paměti je ve skutečnosti příliš malá na to, aby pojala celou pracovní datovou sadu. Nedostanete okamžitou chybu ORA-600 ani zjevnou závažnou chybu; databáze se i přes omezenou paměť stále snaží tuto funkci respektovat.

Předpokládejme, že zmenšíte mezipaměť vyrovnávací paměti tak, aby realisticky pojala pouze jednu z velkých tabulek. Po povolení úplného ukládání databáze do mezipaměti a vymazání existujících bloků se při úplném prohledávání první velké tabulky mezipaměť opět naplní téměř všemi jejími bloky. V tu chvíli je paměť v podstatě nasycena tímto jediným objektem.

Když pak prohledáte druhou velkou tabulku, Oracle se stále chová, jako by chtěl ukládat do mezipaměti vše, ale nyní musí z první tabulky vymazat bloky, aby uvolnil místo. Výsledkem je, že druhá tabulka je nakonec plně uložena v mezipaměti, zatímco první tabulka je pouze částečně rezidentní; značná část jejích bloků bude mimo mezipaměť zestárlá.

Pokud znovu prohledáte první tabulku, proces se obrátí: první tabulka se plně uloží do mezipaměti a druhá tabulka ztratí část svých bloků. Dostanete se do situace, kdy se velké objekty při každém úplném skenování navzájem vytlačují z paměti. Počet diskových vstupů/výstupů prudce vzroste a vy ztratíte většinu výhod, které mělo úplné ukládání do mezipaměti databáze poskytovat.

Z tohoto důvodu je použití úplného ukládání databáze do mezipaměti u databáze, jejíž logická velikost dat je větší než efektivní paměť, obvykle špatný nápad. V takových případech je obvykle lepší nechat Oracle aplikovat jeho osvědčené algoritmy správy vyrovnávací paměti, které chrání malé a často používané segmenty před jejich zničením nepravidelnými velkými prohledáváními.

Čisté zakázání úplného ukládání databáze do mezipaměti

Pokud se rozhodnete, že úplné ukládání databáze do mezipaměti není pro vaše prostředí vhodné, jeho zakázání je jednoduché, ale vyžaduje kontrolovaný restart. Před opětovným otevřením je nutné databázi vypnout, připojit a zadat příkaz k zastavení vynucení úplného ukládání databáze do mezipaměti.

Po opětovném otevření databáze rychlá kontrola V$DATABASE ukáže, že FORCE_FULL_DB_CACHING je nastaveno zpět na NO. Od tohoto okamžiku se mezipaměť vyrovnávací paměti vrací k výchozímu chování, kdy jsou upřednostňovány malé tabulky, střední tabulky jsou posuzovány individuálně a velké tabulky jsou většinou uchovávány mimo mezipaměť, pokud nejsou explicitně zafixovány pomocí funkcí, jako je například fond KEEP.

Široké tabulky: návrh, modelování a aspekty výkonu

Trend směrem k velmi širokým tabulkám – se stovkami nebo tisíci sloupců – mění způsob, jakým navrhujeme schémata a jak se využívají funkce, jako je úložiště sloupců v paměti a ukládání do mezipaměti. Tyto tabulky mohou zjednodušit určité vzorce náročné na čtení a usnadnit život týmům pro tvorbu reportů, ale přinášejí s sebou vážné kompromisy v oblasti flexibility, údržby a chování při I/O operacích.

Denormalizované široké tabulky mohou být skvělé, když upřednostňujete rychlé čtení a chcete se vyhnout složitým spojením, zejména pro analytiku, telemetrii nebo úložiště funkcí umělé inteligence. Zabalení mnoha atributů do jednoho řádku může snížit hloubku spojení a usnadnit dotazy, což je atraktivní pro nástroje BI, datové vědce a dávkové procesy, které chtějí pouze jeden velký záznam na entitu nebo událost.

Ne každá konceptuální entita si však zaslouží být přeměněna na monolitickou širokou tabulku. Nadměrná denormalizace může vést k řídce osídleným sloupcům, nadměrnému úložišti s hodnotami NULL a složitému DML, zejména pokud mnoho aplikací aktualizuje různé segmenty stejného megařádku. Může také skrýt chyby v modelování, kdy jsou odlišné životní cykly nebo mohutnosti vynucovány do jedné struktury.

Vyvažování pohodlí široké tabulky s rozumným designem obvykle zahrnuje kombinaci řízené denormalizace, vertikálního dělení a alternativního úložiště pro polostrukturované atributy. Například některé sady volitelných atributů lze přesunout do sloupců JSON, samostatných podřízených tabulek nebo struktur optimalizovaných pro sloupce, které jsou primárně využívány analytickými úlohami, zatímco základní transakční atributy zůstávají v štíhlejším a pro OLTP lépe optimalizovaném schématu.

Indexování širokých tabulek je další výzvou: pokus o indexování desítek nebo stovek sloupců není udržitelný. Ideálním řešením je indexovat pouze predikáty, které se často objevují v klauzulích WHERE nebo podmínkách JOIN, a pro složitější analytické přístupové cesty se spoléhat na sloupcové funkce v paměti, prořezávání oddílů a materializované pohledy.

Dělení, materializované pohledy a komprese pro velké široké tabulky

U rozsáhlých tabulek, které obsahují miliardy řádků, je dělení na oddíly téměř nezbytné, aby se udržel výkon a údržba pod kontrolou. Rozsahové, seznamové nebo složené oddíly umožňují cílit na podmnožiny dat pro dotazy, shromažďování statistik a úklidové operace, čímž se snižuje jak I/O operace, tak i kolize.

Dělení na oddíly může dále upřesnit, jak jsou data rozložena v úložišti a mezipaměti vyrovnávací paměti. Například kombinace rozsahu a hash může rovnoměrněji rozdělit aktivní podmnožiny, zatímco nastavení seznamu a rozsahu se mohou úzce shodovat s obchodní sémantikou (například region plus datum). Při použití úložišť sloupců v paměti můžete na úrovni oddílu nebo pododdílu rozhodnout, které části jsou způsobilé pro optimalizaci v paměti.

Materializované pohledy jsou dalším účinným způsobem, jak usnadnit správu širokých tabulek pro analytické účely. Místo toho, abyste pokaždé naráželi na obrovskou základní tabulku, můžete předpočítat agregované nebo doménově specifické projekce, které jsou mnohem užší a snáze se ukládají do mezipaměti. Tyto virtuální projekce (MV) lze aktualizovat pravidelně nebo na vyžádání, což podporuje dotazy a dashboardy BI s mnohem menším využitím zdrojů.

Komprese hraje také klíčovou roli, a to jak na disku, tak v paměti, zejména když mnoho sloupců obsahuje opakující se nebo řídké hodnoty. Pokročilé algoritmy komprese a komprese v paměti od společnosti Oracle mohou výrazně snížit nároky na úložiště a zrychlit skenování zmenšením množství dat, která je třeba číst. Nevýhodou je dodatečné využití procesoru, ale s moderními procesory a vektorizovanými instrukcemi to může být pro mnoho analytických úloh čistý zisk.

Provozní a AI/analytické důsledky velmi širokých tabulek

Kromě čistého výkonu mají široké tabulky i provozní důsledky, které ovlivňují okna zálohování, replikace a údržby. Obrovské množství řádků zvyšuje náklady na hromadné kopie, logické exporty a následné replikační procesy. Jakákoli změna struktury, jako je přidání nebo odstranění sloupců, vyžaduje hlubší analýzu, aby se předešlo neočekávaným dopadům na nástroje a kanály.

Monitorování a pozorovatelnost se stávají kritickými, když jsou široké tabulky jádrem vaší architektury. Musíte sledovat nejen využití CPU a paměti, ale také poměry přístupů do mezipaměti, tlak na tabulkový prostor a chování úložišť v paměti při realistických pracovních zátěžích. Zátěžové testování před spuštěním je nezbytné pro odhalení aktivních míst a možnosti ladění v oblasti dělení, ukládání do mezipaměti a indexování.

Z pohledu umělé inteligence a pokročilé analytiky se široké tabulky často používají jako úložiště funkcí nebo analytické pohledy, které zásobují modely strojového učení a inteligentní agenty. Díky velkému množství atributů na jednom místě se zjednodušuje extrakce vektorů rysů a snižuje se složitost předzpracování, zejména v kombinaci se sloupcovým úložištěm a SIMD-akcelerovaným skenováním.

Zároveň případy použití s ​​vysokým podílem umělé inteligence přinášejí další obavy ohledně správy dat, zabezpečení a dodržování předpisů. Když agregujete mnoho citlivých atributů do jedné široké struktury, zvyšujete dosah jakékoli nesprávné konfigurace přístupu. Správné řízení přístupu na základě rolí, maskování dat a audit se stávají nezbytnými, zejména v regulovaných odvětvích.

Specializované konzultační společnosti a interní architektonické týmy mohou přinést významnou hodnotu tím, že pomohou organizacím rozhodnout se, kdy jsou široké tabulky skutečně tou správnou volbou a kdy se lépe škálují alternativní vzory. To zahrnuje poradenství v oblasti nasazení více cloudů v rámci AWS a Azure, integraci s platformami BI, jako je Power BI, a návrh bezpečných a výkonných datových kanálů, které propojují provozní databáze s analytickými a AI službami.

Rozsáhlé mazání s omezenými oprávněními: dávkové strategie

Jeden často přehlížený aspekt práce s gigantickými tabulkami – ať už širokými, nebo ne – je, jak bezpečně smazat velké části dat, když jste omezeni omezenými oprávněními. V mnoha podnicích nemohou správci databází volně spouštět DDL, vytvářet nové oddíly ani restrukturalizovat objekty v produkčním prostředí; mohou provádět pouze operace DML, jako je DELETE a v některých případech TRUNCATE.

Vydání jediného masivního příkazu DELETE, který eliminuje třetinu tabulky s několika miliardami řádků, je receptem na vyčerpání tabulkového prostoru a dlouhodobé transakce. Takové operace mohou zadržovat uzamčení řádků celé hodiny, narušovat využití funkcí UNDO a TEMP a v případě, že se v průběhu operace něco pokazí, učinit dobu obnovy nepřijatelně dlouhou.

Běžnou strategií pro zmírnění rizik je mazání v kontrolovaných dávkách pomocí PL/SQL s BULK COLLECT a FORALL. Vzor spočívá v otevření kurzoru výběrem ROWID, které splňují predikát mazání, jejich načtením po částech o pevné velikosti (například 100 000 řádků najednou), hromadným smazáním těchto řádků, potvrzením a následným opakováním, dokud není kurzor vyčerpán. Každá iterace spotřebuje zvládnutelné množství operací zpět a udržuje malé okno transakce.

Tento inkrementální přístup snižuje zátěž tabulkového prostoru pro vrácení zpět a poskytuje předvídatelnější postup, ale za cenu nutnosti vícenásobných commitů. V situacích, kdy se nemůžete spolehnout na dělení nebo online redefinici tabulek, je to často nejpragmatičtější možnost. Velikost LIMIT můžete upravit na základě pozorovaného využití vrácení zpět, možností I/O a přijatelné doby trvání transakce.

V ideálním případě, pokud byste měli rozsáhlejší oprávnění, byste mohli preferovat strategie založené na oddílech, jako je například odstranění nebo zkrácení oddílů, aby se historická data téměř okamžitě vymazala. Dalšími možnostmi by mohlo být vytvoření nové tabulky pouze s řádky, které chcete zachovat, a jejich nahrazení. Ale když DDL tabulku nepoužíváte, pečlivě naprogramované dávkové mazání zůstává hlavním nástrojem ve vaší sadě.

Spojením všech těchto vláken dohromady – inteligentních algoritmů ukládání do mezipaměti, úplného ukládání do mezipaměti databáze, sloupcových formátů v paměti, návrhu s rozsáhlými tabulkami, dělení na oddíly, komprese a provozních postupů pro hromadnou údržbu – získáte ucelený mentální model toho, jak může Oracle podporovat extrémně náročné úlohy. Když je velikost paměti v souladu s objemem databáze a návrh schématu respektuje potřeby OLTP i analytických procesů, můžete poskytovat analýzy v kratším čase než sekundu, stabilní transakční výkon a spolehlivé datové kanály umělé inteligence na základě velmi rozsáhlých tabulek uložených zcela nebo z velké části v paměti.