Index šialenstvo: ako sa vyhnúť chaosu databázy

Od zamestnancov Techopedia, 5. októbra 2016

Jedlo so sebou: Host Eric Kavanagh diskutuje o indexovaní databázy s Dr. Robinom Bloorom, Dezom Blanchfieldom a Bertom Scalzom od IDERA.

Momentálne nie ste prihlásení. Ak chcete vidieť video, prihláste sa alebo sa zaregistrujte.

Partner obsahu Techopedia

Zamestnanci Techopedia sú prepojení so spoločnosťou Bloor Group a je možné ich kontaktovať pomocou možností napravo. Informácie o tom, ako spolupracujeme s priemyselnými partnermi, nájdete tu.

• Profile
• webové stránky

Eric Kavanagh: Dámy a páni, ahoj, ešte raz vitajte. Je streda o štvrtej hodine východnej a tí z vás, ktorí program poznajú, vedia, čo to znamená, je čas na ďalšiu epizódu Hot Technologies. Ano, naozaj. Moje meno je Eric Kavanagh, budem vašim moderátorom pre dnešné zasadnutie: "Index Insanity: Ako sa vyhnúť databázovému chaosu." Alebo, ako som sa zmienil v poslednom e-maile, aby som šiel, „databázový wrangling“. V dnešnej dobe, „wrangling“. Každý to robí. Je tu snímka o vás. A dosť o mne.

Preto bola séria Hot Technology skutočne navrhnutá tak, aby definovala konkrétny priestor, na rozdiel od briefingovej miestnosti, ktorá je iba inštruktážou živých analytikov, pre Hot Tech získame dvoch analytikov. Dnes to bude náš vlastný doktor Robin Bloor a náš vedec údajov Dez Blanchfield. A hovoríme o téme, o ktorej si myslím, že je skutočne veľmi symbolickým znakom toho, čo sa dnes deje na trhu.

Pointa je, že sme v dnešnej dobe vo svete zložitosti. Naozaj, ak si spomeniete na pätnásť rokov alebo dvadsať rokov, bol to vtedy úplne iný svet, najmä pokiaľ ide o databázové technológie. Databázy bývali pomerne jednoduché. Bolo ich iba niekoľko; väčšina z nich bola vzťahová. Teraz máme celý rad databázových technológií. Doslova desiatky možností na stole pre každého, kto chce zostaviť aplikáciu alebo urobiť niečo s údajmi. Všetko sa mení a to ovplyvňuje ľudí, ktorí sa snažia tieto systémy spravovať. Dnes sa porozprávame s Bertom Scalzom, ktorý je skutočným odborníkom v tejto oblasti; Je to senior produktový manažment pre IDERA, o tom, čo môžete urobiť, aby ste zvládli všetky tieto údaje. S týmto, odovzdám to doktorovi Robinovi Bloorovi, aby to vzal preč. Robin, podlaha je tvoja.

Robin Bloor: Dobre, ďakujem za úvod. Myslím si, že - pretože je to obojručná vec, myslím, že by som hovoril iba o optimalizácii databázy vo všeobecnosti ako úvod k tejto prehliadke Hot Tech. Začal som život - v technológii a analýze - začal som to robiť život, pretože som písal články o schopnostiach databáz na platforme DEC VAX. Z tohto dôvodu ma utratili používatelia databáz. A to, čo sa mi podobá, je to, prečo by ste mali databázu? Myslím tým, že v tých dňoch strašne veľa ľudí používalo na vytváranie súborov s kľúčovou hodnotou a používalo ich na určitý druh postupného klamstva indexu, ako ich nazývame, ale na vytvorenie určitého druhu databázy a viete, prečo by ste mali čokoľvek iné?

A odpoveď na to si myslím, že Michael Stonebraker na to dal najlepšiu odpoveď a povedal: „Databáza môže vedieť viac o tom, kde sú údaje a ako rýchlo sa dajú získať, ako dokáže ktorýkoľvek program vedieť.“ A myslím si, že je to zaujímavé; je to povaha hry. Ale v 19 - roku okolo roku 1989 som začal v technologickej analýze a viete, v tom čase boli databázy veľmi jednoduché a relačné databázy boli veľmi jednoduché. Mali tak málo schopností, myslím, že mohli ukladať dáta, samozrejme, a mohli by ste ich zálohovať a mali, boli v súlade s ACID, ale skutočne mali veľmi slabých optimalizátorov. V skutočnosti by bolo ťažké tvrdiť, že mali optimalizačnú schopnosť vôbec.

A neskôr sa len zlepšili a zlepšili, ale viete, keď databáza nefunguje - pretože sa zdá, že tieto klokani sú tak či onak naznačujúce - môže existovať nespočetné množstvo dôvodov, prečo to ide pomaly. A to ma privádza k veci: Databázy majú veľa funkcií, ale najdôležitejšou je optimalizácia dotazov. Keby to neurobili, nepoužili by ste ich. Je to o rýchlom získavaní informácií, o tom, že to dokážu, keď existuje veľa súbežných používateľov, a to je ťažký problém. A keď sa na to skutočne pozriete, povedzme im vyspelé databázy, ak sa vám páči - ale určite Oracle, v trochu menšej miere Microsoft SQL Server, určite Teradata a DB2 - optimalizátory týchto databáz dostali, boli desaťročia v stavebniny. Vieš, oni - nikto nesedel - šesť chlapcov na projekt s dvoma mužmi, rok, projekt a len jedného zrazili. Takto to nefunguje. Schopnosť optimalizácie sa postupne rozrastala a vyžaduje si to veľa rastu. Každopádne, poďme hovoriť o pozadí do databázy. O databáze NoSQL sa teraz hovorí strašne veľa a pre grafovú databázu je ešte veľa entuziazmu. A použitie SQL nad Hadoopom a podobné veci. Pravda je však taká, že ak práve teraz chcete databázu, ak chcete plne funkčný, schopný OLTP a rozsiahly prenos dopytov, jedná sa o relačnú databázu alebo o nič.

Medzi relačnými databázami má Oracle v popularite dominantné postavenie. Microsoft SQL Server je podľa môjho názoru druhý. Obe sa dajú použiť na prácu s OLTP a dopytom, ale v skutočnosti sa vám tieto pracovné zaťaženia nemusia vyhnúť. Potrebujete rôzne incidenty pre pracovné zaťaženie OLTP a pracovné zaťaženie dopytov. Existujú alternatívy k SQL a grafu. Väčšina spoločností štandardizuje jednu konkrétnu databázu, čo je dôvod - myslím tým, že po desaťročiach bojov so všetkými ostatnými hráčmi sa Oracle stal dominantnou. Jednoducho preto, že nakoniec dokázali predávať podnikové licencie, a tak spoločnosti používali iba alternatívne produkty vo výnimočných produktoch, ktoré by spoločnosť Oracle jednoducho neurobila. A databázy sú strategické tým, že sa vyvíjajú. A viete, že som urobil trochu výskumu pre túto prezentáciu, a je to druh - prídem k nej za chvíľu, ale je to trochu zaujímavé, ako sa vyvíjajú, pokiaľ ide o pohľad na to z pozície DBA. Tomu hovorím neviditeľný trend. Je to Mooreov zákon. Je to zhruba takto: Najväčšia databáza je a nové databázy neexistujú starej databázy, ktorá by mohla prijať oveľa viac údajov. Spravidla ide o databázu, ktorá sa používa na nový problém. A skutočne rastú z hľadiska objemu údajov. Zhruba pri kocke Mooreovej zákon. Mooreov zákon je teda desaťkrát každých šesť rokov. VLDB majú tendenciu rásť faktor tisíc každých šesť rokov. V roku 1991, 1992 sa veľké databázy merajú v megabajtoch. V rokoch '97 a '98, gigabajty. 2003, '4, terabytes. 2009, '10, začali ste vidieť databázy petabajtov. Myslím, že práve teraz existovala pravdepodobne jedna alebo dve exabyte databázy, ale najväčšia, o ktorej som počul, je 200 petabytov včas, a viete, nezískavate údaje do databáz petabyte. Ale je to z väčšej časti nové veľké spoločnosti s webom 2.0, pravdepodobne máte Facebook týmto smerom.

Ale ak sa na to skutočne pozriete a očakávate, že databáza prejde takým stupňom eskalácie, vyžaduje to veľa. A pozoruhodné je, že až do úrovne petabytov sa zdajú byť dosť dobre. Myslím tým, že hovorím skôr o starších produktoch ako o ničom novom. Zdá sa, že sa im darilo mimoriadne dobre. Ak sa pozrieme na výkonnosť databázy, úzke miesta, trvá mi to späť do času, keď som sa o nich skutočne staral, a musel som sa o nich starať. Viete, že toto je v podstate rozpis hardvéru. Existujú prekážky CPU, možno existujú úzke miesta pamäte, možno sú aj prekážky na disku. Môže to byť sieť, ktorá vám spôsobuje zármutok, a môžete tiež mať problémy so zamykaním, v závislosti od toho, čo robíte, ale zvyčajne to preto, že program nevie, koho treba vytočiť. Takže, ak sa chystáte naladiť databázu, skutočne sa snažíte ju naladiť tak, aby tancovala medzi týmito piatimi možnými prekážkami, ako to dokáže. A to nie je ľahké, pretože množstvo pamäte, ktorú môžete nakonfigurovať na danom serveri, sa dramaticky zvýši. Potom sa CPU stali viacjadrovými, diskovými, takže teraz môžeme urobiť, myslím, že aj na komoditných serveroch si myslím, že môžete robiť stovky a stovky terabajtov, možno štvrtinu petabajtov, dokonca aj na komoditných serveroch. Takže zo všetkých týchto vecí si môžete zahrať, sieť samozrejme môže ísť rôznymi rýchlosťami, ale väčšinou, keď pracujete s databázami, naozaj chcete mať medzi servermi vláknové káble a na tom nič bežať, najmä tým smerom.

Faktory výkonnosti databázy. Chcem tým povedať, že vynechávam, o čom to všetko bude, pretože viem, že o tom bude hovoriť Dez, ale zlý návrh databázy znamená zle fungujúcu databázu. Zlý návrh programovania môže znamenať hádzanie veľmi hlúpeho jazyka SQL do databázy, čo bude trvať omnoho dlhšie. Súbežnosť a miešanie pracovnej záťaže, príliš veľa súbežnosti spôsobí problémy so zúžením. Miešanie pracovnej záťaže, keď máte veľké dotazy s veľmi malými, krátkymi a ostrými dopytmi, ktoré spôsobujú problémy. Vyskytol sa problém s vyrovnávaním záťaže. Väčšina databáz sa o to postará, ale ak nemáte sofistikovaný produkt, potom viete, že pridaním niekoľkých serverov nie je všetko, čo robíte, ak skutočne chcete zväčšiť veľkosť klastra. Skôr ako dosiahnete optimálny výkon, musíte skutočne vyrovnať zaťaženie. Musíte urobiť plánovanie kapacít. Absolútne. Obzvlášť teraz v týchto dňoch, keď objemy údajov narastajú dramatickejšie, než tomu bolo v prípade databáz. Existujú aj celé problémy s dátovou vrstvou v súvislosti s tým, ako údaje prehltnete, ako údaje prenášate. Neschopnosť získať údaje do databázy včas môže byť problémom s výkonom neskôr, pretože sme prešli z databáz pracujúcich vo Windows na dvadsaťštyri, sedem, tristo sedemdesiatpäť operácií a neexistujú žiadne okná, v ktorých môžete spomaliť databázy dole alebo je nepravdepodobné, že v budúcnosti bude.

Problém Oracle DBA. Na to som myslel. Bol som v Oracle DBA s Oracle 7 a pamätám si, ako to naladiť. A ak sa teraz skutočne pozriete na Oracle, je to tak, tak - má to spôsob, viac možností. Má indexovanie bitmapy a podobné veci, ale v skutočnosti som si našiel čas pozrieť sa a zistiť, koľko ladiacich parametrov v súčasnosti existuje v databáze Oracle. A existuje viac ako tristo päťdesiat parametrov ladenia a existuje ďalších sto skrytých parametrov, o ktorých môžu špecializované DBA vedieť, ale normálne Oracle DBA nevedia. A to znamená, že vyladenie tohto druhu databázy je ťažké. Nie je to vôbec jednoduchá vec. Musíte sa k tomu cítiť, musíte to robiť dlho, dlho a musíte presne vedieť, aký problém si myslíte, že riešite, pretože ladenie sa začína, keď sa výkon klesá, ale nemusí to byť výkon všetkého. Záleží na výkone konkrétnych dotazov a možno to budete môcť vyriešiť pripnutím určitých údajov a pamäte, alebo ich budete musieť opraviť indexovaním, alebo budete musieť začať robiť rozdelenie iným spôsobom. Je tu veľa vecí, ktoré môžete urobiť. Preto to neurobia vo svojich hlavách - DBA potrebujú nástroje. Teraz prejdem na Deza, ktorý ti povie o indexovaní.

Eric Kavanagh: Dobre Dez, zober to.

Dez Blanchfield: Ďakujem Robin a mám rád titulnú stránku. Myslím, že si tam hodil rukavicu, aby som prišiel, dokonca sa vzdialene priblížil niečomu vzrušujúcemu. Ale použil som obrázok našej malej galaxie, ako môj pohľad na to, čo sa dnes zmenilo na dnešnú výzvu pre správcov databáz, pretože toto je mentálny obraz, ktorý mám tendenciu vykúzliť, keď sa dostanem do prostredia a už nie som. vo svete správy databáz alebo navrhovania databáz na tejto úrovni. Ale rovnako ako vy, aj Robin a ja sme boli mnoho rokov zapojení do sveta databáz, buď ako správca alebo vývojár, alebo prípadne architekt, a potom som si uvedomil, že by som mohol robiť lepšie veci, aby som získal kôru. Má však tendenciu sa cítiť, akoby ste sa pozerali na túto galaxiu údajov, a tým viac dnes, keď ideme z, ako ste naznačili, prešli sme z megabajtov na petabajty a exo mierky vo veľmi krátkom časovom období., vo veľkej schéme vecí. Ale veta, ktorú mám na mysli, je, že databázové indexy sú teraz čiernym umením a nie sú to skutočne také veci, ktoré by mali obyčajní smrteľníci tak trochu fušovať, pre podnikové podnikové aplikácie a typ formulácie hovorili. Chcel som sa však rýchlo zoznámiť s typom histórie, ktorý som mal s databázovými svetmi, a uviesť do kontextu, do ktorého sa chystáme vyvodiť záver, a potom si dnes so svojimi priateľmi prejsť nejaký materiál. IDERA, pretože si myslím, že existuje veľa rôznych premýšľaní o tom, ako dosiahnuť ladenie výkonu databázy, a jedným z nich je hádzanie plechovky. V prípade mnohých obchodov, s ktorými sa stretávam, sa vždy nedarí doladiť výkon v databázovej vrstve a najmä v indexovej vrstve, kým sa nedostanú cez tvrdú cestu myslenia, že na ňu môžu zahodiť tuner.,

Mnoho ľudí k tomu iba pristupuje s veľkým železom a mám tu fotku The Flash, pretože ak ste niekedy sledovali nejaké staré filmy alebo určite poslednú televíznu reláciu s The Flash, ako v Flash Gordon stará postava a teraz, keď sa volá „The Flash“, má tendenciu ísť veľmi, veľmi rýchlo a vždy mu dôjde energia. A to sa stane, keď hodíte veľké množstvo železa na výkon databázy. Podľa mojich skúseností môžete vždy vložiť do hry vysoký výkon, tvrdú prácu, môžete optimalizovať svoje operačné systémy a naladiť ich do určitého bodu. Môžete si zaistiť, že máte rýchle viacjadrové a viacvláknové procesory na zrýchlenie fungovania aplikácie, môžete na to hádzať veľa pamäte RAM, môžete mať vysokovýkonné plány, môžete prejsť z pevných diskov na ukladanie pevných diskov do vyrovnávacej pamäte v pevnom stave. a vysoko výkonné úložné pole. A dokonca aj teraz, ľudia hádzajú veci, ako sú flash a NVMe, do svojich databázových strojov, pričom si myslia, že dostanú tento prihlasovací čas dvakrát vyšší výkon. A vždy dostanú nejaký zisk. Všetko sa však vracia k rovnakým základným problémom s ladením výkonu. Veľa sieťových pripojení s nízkou latenciou, takže klastre fungujú rýchlo. A zoskupovanie databázovej infraštruktúry, takže máte viac ako len jeden počítač, ktorý vykonáva všetku prácu. Máte však tendenciu sa vracať k rovnakému základnému problému s výkonom, ktorým je čítanie údajov. Písanie údajov je zväčša pomerne lineárna výzva a pokiaľ nie je vykonaná správne.

A potom máme v dnešnom svete výzvu: Nie všetky databázy sú vytvorené rovnako. Existujú databázy a citácie „databáza“. A keď uvažujeme o databázových nástrojoch, ľudia často premýšľajú o tradičných, obvyklých podozrivých, aké boli vo svete SQL. Viete, máme Oracle a Microsoft SQL Server a okolo nich existuje vo svete otvorených zdrojov MySQL, ktorý je teraz vo vlastníctve spoločnosti Oracle, ale stále je to otvorený zdroj. A potom máme neobvyklých podozrivých, motory NoSQL, ktoré majú stále problém s indexovaním a správou výkonu, a ja do nich nebudem chodiť podrobne, ale je ich stále viac. veci sa objavujú každý deň a vyzerajú a cítia sa ako databázové stroje z hľadiska vývojárov a z hľadiska výkonnosti, ale sú to veľmi odlišné zvieratá a majú na svete svoj vlastný malý výklenok, výkon v pamäti alebo lineárna stupnica na disku. Takto však svet vyzerá vo svete databáz. Toto je rok 2016, toto je tretia verzia mapy mnohých ľudí, ktorí vytvárajú túto prebiehajúcu mapu krajiny, ako vyzerajú databázy, a to je miesto, kde by to nemalo zmysel ani nadľudskému architektovi databázy alebo správcovi databázy. z toho. Doslova stovky a stovky a stovky rôznych značiek, modelov, výrobcov databáz, vždy kompatibilný s SQL. A zaujímavé je, že všetci sa vracajú k rovnakej výzve. Ladenie výkonu a výkonu okolo databázového nástroja, a najmä podľa toho, ako sú údaje indexované.

Poďme sa teda rýchlo venovať indexovaniu databázy, pretože je to zaujímavá téma a myslím si, že sa k nej musíte dostať podrobnejšie. Myslím si však, že je celkom dobre akceptované a štandardné priemyselné odvetvie, že ladenie výkonnosti databázových indexov je miestom, kde svet začína a končí, pokiaľ ide o zabezpečenie toho, aby boli vaše údaje prístupné v rýchlom a rýchlom formáte. Čo je to indexovanie databázy? Ak uvažujeme o indexovaní vo forme, v ktorej sme zvyknutí ako bežní ľudia, porozmýšľajte o indexovej stránke v knihe. Ak chcete v knihe nájsť niečo - najmä to, čo sa páči encyklopédii alebo niečo ako referenčný materiál nejakej formy - ak hľadáte niečo podobné tejto stránke, kde hľadám veci ako téma priehrady. v encyklopédii. Chcem nájsť všetky odkazy na priehrady, povodie a veľkú zástavbu, spravidla vyrobené človekom. Pôjdem dozadu, nájdem ho v abecednom zoradenom zozname, od A po Z, zľava doprava a nájdem D. Nájdem slovo „priehrady“ a vidím to na strany 16, 38, 41, existuje odkaz na ne, a potom môžem ísť na tieto stránky, môžem si prezerať svoje oči a nájdem odkaz na slovo „priehrada“. Je to v podstate rovnaký koncept v databáze, ale teraz je to raketová veda v mnohých ohľadoch. Natoľko, že každý správca databázy, ktorý som kedy dobre poznal, považuje indexy za jediný najkritickejší nástroj na ladenie výkonu v akomkoľvek svete databáz, bez ohľadu na to, aké môžu byť ich skúsenosti, pokiaľ ide o hádzanie plechov, alebo nech je to čokoľvek.

Všeobecne platí, že keď hovoríme o indexovaní databázy, existuje množstvo bežných prístupov. A čím zložitejšie sú databázové indexy, tým zložitejší je prístup k indexovaniu údajov. Ale v zásade, keď uvažujete o indexovaní údajov - predstavte si, že máme súbor, ktorý má zoznam mien; nemôžu byť usporiadané v abecednom poradí. Predstavme si, že ich je dvadsať. Ak sa chystáme usporiadať - ak hľadáme údaje v tomto zozname, zhora nadol a povedzme, že ide o zoznam mien. Ak si vyberiem náhodné meno a začnem v tomto zozname listovať zhora nadol, v lineárnom formáte a je to neusporiadaný zoznam, považujem to za môj priemerný čas vyhľadávania a maximálny čas hľadania - dve kritériá, a V druhom riadku mám preklep, mal by byť „maximálny čas vyhľadávania“, prepáčte - ale môj priemerný čas vyhľadávania je v podstate N plus jeden, vydelený dvoma, a to je v priemere trvať mi päťdesiat percent času skenovať od začiatku zoznamu po spodok zoznamu a nájsť v tomto zozname ľubovoľnú náhodnú vec. A druhý riadok, pod lineárnym, by mal byť „maximálny čas vyhľadávania.“ Ale maximálny čas vyhľadávania je v podstate počet položiek, a to znamená, že ak mám zoznam dvadsiatich vecí, najviac mi môže trvať hľadať niečo v tejto databáze, je ísť zhora nadol, čo je v tomto zjednodušenom príklade povedzme 20 položiek. A je to veľmi pomalý proces a neexistuje skutočne spôsob, ako to vyladiť. A potom existujú ďalšie typy spôsobov, ako tieto údaje preniesť a vytvoriť index, čo je v skutočnosti krátky zoznam ukazovateľov, kde sa nachádzajú skutočné údaje, ako napríklad binárny strom, strom B, bitmapa, hashovanie, zoskupovanie a zoskupovanie, a potom existujú rôzne typy údajov, ako sú priestorové, filtrované, XML a plný text.

Binárny kód sa používa veľmi často na veci, v ktorých sa k nim údaje požičiavajú. B-strom je pravdepodobne jediný najbežnejší vo všeobecnom slova zmysle, historicky v tom, že je to bežný spôsob, ako usporiadať index do ľubovoľnej formy údajov a umožňuje loggerom, výberom a vkladaním a mazaním relatívne jednoduché pri posúvaní ukazovateľov okolo odkazy na ukazovatele, body. Existujú aj iné typy, napríklad bitmapa, ktoré sa týkajú typov údajov, ako keby sme dostali priradený rozsah nejakej formy. Hashing funguje veľmi dobre pre veľké objekty, najmä pre blogy a obrázky. A vidíte, že existuje niekoľko rôznych druhov vedeckých prístupov, matematických prístupov k indexovaniu údajov. Pre obyčajného smrteľníka je to zaujímavá výzva, o ktorej by sme mali hovoriť na tejto úrovni. Keď o tom hovoríte na úrovni výkonu pre správcu databázy, skutočne sa stanú raketovým vedcom a ľudia v nich robia tituly, a ja viem, že doktor Robin Bloor to určite urobil, a napísal o tom knihy pre spoločnosti IBM a ďalších veľkých značiek za posledných niekoľko desaťročí. A tak, môj názor, je, že sme skutočne prešli časom, keď viete, že raz za čas by som bol osobne schopný sedieť pred systémom a bol by som schopný ho rozobrať a ukázať vám presne tam, kde boli problémy s výkonom na príkazovom riadku alebo v grafickom nástroji na spustenie používateľského rozhrania, a začnite sa ponoriť do údajov a povedzte im, kde boli problémy, a do nich začleňujte indexy alebo subindexy alebo primárne a sekundárne indexy. a začať ich používať pri hľadaní vecí. Ale keď premýšľate o tejto krajine, ukázal som vám, kde máme stovky a stovky značiek, značiek a modelov a výrobcov a typov databáz, už sme v tom čase skutočne dobre a skutočne, keď človek môže urobiť zmysel typov databázových nástrojov, ktoré máme. Obzvlášť, aj keď sa práve vraciame k obľúbeným Oracle, prevládajúce značky v súčasnosti v relačných databázových platformách.

Počet databáz, s ktorými musia pracovať, buď z proprietárnej platformy, ako je ERP alebo HR alebo finančný systém, alebo či ide o platformu domácu pečenie z rôznych dôvodov, počet databáz a databázových tabuliek a záznamov, ktoré skončíme rokovania sú iba astronomické a fyzicky to nemôžete urobiť ručne. A my sme teraz mali ďalšie komplikácie, keď kedysi dávno mohol databázový server len sedieť pod vašim stolom. Viete, ako malé dieťa po škole som chodil a pracoval na databázovom softvéri, pôvodne, Apple IIes a potom DOS-založené systémy, ako dBase II, dBase III, prešli obdobím mainframe a mid- rozsahu a dokonca aj VAX a PDP a protokolový súbor. A podobne ako Sabre, a potom nakoniec, keď prišli niektoré z databáz SQL. Ale v týchto dňoch, keď uvažujeme o databázových nástrojoch, vyzerajú ako ľavý dolný roh. Databázový server už nie je iba jeden počítač sediaci na podlahe pod stolom; sú to stovky počítačov, ktoré prevádzkujú kópie databázových strojov a klastrov, a škálovajú až stovky a stovky terabajtov údajov, ak nie petabajty údajov, čo sú tisíce terabajtov. A až do krajnosti, ako uviedol doktor Robin Bloor, že niektoré špecifické prípady použitia - najmä letecké spoločnosti, najmä vládne agentúry - sa môžu dostať k exabytom. Stále sú dosť úzko prepojené, ale stovky terabajtov a dokonca desiatky petabytov už nie sú neobvyklé, najmä od dotcom boomu až po súčasnosť, aký druh spoločností nazývame web 2.0, napríklad Facebook, Google, Yahoo. a tak ďalej.

Komplikáciu máme aj teraz, keď sa veci presúvajú na externé služby. Infraštruktúrnu platformu a softvér máme ako servisný prístup poskytujúci infraštruktúru. Najmä platformová služba, kde nemôžeme kúpiť len pre Oracle a ich cloudovú platformu, databázy a servery. To nám umožňuje robiť veľmi rýchly vývoj aplikácií a jednoducho pripojiť databázu späť na servery. Nemusíme premýšľať o tom, čo je pod kapotou. Nevýhodou je, že často nepremýšľame o tom, ako navrhujeme a implementujeme databázu späť dovtedy, kým nezačne bolieť a výkon sa nestane problémom, a potom nakoniec musíme hľadať správny nástroj na diagnostiku, prečo naša databáza bolí a kde sú problémy s výkonom. A vždy sa tým vracia k spoločnému problému, ako sme tieto údaje indexovali, a typy indexov, ktoré sme pre tieto údaje použili a ktoré nás potom priviedli späť k požiadavke nadľudského výkonu. A niekto, kto má prístup k správnym systémom a správnym nástrojom na výkon, naladí tieto motory a začne hľadať hot spot a pozerá sa, kde sú otázky, kde sa údaje pohybujú, typy otázok, ako sú otázky štruktúrované, kto robí otázky a či sa otázky zaraďujú do frontu a musia sa ukladať do vyrovnávacej pamäte. Akú replikáciu hľadáte?

A tak sme v poriadku a podľa môjho názoru teraz v situácii, keď dokonca aj najlepší svetoví databázoví guru, v podstate naši databázoví architekti a naši správcovia databáz a výkonnostné základne, podľa môjho názoru veľmi potrebujú začať využívať správne nástroje poskytovať optimálne ladenie indexov výkonnosti pre akýkoľvek databázový stroj. Pretože rozsah, s ktorým sa zaoberáme, a rýchlosť, s ktorou sa veci pohybujú, to jednoducho nedokážeme urobiť ručne a pokus o to vždy môže priniesť ďalšie problémy s výkonom, pretože v tomto priestore nemusíme mať skúsenosti, ktoré Snažíme sa vyriešiť problém. A ja verím, že tam sa chystáme odovzdať Bertovi a chystáme sa hovoriť o tom, ako vyriešili tento rozmanitý problém a o druhu vecí, ktoré ich nástroj dokáže. urobiť, najmä pre svet Oracle. A s tým, Bert, pôjdem k tebe.

Bert Scalzo: Ďakujem. Vitajte všetci, volám sa Bert Scalzo, pracujem pre IDERA. Som senior produktovým manažérom niektorých našich databázových produktov. Dnes niektoré z nich ukážem. Chcem však hovoriť o indexoch, pretože súhlasím so všetkým, čo tu všetci povedali, najmä posledným listom, že indexy sú teraz také zložité, že potrebujete nástroj, a dúfam, že vás presvedčím. Takže návrh indexu Oracle nie je taký jednoduchý, ako tomu bolo v minulosti. Veľa ľudí si nebude istých, keď sa pozerajú na možnosti, a páči sa mi toto tvrdenie, že som sa vymanil z histórie, „v týchto veciach je jedinou istotou to, že nič nie je isté.“ cítite sa dnes o indexoch, pretože aj keď si myslíte, že viete, že by ste mali odpoveďou indexov X, Y alebo Z, nemôžete si byť istí, kým to nevyskúšate, pretože títo optimalizátori sa niekedy správajú inak, ako očakávate. S návrhom indexu je teda veľa pokusov a omylov. Teraz, keď ste v dobrých starých časoch potrebovali index, spravidla existovali iba dve otázky alebo jedna otázka. Bol jedinečný alebo nebol jedinečný? A možno ste mysleli aj na ďalšie veci, napríklad: „Koľko indexov môžem mať maximum v jednej tabuľke?“, Pretože príliš veľa indexov spomaľuje vaše vloženia, aktualizácie a mazania. Možno ste tiež boli v databázovom systéme, mali ste obmedzenia týkajúce sa toho, koľko stĺpcov by mohlo byť v indexe viacerých stĺpcov, pretože niekedy existovali obmedzenia na základe veľkosti stránky alebo bloku vášho databázového nástroja, ale v skutočnosti to bolo celkom jednoduché späť v starých dobrých časoch. Buď ste to indexovali, alebo nie. A naozaj, všetko bolo v B-strome. Mohli sme povoliť duplikáty alebo nie, a to bolo o tom. Život bol dobrý, život jednoduchý.

Dnes nie je život taký dobrý alebo jednoduchý. Červeným znakom Ghostbuster som dal spôsob, akým sme to robili, pretože teraz máme spojenie B-strom verzus bitmap versus bitmap. A ja ti vysvetlím, o čom sú niektoré z nich. Klastrované a neslastované, jedinečné alebo duplikované, vpred alebo v opačnom poradí, založené na funkciách, rozdelené alebo nerozdelené. Ak ide o vytváranie oddielov, je to globálne alebo miestne rozdelenie? Vysvetlím to tiež. A potom je tu tiež niečo, čo sa nazýva indexovaná organizovaná tabuľka. A v skutočnosti som tu zanechal pol tucta ďalších, pretože si myslím, že tu mám teraz dosť, čo by vás malo presvedčiť, že indexy sú oveľa tvrdšie, ako ste si možno mysleli. Na tejto konkrétnej snímke začnem v ľavej hornej časti diagramu a mám tabuľku. A prvá vec, ktorú musím rozhodnúť, je, že v závislosti od verzie vašej databázy a od dodávateľa vašej databázy povoľujú tabuľky objektov alebo sú iba relačné? Idem dole po pravej strane a poviem, že budujeme relačný stôl. Teraz si musím položiť otázku, či je to v klastri? A mnohí z vás, ktorí už nejakú dobu robili Oracle, si budú pamätať, že klastre boli späť na Oracle 6 dní. Pravdepodobne sa už dnes príliš nepoužívajú, ale dovoľte mi ísť najprv dolu touto vetvou.

Keby som chcel dať tabuľku do klastra, musel by som mať na tejto tabuľke klastrovaný index. Teraz, v Oracle, keď ste zhlukovali tabuľku, v podstate ste ukladali riadky alebo riadky boli blízko seba, kde boli hodnoty podobné. Takže musíte mať klastrovaný index a tento klastrovaný index by mohol byť nerozdelený na oddiely. Inými slovami, v skutočnosti neexistovali žiadne metódy rozdelenia, ako by ste robili zoskupenú tabuľku. Bolo to prísne rozdelené. A pretože to nebolo rozdelené, bolo globálne. Za minútu vysvetlím, čo je globálne. A vždy to bol strom B. Inými slovami, keď som zostúpil z tejto vetvy, bolo to celkom jednoduché, nemal som veľa možností. Ak som teraz urobil index bez klastrov v klastrovej tabuľke, čo bolo v niektorých verziách povolené, opäť to nebolo rozdelené na oddiely; ak nie je rozdelená na oddiely, potom je vaša jediná voľba globálna. A tak tu máte na výber B-strom alebo bitmapu. Opäť to záležalo na vašej verzii databázy. Ale teraz sa vráťme späť k relačnému stolu a začneme znova dolu pravou stranou a teraz budeme mať obyčajný, starý, pravidelný, hromadený stôl: relačný. Bude to v tabuľkovom priestore. Najprv tu idem dolu pravou stranou. Takže je to organizácia, halda. Ďalšia otázka, ktorú si musím položiť, je: „Chcem rozdeliť túto tabuľku alebo nie?“ Teraz by ste niekedy rozdelili na oddiely, pretože ste si mysleli: „Hej, optimalizátor bude inteligentnejší, ako dokáže optimalizovať dotazy. „Veľa DBA vám však povie, že dôvod, pre ktorý to robíte, je na administratívne účely. Ak máte stovku miliárd riadkov, ak ju rozdelíte na oddiely alebo vedrá, keď chcete pridať údaje do posledného vedra, môžete vynechať a indexovať to, čo je len niekoľko miliónov riadkov. Tieto údaje môžete vložiť a potom môžete tento index znova vytvoriť len v tom segmente.

Aj keď pre niektorých to bola dobrá technika, optimalizačné techniky, ako je odstránenie oddielu, jej skutočná hodnota bola schopná spravovať alebo vykonávať administratívne úlohy na menších kusoch. Keď idem na organizačnú hromadu, prvou otázkou bolo: „Rozdelil som to alebo nie?“ Poďme doľava, nebudem rozdeliť tabuľku. Teraz sa to môže zdať čudné, keď vám to poviem, ale môžete mať tabuľku bez oddielu a index nemôžete rozdeliť tak, ako ste zvyknutí, alebo môžete index rozdeliť. Zastavte sa a premýšľajte. Vaša tabuľka má v podstate jednu vedierku, ako ste si vždy mysleli, a napriek tomu bude mať váš index niekoľko vedier. Keď k tomu dôjde, keď existuje nesúlad medzi počtom vedier a tabuľkou a počtom vedier v indexe, znamená to globálny. Ak teda tabuľka nie je rozdelená na oddiely a index je rozdelený na oddiely, považuje sa to za globálne, pretože existuje nesúlad. Teraz mi dovoľte vrátiť sa späť na svoju organizačnú hromadu a namiesto toho zostúpiť na stranu oddielu. Ak teraz mám tabuľku oddielov a povedzme, že tabuľka má štyri vedrá, štyri oddiely, môj index by mohol mať štyri vedrá, takže môj index sa zhoduje s mojím návrhom tabuľky. A tak je koniec, na druhej strane, po pravej strane. To by sa považovalo za miestne. Lokálny index v podstate znamená, že rozdelenie tabuľky a indexu sa uskutočňuje rovnakým spôsobom a má rovnaký počet segmentov. A potom, čo budem mať miestny index, môže to byť strom B alebo bitmapa a tá zelená šípka, ktorú tento druh stúpa, ukazuje, že aj keď je to strom B, stále existujú možnosti, ktoré by sa dali urobiť. Mohlo by to byť založené na funkciách. A tiež, ak ide o bitmapu, existujú rôzne typy bitmáp. Existuje index nazývaný bitmapový index spojenia. Ak skladujete údaje, je to veľmi populárny druh indexu pre hviezdnu schému alebo dizajn. Čo sa stane, je to, že index má ID riadkov pre to, na čo ukazuje v tabuľke, ale bude mať tiež ID riadkov pre nadradené tabuľky, takže keď ste - musíte navrhnúť hviezdnu schému a hľadáte v tabuľke faktov tento index v tabuľke faktov ukazuje na údaje, ktoré vás zaujímajú, a ukazuje vás na každý riadok v dimenziách, takže musíte mať iba jeden index.

A vlastne to vzniklo kvôli Red Brick, ktorá bola databázou pred mnohými rokmi - veľa ľudí si to môže pamätať. A tak, keď sa pozriete na tento obrázok - a nezabúdajte na to, že som na tento obrázok nevložil všetko, pretože obrázok by bol omnoho väčší, sú tu ďalšie problémy, ktoré tu mám v texte nad pravou hornou časťou., Je to index obráteného poradia? A môžete povedať: „Prečo by som chcel index opačného poradia? To vôbec nedáva zmysel. “No, ak ste v klastrovom prostredí v Oracle, ak robíte skutočné klastre aplikácií, ak udržujete svoje indexy v poriadku, takže bez obrátenia, ak máte veľa spracovania, ktoré zasahuje rovnaké hodnoty alebo rovnaké indexové hodnoty, čo by sa stalo, by ste mali horúce oblasti vášho B-stromu. Znamená to, že by ste mali nárok a prípadne uzamknutie, aby ste sa pokúsili získať prístup k týmto materiálom, a to by ste robili cez uzly v sieti. Ak vložíte index obráteného poradia, môžete to teraz vrátiť späť. Môžete povedať: „No, podobné hodnoty sú v rôznych častiach stromov, takže nemám svoje samostatné uzly súťažiace o horúce oblasti stromu.“ A potom si všimnite, že jedinečný pri niektorých možnostiach nefunguje., Ak sa pozriete, očísloval som tri, päť, osem a jedenásť, takže v niektorých prípadoch nemôžem mať jedinečný index. Podobne sú prípady, keď nemôžem mať spätný index, a potom sú tu ďalšie problémy, ako je logovanie alebo žiadne protokolovanie, a paralelné a nerovnobežné. Môžem priradiť veci konkrétnej oblasti v pamäti.

A to vynecháva stále dosť funkcií v Oracle. Povedal by som, že keď sa pozriete na Oracle 12, je tu pravdepodobne opäť asi ďalších tucet vecí, ktoré by som mohol pridať k tomuto obrázku. Indexovanie je skutočne zložité a ja skutočne súhlasím s predchádzajúcim rečníkom. Aby ste sa v tomto mohli pohybovať a urobiť dobrý výber, potrebujete nástroj. Potrebujete nejaký obrázok, ako je tento, a nejakú metodiku, ako by ste veci vybrali, a dúfajme, že by vám tento nástroj pomohol dostať sa tam. A potom to bude pokus a omyl. Vždy hovorím ľuďom o indexovaní: „pozri sa pred tým, ako skočíš.“ A potom tu uvidíš malého psa, skáka bez toho, aby sa pozrel, skončí vo vode so žralokom, alebo sa chlap pripravuje skočiť do vody., a on sa nabodne. Musíte myslieť na svoje indexovanie, pretože vytvorenie indexu nemusí vždy znamenať, že sa veci zlepšia. V skutočnosti môže vytvorenie indexu veci spomaliť. A výkonnosť dotazu môže byť o jeden stupeň lepšia pri jednej voľbe pred druhou. A dám vám dobrý príklad. Ak robíte hviezdnu schému dizajnu a vo svojich rozmerových tabuľkách používate bitmapové indexy v jednom prípade a v inom prípade poviete „Použijem indexy stromu B“, máte bitmapu oproti B- strom. Môžem vám povedať, že jedným riešením bude veľkosť rádu alebo možno niekoľko rádov rýchlejšie ako iné. Majte však na pamäti, čo funguje v jednom prostredí, napríklad v prostredí skladovania údajov, pravdepodobne nie je v prostredí OLTP dobrá voľba.

Napríklad, ak by ste mali vziať transakčnú tabuľku a umiestniť bitmapové indexy na transakčnú tabuľku, je drahé počítať a resetovať bitmapy, tieto dlhé reťazce, a tak v tabuľke OLTP môžete tabuľku zasiahnuť tak silno, že bitmapa index sa môže poškodiť a spomaliť váš systém, pretože jednoducho nie je určený na aktualizácie. Sú vynikajúce pre rýchly prístup, ale nie sú dobré pre aktualizácie. Myslím, že index vyžaduje pokus a omyl. Už neexistuje žiadne zlaté pravidlo - v tejto rovnici je príliš veľa rôznych premenných - a nakoniec sa budete musieť pozrieť na vykonanie alebo vysvetliť plány v databáze, aby ste zistili, či robíte dobré výbery. A niekedy môže byť analýza plánu takmer samostatnou vedou. To sa dnes nebudem zaoberať - to je ďalšia téma -, ale návrh indexu neberte ako samozrejmý. Existujú legitímne dôvody, prečo sú všetky tieto bláznivé indexy, ktoré som vám ukázal, na predchádzajúcom obrázku a o ktorých hovoril predchádzajúci rečník. Neboli vytvorené iba preto, že to bolo elegantné umiestniť kontrolný zoznam niekde pre dodávateľa databázy; existujú prípady použitia alebo scenáre, v ktorých sú tieto indexy dôležité a budú mať významný vplyv. Teraz vám ukážem niekoľko príkladov rôznych typov indexov v jednom z našich nástrojov. Dovoľte mi, aby som iba zdvihol obrazovku, aby ste ju mohli vidieť. Dobre, takže tu sedím vnútri - dovoľte mi minimalizovať túto aplikáciu. Sedím vnútri VMware a prevádzkujem Windows Server 2012 VM.

A vidíte, mám takmer každý nástroj, ktorý pozná človek. Ako produktový manažér si musím byť vedomý svojej konkurencie, takže to nie sú len nástroje, ktoré mám, ale čo robia moji konkurenti? A tu máme tento nástroj s názvom DBArtisan, ktorý už mám spustený, ale idem - tak ho jednoducho vychovám. A to, čo vidíte, je naozaj pekný nástroj, pretože namiesto toho, aby ste ho museli používať, povedzme podnikový manažér pre Oracle a SQL Management Studio pre SQL Server a MySQL Workbench pre MySQL a dvanásť ďalších databáz, ktoré podporujeme, dobre mám všetky svoje databázy zabudované do tohto jedného nástroja. Je tu DB2, MySQL, Oracle, Postgres, SQL Server a Sybase, a to je - v tejto konkrétnej veci mám iba šesť databáz, pretože nemôžem - tento nástroj podporuje dvanásť databáz, ale môj zlý VM, bežiaci súčasne šesť databáz a skúšajúci urobiť ukážku, je toľko, ako môj hardvér uľahčí. Dovoľte mi teda teraz ísť späť do spoločnosti Oracle a ak si všimnete, všetky tieto veci sú rovnaké. Ak chcem zmerať svoj výkon v DB2, je to rovnaká voľba, akú by som mal v Oracle. Teraz pod poťahmi robíme veľa rôznych vecí, takže nemusíte vedieť, čo sa deje, ale poskytujeme vám konzistentné rozhranie, takže môžete byť odborníkom na viac databázových platforiem. A to by zahŕňalo prácu s indexmi, tému tejto diskusie.

Dovoľte mi sem prísť a dovoľte mi začať tým, že sa pozriem na niektoré tabuľky, a mám databázu filmov, ktorá má iba niekoľko tabuliek. A keď sa pozriem na konkrétnu tabuľku, podobne ako na zákaznícku tabuľku, keď ju privediem sem, vidím návrh svojej tabuľky, tu sú moje stĺpce v mojej tabuľke a tu sú informácie o každom stĺpci. Mám pre tabuľku vlastnosti, ale všimnite si, že mám záložku pre indexy a tu vidím, že sú indexy v tabuľke. Všimnite si, že jedným z týchto indexov je môj index PK, môj primárny kľúč. Tieto ďalšie sa zdajú byť iba indexmi na zlepšenie prístupu k dotazom. Možno hľadáme podľa krstného mena alebo priezviska, alebo sa pozrieme na telefóny a PSČ. A ak tu vyberiem konkrétny index, napríklad tento PSČ, a dvakrát naň kliknem, teraz vidím, že je to index, ktorý nie je jedinečný, a tu sú niektoré ďalšie typy, bitmapa, nejedinečný, jedinečný, či už je alebo nie je triedený, či už ide o protokolovanie, či už ide o opačné poradie, či ide o funkčnú základňu. Oh, tu je zábava, ktorú som nezakryl. V skutočnosti môžete mať neviditeľné indexy. A povedali by ste: „Prečo by som sakra chcela urobiť neviditeľný index?“ Dobre, dám vám dobrý príklad. Ste vo svojom produkčnom systéme a máte problém s výkonom a nie ste si istí, že vytvorenie indexu problém vyrieši, takže ho nechcete vytvárať a spomaliť produkciu, ale nejako alebo iný, ktorý chcete byť schopný to otestovať. Môžete vytvoriť index vo výrobe ako neviditeľný, čo znamená, že ho nebude používať veľa kódov aplikácie, ktoré volajú optimalizátor. Bol vytvorený, je platný, ale nebude použitý. Potom môžete urobiť dotaz, o ktorom si myslíte, že by vám tento index pomohol, alebo sériu otázok, a môžete vložiť nápovedu a povedať: „Hej, optimalizátor, tam je neviditeľný index, ktorý chcem, aby si použil a nechal Ja viem, či som veci vylepšil. “A teraz som niečo testoval vo výrobe, ale neprerušil som aplikácie, ktoré bežali. To je použitie pre neviditeľný index. Znie to hlúpo, keď o tom prvýkrát počujete, ale má to zmysel.

V indexoch môžeme tiež určiť, či sú rovnobežné, a tiež to, v koľkých prípadoch sú rovnobežné. Teraz v prostredí bez klastrov alebo v reálnych klastroch aplikácií, takže bez regálov, by paralelne znamenalo, koľko čiastkových procesov môže môj dotaz vyvolať, aby sa pokúsil, a pracovné procesy, aby sa pokúsil získať vec rýchlejšie a rýchlejšie, A paralelnými príkladmi by bolo, že ak som v skutočnom klastri aplikácií, povedzme, že mám desať uzlov, koľko uzlov mám povolenie rozdeliť prácu? Možno sú to štyri z desiatich a na každom z nich štyri čiastkové procesy. To je príklad. A potom máme stlačenie kľúča. Môžete skutočne komprimovať indexy? Áno alebo nie. A potom samozrejme máte parametre úložiska, ktoré môžete zadať v indexoch. Teraz som ich nepokryl, pretože sú v skutočnosti skôr parametrom úložiska než problémom s indexom. A potom konečne máme, či ich chceme rozdeliť alebo nie. Nechaj ma to na chvíľu na chvíľu opustiť. Idem na inú schému. Toto je schéma hviezd a táto tabuľka období je napríklad tabuľkou dimenzií. Ak ste už niekedy navrhli hviezdnu schému, zvyčajne máte dimenziu času, a tak v tejto databáze a tejto hviezdicovej schéme je obdobie časovou dimenziou. Teraz viem, že to bude vyzerať smiešne, povieš: „Gee, pozri sa na všetky tie stĺpce - už ten chlap počul o normalizácii?“ No, keď ste v dátovom sklade alebo v schéme hviezdnych schém, zvyčajne máte non - máte tabuľky, na ktoré by sa typický človek pozrel a povedal: „Hej, tieto nie sú veľmi dobre navrhnuté.“ Ale takto to robíte v prostredí skladovania údajov.

Teraz sledujte, čo sa stane, pretože, dobre, sú tu všetky tieto stĺpce, pozrite sa na to, mám index na každom jednotlivom stĺpci. Teraz v prostredí OLTP, ktoré by bolo no-no. Spomalilo by to všetky moje operácie. V prostredí skladovania údajov by som ich spadol počas cyklov dávkového načítania. Zaťaženie bez režijných nákladov alebo indexov a indexy by som znova vytvoril. A ak som rozdelil svoju tabuľku, potom namiesto toho, aby som musel vynechať index pre každú skupinu v tabuľke, mohol by som len pustiť index na vedro alebo vedrá, do ktorých sa údaje budú ukladať počas tohto cyklu dávkového zaťaženia. A potom znova vytvorte iba časť indexu pre tieto vedrá. A preto je veľmi zvládnuteľná. A keď sa pozriem na - tak tu je stĺpec s názvom „Holiday Flag“ a v podstate je to áno alebo nie. Všimnite si, že toto je bitmapový index, a pre väčšinu z vás poviete: „No, to dáva zmysel.“ Áno alebo nie, Y alebo N, existujú iba dve hodnoty, ktoré dávajú zmysel. A pretože keď čítate dokumentáciu pre bitmapové indexy, vždy vám povedia, aby ste vybrali niečo s nízkou kardinálnosťou.

Teraz mi dovoľte vstúpiť do jednej z mojich faktických tabuliek, takže tu máme moje rozkazy. A toto sú moje rozkazy denne. A teraz uvidíte, že mám opäť niekoľko stĺpcov a znova budem mať viac ako niekoľko indexov. A tu máme niečo, čo sa nazýva univerzálny cenový kód. Bolo to pre maloobchod, takže viete tie malé čiarové kódy, keď niečo kúpite v obchode, jedná sa o univerzálny cenový kód. Teraz existujú milióny univerzálnych cenových kódov. Teraz pre túto konkrétnu spoločnosť, ktorá predávala veci, mali pravdepodobne 1, 7 až 2 milióny univerzálnych cenových kódov, takže budete očakávať, že sa nejedná o index bitovej mapy, pretože 1, 7 milióna odlišných hodnôt znie ako vysoká kardinálnosť. V skutočnosti však v prostredí skladovania údajov chcete, aby to bola bitmapa. Teraz mi dovoľte vysvetliť prečo. Pre tento univerzálny cenový kód môže existovať 1, 7 milióna odlišných hodnôt, počet riadkov v tejto tabuľke objednávok je v stovkách až miliardách riadkov. Môj index je nízka mohutnosť v porovnaní s veľkosťou alebo mohutnosťou tabuľky. Vďaka tomu je nízka mohutnosť. Vďaka tomu je index bitovej mapy užitočný, aj keď je to kontraintuitívne s 1, 7 milióna odlišných hodnôt, ktoré by ste si vybrali bitmapu. Ak by som teraz vedel, že chcem používať index bitmapovej mapy, produkt to momentálne nepodporuje, pridávam to pre ďalšie vydanie, ale to by bola ďalšia alternatíva. A v schéme hviezd si pamätajte, že bitmapový index by bol v tabuľke faktov a že jeden index v B-strome by ukazoval na riadok v tabuľke faktov a potom na každý riadok, ktorý bol pre túto skutočnosť zrejmý v tabuľke rozmerov., A tak tu máte inú možnosť. A tak uvidíme, chcem teraz vyjsť z tabuliek a chcem vám len rýchlo ukázať, že mám rovnaké informácie, pod indexmi, a urobím rovnakú základnú vec.

Teraz, dôvod, prečo som to vyniesol, je, že si môžete všimnúť, hej, tu nie sú žiadne primárne kľúče. Primárne kľúče sa robia s obmedzením kľúča, takže sa na ne skutočne vzťahujú definície definícií. Išlo by o indexy, ktoré nie sú súčasťou obmedzenia. Teraz by ste mohli povedať: „Počkajte minútu, čo by mohlo vyzerať ako cudzí kľúč, a cudzí kľúč je obmedzením, “ ale cudzie kľúče a väčšina databáz nevytvárajú automaticky index v stĺpci cudzích kľúčov, aj keď je to odporúčané a tam máte - opäť mám všetky rovnaké možnosti. A ak chcem zmeniť iba komprimovaný súbor, môžem to urobiť.

Teraz kompresia funguje iba na indexe B-stromu. To umožňuje, keď sa pozriete na rôzne uzly v B-strome, umožňuje to kompresiu niektorých hodnôt. V skutočnosti to nie je kompresia, ako je kompresia tabuľky, je to kompresia toho, čo je uložené v B-strome v ne-listových uzloch. Nezachráni to veľa priestoru, ale môže to zmeniť. A s tým som si všimol, že sa dostávam dosť blízko času, takže chcem urobiť to, že sa chcem vrátiť späť a zastaviť zdieľanie. A máme tu náš produkt na štrnásťdňovú skúšobnú verziu na adrese idera.com. Je to celkom dobrý produkt, najmä ak pracujete s viacerými databázovými platformami. Ak pracujete s dvoma alebo tromi rôznymi databázami, tento nástroj vám život oveľa zjednoduší. Máme nástroje, ktoré vám pomôžu s návrhom a výberom indexu, máme nástroj s názvom DB Optimizer. To som dnes nemohol pokryť, to by bolo príliš veľa. A ak ma chcete kontaktovať, je tu moja e-mailová adresa, je to, alebo ma môžete chytiť na môj súkromný e-mail a mám blogy, mám webovú stránku a blogy a profil LinkedIn. Takže neváhajte a oslovte ma na čokoľvek, aj keď to nesúvisí s produktom, ak chcete hovoriť iba o databázach, som srdcom geek a rád sa učím o technobabble.

Eric Kavanagh: Dobre, Dez, Robin, som si istý, že každý z vás má aspoň pár otázok, máme tu pár minút. Dez, čo si myslíš?

Dez Blanchfield: Mám jednu veľkú otázku, na ktorú sa vás musím opýtať, sedí to vzadu v mojej mysli. Aký najbláznivejší scenár ste videli? Čítal som váš blog, pozorne vás sledujem, ste - pravdepodobne ste jedným z mála ľudí, ktorí žili takmer v každej nepravdepodobnej situácii, a myslím si, že Dr. Robin Bloor je druhý, s ktorým som sa stretol môj život. Ale viete, pravdepodobne ste videli každý bláznivý scenár, aké sú niektoré z najbláznivejších scenárov, ktoré ste videli, s ktorými ste sa stretli, a ako ľudské bytosti, ktoré sa jednoducho nedokázali vyrovnať, sa vám podarilo chodiť a predvádzať triky Jediho s týmto celým DBArtisanom?

Bert Scalzo: Mali sme jedného zákazníka, ktorý vo svojom návrhu databázy veľmi rozmýšľal, ako by myslel pri návrhu rozloženia súborov, a tak - pri normalizácii databázy sa prvá vec, ktorú sa pokúsite urobiť, zbaví opakujúcich sa skupín. Mali stĺpec a urobili ho dlhým, alebo BLOB alebo CLOB, a v ňom by dali hodnotu, číslo jedna, bodkočiarku, číslo hodnoty dva, bodkočiarku, číslo hodnoty, bodkočiarku a mali by tisíce hodnôt tam, ale potrebovali hľadať v tomto stĺpci a sú ako: „Prečo táto vec beží tak pomaly?“ A ja som rád, „Nemôžete vytvoriť index toho, čo ste urobili, je to len nie sme povolené. “V skutočnosti sme im pomocou plánov ukázali, že to, čo musia urobiť, je normalizovať túto tabuľku. Nie preto, že normalizácia je nejaké akademické cvičenie, ktoré veci vylepšuje, ale preto, že chceli dotaz v tejto oblasti, čo znamená, že ho chceli indexovať, a nemohli ste ho indexovať podľa opakujúcej sa skupiny, alebo aspoň nie ľahko, A to je asi to najhoršie, čo som kedy videl.

Dez Blanchfield: Áno, je zaujímavé, ako často sa stretávate, myslím si, že výzva pre databázy, ľudia zabúdajú, že je to veda. A sú tu ľudia, ktorí robia tituly a PhD v tomto celom priestore, píšu o tom noviny a napísali ste celý lup vrátane vašich príručiek TOAD a ďalších vecí z pamäte. Tendencia smerujúca k „veľkým údajom“ v súčasnosti a citujem „veľa údajov“ - vidím, že veľa ľudí zabudlo na základy architektúry databázy a databázových technológií, databázových vied, ak sa vám páči. Čo vidíte v tejto oblasti, pokiaľ ide o posun od tradičných databázových platforiem a tradičných databázových myslení, že sme účinne pritĺkali k zemi, a to bol len prípad ladenia a škálovania výkonnosti. Vidíte veľa ľudí, ktorí sa znovu učia a majú skúsenosti, kde tam len tak sedia a majú „a-ha“ okamih, napríklad okamih Eureka, kde si uvedomujú, že tieto veľké dátové súbory sú vlastne len skutočne veľké databázy? Je to niečo tam a ľudia vám odpovedajú späť a tak nejako: „Zabudli sme, čo sme vedeli a môžete nás priviesť späť z temnej stránky?“

Bert Scalzo: Nuž, nie, a to je hrozné, musím to pripustiť, ale predajcovia relačných databáz pili aj Kool-Aid. Ak si pamätáte, neviem asi pred desiatimi rokmi, začali sme vkladať neštruktúrované údaje do relačných databáz, čo bolo niečo divné, a potom údaje, relačné databázy, teraz pridávajú typ NoSQL. veci. V skutočnosti, v Oracle 12, CR2 - viem, že to ešte nie je vonku - ale ak sa pozriete na beta verziu, ak ste v beta verzii, podporuje ostreľovanie. A tak teraz máte relačnú databázu, ktorá nepridala koncepciu zo systému NoSQL Sharding. A tak sa zdá, že okamih „a-ha“ je skôr pre ľudí na relačnej strane, ktorí idú „a-ha“. Nikto to nikdy neurobí znova, dokonca ani pre databázových manažérov, takže máme musím ísť a pripojiť sa k temnej strane.

Dez Blanchfield: Správne, takže hovoríte o posunu k mnohým chaotickým údajom, ak chápem správne, keď sa dostaneme do toho, čo teraz nazývame veľké dátové platformy, čo je trochu zábavné, pretože sú nie je to také staré, ale to ešte neznamená, že sa zameriavajú na to, čo robia so svojou relačnou databázou, aby dostali viac peňazí za svoje peniaze?

Bert Scalzo: Nie, zvyčajne, ak majú potrebu - to by bolo citátom „potreba veľkého typu údajov“, zisťujú, že namiesto toho, aby museli ísť na inú databázovú platformu a urobiť niečo v inej ako - predajcovia databáz im teraz poskytujú rovnaké ne-relačné techniky vo svojej relačnej databáze, aby mohli robiť tieto veci. Dobrým príkladom by bolo, ak máte neštruktúrované údaje, ako napríklad typ údajov JSON alebo iný zložitý typ údajov, ktorý má význam zabudovaný do samotných údajov, dodávatelia databázy to nielen podporujú, ale poskytnú vám ACID dodržiavanie neštruktúrovaných údajov. Relačné databázy prijali novšie techniky a technológie, a tak sa opäť zdá, že „a-ha“ nie je viac, „Hej, my, vývojári aplikácií, sme sa niečo odučili a musíme sa to znova naučiť, “ je to „ „Urobíme to týmto spôsobom teraz, ako to môžem urobiť vo vašej tradične relačnej databáze a ako to urobím v tejto databáze tu?“ a to je stále častejšie a ako som povedal, samotní dodávatelia databázy umožňujú že.

Dez Blanchfield: Áno, kto sú tradičnými podozrivými v tomto priestore pre nástroj DBArtisan a to? Urobil som nejaké domáce úlohy o tom, čo ste napísali nedávno, a z pamäte ste napísali niečo, myslím, že to bol jeden z vašich blogov, o extrémnom výkone databázy vo svete Oracle. Nemôžem si spomenúť, kedy to bolo, myslím, že to bolo niekedy tento rok z pamäti, alebo z konca minulého roka, napísal si túto vec. A zdalo sa mi, že to bol tradičný, obvyklý podozrivý na typ témy, o ktorej dnes hovoríme, kde ľudia pôjdu do veľmi rozsiahleho databázového prostredia a hľadajú to, čo v ňom voláte extrémne zisky. Kto sú obvyklé podozrivé osoby, ktoré vidíte vonku, ktorí sa ujímajú organizácie DBArtisan a využívajú ju správne?

Bert Scalzo: No, máme veľa zákazníkov, dnes som bol v skutočnosti s veľmi veľkou vládnou agentúrou, ktorá - a majú doslova pravdepodobne takmer 1 000 kópií nášho softvéru, pretože to ľuďom umožňuje sústrediť sa na to, čo „ nerobím to a nie ako to robiť. A je to v poriadku, myslím, že každý by mal vedieť, ako niečo urobiť, ale produktivita je „hotová“. Ak ma firma požiada o vykonanie úlohy, to je všetko, čo ich zaujíma. Kedy som dostal začiarknutie, aby som povedal, kedy bola úloha vykonaná? Nie akú techniku ​​alebo akú techniku ​​som použil, aby som sa tam dostal. Náš nástroj im teda umožňuje zamerať sa na to, čo je oveľa produktívnejšie, a to je skutočne veľká výhoda, a ako som povedal, niektoré databázy ponúkajú nástroj len pre svoju databázovú platformu. Ponúkame ho pre dvanásť databázových platforiem. Mám rovnaký pracovný postup, rovnaké grafické užívateľské rozhranie, rovnaké navigácie. Ak viete, ako používateľovi udeliť privilégium alebo ako vytvoriť tabuľku alebo vytvoriť index v databáze, môžete to urobiť vo všetkých dvanástich, pretože ide o rovnaký vzhľad a dojem a rovnaký pracovný postup. To má pre našich zákazníkov obrovskú hodnotu.

Dez Blanchfield: Áno, myslím, že ľudia chcú získať oveľa viac tresku za svoje peniaze zo svojich ľudských zdrojov. A dni, keď majú jednotliví špecialisti na Oracle, Ingres a DB2, sú preč. Od ľudí sa očakáva, že budú Jackom všetkých obchodov, takže si myslím, že táto vec ich životy úplne zachránila.

Ešte jedna posledná rýchla vec, než som ju podal doktorovi Robinovi Bloorovi. Uviedli ste, že na štrnásť dní máte k dispozícii bezplatné stiahnutie, čo sa deje - ak sa chystám do toho a urobím to, mimochodom, dám to do technologického laboratória Bloor a roztočím túto vec a zdvihol ruky na to sám - pred dnešným časom som nemal šancu to urobiť. Spomenuli ste štrnásťdňovú skúšobnú verziu, povedali ste, že ju používate na počítači VM, predpokladám, že je to laptop. Aké sú, aké je nastavenie na základnej úrovni pre niekoho, kto by mal začať pracovať a používať štrnásťdňovú skúšobnú verziu, tesne predtým, ako sa vrátim Robinovi na jeho otázky?

Bert Scalzo: Akékoľvek prostredie Windows, teda Windows 7, virtuálny stroj s jedným procesorom a štyrmi koncertmi pamäte. Nie sme skutočne tučný alebo drahý nástroj. Ak by ste teraz chceli spustiť databázový server v tom istom virtuálnom počítači pod tým istým Windows, áno, budete musieť pridať ďalšie, ale ak databázu prevádzkujete na databázovom serveri alebo na samostatnom virtuálnom počítači, VM sa načíta a spustenie nášho produktu je veľmi ľahké: jeden procesor, štyri koncerty pamäte, takmer akákoľvek verzia systému Windows - a podporujeme inštaláciu tridsaťdva a šesťdesiatštyri bitov. Musíte však nainštalovať klienta dodávateľa databázy. Takže ak ste sa chceli pripojiť k Oracle, musíte nainštalovať sieťového klienta SQL, pretože to je to, čo Oracle vyžaduje, aby ste mohli hovoriť s databázou.

Dez Blanchfield: Znie to celkom jednoducho. Myslím si, že jedna z týchto vecí viac než čokoľvek iné, v čo dúfam, že ľudia odnesú preč, okrem uvedomenia si, že tento nástroj zachráni svoje životy, je to, že by mali ísť a stiahnuť si ju a hrať si s ňou, vzhľadom na to, že ponúkate štrnásťdennú bezplatnú skúšobnú verziu. A môže bežať na svojom súčasnom notebooku bez toho, aby inštalovalo čokoľvek navyše, pretože ak už spravujú databázu, už pracujú s databázami, všetky tieto nástroje majú zavedené a či už beží na lokálnom virtuálnom počítači alebo na svojich na miestnej pracovnej ploche to znie, ako by bolo bezbolestné nainštalovať a hrať sa. Preto vrelo odporúčam ľuďom, aby to urobili.

Robin, som si istý, že máš otázky a Eric, pravdepodobne máš nejaké od publika, takže Robin, čo ti mám odovzdať a potom späť k Ericovi?

Robin Bloor: Áno, dobre, dobre musím povedať, myslím, že vždy som túto oblasť fascinoval, pretože to bolo - odrezal som si od nej zuby. Pravdou však je, že asi od roku 1998, 1999 som sa obával toho, čo je Oracle skutočne schopný. A vedel som, že Sybase a Microsoft SQL Server sú oboje pomerne jednoduché v porovnaní s tým, čo by mohla spoločnosť Oracle urobiť. Keď ste sa mi rozosmiali, myslím, zakryl som si ústa, keď ste začali hovoriť o ostreľovaní. Oracle to urobil predtým. Oracle predstavil v určitom okamihu, oni boli nervózni objektovo-relačné myšlienky, tak predstavili schopnosť vytvárať druh notácie objektov a ukladanie objektov v Oracle, a ja som hovoril s jedným z ich inžinierov, niečo ako pár rokov potom, čo ho predstavili, spýtal som sa, koľko ľudí ho použilo, a povedal, že si myslím, že to vyskúšali dvaja zákazníci a to bolo všetko. A myslím si, že to isté sa stane, keď sa začnú snažiť robiť trendy v NoSQL. Vieš, myslím si, že je to chyba, myslím, že ma trochu zaujímajú, aké sú vaše myšlienky. Určite pijú Kool-Aid. Majú pocit, že musia byť schopní robiť tvrdenia podobné veľkým databázam NoSQL ako Cassandra, ale viete, má to pre vás nejaký zmysel?

Bert Scalzo: Nie, narazil si na nechty priamo na hlavu. Pre mňa by som si vybral relačného dodávateľa, ako je Oracle alebo SQL Server alebo DB2 alebo Postgres, ale ak urobím niečo, čo nie je relačné, vo veľkom dátovom priestore alebo v priestore NoSQL si vyberiem ten správny nástroj pre tú správnu prácu. A nemyslím si, že by to malo byť, samozrejme, najskôr môj predajca relačných databáz. A potom k tomu pridáte ďalšiu vrásku, čo je, čo je dostupné v cloude? Toľko ľudí, ktorí chcú dostať svoje databázy mimo predpoklad. Potom sa musíte pozrieť na svojho poskytovateľa cloudu a povedať: „Dobre, čo poskytujete, aké databázy máte pre mňa k dispozícii, ktoré vyhovujú mojim potrebám a aké predajné sú, a úprimne povedané, aká je sadzba alebo poplatok za používanie tejto databázy. v cloude za hodinu alebo za deň. A na gigabajt alebo terabajt? “A čo nájdete, možno sú niektoré z relatívne novších databáz, ako napríklad Mongo alebo Cassandra, možno ich ceny sú lacnejšie, takže ak budete robiť veľké dáta typu petabyte, možno musia - z hľadiska nákladov - vziať do úvahy databázy NoSQL v cloude, pretože môžu byť nákladovo najefektívnejším spôsobom.

Robin Bloor: Áno, správne. Myslím tým, že môj druh - vec relačných databáz podľa mojej skúsenosti - ktorá je dosť dlhá na jazvy, to je isté - existuje veľa zdravého rozumu, že ak ju začnete používať a - chápete, čo to v skutočnosti je, že „Myslím, že si pamätám, že som raz urobil nejaké poradenstvo s jedným zákazníkom, a doviedli ma do miestnosti, urobili akýsi entitný diagram a vytvorili tretiu normálnu formu, model toho, čo boli primárne systémy spoločnosti. Mal okolo dvesto štyridsať stolov a povedali: „Dobre, čo si o tom myslíš? Budeme na to stavať databázu, “a povedal som:„ Čo si o tom myslíte? “Povedal som:„ Nemyslím si, že to bude fungovať. “A je to presne tak, viete, pretože končili s cieľom vytvoriť konkrétnu štruktúru v rámci jedenástich spojení. A to je to, čo treba pochopiť o vzťahu. Takže ma trochu zaujíma to, do akej miery sa stretávate so zlým dizajnom. Myslím, že nemám problém s DBArtisan - robí to veľmi rozumné veci a skutočnosť, že sa skutočne dokážete zobraziť na viacerých platformách, je úžasná - ale koľko sa tam stretnete tam, kde je problém s dizajnom kde si ľudia mohli vyriešiť najrôznejšie zármutky, ak by prišli skôr na hviezdnu schému, než aby sa o tom dostali snehová vločka, viete?

Bert Scalzo: No, nechcem to znieť ako protivný alebo arogantný, ale povedal by som častejšie ako nie. Je zrejmé, že väčšina databáz, ktoré sa tam venujem, má problémy alebo problémy. Čo je dobré, pretože naše nástroje, ako náš nástroj na optimalizáciu databázy, im môžu pomôcť vyriešiť tieto problémy, a čo je pre mňa naozaj zábavné, je to, že veľa problémov sú rovnaké jednoduché problémy znova a znova. Raz som pracoval so zákazníkom, ktorý mal jedenásťnásobný dotaz na pripojenie, a ja som rád: „Dobre, prečo ste nepoužili klauzulu s klauzulí?“ A sú ako „No, ja som Neviem, čo to je. “A potom som povedal:„ A pozrite sa na vaše čiastkové výbery tu na vašich korelovaných a nekorelovaných, “povedal som:„ V niektorých prípadoch máte klauzulu, kde na najhlbšej úrovni, odkaz na tabuľku z vonkajšej strany. “Povedal som:„ To je, posuňte ju na správnu úroveň, nevložte ju hlbšie, ako to musí byť, zmiasť optimalizátor. “A pomocou niekoľkých vylepšení vzali niečo, čo bežalo asi dve hodiny a znížili ho na desať minút a bolo to len - v tom prípade sme neurobili nič iné, ako vylepšili SQL, ktorý napísali. Myslím si, že problémom je, že veľa univerzít a veľa ľudí, ktorí sa učia programovať v neuniverzitnom prostredí, sa to učia ako zaznamenané procesy alebo procesy orientované na riadky a relačné, je súbor orientovaný prírodou, takže vy musieť premýšľať v sadách, aby napísal dobrý SQL.

Robin Bloor: Áno, myslím si, že je to presne tak. A musíte pochopiť, že sú to také veci, že ľudia by mali poznať ABC takýchto vecí. Nezáleží na tom. Nebudete schopní robiť racionálne veci, ak si neuvedomíte, že aj dobre navrhnutá dobre premodelovaná databáza, spojenie bude nejaký čas trvať, druh si bude vyžadovať čas. Robia to preto, že svet nikdy nenašiel spôsob, ako dosiahnuť, aby títo ľudia rýchlo postupovali. Našli spôsoby, ako usporiadať údaje, takže idú rýchlejšie ako inak, a veľa entuziazmu, ktoré musím povedať pre databázy NoSQL, je jednoducho to, že sa vyhýbajú pripojeniu. Začnú budovať databázy s rovnakým šírením údajov v nich, pretože ak sa pripojíte k niektorej z databáz NoSQL, môžu sať. Nemyslíš?

Bert Scalzo: Oh úplne. A ja sa musím smiať, pretože som začal s cestou späť pred relačnými databázami a späť, keď Ingres bol RTI, Relational Technology Institute, a nemali sme SQL, mali sme pred-SQL relačné jazyky. Myslím, že v Ingrese sa vtedy nazývalo Quel. Takže ste sa dostali z týchto starých databázových paradigiem, ako je sieť a vyššie grafické alebo hierarchické, a vy ste prešli relačnými paradigmami po niekoľkých desaťročiach a teraz mi pripadá, že sa vraciame späť k takmer hierarchickým. Je to takmer ako by sme sa vrátili.

Robin Bloor: Áno, správne. Radšej vám dáme Erica, trávim príliš veľa času, ale máme nejaké otázky od publika, Eric?

Eric Kavanagh: Máme, máme pár. Ideme tu trochu dlho, ale hodím na vás pár. O neviditeľných indexoch sme mali niekoľko otázok. Jedna otázka bola: „Musí niekto použiť váš nástroj, aby ich mohol vidieť?“ Ďalšia otázka bola: „No, čo ak ste slepí?“

Bert Scalzo: To je dobrý.

Eric Kavanagh: Zvedavá otázka, tak len FYI.

Bert Scalzo: Nie, nemusíte mať naše nástroje. Toto je funkcia Oracle, index invisibles. V podstate v dátovom slovníku si Oracle ponecháva iba časť metadát, ktorá hovorí: „Optimalizátor, tento index ignoruje. Je to tu, ale pokiaľ nie ste fyzicky inštruovaní prostredníctvom nápovedy v názve optimalizačného tipu v príkaze SQL, nepoužívajte to. “A tak nie, nemusíte mať naše nástroje a vo všetkých ohľadoch je obyčajný starý index, môžete ho vidieť v akomkoľvek nástroji, je to len optimalizátor, ktorý povie: „Pri bežnom spracovaní dotazov ho budeme ignorovať.“ Ak chcete, aby bol zvyknutý, musíte ho nasmerovať. Je to skutočne užitočné pre scenár, ktorý som opísal, ktorý je, ak by ste chceli vytvoriť index vo výrobe, ale neriskovali by ste rozbitie správ alebo veci, ktoré už fungujú, ale chceli ste ich otestovať, môžete to urobiť. To je to, pre čo je to najužitočnejšie.

Eric Kavanagh: To je dobré a potom tu bola ďalšia dobrá otázka. „A čo niektoré z týchto nových databáz v pamäti? Ako zmení technológia databázy v pamäti hru v súvislosti s indexovaním? “

Bert Scalzo: Chlapče, dobre - teraz je to dobré, som rád, že niekto položil túto otázku, budeme musieť ísť ďalšiu pol hodinu. Nie, pamäť v pamäti závisí od dodávateľa databázy. Teraz, normálne, ja nehovorím nič iné, než chvála všetkého, čo robí Oracle, pretože je to úžasná technológia, ktorú vytvorili, ale keď sa odtrhnete pod kryty a pozeráte sa, čo je v pamäti v Oracle, v Oracle databázu, v skutočnosti je to stále vedený ukladací priestor na disku, a dostane načítaný stĺpcový ukladací priestor do pamäte, a ak nie je dostatok pamäte na uloženie celej tabuľky, vráti sa späť k častiam; nezmestí sa to do pamäti, do skladov riadkov, takže môžete skutočne urobiť výber oproti stolu a pre polovicu tabuľky použijete indexovanie, ktoré zasiahne tradičné riadky pri stole, a pre druhú polovicu výber je to, že to vlastne vyjde a všetko popadne z prehľadávania v pamäti, a tak sa líši napríklad tým, že ho SQL Server implementoval pomocou technológie Hekaton, viete, a SQL 2014 a vylepšil sa v SQL 2016, ale v niektorých ohľadoch, je ich vernejšou verziou in-memory a, ale každá implementácia má svoje klady a zápory, ale musíte sa nejako pozrieť pod kryty a uvedomiť si. Pretože som mal zákazníka, ktorý povedal: „Ach, táto tabuľka je v pamäti - ja budem zostavovať všetky indexy, “ a ja som rád, „tabuľka je väčšia ako pamäť, ktorú máte na serveri, takže v určitom okamihu musia niektoré otázky zasiahnuť disk. “

Eric Kavanagh: To je dobrý popis; to je dobré. Ľudia, do konca tohto roku sa chystáme na pár ďalších webcastov s týmito chlapcami. Vráťte sa kedykoľvek, keď budete počuť, že je Bert na prezentácii, pretože vieme, že pozná svoje veci. Je vždy zábavné hovoriť s odborníkmi. Všetky tieto webové vysielania archivujeme pre neskoršie prezeranie. Tu uvádzame kontaktné informácie spoločnosti Bert a my sa pokúsime tento odkaz prevziať na stiahnutie a odoslať ho tiež e-mailom, ale vždy môžete svoj e-mail poslať naozaj pravdivo: máme pre tento účel usporiadaných veľa ďalších webcastov. rok a robíme ed cal práve teraz, takže, ľudia, ak existujú nejaké témy, ktoré naozaj chcete počuť o budúcom roku, nehanbite sa: Postarajte sa, ľudia, budeme sa s vami baviť nabudúce. Bye-bye.

Partner obsahu Techopedia

Zamestnanci Techopedia sú prepojení so spoločnosťou Bloor Group a je možné ich kontaktovať pomocou možností napravo. Informácie o tom, ako spolupracujeme s priemyselnými partnermi, nájdete tu.

• Profile
• webové stránky