Indeksa ārprāts: kā izvairīties no datu bāzes haosa

Autors: Techopedia Staff, 2016. gada 5. oktobris

Takeaway: Uzņēmējs Ēriks Kavanagh apspriež datubāzu indeksāciju ar Dr. Robinu Blooru, Dezu Blanšfīldu un IDERA Bertu Scalzo.

Pašlaik neesat pieteicies. Lai redzētu video, lūdzu, pierakstieties vai reģistrējieties.

Techopedia satura partneris

Techopedia darbinieki ir saistīti ar Bloor Group, un ar viņiem var sazināties, izmantojot labās puses iespējas. Lai uzzinātu vairāk par to, kā mēs strādājam ar nozares partneriem, noklikšķiniet šeit.

• Profils
• Vietne

Ēriks Kavanaghs: dāmas un kungi, sveiki un sveiciniet vēlreiz. Ir trešdiena, pulksten četros austrumos, un tie no jums, kuri zina programmu, zina, ko tas nozīmē, ir pienācis laiks vēl vienai karsto tehnoloģiju sērijai. Jā, patiesi. Mans vārds ir Ēriks Kavanaghs, es būšu jūsu šodienas sesijas moderators: "Indeksa ārprāts: kā izvairīties no datu bāzes haosa". Vai kā es to norādīju pēdējā e-pasta sprādzienā, lai izietu, “datubāzes nemierīgā”. Karstais termins šajās dienās “ķildošanās”. Visi to dara. Ir patiess slaids par tavu. Un par mani pietiek.

Tātad karsto tehnoloģiju sērija patiešām tika izstrādāta, lai noteiktu konkrētu telpu, nevis Briefing Room, kas ir tikai viens pret vienu tiešraidē pavadošs analītiķu instruktāža. Hot Tech mēs iegūstam divus analītiķus. Šodien tas būs mūsu pašu ārsts Robins Bloors un mūsu datu zinātnieks Dezs Blanšfīlds. Un mēs runājam par tēmu, kas, manuprāt, patiešām ir diezgan simboliska tam, kas šodien notiek tirgū.

Galvenais ir tas, ka mūsdienās mēs esam sarežģītā pasaulē. Tiešām, ja jūs domājat piecpadsmit gadus vai divdesmit gadus atpakaļ, tad toreiz tā bija ievērojami atšķirīga pasaule, it īpaši attiecībā uz datu bāzu tehnoloģiju. Datubāzes agrāk bija diezgan vienkāršas. Viņu bija tikai nedaudz; vairums no tiem bija relāciju veidi. Tagad mums ir viss šis datu bāzu tehnoloģiju klāsts. Burtiski tabulas iespēju klāsts ikvienam, kurš vēlas izveidot lietojumprogrammu vai kaut ko darīt ar datiem. Viss mainās, un tas ietekmē cilvēkus, kuri mēģina pārvaldīt šīs sistēmas. Mēs šodien sarunāsimies ar Bertu Scalzo, kurš ir īsts jomas eksperts; viņš ir IDERA vecākais produktu menedžeris par to, ko jūs varat darīt, lai tiktu galā ar visiem šiem datiem. Līdz ar to es to nodošu doktoram Robinam Blooram, lai viņš to atņemtu. Robin, grīda ir tava.

Robins Bloors: Labi, paldies par iepazīstināšanu. Es domāju, ka tā - tā kā tā ir divu roku lieta, es domāju, ka es runātu tikai par datu bāzes optimizēšanu kopumā kā ievadu šajā Hot Tech šovā. Es sāku dzīvi - tehnoloģiju un analīzes jomā - es sāku to darīt, jo es kādreiz rakstīju rakstus par datu bāzu iespējām DEC VAX platformā. Un šī iemesla dēļ datu bāzes iztērētāji mani mēdza informēt. Un tas, kas man rodas, ir tas, kāpēc jums būtu datu bāze? Es domāju, ka šajās dienās šausmīgi daudz cilvēku izmantoja, lai izveidotu galveno vērtību failus un tos izmantotu, lai būtu sava veida indeksa secīga kļūda, kā mēs tos saucam, bet lai izveidotu sava veida datu bāzes iespējas, un jūs zināt, kāpēc jums būtu jebkas cits?

Un, atbildot uz to, es domāju, ka vislabāko atbildi sniedza Maikls Stounbrakers, un viņš sacīja: "Datu bāze var uzzināt vairāk par to, kur ir dati un cik ātri tos iegūt, nekā jebkura programma jebkad var zināt." Un es domāju, ka tas ir interesanti; tas ir spēles raksturs. Bet 19 - labi par 1989. gadu, kuru es sāku tehnoloģiju analīzē, un jūs zināt, tajā brīdī datu bāzes bija ļoti vienkāršas, un relāciju datu bāzes bija ļoti vienkāršas. Viņiem bija tik maz iespēju, es domāju, ka viņi, protams, varēja uzglabāt datus, un jūs varētu dublēt, un viņiem bija, viņi bija saderīgi ar ACID, taču viņiem patiešām bija ļoti vāji optimizētāji. Faktiski būtu grūti apgalvot, ka viņiem vispār bija optimizētāja spēja.

Un vēlāk viņi vienkārši kļuva labāki, bet, jūs zināt, kad datu bāze nefunkcionē - tā kā šie ķenguri vienādi vai citādi norāda - var būt šausmīgi daudz iemeslu, kāpēc tas notiek lēni. Un tas mani norāda: datu bāzēm ir daudz funkciju, bet vissvarīgākā no tām ir vaicājumu optimizācija. Ja viņi to nedarītu, jūs tos neizmantojat. Tas ir saistīts ar informācijas ātru iegūšanu, kā arī par iespēju to izdarīt, ja ir daudz vienlaicīgu lietotāju, un tā ir smaga problēma. Un, kad jūs patiesībā skatāties, sauksim tās par nobriedušām datu bāzēm, ja jums patīk - bet noteikti Oracle, nedaudz mazākā mērā - Microsoft SQL Server, protams, Teradata un DB2 - šo datu bāzu optimizētāji ir ieguvuši gadu desmitiem ēka. Jūs zināt, viņi nespēja - kāds neapsēdās - seši puiši uz divnieka, gadu, projektu un tikai vienu kopā sapucēja. Tā tas nedarbojas. Optimizācijas iespējas ir pakāpeniski pieaudzis, un tas prasa daudz pieaug. Jebkurā gadījumā parunāsim par datu bāzes fona. Nu, tur ir šausmīgi daudz, ko tagad saka par NoSQL datu bāzi, un ir pat daudz entuziasma par grafu datu bāzi. Un SQL izmantošana pār Hadoop un tamlīdzīgas lietas. Bet patiesība ir tāda, ka, ja jūs šobrīd vēlaties datu bāzi, ja vēlaties pilnībā funkcionējošu, kas spēj OLTP un lielu vaicājumu trafiku, tā ir relāciju datu bāze vai tā nav nekas.

Starp relāciju datu bāzēm Oracle ir dominējošā popularitāte. Microsoft SQL Server, es domāju, ir otrais. Viņi abi ir izmantojami OLTP un vaicājumu darba slodzei, bet patiesībā jūs nevarat izvairīties, sajaucot šo darba slodzi. Jums ir nepieciešami dažādi gadījumi OLTP darba un vaicājumu darba slodzēm. Pastāv alternatīvas SQL un diagrammai. Lielākā daļa uzņēmumu standartizē vienu specifisku datu bāzi, tieši tāpēc - es domāju pēc gadu desmitiem ilgas cīņas ar visiem pārējiem spēlētājiem, Oracle kļuva par dominējošo. Vienkārši tāpēc, ka viņi galu galā varēja pārdot korporatīvās licences, un tāpēc uzņēmumi alternatīvus produktus izmantotu tikai ārkārtas produktos, kurus Oracle vienkārši nedarītu. Un datu bāzes ir stratēģiskas tajā ziņā, ka tās attīstās. Un jūs zināt, ka es nedaudz izpētīju šo prezentāciju, un tas ir sava veida - es pēc tam pie tā atnākšu, bet tas ir sava veida interesanti, kā viņi attīstās, skatoties uz to no DBA pozīcijas. To es saucu par neredzamo tendenci. Tas ir Mūra likums kubā. Tas ir aptuveni šāds: Lielākā datu bāze ir, un jaunas datu bāzes, nav vecas datu bāzes, kurai būtu daudz vairāk datu, lai to uzņemtu. Parasti tā ir datu bāze, kas tiek piemērota jaunai problēmai. Un datu apjoma ziņā tie faktiski pieaug. Aptuveni pie Mūra kuba likumu. Tātad Mūra likums ir koeficients desmit reizes sešos gados. VLDB mēdz pieaugt koeficients tūkstoš reizi sešos gados. 1991., 1992. gadā lielās datu bāzes tiek mērītas megabaitos. '97. Un '98. Gadā - gigabaiti. 2003, '4, terabaiti. 2009. gads, '10. Gads, jūs sākat redzēt petabātu datu bāzes. Es domāju, ka šobrīd tur, iespējams, bija viena vai divas eksabātu datu bāzes, taču lielākā, par ko esmu dzirdējis, ir 200 petabaitu laikā, un, jūs zināt, nesaņemot datus petabātu datu bāzēs. Bet, acīmredzot, lielākoties tie būs jaunie lielie web 2.0 uzņēmumi, iespējams, ka jums ir Facebook virziens šajā virzienā.

Jebkurā gadījumā, ja jūs to tiešām skatāties, gaidot, ka datu bāze iziet šāda veida apjoma palielināšanos, tas prasa daudz. Un ievērojams, ka, protams, līdz petabātu līmenim viņi, šķiet, ir paveikuši samērā labi. Es domāju, ka es runāju par vecākiem produktiem, nevis par kaut ko jaunu. Liekas, ka viņiem ir veicies ārkārtīgi labi. Ja mēs skatāmies uz datu bāzu veiktspēju, vājās vietas, tas atgriežas pie laika, kurā es patiesībā rūpējos par viņiem, un man bija par tiem jāuztraucas. Jūs zināt, ka tas principā ir aparatūras sadalījums. Ir CPU sastrēgumi, iespējams, ir atmiņas trūkumi, iespējams, ir arī diska sašaurinājumi. Tas var būt tīkls, kas jums rada bēdas, un jūs varat arī iegūt problēmas ar bloķēšanu atkarībā no tā, ko jūs darāt, bet parasti tas notiek tāpēc, ka programma nezina, kam piezvanīt. Tātad, ja jūs gatavojaties noregulēt datu bāzi, jūs faktiski cenšaties to noregulēt tā, lai tā dejotu starp šīm piecām iespējamām sašaurinājumiem, cik labi vien iespējams. Un tas nav viegli, jo dramatiski palielinās atmiņas apjoms, kuru jūs varētu konfigurēt uz jebkura konkrēta servera. Tad CPU ir kļuvuši par daudzkodolu, disku, un to mēs tagad arī varam darīt, es domāju, ka pat preču serveros es domāju, ka jūs varat darīt simtiem un simtiem terabaitu, ceturtdaļai petabaitu, varbūt pat preču serverim. Tātad, izmantojot visas šīs lietas, jūs varat spēlēt, tīkls, protams, var darboties ar dažādu ātrumu, taču lielākoties, strādājot ar datu bāzēm, jūs patiešām vēlaties, lai starp serveriem būtu optisko šķiedru kabeļi, un nekas cits tajā nedarbojas tādā veidā.

Datubāzes veiktspējas faktori. Es domāju, ka es neatstāšu to, par ko tas viss notiks, jo es zinu, ka Dez par to runās, bet slikta datu bāzes konstrukcija nozīmē sliktas veiktspējas datu bāzi. Slikts programmēšanas dizains, iespējams, var nozīmēt ļoti muļķīga SQL ievietošanu datu bāzē, kas vienkārši prasīs daudz vairāk laika. Vienlaicīgums un darba slodzes sajaukšana, pārāk liela vienlaicība radīs problēmas ar sašaurinājumu. Darba slodzes sajaukšana, ja jums ir lieli jautājumi ar ļoti maziem, īsiem, asiem jautājumiem, tas rada problēmas. Pastāv slodzes līdzsvarošanas problēma. Lielākā daļa datu bāzu par to rūpējas, bet, ja jums vēl nav izsmalcināta produkta, tad jūs zināt, ka tikai pievienojat dažus serverus, tas nav viss, ko jūs darāt, ja patiesībā vēlaties palielināt klastera izmēru. Lai iegūtu optimālu veiktspēju, jums faktiski ir jāsabalansē slodze. Jums jādara kapacitātes plānošana. Pilnīgi. Īpaši tagad, šajās dienās, kad datu apjoms palielinās dramatiskāk nekā tas bija agrāk datu bāzēm. Un datu vākšanai, kā jūs pārvietojat datus, ir visas datu slāņa problēmas. Datu savlaicīga nesaņemšana datu bāzē var būt veiktspējas problēma vēlāk, jo mēs esam pārgājuši no operētājsistēmās Windows strādājošajām datu bāzēm uz divdesmit četrām pa septiņām trīs simtiem septiņdesmit piecām operācijām un nav logu, kur varētu palēnināt datu bāzu darbību. datu bāze nav izveidota, vai maz ticams, ka mūsdienās tāda būs.

Oracle DBA problēma. Tas ir tas, par ko es domāju. Esmu bijis Oracle DBA kopā ar Oracle 7, un es atceros, kā to noskaņot. Un, ja jūs faktiski skatāties uz Oracle tagad, tas ir veids, veids - tas ir veids, kā vairāk iespēju. Tam ir bitkartes indeksācija un tamlīdzīgas lietas, bet es faktiski paņēmu laiku, lai apskatītu un uzzinātu, cik daudz tur šobrīd ir Oracle datu bāzē esošo tuning parametru. Un ir vairāk nekā trīs simti piecdesmit noregulēšanas parametru, un ir vēl simts slēptu parametru, par kuriem speciālisti DBA varētu zināt, bet parastie Oracle DBA nezina. Un tas nozīmē, ka šāda veida datu bāzes iestatīšana ir sarežģīta lieta. Tā nepavisam nav vienkārša lieta. Jums tas ir jājūtas, jums tas ir jādara jau ilgu, ilgu laiku, un jūs precīzi esat jāzina, kāda ir problēma, kuru, jūsuprāt, risināt, jo skaņošana sākas, kad sniegums kļūst slikts, bet tas var nebūt viss. Varbūt svarīga ir noteiktu vaicājumu veikšana, un jūs, iespējams, varēsit to labot, piespraužot noteiktus datus un atmiņu, vai arī jums tas būs jālabo, indeksējot, vai arī jums var nākties sākt sadalīšanu citādā veidā. Ir daudz lietu, ko varat darīt, ir jēga. Līdz ar to viņi to nedarīs galvā - DBA ir nepieciešami rīki. Es tagad nodošu Dez, kurš, manuprāt, jums pastāstīs par indeksēšanu.

Ēriks Kavanaghs: Labi, Dez, atņemiet to.

Dez Blanchfield: Paldies, Robin, un es mīlu titullapu. Es domāju, ka jūs esat nometis sprādzi tur, lai es varētu nākt pat attāli pie kaut kā tik aizraujoša. Bet es esmu izmantojis mūsu mazās galaktikas attēlu, kā mans skatījums uz to, kas ir kļuvis par šodienas izaicinājumu datubāzu administratoriem, jo ​​tas ir garīgais tēls, kuru es mēdzu uzburt, nonākot vidē, un es vairs neesmu datu bāzu administrēšanas vai datu bāzu veidošanas līmenī šajā līmenī. Bet, tāpat kā jūs, Robins un es daudzus gadus esam iesaistījušies datu bāzu pasaulē vai nu kā administrators, vai arī izstrādātājs, vai galu galā kā arhitekts, un tad sapratu, ka es varētu darīt labākas lietas, lai nopelnītu garoza. Bet parasti mēdz justies kā jūs skatāties uz šo datu galaktiku, un vēl jo vairāk šodien, kad mēs pārejam no, kā jūs norādījāt, ļoti īsā laika posmā esam pārgājuši no megabaitiem uz petabaitiem un ekso mērogu, lielo lietu shēmā. Bet frāze, kas man ienāk prātā, ir tāda, ka datu bāzu indeksi tagad ir melna māksla, un tie nav īsti tādi sīkumi, kādos vienkāršiem mirstīgajiem vajadzētu izkļūt uzņēmējdarbības līmeņa biznesa lietojumos un kā jūs formulējat. tikai runāja par. Bet es gribēju ātri iziet no vēstures veida, kāda man ir bijusi ar datu bāzu pasaulēm, un nokļūt kontekstā, kur mēs gatavojamies izdarīt secinājumus, un pēc tam šodien kopā ar draugiem izskatīt kādu materiālu IDERA, jo, manuprāt, ir daudz un dažādas domāšanas par to, kā iegūt datu bāzes veiktspējas pielāgošanu, un viens no viņiem ir skārda piemetināšana lietai. Daudziem veikaliem, ar kuriem es saskāros, viņi vienmēr nenonāk līdz tādam, lai veiktu veiktspējas iestatīšanu datu bāzes slānī un it īpaši indeksa slānī, kamēr nav izgājuši sarežģītu domāšanas ceļu, līdz viņi var iemest skaņotāju .

Daudzi cilvēki, manuprāt, to uztver ar lielu dzelzs pieeju, un man šeit ir Flash attēls, jo, ja jūs kādreiz esat skatījies kādas vecas filmas vai noteikti jaunāko TV šovu, izmantojot Flash, tāpat kā Flash Gordons ir vecais varonis un tagad, kad viņu sauc par “Flash”, viņš mēdz iet ļoti, ļoti ātri un vienmēr viņa enerģija iztek. Un tas notiek, kad metat lielu dzelzi datu bāzes veiktspējā. Vienmēr, pēc manas pieredzes, jūs varat likt lietā augstu veiktspēju, smagu darbu, jūs varat optimizēt operētājsistēmas un noskaņot tās uz noteiktu punktu. Jūs varat nodrošināt, ka jums ir ātrs daudzkodolu, vairāku vītņu CPU, lai padarītu lietojumprogrammu ātrāku, tajā varat iemest daudz operatīvās atmiņas, jums var būt augstas caurlaides spēka plāni, jūs varat pāriet no cietajiem diskiem uz cieto disku kešatmiņu uz cietvielu., un augstas veiktspējas krātuves masīvs. Un pat tagad cilvēki savā datu bāzu motorā ievāc tādas lietas kā flash un NVMe, domājot, ka iegūs šo pieteikšanās reizes divreiz lielāku veiktspēju. Un vienmēr viņi gūst zināmu labumu. Bet tas viss atgriežas pie tām pašām pamata veiktspējas iestatīšanas problēmām. Daudz zema latentuma tīkla savienojumu, lai kopas darbotos ātri. Un klasterizējiet datu bāzes infrastruktūru, tāpēc jums ir vairāk nekā tikai viena mašīna, kas veic visu darbu. Bet jums ir tendence atgriezties pie vienas un tās pašas veiktspējas pamata problēmas, un tas ir datu nolasīšana. Datu rakstīšana lielākoties ir diezgan lineārs izaicinājums un ja vien tas nav izdarīts pareizi.

Un tad mums mūsdienu pasaulē ir izaicinājums: ne visas datu bāzes ir izveidotas vienādi. Pastāv datu bāzes un citātu kotēšana “datu bāze”. Un, domājot par datu bāzu motoriem, cilvēki bieži domā par tradicionālajiem, parastajiem aizdomās turamajiem, kādi viņi bija SQL pasaulē. Jūs zināt, ka mums ir Oracle un Microsoft SQL Server, un atvērtā pirmkoda pasaulē ir pāris ap to ar MySQL, kas tagad pieder Oracle, bet tas joprojām ir atvērts avots. Un tad mums ir ne tik ierastie aizdomās turamie, NoSQL dzinēji, kuriem joprojām ir problēma saistībā ar indeksēšanu un veiktspējas pārvaldību, un es tos sīkāk neiedziļināšos, taču šo gadījumu skaits palielinās lietas, kas uznirst katru dienu, un tās izskatās un jūtas kā datu bāzu motori no izstrādātāju viedokļa un no veiktspējas viedokļa, taču tie ir ļoti, ļoti dažādi zvēri un viņiem ir sava maza niša pasaulē, kuru izdalīt veiktspēja atmiņā vai lineāra skala diskā. Bet tas ir tas, kā izskatās pasaule datu bāzu pasaulē. Šis ir 2016. gads, šī ir kartes trešā versija, ko veido virkne cilvēku, kuri izstrādā šo notiekošo ainavu karti, kā izskatās datu bāzes, un tieši šeit - pat pārcilvēcīgu datubāzu arhitektam vai datu bāzes administratoram varētu būt jēga no tā. Burtiski simtiem, simtiem un simtiem dažādu marku, modeļu, datu bāzu ražotāju, kas vienmēr ir saderīgi ar SQL. Un interesanti ir tas, ka viņi visi atgriežas vienā un tajā pašā izaicinājumā. Veiktspējas un veiktspējas pielāgošana datu bāzes dzinējam, it īpaši pēc tā, kā dati tiek indeksēti.

Tāpēc vienkārši ātri aptversim datu bāzu indeksēšanu, jo tā ir interesanta tēma, un es uzskatu, ka tajā ir jāiedziļinās sīkāk ar demo. Bet es domāju, ka tas ir diezgan labi pieņemts un standarta nozares prakse, ka datu bāzes indeksu veiktspējas iestatīšana ir tā vieta, kur sākas un beidzas pasaule, nodrošinot, ka jūsu dati ir pieejami ātri un ātri. Bet kas ir datu bāzes indeksēšana? Ja mēs domājam par indeksēšanu tādā formā, kā mēs esam pieraduši kā ikdienas cilvēki, domājiet par grāmatas indeksa lapu. Ja vēlaties kaut ko atrast grāmatā - it īpaši enciklopēdijas vai kaut kāda veida atsauces materiālus -, ja jūs meklējat kaut ko līdzīgu šai lapai, kur es meklēju lietas, piemēram, aizsprostu tēmu enciklopēdijā. Es vēlos atrast katru norādi uz aizsprostiem, ūdens sateci un lielu apbūves teritoriju, ko parasti rada māksla. Es iešu aizmugurē, es to atradīšu alfabēta secībā, sakārtotā sarakstā no A līdz Z, no kreisās uz labo, un es atradīšu D. Es atradīšu vārdu “dams”, un es to redzu 16., 38., 41. lappusē ir atsauce uz tām, un tad es varu pāriet uz šīm lapām, es varēju nolaist acis un atradīšu atsauci uz vārdu “dam”. Tas būtībā ir tāds pats jēdziens datu bāzē, bet tagad tā ir raķešu zinātne daudzos veidos. Tik daudz, ka faktiski ikviens datu bāzes administrators, ar kuru es kādreiz esmu labi iepazinies, uzskata indeksus par vienīgo viskritiskāko rīku veiktspējas noskaņošanai jebkurā datu bāzu pasaulē neatkarīgi no tā, kāda ir viņu pieredze, ciktāl tas skar skārdu, vai lai kāds būtu gadījums.

Parasti, kad mēs runājam par datu bāzes indeksēšanu, pastāv vairākas kopīgas pieejas. Un jo sarežģītāki kļūst datu bāzes indeksi, jo sarežģītāka ir pieeja datu indeksēšanai. Bet būtībā, domājot par datu indeksēšanu, iedomājieties, ka mums ir fails, kurā ir vārdu saraksts; tos nedrīkst sakārtot alfabēta secībā. Iedomāsimiesies, ka viņu ir divdesmit. Ja mēs kārtosim - ja mēs meklēsim datus šajā sarakstā, no augšas uz leju, un pieņemsim, ka tas ir vārdu saraksts. Ja es izvēlos nejaušu vārdu un es sāku ritināt uz leju no saraksta uz leju no augšas uz leju lineārā formātā un tas ir nesakārtots saraksts, ir divi kritēriji, par kuriem domāju, kā vidējo meklēšanas laiku un maksimālo meklēšanas laiku - un Man ir drukas kļūda otrajā rindā, jābūt “maksimālajam meklēšanas laikam”, piedodiet - bet mans vidējais meklēšanas laiks būtībā ir N plus viens, dalīts ar diviem, un tas ir vidēji tas, kas man prasa piecdesmit procentus laika lai skenētu no saraksta augšdaļas līdz saraksta lejasdaļai, lai šajā sarakstā atrastu jebkuru nejaušu lietu. Un otrajai rindai zem lineārā jābūt “maksimālajam meklēšanas laikam”. Bet maksimālais meklēšanas laiks būtībā ir vienību skaits, un tas nozīmē, ka, ja man ir divdesmit lietu saraksts, tad visvairāk laika tas var aizņemt kaut ko meklēt šajā datu bāzē ir jāiet no augšas uz leju, kas ir, teiksim, 20 vienumi šajā vienkāršotajā piemērā. Un tas ir ļoti lēns process, un tiešām nav nekādu iespēju to pielāgot. Un tad ir arī citi veidi, kā iegūt šos datus un izveidot indeksu, kas faktiski ir īss saraksts ar norādēm uz to, kur atrodas faktiskie dati, piemēram, binārs, B-koks, bitkarte, jaukšana, grupēšana un neklasēšana, un tad pastāv dažādi datu veidi, piemēram, telpiskais, filtrētais, XML un pilns teksts.

Binārie ir ļoti bieži lietoti gadījumi, kad dati tos izmanto. B koks, iespējams, vēsturiski ir visizplatītākais vienotajā nozīmē, jo tas ir parasts veids, kā strukturēt indeksu jebkura veida datiem, un tas ļauj relatīvi viegli veikt žurnālistus, atlasīt, ievietot un izdzēst, pārvietojot rādītājus ap norāde uz norādēm, punktiem. Ir arī citi veidi, piemēram, bitkarte, kur datu tipi attiecas, piemēram, ja mums ir saistīts kādas formas diapazons. Jaukšana ir ļoti piemērota lieliem objektiem, īpaši emuāriem un attēliem. Un jūs varat redzēt, ka datu indeksēšanai ir virkne dažādu zinātnisko pieeju, matemātisko pieeju. Vienkāršam mirstīgajam viņi ir interesants izaicinājums, par ko runāt šajā līmenī. Kad jūs runājat par to datu bāzes administratora veiktspējas līmenī, viņi patiešām kļūst par raķešu zinātniekiem un cilvēki viņos iegūst grādus, un es zinu, ka ārsts Robins Bloors to noteikti ir izdarījis un par to rakstījis grāmatas, piemēram, IBM un citi lieli zīmoli pēdējo pāris gadu desmitu laikā. Un tā, mans uzskats, ir tāds, ka mēs tiešām esam pagājuši laikā, kad, jūs reiz zināt, es personīgi varētu sēdēt kādas sistēmas priekšā un es varētu to atraut un parādīt jums precīzi tur, kur veiktspējas problēmas atradās komandrindas vai grafiskā lietotāja interfeisa sākuma rīkā, un sāka ienirt datos un pateikt, kur bija problēmas, un izveidot tajā indeksus vai apakšindeksus, vai primāros un sekundāros indeksus datus un sāciet to izmantot lietu atrašanai. Bet, domājot par šo ainavu, es jums parādīju, kur mums ir simtiem un simtiem zīmolu, marku un modeļu, kā arī datu bāzu ražotāji un tipi, un tagad mēs esam labi un patiesi pagājuši garām tam laikam, kur cilvēks var radīt izpratne par mūsu rīcībā esošajiem datu bāzu dzinēju veidiem. Īpaši, pat ja mēs tikai atgriežamies pie Oracle patīk, mūsdienās dominējošie zīmoli ir relāciju datu bāzu platformas.

Datu bāzu skaits, ar kurām tām jāsaskaras, izmantojot patentētu platformu, piemēram, ERP vai HR, vai finanšu sistēmu, vai neatkarīgi no tā, vai tās dažādu iemeslu dēļ ir mājās ceptas platformas, datu bāzu un datu bāzu tabulu un ierakstu skaits, kas mēs galu galā darīšana ir tikai astronomiska, un jūs fiziski to nevarat izdarīt ar rokām. Un tagad mums radās papildu sarežģījumi, kad reiz datu bāzes serveris varētu vienkārši sēdēt zem jūsu galda. Jūs zināt, ka būdams mazs bērns pēc skolas, es mēdzu strādāt un strādāt ar datu bāzu programmatūru sākotnēji Apple IIes un pēc tam DOS personālajā datorā balstītajās sistēmās, piemēram, dBase II, dBase III, izgāja laikmetu ar lieldatoriem un vidējo diapazons un pat VAX un PDP un tajā esošais žurnālfails. Un tāpat kā Sabre, un tad galu galā, kad nāca klāt kāda no SQL datu bāzēm. Bet šajās dienās, kad mēs domājam par datu bāzu dzinējiem, tie izskatās kā kreisajā apakšējā stūrī. Datu bāzes serveris vairs nav tikai viena mašīna, kas sēž uz grīdas zem galda; Tas ir simtiem mašīnu, kas darbina datu bāzu dzinēju un klasteru kopijas, un tās mērogo līdz simtiem un simtiem terabaitu datu, ja ne datu petabaitus, kas ir tūkstošiem terabaitu. Un pat līdz galējam gadījumam, kā minēja ārsts Robins Bloors, ka daži specifiski lietošanas gadījumi - aviosabiedrības, it īpaši valdības aģentūras - var nokļūt exabytes. Viņi joprojām ir diezgan niši-y, taču simtiem terabaitu un pat desmitiem petabaitu vairs nav nekas neparasts, it īpaši sākot ar dotcom uzplaukumu līdz šim brīdim, ko mēs saucam par Web 2.0 uzņēmumiem, piemēram, Facebook, Google, Yahoo un tā tālāk.

Mums ir arī sarežģījumi tagad, kad lietas tiek pārvietotas uz ārējiem dienestiem. Mums ir infrastruktūras platforma un programmatūra kā pakalpojumu pieeja, kas nodrošina infrastruktūru. Īpaši platformas pakalpojumus, kur mēs nevaram iegādāties tikai tādus kā Oracle un viņu mākoņa platformu, datu bāzes un serverus. Tas ļauj mums veikt ļoti ātru lietojumprogrammu attīstību un vienkārši pievienojiet datu bāzi serveriem. Mums nav jādomā par to, kas atrodas zem pārsega. Negatīvie ir tas, ka mēs bieži nedomājam par to, kā mēs veidojam un ieviešam datu bāzi atpakaļ, līdz tā sāk kaitēt un veiktspēja kļūst par problēmu, un tad mums ir jāmeklē pareizais rīks, lai diagnosticētu, kāpēc mūsu datu bāze sāp un kur ir izrādes jautājumi. Un vienmēr tas atgriežas pie kopējās problēmas, kas saistīta ar to, kā mēs esam indeksējuši šos datus un indeksu veidus, kurus mēs esam izmantojuši šiem datiem, un tas mūs atkal ved uz pārcilvēciskām veiktspējas prasībām. Un kāds, kuram ir piekļuve pareizajām sistēmām un pareizajiem rīkiem, lai veiktu veiktspēju, noregulē šos motorus un sāk atrast karsto punktu un meklēt, kur ir vaicājumi, kur dati pārvietojas, vaicājumu veidi, kā vaicājumi ir strukturēti, kas veic vaicājumus un vai vaicājumi tiek ievietoti rindā un ir jāglabā kešatmiņā. Kādu replikāciju jūs meklējat?

Un tā, manuprāt, mēs esam labi un patiesi brīdī, kad pat pasaules labākajiem datu bāzu guriem, galvenokārt mūsu datu bāzu arhitektiem un mūsu datu bāzu administratoram un veiktspējas bāzēm, manuprāt, viņiem ļoti jāsāk piesaistīt pareizos rīkus. lai nodrošinātu optimālu veiktspējas indeksa iestatīšanu jebkuram datu bāzes dzinējam. Tā kā mērogs, ar kuru mēs saskaramies, un ātrums, ar kādu lietas virzās, mēs vienkārši to nevaram izdarīt ar rokām, un, mēģinot to izdarīt vienmēr, var ieviest citas darbības problēmas, jo mums, iespējams, šajā telpā nav pieredzes mēs cenšamies atrisināt problēmu. Un es uzskatu, ka tieši šeit mēs nonāksim pie Berta, un mēs domājam runāt par to, kā viņi ir atrisinājuši šo daudzveidīgo problēmu, un par lietām, kuras viņu rīks var dariet, it īpaši Oracle pasaulei. Un līdz ar to, Bert, es jums došos pāri.

Berts Scalzo: Paldies. Sveicam visus, mans vārds ir Berts Scalzo, es strādāju IDERA. Esmu vecākais produktu menedžeris dažiem mūsu datu bāzes produktiem. Es demonstrēšu dažus no tiem šodien. Bet es gribu runāt par indeksiem, jo ​​es piekrītu visam, ko visi šeit ir teikuši, it īpaši pēdējā slaida, ka indeksi tagad ir tik sarežģīti, ka jums ir nepieciešams rīks, un es ceru jūs pārliecināt. Tātad Oracle indeksa dizains nav tik vienkāršs kā agrāk. Daudzi cilvēki nebūs pārliecināti par sevi, apskatot iespējas, un man patīk šis teiciens, kuru es izcēlu no vēstures: “šajos jautājumos vienīgā pārliecība ir, ka nekas nav drošs.” Un tā es veida jūtieties par indeksiem šajās dienās, jo pat ja jūs domājat, ka zināt atbildi, kas jums jāindeksē X, Y vai Z, jūs patiešām nevarat būt drošs, kamēr to nemēģināt, jo šie optimizētāji dažreiz uzvedas atšķirīgi, kā jūs gaidāt. Un tāpēc indeksa noformēšanā ir daudz izmēģinājumu un kļūdu. Tagad, vecajos labajos laikos, ja jums bija nepieciešams indekss, parasti bija tikai divi jautājumi vai viens jautājums. Vai tā bija unikāla vai nebija? Jūs, iespējams, domājāt par citām lietām, piemēram, “Cik daudz indeksu var būt maksimāli vienā tabulā?”, Jo pārāk daudz indeksu palēnina jūsu ieliktņu, atjauninājumu un dzēšanu. Jūs, iespējams, arī atradāties savā datu bāzes sistēmā, jums bija ierobežojumi attiecībā uz to, cik kolonnas var būt vairāku kolonnu indeksā, jo dažreiz bija ierobežojumi, pamatojoties uz jūsu datu bāzes dzinēja lapas vai bloka lielumu, bet patiesībā tas bija diezgan vienkāršs. vecajos labajos laikos. Vai nu jūs to indeksējāt, vai arī to nedarījāt. Un tiešām, viss bija B kokā. Mēs varētu atļaut dublikātus vai nē, un tas tā bija. Dzīve bija laba, dzīve bija vienkārša.

Mūsdienās dzīve nav tik laba vai tik vienkārša. Es ievietoju sarkano Ghostbuster zīmi tā, kā mēs to darījām, jo ​​tagad mums ir B-koks pret bitu karti, salīdzinot ar bitu karti. Un es paskaidrošu, kādi daži no tiem ir vienā mirklī. Grupēti un ne grupēti, unikāli vai dublikāti, uz priekšu vai apgrieztā secībā, balstīti uz funkcijām, sadalīti vai nesadalīti. Ja ir iesaistīta sadalīšana, vai tā ir globāla vai lokāla? Es to arī paskaidrošu. Un tad tur ir arī kaut kas, ko sauc par indeksētu organizētu tabulu. Un patiesībā ir pusducis citu, ko es esmu atstājis no šejienes, jo es domāju, ka man šeit ir pietiekami daudz laika, lai pārliecinātu jūs, ka indeksi ir daudz stingrāki, nekā jūs varētu domāt. Šajā konkrētajā slaidā es sākšu ar diagrammas augšējo kreiso daļu un esmu ieguvis tabulu. Pirmais, kas man jāizlemj, atkarībā no jūsu datu bāzes versijas un datu bāzes pārdevēja ļauj objekta tabulas vai arī tās ir tikai relācijas? Es dodos lejā pa labo malu un saku, ka mēs veidojam relāciju tabulu. Nākamais jautājums, kas man sev jāuzdod, ir: vai tas ir klasterī? Un daudzi no jums, kas kādu laiku darījuši Oracle, atcerēsies, ka kopas bija atpakaļ Oracle 6 dienas. Mūsdienās viņi, iespējams, vairs nav tik ļoti izmantoti, bet vispirms ļaujiet man nolaist šo zaru.

Ja es gribētu ievietot savu tabulu klasterī, man uz šīs tabulas vajadzētu būt klasterizētam indeksam. Tagad Oracle, apkopojot tabulu, jūs galvenokārt glabājāt rindas vai rindas bija tuvu viena otrai, kur vērtības bija līdzīgas. Tātad jums ir jābūt grupētam indeksam, un šo klasterēto indeksu varētu nesadalīt. Citiem vārdiem sakot, nebija īsti nevienas sadalīšanas metodes, kā jūs darītu grupētu tabulu. Tas bija stingri nesadalīts. Un tāpēc, ka tas nebija sadalīts, tas bija globāls. Es minūtes laikā paskaidrošu, kas ir globāls. Un tas vienmēr bija B-koks. Citiem vārdiem sakot, kad es gāju pa šo filiāli, tas bija diezgan vienkārši, man nebija daudz izvēles. Tagad, ja es klasterizētajā tabulā izdarīju neklasificētu indeksu, kas dažās versijās bija atļauts, atkal tas nebija sadalīts; ja tas nav sadalīts, jūsu vienīgā izvēle ir globāla. Tātad, jums ir izvēle B-koks vai bitkarte. Atkal tas bija atkarīgs no jūsu datu bāzes versijas. Bet tagad atgriezīsimies pie relāciju tabulas un atkal sāksim iet pa labo malu, un tagad mums būs tikai vienkāršs, vecs, parasts, uzpildīts galds: relāciju. Tas notiks galda telpā. Es vispirms došos lejā pa labo malu. Tātad tā ir organizācija, kaudze. Nākamais jautājums, kas man sev jāuzdod, ir: “Vai es vēlos nodalīt šo tabulu, vai ne?” Tagad dažreiz jūs sadalītos, jo domājāt: “Ei, optimizētājs būs gudrāks par to, kā tas var optimizēt vaicājumus. Bet daudz DBA jums pateiks, ka iemesls tam, ka jūs to darāt, ir administratīvos nolūkos. Ja jums ir simts miljardu rindu tabula, ja jūs sadalāt to starpsienās vai segmentos, kad vēlaties pievienot datus pēdējam spainim, varat nomest un indeksēt tikai dažus miljonus rindu. Varat ievietot šos datus un pēc tam atjaunot šo indeksu tikai tajā spainī.

Lai gan tas bija labs paņēmiens dažiem, tādiem optimizācijas paņēmieniem kā nodalījumu likvidēšana, tā patiesā vērtība bija spēja administrēt vai veikt administratīvus uzdevumus mazākiem gabaliem. Dodoties uz organizatorisko kaudzi, pirmais jautājums bija: “Vai es to sadalīju vai nē?” Dosimies pa kreisi, es nedalīšu tabulu. Tagad tas var šķist dīvaini, kad es jums to saku, bet jums varētu būt nesadalīta tabula, un tad jūs nevarat sadalīt indeksu tā, kā jūs esat pieradis, vai arī varat sadalīt indeksu. Apstājies un domā. Jūsu tabulā principā ir viens kauss, kā jūs vienmēr domājāt, un tomēr jūsu indeksam būs vairākas kausi. Kad tas notiek, ja ir neatbilstība starp spaiņu skaitu un tabulu un indeksu spaiņu skaitu, tas ir tas, ko domā globālais. Tātad, ja tabula nav sadalīta un ja indekss ir sadalīts, tas tiek uzskatīts par globālu, jo pastāv neatbilstība. Tagad ļaujiet man atgriezties savas organizācijas kaudzē un nākt uz leju nodalījuma pusē. Tagad, ja man ir nodalījumu tabula un, teiksim, tabulai ir četras spaiņi, četras nodalījumi, manam indeksam varētu būt četras spaiņi, lai mans indekss atbilstu manam tabulas dizainam. Un tā tas ir beidzies, labajā pusē. To uzskatītu par vietējo. Vietējais indekss būtībā nozīmē to, ka tabulas un indeksa sadalīšana tiek veikta vienādi un tai ir vienāds kausu skaits. Un tad, kad man būs vietējais indekss, tas varētu būt B koks vai bitkarte, un šī zaļā bultiņa, kas šāda veida uz augšu, parāda, ka pat tad, ja tas ir B koks, joprojām pastāv izvēles iespējas. Tā varētu būt balstīta uz funkcijām. Un arī, ja tā ir bitkarte, pastāv dažādu veidu bitkartes. Ir kaut kas, ko sauc par bitkartes pievienošanās indeksu. Ja veicat datu glabāšanu, tas ir ļoti populārs zvaigžņu shēmas vai noformējuma indekss. Notiek tas, ka indeksam ir rindu ID tam, uz ko tas norāda tabulā, bet tam būs arī rindu ID vecāku tabulām, lai, kad esat - jums ir jānozīmē zvaigzne shēmas dizains un jūs meklējat faktu tabulā šis indekss faktu tabulā norāda jūs uz datiem, kas jūs interesē, un norāda uz katru jūsu dimensiju rindu, tā ka jums ir jābūt tikai vienam indeksam.

Un patiesībā tas radās sarkano ķieģeļu dēļ, kas bija datu bāze pirms daudziem gadiem - daudzi cilvēki to var atcerēties. Tātad, ja jūs skatāties uz šo attēlu - un paturiet prātā, ka es neievietoju visu šajā attēlā, jo attēls būtu daudz lielāks -, joprojām pastāv papildu problēmas, kas man šeit ir tekstā augšējā labajā stūrī. . Vai tas ir apgrieztas secības indekss? Un jūs varētu teikt: “Kāpēc es gribētu indeksu ar apgrieztu secību? Tam nav nekādas jēgas. ”Ja jūs atrodaties klasterizētā vidē Oracle, ja jūs darāt reālas lietojumprogrammu kopas, ja uzturat savus indeksus kārtībā, tātad neatgriezeniski, ja jums ir daudz apstrādes, kas traucē tās pašas vērtības vai tās pašas indeksa vērtības, kas notiktu, būtu, ja jūsu B kokam būtu karstas vietas. Tas nozīmē, ka jums būs spēja un, iespējams, bloķēšana, lai mēģinātu piekļūt šiem materiāliem, un jūs to darāt visos tīkla mezglos. Nu, ja jūs ievietojat apgrieztas secības indeksu, tagad jūs to varat atsaukt. Jūs varat teikt: “Nu, līdzīgas vērtības ir dažādās koku daļās, tāpēc man nav manu atsevišķo mezglu, kas sacenstos par karstām vietām kokā.” Un tad arī ievērojiet, ka unikāls nedarbojas ar dažām iespējām . Ja paskatās, esmu numurējis trīs, piecus, astoņus un vienpadsmit, tāpēc ir daži gadījumi, kad man nevar būt unikāla indeksa. Tāpat ir daži gadījumi, kad man nevar būt apgrieztā indeksa, un tad rodas papildu problēmas, piemēram, reģistrēšana vai nav reģistrēšanas, kā arī paralēla un ne-paralēla. Es varu lietas iedalīt noteiktā atmiņā.

Un tas joprojām atstāj diezgan daudz Oracle funkciju. Es teiktu, ka, aplūkojot Oracle 12, iespējams, tur atkal ir apmēram pusotra lieta, ko es varētu pievienot šim attēlam. Indeksēšana ir patiešām sarežģīta, un es patiešām piekrītu iepriekšējam runātājam, lai to aplūkotu un izdarītu labu izvēli, jums ir nepieciešams rīks. Varbūt jums ir nepieciešama šāda aina, kā arī kaut kāda metodika, kā izvēlēties lietas, un, cerams, rīks jums palīdzēs nokļūt. Un tad tas būs izmēģinājums un kļūda. Es vienmēr cilvēkiem indeksēšanas laikā saku: “paskaties, pirms lec.” Un tad jūs varat redzēt mazo suni, viņš lec bez skatīšanās, viņš ar haizivi nonāks ūdenī vai puisis gatavojas lēkt ūdenī, un viņš grasās sevi ietekmēt. Jums ir jādomā par indeksēšanu, jo indeksa izveidošana ne vienmēr nozīmē, ka viss uzlabojas. Faktiski indeksa izveidošana var palēnināt lietas gaitu. Un vaicājuma veiktspēja var būt lielāka par lielumu, salīdzinot ar vienu un to pašu. Un minēšu labu piemēru. Ja jūs veidojat zvaigznītes shēmu un dimensiju tabulās vienā gadījumā izmantojat bitkartes indeksus, bet citā gadījumā sakāt: “Es izmantošu B koku indeksus”, jums ir bitkarte salīdzinājumā ar B- koks. Es varu jums pateikt, ka viens risinājums būs lieluma secība vai, iespējams, vairākas lieluma kārtas ātrāk nekā otrs. Bet atcerieties, kas darbojas vienā vidē, piemēram, datu glabāšanas vidē, iespējams, nav laba izvēle OLTP vidē.

Piemēram, ja jūs ņemtu darījumu tabulu un bitu kartes indeksus ievietotu darījumu tabulā, ir dārgi aprēķināt un atiestatīt bitkartes, šīs garās virknes, un tāpēc OLTP tabulā jūs varat tabulu saskarties tik smagi, ka bitkarte indekss var kļūt bojāts un palēnināt jūsu sistēmas darbību, jo tie vienkārši nav paredzēti atjauninājumiem. Tie ir lieliski piemēroti ātrai piekļuvei, bet nav piemēroti atjauninājumiem. Es domāju, ka indekss prasa izmēģinājumus un kļūdas. Patiešām vairs nav zelta likumu - šajā vienādojumā ir pārāk daudz dažādu mainīgo, lai tos zinātu - un galu galā jums nāksies aplūkot izpildi vai izskaidrot plānus datu bāzē, lai redzētu, vai veicat labu atlasi. Dažreiz plāna analīze var būt tikai zinātne pati par sevi. Es šodien to neskatīšu - tā ir cita tēma -, bet neuzņemieties indeksa dizainu par pašsaprotamu. Ir pamatoti iemesli, kāpēc ir visi šie trakie indeksu veidi, kurus es jums parādīju iepriekšējā attēlā un par kuriem runāja iepriekšējais runātājs. Tie netika izveidoti tikai tāpēc, ka tas bija veikls līdzeklis, lai kaut kur pievienotu kontrolsarakstu datu bāzes pārdevējam; ir lietošanas gadījumi vai scenāriji, kad šie indeksi ir svarīgi un tie būtiski mainīs. Tagad es jums parādīšu dažus dažādu veidu indeksu piemērus vienā no mūsu rīkiem. Ļaujiet man vienkārši pacelt savu ekrānu, lai jūs to varētu redzēt. Labi, tāpēc šeit es sēžu iekšā - ļaujiet man samazināt šo lietojumprogrammu. Es sēžu VMware un darbojos ar Windows Server 2012 VM.

Un jūs varat redzēt, ka esmu ieguvis gandrīz ikvienu cilvēkam zināmu rīku. Man kā produktu menedžerim ir jāapzinās sava konkurence, tāpēc tas nav tikai tas, kādi instrumenti man ir, bet tas, ko dara mani konkurenti? Un mums šeit ir šis rīks ar nosaukumu DBArtisan, kuru es jau palaidu, bet es dodos - tāpēc es to vienkārši audzināšu. Un tas, ko jūs varat redzēt, tas ir patiešām jauks rīks, jo tā vietā, lai izmantotu, teiksim uzņēmuma menedžeri Oracle un SQL Management Studio SQL Server un MySQL Workbench MySQL, kā arī divpadsmit citas datu bāzes, kuras mēs atbalstām, labi, ka visas manas datu bāzes ir iebūvētas šajā vienā rīkā. Tur ir DB2, tur ir MySQL, Oracle, Postgres, SQL Server un Sybase, un tas ir - man šajā konkrētajā lietā ir tikai sešas datu bāzes, jo es to nevaru - rīks atbalsta divpadsmit datubāzes, bet mans sliktais VM, vienlaikus darbojas sešas datu bāzes un mēģina veikt demonstrāciju, ir apmēram tikpat, cik mana aparatūra atvieglos. Tāpēc ļaujiet man atgriezties Oracle tagad, un, ja pamanāt, visas šīs lietas ir vienādas. Ja es vēlos izmērīt savu veiktspēju DB2, tas ir tās pašas izvēles, kuras es darītu Oracle. Tagad zem vākiem mēs darām daudz dažādu lietu, tāpēc jums nav jāzina, kas notiek, bet mēs piedāvājam jums saskanīgu saskarni, lai jūs varētu būt eksperts ar vairākām datu bāzu platformām. Un tas ietvertu darbu ar indeksiem, šīs diskusijas tēmu.

Ļaujiet man ienākt šeit un vispirms ļaujiet man aplūkot dažas tabulas, un man ir filmu datu bāze, kurā ir tikai dažas tabulas. Un, ja es skatos uz konkrētu tabulu, piemēram, uz klientu galdu, kad es to šeit audzinu, es redzu tabulas dizainu, šeit ir manas tabulas slejas un šeit ir informācija par katru kolonnu. Man ir tabulas rekvizīti, taču ņemiet vērā, ka man šeit ir cilne indeksiem, un es redzu, ka šeit ir tabulas indeksi. Ievērojiet, ka viens no šiem indeksiem ir mans PK indekss, mana galvenā atslēga. Šie citi izskatās tikai indeksi, lai uzlabotu piekļuvi vaicājumiem, varbūt mēs vaicājam pēc vārda vai uzvārda, vai arī mēs skatāmies uz tālruņiem un pasta indeksiem. Un, ja es šeit izvēlos noteiktu indeksu, piemēram, šo pasta indeksu, un divreiz uz tā noklikšķinu, tagad es redzu, ka, hei, tas ir unikāls indekss, un šeit ir daži citi veidi, bitkarte, unikāls, unikāls, neatkarīgi no tā, vai tas ir sakārtots, neatkarīgi no tā, vai reģistrēšana notiek vai nav, neatkarīgi no tā, vai tā ir apgrieztā secībā, vai tā ir funkciju bāze. Ak, šeit ir jautri, ko es neaptveru. Jums faktiski var būt neredzami indeksi. Un jūs sakāt: “Kāpēc gan es gribētu darīt neredzamu indeksu?” Nu, es jums parādīšu labu piemēru. Jūs esat ražošanas sistēmā, un jums ir problēmas ar veiktspēju, un neesat pārliecināts, ka indeksa izveidošana novērsīs problēmu, tāpēc jūs nevēlaties izveidot indeksu un palēnināt ražošanu, bet kaut kā vai cits, kuru vēlaties jāprot to pārbaudīt. Ražošanas indeksu var izveidot kā neredzamu, kas nozīmē, ka nav daudz lietojumprogrammu kodu, izsaucot pilnveidotāju, kurš izmantos šo indeksu. Tas ir izveidots, tas ir derīgs, bet netiks izmantots. Tad jūs varat veikt vaicājumu, kas, jūsuprāt, varētu palīdzēt ar šo indeksu, vai virkni vaicājumu, un jūs varat pielīmēt mājienu un pateikt: “Hei, optimizētājs, tur ir neredzams indekss, ko es vēlos, lai jūs izmantotu un ļautu es zinu, vai esmu uzlabojis lietas. ”Un tagad es esmu kaut ko testējis ražošanā, bet es neesmu sadalījis ražošanā esošās lietojumprogrammas. Tas ir neredzamā indeksa lietojums. Tas izklausās muļķīgi, kad pirmo reizi par to dzirdat, taču tam ir pielietojums.

Rādītājos mēs varam arī noteikt, vai tie ir paralēli, un arī to, cik gadījumu tie ir paralēli. Tagad neklasterizētā vai nereālā lietojumprogrammu klasteru vidē, tātad bez platformas, paralēlais nozīmētu, cik daudzus apakšprocesus mans vaicājums var parādīt, lai mēģinātu, un strādnieku procesus, lai mēģinātu tikt galā ātrāk vai ātrāk. . Un paralēli gadījumi būtu, ja es esmu reālā lietojumprogrammu klasterī, sakot, ka man ir desmit mezgli, cik no mezgliem man ir atļauts sadalīt darbu pāri? Varbūt tas ir četri no desmit un katrā no tiem četri apakšprocesi. Tas ir piemērs. Un tad mums ir atslēgu saspiešana. Jūs faktiski varat saspiest indeksus? Jā vai nē. Un tad, protams, jums ir savi krātuves parametri, kurus varat norādīt indeksos. Tagad es tos neaptveru, jo tie tiešām ir vairāk atmiņas parametri nekā indeksa problēma. Un tad beidzot mums ir, vai padarīt šos sadalītos vai nesadalītos. Ļaujiet man uz brīdi to nomest. Es iešu pie citas shēmas. Šī ir zvaigžņu shēma, un, piemēram, šī perioda tabula ir dimensiju tabula. Ja esat kādreiz veicis zvaigžņu shēmas noformēšanu, parasti jums ir laika dimensija, tāpēc šajā datu bāzē un šajā zvaigžņu shēmā periods ir laika dimensija. Tagad es zinu, ka tas izskatīsies smieklīgi, sakot: “Dod, paskaties visas šīs kolonnas - vai puisis kādreiz ir dzirdējis par normalizēšanu?” Nu, kad jūs atrodaties datu noliktavā vai zvaigžņu shēmas dizainā, jūs parasti tabulās nav tabulas, kuras parastās personas apskatītu un teiktu: “Džej, tās nav pārāk labi izstrādātas.” Bet tas ir veids, kā jūs to darāt datu glabāšanas vidē.

Tagad skatieties, kas notiks, jo, labi, ir visas šīs slejas, paskatieties, man ir indekss katrā kolonnā. Tagad OLTP vidē, kas būtu nē. Tas palēninātu visas manas operācijas. Datu glabāšanas vidē es tos nomestu partijas ielādes ciklu laikā. Ielādējiet bez pieskaitāmām vērtībām vai indeksiem, un es indeksus atjaunotu. Un, ja es nodalīju savu tabulu, tad tā vietā, lai nomestu indeksu katram tabulas spainim, es varētu vienkārši nomest indeksu uz kausu vai spaiņiem, kur šajā partijas ielādes ciklā bija paredzēts ievadīt datus. Un pēc tam atjaunojiet tikai šo spaiņu indeksa daļu. Un tas padara to ļoti vadāmu. Un, ja es paskatos - tātad šeit ir sleja ar nosaukumu “Brīvdienu karogs”, un būtībā tas ir jā vai nē. Ņemiet vērā, ka tas ir bitkartes indekss, un lielākajai daļai no jums jūs sakāt: “Nu, tam ir jēga.” Jā vai nē, Y vai N, ir tikai divas vērtības, kurām ir jēga. Un tāpēc, ka, lasot bitkartes indeksu dokumentāciju, viņi vienmēr saka, ka jums jāizvēlas kaut kas ar mazu kardinālumu.

Tagad ļaujiet man ieiet vienā no manām faktu tabulām, tāpēc šeit mums ir mani pasūtījumi. Un tas ir mans pasūtījums dienā. Un jūs redzēsit, ka man atkal ir diezgan daudz kolonnu, un man atkal būs vairāk nekā daži indeksi. Un tieši šeit mums ir kaut kas, ko sauc par universālo cenu kodu. Tas bija mazumtirdzniecības veikalam, tāpēc jūs zināt šos mazos svītru kodus, kad kaut ko pērkat veikalā, tas ir universālais cenu kods. Tagad ir miljoniem universālu cenu kodu. Tagad šim konkrētajam uzņēmumam, kurš pārdeva preces, viņiem, iespējams, bija 1, 7 līdz 2 miljoni universālo cenu kodu, tāpēc jūs domājat, ka tas nebūs bitkartes indekss, jo 1, 7 miljoni atšķirīgu vērtību izklausās kā augsta kardinālitāte. Bet patiesībā datu glabāšanas vidē jūs vēlaties, lai tas būtu bitkarte. Tagad ļaujiet man paskaidrot, kāpēc. Šim universālajam cenu kodam var būt 1, 7 miljoni atšķirīgu vērtību, šajā pasūtījumu tabulā rindu skaits ir no simtiem miljonu līdz miljardu rindu. Mans indekss ir zems, salīdzinot ar tabulas lielumu vai kardinalitāti, kardinalitāte. Tas padara to par zemu kardinalitāti. Tas padara bitkartes indeksu noderīgu, kaut arī tas ir pretuzdevīgs ar 1, 7 miljoniem atšķirīgu vērtību, ko šeit izvēlētos bitkarte. Tagad, ja es zinātu, ka vēlos izmantot bitu kartes pievienošanās indeksu, pašlaik produkts to neatbalsta, es to pievienoju nākamajai laidienai, taču tā šeit būtu vēl viena alternatīva. Un, zvaigznīšu shēmā, atcerieties, ka bitkartes indekss būtu uz faktu tabulas un ka viens indekss B kokā norādītu uz rindu faktu tabulā un pēc tam uz katru rindu, kas bija redzama šī fakta dimensiju tabulā. . Un tā, jums tur ir vēl viena iespēja. Un tā, redzēsim, es tagad gribu iznākt no tabulām, un es tikai gribu jums ātri parādīt, ka man ir tāda pati informācija, ar indeksiem, un es darīšu to pašu pamata lietu.

Tagad iemesls, kāpēc es to uzaudzināju, ir tas, ka jūs varat pamanīt, hey, šeit nav primāro atslēgu. Primārās atslēgas tiek veiktas ar taustiņu ierobežojumiem, tāpēc uz tām faktiski attiecas ierobežojuma definīcijas. Tie būtu indeksi, kas nav ierobežojumu sastāvdaļa. Tagad jūs varētu teikt: “Nu, pagaidiet minūti, kas varētu izskatīties kā sveša atslēga, un sveša atslēga ir ierobežojums”, taču svešās atslēgas un vairums datu bāzu automātiski neveido indeksu svešas atslēgas kolonnā, kaut arī tā ir ieteicams, un tur jūs ejat - es atkal esmu izvēlējies visu to pašu izvēli. Un, ja es gribu mainīt tikai tāpēc, lai to saspiestu, es to varu izdarīt.

Tagad saspiešana darbojas tikai ar B-koka indeksu. Tas, ko atļauj, ir, apskatot dažādus B koka mezglus, tas ļauj saspiest dažas vērtības. Tas tiešām nav saspiešana, piemēram, tabulas saspiešana, bet gan tā, kas tiek glabāts B kokā ne-lapu mezglos. Tas netaupa tonnu vietas, bet tas var mainīt. Ar to es pamanīju, ka man ir diezgan tuvu laikam, tāpēc es gribu darīt, es gribu atgriezties un pārtraukt dalīšanos. Un mums ir pieejams mūsu produkts četrpadsmit dienu izmēģinājumam vietnē idera.com. Tas ir diezgan labs produkts, īpaši, ja strādājat ar vairākām datu bāzu platformām. Ja strādājat ar divām vai trim dažādām datu bāzēm, šis rīks ievērojami atvieglos jūsu dzīvi. Mums ir rīki, kas palīdzēs jums indeksa izveidē un atlasē, mums ir rīks ar nosaukumu DB Optimizer. Es to vienkārši šodien nespēju aptvert, tas būtu par daudz. Un, ja vēlaties sazināties ar mani, tur ir mana e-pasta adrese, tā ir, vai jūs varat mani noķert, izmantojot manu privāto e-pastu, un es esmu saņēmis emuārus, man ir vietne un emuāri, kā arī LinkedIn profils. Tāpēc nekautrējieties sazināties ar mani par jebko, pat ja tas nav saistīts ar produktu, ja jūs vienkārši vēlaties sarunāties datu bāzēs, es esmu sirds drosmīgs un es mīlu ķerties pie tehnikas izvēles.

Ēriks Kavanaghs: Labi, labi, Dez, Robin, es esmu pārliecināts, ka katrs esat ieguvis vismaz dažus jautājumus, mums šeit ir palikušas dažas minūtes. Dez, ko tu domā?

Dezs Blanšfīlds: Esmu ieguvis vienu lielisku jautājumu, kas man jums jāuzdod, tas ir sēdējis mana prāta aizmugurē. Kāds trakākais scenārijs tu esi redzējis? Esmu lasījis jūsu emuāru, es jums cieši sekoju, - jūs, iespējams, esat viens no nedaudzajiem cilvēkiem, kas dzīvo gandrīz visos maz ticamajos, un es domāju, ka dr. Robins Bloors ir otrais, ar kuru esmu ticies mans mūžs. Bet, jūs zināt, jūs droši vien esat redzējis katru trako scenāriju, kādi ir daži no trakākajiem scenārijiem, kurus esat redzējuši, ka esat saskārušies, un kā cilvēkiem, kuri vienkārši nespēja tikt galā, jums ir izdevies staigāt un veikt Jedi prāta trikus ar visu šo DBArtisan?

Berts Scalzo: Mums reiz bija klients, kurš savā datu bāzes dizainā ļoti domāja, kā viņi domāja failu izkārtojuma dizainā, un tā, normalizējot datu bāzi, pirmais, ko mēģināt darīt, ir atbrīvoties atkārtotu grupu. Viņiem bija kolonna, un viņi to veidoja par garu, par BLOB vai CLOB, un tajā viņi ievietos vērtību, skaitli viens, semikolu, otro numuru, semikolu, vērtības skaitli, semikolu, un viņiem būs tūkstošiem vērtību tur, bet viņiem vajadzēja meklēt šajā slejā, un viņi ir šādi: “Kāpēc šī lieta rit tik lēni?” Un es esmu tāds: “Nu, jūs nevarat izveidot indeksu tam, ko izdarījāt, tas ir tikai nav atļauts. ”Tātad mēs, izmantojot plānus, mēs viņiem parādījām, ka viņiem vajadzēja šo tabulu normalizēt. Ne tāpēc, ka normalizēšana ir kaut kāds akadēmisks vingrinājums, kas padara lietas labākas, bet tāpēc, ka viņi gribēja vaicājumu šajā laukā, kas nozīmēja, ka viņi gribēja, lai varētu to indeksēt, un jūs to nevarējāt indeksēt atkārtojošā grupā vai vismaz ne tik viegli . Un tā, iespējams, ir vissliktākā lieta, ko jebkad esmu redzējis.

Dezs Blanšfīlds: Jā, ir interesanti, cik bieži jūs sastopaties, es domāju, ka izaicinājums ir ar datu bāzēm, cilvēki aizmirst, ka tā ir zinātne. Un tur ir cilvēki, kas visā grāmatā veic grādus un doktora grādus, raksta tajā dokumentus, un jūs esat uzrakstījis veselu laupījumu, ieskaitot savas TOAD rokasgrāmatas un citas lietas no atmiņas. Tendence veidot “lielos datus”, citējot uz citātiem - es redzu, ka daudzi cilvēki, ja vēlaties, aizmirst par datu bāzu arhitektūras un datu bāzes tehnoloģijas, datu bāzes zinātnes pamatiem. Ko jūs redzat laukā, pārejot no tradicionālajām datu bāzu platformām un tradicionālās datubāzes domāšanas, ka mēs efektīvi darbojāmies pie zemes, un tas bija tikai veiktspējas iestatīšanas un mērogošanas gadījums. Vai jūs redzat, ka daudzi cilvēki no jauna mācās un ir pieredze, kad viņi vienkārši tur sēž un viņiem ir “ha-ha” brīdis, piemēram, “eureka” brīdis, kur viņi saprot, ka šie lielo datu faili patiesībā ir tikai sava veida patiešām lielas datu bāzes? Vai tā ir lieta, kas atrodas tur, un cilvēki uz jums atbild: "Mēs aizmirsām, ko zinājām, un vai jūs varat mūs atgriezt no tumšās puses?"

Berts Scalzo: Nu, nē, un tas ir briesmīgi, jo ir kaut kā jāatzīst, bet relāciju datu bāzu pārdevēji ir izdzēruši arī šo Kool-Aid. Ja jūs atceraties, es nezinu, pirms apmēram desmit gadiem mēs sākām nestrukturētu datu ievietošanu relāciju datu bāzēs, kas bija savādi, ko darīt, un pēc tam dati, relāciju datu bāzes, tagad pievieno NoSQL tipu. sīkumi. Faktiski Oracle 12, CR2 - es zinu, ka tas vēl nav beidzies - bet, ja skatāties uz beta versiju, ja atrodaties beta programmā, tā atbalsta sharding. Tātad, tagad jums ir relāciju datu bāze, kurai nav pievienota NoSQL sharding koncepcija. Un tā, šķiet, ka “a-ha” brīdis vairāk attiecas uz cilvēkiem no relatīvās puses, kuri dodas “a-ha”. Neviens vairs nekad to nedarīs pareizi, pat ne datu bāzes pārvaldnieki, tāpēc mēs esam jāiet pāri un jāpievienojas tumšajai pusei.

Dezs Blanšfīlds: Pareizi, tāpēc jūs sakāt, ka tiek pārorientēts uz daudziem nekārtīgiem datiem, ja es saprotu pareizi, tāpēc, ka mēs esam ielikti tajā, ko mēs tagad saucam par lielajām datu platformām, kas ir sava veida smieklīgi, jo viņi nav tik vecs, bet vai tas nenozīmē, ka viņi pārorientējas uz to, ko viņi dara ar savu relāciju datu bāzi, lai iegūtu lielāku sprādzienu par viņu naudu?

Berts Scalzo: Nē, parasti, ja viņiem ir vajadzība - tas būtu bijis citāts kā “liela datu veida vajadzība”, viņi secina, ka tā vietā, lai dotos uz otru datu bāzes platformu un kaut ko darītu ārpus - Relāciju veidā, datu bāzu pārdevēji tagad viņiem piešķir tās pašas relāciju datu bāzes nesaistītās metodes, lai veiktu šīs lietas. Es domāju, ka labs piemērs būtu, ja jums ir nestrukturēti dati, piemēram, JSON datu tips vai kāds cits sarežģīts datu tips, kam ir nozīme, kas ir iestrādāts pašos datos, datu bāzes pārdevēji to ne tikai atbalsta, bet arī sniegs jums ACID atbilstība nestrukturētiem datiem. Relāciju datu bāzēs ir iekļauti jaunāki paņēmieni un tehnoloģijas, un tāpēc atkal šķiet, ka “a-ha” drīzāk ir nevis tas, ka “hei, mēs, lietojumprogrammu izstrādātāji, kaut ko esam iemācījušies, un mums tas jāapgūst no jauna”, tas ir “hei, mēs to darām tagad, kā es varu to izdarīt jūsu tradicionāli relāciju datu bāzē un darīt to tāpat kā es šajā datu bāzē šeit? ”Un tas kļūst arvien izplatītāks, un, kā es teicu, paši datu bāzes pārdevēji dod iespēju ka.

Dezs Blanšfīlds: Pareizi, kuri šajā telpā ir tradicionālie aizdomās turamie par rīku DBArtisan? Es paveicu dažus mājas darbus par to, ko jūs nesen uzrakstījāt, un no atmiņas jūs kaut ko uzrakstījāt, es domāju, ka tas bija viens no jūsu emuāriem, par ārkārtas datu bāzu veiktspēju Oracle pasaulē. Es neatceros, kad tas bija, es domāju, ka tas bija kaut kad šogad no atmiņas vai no pagājušā gada beigām jūs būtu uzrakstījis šo lietu. Un man šķita, ka tas ir tradicionāls, parasts aizdomas par tāda veida tēmām, par kuru mēs šodien runājam, kur cilvēki apmeklēs ļoti liela mēroga datu bāzes vidi un meklēs to, ko jūs saucat par ārkārtēju ieguvumu tajā. Kurš ir parastais aizdomās turamais, kurš jūs redzat tur, kurš uzņem DBArtisan un izmanto to labi?

Berts Scalzo: Patiesībā, mums ir daudz klientu, patiesībā šodien es biju kopā ar ļoti lielu valdības aģentūru, kas - un viņiem burtiski, iespējams, ir tuvu 1000 mūsu programmatūras eksemplāru, jo tas ļauj cilvēkiem koncentrēties uz to, ko viņi re dara, nevis kā to darīt. Un tas ir labi, es domāju, ka ikvienam vajadzētu zināt, kā kaut ko darīt, bet produktivitāte kļūst par “ko” izdarītu. Ja bizness man prasa veikt uzdevumu, tas ir viss, kas viņus interesē. Kad es saņēmu atzīmi, lai pateiktu, kad uzdevums tika veikts? Nevis to, kādu paņēmienu vai kādu tehnobabu izmantoju, lai tur nokļūtu. Un tā, mūsu rīks ļauj viņiem koncentrēties uz to, kas ļauj, un viņi var būt daudz produktīvāki, un tā patiešām ir milzīga priekšrocība, un, kā es teicu, dažas datu bāzes piedāvā rīku tieši savai datu bāzes platformai. Mēs to piedāvājam divpadsmit datu bāzes platformām. Man ir tāda pati darbplūsma, viena un tā pati grafiskā lietotāja saskarne, tās pašas navigācijas. Ja jūs zināt, kā lietotājam piešķirt privilēģijas vai kā izveidot tabulu vai izveidot indeksu datu bāzē, varat to darīt visos divpadsmit, jo tas ir tāds pats izskats un darbība, un tā pati darbplūsma. Tam ir milzīga vērtība mūsu klientiem.

Dezs Blanšfīlds: Jā, es domāju, cilvēki vēlas no saviem cilvēkresursiem iegūt daudz lielāku sprādzienu par savu naudu. Un visas dienas, kad ir individuāls speciālists Oracle, Ingres un DB2, vairs nav. Paredzams, ka cilvēki būs visu amatu džeki, tāpēc es domāju, ka šī lieta ir absolūti izglābusi viņu dzīvības.

Tikai viena pēdējā ātrā lieta, pirms es to nodevu dakterim Robinam Blooram. Jūs minējāt, ka četrpadsmit dienas ir pieejama bezmaksas lejupielāde. Ko tas nozīmē - ja es gatavojos rīkoties un es to darīšu, starp citu, es to ievietosim Bloor tehnoloģiju laboratorijā un spinēšu šo lietu piecelties un pats to dabūt - man līdz šodienai nebija iespējas to darīt. Jūs pieminējāt četrpadsmit dienu izmēģinājumu, jūs teicāt, ka izmantojat to ar datora VM, un es pieņemu, ka tas ir klēpjdators. Kādas ir sākuma līmeņa iestatīšanas iespējas, lai kāds varētu nodibināt roku un izmantot četrpadsmit dienu izmēģinājumu, tieši pirms es atgriežos pie Robina pie viņa jautājumiem?

Berts Scalzo: Jebkura Windows vide, tātad Windows 7, virtuālā mašīna ar vienu CPU un četrām atmiņas atmiņām. Mēs neesam īsti trekns vai dārgs rīks. Tagad, ja jūs vēlētos palaist datu bāzes serveri tajā pašā virtuālajā mašīnā tajā pašā Windows, jā, jums vajadzēs pievienot vairāk, bet, ja jūs darbināt savu datu bāzi datu bāzes serverī vai atsevišķā virtuālajā mašīnā, ielādēt un palaist mūsu produktu ir ļoti viegls: viens centrālais procesors, četras atmiņas atmiņas, gandrīz jebkura Windows versija - un mēs atbalstām gan trīsdesmit divas, gan sešdesmit četras bitu instalācijas. Bet jums ir jāinstalē datu bāzes pārdevēja klients. Tātad, ja jūs vēlējāties izveidot savienojumu ar Oracle, jums jāinstalē SQL tīkla klients, jo tas ir tas, kas nepieciešams Oracle, lai jūs varētu sarunāties ar datu bāzi.

Dez Blanchfield: Tas izklausās diezgan vienkārši. Es domāju, ka viena no tām vairāk nekā kaut kas, ko es ceru, ka cilvēki atņems, izņemot izpratni, ka šis rīks izglābs viņu dzīvības, ir tas, ka viņiem vajadzētu aiziet un lejupielādēt to, un spēlēties ar to, ņemot vērā, ka jūs piedāvājat četrpadsmit dienu bezmaksas izmēģinājumu. Tas var darboties viņu pašreizējā klēpjdatorā, neinstalējot neko papildus, jo, ja viņi jau veic datu bāzes administrēšanu, viņi jau strādā ar datu bāzēm, viņi ir ieguvuši visus šos rīkus, un neatkarīgi no tā, vai tas darbojas vietējā virtuālajā mašīnā vai viņu vietējā darbvirsmā, šķiet, ka ir nesāpīgi instalēt un ar to spēlēt. Tāpēc es ļoti iesaku cilvēkiem to darīt.

Robin, es esmu pārliecināts, ka jums ir jautājumi, un Ēriks, jūs, iespējams, esat ieguvis dažus no auditorijas, tāpēc Robin, kā būtu, ja es nodotu jums, un pēc tam atpakaļ pie Ērika?

Robins Bloors: Jā, labi, labi, ka man ir kas sakāms, es domāju, es vienmēr esmu atradis šo zonu aizraujošu, jo tas bija - es sagriezu zobus uz tā. Bet patiesība ir tāda, ka, iespējams, apmēram kopš 1998. gada, 1999. gada, es esmu aizrāvies ar to, uz ko Oracle patiesībā ir spējīgs. Un es zināju, ka Sybase un Microsoft SQL Server, abi šie ir diezgan vienkārši, salīdzinot ar to, ko varēja darīt Oracle. Jūs man likāt smieties, kad jūs domājāt - es aizklāju muti, kad jūs sākāt runāt par ēšanu. Oracle to darīja jau iepriekš. Oracle kādā brīdī iepazīstināja viņus ar ideju par objektu relāciju, tāpēc viņi iepazīstināja ar iespēju Oracle izveidot sava veida objektu apzīmējumus un objektu glabāšanu, un es runāju ar vienu no viņu inženieriem, kaut kas līdzīgs pāris gadus pēc tam, kad viņi to ieviesa, un es jautāju, cik cilvēku to izmanto, un viņš teica, ka, manuprāt, divi klienti to ir izmēģinājuši, un tas arī bija. Un es domāju, ka tas pats notiks, ja viņi sāks mēģināt darīt NoSQL lietas. Jūs zināt, es domāju, ka tā ir kļūda, es domāju, ka mani interesē jūsu domas. Protams, viņi dzer Kool-Aid. Viņi jūtas tā, it kā viņiem būtu jāprot iesniegt pretenzijas, kas ir līdzīgas lielajām NoSQL datu bāzēm, piemēram, Cassandra, bet, vai jūs zināt, vai jums ir kāda jēga?

Berts Scalzo: Nē, jūs esat trāpījis nagam tieši uz galvas. Man šķiet, ka, ja es darīšu relāciju, es izvēlēšos tādu relāciju pārdevēju kā Oracle vai SQL Server, DB2 vai Postgres, bet, ja es darīšu kaut ko, kas nav saistīts ar relāciju, lielajā datu telpā vai NoSQL telpā es izvēlos pareizo darbu pareizajam rīkam. Un es nedomāju, ka tas, protams, vispirms būtu jāgriežas pie mana relāciju datu bāzes pārdevēja. Un tad jūs tam pievienojat otru grumbu, tas ir, kas ir pieejams mākonī? Tik daudz cilvēku vēlas atbrīvot savas datu bāzes no telpas. Tad jums jāpaskatās uz savu mākoņa pakalpojumu sniedzēju un jāsaka: “Labi, ko jūs sniedzat, kādas datu bāzes man ir pieejamas manām vajadzībām un cik tās ir nopērkamas, un atklāti sakot, kāda ir likme vai maksa par šīs datu bāzes izmantošanu mākonī stundā vai dienā. Un par gigabaitu vai terabaitu? ”Un tas, ko jūs atradīsit, varbūt ir dažas no salīdzinoši jaunākajām datu bāzēm, piemēram, Mongo vai Cassandra, varbūt to likmes ir lētākas, tāpēc, ja jūs gatavojaties darīt vairāku petabātu tipa lielos datus, iespējams, - tikai no izmaksu viedokļa - ir jāņem vērā mākonī esošās NoSQL datu bāzes, jo tās var būt visrentablākais veids, kā to izdarīt.

Robins Bloors: Jā, pareizi. Es domāju, ka mana veida lieta - par relāciju datu bāzēm manā pieredzē - kas ir pietiekami ilga, lai būtu rētas, tas noteikti ir - ir daudz veselā saprāta, ka, ja jūs sākat to lietot un - jūs saprotat, kas patiesībā ir relācija, tas Es domāju, ka es atceros, ka kādreiz konsultējos ar vienu klientu, un viņi mani ieveda telpā, un viņi bija izveidojuši sava veida entītiju diagrammu un izveidoja trešo parasto formu - uzņēmuma primāro sistēmu modeli. Tajā bija divi simti četrdesmit galdi, un viņi teica: “Nu, ko jūs par to domājat? Mēs tam izveidosim datu bāzi ”, un es teicu:“ Ko jūs par to domājat? ”Es atbildēju:“ Es nedomāju, ka tas darbosies. ”Un tas ir pilnīgi pareizi, jūs zināt, jo tie beidzās lai izveidotu īpašu struktūru vienpadsmit virzienu savienojumos. Un tā ir lieta, kas jāsaprot par relāciju. Tāpēc mani interesē tas, cik slikts dizains jums rodas. Es domāju, ka man nav nekādu problēmu ar DBArtisan - tas dara ļoti saprātīgas lietas, un tas, ka jūs, manuprāt, faktiski varat izstādīties uz vairākām platformām, ir brīnišķīgi - bet cik daudz jūs sastopaties tur, kur ir dizaina jautājums kur cilvēki būtu varējuši atrisināt visādas sirdssāpes, ja viņi nonāktu pie zvaigžņu shēmas, nevis iegūtu par to sniegpārsliņu, jūs zināt?

Berts Scalzo: Es negribu izklausīties prātīgs vai augstprātīgs, bet es teiktu, ka biežāk. Skaidrs, ka lielākajā daļā datu bāzu, kurās es iesaistos, tām ir problēmas vai problēmas. Kas ir labi, jo mūsu rīki, piemēram, datu bāzes optimizētāja rīks, var palīdzēt viņiem atrisināt šīs problēmas, un, kas man patiešām ir smieklīgi, ir tas, ka daudzas problēmas atkal un atkal ir vienas un tās pašas vienkāršās problēmas. Es tikai dienu strādāju ar klientu, kuram bija vienpadsmit veidu pievienošanās vaicājums, un es esmu tāds: “Labi, kāpēc jūs neizmantojāt ar klauzulu?”, Un viņi ir šādi: “Nu, es "Es nezinu, kas tas ir." Un tad es teicu: "Un paskatieties uz jūsu apakšizvēlēm šeit uz jūsu savstarpēji saistītajām un jūsu savstarpēji nesaistītajām", es teicu: "Dažos gadījumos jums ir, kur klauzula atrodas visdziļākajā līmenī, tabulas atsauces forma no ārpuses. ”Es teicu:“ Tas ir, pārvietojiet to pareizajā līmenī, neiekļaujiet to dziļāk, nekā tam ir jābūt, jūs sajauksit optimizētāju. ”Un ar dažiem pāris pielāgojumiem mēs paņēma kaut ko, kas ilga apmēram divas stundas, un nojauta to līdz desmit minūtēm, un tas bija vienkārši - tādā gadījumā mēs neko nedarījām, kā vien uzlabojām viņu uzrakstīto SQL. Es domāju, ka problēma ir tā, ka liela daļa universitāšu un daudz cilvēku, kuri apgūst programmēšanu neakadēmiskajā vidē, viņi to apgūst kā ierakstīta laika procesus vai procesu, kas orientēts uz rindu, un relāciju veido raksturs, un tāpēc jūs ir jādomā komplektos, lai uzrakstītu labu SQL.

Robins Bloors: Jā, es domāju, ka tas ir pilnīgi pareizi. Un jums ir jāsaprot, ka tās ir lietas, piemēram, cilvēkiem būtu jāzina tādu lietu kā ABC. Tam nav nozīmes. Jūs nevarēsit veikt racionālas lietas, ja neapzināsities, ka pat labi izstrādāta, labi modelēta datu bāze, pievienošanās prasīs laiku, kārtošana prasīs laiku. Viņi to dara tāpēc, ka pasaule nekad nav atradusi veidu, kā panākt, lai tie ātri notiktu. Viņi ir atraduši datu organizēšanas veidus, tāpēc viņi iet ātrāk nekā citādi, un liels entuziasms, kas man jāsaka par NoSQL datu bāzēm, ir vienkārši tas, ka viņi izvairās no pievienošanās. Viņi tikai sāk veidot datu bāzes ar vienādu datu izplatību tajās, jo, ja jūs pievienojaties kādai no NoSQL datu bāzēm, tās vareni sūkā. Nedomājat?

Berts Scalzo: Ak, absolūti. Un man jāsmejas, jo es sāku ceļu atpakaļ pirms relāciju datu bāzēm un atpakaļ, kad Ingres bija RTI, Relāciju tehnoloģiju institūts, un mums nebija SQL, mums bija pirms SQL relāciju valodas. Es domāju, ka Ingresā toreiz to sauca par Kuelu. Tātad jūs ieguvāt no šīm vecajām datu bāzu paradigmām, piemēram, tīkla un augstākas grafiskas vai hierarhiskas, un pēc pāris gadu desmitiem iziet relāciju paradigmas, un tagad man šķiet, ka mēs atkal atgriezīsimies gandrīz hierarhiskā stāvoklī. Tas ir gandrīz kā mēs esam atgriezušies.

Robins Bloors: Jā, pareizi. Labāk nododiet Ērikam, es patērēju pārāk daudz laika, bet vai mums ir kādi jautājumi no auditorijas, Ēriks?

Ēriks Kavanaghs: Mēs darām, mums ir daži. Mēs šeit dodamies ilgi, bet es jums uzmetīšu pāris. Mums bija pāris jautājumu ap neredzamo indeksu. Viens jautājums bija: “Vai kādam ir jāizmanto jūsu rīks, lai tos redzētu?” Cits jautājums bija: “Nu, kas būtu, ja tu esi akls?”

Berts Scalzo: Tas ir labi.

Ēriks Kavanaghs: arī ziņkārīgs jautājums, tāpēc vienkārši FYI.

Berts Scalzo: Nē, jums nav jābūt mūsu rīkiem. Tā ir Oracle funkcija, neredzamo lietu indekss. Datu vārdnīcā Oracle vienkārši glabā metadatus, kas saka: “Optimizētājs, ignorējiet šo indeksu. Tas ir šeit, bet, ja vien jums nav fizisku norādījumu, izmantojot mājienu, optimizētāja mājienu SQL komandā, nelietojiet to. ”Un tā, nē, jums nav jābūt mūsu rīkiem un visādā ziņā ir vienkāršs vecs indekss, jūs to varat redzēt jebkurā rīkā, vienkārši optimizētājs teiks: “Parastā vaicājumu apstrādē mēs to ignorēsim.” Jums tas jāvirza, ja vēlaties, lai tas pierod. Tas ir ļoti noderīgs manis aprakstītajam scenārijam, ja jūs vēlaties izveidot indeksu ražošanā, bet neriskējat salauzt pārskatus vai lietas, kas jau darbojas, bet jūs vēlējāties tos pārbaudīt, jūs to varētu izdarīt. Tam tas ir visnoderīgākais.

Ēriks Kavanaghs: Tas ir labs sīkums, un tad šeit bija vēl viens labs jautājums. “Kā ir ar dažām no šīm jaunajām atmiņu datu bāzēm? Kā atmiņā esošo datu bāzu tehnoloģija maina spēli attiecībā uz indeksēšanu? ”

Berts Scalzo: Zēns, labi, mēs - tagad tas ir labi, es priecājos, ka kāds uzdeva šo jautājumu, mums būs jāiet vēl pusstundu. Nē, atmiņā, tas ir atkarīgs no datu bāzes pārdevēja. Parasti es esmu tā, ka es nerunāju neko, bet tikai slavēju visu, ko dara Oracle, jo tā ir pārsteidzoša viņu uzbūvētā tehnoloģija, bet, kad jūs noplēšaties zem vākiem un skatāties, kāda atmiņā ir Oracle, Oracle datu bāze, kāda tā ir patiesībā, vai tā joprojām tiek turēta rindu krātuvē diskā, un tajā tiks ielādēta kolonnu krātuve atmiņā, un, ja nepietiek atmiņas, lai noturētu visu tabulu, tā atgriezīsies porcijās; tas neiederēsies atmiņā, ja to darīsim rindu veikalā, un tādējādi jūs faktiski varētu veikt atlasi pret galdu un pusei galda jūs izmantojat indeksēšanu, hitting tradicionālās rindas pie galda, bet otra puse atlasiet, ka tas faktiski iziet, un tikai satveriet visu, kas meklēts atmiņā, un tāpēc tas atšķiras ar to, ka, piemēram, SQL Server to ieviesa ar savu Hekaton tehnoloģiju, jūs zināt, un SQL 2014, un tas ir pilnveidots SQL 2016, bet dažos aspektos savējais ir patiesāka atmiņā saglabātā versija, un, taču katrai ieviešanai ir plusi un mīnusi, taču jums ir jāskatās zem vākiem un jāsaprot. Tāpēc, ka man bija kāds klients, kurš teica: “Ak, šī tabula ir atmiņā - es tikai gatavošos sastādīt visus indeksus”, un es esmu tāds: “Tabula ir lielāka par atmiņu, kāda jums ir uz servera, tāpēc kādā brīdī dažiem vaicājumiem ir jāatsit disks. ”

Ēriks Kavanaghs: Tas ir labs apraksts; tas ir labs sīkums. Labi, ļaudīm, mēs šo pārējo gada laikā kopā ar šiem puišiem rīkosim vēl dažas tīmekļa pārraides. Atgriezieties jebkurā laikā, kad dzirdat par Berta piedalīšanos prezentācijā, jo mēs zinām, ka viņš zina savas lietas. Vienmēr ir jautri sarunāties ar ekspertiem. Mēs visas šīs tīmekļa pārraides arhivējam, lai vēlāk varētu skatīties. Šeit atkal ir Berta kontaktinformācija, un mēs centīsimies izgūt šo saiti lejupielādei un nosūtīt to arī pa e-pastu, taču jūs vienmēr varat pa e-pastu sūtīt patiesu e-pastu: mums ir vēl virkne tīmekļa pārraidījumu gadā, un mēs šobrīd darām ed cal, tāpēc, ļaudīm, ja ir kādas tēmas, kuras jūs patiešām vēlaties dzirdēt par nākamo gadu, nekautrējieties: Esiet piesardzīgi, ļaudis, mēs ar jums sarunāsimies nākamreiz. Labdien!

Techopedia satura partneris

Techopedia darbinieki ir saistīti ar Bloor Group, un ar viņiem var sazināties, izmantojot labās puses iespējas. Lai uzzinātu vairāk par to, kā mēs strādājam ar nozares partneriem, noklikšķiniet šeit.

• Profils
• Vietne