Tartalomjegyzék:
A Techopedia munkatársai, 2016. október 5
Elvihető: A házigazda Eric Kavanagh az adatbázis-indexelést Dr. Robin Bloorral, Dez Blanchfield-rel és az IDERA Bert Scalzo-val tárgyalja.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Techopedia tartalompartner
A Techopedia munkatársai kapcsolatban állnak a Bloor Csoporttal és kapcsolatba léphetnek a jobb oldali lehetőségekkel. Kattintson ide az ipari partnerekkel való együttműködésről.- Profil
- Weboldal
Eric Kavanagh: Hölgyeim és uraim, helló, üdvözlöm még egyszer. Szerda van, négy órakor keletre, és azok közül, akik ismerik a programot, tudják, mit jelent ez, itt az ideje a Hot Technologies újabb epizódjának. Igen valóban. Eric Kavanagh vagyok, a mai ülésszak moderátora vagyok: "Index őrület: Hogyan kerüljük el az adatbázis káoszt." Vagy amint arra utaltam az utolsó e-mailes robbanás során, hogy kimenjen: „adatbázis botlik.” Forró kifejezés manapság: „kócos”. Mindenki megteszi. Van egy dia az önről. És elég rólam.
Tehát a Hot Technology sorozatot valóban arra tervezték, hogy meghatározza egy adott helyet, szemben a Briefing Room-rel, amely csak egy-egy élő elemzői eligazítás, a Hot Tech számára két elemzőt kapunk. Ma a saját orvosunk, Robin Bloor és adattudósunk, Dez Blanchfield leszünk. És egy olyan témáról beszélünk, amely szerintem valóban meglehetősen emblematikus ahhoz, ami a mai piacon zajlik.
A lényeg az, hogy manapság bonyolult világban vagyunk. Valójában, ha tizenöt, vagy húsz évre visszatekintünk, akkor akkor egy rendkívül eltérő világ volt, különösen az adatbázis-technológia vonatkozásában. Az adatbázisok régen meglehetősen egyszerűek voltak. Csak maroknyi volt; többségük relációs volt. Most megvan ez az egész adatbázis-technológiák. Szó szerint az asztalon lévő lehetőségek sokasága azok számára, akik alkalmazást akarnak készíteni, vagy adatokkal megtenni valamit. Minden változik, és ez érinti az embereket, akik megpróbálják kezelni ezeket a rendszereket. Ma beszélünk Bert Scalzo-val, aki igazi szakértő a területen; ő az IDERA vezető termékmenedzsmentje arról, hogy mit tehet az összes ilyen adat kezelése érdekében. Ezzel átadom doktor Robin Bloornak, hogy elvegye. Robin, a padló a tied.
Robin Bloor: Oké, köszönöm a bevezetést. Azt hiszem - mivel ez kétkezes dolog, úgy gondolom, hogy általában csak az adatbázis-optimalizálásról szólnék, mint a Hot Tech show bevezetésének. Az életet kezdtem - a technológiában és az elemzésben - azért kezdtem ezt az életet, mert cikkeket írtam az adatbázisok képességeiről a DEC VAX platformon. És ezért az adatbázis-kiadók röviden ismertettek engem. És az a dolog, ami ilyen történik számomra az, hogy miért lenne egy adatbázisa? Úgy értem, akkoriban szörnyű sok ember készített kulcsfontosságú fájlokat, és azokat felhasználta, hogy egyfajta indexszekvenciális tévedés legyen, ahogyan nevezzük, hanem egyfajta adatbázis-képesség létrehozására, és tudja, miért lenne akármi más?
És erre a válaszra, azt hiszem, Michael Stonebraker adta a legjobb választ erre, és azt mondta: "Az adatbázis többet tudhat arról, hogy hol vannak az adatok, és hogy milyen gyorsan tudják azokat megszerezni, mint bármelyik program tud valaha." És azt hiszem, ez érdekes; ez a játék természete. De a 19 - jó körülbelül 1989-ben, amelyet a technológiai elemzésben kezdtem, és tudod, abban az időben az adatbázisok nagyon egyszerűek voltak, a relációs adatbázisok pedig rendkívül egyszerűek voltak. Olyan kevés képességük volt, úgy értem, nyilvánvalóan tudtak adatokat tárolni, és Ön is készíthet biztonsági másolatot, és nekik is voltak ACID-kompatibilisek, de valójában nagyon gyenge optimalizálóik voltak. Valójában nehéz azt állítani, hogy egyáltalán rendelkeznek-e az optimalizáló képességgel.
És később csak egyre jobbak lettek, de tudod, amikor egy adatbázis nem működik - mivel ezek a kengurók úgy tűnnek, mint egy vagy más módon, - szörnyű sok oka lehet annak, hogy miért lassul. És ez rávilágít: az adatbázisoknak sok funkciója van, de a legfontosabb a lekérdezés optimalizálása. Ha nem tették meg, akkor nem használnák őket. Arról van szó, hogy gyorsan megszerezzük az információkat, és ha egyszerre több felhasználó van, akkor ez is nehéz probléma. És ha ténylegesen megnézzük, hívjuk érett adatbázisoknak, ha tetszik - de természetesen az Oracle, kissé kisebb mértékben a Microsoft SQL Server, természetesen a Teradata és a DB2 -, amelyek ezen adatbázisok optimalizálói rendelkeznek, évtizedek óta a épület. Tudod, nem - valaki nem ült le - hat srác egy két férfira, egy évre, egy projektre, és csak összeütköztek. Ez nem működik így. Az optimalizálási képesség fokozatosan nőtt, és sok növekedést igényel. Mindenesetre beszéljünk az adatbázis hátteréről. Rendkívül sokat mondtak már a NoSQL adatbázisról, sőt még nagy lelkesedéssel bír a grafikon adatbázis. És az SQL használata a Hadoop felett és hasonló dolgok. De az igazság az, hogy ha most egy adatbázist szeretne, ha teljesen működőképes, OLTP-re képes és nagy lekérdezés-forgalmat szeretne, akkor ez egy relációs adatbázis, vagy semmi.
A relációs adatbázisok között az Oracle uralja a népszerűségét. A Microsoft SQL Server, azt hiszem, a második. Mindkettő alkalmas az OLTP és a lekérdezés munkaterhelésének felhasználására, de valójában nem tud megszabadulni a munkaterhelések keveréséről. Különböző eseményekre van szükség az OLTP-munkaterheléshez és a lekérdezés-munkaterheléshez. Vannak alternatívák az SQL és a gráf számára. A legtöbb vállalat szabványosítja egy adott adatbázist, ezért - úgy értem, hogy évtizedek óta harcoltam ki az összes többi szereplővel, az Oracle lett a domináns. Egyszerűen azért, mert végül képesek voltak eladni a vállalati engedélyeket, és így a vállalatok csak kivételes termékekben használnának alternatív termékeket, az Oracle egyszerűen nem tenné őket. És az adatbázisok stratégiai szempontból abban is fejlődnek. És tudod, hogy végeztem egy kicsit kutatást a bemutató elõtt, és ez olyasmi - el fogok nézni egy darabig, de az a fajta érdekes, hogy hogyan alakulnak tovább, a DBA helyzetébõl nézve. Ezt hívom a láthatatlan trendnek. A Moore törvénye kockára vágott. Nagyjából így: A legnagyobb adatbázis, és új adatbázisok, nincs olyan régi adatbázis, amely sokkal több adatot tudna bevenni. Ez általában egy adatbázis, amelyet új problémára alkalmaznak. És valójában növekszik az adatmennyiség. Nagyjából a Moore kocka mellett törvény. Tehát Moore törvénye hatévenként tízszeres tényező. A VLDB-k általában hat évente ezer tényezővel növekednek. 1991-ben és 1992-ben a nagy adatbázisokat megabájtban mérik. '97-ben és '98-ban, gigabájt. 2003, '4, terabyte. 2009, '10, elkezdted látni a petatabátus adatbázisokat. Azt hiszem, valószínűleg egy vagy két exabitát tartalmazó adatbázis létezett ott, de a legnagyobb, amiről hallottam, a 200 petatate időben, és tudod, hogy az adatok nem kerülnek petabita adatbázisba. De ez nyilvánvalóan az új nagy web 2.0 cégek lesz, valószínűleg, ha a Facebook ebbe az irányba mutat.
De egyébként, ha ezt ténylegesen megvizsgálja, elvárva, hogy egy adatbázis végigmenjen az ilyen jellegű eszkaláción, ez nagyon sokat kér. És figyelemre méltó, hogy valószínűleg egészen a petabita szintjéig, ésszerűen jól teljesítettek. Úgy értem, inkább a régebbi termékekről beszélek, mint bármi újról. Úgy tűnik, hogy rendkívül jól teljesítettek. Ha az adatbázis teljesítményét, a szűk keresztmetszeteket tekintjük, ez visszatér ahhoz az időhöz, amelyben én tényleg törődtem velük, és aggódnom kellett rájuk. Tudod, hogy ez alapvetően a hardver bontása. Vannak CPU szűk keresztmetszetek, lehetnek memória szűk keresztmetszetek, valószínűleg vannak lemez szűk keresztmetszetek. Lehet, hogy a hálózat bánatot okoz, és a zárolással kapcsolatban is problémákat vethet fel, attól függően, hogy mit csinál, de általában azért van, mert a program nem tudja, kinek kell lezárnia. Tehát, ha egy adatbázist hangol, akkor valójában megpróbálja úgy hangolni, hogy az tíz lehetséges szűk keresztmetszet között táncoljon, amennyire csak képes. És ez nem egyszerű kérdés, mert drasztikusan megnő az a memóriamennyiség, amelyet bármilyen kiszolgálón konfigurálhat. Akkor a CPU-k többmagos, lemezesekké váltak, és most már meg tudjuk csinálni, azt hiszem, még árupszervereknél is azt hiszem, hogy száz és száz terabyte-ot tudsz megtenni, negyedévben a petabájtot, talán még árupiasztó kiszolgálón is. Tehát ezekkel a dolgokkal játszhatsz, a hálózat természetesen eltérő sebességgel haladhat, de leginkább, ha adatbázisokkal foglalkozik, akkor valóban azt akarja, hogy szálas kábelek legyenek a szerverek között, és semmi más nem fut rajta, különösen úgy.
Az adatbázis teljesítményének tényezői. Úgy értem, kihagyom, mi ez az egész, mert tudom, hogy Dez erről beszél, de a rossz adatbázis-tervezés egy rosszul teljesítő adatbázist jelent. A rossz programozási terv azt jelentheti, hogy egy nagyon hülye SQL-t eldob egy adatbázisba, ami szörnyen sokkal tovább tart. Párhuzamosság és a munkaterhelés keverése, a túl sok párhuzamosság szűk keresztmetszeti problémákat okoz. A munkaterhelés-keverés, ha nagy lekérdezések vannak nagyon kicsi, rövid, éles lekérdezésekkel, ez problémákat okoz. Van egy terheléselosztási kérdés. A legtöbb adatbázis ezt vigyázza, de ha még nincs kifinomult termék, akkor tudod, hogy csak néhány kiszolgáló hozzáadása nem minden, amit tesz, ha valóban meg szeretné növelni a klaszter méretét. Az optimális teljesítmény elérése érdekében tényleg meg kell egyensúlyoznia a terhelést. A kapacitástervezést meg kell tennie. Teljesen. Különösen manapság, amikor az adatmennyiségek drámaibb növekedést mutatnak, mint az adatbázisokhoz régen. És egész adatréteggel kapcsolatos problémák merülnek fel azzal, hogy miként veszi be az adatokat, hogyan mozgatja az adatokat. Az adatok időben történő eljutása az adatbázisba később teljesítményprobléma lehet, mivel a Windowsban működő adatbázisokról huszonnégy-hétről hétszáz-hetvenöt műveletre mentünk, és nincs olyan ablak, ahol lelassíthatjuk a adatbázis le van állítva, vagy nem valószínű, hogy manapság ilyen lesz.
Az Oracle DBA probléma. Erre gondoltam. Az Oracle DBA-ban voltam az Oracle 7-nél, és emlékszem, hogyan kell ezt beállítani. És ha valójában most az Oracle-re nézi, akkor az út, út - van út, még több képesség. Megvan a bitképes indexelése és hasonló dolgok, de valójában időt vettem arra, hogy megvizsgáljam és megnézem, hogy jelenleg hány hangolási paraméter van egy Oracle adatbázisban. És több mint háromszázötven hangoló paraméter van, és van még száz rejtett paraméter, amelyekről a speciális DBA-k tudnak, de a normál Oracle DBA-k nem tudnak. És ez azt jelenti, hogy az ilyen típusú adatbázis hangolása nehéz feladat. Ez egyáltalán nem egyszerű dolog. Meg kell érezni ezt, hosszú-hosszú idő óta kell csinálnia, és pontosan meg kell tudnia, hogy mi a probléma, amelyet Ön szerint megold, mert a hangolás akkor kezdődik, amikor a a teljesítmény gyenge lesz, de lehet, hogy nem mindent teljesít. Lehetséges, hogy bizonyos lekérdezések végrehajtása, és javíthatja ezt bizonyos adatok és memória rögzítésével, vagy indexeléssel kell javítania, vagy máskülönben el kell kezdenie a particionálást. Sok minden, amit megtehetsz, az a lényeg. Tehát következésképpen nem fogják ezt megtenni a fejükben - a DBA-knak eszközökre van szükségük. Most továbbadom Deznek, aki szerintem elmondja neked az indexelést.
Eric Kavanagh: Rendben Dez, vedd el.
Dez Blanchfield: Köszönöm, Robin, és szeretem a borítólapot. Azt hiszem, ott dobta le a kesztyűt, hogy nekem még távolról is eljöhessen valami izgalmas dolog. De felhasználtam egy képet a kis galaxisunkról, ahogyan az az adatbázis-adminisztrátorok mai kihívásává vált véleményem, mert ez a mentális kép inkább felébreszteni, amikor egy környezetbe kerülek, és már nem vagyok többé az adatbázisok adminisztrálásának vagy adatbázisok ezen a szinten történő tervezésének világában. De önhöz hasonlóan, Robinnal és én évek óta részt veszünk az adatbázisok világában, akár adminisztrátorként, akár fejlesztőként, vagy végül építészként, és aztán rájöttünk, hogy jobb dolgokat tehetek a kéreg keresése érdekében. De általában úgy érzi, hogy ezt az adatok galaxist bámulja, és még inkább ma, amikor - amint azt már rámutattunk - a megabyte-ról petatabátokra és exo-skálára megyünk nagyon rövid idő alatt, a dolgok nagy rendszerében. De az a véleményem, hogy az a véleményem, hogy az adatbázis-indexek most fekete művészet, és nem igazán olyan fajta cucc, amelyben a halandóknak valamilyen módon el kellene száguldniuk, vállalati szintű üzleti alkalmazásokhoz és az, hogy milyen formában fogalmaznak meg csak beszéltek. De szerettem volna gyorsan átgondolni azt a történelemtípust, amely az adatbázis-világokkal kapcsolatban volt, és összehozni azt a kontextust, ahova következtetéseket vonunk le, majd áttekinteni néhány anyagot ma barátaival a IDERA, mert szerintem nagyon sok más gondolkodás történik arról, hogyan lehet az adatbázis teljesítményének hangolását elvégezni, és egyikük ón dobása a dolgokra. Sok olyan üzlet esetében, ahol találkozom, mindig nem jutnak el arra a pontra, hogy teljesítmény-hangolást végezzenek az adatbázis-rétegen, és különösen az indexrétegen, amíg átjutnak a nehéz gondolkodási útvonalon, hogy rá tudnak dobni egy hangolót. .
Sokan csak gondolkodásom szerint nagy érzelmi megközelítést alkalmaznak erre, és itt van egy képet a The Flash-ről, mert ha valaha néztek valamilyen régi filmet vagy minden bizonnyal a legfrissebb TV-műsort a Flash-szel, mint a Flash Gordon, a régi karakter, és most, hogy „The Flash” -nek hívják, hajlamos nagyon-nagyon gyorsan megy, és mindig energiája elfogy. És ez történik, amikor nagy vasat dob az adatbázis teljesítményére. Mindig, tapasztalataim szerint, nagy teljesítményű és kemény munkát tehet a játékban, optimalizálhatja operációs rendszereit és beállíthatja őket egy adott pontra. Gondoskodhat arról, hogy gyors többmagos, többszálú CPU-k legyenek, hogy az alkalmazás gyorsabban működjön, rengeteg RAM-ot dobhat el rá, nagy teljesítményű háttérképeket hozhat létre, a merevlemez-meghajtóktól a merevlemezek gyorsítótárazásához átállhat szilárd állapotba., és nagy teljesítményű tároló tömb. És még most is az emberek olyan dolgokat dobnak be, mint például a flash és az NVMe az adatbázis-motorjaikba, arra gondolva, hogy ezt a bejelentkezési alkalmat kétszer fogják megszerezni. És mindig megkapnak némi nyereséget. De mindez ugyanazokhoz az alapvető teljesítmény-hangolási problémákhoz vezet vissza. Sok alacsony késleltetésű hálózati kapcsolat, így a fürtök gyorsan működnek. És az adatbázis-infrastruktúra fürtözésével, tehát nem csak egy, az összes munkát végző géppel rendelkezik. De általában visszatér ugyanahhoz az alapvető teljesítményproblémahoz, azaz az adatok olvasása. Az adatok írása nagyrészt meglehetősen lineáris kihívás, és hacsak nem hajtják végre megfelelően.
És akkor van kihívásunk a mai világban: Nem minden adatbázis hoz létre egyenlőt. Vannak adatbázisok és idézettel idézett „adatbázis”. És amikor az adatbázis-motorokra gondolunk, az emberek gyakran gondolkodnak a hagyományos, szokásos gyanúsítókkal, mint az SQL világában. Tudod, megvan az Oracle és a Microsoft SQL Server, és van egy pár körül a MySQL nyílt forráskódú világában, amely most az Oracle tulajdonában van, de még mindig nyílt forrású. És akkor megvannak a nem szokásos gyanúsítottak, a NoSQL motorok, amelyeknek továbbra is kérdése van az indexelés és a teljesítmény menedzsment területén, és nem foglalkozom velük részletesebben, de ezek egyre több minden nap felbukkanó dolgok vannak, és úgy néznek ki és érzik magukat, mint az adatbázis-motorok a fejlesztők és a teljesítmény szempontjából, ám nagyon-nagyon különféle vadállatok, és van saját kis résük a világon, hogy kivágják memórián belüli teljesítmény vagy lineáris skála a lemezen. De a világ úgy néz ki, mint az adatbázis-világban. Ez a 2016-os, ez a térkép harmadik verziója azon emberek körében, akik elkészítik ezt a folyamatban lévő tájképet, hogy miként néznek ki az adatbázisok, és ez az, ahol - még egy emberfeletti adatbázis-építésznek vagy adatbázis-adminisztrátornak sem lenne értelme belőle. Szó szerint több száz, és száz, és több száz különböző gyártmányú modell, modell, adatbázis-gyártó, változatlanul az SQL-kompatibilis. És az érdekes, hogy mind ugyanazon kihíváshoz térnek vissza. A teljesítmény és a teljesítmény hangolása az adatbázis-motor körül, különös tekintettel az adatok indexelésének módjára.
Tehát csak gyorsan fedezzük fel az adatbázis-indexelést, mert ez egy érdekes téma, és be kell gondolnom, hogy részletesebben bele kell foglalkoznia a bemutatóval. De azt hiszem, hogy meglehetősen elfogadott és a szokásos iparági gyakorlat szerint az adatbázis-index teljesítményének hangolása az, ahol a világ kezdődik és végződik, mindaddig, amíg az Ön adatai gyors és gyors formátumban elérhetők. De mi az adatbázis indexelése? Ha arra gondolunk, hogy az indexelést olyan formában végezzük, amelyhez szoktuk, mint mindennapi ember, gondoljunk egy könyv indexoldalára. Ha valamit szeretne találni egy könyvben - különösen egy enciklopédia kedvelőit, vagy valami hasonlót, mint valamilyen formájú referencia anyag -, ha valami hasonlót keres ezen az oldalon, ahol olyan dolgokat keresek, mint például a gátak témája egy enciklopédia. Minden utalást szeretnék találni a gátakra, a vízgyűjtődésre és egy nagy ember által létrehozott nagy építési területre. Megyek hátul, és ábécézett, rendezett listában találom, A-tól Z-ig, balról jobbra, és D.-t fogok találni. Megtalálom a „damok” szót, és ezt látom 16., 38., 41. oldal, ott van hivatkozás rájuk, majd elmehetek azokra az oldalakra, le tudom szkennelni a szemem, és megtalálom a „gát” szóra való hivatkozást. Ez lényegében ugyanaz a fogalom egy adatbázisban, de ez most sok szempontból egy rakéta tudomány. Annyira, hogy gyakorlatilag minden adatbázis-adminisztrátor, akit valaha is jól megismertem, úgy véli, hogy az indexek az egyetlen kritikus eszköz a teljesítmény hangolásához bármely adatbázis-világban, függetlenül attól, hogy milyen tapasztalataik vannak, ha ónra dobják, vagy bármi is legyen az eset.
Általában, amikor adatbázis-indexelésről beszélünk, számos általános megközelítés létezik. És minél bonyolultabb adatbázis-indexeket kap, annál bonyolultabb az adatok indexelésének megközelítése. De alapvetõen, amikor az adatok indexelésére gondolkodik - képzelje el, hogy van egy fájlunk, amely nevnevet tartalmaz; Lehet, hogy nem sorolhatók ábécé sorrendben. Képzeljük el őket húsz. Ha válogatni fogunk - ha adatokat keresünk a listából, felülről lefelé, és mondjuk, hogy ez egy névlista. Ha egy véletlenszerű nevet választom, és elkezdem görgetni ezt a listát, felülről lefelé, lineáris formában, és ez egy rendezetlen lista, két kritérium van, amelyekre gondolok, mint az átlagos keresési idő és a maximális keresési idő - és A második sorban elíróm van, legyen „maximális keresési idő”, sajnálom - de az átlagos keresési időm lényegében N plusz egy, osztva kettővel, és ez átlagosan az idő ötven százaléka. beolvasni a lista tetejéről, a lista aljára, hogy megtalálja a listában szereplő véletlenszerű dolgokat. És a második sornak, a lineáris alatt, „maximális keresési időnek” kell lennie. De a maximális keresési idő lényegében az elemek száma, vagyis ha húsz dolgom van egy listammal, akkor a legtöbb időbe telik. ha valamit keresünk az adatbázisban, akkor fentről lefelé kell mennünk, azaz tegyük fel, hogy ebben az egyszerűsített példában 20 elem található. És ez egy nagyon lassú folyamat, és tényleg nincs mód arra, hogy a teljesítmény ezt beállítsa. És akkor léteznek másfajta módok is ezen adatok begyűjtésére és egy index létrehozására, amely gyakorlatilag azon mutatók rövid listája, ahol a tényleges adatok megtalálhatók, például bináris, B-fa, bitkép, hashing, fürtözött és nem fürtözött, és akkor különféle típusú adatok léteznek, például térbeli, szűrt, XML és teljes szöveg.
A bináris fájlok nagyon gyakran használhatók olyan dolgokhoz, amelyekben az adatok felhasználhatók. A B-fa valószínűleg az általános értelemben a leggyakoribb egyetlen, történelmileg abban az értelemben, hogy általános módszer az indexek bármilyen formájú struktúrálására, és lehetővé teszi a naplózókat, a kiválasztásokat, valamint a beszúrásokat és törléseket viszonylag egyszerűen, amikor a mutatókat a hivatkozás a mutatókra, a pontokra. Vannak más típusok is, például a bitmap, ahol az adattípusok olyanokra vonatkoznak, mintha valamilyen formához társított tartományunk lenne. A hashing nagyon jól használható nagy objektumokhoz, különösen blogokhoz és képekhez. És láthatja, hogy számos különféle tudományos megközelítés, matematikai megközelítés létezik az adatok indexeléséhez. A puszta halandók számára érdekes kihívásnak számítanak ezen a szinten. Ha teljesítményszinten beszélünk róla egy adatbázis-adminisztrátorról, valójában rakétatudósssá válnak, és az emberek fokozatot szereznek bennük, és tudom, hogy Robin Bloor orvos ezt bizonyosan megtette, és könyveket írt róla az IBM és más nagy márkák az elmúlt néhány évtizedben. És tehát - véleményem szerint - tényleg elmúltunk egy olyan időpontra, amikor egyszer tudod, hogy én személyesen képes lennék ülni egy rendszer előtt, és széthúzhatnám, és megmutathatnám pontosan ott, ahol a teljesítményproblémák a parancssorban vagy a grafikus felhasználói felület indító eszközénél voltak, és elkezdtek belemerülni az adatokba, és megmondhatják, hol vannak a problémák, és ehhez indexeket, alindexeket, vagy elsődleges és másodlagos mutatókat építhetnek bele adatokat, és elkezdi használni dolgokat. De amikor erre a tájra gondolsz, megmutattam nektek, ahol száz és száz márka, gyártó és modell, valamint gyártó és típusú adatbázis van, és jól és valóban túl vagyunk az időben, most, ahol az ember képes az adatbázis-motorok típusának megértése. Különösen akkor, ha visszatérünk az Oracle kedvelthez, manapság az uralkodó márkák a relációs adatbázis platformokon.
Azon adatbázisok száma, amelyekkel saját tulajdonú platformon, például ERP vagy HR, vagy pénzügyi rendszeren keresztül kell kezelniük, vagy különféle okok miatt otthoni sütésű platformnak kell lenniük, az adatbázisok és az adatbázis-táblák és a nyilvántartások száma, amelyek végén a dolgok csak csillagászati, és fizikailag nem tudod kézzel megcsinálni. És most még egy további bonyodalommal bírtunk, amikor egyszer az adatbázis-kiszolgáló csak ül az asztalod alatt. Tudod, hogy egy fiatal gyerekként az iskola után szoktam dolgozni az adatbázis-szoftverekkel az eredetileg az Apple IIes, majd a DOS PC alapú rendszereken, mint például a dBase II, a dBase III, egy nagy korszakon ment keresztül mainframe-ekkel és középkategóriákkal. tartomány és akár VAX-ok és PDP-k, és naplófájl. És hasonlóan Saberhez, majd végül, amikor az SQL-adatbázisok közül néhány megjelent. De manapság, amikor az adatbázis-motorokra gondolunk, úgy néznek ki, mint a bal alsó sarok. Az adatbázis-kiszolgáló nem csak egy, a földön egy asztal alatt ülő gép; gépek százai futtatják az adatbázis-hajtóművek és klaszterek másolatát, és akár száz és több terabyte adatot is skálázhatnak, ha nem petabájtnyi adat, ezer ezer terabyte. És még a végső soron is, amint azt Robin Bloor doktor megemlítette, hogy egyes speciális felhasználási esetek - különösen a légitársaságok, különösen a kormányhivatalok - eljuthatnak exabitákba. Még mindig meglehetősen niche-y, de több száz terabájt és akár több tucat petatata már nem szokatlan, különösen a dotcom fellendüléséig, a mai napig, amit web 2.0 cégeknek hívunk, a Facebook, a Google, a Yahoo kedveli. és így tovább.
Arra is bonyodalmunk van, hogy a dolgok külső szolgálat felé mozognak. Infrastruktúra-platformot és szoftvert kínálunk, mint infrastruktúra-szolgáltatási megközelítést. Különösen platformszolgáltatások, ahol nem csak vásárolhatunk az Oracle kedvelt termékeire, azok felhőplatformjára, adatbázisaira és szervereire. Ez lehetővé teszi számunkra, hogy az alkalmazás nagyon gyors fejlesztését elvégezzük, és csak egy adatbázist dugjunk vissza a szerverre. Nem kell gondolkodnunk arról, mi van a motorháztető alatt. A hátránya, hogy gyakran nem gondolkodunk azon, hogy miként tervezzük és valósítsuk meg az adatbázist, amíg az nem sérül, és a teljesítmény nem jelent problémát, majd végül a megfelelő eszközt kell keresnünk annak diagnosztizálására, hogy mi okozza az adatbázisunkat, és ahol a teljesítmény kérdései vannak. És változatlanul visszahozza azt a közös problémát, hogy hogyan indexáltuk az adatokat és az indexek típusait, amelyeket az adatokhoz használtunk, és ez visszahozza az emberfeletti teljesítménykövetelményt. És valaki, aki hozzáfér a megfelelő rendszerekhez és a teljesítményhez szükséges megfelelő eszközökhöz, beállítja ezeket a motorokat, és elkezdi megtalálni a forró pontot, és megnézheti, hol vannak a lekérdezések, hol az adatok mozognak, a lekérdezések típusai, a lekérdezések felépítése, ki csinálja a lekérdezéseket, és hogy a lekérdezések sorban vannak-e, és gyorsítótárban kell lennie. Milyen replikációt keres?
És tehát - véleményem szerint - jól és igazán jól vagyunk abban a pillanatban, amikor még a világ legjobb adatbázis-gurujjaira is, alapvetően adatbázis-tervezőinkre és adatbázis-adminisztrátorainkra és teljesítménybázisunkra, véleményem szerint nagyon fontosnak kell kezdeniük a megfelelő eszközök kiaknázását. bármilyen adatbázis-motor számára optimális teljesítménymutató hangolást biztosít. Mivel az általunk vizsgált méretarány és a sebesség, amellyel a dolgok haladnak, egyszerűen nem tudjuk kézzel csinálni, és ezt mindig megkísérelve más teljesítményproblémákat vezethetünk be, mert előfordulhat, hogy nincs tapasztalata abban a térben, amely próbálunk egy problémát megoldani. És azt hiszem, hogy itt fogunk kezdeni Bertnek, és arról fogunk beszélni, hogy miként oldták meg ezt a változatos problémát, és hogy milyen típusú dolgokra képes eszközük csináld, különösen az Oracle világában. És ezzel, Bert, átadom neked.
Bert Scalzo: Köszönöm. Üdvözöljük mindenkit, Bert Scalzo vagyok, az IDERA-nél dolgozom. Néhány adatbázis-termékünk vezető termékmenedzsere vagyok. Ma bemutatom ezek közül néhányat. De indexekről akarok beszélni, mert egyetértek mindennel, amit mindenki mondott, különösen az utolsó dián, hogy az indexek annyira összetettek, hogy szükség van egy eszközre, és remélem meggyőzni. Tehát az Oracle index kialakítása nem olyan egyszerű, mint régen. Sok ember nem biztos benne, ha megvizsgálja a lehetőségeket, és szeretem ezt a mondatot, hogy kihúzódtam a történelemből: „ezekben az ügyekben az egyetlen bizonyosság az, hogy semmi sem biztos.” És így vagyok ilyen. érdekli az indexeket manapság, mert még ha úgy gondolja, hogy tudja a választ, ha X, Y vagy Z indexelést igényel, akkor nem lehet biztos benne, amíg meg nem próbálja, mert ezek az optimalizálók néha eltérően viselkednek, ahogy várták. Tehát nagyon sok próba és hiba van az index-kialakításban. A régi jó időkben, ha szüksége volt egy indexre, általában csak két kérdés vagy egy kérdés volt. Egyedülálló volt, vagy nem volt egyedi? És talán más dolgokra gondolhatott, például: „Hány indexet lehet legfeljebb egy táblán?”, Mert túl sok index lelassítja a betéteket, frissíti és törli. Lehet, hogy az adatbázis-rendszerben is volt, korlátozásokkal rendelkezett arra vonatkozóan, hogy hány oszlop lehet egy több oszlopos indexben, mivel néha voltak korlátozások az adatbázis motorjának oldal- vagy blokkméretén alapulva, de a valóságban ez elég egyszerű volt a régi jó időkben. Vagy indexelte, vagy nem. És valójában minden B-fában volt. Engedélyezhetjük-e a másolatokat, vagy sem, és erről volt szó. Az élet jó volt, az élet egyszerű.
Nos, az élet nem olyan jó vagy olyan egyszerű. A vörös Ghostbuster jelet áthelyeztük a szokásos módon, mert most van B-fa versus bitmap, versus bitmap join. És el fogom magyarázni, hogy ezek közül néhány egy pillanat alatt fennáll. Fürtözött és nem csoportosítva, egyedi vagy másolatai, előre vagy fordított sorrendben, funkcióalapú, particionált vagy nem particionált. Ha van partíció, akkor globális vagy helyi particionálás? Ezt el is magyarázom. És akkor van még valami, amit indexelt szervezett táblának hívnak. És valójában fél tucat másik van, akiket itt hagytam, mert szerintem már elég itt van, hogy meggyőzze Önt arról, hogy az indexek sokkal szigorúbbak, mint gondolnád. Ebben a konkrét diaban a diagram bal felső részén indulok, és van egy táblázatom. És az első dolog, amit el kell döntenem, az adatbázis verziójától és az adatbázis gyártótól függően, engedélyezik-e az objektumtáblákat vagy csak relációs? Megyek a jobb oldalon, és azt mondom, hogy relációs táblát építünk. Most a következő kérdést kell feltennem magamtól: egy klaszterben van? És sokan, akik egy ideje végzett az Oracle szolgáltatással, emlékezni fognak arra, hogy a klaszterek visszatértek az Oracle 6 napjáig. Ma valószínűleg nem használják túl erősen, de előbb engedjék le ezt az ágat.
Ha a táblámat egy klaszterbe szeretném tenni, akkor fürtözött indexnek kellene lennie abban a táblában. Most, az Oracle-ben, amikor egy táblát csoportosított, alapvetően a sorokat tárolta, vagy a sorok egymáshoz közel álltak, ahol az értékek hasonlóak voltak. Tehát, ha van egy fürtözött index, akkor a fürtözött index nem lehet particionálva. Más szavakkal, valójában nem volt olyan particionálási módszer, ahogyan egy fürtözött táblázatot tennék. Szigorúan nem volt megosztva. És mivel nem volt particionálva, globális volt. Egy perc alatt elmagyarázom, mi a globális. És mindig B-fa volt. Más szavakkal, amikor lementem az ágon, ez elég egyszerű volt, nem volt sok választásom. Most, ha nem fürtözött indexet készítettem egy fürtözött táblán, amely bizonyos verziókban megengedett volt, megint nem volt particionálva; ha nincs particionálva, akkor az egyetlen választásod globális. Tehát ott van a B-fa vagy a bitmap választása. Ez ismét az adatbázis verziójától függött. De most térjünk vissza a relációs táblázathoz, és kezdjük újra lefelé a jobb oldalon, és most egy egyszerű, régi, szabályos, halmozott táblázatot kapunk: relációs. Asztaltérben lesz. Először a jobb oldalon megyek le. Tehát ez szervezés, halom. A következő kérdés, amelyet fel kell tennem magamtól: „Szeretnék particionálni ezt a táblát, vagy nem?” Most néha szétválná, mert azt gondolta: „Hé, az optimalizáló okosabb lesz abban, hogy miként tudja optimalizálni a lekérdezéseket. "De sok DBA-k azt fogják mondani neked, hogy az okad adminisztratív célokat szolgál. Ha van egy százmilliárd soros táblája, ha partíciókra vagy vödrökre bontja, amikor az utolsó vödörhez adatot szeretne hozzáadni, akkor csak néhány millió sor eldobható és indexelhető. Beillesztheti ezeket az adatokat, majd újraépítheti az indexet csak arra a vödörre.
Míg ez jó módszer volt néhány olyan optimalizálási technikára, mint a partíciók eltávolítása, valódi értéke az volt, hogy kisebb darabokon adminisztrálni vagy adminisztratív feladatokat tudott végezni. Amikor elmegyek a szervezeti kupacba, az első kérdés a következő volt: „Osztottam fel, vagy sem?” Menjünk balra, nem fogom megosztani az asztalt. Most furcsának tűnhet, ha ezt elmondom neked, de lehet nem particionált táblázata, és akkor nem oszthatja szét az indexet, amellyel megszokta, vagy feloszthatja az indexet. Álj meg és gondolkozz. A táblázata alapvetően egy vödröt tartalmaz, ahogy mindig is gondoltad, és az indexednek azonban több vödör lesz. Amikor ez megtörténik, ahol eltérés van a vödrök és az asztal száma, valamint az index vödörjeinek száma között, akkor ez a globális fogalom. Tehát, ha a táblázat nincs particionálva, és ha az index particionálva van, akkor globálisnak tekintjük, mert eltérés van. Most hadd menjek vissza a szervezeti halomra, és ehelyett a partíciós oldalra jöjjek le. Most, ha van egy partíciós táblám, és mondjuk, hogy a táblázatnak négy vödörje, négy partíciója van, az indexemnek négy vödörben lehetne, így az indexe megegyezik a táblatervezésemmel. És tehát vége, jobbra a végén. Ezt helyinek tekintik. A helyi index alapvetően azt jelenti, hogy a tábla és az index particionálása ugyanúgy történik, és azonos számú vödörrel rendelkezik. És ha egyszer megvan a helyi index, akkor lehet B-fa vagy bitkép, és az a zöld nyíl, amely ilyen módon felmegy, megmutatja, hogy még ha B-fa is, még mindig vannak választási lehetőségek. Lehet, hogy függvény-alapú. És ha bitmap is van, akkor különböző típusú bitképek is vannak. Van valami, amit bitmap join indexnek hívnak. Ha adattárolást végez, akkor ez egy nagyon népszerű index a csillag séma vagy a terv számára. Ami történik, hogy az indexnek meg kell adnia a sor azonosítóit, amire mutat a táblában, de a szülő tábláknak is sor azonosítókat kell tartalmaznia, így amikor Ön - meg kell csillagolnia a séma kialakítását, és egy ténytáblázatnál az a ténytáblázatban szereplő mutató azokra az adatokra mutat, amelyek érdekli, és a dimenziók minden sorára mutat, így csak egy mutatóval kell rendelkeznie.
Valójában ez a Red Brick miatt jött létre, amely sok évvel ezelőtt volt egy adatbázis - sok ember emlékszik erre. És tehát, ha ezt a képet nézi - és ne feledje, nem mindent tettem ebbe a képbe, mert a kép sokkal nagyobb lenne -, vannak még további kérdések, amelyek itt vannak a szövegben a jobb felső rész felett . Ez fordított sorrendű index? Ön azt mondhatja: „Miért akarok fordított sorrendű indexet? Ennek nincs értelme. ”Nos, ha az Oracle fürtözött környezetében vagy, ha valódi alkalmazásfürtöket végez, ha az indexeit rendben tartja, tehát nem megfordítva, ha rengeteg feldolgozással rendelkezik, ami üt ugyanazok az értékek vagy ugyanazok az index értékek, mi történne, ha meleg területei lennének a B-fának. Ez azt jelenti, hogy vitatkoznod kell és esetleg reteszel, hogy megpróbáld elérni ezeket a dolgokat, és ezt egy hálózat csomópontjain keresztül csinálod. Nos, ha fordított sorrendű indexet helyez be, akkor ezt visszavonhatja. Ön azt mondhatja: „Nos, a fák különböző részein hasonló értékek vannak, tehát nincs külön csomópontom, amely a fák forró területein versenyezne.” És aztán azt is észreveheti, hogy az egyedi nem működik egyes lehetőségekkel. . Ha megnézed, akkor három, öt, nyolc és tizenegyet sorszámoztam, tehát vannak olyan esetek, amikor nem lehet egyedi index. Hasonlóképpen, vannak olyan esetek, amikor nem tudok fordított indexet létrehozni, és akkor további problémák merülnek fel, például naplózás vagy nincs naplózás, párhuzamos és nem párhuzamos. Tudom hozzárendelni a dolgokat egy bizonyos területhez a memóriában.
És ez még mindig elég sok funkciót kimarad az Oracle-ben. Azt mondanám, hogy amikor az Oracle 12-re nézel, valószínűleg megint körülbelül egy tucat új dolgot tudok hozzáadni ehhez a képhez. Az indexálás nagyon bonyolult, és tényleg egyetértek az előző felszólalóval, hogy ezen a navigáláson és a jó döntés meghozatalához eszközre van szüksége. Valószínűleg szükség van egy ilyen képet, és valamilyen módszertant arra, hogy miként választja ki a dolgokat, és remélhetőleg az eszköz segít odajutni. És akkor próba és hiba lesz. Az indexeléskor mindig az embereknek azt mondom, hogy „nézz, mielőtt ugrálsz”. És láthatja itt a kis kutyát, úgy néz ki, hogy keres, ugrik a cápa vízbe, vagy a srác felkészül arra, hogy a vízbe ugorjon., és meg fogja hatni magára. Gondolkodnia kell az indexelésedre, mert az index létrehozása nem mindig azt jelenti, hogy a dolgok javulnak. Az index létrehozása valójában lelassíthatja a dolgokat. És a lekérdezés teljesítménye nagyságrenddel nagyobb lehet, ha az egyik választható a másiknál. És jó példát hozok neked. Ha csillagvázlatot készít, és a mérettáblázatain egy esetben bittérképes mutatókat használ, és egy másik esetben azt mondja: “B-fa indexeket fogok használni”, akkor bittérképet kap a B- fa. Megmondhatom neked, hogy az egyik megoldás nagyságrendű, vagy esetleg több nagyságrendű gyorsabb lesz, mint a másik. De ne feledje, hogy mi működik egy környezetben, például az adattárolási környezetben, valószínűleg nem jó választás egy OLTP környezetben.
Például, ha tranzakciós táblát venne, és bitmap indexeket helyezne egy tranzakciós táblára, akkor drága kiszámítani és alaphelyzetbe állítani a bitképeket, ezeket a hosszú karakterláncokat, és így egy OLTP táblában annyira sújthatja a táblát, hogy a bitmap Az index megsérülhet, és lelassíthatja a rendszert, mert csak nem a frissítésekre szánják őket. Nagyszerűek a gyors hozzáféréshez, de nem alkalmasak a frissítésekre. Azt hiszem, hogy az index kipróbálást és hibát igényel. Valójában nincs aranyszabály - túl sok különböző változó van ebben az egyenletben ahhoz, hogy tudjon - és végül meg kell nézni a végrehajtást, vagy meg kell magyaráznia az adatbázisban lévő terveket, hogy megnézze, jó választásokat hajt végre. És néha a terv elemzése szinte tudomány lehet önmagában. Ma nem foglalkozom vele - ez egy másik téma -, de az indextervezést nem veszem biztosnak. Jogos okok vannak arra, hogy miért vannak ezek az őrült index típusok, amelyeket az előző képben mutattam neked, és amelyekről az előző beszélő beszélt. Ezeket nem csak azért hozták létre, mert ügyes volt az, ha ellenőrző listát készítettek valahol egy adatbázis-szolgáltató számára; vannak olyan használati esetek vagy forgatókönyvek, ahol ezek az indexek fontosak, és jelentős különbséget fognak hozni. Most ezzel bemutatom néhány példát a különféle típusú indexekről az egyik eszközünkben. Hadd tegyem fel a képernyőmet, hogy láthassa. Oké, tehát itt ülök - hadd minimalizáljam ezt az alkalmazást. A virtuális gép belsejében ülök, és Windows Server 2012 virtuális gépet futok.
És láthatja, szinte minden szerszámom van az ember számára. Termékmenedzserként tisztában kell lennem a versennyel, tehát nem csak az, hogy milyen eszközök vannak, hanem mit tesznek a versenytársaim? És itt van ez a DBArtisan nevű eszköz, amelyet már futtam, de megyek - szóval csak előhozom. És amit láthat, ez egy igazán szép eszköz, mert használat helyett mondjuk az Oracle vállalati menedzserét és az SQL Management Studio az SQL Server számára, valamint a MySQL Workbench for MySQL és tizenkét másik adatbázisunk számára, amelyeket támogatunk, Nos, az összes adatbázisomat beépítettem ebbe az eszközbe. Van egy DB2, ott a MySQL, az Oracle, a Postgres, az SQL Server és a Sybase, és ez az - csak hat adatbázisom van ebben a konkrét dologban, mert nem tudom - az eszköz támogatja tizenkét adatbázist, de a szegény virtuális gépét, egyidejűleg hat adatbázis futtatását és próbálkozását. demo elkészítése nagyjából annyit tesz, mint a hardverem. Tehát hadd menjek vissza az Oracle-hez, és ha észreveszed, ezek a dolgok azonosak. Ha meg akarom mérni a teljesítményemet a DB2-ben, ugyanazok a lehetőségek vannak, mint az Oracle-ben. Most a borítók alatt rengeteg különféle dolgot csinálunk, így nem kell tudnia, hogy mi folyik, de adunk egy következetes felületet, így szakértő lehetsz több adatbázis-platformon. És ez magában foglalná az indexekkel való munkát, a vita témáját.
Hadd jöjjek ide, és először kezdjek nézegetni néhány táblát, és van egy film-adatbázisom, amelyben csak néhány tábla található. És ha úgy nézek ki egy adott asztal, mint például az ügyféltábla, amikor ide hozom, láthatom a tábla kialakítását, itt vannak az oszlopok a táblázatomban, és itt vannak információk az egyes oszlopokról. Megvan a tulajdonságai a táblázathoz, de vegye figyelembe, hogy itt van egy lap az indexekhez, és láthatom, hogy itt vannak az asztali indexek. Vegye figyelembe, hogy ezen indexek egyike a PK-indexem, az elsődleges kulcsom. Ezek a többi csak indexeknek tűnnek a lekérdezéshez való hozzáférés javítása érdekében, esetleg keresztnév vagy vezetéknév alapján keresünk, vagy telefonokat és irányítószámot keresünk. És ha kiválasztom egy adott indexet, például ezt a irányítószámot, és kétszer rákattintom, akkor most látom, hogy hé, ez nem egyedülálló index, és itt van néhány más típus, bitmap, nem egyedi, egyedi, függetlenül attól, hogy rendezve van-e, függetlenül attól, hogy a naplózás történik-e, függetlenül attól, hogy fordított sorrendben van-e, függetlenül attól, hogy funkcionális alap. Ó, itt van egy szórakoztató, amit nem fedeztem fel. Valójában láthatatlan indexek is lehetnek. És azt mondanád: „Nos, mi az ördögért akarok láthatatlan indexet csinálni?” Nos, jó példát fogok adni. Ön a termelési rendszerben van, és teljesítményproblémája van, és nem biztos benne, hogy az index létrehozása meg fogja javítani a problémát, ezért nem az index létrehozását és a termelés lelassítását szeretné, hanem valahogy, vagy a másik képes legyen tesztelni. Létrehozhatja az indexet a termelésben láthatatlanul, vagyis nem sok alkalmazáskódot használ, amely az optimalizálót hívja fel. Létrehozta, érvényes, de nem fogja használni. Akkor elvégezhet egy olyan lekérdezést, amelyről úgy gondolja, hogy ez az index segíthet, vagy egy lekérdezés sorozatát, és ragaszkodhat egy tippre, és mondhatja: “Hé, optimalizáló, ott van egy láthatatlan index, amit ki akarok használni és engedni tudom, hogy javítottam-e a dolgokat. ”És most teszteltem valamit a termelésben, de nem szakítottam meg a gyártásban futó alkalmazásokat. Ez egy láthatatlan index használata. Némán hangzik, amikor először hall róla, de ennek van értelme.
Az indexeknél meghatározhatjuk, hogy párhuzamosak-e, és azt is, hogy hány példányban vannak párhuzamosak az egész. Most, nem fürtözött vagy nem valós alkalmazásfürt környezetben, tehát nem rackként, a párhuzamosság azt jelentené, hogy hány alfolyamatot tud felhozni a lekérdezésem, hogy megpróbáljam, és a munkavégző folyamatokat, hogy megpróbáljam megoldani valamit gyorsabban vagy gyorsabban . És párhuzamos példák lennének, ha egy valódi alkalmazási klaszterben vagyok, mondjuk, hogy tíz csomópont van, hány csomópontra hagyhatom felosztani a munkát? Talán ez a tízből négy, és mindegyikükön négy alfolyamat. Ez egy példa. És akkor megvan a kulcs-tömörítés. Valójában tömörítheti az indexeket? Igen vagy nem. És akkor természetesen megvannak a tárolási paraméterei, amelyeket megadhat az indexeknél. Most nem foglalkoztam velük, mert valójában inkább tárolási paraméterek, mint indexkiadások. És végül, meg kell döntenünk, hogy ezeket particionáljuk-e vagy sem. Hadd dobjam el ezt egy pillanatra. Megyek egy másik séma. Ez egy csillag séma, és például ez az időszak táblázat egy dimenziós táblázat. Ha valaha is készített csillag sémát, akkor általában rendelkezik egy dimenzióval az időhöz, tehát ebben az adatbázisban és a csillag sémában az időszak egy idő dimenzió. Nos, tudom, hogy viccesnek fog mondani, azt fogja mondani: „Gyere, nézd meg ezeket az oszlopokat - hallott már valaki a srácról a normalizálásról?” Nos, amikor adattárházban vagy csillag-séma-kialakításban vagy, általában nem olyan táblázata van, amelyet egy tipikus ember megnéz, és azt mondja: „Gyere, ezek nem túl jól megtervezett”. De ez az, amit adattárolási környezetben csinálsz.
Most nézzétek meg, mi fog történni, mert oké, vannak ezek az oszlopok, nézd meg, minden oszlophoz van indexem. Most egy OLTP környezetben, amely nem-nem lenne. Ez lelassítja az összes műveletemet. Adatraktározási környezetben a kötegelt töltési ciklusok alatt eldobnám őket. Töltsön meg felül vagy az indexek nélkül, és én újra létrehozom az indexeket. És ha particionáltam a táblámat, akkor ahelyett, hogy el kellene dobnom az indexet a táblázat minden vödörére, el tudtam dobni az indexet a vödörre vagy vödrökre, ahol az adatok belemennének az adott kötegelt betöltési ciklusba. És akkor hozza létre újra csak az indexet azokra a vödrökre. És így nagyon kezelhetővé teszi. És ha megnézem - itt van egy „Üdülési zászló” oszlop, és alapvetően ez igen vagy nem. Ne feledje, hogy ez egy bitmap index, és a legtöbb embernek azt fogja mondani: “Nos, ennek van értelme.” Igen vagy nem, I vagy N, csak két értéknek van értelme. És mivel az, amikor elolvassa a bitmap indexek dokumentációját, mindig azt mondják, hogy válasszon valamit alacsony kardinalitással.
Most hadd menjek be az egyik ténytáblámba, tehát itt vannak megrendeléseink. És ez a napi rendeléseim. És most látni fogod, hogy ismét nagyon sok oszlopom van, és ismét nekem több index is lesz. És itt van valami, az úgynevezett univerzális árkód. Ez egy kiskereskedelmi üzlet számára volt, tehát ismeri ezeket a kis vonalkódokat, amikor vásárol valamit a boltban, ez az univerzális árkód. Most több millió univerzális árkód van. Most arra a cégre, amely cuccokat árusított, valószínűleg 1, 7–2 millió egyetemes árkód volt, tehát arra számíthat, hogy ez nem lesz bitmap-index, mivel 1, 7 millió különálló érték nagyszerűségnek hangzik. De a valóságban egy adattárolási környezetben azt akarja, hogy ez egy bitkép legyen. Hadd magyarázzam meg miért. Nos, lehet, hogy 1, 7 millió különbözõ érték van ennek az univerzális árkódnak, az ebben a rendelési táblázatban a sorok száma százmillióktól milliárd sorig terjed. A mutatóm alacsony kardinalitású, az asztal méretéhez vagy kardinalitásához képest. Ez alacsony kardinalitássá teszi. Ez hasznosá teszi a bitmap-indexet, annak ellenére, hogy az 1, 7 millió különbözõ értékkel szemben ellenérzékeny, ha itt választaná meg a bitmap-et. Most, ha tudtam, hogy bitkép-csatlakozási indexet akarok használni, a termék jelenleg nem támogatja ezt, ezt hozzáadom a következő kiadáshoz, de ez itt egy másik alternatíva. És ne felejtsen el egy csillagsémában, hogy a bittérképes index a ténytáblán legyen, és hogy a B-fában az egyik mutató a ténytáblázat sorára, majd minden sorra mutatjon, amely az adott tény dimenziós táblájában látható volt. . És tehát van még egy lehetőségetek. És hát, lássuk, most ki akarok jönni a táblákból, és csak gyorsan meg akarom mutatni neked, hogy ugyanazok az információk vannak, indexek alatt, és ugyanazt az alapvető dolgot fogom csinálni.
Ez az oka annak, hogy felhoztam ezt, az lehet, hogy észreveheti, hé, itt nincs elsődleges kulcs. Az elsődleges kulcsok kulcskorlátozással készülnek, tehát valójában ezekre vonatkoznak a korlátozások meghatározásai. Ezek olyan indexek lennének, amelyek nem képezik részét a kényszernek. Most azt mondhatja: „Nos, várjon egy percet, amely idegen kulcsnak tűnik, és egy idegen kulcs kényszer”, de a külföldi kulcsok és a legtöbb adatbázis nem hoz létre automatikusan indexet a külföldi kulcs oszlopában, bár ez tanácsos, és oda megy - ismét ugyanazokat a lehetőségeket választottam. És ha csak tömörítés céljából akarok változtatni, megtehetem.
Most a tömörítés csak egy B-fa indexen működik. Amit ez lehetővé teszi, ha a B-fa különféle csomópontjait nézi, ez lehetővé teszi az egyes értékek tömörítését. Valójában nem olyan tömörítés, mint asztali tömörítés, hanem a B-fában a nem levélcsomópontokban tárolt adatok tömörítése. Nem takarít meg egy csomó helyet, de változást hozhat. És ezzel észrevettem, hogy nagyon közel vagyok az időhez, tehát azt akarom tenni, hogy vissza akarok térni, és abbahagyom a megosztást. És megvan a termékünk egy tizennégy napos próbaverzióra az idera.com oldalon. Ez egy nagyon jó termék, különösen, ha több adatbázis-platformon dolgozik. Ha két vagy három különféle adatbázissal dolgozik, ez az eszköz sokkal könnyebbé teszi az életét. Van olyan eszközünk, amely segít az index tervezésében és kiválasztásában, és van egy eszközünk, a DB Optimizer nevű eszközzel. Ezt csak ma nem tudtam fedezni, ez túl sok lenne. És ha kapcsolatba akar lépni velem, ott van az e-mail címem, vagy megtalálhatja a privát e-mail címemet, és van blogjaim, van egy weboldalam és blogjaim, valamint egy LinkedIn profilom. Tehát nyugodtan felkereshet velem bármit, még akkor is, ha ez nem a termékhez kapcsolódik, ha csak adatbázisokkal akar beszélni, nagyon szívélyes vagyok és imádkozom a technobabble iránt.
Eric Kavanagh: Rendben, nos, Dez, Robin, biztos vagyok benne, hogy mindegyiknek van legalább néhány kérdése, van néhány perc idejük. Dez, mit gondolsz?
Dez Blanchfield: Egy nagyszerű kérdésem van, amit fel kell tennem tőlem. A fejemben ül. Mi a legőrültebb forgatókönyv, amit látott? Elolvastam a blogod, szorosan nyomon követek téged - te valószínűleg egyike annak a kevés embernek, aki szinte minden valószínűtlenben élt, és szerintem Dr. Robin Bloor a második, akivel találkoztam életemben. De tudod, valószínűleg minden őrült forgatókönyvet is látott, melyek közül néhány a legőrültebb forgatókönyvek közül, amelyeket már láttam, és amelyekkel találkoztam, és mint az emberek, akik csak nem tudtak megbirkózni, akkor sikerült sétálnod és végre a Jedi gondolkodási trükköket ezzel az egész DBArtisannel?
Bert Scalzo: Egyszer volt egy ügyfelünk, aki az adatbázis-tervezés során nagyon sokat gondolkodott úgy, ahogy gondolkodni fognak a fájl elrendezésében, és így van - amikor normalizál egy adatbázist, az első dolog, amit megpróbálsz megszabadulni ismétlődő csoportok. Nos, volt egy oszlopuk, és hosszúból, vagy BLOB-ból vagy CLOB-ból készítették őket, és értéküket, első számú, pontosvesszőt, második számot, pontosvesszőt, értékszámot, pontosvesszőt adnák, és több ezer értékük lenne ott, de keresniük kellett ezen az oszlopon, és így gondolkodnak: „Miért fut ez a dolog olyan lassan?” És én olyan vagyok, mint: „Nos, nem hozhatsz létre indexet arra, amit csináltál, csak nem megengedett. ”Tehát a tervek felhasználásával megmutattuk nekik, hogy a táblázat normalizálására van szükségük. Nem azért, mert a normalizálás valamilyen tudományos feladat, amely javítja a dolgokat, hanem azért, mert egy lekérdezést akartak arra a mezőre, ami azt jelentette, hogy képesek voltak indexelni, és nem tudták indexelni egy ismétlődő csoporton, vagy legalábbis nem könnyű . És tehát ez valószínűleg a legrosszabb dolog, amit valaha láttam.
Dez Blanchfield: Igen, érdekes, hogy milyen gyakran találkozol, azt hiszem, kihívást jelent az adatbázisok, az emberek elfelejtik, hogy ez egy tudomány. És vannak olyan emberek, akik diplomát és PhD-t készítenek az egész térben, ráírnak papírokat, és egy egész szalagot írtál, beleértve a TOAD-kézikönyveket és másokat is a memóriából. Az a tendencia, hogy az idézetten idézzük a „nagy adatot” - sok ember látom, ha elfelejti az adatbázis-architektúra és az adatbázis-technológia, az adatbázistudomány alapjait, ha úgy tetszik. Mit lát a téren, ahogy a hagyományos adatbázis-platformoktól és a hagyományos adatbázis-gondolkodástól való elmozdulást tapasztaltuk, hogy ténylegesen a földre szögeztünk, és ez csak a teljesítmény hangolása és méretezése volt. Látod, hogy sok ember újraéled, és van tapasztalata, amikor csak ott ülnek, és van egy „a-ha” pillanat, mint egy eureka pillanat, amikor rájönnek, hogy ez a nagy adat cucc valójában csak egyfajta igazán nagy adatbázis? Ez valami odakint van, és az emberek visszaadnak és válaszolnak neked: "Elfelejtettük, amit tudtunk, és visszahozhatsz minket a sötét oldalról?"
Bert Scalzo: Nos, nem, és ez szörnyű, hogy ezt valamiféle be kell vallanom, de a relációs adatbázis-gyártók ezt a Kool-Aidot is megitták. Ha emlékszel, nem tudom, kb. Egy évtizeddel ezelőtt elkezdtük a nem strukturált adatokat relációs adatbázisokba helyezni, ami nagyon furcsa dolgot tett, majd az adatok, a relációs adatbázisok most hozzáadják a NoSQL-típust dolog. Valójában az Oracle 12, CR2 - tudom, hogy még nem jött ki -, de ha megnézi a béta-t, ha a bétaprogramban vagy, akkor támogatja a shardingot. Tehát most van egy relációs adatbázis, amely nem adta hozzá a NoSQL sharding koncepcióját. Tehát úgy tűnik, hogy az „a-ha” pillanat inkább azoknak a relációs oldalaknak szól, akik „a-ha-ra” lépnek. Senki sem fogja újra megtenni, még az adatbázis-kezelők sem, tehát át kellett menni és csatlakozni a sötét oldalhoz.
Dez Blanchfield: Igaz, tehát azt mondod, hogy sok minden rendetlen adat felé halad, ha jól értem, bekerülve a nagy adatplatformokra, amelyeket most hívunk, ami nagyon vicces, mert ők nem annyira régi, de ez nem azt jelenti, hogy akkor koncentrálnak arra, amit csinálnak a relációs adatbázisukkal, hogy minél több ütést kapjanak a pénzükért?
Bert Scalzo: Nem, általában, ha van rá szükségük - ez egy „nagy adattípusú igényt” idézne, mert úgy találják, hogy ahelyett, hogy el kellene menniük a másik adatbázis-platformra, és valami - Relációs módon, az adatbázis-gyártók most ugyanazokat a nem-relációs technikákat adják nekik a relációs adatbázisukban, hogy elvégezzék ezeket a dolgokat. Úgy értem, jó példa erre az, ha nem strukturált adatai vannak, például JSON-adattípus vagy más összetett adattípus, amelynek jelentése magában az adatba ágyazott, az adatbázis-gyártók nem csak támogatják, hanem ACID-t adnak a nem strukturált adatoknak való megfelelés. A relációs adatbázisok átvették az újabb technikákat és technológiákat, és úgy tűnik, hogy az „a-ha” inkább nem az, hogy „Hé, mi, az alkalmazásfejlesztők, valamit megtanultak, és meg kell tanulnunk újra”, ez „Hé, most így csináljuk, hogyan lehet ezt megtenni a hagyományosan relációs adatbázisban, és úgy csinálni, mint én itt az adatbázisban? ”És ez egyre gyakoribb, és amint mondtam, az adatbázis-gyártók maguk is lehetővé teszik hogy.
Dez Blanchfield: Igaz, kik a hagyományos gyanúsítottak ebben a térségben a DBArtisan szerszámhoz? Néhány házi feladatot elvégeztem azon, amit nemrég írtál, és a memóriából írtál valamit, azt hiszem, az egyik blogod volt az extrém adatbázis-teljesítményről az Oracle világában. Nem emlékszem, mikor volt, azt hiszem, valamikor ebben az évben emlékezetből, vagy a tavalyi év végétől írtad ezt a dolgot. És számomra úgy tűnt, hogy ez a tradicionális, szokásos gyanúsítás a mai témájú témában, ahol az emberek nagyon nagyszabású adatbázis-környezetbe mennek, és keresik, amit szélsőséges haszonnak hívnak benne. Kik azok a szokásos gyanúsítottak, akiket kint látnak, akik felveszik a DBArtisant és hasznosítják?
Bert Scalzo: Nos, nagyon sok ügyfelünk van, ma egy nagyon nagy kormányzati ügynökséggel voltam kapcsolatban, aki - és szó szerint valószínűleg közel 1000 példányban van a szoftverünk, mert lehetővé teszi az emberek számára, hogy arra összpontosítsanak, amit ők újra csinálni, és nem hogyan kell csinálni. És rendben van, úgy értem, hogy mindenkinek tudnia kell, hogyan kell valamit tenni, de a termelékenység megkapja a „mit”. Ha a vállalkozás felkéri egy feladat elvégzésére, akkor az mindannyian érdekli őket. Mikor kaptam egy pipa jelölést, hogy megmondjam, mikor hajtották végre a feladatot? Nem az, hogy milyen technikát vagy milyen technobabábot használtam odajutáshoz. Így eszközünk lehetővé teszi számukra, hogy összpontosítson rájuk, és sokkal eredményesebbé tegye őket. Ez valóban óriási előnye, és amint mondtam, egyes adatbázisok eszközöket kínálnak csak az adatbázis-platformjukhoz. Tizenkét adatbázis-platformon kínáljuk. Ugyanaz a munkafolyamat, ugyanaz a grafikus felhasználói felület, ugyanazok a navigációk. Ha tudja, hogy miként adhat privilégiumokat egy felhasználónak, vagy hogyan hozhat létre táblát, vagy hogyan lehet indexet létrehozni az adatbázisban, akkor megteheti mind a tizenkétben, mert ugyanaz a külső megjelenés, ugyanolyan munkafolyamat. Ennek óriási értéke van ügyfeleink számára.
Dez Blanchfield: Igen, azt hiszem, az emberek sokkal többet akarnak elérni a pénzükért az emberi erőforrásokból. És eltűntek azok a napok, amikor az Oracle, az Ingres és a DB2 számára egyéni szakember volt. Az emberektől elvárják, hogy minden üzlet Jack-je legyen, tehát azt hiszem, ez a dolog feltétlenül megmentette életét.
Csak egy utolsó gyors dolog, mielőtt átadtam volna Robin Bloor doktornak. Megemlítette, hogy tizennégy napig ingyenesen letölthető, mit jelent - ha megyek előre, és megteszem, ezt egyébként megteszem a Bloor tech laboratóriumba, és megpördíthetem ezt a dolgot felállni, és maga kezét kapni - a mai napig nem volt esélyem erre. Megemlítette egy tizennégy napos próbaverziót, azt mondta, hogy virtuális gépén futtatja a számítógépen, feltételezem, hogy ez egy laptop. Milyen, mi az a belépő szintű beállítás, hogy valaki megkapja a kezét és használja a tizennégy napos próbát, még mielőtt visszaadom Robinnak a kérdéseit?
Bert Scalzo: Bármely Windows környezet, tehát Windows 7, virtuális gép egy CPU-val és négy koncert memóriával. Nem vagyunk igazán kövér vagy drága eszközök. Most, ha az adatbázis-kiszolgálót ugyanazon a virtuális Gépen szeretné futtatni ugyanazon a Windows alatt, igen, akkor még többet kellene hozzáadnia, de ha az adatbázist adatbázis-kiszolgálón vagy külön virtuális gépen futtatja, akkor a betöltő és a virtuális gép A termék futtatása nagyon könnyű: egy CPU, négy koncert memória, nagyjából minden Windows verzió - és támogatjuk a harminckettő és a hatvannégy bites telepítést is. De telepítenie kell az adatbázis-gyártó ügyfélprogramját. Tehát ha csatlakozni kívánott az Oracle-hez, telepítenie kell az SQL net klienst, mert az Oracle ehhez szükséges ahhoz, hogy adatbázis-beszélgetést folytathasson.
Dez Blanchfield: Nagyon egyszerű. Úgy gondolom, hogy ebből az egyik dolog, ami remélem, hogy az emberek el fognak fogni, kivéve azt a felismerést, hogy ez az eszköz megmenti az életüket, az, hogy menjen le és töltse le, és játsszon vele, mivel egy tizennégy napos ingyenes próbaverziót kínálsz. És futhat a jelenlegi laptopjukon, anélkül, hogy bármilyen extra telepítést telepítenének, mert ha már végeznek adatbázis-adminisztrációt, akkor már dolgoznak az adatbázisokkal, megvannak az összes ilyen eszköz a helyükön, és függetlenül attól, hogy az egy helyi virtuális gépen vagy a helyi asztali számítógépen úgy tűnik, hogy fájdalmatlan a telepítés és a játék. Ezért nagyon ajánlom az embereknek ezt.
Robin, biztos vagyok benne, hogy kérdése van, és Eric, valószínűleg felvettek néhányat a közönségből, tehát Robin, mi lenne, ha átadom neked, majd vissza Ericnek?
Robin Bloor: Igen, rendben, jól van, amit mondani kell, úgy értem, mindig is izgalmasnak találtam ezt a területet, mert az volt - levágtam a fogaimat. De az igazság az, hogy valószínűleg mintegy 1998, 1999 óta elvonultam attól, amire az Oracle valójában képes. És tudtam, hogy a Sybase-t és a Microsoft SQL Server-t mindkettő meglehetősen egyszerű, összehasonlítva azzal, amit az Oracle tehet. Nevettek, amikor neked gondoltam - befejeztem a számat, amikor elkezdett beszélni a szilánkokról. Az Oracle ezt korábban is tette. Az Oracle bevezetése valamikor, ideges lett az objektum-relációs elképzelés miatt, így bevezették a képességet egyfajta objektum-jelölés és objektumtárolás létrehozására az Oracle-ben, és beszéltem az egyik mérnökömmel, valami hasonlóval évekkel azután, hogy bevezették, és megkérdeztem, hogy hány ember használta, és azt mondta, hogy szerintem két ügyfél kipróbálta, és ennyi volt. És azt hiszem, ugyanez fog történni, ha elkezdenek kipróbálni NoSQL dolgokat. Tudod, azt hiszem, hogy ez egy hiba, úgy értem, engem nagyon érdekel az a gondolatod. Természetesen: - iszik a Kool-Aidot. Úgy érzik, hogy képesnek kell lenniük a nagy NoSQL adatbázisokhoz hasonló állítások benyújtására, mint például a Cassandra, de tudod, van-e értelme számodra?
Bert Scalzo: Nem, közvetlenül a fejedre érted a szöget. Számomra azt szeretném, ha relációt fogok csinálni, egy relációs szolgáltatót választom, mint például Oracle, SQL Server, DB2 vagy Postgres, de ha valami nem relációs, a nagy adatterületen, vagy a NoSQL térben, kiválasztom a megfelelő eszközt a megfelelő feladathoz. És nem hiszem, hogy ez természetesen először a relációs adatbázis-szállítóm felé fordulna. Aztán hozzáteszi a másik ráncot, azaz mi elérhető a felhőben? Olyan sok ember szeretné, ha adatbázisát ki kellene állítania. Akkor meg kell néznie a felhő-szolgáltatót, és azt kell mondania: „Oké, mit szolgáltatsz, milyen adatbázis áll rendelkezésre számomra, amely megfelel az igényeimnek és mennyire értékesíthetők, és őszintén szólva, milyen mértékű vagy díjat fizet az adatbázis használata a felhőben óránként vagy naponta. És gigabájtonként vagy terabyte-ig? ”És amit talál, talán néhány viszonylag újabb adatbázis, mint például a Mongo vagy a Cassandra, valószínűleg azok aránya olcsóbb, tehát ha többpetabájt-típusú nagy adatokat fog készíteni, akkor valószínűleg - csak a költségek szempontjából - figyelembe kell venni a felhőben lévő NoSQL-adatbázisokat, mivel ezek a leginkább költséghatékony módszer erre.
Robin Bloor: Igen, igaz. Úgy értem, hogy az én típusú - a tapasztalatom szerint a relációs adatbázisokkal kapcsolatos kérdés - amely elég hosszú ahhoz, hogy hegek legyenek, ez biztos - nagyon sok a józan ész, hogy ha elkezdi alkalmazni és - megérti, hogy mi a reláció valójában, az Úgy értem, emlékszem, hogy egyszer tanácsot folytattam egy ügyféllel, és ők vezettek egy szobába, és egyfajta entitásdiagramot készítettek, és létrehoztak egy harmadik normál formát, egy modellt, amely a vállalat elsődleges rendszereihez hasonlított. Kétszáznegyven asztal körül volt, és azt mondták: „Nos, mit gondolsz erről? Építeni fogunk ehhez egy adatbázist. ”És azt mondta:„ Mit gondol erről? ”Azt mondtam:„ Nem hiszem, hogy működni fog. ”És pontosan így van, tudod, mert véget értek felfelé annak érdekében, hogy egy konkrét struktúrát hozzon létre a tizenegyes csatlakozásokon belül. És ezt kell megérteni a relációról. Tehát engem nagyon érdekel az a kérdés, hogy mennyi rossz tervezéssel szembesül. Úgy értem, nincs semmiféle problémám a DBArtisannel - nagyon értelmes dolgokat csinál, és azt hiszem, hogy tényleg több platformon is megjeleníthetsz, csodálatos - de mennyivel találkozol ott, ahol a formatervezés kérdése? ahol az emberek mindenféle szívfájdalmat el tudtak volna oldani, ha csillagrendszerre jöttek volna, és nem pedig hópelyhet szereztek róla, tudod?
Bert Scalzo: Nos, nem akarom, hogy zavargottan vagy arrogánsan hangzik, de többnyire mondanám. Nyilvánvaló, hogy azoknak az adatbázisoknak a nagy részében, amelyekbe bevonulok, problémák vagy problémák vannak. Ami jó, mert az eszközeink, mint például az adatbázis-optimalizáló eszköz, segíthetnek nekik a problémák megoldásában, és ami számomra nagyon vicces, az az, hogy sok probléma újra és újra ugyanaz az egyszerű probléma. A másik napon csak egy vevővel dolgoztam, aki tizenegy irányú csatlakozási lekérdezéssel rendelkezik, és így vagyok: „Oké, miért nem használta a záradékot?”, És ők olyanok, mint: „Nos, én nem "Nem tudom, mi ez." És akkor azt mondtam: "És nézzétek meg itt az al-kiválasztókat a korrelált és a nem korrelált között." Azt mondtam: "Bizonyos esetekben a legmegfelelőbb záradékod van, A táblázat referenciája a külső oldalról. ”Azt mondtam:„ Ez azt jelenti, hogy mozgassa a megfelelő szintre, ne ágyazza be mélyebben, mint amilyennek lennie kell, akkor összezavarja az optimalizálót. ”És néhány pár csípéssel elvitt valamit, ami körülbelül két órán keresztül futott, és tíz percre lecsökkent, és csak az volt - ebben az esetben nem tettünk semmit, csak az általunk írt SQL fejlesztését. Úgy gondolom, hogy a probléma az, hogy sok egyetem és sok ember, akik nem tudományos környezetben tanulják meg a programozást, rögzített időbeli folyamatokként vagy sororientált folyamatokként tanulják meg, és a reláció a természet orientált halmaza, és így Ön sorokban kell gondolkodnia a jó SQL írásához.
Robin Bloor: Igen, azt hiszem, pontosan így van. És meg kell értenie, hogy olyan dolgok vannak, hogy az embereknek tudniuk kell az ilyen dolgok ABC-jét. Nem számít. Nem fog tudni racionális dolgokat csinálni, ha nem veszi észre, hogy még egy jól megtervezett, jól modellezett adatbázishoz való csatlakozás is időt vesz igénybe, a válogatás időt vesz igénybe. Azért teszik, mert a világ még soha nem talált módot arra, hogy ezek gyorsan gyorsuljanak. Megtalálták az adatok megszervezésének módját, így gyorsabban haladnak, mint máskülönben, és a lelkesedés, amit mondanom kell a NoSQL adatbázisok iránt, egyszerűen az, hogy elkerülik a csatlakozásokat. Csak kezdik az adatbázisok felépítését, ugyanolyan adatterjedéssel járnak bennük, mert ha csatlakozol a NoSQL adatbázisok bármelyikéhez, akkor nagyot szívnak. Nem gondolod?
Bert Scalzo: Ó, feltétlenül. Nevetnem kell, mert visszaléptem a relációs adatbázisok előtt, és amikor Ingres RTI volt, a Relációs Technológiai Intézet, és mi nem rendelkezünk SQL-vel, az SQL-t megelőző relációs nyelvek voltak. Azt hiszem, akkoriban Ingres-ben Quelnek hívták. Tehát ezekből a régi adatbázis-paradigmákból származott, mint például a hálózat és egy magasabb grafikus, vagy hierarchikus, és néhány évtized után átment a relációs paradigmákból, és számomra úgy érzi, hogy visszatérünk majdnem a hierarchikushoz. Ez majdnem olyan, mintha visszatértünk.
Robin Bloor: Igen, igaz. Jobb, ha átadom Ericnek, túl sok időt veszek igénybe, de van kérdésünk a közönséggel, Eric?
Eric Kavanagh: Igen, van néhány. Egy kicsit tovább megyünk itt, de dobtok egy párot rád. Néhány kérdésünk merült fel a láthatatlan indexek körül. Az egyik kérdés a következő volt: „Használjon valakinek az Ön eszközét a látáshoz?” A másik kérdés az volt: „Nos, mi van, ha vak vagy?”
Bert Scalzo: Ez jó.
Eric Kavanagh: Kíváncsi kérdés is, tehát csak a FYI.
Bert Scalzo: Nem, nem kell, hogy rendelkezzen eszközökkel. Ez egy Oracle szolgáltatás, a láthatatlanok indexe. Alapvetően az adatszótárban az Oracle csak egy olyan metaadatot tárol, amely azt mondja: „Optimizáló, hagyja figyelmen kívül ezt az indexet. Itt van, de ha nem fizikailag utasítást kap az SQL-parancs optimalizálójára, az SQL-parancsban, ne használja ezt. ”És tehát nem, nem kell rendelkeznie az eszközöinkkel és minden tekintetben egy egyszerű régi index, láthatja bármilyen eszközben, csak az optimalizáló azt fogja mondani: “A normál lekérdezés-feldolgozásnál figyelmen kívül hagyjuk.” Ha irányítani szeretné, irányítania kell. Ez nagyon hasznos az általam leírt forgatókönyvhöz, ha ha indexet akar létrehozni a termelésben, de nem kockáztatja, hogy megsemmisíti a jelentéseket vagy a már futó dolgokat, de meg akarta kipróbálni, akkor megteheti. Erre a leghasznosabb.
Eric Kavanagh: Ez jó dolog, és itt volt még egy jó kérdés. - Mi lenne ezekkel az új, memóriában lévő adatbázisokkal? Hogyan változtathatja meg a memóriában lévő adatbázis-technológia a játékot az indexelés szempontjából? ”
Bert Scalzo: Boy, well we – now that's a good, I'm glad someone asked that question, we're going to have to go another half hour. No, the in-memory, it depends on the database vendor. Now, normally, I am, I speak nothing but praise of anything that Oracle does because it's amazing the technology they've built, but when you tear back under the covers and you look at what in-memory is in Oracle, in the Oracle database, what it is in reality is it still kept row store on disk, and it will get loaded column-store in-memory, and if there's insufficient memory to hold the whole table, it will revert back to for the portions; it won't fit in memory, to doing it row store, and so you could actually do a select against the table and for half the table, you 're using an indexing hitting traditional rows at the table, and for the other half of the select it's actually going out and just grabbing everything from an in-memory search, and so, it's different in the way that SQL Server, for example, implemented it with their Hekaton technology, you know, and SQL 2014, and it's been improved in SQL 2016, but in some respects, theirs is a more true version of in-memory, and, but each implementation has a pros and cons, but you have to kind of look under the covers and realize. Because, I had a customer who said, “Oh this table's in-memory – I'm just going to draw up all the indexes, ” and I'm like, “The table's bigger than the memory that you have on the server, so at some point some of the query's got to hit disk.”
Eric Kavanagh: That's a good description; that's good stuff. Well, folks, we're going to have a few more webcasts with these guys over the rest of this year, come back anytime you hear of Bert being on a presentation because we know he knows his stuff. It's always fun to talk to the experts. We do archive all these webcasts for later viewing. Here's Bert's contact information once again, and we'll try to dig up that link for the download and send it out as well by email, but you can always email yours truly:, we've got a bunch more webcasts lined up for this year and we're doing the ed cal right now, so, folks, if there's any topics you really want to hear about next year, don't be shy: Take care, folks, we'll talk to you next time. Bye-bye.
Techopedia tartalompartner
A Techopedia munkatársai kapcsolatban állnak a Bloor Csoporttal és kapcsolatba léphetnek a jobb oldali lehetőségekkel. Kattintson ide az ipari partnerekkel való együttműködésről.- Profil
- Weboldal
