Pagkabigo ng index: kung paano maiwasan ang kaguluhan sa database

Sa pamamagitan ng Techopedia Staff, Oktubre 5, 2016

Takeaway: Tinatalakay ng Host na si Eric Kavanagh ang pag-index ng database kasama si Dr. Robin Bloor, Dez Blanchfield at ang Bert Scalzo ng IDERA.

Kasalukuyan kang hindi naka-log in. Mangyaring mag-log in o mag-sign up upang makita ang video.

Kasosyo sa Nilalaman ng Techopedia

Ang Staff ng Techopedia ay kaakibat ng Bloor Group at maaaring makipag-ugnay gamit ang mga pagpipilian sa kanan. Para sa impormasyon kung paano kami nakikipagtulungan sa mga kasosyo sa industriya mag-click dito.

• Profile
• Website

Eric Kavanagh: Mga kababaihan at mga ginoo, kumusta, at maligayang pagdating muli. Ito ay isang Miyerkules, sa alas-otso ng Silangan, at ang mga alam mo ang programa, alam kung ano ang ibig sabihin nito, oras na para sa isa pang yugto ng Hot Technologies. Oo, naman. Ang pangalan ko ay Eric Kavanagh, ako ang magiging moderator mo para sa sesyon ngayon: "Index Insanity: Paano Maiiwasan ang Pagkagulo sa Database." O habang tinutukoy ko ito sa huling pagsabog ng email na lumabas, "database wrangling." Mainit na term sa mga araw na ito, "nakakagulo." Lahat ng ito ay gumagawa nito. Mayroong slide tungkol sa iyo ng tunay. At sapat na tungkol sa akin.

Kaya, ang serye ng Hot Technology ay talagang idinisenyo upang tukuyin ang isang partikular na espasyo, kumpara sa Briefing Room na kung saan ay isa-isa lamang na live na analyst na pagsusuri, para sa Hot Tech nakakakuha kami ng dalawang analyst. Ngayon, ito ay magiging aming sariling Doctor Robin Bloor at aming scientist ng data na si Dez Blanchfield. At pinag-uusapan namin ang tungkol sa isang paksa na sa palagay ko ay talagang napakatanga ng nangyayari sa palengke ngayon.

Ang nasa ilalim na linya ay nasa mundo tayo ng pagiging kumplikado sa mga araw na ito. Talagang, kung sa tingin mo bumalik labinlimang taon, o dalawampung taon, ito ay isang iba't ibang iba't ibang mundo pabalik noon, lalo na tungkol sa teknolohiya ng database. Ang mga database na ginamit ay medyo simple. May ilan lamang sa kanila; ang karamihan sa kanila ay relational. Ngayon, mayroon kaming buong panoply ng mga teknolohiya sa database. Literal na mga marka ng mga pagpipilian sa talahanayan para sa sinumang nais na bumuo ng isang application o gumawa ng isang bagay gamit ang data. Nagbabago ang lahat at nakakaapekto sa mga taong sumusubok na pamahalaan ang mga sistemang ito. Pag-uusapan natin ngayon si Bert Scalzo, na isang tunay na dalubhasa sa larangan; siya ang pamamahala ng senior product para sa IDERA, tungkol sa kung ano ang maaari mong gawin upang makakuha ng isang hawakan sa lahat ng data na iyon. Gamit ang, ihahatid ko ito kay Doctor Robin Bloor upang kunin ito. Robin, ang sahig ay iyo.

Robin Bloor: Okay, salamat sa pagpapakilala na iyon. Sa palagay ko - dahil sa isang bagay na may dalawang kamay, sa palagay ko ay pag-uusapan ko lang ang tungkol sa pag-optimize ng database sa pangkalahatan bilang isang pagpapakilala sa ito ng Hot Tech na palabas. Sinimulan ko ang buhay - sa teknolohiya at pagsusuri - Sinimulan ko ang buhay na gawin ito dahil dati kong sumulat ng mga artikulo sa mga kakayahan ng mga database sa platform ng DEC VAX. At sa kadahilanang iyon, ginamit ng mga tagastos ng database upang maikli ako. At ang bagay na nangyayari sa akin ay iyon, bakit magkakaroon ka ng isang database? Ibig kong sabihin, sa mga panahong iyon isang kakila-kilabot na mga tao na ginamit upang lumikha ng mga key file na halaga at gamitin ang mga magkakaroon ng isang uri ng sunud-sunod na pagkakasunod ng index tulad ng pagtawag namin sa kanila, ngunit upang lumikha ng isang uri ng kakayahan sa database, at alam mo, kung bakit magkakaroon ka ano pa?

At ang sagot na iyon, sa palagay ko ay ibinigay ni Michael Stonebraker ang pinakamahusay na sagot sa iyon, at sinabi niya, "Ang isang database ay maaaring malaman ang higit pa tungkol sa kung saan ang data at kung gaano kabilis makuha ito, kaysa sa anumang programa na maaaring malaman." At sa palagay ko kawili-wili iyon; ito ang likas na katangian ng laro. Ngunit sa ika-19 - mabuti noong 1989 na nagsimula ako sa pagsusuri ng teknolohiya at alam mo, sa puntong iyon sa oras, ang mga database ay napaka-simple at ang mga pamalarang database ay sobrang simple. Sila ay may kaunting kakayahan, ibig kong sabihin, maaari silang mag-imbak ng data, malinaw naman, at maaari mong i-back up at mayroon sila, sumusunod sila sa ACID, ngunit talagang may mahina silang mga optimizer. Sa katunayan, mahirap magtaltalan na sila ay may kakayahang pang-optimizer.

At sa paglaon ay nakakuha lamang sila ng mas mahusay at mas mahusay, ngunit, alam mo, kapag ang isang database ay hindi gumana - dahil ang mga kangaroos na ito ay tila sa isang paraan o ibang nagpapahiwatig - maaaring magkaroon ng isang kakila-kilabot na mga kadahilanan kung bakit ito ay mabagal. At iyon ang nagdudulot sa akin: Ang mga database ay maraming mga pag-andar, ngunit ang pinakamahalaga ay ang pag-optimize ng query. Kung hindi nila ito ginawa, hindi mo ito gagamitin. Ito ay tungkol sa pagkuha ng impormasyon nang mabilis, tungkol sa magagawa ito kapag mayroong maraming mga kasabay na mga gumagamit, at iyon ay isang mahirap na problema. At kapag tinitingnan mo ang, tingnan natin ang mga ito na mga database ng database, kung gusto mo - ngunit tiyak na Oracle, sa isang bahagyang mas mababang sukat, ang Microsoft SQL Server, tiyak na Teradata at DB2 - ang mga optimizer ng mga database na nakuha, ay mga dekada sa gusali. Alam mo, hindi nila - isang tao ay hindi nakaupo - anim na lalaki sa isang dalawang-taong, taon, proyekto at magkatok lang. Hindi ito gagana. Ang kakayahang pag-optimize ay unti-unting lumago, at nangangailangan ng maraming lumalagong. Pa rin, pag-usapan natin ang tungkol sa background sa database. Sa totoo lang, mayroong isang kakila-kilabot na sinabi tungkol sa NoSQL database ngayon, at mayroong maraming sigasig para sa mga database database. At ang paggamit ng SQL sa Hadoop at mga bagay na katulad nito. Ngunit, ang katotohanan ng bagay ay kung nais mo ang isang database ngayon, kung nais mo ang isang ganap na pagganap, may kakayahang OLTP at malaking query sa trapiko, ito ay isang pamanggit na database, o wala ito.

Sa gitna ng mga database ng relational, ang Oracle ay nangingibabaw sa katanyagan. Sa tingin ko, ang Microsoft SQL Server, ay pangalawa. Pareho silang may kakayahang magamit para sa OLTP at workload ng query, ngunit talagang hindi ka maaaring lumayo sa paghahalo ng mga workload na iyon. Kailangan mo ng iba't ibang mga insidente para sa mga OLTP na mga workload at mga query sa trabaho. Mayroong mga kahalili sa SQL at graph. Karamihan sa mga kumpanya ay nag-standardize sa isang tukoy na database, na ang dahilan kung bakit - Ibig kong sabihin pagkatapos ng mga dekada na labanan ito kasama ang lahat ng iba pang mga manlalaro, si Oracle ang naging pinakapangunahing. Dahil lamang natapos nila na maaaring magbenta ng mga lisensya sa korporasyon, at sa gayon ang mga kumpanya ay gagamit lamang ng mga alternatibong produkto sa mga pambihirang produkto na hindi lang ito gagawin ng Oracle. At ang mga database ay madiskarteng nasa evolve din sila. At alam mong gumawa ako ng kaunting pananaliksik para sa presentasyong ito, at ito ay uri ng - darating ako sa loob ng ilang sandali, ngunit ito ay uri ng kawili-wiling kung paano sila umusbong, sa mga tuntunin ng pagtingin dito mula sa posisyon ng DBA. Ito ang tinatawag ko na hindi nakikita na takbo. Ito ay batas ng Moore. Ito ay halos ganito: Ang pinakamalaking database ay, at mga bagong database, walang isang lumang database na nakakakuha ng mas maraming data sa ingest. Karaniwan itong isang database na inilalapat sa isang bagong problema. At talagang lumalaki sila sa mga tuntunin ng dami ng data. Matindi sa kubo ng Moore's batas. Kaya ang batas ni Moore ay isang kadahilanan ng sampung beses bawat anim na taon. Ang mga VLDB ay may posibilidad na mapalago ang isang kadahilanan ng isang libong bawat anim na taon. Noong 1991, 1992, ang mga malalaking database ay sinusukat sa mga tuntunin ng mga megabytes. Sa '97 at '98, gigabytes. 2003, '4, terabytes. 2009, '10, nagsimula kang makakita ng mga database ng petabyte. Sa palagay ko marahil ay mayroong isa o dalawang mga database ng exabyte na naroroon ngayon, ngunit ang pinakamalaking narinig ko ay ang 200 petabytes sa oras, at alam mo, hindi nakakakuha ng data sa isang database ng petabyte. Ngunit, ito ay karamihan sa mga iyon ay malinaw naman na ang bagong malaking mga kumpanya ng web 2.0, marahil, nakuha mo ang Facebook sa heading na iyon.

Ngunit gayon pa man, kung titingnan mo talaga iyon, umaasa ang isang database na dumaan sa ganoong uri ng pagtaas sa dami, marami itong hinihiling. At kamangha-mangha, tiyak na hanggang sa antas ng petabyte, tila maayos na nagawa nila. Ibig kong sabihin, pinag-uusapan ko ang mga matatandang produkto kaysa sa bago. Tila nagawa nilang magawa nang maayos. Kung titingnan namin ang pagganap ng database, mga bottlenecks, dadalhin ako nito sa oras na aktwal kong nag-aalaga sa kanila, at kailangang mag-alala tungkol sa kanila. Alam mo na ito ay panimula ang pagkasira ng hardware. Mayroong mga bottlenecks ng CPU, marahil, may mga bottlenecks ng memorya, marahil, may mga disk bottlenecks, marahil. Maaari itong maging network na nagdudulot sa iyo ng kalungkutan, at maaari ka ring makakuha ng mga problema sa pag-lock, depende sa iyong ginagawa, ngunit normal na dahil hindi alam ng programa kung sino ang tatawag sa lock. Kaya, kung pupunta ka ng isang database, talagang sinusubukan mong i-tune ito upang sumayaw sa pagitan ng limang posibleng mga bottlenecks pati na rin ang magagawa nito. At hindi iyon madaling bagay, dahil ang dami ng memorya na maaari mong mai-configure sa anumang naibigay na server ay nadagdagan nang husto. Pagkatapos ay ang mga CPU ay naging multicore, disk, na maaari nating gawin ngayon, sa palagay ko, kahit sa mga server ng kalakal, sa palagay ko makakagawa ka ng daan-daang at daan-daang terabytes, quarter ng petabyte, marahil, kahit sa isang server ng kalakal. Kaya, sa lahat ng mga bagay na ito, maaari kang maglaro, siyempre ang network ay maaaring pumunta sa iba't ibang bilis, ngunit kadalasan kapag nakikipag-usap ka sa mga database, gusto mo talagang magkaroon ng mga cable cable sa pagitan ng mga server at walang ibang tumatakbo sa, partikular doon.

Mga kadahilanan sa pagganap ng database. Ibig kong sabihin, aalis na ako kung ano ang mangyayari, dahil alam kong pag-uusapan ito ni Dez, ngunit ang masamang disenyo ng database ay nangangahulugang isang hindi magandang pagganap ng database. Ang masamang disenyo ng programming ay maaaring nangangahulugang ihagis ang napaka-hangal na SQL sa isang database, na tatagal lamang ng mas matagal. Ang pagkumpirma at paghahalo ng workload, sobrang pagkakasundo ay magiging sanhi ng mga problema sa bottlenecking. Ang paghahalo ng workload, kapag nakakuha ka ng malalaking query na may napakaliit, maikli, matalim na mga query, na nagiging sanhi ng mga problema. Mayroong isyu sa pagbabalanse ng pagkarga. Karamihan sa mga database ay nag-aalaga sa na, ngunit kung hindi ka pa nakakakuha ng isang sopistikadong produkto, pagkatapos ay alam mo, pagdaragdag lamang ng ilang mga server, hindi ba ang gagawin mo kung talagang nais mong dagdagan ang laki ng isang kumpol. Kailangan mong balansehin ang pag-load bago mo makuha ang pinakamabuting kalagayan na pagganap. Kailangan mong gawin ang pagpaplano ng kapasidad. Ganap. Lalo na ngayon sa mga araw na ito tulad ng kapag ang dami ng data ay nagdaragdag ng higit na kapansin-pansing kaysa sa dati nila para sa mga database. At mayroong buong mga isyu sa layer ng data sa kung paano mo nai-ingest ang data, kung paano mo ilipat ang data. Ang hindi pagkuha ng data sa isang database sa oras ay maaaring maging isang isyu sa pagganap sa paglaon dahil nawala kami mula sa mga database na nagtatrabaho sa Windows, sa dalawampu't apat sa pamamagitan ng pito sa pamamagitan ng tatlong daan at pitumpu't limang operasyon at walang mga bintana kung saan maaari mong mabagal ang database down o malamang na hindi magkakaroon ngayon.

Ang problema sa Oracle DBA. Ito ang naiisip ko. Nakarating ako sa Oracle ng DBA kasama ang Oracle 7, at naalala ko kung paano i-tune iyon. At kung talagang tinitingnan mo ngayon ang Oracle, ito ay paraan, paraan - nakuha ito, paraan ng higit pang kakayahan. Mayroon itong pag-index ng bitmap at mga bagay na ganyan, ngunit talagang naglaan ako ng oras upang tumingin at makita kung gaano karaming mga pag-tune ng mga parameter doon ay talagang nasa isang Oracle database sa ngayon. At mayroong higit sa tatlong daan at limampung mga parameter ng pag-tune at mayroong isang karagdagang isang daang nakatagong mga parameter, na maaaring malaman tungkol sa mga espesyalista na DBA, ngunit ang mga normal na Oracle DBA ay hindi alam tungkol sa. At nangangahulugan ito na ang pag-tune ng ganitong uri ng database ay isang matigas na bagay. Ito ay hindi isang simpleng bagay. Kailangan mong magkaroon ng pakiramdam para dito, kailangan mong gawin ito nang mahabang panahon, at alam mo nang eksakto kung ano ang problema sa palagay mo na malulutas, dahil ang pag-tune ay nagsisimula kapag ang nagiging mahina ang pagganap, ngunit maaaring hindi ito ang pagganap ng lahat. Maaaring ang pagganap ng mga tukoy na query na mahalaga, at maaari mong ayusin ito sa pamamagitan ng pag-pin ng ilang data at memorya, o maaaring kailanganin mong ayusin ito sa pamamagitan ng pag-index, o maaaring kailanganin mong simulan ang paggawa ng pagkahati sa ibang paraan. Mayroong maraming mga bagay na maaari mong gawin, ay ang punto. Kaya, dahil dito, hindi nila ito gagawin sa kanilang mga ulo - Ang mga DBA ay nangangailangan ng mga tool. Ipapasa ko ngayon kay Dez na sasabihin sa iyo tungkol sa pag-index, sa palagay ko.

Eric Kavanagh: Alright Dez, ilayo mo na.

Dez Blanchfield: Salamat, Robin, at gustung-gusto ko ang takip na pahina. Sa palagay ko ay itinapon mo ang gauntlet doon para sa akin ay darating kahit na malapit na malapit sa isang bagay na kapana-panabik. Ngunit ginamit ko ang isang imahe ng aming maliit na kalawakan, tulad ng aking pagtingin sa kung ano ang hamon ngayon para sa mga tagapangasiwa ng database ay naging, sapagkat ito ang imaheng kaisipan na may posibilidad kong kumita kapag nakapasok ako sa isang kapaligiran at wala na ako sa mundo ng pamamahala ng mga database o pagdidisenyo ng mga database sa antas na iyon. Ngunit, tulad ng iyong sarili, si Robin at ako ay nagkaroon ng maraming taon na kasangkot sa mundo ng mga database, alinman bilang tagapangasiwa o developer, o kalaunan na arkitekto, at pagkatapos ay napagtanto na makakagawa ako ng mas mahusay na mga bagay upang kumita ng isang crust. Ngunit ito ay malamang na pakiramdam tulad ng tinititigan mo ang kalawakan ng data na ito, at higit pa sa ngayon, kapag umalis kami, tulad ng iyong nabalangkas, nawala kami mula sa mga megabytes sa mga petabytes at exo-scale sa isang napakaikling panahon, sa engrandeng pamamaraan ng mga bagay. Ngunit ang parirala na nasa isip ko ay, na ang mga index index ay ngayon isang itim na sining at hindi talaga sila ang uri ng mga bagay na dapat gawin ng mga mortals lamang, para sa mga aplikasyon ng negosyo na may negosyo at ang uri ng bumubuo sa iyo pinag-uusapan lang. Ngunit, nais kong dumaan sa isang mabilis na rundown ng uri ng kasaysayan na mayroon ako sa mga mundo ng database at dalhin sa konteksto kung saan tayo gagawa ng konklusyon, at pagkatapos ay magpatakbo ng ilang materyal ngayon kasama ang aming mga kaibigan sa IDERA, dahil sa palagay ko maraming iba't ibang pag-iisip tungkol sa kung paano makakuha ng pag-tune ng pagganap sa database at ang isa sa kanila ay ibinabato ang lata sa bagay na ito. Para sa maraming mga tindahan na napagtagumpayan ko, hindi nila nakukuha ang punto ng paggawa ng pag-tune ng pagganap sa layer ng database at lalo na ang index layer hanggang sa makarating sila sa mahirap na ruta ng pag-iisip na maaari silang magtapon ng isang tuner dito .

Ang isang pulutong ng mga tao ay kumuha lamang ng isang malaking diskarte sa bakal dito, sa aking isip, at nakuha ko ang isang larawan ng The Flash dito dahil kung napanood mo ang anumang mga lumang pelikula o tiyak na ang pinakabagong palabas sa TV sa The Flash, tulad ng sa Si Flash Gordon ang dating character, at ngayon na tinawag siyang "Ang Flash, " ay may posibilidad na siya ay napunta, napakabilis at walang kabuluhan ang kanyang enerhiya. At ito ang nangyayari kapag inihagis mo ang malaking bakal sa pagganap ng database. Hindi kapani-paniwala, sa aking karanasan, maaari kang maglagay ng mataas na pagganap, masipag sa laro, maaari mong mai-optimize ang iyong mga operating system at i-tune ang mga ito sa isang tiyak na punto. Maaari mong matiyak na nakakuha ka ng mabilis na multicore, multithreading na mga CPU upang mas mabilis na tumakbo ang application, maaari kang magtapon ng maraming RAM dito, maaari kang magkaroon ng mga high-throughput backplanes, maaari kang pumunta mula sa mga hard drive hanggang sa caching hard drive sa solidong estado, at mataas na pagganap na imbakan ng pag-iimbak. At kahit ngayon, ang mga tao ay nagtatapon ng mga bagay tulad ng flash at NVMe sa kanilang mga database ng engine, na iniisip na kukuha sila ng beses sa pag-login na ito ng dalawang nakakuha ng pagganap. At madalas na nakakakuha sila ng ilang pakinabang. Ngunit, ang lahat ay bumalik sa parehong mga pangunahing problema sa pag-tune ng pagganap. Maraming mga koneksyon sa mababang latency ng network, upang ang mga kumpol ay gumana nang mabilis. At ng mga istruktura ng database ng kumpol, kaya't mayroon kang higit sa isang makina na ginagawa ang lahat ng gawain. Ngunit malamang na bumalik ka sa parehong pangunahing problema sa pagganap, at iyon ang pagbabasa ng data. Ang pagsulat ng data, ay para sa karamihan, isang medyo linear na hamon at maliban kung ito ay maayos na ginagawa.

At pagkatapos ay mayroon kaming hamon sa mundo ngayon: Hindi lahat ng mga database ay nilikha pantay. Mayroong mga database at quote-on-quote na "database." At kapag iniisip namin ang tungkol sa mga makina ng database, ang mga tao ay madalas na iniisip ang tungkol sa tradisyonal, karaniwang mga hinihinalang nasa kanilang SQL mundo. Alam mo, nakuha namin ang Oracle, at Microsoft SQL Server, at mayroong isang pares sa paligid nito sa bukas na mapagkukunan ng mundo kasama ang MySQL, na ngayon ay pag-aari ng Oracle, ngunit bukas pa rin ang mapagkukunan nito. At pagkatapos ay nakuha namin ang hindi karaniwang-hinihinalang mga suspek, ang mga makina ng NoSQL, na mayroon pa ring isyu sa paligid ng pag-index at pamamahala ng pagganap, at hindi ako pupunta sa kanila nang maraming detalye, ngunit mayroong isang pagtaas ng bilang ng mga ito ang mga bagay na tumatakbo araw-araw at sila ay tumingin at pakiramdam tulad ng mga makina ng database mula sa punto ng view ng mga developer at mula sa isang punto ng pagganap, ngunit sila ay napaka-iba't ibang mga hayop at mayroon silang sariling maliit na angkop na lugar sa mundo upang mag-ukit ng alinman sa pagganap ng memorya o linear scale sa disk. Ngunit ito ang hitsura ng mundo sa mundo ng database. Ito ang 2016, ito ang bersyon ng tatlo ng mapa ng, sa pamamagitan ng isang hanay ng mga tao na gumagawa ng patuloy na mapa ng landscape ng kung ano ang hitsura ng mga database, at ito ay kung saan ito - hindi kahit na isang superhuman database architect o database administrator ay maaaring magkaroon ng kahulugan ng ito. Sa literal na daan-daang, at daan-daang, at daan-daang iba't ibang gumagawa, mga modelo, tagagawa ng mga database, palagiang sumusunod sa SQL. At ang nakawiwiling bagay ay, lahat sila ay bumalik sa parehong hamon. Pag-tune ng pagganap at pagganap sa paligid ng database ng database, at lalo na sa kung paano na-index ang data.

Kaya't mabilis na takpan ang pag-index ng database, dahil ito ay isang kawili-wiling paksa, at kailangan mong makapasok nang mas detalyado sa demo, naniniwala ako. Ngunit, sa palagay ko ay tinatanggap na rin ito at pamantayan sa kasanayan sa industriya na ang pag-tune ng pagganap ng index ng index ay kung saan nagsisimula at nagtatapos ang mundo hanggang sa pagtiyak na ma-access ang iyong data sa isang mabilis at mabilis na format. Ngunit ano ang database index? Kung iisipin natin ang tungkol sa pag-index sa form na ginagamit natin bilang pang-araw-araw na tao, mag-isip ng isang pahina ng index sa isang libro. Kung nais mong maghanap ng isang bagay sa isang libro - lalo na ang mga gusto ng isang encyclopedia, o isang bagay tulad ng isang sanggunian na materyal ng ilang form - kung naghahanap ka ng isang bagay tulad ng pahinang ito, kung saan naghahanap ako ng mga bagay tulad ng paksa ng mga dam sa isang encyclopedia. Nais kong hanapin ang bawat sanggunian sa mga dam, ang pagkuha ng tubig at isang malaking lugar ng buildup, na gawa ng tao sa pangkalahatan. Babalik ako sa likuran, makikita ko ito sa isang alpabetong, pinagsunod-sunod na listahan, A hanggang Z, pakaliwa sa kanan, at makikita ko si D. Makikita ko ang salitang "mga dam" at nakikita ko na sa mga pahina 16, 38, 41 mayroong isang sanggunian sa kanila, at pagkatapos ay makakapunta ako sa mga pahinang iyon, maaari kong i-scan ang aking mga mata at makikita ko ang sanggunian sa salitang "dam." Ito ay mahalagang kaparehong konsepto sa isang database, ngunit ngayon ay isang agham na rocket sa maraming paraan. Sa gayon, na epektibo ang bawat tagapangasiwa ng database na alam ko nang mabuti, isinasaalang-alang ang mga index na maging ang pinaka-kritikal na tool para sa pagganap sa pag-tune sa anumang database ng mundo, anuman ang kung ano ang kanilang karanasan ay maaaring maging tulad ng pagkahagis ng lata dito, o kahit anong kaso.

Karaniwan kapag pinag-uusapan natin ang tungkol sa pag-index ng database, mayroong isang bilang ng mga karaniwang pamamaraan. At ang mas kumplikadong mga index ng database ay nagiging, mas kumplikado ang diskarte sa pag-index ng data. Ngunit mahalagang kapag iniisip mo ang tungkol sa data ng pag-index - isipin na mayroon kaming isang file na nakuha ang isang listahan ng mga pangalan; hindi sila maaaring pinagsunod-sunod sa pagkakasunud-sunod ng alpabeto. Isipin natin na may dalawampu sa kanila. Kung susuriin namin - kung maghanap kami ng data sa listahan na iyon, mula sa itaas hanggang sa ibaba, at sabihin nating isang listahan ng mga pangalan. Kung pumili ako ng isang random na pangalan at nagsisimula akong mag-scroll down na lista, mula sa itaas hanggang sa ibaba, sa isang guhit na format at ito ay isang hindi nakakaugnay na listahan, mayroong dalawang pamantayan na naiisip ko bilang aking average na oras ng paghahanap at ang aking maximum na oras ng paghahanap - at Mayroon akong isang typo sa pangalawang linya, dapat na "maximum na oras ng paghahanap, " pasensya - ngunit ang aking average na oras ng paghahanap ay mahalagang N kasama ang isa, na hinati sa dalawa, at iyon ay sa average, aabutin ako ng limampung porsyento ng oras upang i-scan mula sa tuktok ng listahan, hanggang sa ilalim ng listahan upang makahanap ng anumang mga random na bagay sa listahan na iyon. At ang pangalawang linya doon, sa ilalim ng linear, ay dapat na "maximum na oras ng paghahanap." Ngunit ang maximum na oras ng paghahanap ay talaga ang bilang ng mga item, at iyon ay kung mayroon akong listahan ng dalawampung bagay, na ang pinakamaraming oras na magagawa sa akin upang maghanap ng isang bagay sa database na iyon ay upang pumunta mula sa itaas hanggang sa ibaba, na sabihin nating 20 mga item sa pinasimple nitong halimbawa. At ito ay isang napakabagal na proseso at wala talagang paraan sa pagganap ng tono. At pagkatapos, mayroong iba pang mga uri ng mga paraan ng pagkuha ng data na iyon at paglikha ng isang index, na kung saan ay epektibong isang maikling listahan ng mga payo sa kung saan ang aktwal na data ay, tulad ng binary, B-tree, bitmap, hashing, clustered at non-clustered, at pagkatapos ay may iba't ibang uri ng data tulad ng spatial, na-filter, XML at buong teksto.

Binary ay isang napaka-karaniwang ginagamit para sa mga bagay na kung saan ang data ay nagbibigay ng sarili nito. Ang B-tree ay marahil ang nag-iisang pangkaraniwan sa isang pangkalahatang kahulugan, ayon sa kasaysayan, sa pangkaraniwang paraan upang istraktura ang isang index sa anumang anyo ng data at pinapayagan ang mga logger, seleksyon, at mga insertion at mga pagtanggal ay medyo madali habang lumilipat ang mga payo sa paligid ng sanggunian sa mga payo, mga puntos. Mayroong iba pang mga uri, tulad ng bitmap, kung saan ang pag-aalala ng mga uri ng data kung mayroon kaming isang nauugnay na saklaw ng ilang form. Napakahusay na gumagana ang Hashing para sa mga malalaking bagay, lalo na sa mga blog at imahe. At makikita mo na mayroong isang iba't ibang mga uri ng mga pang-agham na pamamaraan, matematika na pamamaraan, sa pag-index ng data. Para sa tao lamang, sila ay isang kagiliw-giliw na hamon na pag-usapan sa antas na ito. Kung pinag-uusapan mo ito sa antas ng pagganap para sa isang tagapangasiwa ng database, talagang nagiging isang scientist na rocket at ginagawa ng mga tao ang mga degree sa kanila, at alam kong tiyak na nagawa iyon ni Doctor Robin Bloor, at nakasulat ng mga libro tungkol dito para sa mga gusto ng IBM at iba pang malalaking tatak sa huling ilang mga dekada. At kung gayon, ang - ang aking pananaw, ay talagang naipasa namin ang isang oras kung saan, alam mo minsan sa isang oras na personal kong makaupo sa harap ng isang sistema at makakaya kong hilahin ito, at ipakita sa iyo eksakto kung saan ang mga isyu sa pagganap ay nasa isang linya ng utos o sa isang tool ng pagsisimula ng interface ng graphic na gumagamit, at simulang suriin ang data at sabihin sa iyo kung saan ang mga isyu, at bumuo ng mga index, o mga sub-index, o pangunahin at pangalawang mga index sa na data at simulang gamitin ito upang maghanap ng mga bagay. Ngunit kapag iniisip mo ang tanawin na iyon ay ipinakita ko sa iyo, kung saan nakakuha kami ng daan-daang at daan-daang mga tatak, gumagawa at modelo, at mga tagagawa at uri ng mga database, maayos at tunay na ang nakaraan namin sa oras na iyon, kung saan makakagawa ang isang tao kahulugan ng mga uri ng mga makina ng database na nakuha namin. Lalo na, kahit na bumalik lamang tayo sa mga kagustuhan ng Oracle, ang pangunahing mga tatak sa mga araw na ito sa mga platform ng relational database.

Ang bilang ng mga database na kailangan nilang harapin alinman sa isang proprietary platform tulad ng isang ERP o HR o sistema ng pinansya, o kung ang mga ito ay isang lutong platform sa bahay para sa iba't ibang mga kadahilanan, ang bilang ng mga database at mga talahanayan ng database at mga talaan na tinatapos namin ang pakikitungo sa mga ito ay pang-astronomya lamang at hindi mo ito magagawa sa pamamagitan ng kamay. At mayroon kaming isang karagdagang komplikasyon ngayon, kung saan minsan, ang isang database server ay maaaring umupo lamang sa ilalim ng iyong desk. Alam mo, bilang isang batang bata pagkatapos ng paaralan, nauna akong nagtungo at magtrabaho sa database ng software sa, orihinal, Apple IIes at pagkatapos ay ang mga system na batay sa DOS PC, tulad ng dBase II, dBase III, ay dumaan sa isang panahon na may mga mainframes at mid- saklaw at kahit ang mga VAX at PDPs at mag-log file sa na. At tulad ng Saber, at pagkatapos ay sa huli kapag ang ilan sa mga database ng SQL ay sumama. Ngunit sa mga araw na ito kapag iniisip namin ang tungkol sa mga makina ng database, mukhang sa ilalim ng kaliwang sulok. Ang isang database server ay hindi lamang isang makina na nakaupo sa sahig sa ilalim ng isang desk; ito ay daan-daang mga makina na nagpapatakbo ng mga kopya ng mga makina ng database, at mga kumpol, at ginagawa nila ang sukat hanggang sa daan-daang at daan-daang mga terabytes ng data, kung hindi mga petabytes ng data, na libu-libong terabytes. At kahit na sa sukdulan, tulad ng nabanggit ni Doctor Robin Bloor, na ang ilang mga tiyak na mga kaso ng paggamit - mga airlines, partikular ang mga ahensya ng gobyerno - ay maaaring makarating sa mga exabytes. Patas pa rin ang mga angkop na lugar, ngunit daan-daang mga terabytes at kahit na dose-dosenang mga petabytes ay hindi pangkaraniwan ngayon, lalo na mula sa dotcom boom hanggang ngayon, uri ng kung ano ang tinatawag namin na mga kumpanya ng web 2.0, ang gusto ng Facebook, Google, Yahoo at iba pa.

Mayroon din kaming komplikasyon ngayon na ang mga bagay ay lumilipat sa panlabas na serbisyo. Mayroon kaming platform platform at software bilang isang diskarte sa serbisyo na nagbibigay ng imprastraktura. At lalo na ang serbisyo sa platform kung saan hindi lamang namin mabibili para sa mga gusto ng Oracle at ang kanilang platform sa ulap, mga database at server. At sa gayon ay nagbibigay-daan sa amin na gawin ang napakabilis na pag-unlad ng application at mag-plug lamang ng isang database pabalik sa mga server. Hindi namin kailangang isipin ang tungkol sa kung ano ang nasa ilalim ng hood. Ang downside, ay madalas na hindi namin iniisip ang tungkol sa kung paano namin idisenyo at ipatupad ang database pabalik hanggang sa magsimula itong masaktan at ang pagganap ay nagiging isang isyu at pagkatapos ay magtatapos tayo na maghanap ng tamang tool upang masuri kung bakit nasasaktan ang aming database at kung saan ang mga isyu sa pagganap. At madalas na ibabalik ito sa karaniwang problema ng kung paano namin na-index ang data na iyon at ang mga uri ng mga index na ginamit namin para sa data na iyon at pagkatapos ay ibabalik sa amin ang kinakailangan sa superhuman na pagganap. At ang isang taong may access sa mga tamang sistema at tamang mga tool upang mag-tune ang mga makina, at magsimulang makahanap ng isang mainit na lugar at tingnan kung nasaan ang mga query, kung saan gumagalaw ang data, ang mga uri ng mga query, kung paano nakaayos ang mga query, sino ang gumagawa ng mga query, at kung ang mga query ay nakapila, at kinakailangang mai-cache. Anong replication ang hinahanap mo?

At kaya kami ay mabuti at tunay - sa aking pagtingin - sa isang punto ngayon kung saan kahit na ang pinakamahusay na mga gurus ng database sa buong mundo, mahalagang ang aming mga arkitekto ng database at ang aming database administrator at mga base ng pagganap, sa aking pananaw ay kailangan nila upang simulan ang pag-agaw ng tamang mga tool upang maihatid ang pinakamainam na pag-tune ng index ng pagganap para sa anumang database ng database. Sapagkat ang sukat na kinakaharap namin at ang bilis ng paglipat ng mga bagay, hindi natin ito magagawa sa pamamagitan ng kamay, at ang pagtatangka na gawin na palagi ay maaaring magpakilala ng iba pang mga isyu sa pagganap, dahil maaaring hindi tayo magkaroon ng karanasan sa puwang na sinusubukan naming lutasin ang isang problema sa. At naniniwala ako na doon ay malapit na kaming ibigay kay Bert, at malapit nang pag-usapan natin kung paano nila malutas ang iba't ibang problema at ang uri ng mga bagay na maari ng kanilang tool gawin, lalo na para sa mundo ng Oracle. At doon, Bert, pupunta ako sa iyo.

Bert Scalzo: Salamat. Maligayang pagdating sa lahat, ang pangalan ko ay Bert Scalzo, nagtatrabaho ako para sa IDERA. Ako ang senior manager ng produkto para sa ilan sa aming mga produkto ng database. Ipapakita ko ang ilan sa mga ngayon. Ngunit nais kong pag-usapan ang tungkol sa mga index, dahil sumasang-ayon ako sa lahat ng sinabi ng lahat dito, lalo na ang huling slide, ang mga index ay napakasalimuot ngayon na kailangan mo ng isang tool, at inaasahan kong makumbinsi ka. Kaya ang disenyo ng indeks ng Oracle, hindi ganoon kadali ang dati nitong mga araw. Ang isang pulutong ng mga tao ay hindi sigurado sa kanilang sarili kapag tiningnan nila ang mga pagpipilian, at gusto ko ang kasabihang ito na hinugot ko mula sa kasaysayan, "sa mga bagay na ito, ang tanging katiyakan, ay walang tiyak." At iyan ang uri ko pakiramdam tungkol sa mga index sa mga araw na ito, dahil kahit na sa palagay mo alam mo ang sagot ng dapat mong index X, Y o Z, talagang hindi ka maaaring maging tiyak hanggang sa susubukan mo ito, dahil ang mga optimizer na iyon ay minsan ay kumikilos nang iba sa paraang inaasahan mo. At kaya maraming pagsubok at error sa disenyo ng index. Ngayon, sa mabuting mga lumang araw, kung kailangan mo ng isang index doon sa pangkalahatan ay dalawa lamang ang mga katanungan, o isang tanong. Natatangi ba ito o hindi ba natatangi? At maaari mong naisip ang iba pang mga bagay tulad ng, "Gaano karaming mga index ang maaaring magkaroon ng maximum sa isang talahanayan?" Dahil napakaraming mga index na nagpapabagal sa iyong mga pagsingit, pag-update at pagtanggal. Maaari ka ring nasa iyong system ng database, nagkaroon ng mga paghihigpit sa kung gaano karaming mga haligi ang maaaring maging sa isang index ng multi-haligi, dahil kung minsan mayroong mga limitasyon batay sa pahina o sukat ng bloke ng iyong database ng engine, ngunit sa katotohanan ito ay medyo simpleng likod sa magandang araw. In-index mo rin ito o hindi mo ginawa. At talagang, lahat ay nasa isang B-puno. Pinahihintulutan namin ang mga duplicate o hindi, at tungkol dito. Maganda ang buhay, simple ang buhay.

Sa ngayon, ang buhay ay hindi napakahusay o sobrang simple. Inilagay ko ang pulang Ghostbuster sign sa pamamagitan ng paraan na ginamit namin, dahil ngayon mayroon kaming B-tree kumpara sa bitmap, kumpara sa bitmap sumali. At ipapaliwanag ko kung ano ang ilang mga ito sa isang iglap. Clustered at non-clustered, natatangi o duplicate, pasulong o baligtad na pagkakasunud-sunod, function-based, partitioned o hindi nahati. Kung may partitioning na kasangkot, global ba ito o lokal na pagkahati? Ipapaliwanag ko rin iyon. At pagkatapos ay mayroon ding isang bagay na tinatawag na isang nakaayos na talahanayan. At talagang kalahati ng isang dosenang iba pa na iniwan ko dito, dahil sa palagay ko sapat na ako dito na dapat kumbinsihin sa iyo na ang mga index ay mas mahirap kaysa sa naisip mo. Sa partikular na slide na ito, magsisimula ako sa tuktok na kaliwang bahagi ng diagram at nakuha ko ang isang mesa. At ang unang dapat kong magpasya ay, nakasalalay sa iyong bersyon ng database at sa iyong database vendor, pinapayagan ba nila ang mga object table o sila ay relational lamang? Bababa ako sa kanang bahagi at sasabihin na nagtatayo kami ng isang relational table. Ngayon, ang susunod na tanong na dapat kong tanungin ang aking sarili, ito ba ay nasa isang kumpol? At maraming sa iyo na nagawa ang Oracle para sa ilang oras ay maaalala na ang mga kumpol ay bumalik sa Oracle 6 na araw. Marahil hindi sila masyadong gagamitin ngayon, ngunit hayaan ko munang ibaba ang sanga na iyon.

Kung ilalagay ko ang aking talahanayan sa isang kumpol, kailangan kong magkaroon ng isang clustered index sa talahanayan na iyon. Ngayon, sa Oracle, kapag nag-cluster ka ng isang lamesa, talaga na itinatago mo ang mga hilera o ang mga hilera ay malapit sa bawat isa kung saan magkapareho ang mga halaga. At sa gayon, kailangan mong magkaroon ng isang clustered index at ang clustered index ay maaaring hindi nahati. Sa madaling salita, wala talagang anumang mga pamamaraan ng pagkahati para sa kung paano mo gagawin ang isang clustered table. Ito ay mahigpit na hindi partisyon. At dahil hindi ito nahati, ito ay pandaigdigan. Ipapaliwanag ko kung ano ang pandaigdigan sa isang minuto. At ito ay palaging B-puno. Sa madaling salita, nang bumaba ako sa sangang iyon, medyo simple, wala akong maraming mga pagpipilian. Ngayon, kung gumawa ako ng isang hindi clustered index sa isang clustered table, na pinapayagan sa ilang mga bersyon, muli ito ay hindi nahati; kapag hindi ito nahati, pagkatapos ay ang iyong tanging pagpipilian ay pandaigdigan. At kung gayon, doon ka napili ng B-puno o bitmap. Muli, nakasalalay ito sa iyong bersyon ng database. Ngunit ngayon, bumalik tayo sa relational na talahanayan at simulan ang pagpunta sa kanang bahagi ng kamay muli at ngayon lamang tayo ay magkakaroon ng isang plain, luma, regular, na may buntong mesa: relational. Pupunta ito sa isang puwang ng mesa. Ako ay uri ng bumaba sa kanang bahagi dito muna. Kaya ito ay samahan, magbunton. Ang susunod na tanong na dapat kong tanungin ang aking sarili ay, "Gusto ko bang mahati ang talahanayan na ito o hindi ako?" Ngayon, kung minsan ay magkahiwalay ka dahil naisip mo, "Uy, ang optimizer ay magiging mas matalinon tungkol sa kung paano ito mai-optimize ang mga query. "Ngunit maraming DBA ang magsasabi sa iyo na ang dahilan na ginagawa mo ay para sa mga layuning pang-administratibo. Kung mayroon kang isang daang-bilyong-talahanayan talahanayan, kung masira mo ito sa mga partisyon o mga timba, kung nais mong magdagdag ng data sa huling balde, maaari kang mag-drop at mag-index na ilang milyong hilera lamang. Maaari mong ipasok ang data na iyon at pagkatapos maaari mong muling itayo ang index na iyon sa balde lamang.

Habang ito ay isang mahusay na pamamaraan para sa ilan, mga diskarte sa pag-optimize tulad ng pag-aalis ng pagkahati, ang tunay na halaga nito ay pinangasiwaan o gawin ang mga gawain sa administratibo sa mas maliit na piraso. Kapag nagpunta ako sa tambak ng organisasyon, ang unang tanong ay, "Naghiwalay ba ako o hindi?" Pumunta tayo sa kaliwa, hindi ako hihiwalay sa mesa. Ngayon, mukhang kakaiba kapag sinabi ko ito sa iyo, ngunit maaari kang magkaroon ng isang hindi partisyon na mesa at pagkatapos ay hindi mo mahati ang indeks tulad ng nasanay ka, o maaari mong mahati ang index. Tumigil at mag-isip. Ang iyong talahanayan ay karaniwang isang balde, tulad ng lagi mong naisip, at gayon pa man ang iyong indeks ay magkakaroon ng maraming mga balde. Kapag nangyari iyon, kung saan mayroong isang pagkakamali sa pagitan ng bilang ng mga mga balde at talahanayan, at ang bilang ng mga mga balde sa index, iyon ang ibig sabihin ng global. At sa gayon, kung ang talahanayan ay hindi nahati, at kung ang index ay nahati, itinuturing na pandaigdigan, dahil mayroong isang mismatch. Ngayon, pabalikin ko ang aking tambak, at bumaba sa partisyon. Ngayon, kung mayroon akong isang talahanayan ng pagkahati, at sabihin nating ang talahanayan ay may apat na mga balde, apat na partisyon, ang aking index ay maaaring magkaroon ng apat na mga balde upang ang aking index ay tumutugma sa aking disenyo ng mesa. At kaya natapos na, patungo sa kanang bahagi. Iyon ay ituturing na lokal. Ang isang lokal na index ay nangangahulugan na ang pagkahati ng talahanayan at ang index ay ginagawa sa parehong paraan at may parehong bilang ng mga mga balde. At pagkatapos na magkaroon ako ng lokal na index, maaari itong maging isang B-puno o isang bitmap, at ang berdeng arrow na uri ng iyon ay pupunta, ay nagpapakita sa iyo na kahit na ito ay isang B-puno, may mga pagpipilian pa rin na maaaring gawin. Maaari itong maging batay sa pag-andar. At din, kung ito ay isang bitmap, may iba't ibang uri ng mga bitmaps. Mayroong isang bagay na tinatawag na isang bitmap sumali index. Kung gumagawa ka ng warehousing ng data, iyon ay isang napaka tanyag na uri ng index para sa star schema o disenyo. Ang mangyayari ay ang index ay mayroong mga row ID para sa kung ano ang itinuturo nito sa talahanayan, ngunit magkakaroon din ito ng mga row ID para sa mga talahanayan ng magulang upang kapag ikaw ay - kailangan mong mag-star schema design at naghahanap ka sa isang talahanayan ng katotohanan, ang indeks na iyon sa talahanayan ng katotohanan ay nagtuturo sa iyo sa data na interesado ka, at itinuturo ka sa bawat hilera sa iyong mga sukat, upang mayroon ka lamang magkaroon ng isang index.

At sa totoo lang, ito ay naging dahil sa Red Brick, na isang database ng maraming taon na ang nakararaan - maraming tao ang maaaring maalala iyon. At kaya, kung titingnan mo ang larawang ito - at tandaan na hindi ko inilagay ang lahat sa larawang ito dahil ang larawan ay magiging mas malaki - mayroon pa ring mga karagdagang isyu, na mayroon akong teksto dito sa tuktok na kanang bahagi . Ito ba ay isang reverse-order index? At maaari mong sabihin, "Bakit gusto ko ang isang reverse-order index? Hindi mahalaga kung anuman. "Well kung ikaw ay nasa isang clustered na kapaligiran sa Oracle, kung gumagawa ka ng mga tunay na kumpol ng aplikasyon, kung pinapanatili mo ang iyong mga index, kaya hindi mababalik, kung mayroon kang maraming pagproseso na pagpindot ang parehong mga halaga o magkatulad na halaga ng index, kung ano ang mangyayari ay, mayroon kang maiinit na lugar ng iyong B-puno. Ibig sabihin na magkakaroon ka ng pagtatalo at marahil ang pag-lock upang subukan at ma-access ang mga bagay na iyon, at gagawin mo iyon sa mga node sa isang network. Buweno, kung naglagay ka ng isang reverse-order index, maaari mo nang alisin ito. Maaari mong sabihin, "Buweno, ang magkaparehong mga halaga ay nasa iba't ibang bahagi ng mga puno, kaya wala akong mga hiwalay na node na nakikipagkumpitensya para sa mga mainit na lugar sa puno." At pagkatapos ay mapansin din na ang natatanging ay hindi gumagana sa ilang mga pagpipilian . Kung titingnan mo, naibilang ko ang tatlo, lima, walo at labing isa, kaya may ilang mga kaso kung saan hindi ako magkakaroon ng isang natatanging index. Gayundin, may ilang mga kaso kung saan hindi ako maaaring magkaroon ng isang reverse index, at pagkatapos ay mayroong mga karagdagang isyu tulad ng pag-log o walang pag-log, at kahanay at hindi kahanay. Maaari akong magtalaga ng mga bagay sa isang tiyak na lugar sa memorya.

At ito ay umalis pa rin ng kaunting mga tampok sa Oracle. Sasabihin ko na kapag tiningnan mo ang Oracle 12, marahil muli ang tungkol sa isa pang kalahating dosenang mga bagay na maaari kong idagdag sa larawang ito. Ang pag-index ay talagang kumplikado at talagang sumasang-ayon ako sa naunang tagapagsalita, upang mag-navigate sa pamamagitan nito at gumawa ng isang mahusay na pagpipilian, kailangan mo ng isang tool. Uri mo ng pangangailangan, marahil, isang larawan na tulad nito, at ilang uri ng isang pamamaraan sa kung paano mo pipiliin ang mga bagay at sana ay makakatulong ang iyong makarating doon. At pagkatapos ay magiging pagsubok at pagkakamali. Palagi kong sinasabi sa mga tao sa pag-index, "tumingin bago ka lumukso." At pagkatapos ay makikita mo ang maliit na aso dito, tumatalon siya nang hindi naghahanap, pupunta siya sa tubig na may pating, o ang tao ay naghahanda na tumalon sa tubig, at ipo-impale niya ang kanyang sarili. Dapat mong isipin ang tungkol sa iyong pag-index, dahil ang paglikha ng isang index ay hindi palaging nangangahulugang gumaling ang mga bagay. Sa katunayan, ang paglikha ng isang index ay maaaring magpabagal sa mga bagay. At ang pagganap ng query ay maaaring maging isang order ng magnitude na mas mahusay sa isang pagpipilian kaysa sa isa pa. At bibigyan kita ng isang magandang halimbawa. Kung gumagawa ka ng isang star schema ng disenyo, at sa iyong mga talahanayan ng sukat gumamit ka ng mga index ng bitmap sa isang kaso, at sa ibang kaso sasabihin mo, "Gumagamit ako ng mga index ng B-tree, " mayroon kang bitmap kumpara sa B- puno. Masasabi ko sa iyo na ang isang solusyon ay magiging isang pagkakasunud-sunod ng magnitude o posibleng maraming mga order ng magnitude na mas mabilis kaysa sa iba pa. Ngunit tandaan kung ano ang gumagana sa isang kapaligiran, tulad ng sa isang kapaligiran sa warehousing ng data, marahil ay hindi isang mahusay na pagpipilian sa isang OLTP na kapaligiran.

Halimbawa, kung kukuha ka ng isang talahanayan ng transactional, at maglagay ng mga index ng bitmap sa isang talahanayan ng transactional, mahal na makalkula at i-reset ang mga bitmaps, ang mga mahabang string na ito, at iba pa sa isang talahanayan ng OLTP, maaari mong pindutin ang talahanayan nang labis na ang bitmap Maaaring maging tiwali ang index at pabagalin ang iyong system dahil hindi lamang ito para sa mga pag-update. Magaling sila para sa mabilis na pag-access, ngunit hindi mabuti para sa mga pag-update. Sa palagay ko ay tumatagal ang pagsubok at error. Wala talagang gintong panuntunan - napakaraming iba't ibang mga variable sa ekwasyong ito na malaman - at sa huli ay kailangan mong tingnan ang pagpapatupad o ipaliwanag ang mga plano sa iyong database upang makita kung gumawa ka ba o hindi ka nakakagandang mga pagpipilian. At kung minsan, ang pagtatasa ng plano ay halos maging isang agham sa kanyang sarili. Hindi ko tatakpan na ngayon - iyon ang isa pang paksa - ngunit huwag mong bigyang-halaga ang disenyo ng index. May mga lehitimong dahilan kung bakit mayroong lahat ng mga ganitong uri ng mabaliw na index na ipinakita ko sa iyo, sa naunang larawan, at ang naunang nagsasalita ay nagsalita. Ang mga ito ay hindi lamang nilikha dahil ito ay isang masinop na tampok upang maglagay sa isang listahan ng tseke sa isang lugar para sa isang nagbebenta ng database; mayroong mga kaso ng paggamit o mga sitwasyon kung saan mahalaga ang mga index na ito at gagawa ng isang makabuluhang pagkakaiba. Ngayon, ipapakita ko sa iyo ang ilang mga halimbawa ng iba't ibang uri ng mga index sa isa sa aming mga tool. Hayaan ko na lang na mag-screen ang aking screen upang makita mo ito. Okay, kaya narito ako nakaupo sa loob ng - hayaan mong i-minimize ang application na ito. Nakaupo ako sa loob ng VMware at nagpapatakbo ako ng Windows Server 2012 VM.

At makikita mo, mayroon akong halos lahat ng tool na kilala sa tao. Bilang isang tagapamahala ng produkto, kailangan kong manatiling kamalayan sa aking kumpetisyon, kaya hindi lamang kung anong mga tool ang mayroon ako, ngunit ano ang ginagawa ng aking mga kakumpitensya? At nakuha namin ang tool na ito na tinawag na DBArtisan, na tumakbo na ako, ngunit pupunta ako - kaya dadalhin ko lang ito. At ang nakikita mo ay ito ay isang napakagandang tool, dahil sa halip na kinakailangang gamitin, sabihin ng isang manager ng enterprise para sa Oracle at isang SQL Management Studio para sa SQL Server, at ang MySQL Workbench para sa MySQL, at labindalawang iba pang mga database na sinusuportahan namin. mabuti nakuha ko ang lahat ng aking mga database na binuo sa isang tool na ito. Mayroong DB2, mayroong MySQL, Oracle, Postgres, SQL Server at Sybase, at iyon - Mayroon lamang akong anim na mga database sa partikular na bagay na ito sapagkat hindi ko magagawa - sinusuportahan ng tool ang labindalawang database ngunit ang aking mahinang VM, na tumatakbo ng anim na mga database nang sabay, at sinusubukan upang gumawa ng isang demo, ay tungkol sa mas maraming bilang ng aking hardware ay mapadali. Kaya't bumalik ako sa Oracle ngayon, at kung napansin mo, ang lahat ng mga bagay na ito ay pareho. Kung nais kong sukatin ang aking pagganap sa DB2, pareho ang mga pagpipilian na nais kong makuha sa Oracle. Ngayon sa ilalim ng mga pabalat ginagawa namin ang maraming iba't ibang mga bagay upang hindi mo na kailangang malaman kung ano ang nangyayari, ngunit bibigyan ka namin ng isang pare-pareho na interface upang maaari kang maging isang dalubhasa na may maraming mga platform sa database. At isasama ang pagtatrabaho sa mga index, ang paksa ng talakayang ito.

Hayaan akong pumasok dito at hayaan akong magsimula sa pamamagitan ng pagpunta sa pagtingin sa ilang mga talahanayan, at mayroon akong database ng mga pelikula na mayroon lamang ng ilang mga talahanayan. At kung titingnan ko ang isang partikular na talahanayan, tulad ng talahanayan ng customer, kapag dinala ko ito, makikita ko ang disenyo ng mesa ko, narito ang aking mga haligi sa aking talahanayan, at narito ang impormasyon tungkol sa bawat haligi. Mayroon akong mga katangian para sa talahanayan, ngunit tandaan na mayroon akong isang tab dito para sa mga index at nakikita ko dito ang mga index sa mesa. Pansinin na ang isa sa mga index na ito ay ang aking index ng PK, ang aking pangunahing susi. Ang iba pang mga ito ay mukhang mga index lamang para sa pagpapabuti ng pag-access sa query, marahil ay nag-query kami sa pamamagitan ng unang pangalan, o apelyido, o tiningnan namin ang mga telepono at mga code ng zip. At kung pumili ako ng isang partikular na index, tulad ng zip code dito, at doble akong nag-click dito, ngayon makikita ko na, hey, ito ay isang hindi natatanging index at narito ang ilan sa iba pang mga uri, bitmap, hindi natatangi, natatangi, pinag-uusapan man o hindi, hindi man ang pag-log, o reverse order ito, kung ito ay isang base ng function. Oh, narito ang isang masaya na hindi ko nasaklaw. Maaari kang aktwal na magkaroon ng mga hindi nakikita na index. At sasabihin mo, "Well, bakit gusto kong gawin ang isang hindi nakikita na index?" Well, bibigyan kita ng isang magandang halimbawa. Nasa iyong sistema ng paggawa at mayroon kang problema sa pagganap at hindi ka sigurado na ang paglikha ng index ay ayusin ang problema, kaya ayaw mong lumikha ng index at pabagalin ang produksiyon, ngunit kahit papaano o ang iba pang nais mong maaring subukan ito. Maaari kang lumikha ng index sa produksyon bilang hindi nakikita, nangangahulugang hindi maraming application code, na tumatawag sa optimizer, ay gagamitin ang index na iyon. Nilikha ito, may bisa, ngunit hindi ito gagamitin. Pagkatapos ay maaari kang kumuha ng isang query na sa palagay mo ay makakatulong ang index na ito, o isang serye ng mga query, at maaari kang dumikit sa isang pahiwatig at sasabihin, "Hoy, optimizer, mayroong isang hindi nakikita na indeks doon na nais kong gamitin at hayaan mo. alam ko kung nagawa ko bang gumawa ng mga bagay. "At ngayon nasubukan ko ang isang bagay sa paggawa, ngunit hindi ko nasira ang mga aplikasyon sa paggawa na tumatakbo. Iyon ang paggamit para sa isang hindi nakikitang index. Ito ay pipi kapag una mong narinig ang tungkol dito, ngunit mayroon itong gamit.

Maaari din namin, sa mga index, tukuyin kung kahanay sila, at kung gaano karaming mga pagkakataon na magkatulad sila. Ngayon, sa isang hindi clustered o isang hindi tunay na kapaligiran ng kumpol ng aplikasyon, kaya ang hindi rack, kahanay ay nangangahulugang kung gaano karaming mga sub-proseso ang maaaring magawa ng aking query upang subukan, at mga proseso ng manggagawa, upang subukan at makakuha ng bagay sa pamamagitan ng mas mabilis o mas mabilis . At ang magkatulad na mga pagkakataon ay magiging, kung ako ay nasa isang tunay na kumpol ng aplikasyon, sabihin na mayroon akong sampung mga node, ilan sa mga node ang pinapayagan kong hatiin ang trabaho sa kabuuan? Marahil ito ay apat sa sampu, at sa bawat isa sa kanila, apat na sub-proseso. Isang halimbawa iyon. At pagkatapos ay mayroon kaming key na compression. Maaari mong aktwal na i-compress ang mga index? Oo o Hindi. At pagkatapos siyempre mayroon kang iyong mga parameter ng imbakan na maaari mong tukuyin sa mga index. Ngayon, hindi ko nasasakop ang mga ito dahil talagang marami silang isang parameter ng imbakan kaysa sa isang isyu sa index. At pagkatapos ay sa wakas, mayroon kami kung gagawin o hindi ang pagkahati sa mga ito o hindi. Ihulog ko na dito para sa isang segundo. Pupunta ako sa ibang schema. Ito ay isang star schema at, halimbawa, ang period table na ito ay isang talahanayan ng sukat. Kung nagawa mo na ang disenyo ng star schema na karaniwang mayroon kang isang sukat para sa oras at sa gayon sa database na ito at ang star schema na ito, ang panahon ay isang sukat sa oras. Ngayon, alam kong nakakatawa ito, sasabihin mo, "Gee, tingnan ang lahat ng mga haligi na iyon - narinig ba ng tao ang normalisasyon?" Buweno, kapag nasa isang bodega ka ng data o disenyo ng isang schema ng bituin, ikaw Karaniwan ay walang mga - mayroon kang mga talahanayan na titingnan ng isang karaniwang tao at sasabihin, "Gee, ang mga ito ay hindi masyadong mahusay na dinisenyo." Ngunit ganyan ang ginagawa mo sa isang kapaligiran ng warehousing ng data.

Ngayon, panoorin kung ano ang mangyayari dahil, okay, mayroong lahat ng mga haligi na ito, tingnan mo na, mayroon akong isang index sa bawat solong haligi. Ngayon, sa isang OLTP na kapaligiran na magiging isang no-no. Mapabagal nito ang lahat ng aking operasyon. Sa isang kapaligiran ng warehousing ng data, ibababa ko ang mga ito sa panahon ng aking mga pag-load ng mga batch. Mag-load nang walang overhead o sa mga index, at gusto kong muling likhain ang mga index. At kung nahati ko ang aking talahanayan, at pagkatapos ay sa halip na i-drop ang index para sa bawat balde sa talahanayan, maaari ko lamang ihulog ang index sa mga balde o mga balde kung saan pupunta ang data sa panahon ng pag-load ng batch na iyon. At pagkatapos ay muling likhain ang bahagi ng index para sa mga balde. At sa gayon ito ay napapamahalaan. At kung titingnan ko - kaya narito ang isang haligi na tinatawag na "Holiday Flag" at talaga na oo o hindi. Pansinin na ito ay isang bitmap index, at para sa karamihan sa iyo sasabihin mo, "Well, nangangahulugang iyon." Oo o hindi, Y o N, may dalawang mga halaga lamang na may katuturan. At dahil nabasa mo ang dokumentasyon para sa mga index ng bitmap, lagi nilang sinasabi sa iyo na pumili ka ng isang bagay na may mababang kardinidad.

Ngayon ipasok ko ang isa sa aking mga talahanayan ng katotohanan, kaya narito, mayroon tayong mga order. At ito ang aking mga order bawat araw. At makikita mo ngayon, na muli mayroon akong kaunting mga haligi, at muli, magkakaroon ako ng higit sa ilang mga index. At dito mismo, mayroon kaming isang bagay na tinatawag na universal code ng presyo. Ito ay para sa isang tindahan ng tingi, kaya alam mo ang mga maliit na bar code kapag bumili ka ng isang bagay sa tindahan, ito ang unibersal na code ng presyo. Ngayon, may mga milyon-milyong mga code ng unibersal na presyo. Ngayon, para sa partikular na kumpanya na nagbebenta ng mga bagay-bagay, marahil sila ay 1.7 hanggang 2 milyong unibersal na mga code ng presyo, kaya aasahan mong hindi ito magiging isang bitmap index dahil ang 1.7 milyong natatanging halaga ay parang tunog ng mataas na kardinidad. Ngunit sa katotohanan, sa isang kapaligiran ng warehousing ng data, nais mo itong maging isang bitmap. Ngayon, hayaan kong ipaliwanag kung bakit. Buweno, maaaring mayroong 1.7 milyong natatanging mga halaga para sa unibersal na code ng presyo na ito, ang bilang ng mga hilera sa talahanayan ng order na ito ay nasa daan-daang milyon sa bilyun-bilyong mga hilera. Ang aking index ay mababa ang kardinidad kung ihahambing sa laki o kardinidad ng talahanayan. Ginagawa nitong mababa ang kardinalidad. Ginagawa nitong kapaki-pakinabang ang index ng bitmap, kahit na ito ay counterintuitive na may 1.7 milyong natatanging mga halaga na pipiliin mo ang bitmap dito. Ngayon, kung alam ko na nais kong gumamit ng isang bitmap sumali index, kasalukuyang hindi suportado ng produkto na, kukuha ako ng naidagdag para sa susunod na paglabas, ngunit iyon ay isa pang alternatibo dito. At sa isang schema ng bituin, tandaan, ang index ng bitmap ay nasa katotohanan ng talahanayan at na ang isang indeks sa B-puno ay ituturo sa hilera sa talahanayan ng katotohanan at pagkatapos sa bawat hilera na maliwanag sa talahanayan ng sukat para sa katotohanang iyon . At kung gayon, mayroon kang ibang pagpipilian doon. At sa gayon, tingnan natin, nais kong lumabas ng mga talahanayan ngayon at nais kong ipakita sa iyo nang mabilis na mayroon akong parehong impormasyon, sa ilalim ng mga index, at gagawin ko ang parehong pangunahing bagay.

Ngayon, ang dahilan kung bakit ko ito napansin ay maaari mong mapansin, hey walang pangunahing mga susi dito. Ang mga pangunahing key ay ginagawa gamit ang isang pangunahing pagpilit, kaya talagang nasasaklaw sila ng mga kahulugan ng pagpilit. Ito ay magiging mga index na hindi bahagi ng pagpilit. Ngayon ay maaari mong sabihin, "Well, maghintay ng isang minuto, na maaaring mukhang isang susi ng dayuhan, at ang isang dayuhang susi ay isang pagpilit, " ngunit ang mga dayuhang mga susi at karamihan sa mga database ay hindi awtomatikong lumikha ng isang index sa dayuhang key na haligi, kahit na maipapayo, at doon ka pupunta - nakuha ko na rin ang lahat ng parehong mga pagpipilian. At kung nais kong baguhin lamang upang mai-compress, magagawa ko iyon.

Ngayon ang compression ay gumagana lamang sa isang index ng B-tree. Ano ang nagpapahintulot ay, kapag tiningnan mo ang iba't ibang mga node sa B-puno, pinapayagan nito ang pag-compress ng ilan sa mga halaga. Talagang hindi ito compression tulad ng compression ng talahanayan, ito ay isang compression ng kung ano ang naka-imbak sa B-tree sa mga non-leaf node. Hindi ito nakakatipid ng isang toneladang espasyo, ngunit maaari itong gumawa ng pagkakaiba. At sa napansin ko na, malapit na ako sa oras, kaya ang nais kong gawin ay, nais kong bumalik, at itigil ang aking pagbabahagi. At, mayroon kaming produkto sa labas para sa isang labing-apat na araw na pagsubok sa idera.com. Ito ay isang magandang produkto, lalo na kung nagtatrabaho ka sa maraming mga platform sa database. Kung nagtatrabaho ka sa dalawa o tatlong magkakaibang mga database, gawing mas madali ang iyong tool. Mayroon kaming mga tool upang matulungan ka sa disenyo at pagpili ng index, mayroon kaming isang tool na tinatawag na DB Optimizer. Hindi ko lang kayang takpan iyon ngayon, magiging sobra na. At kung nais mong makipag-ugnay sa akin, nariyan ang aking email address, o, maaari mo akong mahuli sa aking pribadong email, at mayroon akong mga blog, mayroon akong isang website at blog, at isang profile sa LinkedIn doon. Kaya't huwag mag-atubiling maabot ang anumang bagay sa akin, kahit na hindi ito nauugnay sa produkto, kung nais mo lamang na makipag-usap sa mga database, ako ay isang geek sa puso at gustung-gusto kong mag-usap tungkol sa technobabble.

Eric Kavanagh: Sige, well Dez, Robin, sigurado ako na bawat isa ay mayroon kang ilang mga katanungan kahit papaano, mayroon kaming ilang minuto na naiwan dito. Dez, ano sa tingin mo?

Dez Blanchfield: Mayroon akong isang mahusay na katanungan na dapat kong tanungin, nakaupo ito sa likuran ng aking isip. Ano ang pinakapangit na senaryo na iyong nakita? Nabasa ko na ang iyong blog, sinusundan kita ng malapit, ang - ikaw, marahil isa ka sa ilang mga tao na nanirahan sa halos lahat ng hindi malamang, at sa palagay ko si Dr. Robin Bloor ang pangalawa na nakilala ko sa habang buhay ko. Ngunit, alam mo, malamang na nakita mo ang bawat nakatutuwang senaryo, kung ano ang ilan sa mga pinakapangit na mga sitwasyong nakita mo, na napagtagumpayan mo, at tulad ng mga tao na hindi lamang makaya, nakaya mong maglakad at gumanap Jedi isip trick sa buong DBArtisan?

Bert Scalzo: Nagkaroon kami ng isang customer kung sino, sa kanilang disenyo ng database na naisip nila nang labis ang paraan na iisipin nila sa isang disenyo ng layout ng file, at kung gayon, ito - kapag normalize mo ang isang database, ang unang bagay na sinusubukan mong gawin ay mapupuksa ng paulit-ulit na mga pangkat. Well, mayroon silang isang haligi at ginawa nila ito ng mahaba, o isang BLOB o CLOB, at sa loob nito ay ilalagay nila ang halaga, numero uno, semicolon, halaga ng numero ng dalawang, semicolon, halaga ng halaga, semicolon, at magkakaroon sila ng libu-libong mga halaga doon, ngunit kailangan nilang maghanap sa haligi na iyon at tulad nila, "Bakit ang bagay na ito ay tumakbo nang napakabagal?" At tulad ko, "Well, hindi ka maaaring lumikha ng isang indeks sa iyong ginawa, ito ay hindi pinapayagan. "Kaya talagang ipinakita namin sa kanila, gamit ang mga plano, na ang kailangan nilang gawin ay gawing normal ang talahanayan. Hindi dahil ang normalisasyon ay ilang ehersisyo na pang-akademiko na nagpapabuti sa mga bagay, ngunit dahil nais nila ang isang query sa larangan na iyon, na nangangahulugang nais nilang mai-index ito, at hindi mo ito ma-index sa isang paulit-ulit na grupo, o hindi bababa sa madali . At sa gayon marahil ang pinakamasama bagay na nakita ko.

Dez Blanchfield: Oo, kawili-wili kung gaano kadalas ka makarating, sa palagay ko ang hamon sa mga database, nakalimutan ng mga tao na ito ay isang agham. At mayroong mga tao na gumawa ng mga degree at PhD sa buong puwang na ito, sumulat ng mga papeles dito, at nakasulat ka ng isang buong swag kasama ang iyong mga handbook ng TOAD at iba pang mga bagay mula sa memorya. Ang takbo patungo sa uri ng, quote-on-quote na "malaking data" ngayon - Nakikita ko ang maraming tao na nakakalimutan ang mga pangunahing kaalaman ng arkitektura ng database at teknolohiya ng database, science science, kung gusto mo. Ano ang nakikita mo sa larangan hanggang sa paglayo ng tradisyonal na mga platform ng database at tradisyunal na pag-iisip ng database na epektibong ginawa namin ang kuko sa lupa, at ito ay isang kaso lamang ng pagganap sa pag-tune at pag-scale. Nakakakita ka ba ng maraming tao na muling bumalik at magkaroon ng isang karanasan kung saan nakaupo lang sila doon at mayroong isang "a-ha" sandali, tulad ng isang sandali ng Eureka, kung saan napagtanto nila, ang malaking bagay na datos na ito ay talagang uri ng talagang malaking database? Ito ba ay isang bagay sa labas at ang mga tao ay sumasagot sa iyo pabalik at uri ng, "Nakalimutan namin, ang alam namin at maaari mong ibalik sa amin mula sa madilim na bahagi?"

Bert Scalzo: Well, hindi, at ito ay kakila-kilabot na dapat na uri ng aminin, ngunit ang mga relational database vendor ay uminom din ng Kool-Aid. Kung naaalala mo, hindi ko alam, tungkol sa isang dekada na ang nakakaraan, sinimulan namin ang paglagay ng hindi naka-istrukturang data sa mga database ng relational, na kung saan ay uri ng isang kakaibang bagay na dapat gawin, at pagkatapos ang data, ang mga nakabatay na mga database, ay nagdaragdag ngayon sa uri ng NoSQL bagay. Sa katunayan, sa Oracle 12, CR2 - alam kong hindi pa ito - ngunit kung titingnan mo ang beta, kung nasa beta program ka, sinusuportahan nito ang sharding. At kaya, ngayon mayroon ka nang isang relational database na hindi naidagdag ang konsepto mula sa pag-shard ng NoSQL. At kung gayon, ang "a-ha" sandali ay tila higit pa para sa mga tao sa panig ng pamamagitan na pupunta ng "a-ha." Walang sinumang gagawing gawin muli ito, hindi kahit na ang mga tagapamahala ng database, kaya't nagawa namin kailangang pumunta at sumali sa madilim na bahagi.

Dez Blanchfield: Tama, kaya't sinasabi mo ang isang paglipat sa maraming magulo na data, kung nauunawaan ko nang tama, na inilalagay sa, kung ano ang tinatawag nating malalaking platform ng data, na uri ng nakakatawa, dahil sila ay hindi iyon matanda, ngunit hindi ba nangangahulugan ito na sila ay tumututok sa kung ano ang ginagawa nila sa kanilang database ng pamanggit upang makakuha ng mas maraming bang para sa kanilang mga usang lalaki?

Bert Scalzo: Hindi, kadalasan, kung mayroon silang pangangailangan sa - na sana ay quote ng isang "malaking pangangailangan ng uri ng data, " hinahanap nila na sa halip na pumunta sa ibang platform ng database at gumawa ng isang bagay sa isang non Pang-ugnay na paraan, binibigyan sila ngayon ng mga nagtitinda ng database ng parehong mga pamamaraan na hindi nakakapag-ugnay sa loob ng kanilang database ng pamanggit, upang gawin ang mga bagay na iyon. Ibig kong sabihin, isang magandang halimbawa ang magiging, kung mayroon kang hindi nakaayos na data, tulad ng isang uri ng data ng JSON o ilang iba pang kumplikadong uri ng data na may kahulugan na naka-embed sa data mismo, ang mga nagtitinda ng database ay hindi lamang sumusuporta sa, ngunit bibigyan ka nila ng ACID pagsunod sa hindi nakaayos na data. Ang mga database ng kaugnayan ay yakapin ang mga mas bagong pamamaraan at teknolohiya at sa gayon, muli na ang "a-ha" ay tila hindi na, "Uy, kami, ang mga nag-develop ng aplikasyon, ay walang kaalaman at kailangan nating malaman ito, " ito ay "Hoy, ginagawa namin ito sa ngayon, paano ko ito magagawa sa iyong tradisyonal na database ng relational at gawin ko tulad ng ginagawa ko sa database na ito dito? "at iyon ay nagiging higit na karaniwan, at tulad ng sinabi ko, ang mga nagtitinda ng database mismo ay nagpapagana. na.

Dez Blanchfield: Tama, sino ang mga tradisyunal na suspek sa puwang na ito para sa tool na DBArtisan at iyon? Ginawa ko ang ilang araling-bahay sa kung ano ang nais mong isulat kamakailan, at mula sa memorya na nais mong sumulat ng isang bagay, sa palagay ko ito ay isa sa iyong mga blog, sa matinding pagganap ng database sa mundo ng Oracle. Hindi ko matandaan kung kailan ito, sa palagay ko ay minsan sa taong ito mula sa memorya, o mula noong huling taon, naisulat mo ang bagay na ito. At sa palagay ko ito ay ang tradisyonal, karaniwang pinaghihinalaan para sa uri ng paksa na pinag-uusapan natin ngayon, kung saan ang mga tao ay pupunta sa napakalaking database ng database at hanapin kung ano ang tinawag mong matinding mga nakuha dito. Sino ang mga karaniwang pinaghihinalaan na nakikita mo doon na kumukuha ng DBArtisan at ginagamit ito nang mahusay?

Bert Scalzo: Well, marami kaming mga customer, sa katunayan, ngayon ay nakasama ako sa isang napakalaking ahensya ng gobyerno na - at literal na malapit sila sa 1, 000 kopya ng aming software, sapagkat pinapayagan nito ang mga tao na tutukan ang kung ano sila ginagawa muli, at hindi kung paano gawin ito. At okay lang, ibig kong sabihin, dapat alam ng lahat kung paano gumawa ng isang bagay, ngunit ang pagiging produktibo ay nakakakuha ng "kung ano". Kung hinihiling sa akin ng negosyo na gumawa ng isang gawain, iyon lamang ang kanilang kinagigiliwan. Kailan ako nakakuha ng isang tseke upang sabihin kung natapos ang gawain? Hindi kung ano ang diskarte o kung ano ang teknobabble na ginamit ko upang makarating doon. At sa gayon, ang aming tool ay nagbibigay-daan sa kanila na tumuon sa kung ano, at hinahayaan silang maging mas produktibo, at iyon talaga ang malaking bentahe, at tulad ng sinabi ko, ang ilang mga database ay nag-aalok ng isang tool para lamang sa kanilang database platform. Inaalok namin ito para sa labindalawang platform ng database. Mayroon akong parehong daloy ng trabaho, ang parehong graphical na interface ng gumagamit, ang parehong pag-navigate. Kung alam mo kung paano magbigay ng isang pribilehiyo sa isang gumagamit o kung paano lumikha ng isang talahanayan o lumikha ng isang index sa isang database, magagawa mo ito sa lahat ng labindalawang dahil ito ay ang parehong hitsura at pakiramdam at parehong daloy ng trabaho. Malaki ang halaga nito sa aming mga customer.

Dez Blanchfield: Oo, sa palagay ko, ang mga tao ay nais na makakuha ng mas maraming bang para sa kanilang mga usang lalaki mula sa kanilang mga mapagkukunan ng tao. At ang mga araw ng pagkakaroon ng isang indibidwal na espesyalista sa Oracle, Ingres at DB2 ay nawala lahat. Ang mga tao ay inaasahan na maging ang Jack ng lahat ng mga kalakal, kaya sa palagay ko ang bagay na ito ay ganap na nai-save ang kanilang buhay.

Isa lang sa huling mabilis na bagay bago ko ibigay ito kay Doctor Robin Bloor. Nabanggit mo na mayroong isang libreng pag-download para sa labing-apat na araw, ano ang - kung pupunta ako sa unahan at gagawin ko iyon, sa pamamagitan ng paraan, ilalagay ko ito sa lab na Bloor tech at iikot ang bagay na ito up at kumuha ng kamay sa aking sarili - Hindi ako nagkaroon ng pagkakataon na gawin iyon bago ngayon. Nabanggit mo ang isang labing-apat na araw na pagsubok, sinabi mong pinapatakbo mo ito sa isang VM sa iyong computer, inaakala kong ito ay isang laptop. Ano ang, ano ang pag-setup ng antas ng entry para sa isang tao na gumamit at gamitin ang labing-apat na araw na pagsubok, tulad ng bago ko ibabalik kay Robin ang kanyang mga katanungan?

Bert Scalzo: Anumang kapaligiran sa Windows, kaya ang Windows 7, virtual machine na may isang CPU at apat na gig ng memorya. Hindi kami talagang taba o mamahaling tool. Ngayon kung nais mong patakbuhin ang iyong database server sa parehong VM sa ilalim ng parehong Windows, oo, kakailanganin mong magdagdag ng higit pa, ngunit kung pinapatakbo mo ang iyong database sa isang database server o sa isang hiwalay na VM, ang VM upang mag-load at patakbuhin ang aming produkto ay napaka magaan: isang CPU, apat na gig ng memorya, medyo maraming bersyon ng Windows - at sinusuportahan namin ang parehong tatlumpu't dalawa at animnapu't-apat na bit na pag-install. Ngunit kailangan mong i-install ang client ng iyong vendor ng database. Kaya kung nais mong kumonekta sa Oracle, kailangan mong i-install ang kliyente ng SQL net, dahil iyon ang hinihiling ng Oracle para makausap mo ang isang database.

Dez Blanchfield: Mukhang diretso ito. Sa palagay ko na ang isang bagay mula sa higit pa sa anumang bagay na inaasahan kong aalisin ng mga tao, maliban sa pagsasakatuparan na ang tool na ito ay ililigtas ang kanilang buhay, ay dapat silang pumunta at i-download ito at maglaro kasama ito, ibinigay na nag-aalok ka ng isang labing-apat na araw na libreng pagsubok. At maaari itong tumakbo sa kanilang kasalukuyang laptop nang walang pag-install ng anumang labis, dahil kung nagagawa na nila ang database administrasyon, nagtatrabaho na sila sa mga database na nakuha nila ang lahat ng mga tool na iyon at kung ang pagpapatakbo nito sa isang lokal na VM o sa kanilang lokal na desktop, parang hindi masakit na mai-install at magkaroon ng paglalaro. Kaya inirerekomenda ko nang husto ang mga tao na gawin iyon.

Robin, sigurado akong mayroon kang mga katanungan at Eric, marahil mayroon kang ilang mula sa mga tagapakinig, kaya Robin, paano ako ipapasa sa iyo, at pagkatapos ay bumalik kay Eric?

Robin Bloor: Oo, okay, well mayroon akong mga bagay na sasabihin, ang ibig kong sabihin, lagi kong nahanap ang lugar na ito na kamangha-manghang dahil ito - pinutol ko ang aking mga ngipin. Ngunit ang katotohanan ay, marahil mula noong 1998, 1999, na-adrift ko kung ano talaga ang may kakayahan ng Oracle. At, alam kong Sybase at Microsoft SQL Server, pareho ng mga iyon ay medyo simple kumpara sa kung ano ang magagawa ni Oracle. Ginawa mo akong tumawa kapag ikaw - ang ibig kong sabihin, tinakpan ko ang aking bibig, nang nagsimula kang magsalita tungkol sa sharding. Oracle ginawa ito bago. Oracle ipinakilala sa ilang mga oras sa oras, sila ay kinakabahan ng bagay na may kaugnayan sa bagay, kaya ipinakilala nila ang kakayahang lumikha ng isang uri ng notasyon ng object at pag-iimbak ng object sa Oracle, at nakausap ko ang isa sa kanilang mga inhinyero, tulad ng isang pares ng mga taon pagkatapos nilang ipakilala ito at tinanong ko kung gaano karaming mga tao ang gumamit nito, at sinabi niya na sa palagay ko ay sinubukan ng dalawang mga customer at ito na. At sa palagay ko ang parehong bagay ay mangyayari kung sisimulan nilang subukan at gawin ang mga bagay na walang trabahong NoSQL. Alam mo, sa palagay ko ay isang pagkakamali, ang ibig kong sabihin, ako ay uri ng interesado sa kung ano ang iyong mga iniisip. Tiyak, ang - uminom sila ng Kool-Aid. Pakiramdam nila ay parang nagawa nilang makagawa ng mga paghahabol na katulad sa malaking mga database ng NoSQL tulad ng Cassandra, ngunit alam mo, may katuturan ba ito sa iyo?

Bert Scalzo: Hindi, tinamaan ka ng pako sa ulo. Para sa akin, gagawin ko, kung gagawin ko ang relational, kukuha ako ng isang relational vendor tulad ng isang Oracle o isang SQL Server o isang DB2 o isang Postgres, ngunit kung gagawin ko ang isang bagay na hindi nakakaugnay, sa malaking puwang ng data, o puwang ng NoSQL, pipiliin ko ang tamang tool para sa tamang trabaho. At hindi sa palagay ko na iyon ay natural na pumunta sa aking relational database vendor muna. At pagkatapos, idagdag mo ang iba pang mga kulubot dito, kung saan, kung ano ang magagamit sa ulap? Kaya maraming mga tao ang nais na makuha ang kanilang mga database sa premise. Pagkatapos ay kailangan mong tingnan ang iyong provider ng ulap at sabihing, "Okay, ano ang iyong tagapagbigay ng serbisyo, kung ano ang mga database na magagamit mo para sa akin na akma sa aking mga pangangailangan at kung paano maligtas ang mga ito, at lantaran kung ano ang rate o singil para sa paggamit ng database na iyon sa ulap bawat oras, o bawat araw. At bawat gigabyte o terabyte? "At kung ano ang makikita mo ay marahil ang ilan sa mga medyo mas bagong database tulad ng Mongo o Cassandra, marahil ang kanilang mga rate ay mas mura, kaya kung gagawa ka ng maraming uri ng data na malaking petabyte, maaari mong kailangang - mula lamang sa kinatatayuan ng gastos - kailangang isaalang-alang ang mga database ng NoSQL sa ulap dahil maaaring sila ang pinaka-epektibong paraan upang gawin ito.

Robin Bloor: Oo, tama. Ibig kong sabihin, ang aking uri ng - ang bagay tungkol sa mga nakabatay na mga database sa aking karanasan - na kung saan ay sapat na mahaba ang pagkakaroon ng mga scars, sigurado - mayroong maraming pangkaraniwang kahulugan na kung simulan mong ilapat ito at - nauunawaan mo kung ano talaga ang relational, , Ang ibig kong sabihin, naalala ko ang pagpunta sa ilang pagkonsulta sa isang customer minsan, at pinangunahan nila ako sa isang silid at nakagawa sila ng isang uri ng diagram ng nilalang at lumikha ng isang pangatlong normal na porma, isang modelo ng kung ano ang mga pangunahing sistema ng kumpanya. Mayroon itong dalawang daan at apatnapu't talahanayan tungkol sa at sinabi nila, "Well, ano sa palagay mo iyon? Magtatayo kami ng isang database para dito, "at sinabi" Ano sa palagay mo iyon? "Sinabi ko, " Hindi sa palagay ko ito gagana. "At eksaktong tama ito, alam mo, dahil natatapos na sila. upang lumikha ng partikular na istraktura sa loob ng labing-isang paraan na sumali. At iyon ang bagay na maiintindihan tungkol sa relational. Kaya't ako ay uri ng interesado sa mga tuntunin ng kung gaano kalaki ang hindi magandang disenyo na nakatagpo mo. Ibig kong sabihin, wala akong anumang problema sa DBArtisan - ginagawa itong napaka-makatwirang mga bagay at ang katunayan na maaari mong ipakita sa maraming mga platform, sa palagay ko, ay kamangha-manghang - ngunit gaano ka nakakaharap doon kung saan ang isyu ng disenyo kung saan malulutas ng mga tao ang kanilang sarili ng lahat ng uri ng sakit ng puso kung bumaba sila sa isang schema ng bituin kaysa sa pagkuha ng snowflake-y tungkol dito, alam mo?

Bert Scalzo: Well, hindi ko nais na tunog tulad ng, mapangahas o mayabang, ngunit mas madalas kong sasabihin kaysa sa hindi. Maliwanag, ang karamihan sa mga database na nakikisali ako doon, mayroon silang mga isyu o problema. Alin ang mabuti, dahil ang aming mga tool, tulad ng aming tool sa database optimizer, ay makakatulong sa kanila upang malutas ang mga problemang iyon, at, ngunit kung ano ang talagang nakakatawa sa akin, na ang maraming mga problema ay ang parehong simpleng mga problema nang paulit-ulit. Nagtatrabaho lang ako sa isang customer sa ibang araw na may isang labing-isang paraan na sumali sa query, at tulad ko, "Okay, bakit hindi ka gumagamit ng isang sugnay?" At sila ay tulad ng, "Well, ginawa ko alam ko kung ano iyon. "At pagkatapos ay sinabi ko, " At tingnan ang iyong mga sub-pinili dito sa iyong correlated at iyong hindi correlated, "sabi ko, " Sa ilang mga kaso mayroon ka sa kung saan ang sugnay sa pinakamalalim na antas, isang form ng sanggunian sa talahanayan ang panlabas. "Sinabi ko, " Iyon, ilipat ito sa tamang antas, huwag i-embed ito nang mas malalim kaysa sa dapat na ito, malito mo ang nag-optimize. "At sa ilang mga pag-tweak namin kinuha ng isang bagay na tumatakbo ng tungkol sa dalawang oras at nakuha ito hanggang sampung minuto at ito lang - sa kasong iyon wala kaming ibang ginawa maliban sa pagbutihin ang SQL na kanilang isinulat. Sa palagay ko ang problema ay ang maraming mga unibersidad at maraming tao na natututo ng pagprograma sa isang di-pang-akademikong kapaligiran, natutunan nila ito bilang naitala na mga proseso ng oras o proseso na nakaayos na nakakasunod-sunod at relational ay isang set na nakatuon sa kalikasan, at sa gayon ikaw kailangang mag-isip sa mga set upang magsulat ng mahusay na SQL.

Robin Bloor: Oo, sa palagay ko, tama iyon. At kailangan mong maunawaan, ito ay mga bagay tulad, nararapat na malaman ng mga tao ang mga ABC ng mga bagay na tulad nito. Hindi mahalaga. Hindi mo magagawang magawa ang mga nakapangangatwiran na mga bagay kung hindi mo napagtanto na kahit isang mahusay na dinisenyo, mahusay na modelo ng database, sumali ay magkakaroon ng oras, magkakaroon ng oras ang mga uri. Ginagawa nila ito dahil ang mundo ay hindi pa nakahanap ng isang paraan upang mapabilis ang mga iyon. Natagpuan nila ang mga paraan ng pag-aayos ng data kaya mas mabilis silang pumunta kaysa sa kabilang banda, at maraming sigasig na dapat kong sabihin para sa mga database ng NoSQL ay simpleng iniiwasan nila ang paggawa ng mga sumali. Simulan lamang nila ang pagbuo ng mga database na may parehong pagkalat ng data sa kanila, dahil kung sumali ka sa alinman sa mga database ng NoSQL na sinuso nila nang malakas. Hindi ba sa tingin mo?

Bert Scalzo: Oh ganap. At kailangan kong tumawa dahil, nagsimula ako pabalik bago ang mga database ng relational at pabalik kapag ang Ingres ay RTI, Relational Technology Institute, at wala kaming SQL, mayroon kaming mga pre-SQL na mga wika sa pakikipag-ugnayan. Sa tingin ko sa Ingres, pabalik noon, tinawag itong Quel. Kaya nakakuha ka mula sa mga lumang paradigma ng database tulad ng network at isang mas mataas na graphical, o hierarchical, at dumaan ka sa mga relational paradigms pagkatapos ng ilang dekada at ngayon sa akin nararamdaman kong babalik tayo sa halos isang hierarchical muli. Halos parang nagbaliktad kami.

Robin Bloor: Oo, tama. Mas mahusay na ibigay ka kay Eric, gumugugol ako ng maraming oras, ngunit mayroon ba kaming anumang mga katanungan mula sa madla, Eric?

Eric Kavanagh: Gawin namin, mayroon kaming ilang. Medyo matagal kaming pupunta dito ngunit itatapon kita ng isang pares. Mayroon kaming ilang mga katanungan sa paligid ng mga hindi nakikita index. Ang isang tanong ay, "Kailangan bang gamitin ng isang tao ang iyong tool upang makita ang mga iyon?" Ang isa pang tanong ay, "Well, paano kung bulag ka?"

Bert Scalzo: Magaling yan.

Eric Kavanagh: Nagtataka ring tanong, kaya FYI lang.

Bert Scalzo: Hindi, hindi mo kailangang magkaroon ng aming mga tool. Iyon ay isang tampok na Oracle, ang index ng invisibles. Karaniwan sa diksyunaryo ng data, pinapanatili lamang ng Oracle ang isang piraso ng metadata na nagsasabing, "Optimizer, huwag pansinin ang index na ito. Narito, ngunit maliban kung ikaw ay pisikal na itinuro sa pamamagitan ng isang pahiwatig sa, isang pahiwatig ng optimizer sa utos ng SQL, huwag gamitin ito. "At sa gayon, hindi, hindi mo kailangang magkaroon ng aming mga tool, at sa bawat paggalang nito. ay isang payak na old index, makikita mo ito sa anumang tool, ito lang ang sasabihin ng optimizer, "Babalewalain namin ito sa normal na pagproseso ng query." Kailangan mong idirekta kung nais mo itong masanay. Ito ay talagang madaling gamiting para sa senaryo na inilarawan ko na kung, kung nais mong magtayo ng isang index sa paggawa ngunit hindi panganib na masira ang mga ulat, o ang mga bagay na tumatakbo na, ngunit nais mong subukan ang mga ito, magagawa mo ito. Iyon ang pinaka-kapaki-pakinabang para sa.

Eric Kavanagh: Magandang bagay iyon at pagkatapos ay mayroong isa pang magandang katanungan dito. "Ano ang tungkol sa ilan sa mga bagong mga memorya na mga database? Paano binabago ng teknolohiya ng database ng memorya ang laro patungkol sa pag-index? "

Bert Scalzo: Boy, well kami - ngayon mabuti na, natutuwa ako na may nagtanong sa tanong na iyon, kailangan nating pumunta ng isa pang kalahating oras. Hindi, ang nasa memorya, nakasalalay ito sa nagbebenta ng database. Ngayon, normal, ako, wala akong sinasalita kundi papuri sa anumang ginagawa ng Oracle dahil kamangha-mangha ang teknolohiyang kanilang itinayo, ngunit kapag napunit ka sa ilalim ng mga pabalat at tiningnan mo kung ano ang nasa memorya sa Oracle, sa Oracle database, kung ano ang katotohanang ito ay pinananatili pa rin ang hilera store sa disk, at makakakuha ito ng mga naka-load na haligi-store sa memorya, at kung walang sapat na memorya upang hawakan ang buong talahanayan, babalik ito sa mga bahagi; hindi ito akma sa memorya, sa paggawa nito ng tindahan ng hilera, at sa gayon maaari kang gumawa ng isang pagpipilian laban sa mesa at para sa kalahati ng mesa, gumagamit ka ng isang pag-index ng pagpindot sa tradisyonal na mga hilera sa talahanayan, at para sa iba pang kalahati ng ang pipiliin ay talagang lalabas at daklot lamang ang lahat mula sa isang paghahanap sa memorya, at iba pa, naiiba ito sa paraan na ipinatupad ito ng SQL Server, sa kanilang teknolohiya ng Hekaton, alam mo, at SQL 2014, at napabuti ito sa SQL 2016, ngunit sa ilang mga aspeto, sa kanila ay isang mas totoong bersyon ng in-memorya, at, ngunit ang bawat pagpapatupad ay may kalamangan at kahinaan, ngunit kailangan mong uri ng hitsura sa ilalim ng mga takip at mapagtanto. Sapagkat, mayroon akong isang customer na nagsabi, "Oh ang talahanayan ng talahanayan na ito - Kukunin ko lang ang lahat ng mga index, " at tulad ko, "Ang talahanayan ay mas malaki kaysa sa memorya na mayroon ka sa server, kaya sa ilang mga punto ang ilan sa mga query ay nakuha sa hit disk. "

Eric Kavanagh: Magandang paglalarawan iyon; buti na lang. Buweno, mga tao, magkakaroon kami ng ilang mga webcater kasama ang mga taong ito sa natitirang taon, babalik sa anumang oras na maririnig mo si Bert na nasa isang pagtatanghal dahil alam namin na alam niya ang kanyang mga bagay. Palaging masaya na makipag-usap sa mga eksperto. Ginagawa naming i-archive ang lahat ng mga webcasts na ito para sa pagtingin sa paglaon. Narito muli ang impormasyon ng contact ni Bert, at susubukan naming maghukay ng link na iyon para sa pag-download at ipadala ito pati na rin sa pamamagitan ng email, ngunit maaari mong palaging i-email ang iyong tunay na:, nakakuha kami ng maraming mga webcater na may linya para dito taon at ginagawa namin ngayon ang ed cal, kaya, mga tao, kung mayroong anumang mga paksa na nais mong marinig tungkol sa susunod na taon, huwag mahiya: Mag-ingat, mga tao, makikipag-usap kami sa iyo sa susunod. Paalam.

Kasosyo sa Nilalaman ng Techopedia

Ang Staff ng Techopedia ay kaakibat ng Bloor Group at maaaring makipag-ugnay gamit ang mga pagpipilian sa kanan. Para sa impormasyon kung paano kami nakikipagtulungan sa mga kasosyo sa industriya mag-click dito.

• Profile
• Website