Oracle In-Memory Wide Tabels dhe Deep Dive i plotë i Caching-ut të Bazës së të Dhënave

Kryesore » Piton » Oracle In-Memory Wide Tabels dhe Deep Dive i plotë i Caching-ut të Bazës së të Dhënave

Të punosh me tabela të gjera të ruajtura plotësisht në memorien e Oracle mund të të ndiejë si të ngasësh një makinë të Formula 1: tepër e shpejtë kur gjithçka është e akorduar, dhe dhimbshëm e pamëshirshme kur diçka nuk shkon. Ndërsa bazat e të dhënave evoluojnë drejt skemave me qindra apo edhe mijëra kolona, ​​qasja jonë ndaj modelimit, ruajtjes në memorje dhe pyetjeve të të dhënave duhet të ndryshojë. Oracle ofron veçori të fuqishme të memorjes në memorje dhe në memorjen e përkohshme, por ato shkëlqejnë vetëm nëse kuptojmë se si i trajtojnë ato tabelat e vogla, të mesme dhe të mëdha dhe si ndërveprojnë këto me dizajnin e tabelave të gjera.

Ky udhëzues shpjegon se si Oracle trajton formatet në memorie, ruajtjen e plotë në memorien e bazës së të dhënave dhe implikimet praktike të tabelave shumë të gjera për analizat, ngarkesat e punës OLTP dhe operacionet. Gjatë rrugës, do të shihni se si algoritmet e memorjes së përkohshme (cache) evoluan përtej LRU-së së thjeshtë, pse Oracle i trajton ndryshe tabelat e mëdha, kur ka kuptim ruajtja e plotë e bazës së të dhënave në memorien e përkohshme dhe si ndikon e gjithë kjo në strategjinë e indeksimit, ndarjen, ngarkesat e punës së inteligjencës artificiale/analitike dhe madje edhe fshirjet në shkallë të gjerë nën kufizime të rrepta sigurie.

Formati kolonar në memorie dhe skanimi SIMD në Oracle

Oracle Database In-Memory prezanton një përfaqësim kolonor të projektuar posaçërisht për skanime, bashkime dhe agregime jashtëzakonisht të shpejta në memorie. Në vend që të lexojë rreshta të plotë nga blloqet e orientuara në disk, Oracle mund të ruajë objektet e zgjedhura në një depo kolonash në memorie ku çdo kolonë është e kompresuar dhe e optimizuar për pyetje analitike që prekin shumë rreshta, por relativisht pak kolona.

Për më tepër, Oracle shfrytëzon përpunimin vektorial SIMD (Udhëzim i Vetëm, të Dhëna të Shumëfishta) në nivelin e CPU-së për të përpunuar miliarda rreshta në sekondë për çdo bërthamë për ngarkesa pune të përshtatshme. Kur pyetjet janë kryesisht vetëm për lexim dhe përfshijnë filtra diapazoni, agregime dhe funksione analitike, baza e të dhënave mund të vlerësojë vlera të shumëfishta paralelisht brenda një udhëzimi të vetëm të CPU-së, duke rritur ndjeshëm rendimentin krahasuar me ekzekutimin konvencional rresht pas rreshti.

Për tabelat e gjera kjo ka shumë rëndësi, sepse formati tradicional i bazuar në rreshta bën që çdo lexim të paguajë për të gjitha kolonat në bllok, edhe kur pyetja prek vetëm një pjesë të vogël të tyre. Kur aktivizohen tabela ose ndarje të caktuara të gjera për ruajtjen e kolonave në memorie, Oracle mund t'i anashkalojë plotësisht kolonat e parëndësishme, duke zvogëluar përdorimin e bandwidth-it të memories dhe punën e CPU-së, gjë që është kritike për analizat dhe panelet në kohë reale.

Në praktikë, kjo do të thotë që analizat që më parë zgjasnin orë të tëra, shpesh mund të reduktohen në sekonda, duke mundësuar vendimmarrje pothuajse në kohë reale mbi të dhënat operative. Raportet mbi tabelat masive të fakteve, hetimet ad-hoc të telemetrisë dhe pyetjet e inteligjencës së biznesit përfitojnë nga kombinimi i kompresimit, aksesit kolonar dhe përpunimit të vektorizuar kur konfigurohen saktë.

Nga LRU bazë te algoritmet më të zgjuara të memorjes së përkohshme të bufferit (buffer cache)

Para se të hyjmë në ruajtjen e plotë të bazës së të dhënave në memorje, është e dobishme të kuptojmë se si Oracle vendosi historikisht se cilat blloqe qëndrojnë në memorjen e bufferit dhe cilat hiqen. Në versionet e hershme, Oracle mbështetej në një listë të drejtpërdrejtë LRU (Last Recently Used - Përdorur së Fundmi): kur memoria e përkohshme e bufferit mbushej, blloqet e përdorura më pak së fundmi në fund të listës hidheshin poshtë për të krijuar vend për të reja.

Problemi me qasjen naive të LRU është grindja dhe padrejtësia nën ngarkesa të përziera pune OLTP. Sa herë që prekej një bllok, ai duhej të zhvendosej në fundin "e nxehtë" të listës. Nën akses të dendur të njëkohshëm, shumë seanca që konkurronin për të promovuar blloqe e shndërruan atë rajon të listës në një pikë të nxehtë. Përveç kësaj, një skanim i plotë i një tabele të madhe mund të shtynte një valë të madhe blloqesh në krye të listës, duke i nxjerrë me shpejtësi blloqet vërtet të nxehta nga tabelat më të vogla të aksesueshme shpesh.

Për ta adresuar këtë, Oracle evoluoi algoritmin e memories së përkohshme të bufferit duke shtuar një numërues përdorimi dhe një pullë kohore në secilin bllok, në vend që të zhvendoste verbërisht çdo bllok të prekur në krye. Sa herë që aksesohet një bllok, numëruesi i tij rritet dhe koha e përdorimit të tij të fundit përditësohet. Një numërues i lartë sugjeron që blloku është i popullarizuar, por kohëzgjatja e fundit e vulës kohore ende ka rëndësi; një bllok i përdorur shumë një orë më parë, por jo që atëherë, mund të mos jetë aq i vlefshëm sa diçka që goditet vazhdimisht në sekondat e fundit.

Vendimi për dëbim bazohet, pra, në një kombinim të shpeshtësisë dhe kohëve të fundit të përdorimit të një blloku. Oracle i balancon këto dy dimensione në mënyrë që blloqet e lexuara intensivisht në një periudhë shumë të shkurtër të mos dominojnë gjithmonë mbi blloqet që kanë një model aksesi më të moderuar, por të qëndrueshëm. Kjo strategji hibride zbut rastet patologjike të krijuara nga skanimet e mëdha dhe zvogëlon grindjet rreth anës "të nxehtë" të memorjes së përkohshme.

Si i trajton Oracle tabelat e vogla, të mesme dhe të mëdha në memorjen buffer

Meqenëse memoria nuk është e pafundme, Oracle zbaton strategji të ndryshme të ruajtjes në memorje në varësi të madhësisë relative të një tabele krahasuar me memorjen totale të buffer-it. Kjo është thelbësore kur keni të bëni me tabela të gjera ose me tabela faktesh shumë të mëdha që mund ta tejkalojnë lehtësisht memorien tuaj të disponueshme.

Për tabela të vogla, Oracle është shumë miqësor me memorien cache. Kur madhësia totale e një tabele është më pak se afërsisht 2% e memorjes së përkohshme të buffer-it, Oracle zakonisht do të ruajë në memorje të gjitha blloqet e saj pasi të lexohen, duke e mbajtur të gjithë tabelën në memorie. Tabelat e vogla të kërkimit dhe të dhënat referuese shpesh bien në këtë kategori, gjë që është ideale sepse ato aksesohen shpesh dhe përfitojnë shumë nga ruajtja e plotë në memorje.

Tabelat me madhësi mesatare renditen në një kategori më të nuancuar, shpesh diku midis 2% dhe rreth 10% të memorjes së përkohshme të bufferit, megjithëse pragjet e sakta mund të ndryshojnë. Për këto, Oracle merr në konsideratë disa sinjale përpara se të vendosë nëse do t'i ruajë blloqet në mënyrë agresive: kur tabela është skanuar plotësisht për herë të fundit, sa kohë janë përdorur blloqet që ndodhen tashmë në memorje, sa hapësirë ​​e lirë ekziston në memorjen e përkohshme të buffer-it dhe madhësia e tabelës. Me fjalë të tjera, tabelat e mesme trajtohen me një vendim kosto-përfitim bazuar si në madhësinë e objektit ashtu edhe në modelet e aksesit.

Tabelat e mëdha, veçanërisht ato madhësia e të cilave tejkalon shumë 10% të memorjes së përkohshme të bufferit, trajtohen në mënyrë shumë konservative si parazgjedhje. Oracle në përgjithësi do të shmangë popullimin e memorjes së përkohshme të bufferit me të gjitha blloqet e tyre pas një skanimi të plotë, sepse duke vepruar kështu mund të fshihen të dhëna vërtet të nxehta nga tabela më të vogla, të cilat qasen shpesh. Mund të shihni disa meta-data ose një grusht blloqesh të dhënash në memorje, por tabelat e mëdha nuk ruhen plotësisht në memorje, përveç nëse i jepni udhëzime të qarta Oracle-it duke përdorur mekanizma si grupi i bufferit KEEP ose direktiva të tjera.

Kjo strategji është veçanërisht e rëndësishme kur punohet me tabela të gjera faktesh që mund të përfshijnë gigabajt ose terabajt. Një skanim i vetëm javor ose mujor i një tabele të tillë nuk duhet ta nxjerrë të gjithë grupin e punës OLTP nga memoria. Në vend të kësaj, Oracle i jep përparësi objekteve që ofrojnë përfitimin më të lartë për shumicën e pyetjeve.

Ruajtja e plotë e të dhënave në memorje: kur gjithçka futet në memorie

Memoria e plotë e bazës së të dhënave në cache, e prezantuar në Oracle Database 12.1.0.2, është projektuar për mjedise ku memoria e përkohshme e bufferit është mjaftueshëm e madhe për të mbajtur madhësinë logjike të të gjithë bazës së të dhënave. Në këtë skenar, zbatimi i rregullave komplekse të dëbimit për tavolina të mëdha kundrejt atyre të vogla nuk ka më kuptim; nëse gjithçka përshtatet, qëllimi është ta mbajmë aty.

Kur aktivizohet ruajtja e plotë e të dhënave në memorje, Oracle supozon se të gjitha blloqet e lexuara nga të dhënat e përdoruesit mund dhe duhet të mbeten në memorie. Dallimet klasike midis objekteve të vogla, të mesme dhe të mëdha injorohen kryesisht në lidhje me ruajtjen në memorje; çdo tabelë që lexoni, pavarësisht se sa e gjerë ose e madhe është, do të ketë blloqet e saj të ruajtura në memorjen e përkohshme të bufferit ndërsa ato aksesohen, deri në kufijtë fizikë të memories.

Është e rëndësishme të theksohet se aktivizimi i Caching-ut të Plotë të Bazës së të Dhënave nuk i lexon menjëherë të gjitha blloqet e të gjitha objekteve në memorie. Në vend të kësaj, sillet në mënyrë oportuniste: ndërsa aplikacionet kërkojnë tabela dhe segmente, blloqet e aksesuara ruhen në memorje dhe më pas mbahen në vend që të zëvendësohen bazuar në heuristikat më të vjetra. Me kalimin e kohës, ndërsa ngarkesat e punës prekin më shumë një pjesë të bazës së të dhënave, memorja e përkohshme e bufferit konvergon në një gjendje ku i gjithë grupi i të dhënave është rezident në memorie.

Në mjediset me shumë qiramarrës, nëse aktivizoni ruajtjen e plotë të bazës së të dhënave në memorjen specifike në nivelin CDB, sjellja shtrihet në të gjitha PDB-të në atë bazë të dhënash kontejner. Kjo do të thotë që çdo bazë të dhënash e lidhshme nën atë kontejner mund të përfitojë nga kjo veçori dhe nuk mund ta aktivizoni ose çaktivizoni atë në mënyrë selektive për çdo rast brenda një konfigurimi RAC; është një veti gjithçka-ose-asgjë e bazës së të dhënave.

Një efekt tjetër delikat, por i rëndësishëm, është se edhe segmentet e shënuara si NOCACHE, duke përfshirë segmentet LOB, përfundojnë të ruajtura në memorien e përkohshme kur detyrohet ruajtja e plotë e memories së bazës së të dhënave. Baza e të dhënave në mënyrë efektive anashkalon sugjerimet e zakonshme të ruajtjes në memorje në nivel objekti, sepse supozimi global është se memoria është e mjaftueshme për të mbajtur gjithçka.

Rregullat e madhësisë dhe kontrollet për ruajtjen e plotë të bazës së të dhënave në memorje

Para se të aktivizoni Ruajtjen e Plotë të Memorjes së Bazës së të Dhënave, duhet të konfirmoni që memoria juaj e përkohshme e bufferit është vërtet mjaftueshëm e madhe për ngarkesën e punës së bazës së të dhënave. Oracle bën dallimin midis bazave të të dhënave me një instancë të vetme dhe Grumbujve të Aplikacioneve Reale (RAC) kur kontrollon fizibilitetin.

Për një bazë të dhënash jo-RAC, madhësia logjike e bazës së të dhënave duhet të jetë më e vogël se madhësia totale e memorjes së përkohshme të bufferit. Madhësia logjike këtu i referohet të dhënave që realisht duhet të ruhen në memorien e përkohshme për ngarkesën tuaj të punës, jo domosdoshmërisht çdo bajt të fundit të informacionit arkivor të përdorur rrallë. Megjithatë, në praktikë, ju dëshironi një diferencë të rehatshme në mënyrë që rritja dhe rritjet e aktivitetit të mos e thyejnë papritur supozimin se "gjithçka përshtatet".

Në mjediset RAC, rregulli është më i rreptë dhe duhet të zbatohet si në nivelin e instancës ashtu edhe në atë të klasterit. Madhësia logjike e bazës së të dhënave duhet të jetë më e vogël se madhësia e memorjes së përkohshme të çdo instance individuale, dhe gjithashtu më pak se afërsisht 80% e shumës së memorjeve të përkohshme të të gjitha instancave në klaster. Ky kufizim i dyfishtë siguron që asnjë instancë e vetme të mos bëhet pengesë, ndërsa klasteri në tërësi përfiton ende nga kjo veçori.

Mund të kontrolloni shpejt madhësinë aktuale të memorjes së përkohshme të bufferit duke përdorur një pyetje kundrejt pamjes V$SGAINFO. Një pyetje e përdorur zakonisht e ndan madhësinë në bajt me fuqitë 1024 për të paraqitur rezultatin në gigabajt, duke e bërë më të lehtë krahasimin me madhësinë e bazës së të dhënave dhe parashikimet e rritjes. Pyetje të ngjashme me pamjet e fjalorit të të dhënave ju lejojnë të vlerësoni madhësinë logjike të të dhënave të përdoruesit tuaj.

Për të verifikuar nëse Full Database Caching është aktualisht aktiv, mund të bëni një pyetje në V$DATABASE dhe të inspektoni kolonën FORCE_FULL_DB_CACHING. Një vlerë PO tregon që baza e të dhënave është nisur me funksionin e aktivizuar, ndërsa JO do të thotë që memoria e përkohshme po funksionon sipas heuristikave të zakonshme për tabela të vogla, të mesme dhe të mëdha.

Sjellje pa ruajtje të plotë të bazës së të dhënave në memorje: skanime të mëdha dhe modele nxjerrjeje nga përdorimi

Shqyrtoni një skenar me tre tabela në të njëjtën skemë: dy tabela shumë të mëdha dhe një e vogël. Çdo tabelë e madhe konsumon rreth 1.1 TB, ndërsa tabela e vogël është vetëm rreth 1 MB. Vetë memoria e përkohshme e bufferit është vetëm disa gigabajt, kështu që çdo tabelë e madhe është qartësisht shumë mbi 10% të memorjes së përkohshme, ndërsa tabela e vogël është shumë nën pragun prej 2%.

Pas rinisjes ose pastrimit të SGA-së, zakonisht nuk do të shihni blloqe të ruajtura në memorien e përkohshme për asnjë nga këto tabela kur pyetni titujt e blloqeve nga pamje si V$BH të bashkuara me DBA_OBJECTS. Pasi të kryeni një skanim të plotë të tabelës në tabelën e parë të madhe, pritja me algoritmin e parazgjedhur është që baza e të dhënave do të shmangë mbushjen e memorjes së përkohshme me blloqet e saj.

Në të vërtetë, pas këtij skanimi, mund të vëreni se vetëm një numër i vogël blloqesh për tabelën e madhe ruhen në memorien e përkohshme, shpesh vetëm disa blloqe që lidhen me meta-të dhënat. Pavarësisht përpunimit të miliona ose miliarda rreshtave, Oracle zgjedh të mos i mbajë ato blloqe të dhënash sepse tabela njihet si "e madhe" në krahasim me memorien e përkohshme, dhe mbajtja e tyre do të ishte e dëmshme për segmentet që përdoren më shpesh.

Nëse më pas skanoni tabelën e dytë të madhe, shfaqet një model i ngjashëm: vetëm një numër i vogël i blloqeve të saj mbeten të ruajtura në memorien e përkohshme. Baza e të dhënave vazhdon të zbatojë rregullat e saj të trajtimit të tabelave të mëdha, duke parandaluar që secila prej tabelave të mëdha të dominojë memorien e përkohshme. Kjo mbron grupin e punës të tabelave më të vogla që ka të ngjarë të jenë shumë më kritike për performancën e përditshme të OLTP.

Megjithatë, kur më në fund skanoni tabelën e vogël 1 MB, sjellja ndryshon në mënyrë dramatike. Meqenëse madhësia e tabelës është nën pragun prej 2% të memorjes së përkohshme të bufferit, Oracle i ruan me padurim të gjitha blloqet e saj në memorje, duke e bërë çdo qasje të ardhshme në atë tabelë një goditje të pastër në memorie. Nga një perspektivë e performancës, kjo është ideale për tabela të vogla kërkimi dhe të dhëna konfigurimi të ndara në shumë transaksione.

Sjellje me ruajtjen e plotë të bazës së të dhënave në memorje të aktivizuar

Tani imagjinoni aktivizimin e Full Database Caching në të njëjtin mjedis duke montuar bazën e të dhënave dhe duke lëshuar një komandë FORCE FULL DATABASE CACHING. Pas hapjes së bazës së të dhënave, mund të konfirmoni përsëri nëpërmjet V$DATABASE që funksioni është aktiv përpara se të përsërisni të njëjtën sekuencë skanimesh.

Në fillim, menjëherë pas një rinisjeje, ende nuk ka blloqe të ruajtura në memorien e përkohshme për të tre tabelat, njësoj si më parë. Megjithatë, ndërsa kryeni një skanim të plotë të tabelës në tabelën e parë të madhe, tani do të shihni pothuajse të gjitha blloqet e saj që ndodhen në memorjen e përkohshme të buffer-it. Në vend të vetëm një pranie simbolike, praktikisht të gjitha 1.1 TB të dhënash që u lexuan do të mbahen në memorie.

Skanimi i tabelës së dytë të madhe shton edhe 1.1 TB blloqe të tjera në memorjen e përkohshme të bufferit, pa hequr blloqet e ruajtura më parë nga tabela e parë. Sipas Ruajtjes së Plotë të Bazës së të Dhënave në Memorje, sistemi në mënyrë efektive "grumbullon" çdo bllok që lexohet, duke punuar nën supozimin se memoria është e madhësisë për këtë sjellje dhe se nxjerrja jashtë nuk duhet të jetë e nevojshme.

Kur më në fund skanoni tabelën e vogël, të gjitha blloqet e saj ruhen gjithashtu në memorien e përkohshme dhe, përsëri, asnjë bllok i tabelave të mëdha nuk hidhet poshtë. Me kalimin e kohës, ndërsa pyetjet prekin më shumë objekte, baza e të dhënave ndërton një imazh memorieje të të gjithë të dhënave aktive. Për ngarkesa pune me shumë lexim ose të përziera ku memoria tejkalon vërtet madhësinë logjike të të dhënave, kjo mund të ofrojë performancë të shkëlqyer dhe sjellje shumë të parashikueshme të memorjes së përkohshme.

Çfarë ndodh kur aktivizohet ruajtja e plotë e të dhënave në memorje, por memoria nuk është e mjaftueshme?

Një rast interesant anësor lind kur detyrohet aktivizimi i plotë i memorjes së bazës së të dhënave, por memoria e memorjes së përkohshme të bufferit është në të vërtetë shumë e vogël për të mbajtur të gjithë grupin e të dhënave funksionale. Nuk do të merrni menjëherë një gabim ORA-600 ose një gabim të dukshëm brutal; baza e të dhënave ende përpiqet ta respektojë veçorinë ndërsa merret me limitin e fortë të memories.

Supozoni se e zvogëloni memorjen e përkohshme të bufferit në mënyrë të tillë që ajo të mund të mbajë realisht vetëm njërën nga tabelat e mëdha plotësisht. Pas aktivizimit të Ruajtjes së Plotë të të Dhënave në Memorje të Vogël dhe pastrimit të blloqeve ekzistuese, një skanim i plotë i tabelës së parë të madhe do ta mbushë përsëri memorjen e përkohshme me pothuajse të gjitha blloqet e saj. Në atë moment, memoria është në thelb e ngopur nga ai objekt i vetëm.

Kur skanoni tabelën e dytë të madhe, Oracle ende sillet sikur dëshiron të ruajë gjithçka në memorien e përkohshme, por tani duhet të heqë blloqet nga tabela e parë për të liruar vend. Rezultati është se tabela e dytë përfundon e ruajtur plotësisht në memorien e përkohshme, ndërsa tabela e parë është vetëm pjesërisht e ruajtur; një pjesë e konsiderueshme e blloqeve të saj do të jenë hequr nga memoria e përkohshme.

Nëse e skanoni përsëri tabelën e parë, procesi përmbyset: tabela e parë ruhet plotësisht në memorien e përkohshme dhe tabela e dytë humbet një pjesë të blloqeve të saj. Përfundoni në një skenar të dobët ku objektet e mëdha i humbasin kujtesën njëri-tjetrit pas çdo skanimi të plotë. Hyrjet/Daljet e diskut rriten ndjeshëm dhe humbni pjesën më të madhe të përfitimit që kishte për qëllim të ofronte Full Database Caching.

Për këtë arsye, përdorimi i ruajtjes së plotë të bazës së të dhënave në memorjen e përkohshme në një bazë të dhënash, madhësia logjike e të dhënave të së cilës është më e madhe se memoria juaj efektive është zakonisht një ide e keqe. Në raste të tilla, zakonisht është më mirë ta lini Oracle të aplikojë algoritmet e saj të provuara dhe të vërteta të menaxhimit të buffer-ave, të cilat mbrojnë segmentet e vogla dhe të përdorura shpesh nga shkatërrimi nga skanimet e mëdha dhe të rralla.

Çaktivizimi i plotë i ruajtjes në memorje të bazës së të dhënave në mënyrë të pastër

Nëse vendosni që ruajtja e plotë e bazës së të dhënave në memorien e përkohshme nuk është e përshtatshme për mjedisin tuaj, çaktivizimi i saj është i thjeshtë, por kërkon një rinisje të kontrolluar. Duhet ta mbyllni bazën e të dhënave, ta montoni atë dhe të jepni komandën për të ndaluar ruajtjen e plotë në memorje të bazës së të dhënave përpara se ta hapni përsëri.

Pasi të rihapet baza e të dhënave, një kontroll i shpejtë i V$DATABASE do të tregojë se FORCE_FULL_DB_CACHING është vendosur përsëri në NO. Nga ajo pikë e tutje, memoria e përkohshme e bufferit kthehet në sjelljen e saj të paracaktuar, ku tabelat e vogla favorizohen, tabelat mesatare konsiderohen rast pas rasti dhe tabelat e mëdha mbahen kryesisht jashtë memorjes së përkohshme, përveç nëse fiksohen në mënyrë të qartë nëpërmjet veçorive si grupi KEEP.

Tabelat e gjera: konsideratat e dizajnit, modelimit dhe performancës

Trendi drejt tabelave shumë të gjera - me qindra ose mijëra kolona - ndryshon mënyrën se si i projektojmë skemat dhe si shfrytëzohen veçori të tilla si ruajtja e kolonave në memorie dhe ruajtja në memorje. Këto tabela mund të thjeshtojnë disa modele që kërkojnë shumë lexim dhe ta bëjnë jetën më të lehtë për ekipet e raportimit, por ato vijnë me kompromise serioze në fleksibilitet, mirëmbajtje dhe sjellje të IO-së.

Tabelat e gjera të denormalizuara mund të jenë të shkëlqyera kur u jepni përparësi leximeve të shpejta dhe dëshironi të shmangni bashkimet e ndërlikuara, veçanërisht për analizat, telemetrinë ose dyqanet e veçorive të IA-së. Paketimi i shumë atributeve në një rresht të vetëm mund të zvogëlojë thellësinë e bashkimit dhe t'i bëjë pyetjet më të thjeshta, gjë që është tërheqëse për mjetet e inteligjencës së biznesit, shkencëtarët e të dhënave dhe proceset grumbulluese që duan vetëm një rekord të madh për entitet ose ngjarje.

Megjithatë, jo çdo entitet konceptual meriton të shndërrohet në një tabelë të gjerë monolitike. Denormalizimi i tepërt mund të çojë në kolona me popullsi të rrallë, ruajtje të tepërt të të dhënave NULL dhe DML komplekse, veçanërisht nëse shumë aplikacione përditësojnë feta të ndryshme të të njëjtit mega-rresht. Gjithashtu mund të fshehë gabimet e modelimit ku ciklet e jetës ose kardinalitetet e dallueshme detyrohen të futen në një strukturë të vetme.

Balancimi i komoditetit të një tavoline të gjerë me dizajnin e shëndoshë zakonisht përfshin një përzierje të denormalizimit të kontrolluar, ndarjes vertikale dhe ruajtjes alternative për atributet gjysmë të strukturuara. Për shembull, disa grupe atributesh opsionale mund të zhvendosen në kolona JSON, tabela të veçanta fëmijësh ose struktura të optimizuara për kolona, ​​të shfrytëzuara kryesisht nga ngarkesat e punës analitike, ndërsa atributet kryesore transaksionale mbeten në një skemë më të thjeshtë dhe më miqësore me OLTP.

Indeksimi i tabelave të gjera është një sfidë tjetër: përpjekja për të indeksuar dhjetëra ose qindra kolona nuk është e qëndrueshme. Pika ideale është të indeksohen vetëm predikatet që shfaqen shpesh në klauzolat WHERE ose kushtet JOIN, dhe të mbështeten në veçoritë koloniale në memorie, shkurtimin e ndarjeve dhe pamjet e materializuara për shtigje aksesi analitike më komplekse.

Ndarja, pamjet e materializuara dhe kompresimi për tabela të mëdha e të gjera

Për tabela të gjera që përmbajnë miliarda rreshta, ndarja është pothuajse e detyrueshme për të mbajtur nën kontroll performancën dhe mirëmbajtjen. Ndarjet e diapazonit, listës ose të përbëra ju lejojnë të synoni nëngrupe të të dhënave për pyetje, mbledhje statistikash dhe operacione mirëmbajtjeje, duke zvogëluar si I/O ashtu edhe grindjet.

Nën-ndarja mund të përsosë më tej mënyrën se si shpërndahen të dhënat nëpër memorien e përkohshme dhe në memorjen e përkohshme të bufferit. Për shembull, një kombinim diapazon-hash mund të shpërndajë nëngrupet e nxehta në mënyrë më të barabartë, ndërsa konfigurimet listë-diapazon mund të përputhen ngushtë me semantikën e biznesit (siç është rajoni plus data). Kur përdorni depozita kolonash në memorie, mund të vendosni në nivelin e ndarjes ose nënndarjes se cilat pjesë janë të përshtatshme për optimizim në memorie.

Pamjet e materializuara janë një mënyrë tjetër e fuqishme për t'i bërë tabelat e gjera të menaxhueshme për analiza. Në vend që të shkoni në tabelën bazë monstruoze çdo herë, mund të parallogaritni projeksione të agreguara ose specifike për domenin që janë shumë më të ngushta dhe më të lehta për t'u ruajtur në memorje. Këto MV mund të rifreskohen periodikisht ose sipas kërkesës, duke mbështetur pyetjet dhe panelet e biznesit të biznesit me përdorim shumë më të lehtë të burimeve.

Kompresimi gjithashtu luan një rol vendimtar, si në disk ashtu edhe në memorie, veçanërisht kur shumë kolona kanë vlera përsëritëse ose të rralla. Algoritmet e avancuara të kompresimit dhe kompresimit në memorie të Oracle mund të zvogëlojnë ndjeshëm gjurmët e ruajtjes dhe të përshpejtojnë skanimet duke zvogëluar sasinë e të dhënave që duhen lexuar. Kompromisi është puna shtesë e CPU-së, por me procesorët modernë dhe udhëzimet e vektorizuara, kjo mund të jetë një fitore neto për shumë ngarkesa pune analitike.

Implikimet operacionale dhe të inteligjencës artificiale/analitike të tabelave shumë të gjera

Përtej performancës së pastër, tabelat e gjera kanë pasoja operative që ndikojnë në dritaret e kopjimit të kopjeve rezervë, replikimit dhe mirëmbajtjes. Rreshtat masivë rrisin koston e kopjeve në masë, eksporteve logjike dhe proceseve të replikimit në rrjedhën e poshtme. Çdo ndryshim në strukturë, siç është shtimi ose heqja e kolonave, ka nevojë për analizë më të thellë për të shmangur efektet e papritura anësore në mjete dhe kanale.

Monitorimi dhe vëzhgueshmëria bëhen kritike kur tabelat e gjera janë në thelb të arkitekturës suaj. Duhet të gjurmoni jo vetëm përdorimin e CPU-së dhe të memories, por edhe raportet e goditjeve të memorjes së përkohshme të buffer-it, të anuloni presionin e hapësirës së tabelave dhe sjelljen e depove në memorie nën ngarkesa pune realiste. Testimi i ngarkesës përpara se të vihet në punë është thelbësor për të zbuluar pikat e nxehta dhe për të akorduar mundësi rreth ndarjes, ruajtjes në memorien e përkohshme dhe indeksimit.

Nga një perspektivë e inteligjencës artificiale dhe analitikës së avancuar, tabelat e gjera shpesh përdoren si dyqane veçorish ose pamje analitike që ushqejnë modelet e të mësuarit automatik dhe agjentët inteligjentë. Të kesh shumë atribute në një vend të vetëm thjeshton nxjerrjen e vektorëve të karakteristikave dhe zvogëlon kompleksitetin e para-përpunimit, veçanërisht kur kombinohet me ruajtje kolonare dhe skanime të përshpejtuara nga SIMD.

Në të njëjtën kohë, rastet e përdorimit të rëndë të inteligjencës artificiale sjellin shqetësime shtesë në lidhje me qeverisjen e të dhënave, sigurinë dhe pajtueshmërinë. Kur bashkoni shumë atribute të ndjeshme në një strukturë të vetme të gjerë, ju rritni rrezen e shpërthimit të çdo konfigurimi të gabuar të aksesit. Kontrolli i duhur i aksesit bazuar në role, maskimi i të dhënave dhe auditimi bëhen të panegociueshme, veçanërisht në industritë e rregulluara.

Konsulencat e specializuara dhe ekipet e arkitekturës së brendshme mund të shtojnë vlerë të konsiderueshme duke i ndihmuar organizatat të vendosin se kur tavolinat e gjera janë vërtet zgjedhja e duhur dhe kur modelet alternative shkallëzohen më mirë. Kjo përfshin këshillimin mbi vendosjet në shumë cloud-e në AWS dhe Azure, integrimin me platformat BI si Power BI dhe projektimin e kanaleve të të dhënave të sigurta dhe performuese që lidhin bazat e të dhënave operacionale me shërbimet analitike dhe të IA-së.

Fshirje në shkallë të gjerë nën leje të kufizuara: strategji në grup

Një aspekt shpesh i anashkaluar i punës me tabela gjigante - të gjera apo jo - është se si të fshini në mënyrë të sigurt pjesë të mëdha të të dhënave kur jeni të kufizuar nga privilegje të kufizuara. Në shumë ndërmarrje, bazat e të dhënave (DBA) nuk mund të ekzekutojnë lirisht DDL, të krijojnë ndarje të reja ose të ristrukturojnë objektet në prodhim; ato mund të jenë në gjendje të kryejnë vetëm operacione DML si DELETE dhe, në disa raste, TRUNCATE.

Lëshimi i një deklarate të vetme masive DELETE që eliminon një të tretën e një tabele me shumë miliardë rreshta është një recetë për anulimin e shterimit të hapësirës së tabelave dhe transaksione afatgjata. Operacione të tilla mund t’i mbajnë bllokimet e rreshtave për orë të tëra, të rrisin përdorimin e funksioneve UNDO dhe TEMP dhe t’i bëjnë kohët e rikuperimit të papranueshme nëse diçka shkon keq në mes të rrugës.

Një strategji e zakonshme zbutëse është fshirja në grupe të kontrolluara duke përdorur PL/SQL me BULK COLLECT dhe FORALL. Modeli është të hapësh një kursor duke zgjedhur ROWID-et që plotësojnë predikatin e fshirjes, t'i marrësh ato në pjesë me një madhësi fikse (për shembull, 100,000 rreshta në të njëjtën kohë), t'i fshish ato rreshta në masë, t'i kryesh dhe pastaj të përsëritësh derisa kursori të jetë shteruar. Çdo përsëritje konsumon një sasi të menaxhueshme anulimesh dhe e mban dritaren e transaksionit të vogël.

Kjo qasje graduale zvogëlon stresin në hapësirën e tabelës së anulimit dhe ofron progres më të parashikueshëm, me koston e kryerjes së shumë veprimeve. Në skenarë ku nuk mund të mbështeteni te ndarjet ose ripërcaktimi i tabelave online, shpesh është opsioni më pragmatik. Mund ta akordoni madhësinë LIMIT bazuar në përdorimin e vëzhguar të anulimit, aftësinë I/O dhe kohëzgjatjen e pranueshme të transaksionit.

Idealisht, nëse do të kishit privilegje më të gjera, mund të preferonit strategji të bazuara në ndarje, të tilla si heqja ose shkurtimi i ndarjeve për të fshirë të dhënat historike pothuajse menjëherë. Opsione të tjera mund të përfshijnë krijimin e një tabele të re vetëm me rreshtat që dëshironi të mbani dhe zëvendësimin e saj. Por kur DDL është jashtë tabelës, fshirjet e koduara me kujdes në grupe mbeten mjeti kryesor në paketën tuaj.

Bashkimi i të gjitha këtyre fijeve së bashku – algoritme inteligjente të ruajtjes në memorje, ruajtje në memorje e plotë e bazës së të dhënave, formate kolonore në memorie, dizajn me tabela të gjera, ndarje, kompresim dhe praktika operative për mirëmbajtje në masë – ju jep një model mendor koherent se si Oracle mund të mbështesë ngarkesa pune jashtëzakonisht të vështira. Kur madhësia e memories përputhet me vëllimin e bazës së të dhënave dhe dizajni i skemës respekton si nevojat OLTP ashtu edhe ato analitike, ju mund të ofroni analiza nën sekonda, performancë të qëndrueshme transaksionale dhe kanale të besueshme të të dhënave të inteligjencës artificiale mbi tabela shumë të gjera të ruajtura tërësisht ose kryesisht në memorie.