Rodyklės beprotybė: kaip išvengti duomenų bazės chaoso

Autorius „Techopedia“ darbuotojai, 2016 m. Spalio 5 d

„Takeaway“: Priėmėjas Ericas Kavanaghas aptaria duomenų bazių indeksavimą su dr. Robinu Blooru, Dezu Blanchfieldu ir IDERA Bertu Scalzo.

Šiuo metu nesate prisijungęs. Jei norite pamatyti vaizdo įrašą, prisijunkite arba prisiregistruokite.

„Techopedia“ turinio partneris

„Techopedia“ personalas yra susijęs su „Bloor Group“ ir su juo galima susisiekti naudojant dešinėje pateiktas parinktis. Norėdami sužinoti daugiau informacijos apie tai, kaip mes dirbame su pramonės partneriais, spustelėkite čia.

• Profilis
• Interneto svetainė

Erikas Kavanaghas: Ponios ir ponai, sveiki ir dar kartą pasveikinkite. Tai trečiadienis, ketvirtą valandą rytų, ir tiems iš jūsų, kurie žino programą, žino, ką tai reiškia, atėjo laikas kitam „Hot Technologies“ epizodui. Taip išties. Mano vardas Ericas Kavanaghas, aš būsiu jūsų šios dienos sesijos moderatorius: „Indeksavimas beprotybė: kaip išvengti duomenų bazės chaoso“. Arba kaip aš tai minėjau paskutiniame el. Pašto sprogdinime, kad išeitų, kad „duomenų bazė klaidžioja“. Karštas terminas šiomis dienomis yra „nemalonus“. Visi tai daro. Čia yra jūsų skaidrių skaidrumas. Ir pakankamai apie mane.

Taigi „Hot Technology“ serija iš tikrųjų buvo skirta apibrėžti tam tikrą erdvę, priešingai nei „Briefing Room“, kuris yra tiesiog vienas prieš vieną gyvas analitikų instruktažas, „Hot Tech“ mes gauname du analitikus. Šiandien tai bus mūsų pačių gydytojas Robinas Blooras ir mūsų duomenų mokslininkas Dezas Blanchfieldas. Ir mes kalbame tema, kuri, mano manymu, yra gana simboliška to, kas vyksta rinkoje šiandien.

Esmė ta, kad šiomis dienomis esame sudėtingumo pasaulyje. Tikrai, jei pagalvojote penkiolika ar dvidešimt metų, tuometinis pasaulis buvo labai skirtingas, ypač duomenų bazių technologijos srityje. Duomenų bazės buvo gana paprastos. Jų buvo tik saujelė; dauguma jų buvo reliatyvūs. Dabar turime visą duomenų bazių technologijų paketą. Žodžiu, daugybė variantų ant stalo visiems, norintiems sukurti programą ar ką nors padaryti su duomenimis. Viskas keičiasi ir tai daro įtaką žmonėms, kurie bando valdyti šias sistemas. Šiandien kalbėsimės su Bertu Scalzo, kuris yra tikras šios srities ekspertas; jis yra „IDERA“ vyresnysis produkto valdytojas apie tai, ką galite padaryti, kad sutvarkytumėte visus tuos duomenis. Turėdamas tai perduosiu gydytojui Robinui Bloorui, kad jis atimtų. Robinai, grindys tavo.

Robinas Blooras: Gerai, ačiū už įvadą. Manau, kad kadangi tai yra dviejų rankų dalykas, manau, kad apskritai kalbėčiau apie duomenų bazių optimizavimą kaip įvadą į šį „Hot Tech“ šou. Aš pradėjau gyvenimą - technologijos ir analizės srityse - pradėjau tai daryti, nes anksčiau rašydavau straipsnius apie duomenų bazių galimybes DEC VAX platformoje. Dėl šios priežasties duomenų bazės leidėjai mane trumpai informavo. Man taip atsitinka, kodėl turėtumėte duomenų bazę? Aš turiu omenyje, kad tais laikais siaubingai daug žmonių naudodavo svarbiausių failų kūrimą ir naudodavo juos tam tikram indeksų nuoseklumui, kaip mes juos vadiname, bet norėdami sukurti tam tikrą duomenų bazės galimybę, ir žinote, kodėl turėtumėte dar kas nors?

Atsakymas į tai, manau, yra geriausias Michaelio Stonebrakerio atsakymas ir jis pasakė: "Duomenų bazė gali sužinoti daugiau apie tai, kur yra duomenys ir kaip greitai juos gauti, nei bet kuri programa gali žinoti." Ir manau, kad tai įdomu; tai yra žaidimo pobūdis. Bet 19–1989 m., Kai pradėjau analizuoti technologijas, ir jūs žinote, tuo metu duomenų bazės buvo labai paprastos, o reliacinės duomenų bazės - labai paprastos. Jie turėjo tiek mažai galimybių, turiu omenyje, kad, be abejo, jie galėjo saugoti duomenis. Jūs galėjote sukurti atsarginę kopiją ir jie turėjo ACID reikalavimus, tačiau tikrai turėjo labai silpnus optimizatorius. Tiesą sakant, sunku būtų teigti, kad jie išvis turėjo optimizavimo galimybę.

Vėliau jie darėsi vis geresni, bet, žinote, kai duomenų bazė neveikia - nes šios kengūros vienaip ar kitaip rodo - gali būti be galo daug priežasčių, kodėl tai vyksta lėtai. Ir tai priveda mane prie minties: Duomenų bazės turi daug funkcijų, tačiau svarbiausia yra užklausų optimizavimas. Jei jie to nepadarytų, jūs jų nenaudotumėte. Tai yra greitas informacijos gavimas, tai yra galimybė tai padaryti, kai yra daug vienu metu besinaudojančių vartotojų, ir tai yra sunki problema. Ir kai jūs iš tikrųjų pažvelgsite į, vadinkime jas brandžiomis duomenų bazėmis, jei jums patinka - bet neabejotinai „Oracle“, šiek tiek mažesniu mastu - „Microsoft SQL Server“, be abejo, „Teradata“ ir „DB2“ - tų duomenų bazių optimizatoriai turi dešimtmečius. pastatas. Žinote, jie ne - kai kas nesėdėjo - šešis vaikinus dviese, metus, projektą ir tiesiog numuškite vieną kartu. Tai neveikia taip. Palaipsniui augo optimizavimo galimybės, todėl reikia daug augti. Šiaip ar taip, pakalbėkime apie duomenų bazės foną. Na, dabar yra be galo daug ką pasakyta apie „NoSQL“ duomenų bazę, ir netgi yra didelis entuziazmas dėl grafikų duomenų bazės. SQL naudojimas per Hadoop ir panašūs dalykai. Tiesa ta, kad dabar norite duomenų bazės, jei norite visiškai funkcionalaus, galinčio OLTP ir didelio užklausų srauto, tai yra reliacinė duomenų bazė, arba tai nieko.

Tarp reliacinių duomenų bazių populiarumas yra „Oracle“. „Microsoft SQL Server“, manau, yra antra. Jie abu gali būti naudojami OLTP ir užklausų darbo krūviui, tačiau iš tikrųjų jūs negalite atsikratyti sumaišydami tuos darbo krūvius. Jums reikia skirtingų įvykių, susijusių su OLTP ir užklausų darbo apkrovomis. Yra SQL ir grafiko alternatyvų. Daugelis kompanijų standartizuoja vieną konkrečią duomenų bazę, todėl aš turiu omenyje, kad po dešimtmečių kovos su visais kitais žaidėjais „Oracle“ tapo dominuojančia. Paprasčiausiai todėl, kad jie galų gale galėjo parduoti įmonių licencijas, taigi įmonės naudotų alternatyvius produktus tik išskirtiniuose produktuose, kurių „Oracle“ paprasčiausiai nepadarytų. Duomenų bazės yra strateginės tuo atžvilgiu, kad jos tobulėja. Ir jūs žinote, kad aš šiek tiek ištyriau šį pristatymą, ir tai yra savotiška - aš po to šiek tiek apsilankysiu, bet yra įdomu, kaip jie vystosi, žiūrint į tai iš DBA pozicijos. Tai aš vadinu nematoma tendencija. Tai Mūro įstatymas kubinis. Tai maždaug tokia: Didžiausia duomenų bazė yra ir naujos duomenų bazės, nėra senos duomenų bazės, kuriai būtų prarasta daug daugiau duomenų. Paprastai tai duomenų bazė, taikoma naujai problemai. Ir jie iš tikrųjų auga pagal duomenų apimtį. Maždaug ties Moore'o kubu įstatymas. Taigi Moore'o įstatymas yra dešimt kartų per šešerius metus koeficientas. VLDB kas šešeri metai paprastai auga tūkstančio koeficientu. 1991 m., 1992 m. Didžiosios duomenų bazės buvo išmatuotos megabaitais. '97 ir '98, gigabaitai. 2003, '4, terabaitai. 2009 m., '10 m., Jūs pradėjote matyti petabaitų duomenų bazes. Aš manau, kad šiuo metu ten galbūt buvo viena ar dvi exabyte duomenų bazės, bet didžiausia, apie kurią aš girdėjau, yra 200 petalatų laiku, ir jūs žinote, kad nepateko duomenų į petabaitų duomenų bazes. Bet, aišku, tai bus naujos didelės žiniatinklio 2.0 kompanijos, galbūt, jūs turite „Facebook“ šia linkme.

Bet kokiu atveju, jei jūs iš tikrųjų pažvelgsite į tai, tikėdamiesi, kad duomenų bazė padidins tokio pobūdžio apimtį, ji klausia labai daug. Ir nepaprastai gerai, žinoma, iki petabaidų lygio, atrodo, kad jie padarė pakankamai gerai. Aš turiu omenyje senesnius produktus, o ne ką nors naują. Atrodo, kad jiems sekėsi nepaprastai gerai. Jei pažvelgtume į duomenų bazės veikimą, trūkumus, tai sugrįžtų į laiką, kurį aš joms rūpėjau, ir turėjau jaudintis. Jūs žinote, kad tai iš esmės yra aparatinės įrangos suskirstymas. Yra procesoriaus trūkumų, gali būti atminties trūkumų, yra disko trūkumų. Gali būti, kad tinklas sukelia sielvartą, taip pat gali kilti problemų dėl užrakinimo, atsižvelgiant į tai, ką darote, tačiau paprastai taip yra todėl, kad programa nežino, kam skambinti užraktui. Taigi, jei ketinate sureguliuoti duomenų bazę, jūs iš tikrųjų bandote ją sureguliuoti taip, kad ji kuo geriau šoktų tarp šių penkių galimų kliūčių. Tai nėra lengvas dalykas, nes dramatiškai padidėja atminties kiekis, kurį galėtumėte sukonfigūruoti bet kuriame serveryje. Tuomet procesoriai tapo daugiagysliais, diskiniais, ką dabar galime padaryti, manau, net ir prekių serveriuose, manau, jūs galite padaryti šimtus ir šimtus terabaitų, ketvirtadalį petabaito, gal net prekių serveryje. Taigi, su visais šiais dalykais galite žaisti, tinklas, žinoma, gali judėti skirtingu greičiu, tačiau dažniausiai dirbdami su duomenų bazėmis tikrai norite, kad tarp serverių būtų pluošto kabeliai, o nieko daugiau, būtent to, ypač kad taip.

Duomenų bazės veikimo veiksniai. Aš turiu omenyje tai, kas visa tai bus, nes aš žinau, kad Dezas apie tai kalbės, tačiau blogas duomenų bazės dizainas reiškia prastai veikiančią duomenų bazę. Netinkamas programavimo dizainas gali reikšti labai kvailo SQL įmetimą į duomenų bazę, o tai užtruks baisiai daug ilgiau. Sutapimas ir darbo krūvis, per didelis suderinamumas sukels kliūčių mažinimo problemas. Darbo krūvio derinimas, kai turite didelių užklausų su labai mažomis, trumpomis, aštriomis užklausomis, dėl to kyla problemų. Iškilo apkrovos balansavimo problema. Daugelis duomenų bazių tuo rūpinasi, tačiau jei neturite sudėtingesnio produkto, tuomet žinote, kad pridedate tik kelis serverius, o tai nėra viskas, ką darote, jei iš tikrųjų norite padidinti klasterio dydį. Prieš pasiekdami optimalų našumą, iš tikrųjų turite subalansuoti apkrovą. Turite planuoti pajėgumus. Visiškai. Ypač šiais laikais, kai duomenų apimtys padidėja labiau nei įprasti duomenų bazėms. Yra daugybė duomenų lygmens problemų, susijusių su duomenų praradimu, duomenų perkėlimu. Laiku nepateikus duomenų į duomenų bazę, vėliau gali kilti našumo problemų, nes mes perėjome nuo „Windows“ duomenų bazių prie dvidešimt keturių septynių tris šimtus septyniasdešimt penkių operacijų ir nėra langų, kuriuose būtų galima sulėtinti duomenų bazės veikimą. duomenų bazės ar mažai tikėtina, kad šiais laikais jos bus.

„Oracle DBA“ problema. Apie tai galvojau aš. Aš buvau „Oracle“ DBA su „Oracle 7“ ir prisimenu, kaip tai suderinti. Ir jei jūs iš tikrųjų žiūrite į „Oracle“ dabar, tai būdas, būdas - tai daugiau, tuo daugiau galimybių. Čia pateiktas bitkoinų indeksavimas ir panašūs dalykai, tačiau aš iš tikrųjų užtrukdavau laiko, kad pamačiau ir pamatyčiau, kiek iš tikrųjų „Oracle“ duomenų bazėje yra nustatymų parametrų. Yra daugiau nei trys šimtai penkiasdešimt derinimo parametrų ir dar šimtas paslėptų parametrų, apie kuriuos DBA specialistai gali žinoti, bet apie normalius „Oracle“ DBA. O tai reiškia, kad tokio tipo duomenų bazių derinimas yra sunkus dalykas. Tai visai nėra paprastas dalykas. Jūs turite tai jausti, jūs turite tai daryti ilgą, ilgą laiką ir jūs turite tiksliai žinoti, kokią problemą, jūsų manymu, išsprendžiate, nes derinimas prasideda tada, kai spektaklis tampa prastas, bet gali būti, kad ne viskas. Tai gali būti svarbių konkrečių užklausų atlikimas, ir jūs galite tai ištaisyti, susiedami tam tikrus duomenis ir atmintį, arba gali reikėti ištaisyti juos indeksuodami, arba gali reikėti pradėti skirstyti į skaidymą kitaip. Yra daugybė dalykų, kuriuos galite padaryti, yra esmė. Taigi, jie to nesiruošia daryti galvoje - DBA reikia įrankių. Dabar perduosiu Dezui, kuris, manau, papasakos jums apie indeksavimą.

Erikas Kavanaghas: Gerai Dezai, atimk jį.

Dez Blanchfield: Ačiū, Robinai, ir man patinka viršelis. Manau, kad numetėte ten laužą, kad galėčiau ateiti net nuotoliniu būdu šalia kažko įdomaus. Bet aš panaudojau mūsų mažosios galaktikos atvaizdą, kaip mano požiūris į tai, koks tapo šiandienos iššūkis duomenų bazių administratoriams, nes tai yra tas psichinis įvaizdis, kurį aš linkęs sužavėti patekęs į aplinką ir nebesu tas duomenų bazių administravimo ar duomenų bazių projektavimo to lygio pasaulyje. Tačiau, kaip ir jūs, Robinas ir aš daug metų buvome įsitraukę į duomenų bazių pasaulį kaip administratoriai ar kūrėjai, arba galiausiai kaip architektai, ir tada supratau, kad galiu padaryti geresnius dalykus, kad užsidirbčiau plutos. Tačiau paprastai jaučiasi, kad žvelgiate į šią duomenų galaktiką, ir tuo labiau, kad šiandien, kaip jūs apibūdinote, mes perėjome nuo megabaitų iki petabaitų ir egzoskalo per labai trumpą laiką., pagal didžiąją dalykų schemą. Bet manau, kad galvoje yra frazė, kad duomenų bazių rodyklės dabar yra juodasis menas ir tai nėra iš tikrųjų tokie dalykai, kuriuos paprasčiausi mirtingieji turėtų įsisprausti į verslo lygio verslo programas ir tai, kaip suformuluoti jus. buvo tik kalbama apie. Bet aš norėjau greitai perprasti istorijos, kurią turėjau su duomenų bazių pasauliais, tipą ir patekti į kontekstą ten, kur mes padarysime išvadą, ir po to peržvelgti medžiagą šiandien su draugais „IDERA“, nes, manau, kad reikia daug galvoti apie tai, kaip suderinti duomenų bazės našumą, ir vienas iš jų yra skardos metimas į daiktą. Daugeliui parduotuvių, su kuriomis aš susiduriu, jos visada nesiekia atlikti duomenų našumo nustatymo duomenų bazės ir ypač rodyklės sluoksniuose, kol neįsigilinę į sunkų mąstymo kelią jie gali mesti imtuvą į jį. .

Daugelis žmonių, mano manymu, tiesiog naudojasi dideliu geležiniu požiūriu, ir aš čia turiu „The Flash“ nuotrauką, nes jei jūs kada nors žiūrėjote kokius nors senus filmus ar tikrai naujausią „The Flash“ televizijos laidą, kaip kad „Flash Gordon“ yra senasis veikėjas, o dabar, kai jis vadinamas „Blykste“, jis linkęs eiti labai, labai greitai ir visada jo energija pritrūksta. Ir tai nutinka, kai jūs metate didelę reikšmę duomenų bazės veikimui. Visada, mano patirtimi, jūs galite įdėti aukštą našumą ir sunkų darbą žaidime, galite optimizuoti operacines sistemas ir suderinti jas iki tam tikro taško. Galite būti tikri, kad turite greitus daugiagyslius, daugiasriegius procesorius, kad programa būtų paleista greičiau, galite įmesti daug RAM, galite turėti didelio pralaidumo fonus, pereiti nuo standžiųjų diskų iki talpyklinių kietųjų diskų į kietą būseną., ir didelio našumo saugyklų masyvas. Ir net dabar žmonės į savo duomenų bazės variklius įmeta tokius dalykus kaip „Flash“ ir „NVMe“, manydami, kad jie gaus šį prisijungimo laiką dvigubai efektyviau. Ir visada jie iš to gauna tam tikrą naudą. Tačiau visa tai grįžta prie tų pačių pagrindinių atlikimo derinimo problemų. Daugybė mažai uždelstų tinklo jungčių, kad klasteriai veiktų greitai. O klasterių duomenų bazių infrastruktūra, taigi jūs turite ne tik vieną mašiną, atliekančią visą darbą. Tačiau jūs linkę grįžti prie tos pačios pagrindinės našumo problemos ir tai yra duomenų skaitymas. Duomenų rašymas dažniausiai yra gana linijinis iššūkis ir nebent tai būtų padaryta tinkamai.

Ir tada mes turime iššūkį šiandieniniame pasaulyje: ne visos duomenų bazės yra sukurtos lygios. Yra duomenų bazės ir citata su citata „duomenų bazė“. O galvodami apie duomenų bazių variklius, žmonės dažnai galvoja apie tradicinius, įprastus įtariamuosius, kokie jie buvo SQL pasaulyje. Žinote, mes turime „Oracle“ ir „Microsoft SQL Server“, o atvirojo kodo pasaulyje yra pora su „MySQL“, kuri dabar priklauso „Oracle“, tačiau ji vis dar yra atviro kodo. Tada mes turime ne tokius įprastuosius įtariamuosius kaip „NoSQL“ variklius, kuriems vis dar kyla problemų dėl indeksavimo ir našumo valdymo, ir aš nenagrinėsiu jų iki smulkmenų, tačiau jų yra vis daugiau dalykai, iškylantys kiekvieną dieną, ir kūrėjų, ir našumo požiūriu jie atrodo ir jaučiasi kaip duomenų bazių varikliai, tačiau jie yra labai, labai skirtingi žvėrys ir turi savo mažą nišą pasaulyje, kad galėtų tai padaryti. veikimas atmintyje arba linijinė skalė diske. Bet štai kaip atrodo pasaulis duomenų bazių pasaulyje. Tai yra 2016 m., Tai yra trečioji žemėlapio versija, kurią sudaro daugybė žmonių, kurie sukuria šį nuolatinį kraštovaizdžio žemėlapį, kaip atrodo duomenų bazės, ir štai kur - net ir antžmogiškas duomenų bazių architektas ar duomenų bazių administratorius negalėjo turėti prasmės iš jo. Pažodžiui šimtai, ir šimtai, ir šimtai įvairių markių, modelių, duomenų bazių gamintojų, visada suderinamų su SQL. Įdomu tai, kad visi jie grįžta į tą patį iššūkį. Našumo ir našumo derinimas pagal duomenų bazės variklį, ypač pagal tai, kaip indeksuojami duomenys.

Taigi tegul greitai įtraukia duomenų bazių indeksavimą, nes tai yra įdomi tema, ir aš tikiu, kad jūs turite išsamiau susipažinti su demonstracine versija. Bet aš manau, kad gana gerai yra priimta ir standartinė pramonės praktika, kai duomenų bazių rodyklių našumas yra tas, kuriame prasideda ir baigiasi pasaulis, užtikrinant, kad jūsų duomenys būtų prieinami greitai ir greitai. Bet kas yra duomenų bazės indeksavimas? Jei galvojame apie indeksavimą tokia forma, kokia esame įpratę kaip kasdieniai žmonės, pagalvokime apie rodyklės puslapį knygoje. Jei norite ką nors atrasti knygoje - ypač patinkančią enciklopediją ar panašų į tam tikros formos pavyzdinę medžiagą - jei ieškote kažko panašaus į šį puslapį, kur aš ieškau tokių dalykų, kaip užtvankų tema enciklopedijoje. Norėčiau rasti visas nuorodas į užtvankas, vandens baseiną ir didelę užstatymo vietą, kurią paprastai sukuria žmogus. Aš eisiu atgal, rasiu abėcėlės tvarka, surūšiuotame sąraše nuo A iki Z, iš kairės į dešinę, ir rasiu D. Aš rasiu žodį „užtvankos“ ir matau, kad ant 16, 38, 41 puslapiuose yra nuoroda į juos, tada aš galiu eiti į tuos puslapius, nuskaityti akis ir rasti nuorodą į žodį „užtvanka“. Tai iš esmės ta pati sąvoka duomenų bazėje, bet dabar tai yra raketų mokslas įvairiais būdais. Tiek daug, kad faktiškai kiekvienas duomenų bazės administratorius, su kuriuo aš kada nors gerai susipažinau, laiko indeksus vienintele kritiškiausia našumo derinimo priemone bet kuriame duomenų bazių pasaulyje, neatsižvelgiant į tai, kokia jų patirtis gali būti tokia, kaip įmesta į skardą ar kad ir koks būtų atvejis.

Paprastai kalbant apie duomenų bazių indeksavimą, yra keletas bendrų metodų. Ir kuo sudėtingesni duomenų bazių indeksai, tuo sudėtingesnis požiūris į duomenų indeksavimą. Iš esmės, kai galvojate apie duomenų indeksavimą - įsivaizduokite, kad turime failą, kuriame yra vardų sąrašas; jie negali būti rūšiuojami abėcėlės tvarka. Įsivaizduokime, kad jų yra dvidešimt. Jei ketiname rūšiuoti - jei ieškosime duomenų tame sąraše iš viršaus į apačią ir tarkime, kad tai vardų sąrašas. Jei pasirenku atsitiktinį pavadinimą ir pradedu slinkti tą sąrašą iš viršaus į apačią, linijiniu formatu ir tai nėra netvarkingas sąrašas, yra du kriterijai, kuriuos aš pamatau kaip vidutinį paieškos laiką ir maksimalų paieškos laiką - ir Aš turiu rašybos klaidą antroje eilutėje, turėtų būti „maksimalus paieškos laikas“, atsiprašau, bet mano vidutinis paieškos laikas iš esmės yra N plius vienas, padalytas iš dviejų, ir tai reiškia, kad vidutiniškai man prireikia penkiasdešimt procentų laiko nuskaityti nuo sąrašo viršaus iki sąrašo apačios, kad surastumėte bet kurį atsitiktinį dalyką tame sąraše. O antroji eilutė, esanti tiesine linija, turėtų būti „maksimalus paieškos laikas“. Tačiau maksimalus paieškos laikas iš esmės yra daiktų skaičius, tai yra, jei turiu dvidešimties daiktų sąrašą, tai daugiausiai laiko gali užtrukti ieškoti kažko toje duomenų bazėje reikia eiti iš viršaus į apačią, tarkime, 20 elementų šiame supaprastintame pavyzdyje. Tai labai lėtas procesas ir nėra jokio būdo, kaip tai suderinti. Tada yra ir kitų būdų, kaip paimti tuos duomenis ir sukurti rodyklę, kuri iš tikrųjų yra trumpas sąrašas rodyklių, kur yra faktiniai duomenys, pavyzdžiui, dvejetainis, B-medis, bitkoinas, maišos, sugrupuoti ir nekaupiami, tada yra įvairių tipų duomenys, tokie kaip erdvinis, filtruojamas, XML ir visas tekstas.

Dvejetainiai elementai yra labai paplitę dalykai, kai duomenys yra tinkami naudoti. „B-medis“ yra turbūt labiausiai paplitęs plačiąja prasme istoriškai, nes tai yra įprastas būdas susisteminti indeksą pagal bet kokio pavidalo duomenis ir leidžia kaupikliams, atrankai, įterpimams ir ištrynimams palyginti nesudėtingas, kai judate žymiklius aplink nuoroda į rodykles, taškus. Yra ir kitų tipų, tokių kaip bitkoinas, kai duomenų tipai yra susiję, pavyzdžiui, jei turime susietą tam tikros formos diapazoną. Maišymas labai gerai tinka dideliems objektams, ypač tinklaraščiams ir vaizdams. Galite pastebėti, kad duomenų indeksavimui yra daugybė skirtingų tipų, matematinių metodų. Paprastam mirtingajam jie yra įdomus iššūkis, apie kurį reikia kalbėti šiame lygmenyje. Kai jūs kalbate apie tai duomenų bazės administratoriaus našumo lygiu, jie iš tikrųjų tampa raketų mokslininkais ir žmonės juose įgyja laipsnius. Aš žinau, kad gydytojas Robinas Blooras tikrai tai padarė ir parašė apie tai knygas mėgstantiems IBM ir kiti dideli prekių ženklai per pastaruosius porą dešimtmečių. Taigi, mano nuomone, mes iš tikrųjų praėjome laiką, kai, jūs žinote, kada nors aš asmeniškai galėčiau sėdėti priešais sistemą ir galėčiau ją atskirti, parodyti jums tiksliai ten, kur buvo našumo problemos komandinėje eilutėje arba grafinėje vartotojo sąsajos pradžios priemonėje, pradėkite gilintis į duomenis ir pasakyti jums, kur buvo problemos, ir kurti indeksus, subindeksus arba pirminius ir antrinius indeksus. duomenis ir pradėkite juos naudoti daiktams surasti. Bet kai galvojai apie tą kraštovaizdį, aš tau parodžiau, kur turime šimtus ir šimtus prekės ženklų, gamintojų ir modelių bei gamintojų ir duomenų bazių tipų. Mes gerai ir tikrai praeityje to laiko, kur žmogus gali padaryti duomenų bazių variklių tipų suvokimas. Visų pirma, net jei grįžtume prie „Oracle“ pamėgtų prekių ženklų, šių dienų santykinių duomenų bazių platformose.

Duomenų bazių, kurias jie turi tvarkyti naudodamiesi patentuota platforma, pavyzdžiui, ERP, HR, ar finansų sistema, ar jos yra namuose keptos platformos dėl įvairių priežasčių, skaičius duomenų bazių ir duomenų bazių lentelių bei įrašų, kuriuos mes turime santykiai yra tik astronominiai ir jūs fiziškai negalite to padaryti ranka. Dabar mes patyrėme papildomą komplikaciją, kai kadaise duomenų bazės serveris gali tiesiog sėdėti po jūsų stalu. Jūs žinote, kad būdamas mažas vaikas po mokyklos buvau pradėjęs dirbti su duomenų bazių programine įranga iš pradžių „Apple IIes“, o po to DOS kompiuteriais pagrįstose sistemose, tokiose kaip „dBase II“, „dBase III“, išgyveno erą su mainframe ir viduryje diapazoną ir net VAX ir PDP bei žurnalo failą. Ir panašiai kaip „Sabre“, o galiausiai, kai atsirado keletas SQL duomenų bazių. Tačiau šiomis dienomis, kai mes galvojame apie duomenų bazių variklius, jie atrodo kaip apatinis kairiajame kampe. Duomenų bazės serveris nėra tik viena mašina, sėdinti ant grindų po stalu; tai yra šimtai mašinų, veikiančių duomenų bazių variklių kopijas, ir grupių, ir jos išmatuoja šimtus ir šimtus terabaitų duomenų, jei ne duomenų petabaidus, o tai yra tūkstančiai terabaitų. Ir net kraštutinumu, kaip minėjo gydytojas Robinas Blooras, kad kai kurie konkretūs naudojimo atvejai - oro linijos, ypač vyriausybinės agentūros - gali patekti į tremtį. Jie vis dar yra gana nišiniai, bet šimtai terabaitų ir net dešimtys petabaitų jau nėra neįprasta, ypač nuo „dotcom“ bumo iki dabar, tam tikrų, kuriuos mes vadiname „web 2.0“ kompanijomis, „Facebook“, „Google“, „Yahoo“ ir taip toliau.

Mums taip pat sudėtinga dabar, kai viskas pereina prie išorės tarnybos. Mes turime infrastruktūros platformą ir programinę įrangą, kaip paslaugų metodą teikiant infrastruktūrą. Ypač platformos paslaugos, kur mes negalime nusipirkti tiesiog „Oracle“ ir jų debesų platformos, duomenų bazių ir serverių. Taigi tai leidžia mums labai greitai plėtoti taikymą ir tiesiog prijunkite duomenų bazę prie serverių. Mes neturime galvoti apie tai, kas yra po gaubtu. Neigiama pusė yra ta, kad mes dažnai negalvojame apie tai, kaip suprojektuojame ir įgyvendiname duomenų bazę, kol ji pradeda skaudėti ir našumas tampa problema, ir mes galų gale turime ieškoti tinkamo įrankio diagnozuoti, kodėl mūsų duomenų bazė kenkia ir kur yra spektaklio problemos. Ir visada tai sugrąžina į tą bendrą problemą, kaip mes indeksavome tuos duomenis ir indeksų tipus, kuriuos mes naudojome šiems duomenims, ir tai vėl sugrąžina mus į viršžmogiškųjų charakteristikų reikalavimus. O tas, kuris turi prieigą prie tinkamų sistemų ir tinkamų įrankių, leidžiančių suderinti šiuos variklius, pradeda ieškoti svarbiausių taškų ir ieškoti, kur yra užklausos, kur juda duomenys, kokio tipo užklausos yra, kaip užklausos yra struktūrizuotos, kas daro užklausas ir ar užklausos yra eilės, ir jas reikia kaupti talpykloje. Kokio atkartojimo ieškote?

Taigi, mes gerai ir tikrai - mano požiūriu - dabar, kai net geriausi pasaulio duomenų bazių guru, iš esmės mūsų duomenų bazių architektai ir duomenų bazių administratoriai bei duomenų bazės, mano manymu, jiems labai reikia pradėti naudoti tinkamas priemones. užtikrinti optimalų našumo indekso derinimą bet kuriam duomenų bazės varikliui. Kadangi mastas, kurį mes susiduriame, ir greitis, kuriuo viskas juda, mes paprasčiausiai negalime to padaryti ranka, o bandymas tai padaryti visada gali sukelti kitų atlikimo problemų, nes mes galbūt neturime patirties toje erdvėje, kuri bandome išspręsti problemą. Ir aš tikiu, kad tai yra tas, kurį ruošiamės perduoti Bertui, ir mes ketiname kalbėti apie tai, kaip jie išsprendė šią įvairią problemą ir apie dalykus, kuriuos jų įrankis gali daryti, ypač „Oracle“ pasauliui. Ir kartu su tuo, Bertu, aš perduosiu tau.

Bertas Scalzo: Ačiū. Sveiki visi, mano vardas Bertas Scalzo, aš dirbu IDERA. Aš esu kai kurių mūsų duomenų bazės produktų vyresnysis vadybininkas. Aš pademonstruosiu kai kuriuos iš šių dienų. Bet aš noriu kalbėti apie rodykles, nes sutinku su viskuo, ką visi čia pasakė, ypač su paskutine skaidrėmis, kad rodyklės yra tokios sudėtingos, kad jums reikia įrankio, ir tikiuosi jus įtikinti. Taigi „Oracle“ rodyklės dizainas nėra toks lengvas, koks buvo senais laikais. Daugelis žmonių nebus tikri dėl savęs, kai žiūrės į galimybes, ir man patinka šis posakis, kurį aš išmečiau iš istorijos, „šiais klausimais vienintelis tikrumas yra tas, kad niekas nėra tikras“. Štai ir aš savotiškai jaustumėtės dėl indeksų šiomis dienomis, nes net jei manote, kad žinote atsakymą, kurį turėtumėte indeksuoti X, Y ar Z, tikrai negalite būti tikras, kol nepabandysite, nes tie optimizatoriai kartais elgiasi kitaip, nei tikitės. Taigi rodyklės dizainas yra labai išbandytas ir klaidingas. Dabar, senais gerais laikais, jei jums reikėjo rodyklės, paprastai buvo tik du klausimai arba vienas klausimas. Ar ji buvo unikali, ar ji nebuvo unikali? Galbūt pagalvojote apie kitus dalykus, pvz., „Kiek indeksų galiu turėti daugiausiai ant vienos lentelės?“, Nes per daug indeksų sulėtina įterpimus, atnaujinimus ir ištrynimus. Jūs taip pat galėjote būti savo duomenų bazės sistemoje, turėjote apribojimų, kiek stulpelių gali būti kelių stulpelių rodyklėje, nes kartais buvo apribojimai, pagrįsti jūsų duomenų bazės variklio puslapiu ar bloko dydžiu, tačiau iš tikrųjų tai buvo gana paprasta atgalinė versija. senais gerais laikais. Jūs arba indeksavote, arba nedarėte. Ir tikrai viskas buvo B medyje. Galėjome leisti kopijas ar ne, ir apie tai buvo kalbama. Gyvenimas buvo geras, gyvenimas buvo paprastas.

Na, šiandien gyvenimas nėra toks geras ar paprastas. Aš įdėjau raudoną „Ghostbuster“ ženklą taip, kaip mes tai darėme anksčiau, nes dabar mes turime „B“ medį, palyginti su „bitmap“, palyginti su „bitmap“, prisijungimu. Ir aš paaiškinsiu, kas kai kurie iš jų yra akimirksniu. Grupuoti ir negrupuoti, unikalūs ar dublikatai, pirmyn arba atvirkštine tvarka, pagrįsta funkcija, padalijama arba neskirstoma. Jei vyksta atskyrimas, ar tai yra globalus ar vietinis skaidymas? Aš tai taip pat paaiškinsiu. Tada taip pat yra kažkas, kas vadinama indeksuota organizuota lentele. Iš tikrųjų čia liko pusė keliolikos kitų, nes manau, kad man čia jau užteko, ir tai turėtų jus įtikinti, kad rodyklės yra daug griežtesnės, nei jūs galėjote pagalvoti. Šioje konkrečioje skaidrėje pradėsiu nuo viršutinės kairiosios diagramos dalies ir turiu lentelę. Ir pirmiausia turiu nuspręsti, atsižvelgiant į jūsų duomenų bazės versiją ir duomenų bazės pardavėją, ar jos leidžia objektų lenteles, ar jos yra tik reliacinės? Aš einu dešine puse ir sakau, kad mes statome reliacinį stalą. Kitas klausimas, kurį turiu užduoti sau, yra: ar jis yra grupėje? Ir daugelis iš jūsų, kurie kurį laiką naudojote „Oracle“, atsimins, kad klasteriai buvo sukurti „Oracle“ 6 dienas. Šiandien jie turbūt nėra labai naudojami, bet pirmiausia leisk man nuleisti tą šaką.

Jei aš ketinau sudėti savo lentelę į klasterį, aš turėčiau turėti klasifikuotą rodyklę ant tos lentelės. Dabar „Oracle“ grupuodami lentelę iš esmės kaupdavote eilutes arba eilutės buvo arti viena kitos, kur reikšmės buvo panašios. Taigi, jūs turite turėti sugrupuotą rodyklę ir tas sugrupuotas rodyklė gali būti neskaidoma. Kitaip tariant, tikrai nebuvo jokių atskyrimo būdų, kaip darytumėte grupuotę. Tai buvo griežtai nedalijama. Kadangi jis nebuvo skaidomas, jis buvo globalus. Aš per minutę paaiškinsiu, kas yra globalumas. Ir tai visada buvo B medis. Kitaip tariant, kai nuėjau tą šaką, ji buvo gana paprasta, aš neturėjau daug pasirinkimų. Dabar, jei aš darydavau neklasifikuotą rodyklę ant klasteriuotos lentelės, kuri buvo leidžiama kai kuriose versijose, vėl ji nebuvo skaidoma; kai jis nėra skaidomas, tada jūsų vienintelis pasirinkimas yra globalus. Taigi, jūs galite pasirinkti B medį arba bitkoiną. Vėlgi, tai priklausė nuo jūsų duomenų bazės versijos. Bet dabar grįžkime prie reliacinio stalo ir vėl pradėkime eiti dešine puse žemyn, o dabar mes tiesiog turėsime paprastą, seną, įprastą, krūvą turinčią lentelę: reliacinę. Tai bus stalo erdvėje. Aš pirmiausia einu dešine puse žemyn. Taigi tai organizacija, krūva. Kitas klausimas, kurį turiu užduoti sau, yra: „Ar aš noriu skirstyti šią lentelę, ar ne?“ Dabar kartais jūs skaidytumėtės, nes galvojote: „Ei, optimizavimo priemonė bus sumanesnė, kaip ji gali optimizuoti užklausas. Bet daugelis DBA jums pasakys, kad priežastis, kurią darote, yra administraciniais tikslais. Jei turite šimto milijardų eilučių lentelę, jei ją suskaidote į pertvaras ar segmentus, kai norite pridėti duomenis prie paskutinio segmento, galite mesti ir indeksuoti tai tik keli milijonai eilučių. Galite įterpti tuos duomenis ir tada galėsite atstatyti tą indeksą tik tame segmente.

Nors kai kuriems tai buvo gera metodika, pvz., Skaidinių pašalinimas, tačiau realioji vertė buvo galimybė administruoti ar atlikti administracines užduotis mažesnėms dalims. Kai einu į organizacinę krūvą, pirmas klausimas buvo: „Ar aš ją padalinau, ar ne?“ Eikime į kairę, aš neketinu skirstyti lentelės. Dabar tai gali atrodyti keista, kai aš jums tai sakau, bet jūs galite turėti lentelę be skirsnių ir tada negalite skaidyti rodyklės, kaip esate įpratę, arba galite skaidyti rodyklę. Sustoti ir galvoti. Kaip visada galvojote, jūsų lentelėje yra vienas kaušas, tačiau indekse bus keli kaušai. Kai tai atsitiks, kai nesutampa kibirų ir stalo skaičius bei indekso segmentų skaičius, būtent tai reiškia globalus. Taigi, jei lentelė nėra padalijama, o jei rodyklė yra skaidoma, ji laikoma visuotine, nes yra neatitikimas. Dabar leisk man grįžti atgal į savo organizacijos krūvą ir leiskis žemyn į pertvaros pusę. Dabar, jei turiu skaidinių lentelę ir tarkime, kad lentelė turi keturis segmentus, keturis skirsnius, mano rodyklėje galėtų būti keturi segmentai, kad mano rodyklė atitiktų mano lentelės dizainą. Taigi viskas baigėsi dešinėje pusėje. Tai būtų laikoma vietine. Vietinis rodyklė iš esmės reiškia, kad lentelės ir rodyklės padalijimas vyksta taip pat ir turi tą patį segmentų skaičių. Tada, kai turėsiu vietinį rodyklę, tai gali būti B medis arba bitkoinas, o ta žalia rodyklė, kylanti aukštyn, rodo, kad net jei tai yra B medis, vis tiek yra pasirinkimų, kuriuos galima padaryti. Tai galėtų būti pagrįsta funkcija. Taip pat, jei tai bitkoinas, yra įvairių tipų bitkoinai. Yra kažkas, kas vadinamas bitmap prisijungimo indeksu. Jei vykdote duomenų sandėliavimą, tai labai populiari žvaigždės schemos ar dizaino rodyklės rūšis. Kas nutinka, indeksas turi eilutės ID, pagal kurias nurodo lentelę, bet taip pat turės pirminių lentelių eilutės ID, kad tada, kai esate - jūs turite pažymėti schemos dizainą žvaigždute ir ieškote faktų lentelėje, tai rodyklė faktų lentelėje nukreipia jus į jus dominančius duomenis ir nurodo kiekvieną jūsų matmenų eilutę, kad turėtumėte tik vieną rodyklę.

Ir iš tikrųjų tai atsirado dėl „Raudonų plytų“, kuri prieš daugelį metų buvo duomenų bazė - tai gali prisiminti daugybė žmonių. Taigi, jei jūs pažvelgsite į šią nuotrauką - ir atminkite, kad nepadariau visko šioje nuotraukoje, nes nuotrauka bus daug didesnė - vis tiek yra papildomų problemų, kurias čia turiu tekste viršutiniame dešiniajame kampe. . Ar tai atvirkštinės eilės indeksas? Ir jūs galite pasakyti: „Kodėl aš norėčiau atvirkštinės eilės indekso? Tai neturi jokios prasmės. “Na, jei esate klasifikuotoje„ Oracle “aplinkoje, jei darote tikras aplikacijų grupes, jei tvarkomės savo rodykles tvarkoje, taigi nekeičiame, jei turite daugybę apdorojimų, kurie trukdo tos pačios vertės ar tos pačios indekso vertės, kas nutiktų, jūs turėtumėte karštas savo B medžio vietas. Reiškia, kad turėtumėte ginčytis ir galbūt užsiblokuosite, kad galėtumėte pasiekti tą medžiagą, ir tai darysite visuose tinklo mazguose. Na, jei įdėsite indeksą atvirkštine tvarka, dabar galite anuliuoti. Galite pasakyti: „Na, panašios vertės yra skirtingose ​​medžių dalyse, todėl aš neturiu savo atskirų mazgų, konkuruojančių dėl karštų medžio vietų“. Ir tada atkreipkite dėmesį, kad unikalus neveikia su kai kuriomis galimybėmis. . Jei pažvelgsite, aš suskaičiavau tris, penkis, aštuonis ir vienuolika, todėl yra atvejų, kai negaliu turėti unikalaus indekso. Taip pat yra keletas atvejų, kai aš negaliu turėti atvirkštinio indekso, tada kyla papildomų problemų, pavyzdžiui, registravimas arba jo nėra, lygiagrečios ir nelygiagrečios. Aš galiu priskirti daiktus tam tikrai sričiai atmintyje.

O tai vis dar palieka nemažai „Oracle“ funkcijų. Aš sakyčiau, kad kai jūs žiūrite į „Oracle 12“, turbūt vėl yra maždaug pusšimtis dalykų, kuriuos galėčiau pridėti prie šio paveikslėlio. Indeksavimas yra tikrai sudėtingas ir aš tikrai sutinku su ankstesniu pranešėju, kad galėtumėte naršyti po šį pasirinkimą ir tinkamai pasirinkti, jums reikia įrankio. Jums gali prireikti tokio paveikslėlio ir šiokios tokios metodikos, kaip galite pasirinkti daiktus, ir tikiuosi, kad įrankis padės jums ten patekti. Ir tada tai bus bandymas ir klaida. Aš visada sakau žmonėms, kad jie indeksuoja: „Pažiūrėk, kol nepašoki.“ Ir tada jūs galite pamatyti mažą šunį, jis šokinėja nežiūrėdamas, jis baigsis vandenyje su rykliu ar vaikinas ruošiasi šokti į vandenį, ir jis imsis smogti pats. Turite galvoti apie savo indeksavimą, nes indekso sukūrimas ne visada reiškia, kad viskas pagerės. Tiesą sakant, indekso sukūrimas gali sulėtinti veiksmus. Ir užklausos našumas gali būti geresnis už vieną eiliškumą, palyginti su kitu. Ir pateiksiu gerą pavyzdį. Jei darote žvaigždės schemą, o matmenų lentelėse vienu atveju naudojate bitkoino indeksus, o kitu atveju sakote: „Aš naudosiu B medžio indeksus“, jūs turite bitmap, palyginti su B- medis. Aš galiu pasakyti, kad vienas sprendimas bus didesnio laipsnio arba galbūt keliomis eilėmis greitesnis už kitą. Tačiau atminkite, kas veikia vienoje aplinkoje, kaip ir duomenų saugojimo aplinkoje, tikriausiai nėra geras pasirinkimas OLTP aplinkoje.

Pvz., Jei imtumėtės operacijų lentelę ir pateiktumėte bitkartinės rodyklės ant sandorių lentelės, brangu apskaičiuoti ir iš naujo nustatyti bitkoinus, šias ilgas eilutes, todėl OLTP lentelėje galite smogti lentelę taip smarkiai, kad bitkoinas rodyklė gali sugadinti ir sulėtinti jūsų sistemos veikimą, nes jie tiesiog nėra skirti atnaujinimams. Jie puikiai tinka greitai pasiekti, bet nėra tinkami atnaujinimams. Manau, kad rodyklė reikalauja bandymų ir klaidų. Iš tikrųjų dabar nėra auksinės taisyklės - šioje lygtyje yra per daug skirtingų kintamųjų, kad galėtumėte žinoti - ir galų gale turėsite pažvelgti į vykdymą arba paaiškinti savo duomenų bazės planus, kad pamatytumėte, ar jūs gerai pasirenkate. Ir kartais plano analizė gali būti beveik savaime suprantamas dalykas. Šiandien aš to nenagrinėsiu - tai jau kita tema -, bet nelaikykite rodyklės formavimo savaime suprantamu dalyku. Yra pagrįstų priežasčių, kodėl yra visi šie beprotiški rodyklių tipai, kuriuos aš jums parodiau ankstesniame paveikslėlyje ir apie kuriuos kalbėjo ankstesnis pranešėjas. Jie nebuvo sukurti tik todėl, kad buvo tikslinga kažkur pateikti duomenų bazės tiekėjo kontrolinį sąrašą; yra atvejų, kai scenarijai yra svarbūs ir reikšmingai pakeis scenarijus. Dabar aš jums parodysiu keletą rūšių indeksų pavyzdžių viename iš mūsų įrankių. Leiskite man tiesiog pakelti ekraną, kad galėtumėte jį pamatyti. Gerai, kad aš čia sėdžiu viduje - leiskite man sumažinti šią programą. Aš sėdžiu VM programinės įrangos viduje ir paleidžiu „Windows Server 2012“ VM.

Ir jūs galite pamatyti, aš turiu beveik kiekvieną įrankį, žinomą žmonėms. Aš, kaip produkto vadovas, turiu žinoti apie savo konkurenciją, todėl svarbu ne tik tai, kokias priemones turiu, bet ir tai, ką daro mano konkurentai? Mes turime šį įrankį pavadinimu „DBArtisan“, kurį jau paleidau, bet einu - taigi aš jį tiesiog parodysiu. Ir tai, ką galite pamatyti, yra tikrai puikus įrankis, nes užuot naudojęsi, tarkime, „Oracle“ įmonės vadybininku ir „SQL Management Studio“, skirtu „SQL Server“, ir „MySQL Workbench“, skirtu „MySQL“, ir dvylika kitų mūsų palaikomų duomenų bazių, gerai, kad aš turiu visas savo duomenų bazes, integruotas į šį vieną įrankį. Yra „DB2“, yra „MySQL“, „Oracle“, „Postgres“, „SQL Server“ ir „Sybase“, ir štai - turiu tik šešias duomenų bazes šiuo konkrečiu dalyku, nes negaliu - įrankis palaiko dvylika duomenų bazių, bet mano prastas VM, vienu metu valdo šešias duomenų bazes ir bando atlikti demonstraciją, yra tiek, kiek palengvins mano aparatinė įranga. Taigi leiskite man grįžti į „Oracle“ dabar ir, jei pastebėsite, visi šie dalykai yra vienodi. Jei noriu įvertinti savo našumą „DB2“, tai tas pats pasirinkimas, kurį turėčiau „Oracle“. Dabar po viršeliais mes darome daugybę įvairių dalykų, todėl jūs neturite žinoti, kas vyksta, tačiau mes suteikiame jums nuoseklią sąsają, kad galėtumėte būti ekspertas, turintis kelias duomenų bazių platformas. Tai apimtų darbą su rodyklėmis, šios diskusijos tema.

Leisk man atvykti čia ir leisk man pirmiausia pradėti pažvelgti į kai kurias lenteles. Turiu filmų duomenų bazę, kurioje yra tik kelios lentelės. Ir jei aš žiūriu į tam tikrą lentelę, pavyzdžiui, į klientų lentelę, kai aš ją čia pateikiu, galiu pamatyti savo lentelės dizainą, čia yra mano lentelės stulpeliai ir čia yra informacija apie kiekvieną stulpelį. Turiu lentelės ypatybes, bet atminkite, kad čia turiu skirtuką indeksams ir galiu pamatyti, ar čia yra lentelės indeksai. Atkreipkite dėmesį, kad vienas iš šių rodyklių yra mano PK rodyklė, mano pagrindinis raktas. Šie kiti atrodo tik indeksai, skirti pagerinti prieigą prie užklausų, galbūt mes užklausame pagal vardą ar pavardę arba žiūrime į telefonus ir pašto kodus. Ir jei aš pasirinksiu tam tikrą rodyklę, pavyzdžiui, šį pašto kodą, ir dukart spustelėjau, dabar galiu pamatyti, kad, ei, tai nėra unikalus rodyklė, ir čia yra keletas kitų tipų, bitmap, unikali, unikalus, nesvarbu, ar jis rūšiuojamas, ar ne, registravimas ar ne, nepriklausomai nuo to, ar tai atvirkštinė tvarka, ar tai yra funkcijos bazė. O, štai įdomus dalykas, kurio neaptariau. Jūs iš tikrųjų galite turėti nematomus indeksus. O jūs sakysite: „Na, kodėl gi aš norėčiau padaryti nematomą rodyklę?“ Na, aš jums pateiksiu gerą pavyzdį. Esate savo gamybos sistemoje ir turite našumo problemų ir nesate tikri, kad sukūrę rodyklę problema išsispręs, todėl nenorite kurti rodyklės ir sulėtinti gamybos procesą, bet kažkaip ar kitas, kurį norite sugebėti tai išbandyti. Gamybos indeksą galite sukurti kaip nematomą, tai reiškia, kad nedaug programos kodo, paskambinus optimizatoriui, bus naudojamas tas indeksas. Jis buvo sukurtas, galioja, bet nebus naudojamas. Tuomet galite pateikti užklausą, kuri, jūsų manymu, padėtų, su šia rodykle, arba užklausų seriją, ir jūs galite užfiksuoti užuominą ir pasakyti: „Ei, optimizatorius, ten yra nematomas rodyklė, kurią noriu naudoti ir leisti Aš žinau, ar aš viską patobulinau. “Ir dabar aš išbandžiau ką nors gamyboje, tačiau nepalaužiau jau veikiančių gamybos programų. Tai nematomo indekso naudojimas. Tai skamba niūriai, kai pirmą kartą apie tai išgirsti, tačiau jis turi prasmę.

Rodyklėse taip pat galime apibrėžti, ar jie yra lygiagrečiai, ir kiek egzempliorių jie yra lygiagretūs. Dabar ne klasterizuotoje, o ne realioje programų klasterio aplinkoje, taigi ne rake, lygiagreti reikštų, kiek subprocesų gali pateikti mano užklausa, kad būtų galima išbandyti, ir darbuotojo procesai, kad būtų galima greičiau ar greičiau atlikti reikalą. . Lygiagrečiai egzistuotų pavyzdžiai, jei aš atsidurtų realioje programų grupėje, tarkime, kad aš turiu dešimt mazgų, kiek mazgų man leidžiama padalinti kūrinį? Gal tai yra keturi iš dešimties, o kiekviename iš jų - keturi antriniai procesai. Tai pavyzdys. Ir tada mes turime raktų glaudinimą. Ar iš tikrųjų galite suspausti indeksus? Taip ar ne. Ir tada, žinoma, turite saugyklos parametrus, kuriuos galite nurodyti rodyklėse. Dabar aš jų nenagrinėjau, nes jie iš tikrųjų yra labiau saugojimo parametras nei rodyklės problema. Ir galiausiai mes turime pasirinkti, ar padalinti, ar neskaidyti. Leisk man tai akimirkai nustoti. Aš pereisiu prie kitokios schemos. Tai yra žvaigždės schema ir, pavyzdžiui, šios laikotarpio lentelė yra matmenų lentelė. Jei kada nors projektavote žvaigždės schemą, paprastai turite laiko matmenis, taigi šioje duomenų bazėje ir šioje žvaigždės schemoje periodas yra laiko aspektas. Dabar aš žinau, kad tai atrodys juokinga, jūs sakysite: „Gee, pažiūrėk į visus tuos stulpelius - ar vaikinas kada nors girdėjo apie normalizavimą?“ Na, kai esate duomenų sandėlyje ar žvaigždės schemos dizaine, jūs paprastai turite ne stalų, į kuriuos paprastai žiūrėtų žmogus ir sakytų: „Gerai, jie nėra labai gerai suprojektuoti.“ Bet taip jūs darote duomenų saugojimo aplinkoje.

Dabar žiūrėk, kas nutiks, nes gerai, kad yra visi šie stulpeliai, žiūrėk, aš turiu rodyklę kiekviename stulpelyje. Dabar OLTP aplinkoje, kuri būtų „ne-ne“. Tai sulėtins visas mano operacijas. Duomenų saugojimo aplinkoje aš juos numečiau per savo paketinių krovinių ciklus. Įkelkite be pridėtinių galų ar rodyklių, ir aš vėl sukurčiau rodykles. Ir jei aš išskaidyčiau savo lentelę, tada užuot turėjęs mesti kiekvienos lentelės segmento rodyklę, galėčiau tiesiog numesti rodyklę ant kibiro ar kibirų, kur duomenys bus naudojami per tą partijos įkėlimo ciklą. Ir tada atkurkite tik tų kibirų rodyklės dalį. Tai daro jį labai lengvai valdomu. Ir jei aš pažvelgsiu - taigi čia yra stulpelis, pavadintas „Atostogų vėliava“, ir iš esmės tai yra taip arba ne. Atminkite, kad tai yra bitkoino rodyklė, ir daugumai iš jūsų sakysite: „Na, tai turi prasmę.“ Taip arba ne, Y arba N, yra tik dvi prasmės. Ir todėl, kad kai jūs skaitote bitkartinės rodyklės dokumentus, jie visada sako, kad turite pasirinkti ką nors, kas yra per maža.

Dabar leiskite man patekti į vieną iš mano faktų lentelių, taigi čia mes turime mano užsakymus. Ir tai yra mano užsakymai per dieną. Dabar jūs pamatysite, kad aš vėl turiu keletą stulpelių ir vėl turėsiu daugiau nei kelis indeksus. Ir čia pat turime tai, kas vadinama universaliu kainų kodu. Tai buvo skirta mažmeninei prekybai, taigi jūs žinote tuos mažus brūkšninius kodus, kai ką nors perkate parduotuvėje, tai yra universalus kainos kodas. Dabar yra milijonai universalių kainų kodų. Dabar šiai konkrečiai įmonei, prekiaujančiai daiktais, jie turbūt turėjo nuo 1, 7 iki 2 milijonų universalių kainų kodų, taigi jūs tikėsitės, kad tai nebus bitkartės indeksas, nes 1, 7 milijono skirtingų verčių skamba kaip didelis kardinalumas. Bet iš tikrųjų duomenų saugojimo aplinkoje norite, kad tai būtų bitkoinas. Dabar leiskite man paaiškinti, kodėl. Na, šiam universaliam kainų kodui gali būti 1, 7 milijono reikšmių, šios užsakymų lentelės eilučių skaičius yra nuo šimtų milijonų iki milijardų eilučių. Mano indeksas yra mažas, palyginti su lentelės dydžiu ar kardinalumu. Tai daro jį menku kardinalumu. Tai daro naudingą bitkoino rodyklę, net jei jis yra neintuityvus su 1, 7 milijono skirtingų reikšmių, kurias čia pasirinktumėte bitmap. Dabar, jei žinočiau, kad noriu naudoti prisijungimo prie bitkoino rodyklę, šiuo metu produktas to nepalaiko, aš pridedu tai kitai spaudai, tačiau tai būtų dar viena alternatyva. Atminkite, kad žvaigždės schemoje bitkoino rodyklė būtų faktų lentelėje ir kad vienas rodyklė B medyje nurodytų faktų lentelės eilutę, o tada kiekvieną eilutę, kuri matoma to fakto matmenų lentelėje. . Taigi jūs turite kitą variantą. Taigi, pažiūrėkime, dabar noriu išeiti iš lentelių ir noriu tik jums greitai parodyti, kad turiu tą pačią informaciją, indeksus ir darau tą patį pagrindinį dalyką.

Dabar priežastis, kodėl aš tai iškėliau, yra ta, kad galite pastebėti, kad, čia nėra pagrindinių raktų. Pirminiai raktai yra daromi suvaržant klavišus, todėl jiems iš tikrųjų taikomi apribojimų apibrėžimai. Tai būtų rodyklės, kurios nėra suvaržymo dalis. Dabar galite sakyti: „Na, palaukite minutę, tai gali atrodyti kaip svetimas raktas, o svetimas raktas yra suvaržymas“, tačiau užsienio raktai ir dauguma duomenų bazių automatiškai nesukuria rodyklės užsienio rakto stulpelyje, nors tai yra patartina, o ten eik - aš vėl turiu tuos pačius pasirinkimus. Ir jei noriu pakeisti tik norėdamas suspausti, galiu tai padaryti.

Dabar glaudinimas veikia tik B medžio indekse. Tai leidžia, kai pažvelgiate į įvairius B medžio mazgus, tai leidžia suspausti kai kurias reikšmes. Tai tikrai nėra suspaudimas, kaip lentelės suspaudimas, tai yra to, kas B medyje saugoma ne lapuose, suspaudimas. Tai neišsaugo tonos vietos, tačiau tai gali pakeisti. Ir tai pastebėjęs, aš jau gana arti laiko, todėl noriu tik grįžti ir nutraukti savo bendrinimą. Ir mes turime savo produktą keturiolikos dienų bandomajam verslui idera.com. Tai gana geras produktas, ypač jei dirbate su keliomis duomenų bazių platformomis. Jei dirbate su dviem ar trimis skirtingomis duomenų bazėmis, šis įrankis palengvins jūsų gyvenimą. Mes turime įrankių, kurie jums padės kuriant ir atrenkant rodyklę. Mes turime įrankį, vadinamą „DB Optimizer“. Aš tiesiog negalėjau to aprėpti šiandien, tai bus per daug. Ir jei norite su manimi susisiekti, yra mano el. Pašto adresas, jis yra, arba galite sugauti mane asmeniniu el. Laišku, aš turiu tinklaraščius, turiu svetainę ir tinklaraščius bei „LinkedIn“ profilį. Taigi nedvejodami kreipkitės į mane dėl bet ko, net jei tai nėra susiję su produktu, jei norite tiesiog kalbėtis duomenų bazėse, man yra geidulinga širdis ir aš mėgstu pasidomėti apie „technobabble“.

Ericas Kavanaghas: Gerai, gerai, Dezai, Robinai, aš tikiu, kad kiekvienas turite bent keletą klausimų, mes turime kelias minutes čia. Dez, ką tu galvoji?

Dezas Blanchfieldas: Turiu vieną puikų klausimą, kurį turiu jums užduoti. Tai sėdėjo mintyse. Koks juokingiausias scenarijus, kurį matėte? Aš skaičiau jūsų tinklaraštį, atidžiai stebiu jus, - jūs, greičiausiai, esate vienas iš nedaugelio žmonių, gyvenančių beveik kiekviename netikėtame, ir aš manau, kad daktaras Robinas Blooras yra antrasis, su kuriuo susitikau mano gyvenimo metu. Bet, žinote, tikriausiai esate matę kiekvieną beprotišką scenarijų, kokie yra patys juokingiausi scenarijai, kuriuos teko matyti, su kuriais teko susidurti, ir kaip žmonėms, kurie tiesiog negalėjo susidoroti, jums pavyko vaikščioti ir atlikti „Jedi“ proto triukus su šiuo DBArtisan'u?

Bertas Scalzo: Kažkada turėjome klientą, kuris, kurdamas savo duomenų bazės dizainą, labai galvojo, kaip jie sugalvos failų išdėstymo dizainą, ir taip - normalizuodami duomenų bazę pirmas dalykas, kurį bandote padaryti, yra atsikratyti kartoti grupes. Na, jie turėjo stulpelį ir jie padarė jį ilgu, arba BLOB ar CLOB, ir jame jie sudėtų vertę, numeris vienas, kabliataškis, antroji reikšmė, kabliataškis, vertės skaičius, kabliataškis, ir jie turėtų tūkstančius reikšmių ten, bet jiems reikėjo ieškoti tame stulpelyje ir jie klausė: „Kodėl šis dalykas veikia taip lėtai?“ O aš toks: „Na, tu negali sukurti indekso apie tai, ką padarei, tai tiesiog neleista. “Taigi mes, naudodamiesi planais, iš tikrųjų jiems parodėme, kad jiems reikėjo normalizuoti tą lentelę. Ne todėl, kad normalizavimas yra kai kurie akademiniai pratimai, kurie padaro viską geresniais, bet todėl, kad jie norėjo užklausos tame lauke, o tai reiškė, kad jie norėjo sugebėti ją indeksuoti, o tu negalėjai jos indeksuoti pasikartojančioje grupėje ar bent jau ne taip lengvai . Taigi tai turbūt blogiausias dalykas, kokį aš kada nors mačiau.

Dezas Blanchfieldas: Taip, įdomu, kaip dažnai jūs susiduriate, manau, kad iššūkis yra duomenų bazėms, žmonės pamiršta, kad tai yra mokslas. Ir yra žmonių, kurie daro laipsnius ir daktaro laipsnius visoje šioje erdvėje, rašo apie tai dokumentus, o jūs parašėte visą sambūrį, įskaitant savo TOAD vadovus ir kitus dalykus iš atminties. Dabar vyraujanti „didelių duomenų“ citavimo citata - matau, kad daug žmonių pamiršta duomenų bazių architektūros ir duomenų bazių technologijos pagrindus, duomenų bazių mokslą, jei norite. Ką jūs matote lauke, kai mes atsitraukėme nuo tradicinių duomenų bazių platformų ir tradicinio duomenų bazių mąstymo, kad mes efektyviai atsikišėme į žemę, ir tai buvo tik atlikimo derinimas ir mastelio keitimas. Ar matote, kaip daug žmonių mokosi iš naujo ir turi patirties, kai jie tiesiog sėdi ten ir turi „a-ha“ momentą, pavyzdžiui, „eureka“ momentą, kai supranti, kad šie dideli duomenys yra tiesiog rūšys iš tikrųjų didelių duomenų bazių? Ar tai yra dalykas, ir žmonės tau atsakinėja: „Pamiršome, ką žinojome ir ar gali mus sugrąžinti iš tamsiosios pusės?“

Bertas Scalzo: Na, ne, ir tai yra siaubinga, kad turiu prisipažinti, tačiau reliacinių duomenų bazių pardavėjai taip pat gėrė tą „Kool-Aid“. Jei pamenate, aš nežinau, prieš maždaug dešimtmetį mes pradėjome nestruktūrizuotus duomenis dėti į reliacines duomenų bazes, o tai padaryti buvo keista, o tada duomenys, reliacinės duomenų bazės, dabar prideda „NoSQL“ tipą. daiktai. Tiesą sakant, „Oracle 12“, CR2 - aš žinau, kad jis dar neišleistas - bet jei pažiūrėsite į beta versiją, jei esate beta programoje, ji palaiko „sharding“. Taigi, dabar jūs turite reliacinę duomenų bazę, kuriai nepridėta „NoSQL sharding“ koncepcija. Taigi, atrodo, kad „a-ha“ momentas labiau skirtas santykinių pusių žmonėms, kurie eina „a-ha“. Niekas niekada to nedarys teisingai, net duomenų bazių tvarkytojai, taigi, mes turėjau pereiti ir prisijungti prie tamsiosios pusės.

Dezas Blanchfieldas: Teisingai, todėl jūs sakote, kad reikia pereiti prie daugybės nešvarių duomenų, jei aš suprantu teisingai, kad jie būtų įtraukti į tai, ką mes dabar vadiname didelėmis duomenų platformomis, o tai yra juokinga, nes jie ne tas senas, bet ar tai nereiškia, kad jie visą dėmesį sutelkia į tai, ką jie daro su savo reliacine duomenų baze, kad gautų daugiau pinigų už savo pinigus?

Bertas Scalzo: Ne, paprastai, jei jie turi poreikį - tai būtų buvę citata „didelis duomenų tipo poreikis“, jie mano, kad užuot turėję eiti į kitą duomenų bazės platformą ir ką nors padaryti ne - Reliaciniu būdu, duomenų bazių tiekėjai dabar jiems naudoja tuos pačius nesusijusius metodus savo reliacinėje duomenų bazėje, kad galėtų atlikti tuos veiksmus. Turiu omenyje, kad geras pavyzdys būtų, jei turite nestruktūrizuotų duomenų, tokių kaip JSON duomenų tipas ar kitas sudėtingas duomenų tipas, turintis prasmę įterpti į pačius duomenis, duomenų bazės tiekėjai ne tik palaiko tai, bet ir suteiks jums ACID nestruktūrizuotų duomenų laikymasis. Reliacinės duomenų bazės aprėpė naujesnius metodus ir technologijas, todėl vėl atrodo, kad „a-ha“ yra ne tas, kuris sako: „Ei, mes, programų kūrėjai, kažko neišmokome ir turime tai išmokti iš naujo“, tai yra „Ei, mes tai darome dabar, kaip aš galiu tai padaryti savo tradicinėje reliacinėje duomenų bazėje ir daryti taip, kaip aš darau šioje duomenų bazėje? “Ir tai tampa vis labiau paplitusi, ir, kaip sakiau, patys duomenų bazių pardavėjai įgalina kad.

Dezas Blanchfieldas: Teisingai, kurie šioje erdvėje yra tradiciniai įtariamieji įrankiu DBArtisan ir tai? Aš padariau keletą namų darbų apie tai, ką neseniai parašei, ir iš atminties ką nors parašei, manau, kad tai buvo vienas iš tavo tinklaraščių, apie ypatingą duomenų bazių našumą „Oracle“ pasaulyje. Neįsimenu, kada tai buvo, manau, kad kažkada šiais metais iš atminties ar iš praėjusių metų pabaigos jūs jau rašėte šį dalyką. Ir man atrodė, kad tai yra tradicinis, įprastas įtartinas dalykas, apie kurį šiandien kalbame, kai žmonės eis į labai plataus masto duomenų bazių aplinką ir ieškos to, ką jūs vadinate ypatingu pelnu. Kas yra įprasti įtariamieji, kuriuos matote ten, kurie pradeda DBArtisan ir naudoja jį gerai?

Bertas Scalzo: Na, mes turime daug klientų iš tikrųjų, šiandien aš bendravau su labai didele vyriausybine agentūra, kuri - ir tiesiogine prasme turbūt turi beveik 1000 mūsų programinės įrangos egzempliorių, nes tai leidžia žmonėms susikoncentruoti į tai, ką jie darote, o ne kaip tai padaryti. Ir tai gerai, turiu omenyje, kad visi turėtų žinoti, kaip ką nors padaryti, tačiau produktyvumas tampa tuo, kas padaryta. Jei verslas paprašo manęs atlikti užduotį, tai yra viskas, kas juos domina. Kada gavau varnelę, kad pasakyti, kada užduotis buvo atlikta? Ne kokią techniką ar kokį technobabą aš panaudojau ten patekti. Taigi, mūsų įrankis leidžia jiems sutelkti dėmesį į tai, kas leidžia, ir leidžia daug našiau, ir tai tikrai yra didžiulis pranašumas, ir, kaip jau sakiau, kai kurios duomenų bazės siūlo įrankį tik jų duomenų bazės platformai. Mes siūlome tai dvylikai duomenų bazių platformų. Aš ta pati darbo eiga, ta pati grafinė vartotojo sąsaja, tos pačios navigacijos. Jei žinote, kaip suteikti privilegiją vartotojui arba kaip sudaryti lentelę ar sukurti indeksą duomenų bazėje, galite tai padaryti visais dvylika, nes tai yra tas pats vaizdas ir pojūtis, ir ta pati darbo eiga. Tai turi didžiulę vertę mūsų klientams.

Dezas Blanchfieldas: Taip, manau, žmonės nori gauti daug daugiau sprogdinimo už savo pinigus iš savo žmogiškųjų išteklių. Dienos, kai turėjome individualų „Oracle“, „Ingres“ ir „DB2“ specialistą, jau nebėra. Tikimasi, kad žmonės bus visų sandorių „Jack“, todėl aš manau, kad šis dalykas išgelbėjo jų gyvybes.

Tik paskutinis greitas dalykas, prieš perduodamas jį gydytojui Robinui Bloorui. Jūs minėjote, kad keturiolika dienų nemokamai atsisiunčiama, ką reiškia - jei aš eisiu į priekį ir padarysiu tai, beje, aš įdėsiu jį į „Bloor“ technikos laboratoriją ir suklasiu šį dalyką pakilkite ir susikibkite už rankos - aš iki šiol neturėjau galimybės to padaryti. Minėjote keturiolikos dienų bandymą, sakėte, kad naudojate jį VM kompiuteryje, manau, kad tai nešiojamas kompiuteris. Kokios yra pradinio lygio sąrankos nuostatos tam, kad kažkas galėtų atiduoti rankas į rankas ir naudoti keturiolikos dienų bandomąją versiją, prieš man perduodant Robiną į jo klausimus?

„Bert Scalzo“: Bet kuri „Windows“ aplinka, taigi „Windows 7“, virtuali mašina su vienu procesoriumi ir keturiomis atminties grupėmis. Mes nesame tikrai riebus ar brangus įrankis. Dabar, jei norėtumėte paleisti savo duomenų bazės serverį tame pačiame VM tame pačiame „Windows“, taip, turėtumėte pridėti daugiau, bet jei naudojate savo duomenų bazę duomenų bazės serveryje arba atskirame VM, įkelkite ir įkelkite VM paleisti mūsų produktą yra labai lengvas: vienas centrinis procesorius, keturi atminties paketai, beveik bet kokia „Windows“ versija - ir mes palaikome trisdešimt du ir šešiasdešimt keturis bitų diegimus. Bet jūs turite įdiegti savo duomenų bazės pardavėjo klientą. Taigi, jei norėjote prisijungti prie „Oracle“, turite įdiegti SQL tinklo klientą, nes to reikia „Oracle“, kad galėtumėte kalbėtis su duomenų baze.

Dezas Blanchfildas: Skamba gana tiesiai. Manau, kad vienas dalykas iš to, kas tikiuosi, kad žmonės atims, išskyrus tai, kad suprantu, kad ši priemonė padės išgelbėti jų gyvybes, yra tai, kad jie turėtų eiti ir atsisiųsti jį ir žaisti su juo, atsižvelgiant į tai, kad jūs siūlote keturiolikos dienų nemokamą bandomąją versiją. Ir jis gali veikti jų dabartiniame nešiojamajame kompiuteryje, neįdiegdamas nieko papildomo, nes jei jie jau vykdo duomenų bazių administravimą, jie jau dirba su duomenų bazėmis, jie turi visus tuos įrankius, nesvarbu, ar jie veikia vietiniame VM, ar vietiniame darbalaukyje, atrodo, kad neskausmingai įdiegti ir žaisti. Taigi labai rekomenduoju žmonėms tai padaryti.

Robin, aš tikiu, kad turite klausimų, ir Eric, jūs tikriausiai turite iš auditorijos, taigi Robin, kaip aš perduosiu tau, o paskui atgal Ericui?

Robinas Blooras: Taip, gerai, gerai, kad turiu ką pasakyti, turiu omenyje, kad visada man ši sritis buvo įdomi, nes ji buvo - supjaustiau dantis. Bet tiesa yra ta, kad turbūt nuo maždaug 1998 m., 1999 m., Aš imuosi to, ką „Oracle“ iš tikrųjų sugeba. Ir aš žinojau „Sybase“ ir „Microsoft SQL Server“ - abi šios yra gana paprastos, palyginti su tuo, ką galėtų padaryti „Oracle“. Jūs privertėte mane juoktis, kai jūs galvojate, kad užsidengiau burną, kai pradėjote kalbėti apie skardą. „Oracle“ tai darė anksčiau. „Oracle“ pristatė tam tikru metu, jie susierzino dėl objekto-santykio idėjos, todėl jie pristatė galimybę sukurti „Oracle“ savotišką objektų žymėjimą ir objektų saugojimą. Aš kalbėjau su vienu iš jų inžinierių, panašiu į porą metų po to, kai jie pristatė, ir aš paklausiau, kiek žmonių juo naudojosi, ir jis sakė, kad aš manau, kad du klientai jį išbandė, ir viskas. Ir aš manau, kad tas pats nutiks, jei jie pradės bandyti daryti „NoSQL“ dalykus. Žinai, aš manau, kad tai klaida, turiu omenyje tai, kad mane domina tavo mintys. Be abejo, jie geria „Kool-Aid“. Jie jaučiasi taip, lyg turės turėti galimybę pateikti teiginius, panašius į dideles „NoSQL“ duomenų bazes, tokias kaip „Cassandra“, bet žinai, ar tau tai yra prasminga?

Bertas Scalzo: Ne, jūs pataikėte į nagą tiesiai ant galvos. Aš norėčiau, jei darysiu reliacinius ryšius, pasirinkti ryšių paslaugų teikėją, pavyzdžiui, „Oracle“ ar „SQL Server“, „DB2“ ar „Postgres“, bet jei darysiu tai, kas nėra santykinė, didelėje duomenų erdvėje arba „NoSQL“ erdvėje aš išsirinksiu tinkamą įrankį tinkamam darbui atlikti. Ir nemanau, kad tai pirmiausia būtų natūralus būdas kreiptis į mano reliacinių duomenų bazių pardavėją. Tada pridedate prie jos kitą raukšlę, tai yra, kas yra debesyje? Tiek daug žmonių, norinčių atsisakyti savo duomenų bazių, neturi prielaidos. Tuomet jūs turite pažiūrėti į savo debesijos paslaugų teikėją ir pasakyti: „Gerai, ką jūs teikiate, kokias duomenų bazes man turite, kad jos atitiktų mano poreikius ir kiek jos yra parduodamos, ir atvirai kalbant, koks yra mokesčio ar mokesčio už naudojimąsi ta duomenų baze pasirinkimas? debesyje per valandą arba per dieną. Ir už gigabaitą ar terabaitą? “Ir tai, ką rasite, yra kai kurios palyginti naujesnės duomenų bazės, tokios kaip„ Mongo “ar„ Cassandra “, galbūt jų kainos yra pigesnės, taigi, jei ketinate daryti kelių petabaitų tipo didelius duomenis, galbūt turi - tik žvelgdami į sąnaudas - atsižvelgti į „NoSQL“ duomenų bazes debesyje, nes jos gali būti ekonomiškiausias būdas tai padaryti.

Robinas Blooras: Taip, teisingai. Aš turiu omenyje tai, kad turiu omenyje reliacinių duomenų bazių, kurios yra pakankamai ilgos, kad būtų randai, tai tikrai. Yra daug sveiko proto, kad jei jūs pradedate ją taikyti ir jūs suprantate, kas iš tikrųjų yra reliatyvus, tai Aš turiu omenyje, kad prisimenu, kad vieną kartą konsultavosi su vienu klientu, ir jie nuvedė mane į kambarį. Jie buvo sudarę savotišką subjektų schemą ir sukūrę trečią normalią formą - modelį, koks buvo įmonės pirminės sistemos. Ant jo buvo du šimtai keturiasdešimt stalų ir jie sakė: „Na, ką jūs apie tai galvojate? Mes ketiname sukurti duomenų bazę tam “, ir paklausiau„ Ką jūs apie tai galvojate? “Aš atsakiau:„ Aš nemanau, kad tai veiks. “Ir tai visiškai teisinga, žinote, nes jie baigėsi aukštyn, kad būtų sukurta tam tikra struktūra per vienuolika sujungimų. Štai ką reikia suprasti apie reliatyvumą. Taigi mane domina, kiek blogo dizaino jūs patiriate. Aš turiu omenyje, kad aš neturiu jokių problemų dėl „DBArtisan“ - tai daro labai protingus dalykus, o tai, kad jūs, tiesą sakant, galite iš tikrųjų demonstruoti keliose platformose, yra nuostabu - bet kiek jūs susiduriate ten, kur kyla dizainas kur žmonės galėjo išspręsti visokius širdies skausmus, jei pasirodytų pagal žvaigždžių schemą, o ne gautų snaigę, žinote?

Bertas Scalzo: Na, aš nenoriu skambėti kaip įžūlus ar arogantiškas, bet aš sakyčiau dažniau. Akivaizdu, kad dauguma duomenų bazių, kuriose aš dalyvauju, turi problemų ar problemų. Kas yra gerai, nes mūsų įrankiai, tokie kaip duomenų bazių optimizavimo įrankis, gali padėti išspręsti tas problemas, ir, kas man iš tikrųjų juokinga, yra tai, kad daug problemų yra tos pačios paprastos problemos vėl ir vėl. Aš kitą dieną tiesiog dirbau su klientu, kuris turėjo vienuolikos prisijungimo užklausą, ir man patinka: „Gerai, kodėl jūs nenaudojote sąlygos su sąlyga?“, Ir jie yra tokie: „Na, aš ne „Nežinau, kas tai yra.“ Ir tada aš pasakiau: „Ir pažiūrėkite į jūsų antrinius atrankos variantus į jūsų koreliuotą ir nesusijusį“, aš pasakiau: „Kai kuriais atvejais jūs turite savo„ išlygą “giliausiame lygmenyje, lentelės nuoroda iš išorės. “Aš sakiau:„ Tai yra, perkelkite ją į reikiamą lygį, nedėkite jos giliau, nei turi būti, supainiojate optimizatorių. “Ir atlikdami keletą porų patarimų paėmė tai, kas veikė maždaug dvi valandas, ir sutrukdė iki dešimties minučių, ir viskas buvo tik - tokiu atveju mes nieko nedarėme, tik patobulinome jų parašytą SQL. Aš manau, kad problema yra ta, kad daugybė universitetų ir daugybė žmonių, kurie mokosi programavimo neakademinėje aplinkoje, mokosi to kaip fiksuoto laiko procesai arba į eilę orientuoti procesai, o reliaciniai yra prigimties orientuoti rinkiniai, taigi jūs turi galvoti rinkiniais, kad parašytų gerą SQL.

Robinas Blooras: Taip, aš manau, kad tai visiškai teisinga. Ir jūs turite suprasti, kad tai yra dalykai, pvz., Žmonės turėtų žinoti tokių dalykų ABC. Nesvarbu. Negalėsite daryti racionalių dalykų, jei nesuvoksite, kad net gerai suprojektuota, gerai modeliuota duomenų bazė prisijungs, užtruks, rūšiavimas užtruks. Jie tai daro todėl, kad pasaulis niekada nerado būdo, kaip priversti tuos greitai praeiti. Jie atrado duomenų tvarkymo būdus, todėl jie eina greičiau nei kitaip, ir didelis entuziazmas, kurį turiu pasakyti apie NoSQL duomenų bazes, yra tiesiog tai, kad jie vengia prisijungti. Jie tiesiog pradeda kurti duomenų bazes, naudodamiesi vienoda duomenų sklaida juose, nes jei prisijungsite prie bet kurios „NoSQL“ duomenų bazės, jos labai čiulpia. Ar nemanote?

Bertas Scalzo: O, be abejo . Ir aš turiu juoktis, nes aš pradėjau atgal prieš reliacines duomenų bazes ir dar tada, kai Ingres buvo RTI, Santykių technologijos institutas, o mes neturėjome SQL, mes turėjome išankstines SQL reliacines kalbas. Aš manau, kad tuo metu Ingres mieste jis buvo vadinamas Queliu. Taigi jūs gavote iš šių senų duomenų bazių paradigmų, tokių kaip tinklas ir aukštesnė grafinė ar hierarchinė, ir po poros dešimtmečių išgyvenate reliacines paradigmas, ir dabar man atrodo, kad mes vėl grįžtame prie beveik hierarchinės. Tai beveik kaip mes grįžome.

Robinas Blooras: Taip, teisingai. Geriau perduokite Erikui, aš per daug sugaišau laiko, bet ar turime kokių nors klausimų iš auditorijos, Eric?

Ericas Kavanaghas: Mes turime keletą. Mes dar ilgai čia eisime, bet pora įmes į tave. Turėjome porą klausimų, susijusių su nematomais rodyklėmis. Vienas klausimas buvo: „Ar reikia naudoti jūsų įrankį norint juos pamatyti?“ Kitas klausimas buvo: „Na, o kas, jei tu esi aklas?“

Bertas Scalzo: Tai gerai.

Erikas Kavanaghas: Įdomus klausimas, taip pat tiesiog FYI.

Bertas Scalzo: Ne, jūs neturite turėti mūsų įrankių. Tai yra „Oracle“ funkcija, nematomų asmenų rodyklė. Iš esmės duomenų žodyne „Oracle“ tiesiog saugo metaduomenis, kuriuose rašoma: „Optimizatorius, nepaisykite šio indekso“. Tai čia, bet nebent jums fiziškai patariama dėl užuominos į SQL komandos optimizavimo priemonės užuominą, nenaudokite to. “Taigi, ne, jūs neturite turėti mūsų įrankių ir visais atžvilgiais tai reikia. yra paprastas senas rodyklė, galite pamatyti bet kuriame įrankyje, tiesiog optimizatorius pasakys: „Mes to nepaisysime įprasto užklausų apdorojimo metu.“ Jei norite, kad jis priprastų, turite nukreipti. Tai tikrai patogu mano aprašytam scenarijui, jei norite sukurti gamybos indeksą, tačiau nerizikuojate sulaužyti ataskaitų ar jau vykdomų dalykų, bet norėjote juos išbandyti, galėtumėte tai padaryti. Tam jis yra naudingiausias.

Ericas Kavanaghas: Tai geras daiktas, tada čia kilo dar vienas geras klausimas. „O kaip su kai kuriomis iš šių naujų atmintyje esančių duomenų bazių? Kaip atminties duomenų bazių technologija keičia žaidimą indeksavimo atžvilgiu? “

Bertas Scalzo: Berniukas, gerai, mes - dabar tai gerai, džiaugiuosi, kad kažkas uždavė tą klausimą, turėsime eiti dar pusvalandį. Ne, atmintyje, tai priklauso nuo duomenų bazės pardavėjo. Dabar aš paprastai kalbu tik už tai, ką daro „Oracle“, nes girdžiu jų sukurtą technologiją, tačiau kai ašarojate po dangteliais ir žiūrite, kokia yra „Oracle“, „Oracle“ atmintinė. duomenų bazė, kokia ji yra iš tikrųjų, ar ji vis dar laikoma eilučių saugykloje diske, ir joje bus įkelta stulpelių saugykla atmintyje, o jei nepakanka atminties, kad būtų galima laikyti visą lentelę, ji vėl grįš į dalis; jis netilps atmintyje, jei norite atlikti eilių parduotuvę, taigi jūs iš tikrųjų galėtumėte pasirinkti lentelę, o pusei stalo naudojate indeksavimą, trenkdami tradicines eilutes prie stalo, o kitai pusei pasirinkite, kad jis iš tikrųjų išeitų ir tiesiog sugriebtų viską iš atmintyje esančios paieškos, taigi, skiriasi tuo, kad, pavyzdžiui, SQL serveris įdiegė jį savo „Hekaton“ technologija, jūs žinote, ir SQL 2014, ir jis buvo patobulintas „SQL 2016“ versijoje, tačiau tam tikrais aspektais jų teisingesnė vidinės atminties versija yra, tačiau kiekviena iš jų turi pliusų ir minusų, tačiau reikia rūpestingai žiūrėti po viršeliais ir suvokti. Nes aš turėjau klientą, kuris pasakė: „O, šios lentelės atmintyje - aš tiesiog ruošiuosi sudaryti visus indeksus“, ir aš esu toks: „Lentelė didesnė nei jūsų serverio atmintis, taigi tam tikru metu kai kurios užklausos turėjo patekti į diską “.

Erikas Kavanaghas: Tai geras aprašymas; tai geri dalykai. Na, žmonės, per šiuos likusius metus turėsime dar keletą transliacijų su šiais vaikinais. Grįžkite bet kada, kai girdėsite apie Berto dalyvavimą pristatyme, nes mes žinome, kad jis žino jo daiktus. Visada smagu kalbėtis su ekspertais. Mes archyvuojame visas šias internetines transliacijas, kad galėtume jas vėliau peržiūrėti. Štai dar kartą „Bert“ kontaktinė informacija. Mes pabandysime išsirinkti šią nuorodą atsisiuntimui ir išsiųsti ją taip pat el. Paštu, tačiau visada galite el. Paštu atsiųsti el. Laišką: mes turime dar daugybę internetinių transliacijų, skirtų tam. metus ir mes darome ed cal, taigi, žmonės, jei yra kokių nors temų, kurias tikrai norite išgirsti apie kitus metus, nebijokite: būkite atsargūs, žmonės, mes su jumis kalbėsimės kitą kartą. Iki.

„Techopedia“ turinio partneris

„Techopedia“ personalas yra susijęs su „Bloor Group“ ir su juo galima susisiekti naudojant dešinėje pateiktas parinktis. Norėdami sužinoti daugiau informacijos apie tai, kaip mes dirbame su pramonės partneriais, spustelėkite čia.

• Profilis
• Interneto svetainė