Index šílenství: jak se vyhnout chaosu databáze

Od zaměstnanců Techopedia, 5. října 2016

S sebou: Host Eric Kavanagh diskutuje o indexování databáze s Dr. Robinem Bloorem, Dezem Blanchfieldem a Bertem Scalzem z IDERA.

Momentálně nejste přihlášeni. Chcete-li zobrazit video, přihlaste se nebo se zaregistrujte.

Partner obsahu Techopedia

Zaměstnanci Techopedia jsou spojeni se společností Bloor Group a lze je kontaktovat pomocí možností na pravé straně. Informace o tom, jak spolupracujeme s průmyslovými partnery, najdete zde.

• Profil
• webová stránka

Eric Kavanagh: Dámy a pánové, ahoj a znovu se vítáme. Je středa ve čtyři hodiny východní a ti z vás, kteří znají program, vědí, co to znamená, je čas na další epizodu Hot Technologies. Ano vskutku. Jmenuji se Eric Kavanagh, budu vaším moderátorem pro dnešní zasedání: "Index Insanity: Jak se vyhnout databázovému chaosu." Nebo jak jsem se zmínil v posledním e-mailové zprávě, abych šel ven, „databáze wrangling.“ V současné době je to „wrangling“. Je tu snímek o vás opravdu. A dost o mně.

Takže série Hot Technology byla skutečně navržena tak, aby definovala konkrétní prostor, na rozdíl od briefingové místnosti, která je pouhým briefingem živých analytiků, pro Hot Tech získáváme dva analytiky. Dnes to bude náš vlastní doktor Robin Bloor a náš datový vědec Dez Blanchfield. A mluvíme o tématu, které si myslím, že je opravdu docela symbolem toho, co se dnes na trhu děje.

Pointa je, že jsme dnes ve světě složitosti. Opravdu, pokud si vzpomenete na patnáct let nebo dvacet let, byl to tehdy úplně jiný svět, zejména s ohledem na databázové technologie. Databáze byly docela jednoduché. Bylo jich jen hrstka; většina z nich byla relační. Nyní máme celou řadu databázových technologií. Doslova desítky možností na stole pro každého, kdo chce vytvořit aplikaci nebo udělat něco s daty. Všechno se mění a to ovlivňuje lidi, kteří se snaží tyto systémy spravovat. Dnes si promluvíme s Bertem Scalzem, který je skutečným odborníkem v oboru; Je to vedoucí produktový management pro IDERA, o tom, co můžete udělat, abyste zvládli všechna ta data. S tím to předám doktoru Robin Bloorovi, aby to vzal. Robine, podlaha je tvoje.

Robin Bloor: Dobře, díky za úvod. Myslím, že to - protože je to obouruční věc, myslím, že bych jen mluvil o optimalizaci databáze obecně jako úvod k této show Hot Tech. Začal jsem život - v technologii a analýze - život jsem začal dělat, protože jsem psal články o schopnostech databází na platformě DEC VAX. Z tohoto důvodu mě spotřebitelé databází používali k tomu, aby mě informovali. A věc, která se mi tak stane, je to, proč byste měli databázi? Myslím tím, že v těch dnech strašně mnoho lidí používalo k vytváření souborů hodnot klíčů a používali je k tomu, aby měli jakousi indexovou sekvenční klam, jak jim říkáme, ale aby vytvořili určitý druh databázové schopnosti a víte, proč byste měli Něco dalšího?

A odpověď na to, myslím, že Michael Stonebraker dal nejlepší odpověď na to, a on řekl: "Databáze může vědět více o tom, kde jsou data a jak rychle je získat, než jakýkoli program může kdy vědět." A myslím, že je to zajímavé; je to povaha hry. Ale v roce 19 - asi v roce 1989 jsem začal v technologické analýze a víte, v té době byly databáze velmi jednoduché a relační databáze byly velmi jednoduché. Měli tak malou schopnost, myslím, že mohli ukládat data, samozřejmě, a mohli byste je zálohovat a měli, byli v souladu s ACID, ale ve skutečnosti měli velmi slabé optimalizátory. Ve skutečnosti by bylo těžké tvrdit, že měli vůbec optimalizační schopnost.

A později se prostě zlepšili a zlepšili, ale jak víte, databáze nefunguje - protože se zdá, že tyto klokani nějakým způsobem naznačují - může být strašně mnoho důvodů, proč to jde pomalu. A to mě přivádí k věci: Databáze mají mnoho funkcí, ale nejdůležitější je optimalizace dotazů. Pokud by to neudělali, nepoužili byste je. Je to o rychlém získávání informací, o tom, že to dokážeme, když existuje mnoho souběžných uživatelů, a to je těžký problém. A když se na to skutečně podíváte, řekněme jim vyspělé databáze, pokud se vám líbí - ale určitě Oracle, v mírně menší míře Microsoft SQL Server, určitě Teradata a DB2 - optimalizátoři těchto databází se dostali za desetiletí budova. Víš, oni - nikdo se nesedl - šest chlapů na dva muže, rok, projekt a prostě srazili jednoho k sobě. Takhle to nefunguje. Schopnost optimalizace se postupně rozrostla a vyžaduje hodně růstu. Každopádně pojďme mluvit o pozadí do databáze. O databázi NoSQL se nyní říká strašně mnoho a pro grafovou databázi je dokonce spousta nadšení. A použití SQL nad Hadoopem a podobné věci. Pravda je však taková, že pokud chcete právě teď databázi, pokud chcete plně funkční, schopný OLTP a velký tok dotazů, jedná se o relační databázi nebo o nic.

Mezi relačními databázemi je Oracle v popularitě dominantní. Microsoft SQL Server je podle mě druhý. Oba jsou schopni být použiti pro OLTP a pracovní vytížení dotazů, ale ve skutečnosti se opravdu nemůžete zbavit mícháním těchto pracovních vytížení. Pro pracovní zátěž OLTP a pracovní zátěž dotazu potřebujete různé incidenty. Existují alternativy k SQL a grafu. Většina společností standardizuje jednu konkrétní databázi, a proto - po desetiletích boje se všemi ostatními hráči se Oracle stal dominantním. Jednoduše proto, že nakonec dokázali prodat podnikové licence, a tak společnosti používaly pouze alternativní produkty ve výjimečných produktech, které by Oracle jednoduše neudělal. A databáze jsou strategické v tom, že se také vyvíjejí. A víte, že jsem pro tuto prezentaci provedl trochu výzkumu, a je to druh - za chvíli k tomu přijdu, ale je to trochu zajímavé, jak se vyvíjejí, pokud jde o pohled na to z pozice DBA. Tomu říkám neviditelný trend. Je to Mooreův zákon. Je to zhruba takto: Největší databáze je a nové databáze neexistují staré databáze, které by mohly přijímat mnohem více dat. Normálně se jedná o databázi, která je aplikována na nový problém. A ve skutečnosti rostou z hlediska objemu dat. Zhruba u Mooreovy kostky zákon. Mooreův zákon je tedy desetkrát každých šest let. VLDB mají tendenci růst každých tisíc let každých šest let. V roce 1991, 1992, jsou velké databáze měřeny v megabajtech. V letech 97 a 98 gigabajty. 2003, '4, terabajty. 2009, '10, začali jste prohlížet petabyte databáze. Myslím, že právě teď byla možná jedna nebo dvě exabyte databáze, ale největší, o kterém jsem slyšel, je 200 petabytů včas, a víte, nedostávají data do petabyte databází. Ale bude to zřejmě největší nová společnost s webem 2.0, možná máte Facebook tímto směrem.

Ale stejně, pokud se na to skutečně podíváte a očekáváte, že databáze projde tímto druhem eskalace objemu, vyžaduje to hodně. A pozoruhodně, jistě až na úroveň petabytů, se zdá, že si vedly docela dobře. Myslím tím, že mluvím spíše o starších produktech než o něčem novém. Zdá se, že si vedly mimořádně dobře. Pokud se podíváme na výkon databáze, úzká místa, vezme mě to zpět do doby, kdy jsem se o ně vlastně staral, a musel jsem se o ně starat. Víte, je to v zásadě rozpis hardwaru. Existují úzká místa CPU, možná jsou i úzká místa v paměti, možná jsou i úzká místa na disku. Může to být síť, která vám způsobuje zármutek, a také můžete mít problémy se zamykáním v závislosti na tom, co děláte, ale obvykle je to proto, že program neví, komu volat zámek. Takže, pokud se chystáte naladit databázi, snažíte se ji skutečně naladit tak, aby tancovala mezi těmito pěti možnými úzkými místy stejně jako to dokáže. A to není snadné, protože množství paměti, které byste mohli nakonfigurovat na kterémkoli daném serveru, se dramaticky zvyšuje. Pak se CPU staly vícejádrovými, diskovými, takže teď můžeme dělat, myslím, že i na komoditních serverech si myslím, že můžete dělat stovky a stovky terabajtů, možná čtvrt petabytu, dokonce i na komoditním serveru. Takže ze všech těchto věcí si můžete hrát, síť samozřejmě může jít různými rychlostmi, ale většinou, když se zabýváte databázemi, opravdu chcete mít mezi servery vláknové kabely a nic jiného na tom běžet, zejména tak.

Faktory výkonu databáze. Chci říct, vynechávám, o čem to všechno bude, protože vím, že Dez o tom bude mluvit, ale špatný návrh databáze znamená špatně fungující databázi. Špatný design programování může znamenat házení velmi hloupého SQL do databáze, což bude trvat mnohem déle. Míchání souběžnosti a pracovní zátěže, příliš mnoho souběžnosti způsobí problémy se zúžením. Míchání pracovní zátěže, když máte velké dotazy s velmi malými, krátkými a ostrými dotazy, které způsobují problémy. Vyskytl se problém s vyrovnáváním zatížení. Většina databází se o to postará, ale pokud nemáte sofistikovaný produkt, pak víte, stačí přidat několik serverů, není vše, co děláte, pokud skutečně chcete zvětšit velikost klastru. Než dosáhnete optimálního výkonu, musíte skutečně vyrovnat zatížení. Musíte provést plánování kapacity. Absolutně. Obzvláště nyní v těchto dnech, kdy objemy dat rostou dramatičtěji, než tomu bylo u databází. A existují celé problémy s datovou vrstvou, jak přijímáte data, jak pohybujete daty. Neschopnost získat data do databáze včas může být problém s výkonem později, protože jsme přešli z databází pracujících ve Windows, na dvacet čtyři sedm sedm na tři sta sedmdesát pět operací a neexistují žádná okna, kde můžete zpomalit databáze dolů nebo je nepravděpodobné, že v dnešní době bude.

Problém Oracle DBA. O tom jsem přemýšlel. Byl jsem v Oracle DBA s Oracle 7 a pamatuji si, jak to naladit. A pokud se na Oracle podíváte nyní, je to tak, tak - je to tak, má více schopností. Má indexování bitmapy a podobné věci, ale ve skutečnosti jsem si vzal čas podívat se a zjistit, kolik tuningových parametrů v současné době existuje v databázi Oracle. A existuje více než tři sta padesát ladících parametrů a existuje dalších sto skrytých parametrů, o kterých by specializovaní DBA mohli vědět, ale normální Oracle DBA o tom nevědí. A to znamená, že vyladění tohoto druhu databáze je těžká věc. Není to vůbec jednoduchá věc. Musíte to mít pocit, musíte to dělat dlouho, dlouho a musíte přesně vědět, jaký problém si myslíte, že řešíte, protože ladění začíná, když výkon klesá, ale nemusí to být výkon všeho. Záleží na výkonu konkrétních dotazů a možná to budete moci opravit připnutím určitých dat a paměti nebo je budete možná muset opravit indexováním, nebo budete muset začít dělat rozdělení jiným způsobem. Je tu spousta věcí, které můžete udělat, to je důležité. V důsledku toho to neudělají ve svých hlavách - DBA potřebují nástroje. Nyní předám Dezovi, který ti řekne o indexování, myslím.

Eric Kavanagh: Dobře, Dez, vezmi to pryč.

Dez Blanchfield: Děkuji, Robine, a miluji titulní stránku. Myslím, že jsi hodil rukavici tam dole, abych přišel dokonce vzdáleně blízko něčemu tak vzrušujícímu. Ale použil jsem obrázek naší malé galaxie jako svůj pohled na to, co se dnešní výzva pro administrátory databází změnila, protože to je mentální obraz, který mám sklon vymýšlet, když se dostanu do prostředí a už nejsem ve světě správy databází nebo navrhování databází na této úrovni. Ale stejně jako vy, i Robin jsme byli mnohaleté zapojení do světa databází, buď jako administrátor nebo vývojář, nebo nakonec architekt, a pak jsme si uvědomili, že mohu dělat lepší věci, abych si vydělal krustu. Ale má sklon cítit se, jako byste zírali na tuto galaxii dat, a tím více dnes, když jdeme od, jak jste naznačil, šli jsme z megabajtů na petabajty a exo-měřítko ve velmi krátkém časovém období., ve velkém schématu věcí. Ale fráze, kterou mám na mysli, je, že databázové indexy jsou nyní černým uměním a nejsou to vlastně věci, které by měli pouhí smrtelníci nějak dabble, pro podnikové aplikace podnikového stupně a typ formulace vás mluvili. Chtěl jsem však rychle projít typ historie, kterou jsem měl s databázovými světy, a přivést do kontextu, kde se chystáme vyvodit závěr, a pak si dnes s našimi přáteli projít nějaký materiál IDERA, protože si myslím, že existuje spousta různých přemýšlení o tom, jak dosáhnout vyladění výkonu databáze, a jeden z nich hodí plechovku na věc. U mnoha obchodů, s nimiž se setkám, se vždy nedostanou do bodu, kdy provádějí ladění výkonu v databázové vrstvě a zejména v indexové vrstvě, dokud se nedostanou přes tvrdou cestu myšlení, že na ni mohou hodit tuner. .

Mnoho lidí k tomu přistupuje jen velmi ironicky a mám tu obrázek The Flash, protože pokud jste někdy sledovali staré filmy nebo určitě nejnovější televizní show s The Flash, jako v Flash Gordon stará postava, a teď, když se jmenuje „Flash“, má tendenci jít velmi, velmi rychle a vždy mu dochází energie. A to se stane, když hodíte velké železo na výkon databáze. Podle mých zkušeností můžete vždy dát do hry vysoký výkon, tvrdou práci, můžete optimalizovat své operační systémy a naladit je do určitého bodu. Můžete si zajistit, že máte rychlé vícejádrové, vícevláknové procesory, aby aplikace běžela rychleji, můžete zahodit spoustu paměti RAM, můžete mít vysoce výkonné backplanes, můžete přejít z pevných disků do mezipaměti pevných disků do solidního stavu a vysoce výkonné úložné pole. A dokonce i teď lidé házejí do svých databázových strojů věci jako flash a NVMe, protože si myslí, že získají tento přihlašovací čas dvakrát vyšší výkon. A vždy získají nějaký zisk. Ale vše se vrací ke stejným základním problémům s laděním výkonu. Mnoho síťových připojení s nízkou latencí, aby klastry fungovaly rychle. A klastrování databázové infrastruktury, takže máte více než jen jeden stroj, který vykonává veškerou práci. Máte však tendenci se vracet ke stejnému základnímu problému s výkonem, a to je čtení dat. Psaní dat je z velké části docela lineární výzvou, a pokud to není provedeno správně.

A pak máme výzvu v dnešním světě: Ne všechny databáze jsou vytvořeny rovnocenné. Existují databáze a citace „databáze“. A když přemýšlíme o databázových strojích, lidé často přemýšlejí o tradičních obvyklých podezřelých, jako by byli ve světě SQL. Víte, máme Oracle a Microsoft SQL Server a ve světě open source existuje pár s MySQL, který je nyní ve vlastnictví Oracle, ale stále je to open source. A pak máme neobvyklé podezřelé, motory NoSQL, které mají stále problém s indexováním a správou výkonu, a já do nich nebudu chodit podrobně, ale je jich stále více věci se objevují každý den a vypadají a cítí se jako databázové stroje z pohledu vývojářů a z hlediska výkonu, ale jsou to velmi, velmi odlišná zvířata a mají na světě svůj malý výklenek, výkon v paměti nebo lineární měřítko na disku. Ale to je to, jak svět vypadá ve světě databází. Toto je rok 2016, jedná se o verzi třetí mapy řady lidí, kteří vytvářejí tuto probíhající krajinnou mapu toho, jak databáze vypadají, a to je místo, kde to může být - ani nadlidský architekt databáze nebo správce databází nemohl dávat smysl z toho. Doslova stovky a stovky a stovky různých značek, modelů, výrobců databází, vždy kompatibilní s SQL. A zajímavé je, že se všichni vracejí ke stejné výzvě. Ladění výkonu a výkonu kolem databázového stroje a zejména podle toho, jak jsou data indexována.

Pojďme se tedy rychle věnovat indexování databáze, protože je to zajímavé téma, a musíte se k němu dostat podrobněji pomocí dema, věřím. Domnívám se však, že je docela dobře přijatelné a standardní průmyslovou praxí, že ladění výkonu indexů databází je místem, kde svět začíná a končí, pokud jde o zajištění toho, aby vaše data byla přístupná v rychlém a rychlém formátu. Co je však indexování databáze? Pokud přemýšlíme o indexování ve formě, kterou jsme zvyklí jako běžní lidé, přemýšlejte o indexové stránce v knize. Pokud chcete v knize najít něco - zejména oblibu encyklopedie nebo něco jako referenční materiál nějaké podoby - pokud hledáte něco jako tato stránka, kde hledám věci, jako je téma přehrad v encyklopedii. Chci najít všechny odkazy na přehrady, povodí vody a velkou zastavěnou plochu, obecně vytvořené člověkem. Půjdu vzadu, najdu to v abecedním, tříděném seznamu, A až Z, zleva doprava, a najdu D. Najdu slovo „dams“ a to vidím na strany 16, 38, 41 je na ně odkaz, a pak na tyto stránky mohu jít, mohu si prohlédnout oči a najdu odkaz na slovo „dam“. V databázi je to v podstatě stejný koncept, ale nyní je to raketová věda v mnoha ohledech. A to natolik, že každý správce databáze, kterého jsem kdy dobře poznal, považuje indexy za jediný nejkritičtější nástroj pro vyladění výkonu v jakémkoli databázovém světě, bez ohledu na to, jaké mohou být jejich zkušenosti, pokud jde o házení cínu, nebo ať je to jakýkoli případ.

Obecně platí, že když mluvíme o indexování databáze, existuje celá řada běžných přístupů. A čím složitější jsou databázové indexy, tím složitější je přístup k indexování dat. Ale v podstatě, když přemýšlíte o indexování dat - představte si, že máme soubor, který má seznam jmen; nesmí být řazeny v abecedním pořadí. Představme si, že jich je dvacet. Pokud se chystáme třídit - pokud budeme hledat data v tomto seznamu, shora dolů a řekněme, že je to seznam jmen. Pokud si vyberu náhodné jméno a začnu posouvat seznam dolů, od shora dolů, v lineárním formátu a je to neuspořádaný seznam, existují dvě kritéria, která považuji za svůj průměrný čas vyhledávání a můj maximální čas vyhledávání - a Ve druhém řádku mám překlep, měl by být „maximální vyhledávací čas“, promiň - ale moje průměrná vyhledávací doba je v zásadě N plus jedna, dělená dvěma, a to je v průměru, zabere mi to padesát procent času Chcete-li skenovat z horní části seznamu, do spodní části seznamu a najít v tomto seznamu libovolnou náhodnou věc. A druhý řádek tam, pod lineárním, by měl být „maximální vyhledávací čas.“ Ale maximální vyhledávací čas je v podstatě počet položek, a to je to, že pokud mám seznam dvaceti věcí, že mi to může nejvíce trvat hledat něco v této databázi, je jít od shora dolů, což je řekněme 20 položek v tomto zjednodušeném příkladu. A je to velmi pomalý proces a ve skutečnosti neexistuje způsob, jak to vyladit. A pak existují další typy způsobů, jak vzít tato data a vytvořit index, což je ve skutečnosti krátký seznam ukazatelů, na nichž jsou skutečná data, například binární, B-strom, bitmapa, hashování, seskupování a neslastování, a pak existují různé typy dat, jako jsou prostorová, filtrovaná, XML a plný text.

Binární je velmi běžně používaný pro věci, kde se k němu data hodí. B-strom je pravděpodobně jediný nejběžnější v obecném slova smyslu, historicky v tom, že je to běžný způsob, jak strukturovat index na jakoukoli formu dat a umožňuje loggerům, výběrům a vkládáním a mazáním relativně snadné, když pohybujete ukazateli kolem odkazy na ukazatele, body. Existují i ​​jiné typy, například bitmapa, kde se datové typy týkají, jako kdybychom dostali přidruženou škálu nějaké formy. Hashing funguje velmi dobře pro velké objekty, zejména pro blogy a obrázky. A vidíte, že existuje řada různých typů vědeckých přístupů, matematických přístupů k indexování dat. Pro obyčejného smrtelníka je to zajímavá výzva, o které se dá mluvit na této úrovni. Když o tom mluvíte na úrovni výkonu pro správce databáze, opravdu se stanou vědcem raket a lidé v nich udělají tituly, a já vím, že doktor Robin Bloor to určitě udělal, a napsal o tom knihy jako pro IBM a dalších velkých značek za posledních několik desetiletí. A tak, můj názor, je to, že jsme vlastně prošli časem, kdy víte, jednou za čas, že budu osobně schopen sedět před systémem a já ho budu moci rozebrat a ukázat vám přesně tam, kde byly problémy s výkonem na příkazovém řádku nebo v grafickém nástroji pro spuštění uživatelského rozhraní, a začněte se ponořovat do dat a řekněte vám, kde se problémy vyskytovaly, a do toho vytvářejte indexy nebo subindexy nebo primární a sekundární indexy. a začít je používat k hledání věcí. Ale když přemýšlíte o této krajině, ukázal jsem vám, kde máme stovky a stovky značek, značek a modelů a výrobců a typů databází, jsme nyní dobře a skutečně minulostí, kde člověk může udělat smysl pro typy databázových strojů, které máme. Zvláště, i když se právě vracíme k Oracle, převládají značky v dnešní době na platformách relačních databází.

Počet databází, s nimiž se musí vypořádat buď z proprietární platformy, jako je ERP nebo HR nebo finanční systém, nebo zda jde o domácí platformu z různých důvodů, počet databází a databázových tabulek a záznamů, které skončíme zabývat se jsou jen astronomické a fyzicky to nemůžete udělat ručně. A nyní jsme měli další komplikaci, kdy jednou mohl databázový server jen sedět pod vaším stolem. Víte, jako malé dítě po škole jsem chodil a pracoval na databázovém softwaru na, původně, Apple IIes a pak DOS-založené systémy, jako dBase II, dBase III, prošly érou s mainframes a mid- rozsah a dokonce i VAX a PDP a soubor protokolu o tom. A podobně jako Sabre, a pak nakonec, když se objevily některé z SQL databází. Ale v těchto dnech, když přemýšlíme o databázových strojích, vypadají jako levý dolní roh. Databázový server už není jen jeden stroj, který sedí na podlaze pod stolem; jsou to stovky počítačů, které provozují kopie databázových strojů a klastrů, a škálovají až stovky a stovky terabajtů dat, ne-li petabajty dat, což jsou tisíce terabajtů. A dokonce až do extrému, jak řekl doktor Robin Bloor, že některé konkrétní případy použití - zejména letecké společnosti, zejména vládní agentury - se mohou dostat k exabytům. Jsou stále dost nika-y, ale stovky terabytů a dokonce desítky petabytů už nejsou neobvyklé, zejména od dotcom boomu až po dnešek, jakési to, čemu říkáme společnosti web 2.0, jako jsou Facebook, Google, Yahoo a tak dále.

Nyní máme také komplikaci, když se věci přesouvají na externí službu. Máme infrastrukturní platformu a software jako servisní přístup poskytující infrastrukturu. A zejména platformová služba, kde nemůžeme koupit pouze pro Oracle a jejich cloudovou platformu, databáze a servery. A to nám umožňuje velmi rychlý vývoj aplikace a stačí připojit databázi zpět na servery. Nemusíme přemýšlet o tom, co je pod kapotou. Nevýhodou je, že často nepřemýšlíme o tom, jak navrhujeme a implementujeme databázi zpět, dokud nezačne bolet a výkon se nestane problémem, a nakonec skončíme s hledáním správného nástroje pro diagnostiku, proč naše databáze bolí a kde jsou problémy s výkonem. A to vždy přináší zpět k tomuto obecnému problému, jak jsme data indexovali, a typy indexů, které jsme pro tato data použili, a které nás pak přivádí zpět k požadavku na nadlidský výkon. A někdo, kdo má přístup ke správným systémům a správným nástrojům pro výkon, vyladí tyto motory a začne hledat hot spot a podívat se, kde jsou dotazy, kde se data pohybují, typy dotazů, jak jsou strukturovány, kdo dělá dotazy a zda jsou dotazy zařazovány do fronty a musí být uloženy do mezipaměti. Jakou replikaci hledáte?

A tak jsme v pořádku - podle mého názoru - v okamžiku, kdy dokonce i nejlepší světoví databázoví guruové, v podstatě naši databázoví architekti a administrátoři databází a výkonnostní základny, podle mého názoru potřebují začít využívat ty správné nástroje k zajištění optimálního vyladění indexu výkonu pro jakýkoli databázový stroj. Protože měřítko, se kterým se zabýváme, a rychlost, se kterou se věci pohybují, to jednoduše nemůžeme udělat ručně a pokus o to vždy může přinést další problémy s výkonem, protože v tomto prostoru nemusíme mít zkušenosti, které Snažíme se vyřešit problém. A já věřím, že právě tady se chystáme předat Bertovi a chystáme se mluvit o tom, jak vyřešili tento rozmanitý problém a o typu věcí, které jejich nástroj dokáže. udělat, zejména pro svět Oracle. A s tím, Bert, půjdu k tobě.

Bert Scalzo: Děkuji. Vítejte všichni, jmenuji se Bert Scalzo, pracuji pro IDERA. Jsem vedoucí produktového manažera pro některé z našich databázových produktů. Dnes některé z nich ukážu. Chci však mluvit o indexech, protože souhlasím se vším, co zde všichni řekli, zejména s posledním snímkem, že indexy jsou nyní tak složité, že potřebujete nástroj, a doufám, že vás přesvědčím. Takže návrh indexu Oracle není tak snadný, jako tomu bylo za starých časů. Spousta lidí si nebude jistá, když se podívají na možnosti, a líbí se mi to, že jsem vytrhl z historie: „v těchto věcech je jedinou jistotou, že nic není jisté.“ A takhle cítit se o indexech v těchto dnech, protože i když si myslíte, že znáte odpověď, kterou byste měli indexovat X, Y nebo Z, opravdu si nemůžete být jistí, dokud to nezkusíte, protože tito optimalizátoři se někdy chovají jinak, než očekáváte. A tak existuje spousta pokusů a omylů s návrhem indexu. Nyní, v dobrých starých časech, pokud jste potřebovali index, byly obecně jen dvě otázky nebo jedna otázka. Byl to jedinečný nebo nebyl jedinečný? A možná jste si vzpomněli na další věci, například: „Kolik indexů mohu mít maximum v jedné tabulce?“, Protože příliš mnoho indexů zpomaluje vkládání, aktualizace a mazání. Možná jste také byli v databázovém systému, měli jste omezení ohledně počtu sloupců v indexu s více sloupci, protože někdy existovaly limity založené na velikosti stránky nebo bloku vašeho databázového stroje, ale ve skutečnosti to bylo docela jednoduché zpět za starých dobrých časů. Buď jste to indexovali, nebo ne. A opravdu, všechno bylo v B-stromu. Mohli jsme dovolit duplikáty nebo ne, a to bylo o tom. Život byl dobrý, život jednoduchý.

Dnes není život tak dobrý nebo tak jednoduchý. Červeným znamením Ghostbusteru jsem provedl způsob, jakým jsme to dělali, protože nyní máme spojení B-strom versus bitmap versus bitmapa. A chystám se vysvětlit, co jsou některé z nich za okamžik. Klastrovaný a neslastovaný, jedinečný nebo duplikovaný, pořadí vpřed nebo vzad, založené na funkcích, rozděleno na oddíly nebo bez oddílů. Pokud se jedná o vytváření oddílů, jedná se o globální nebo místní rozdělení? Vysvětlím to také. A pak je tu také něco, co se nazývá indexovaná organizovaná tabulka. A ve skutečnosti je tu půl tuctu dalších, které jsem opustil, protože si myslím, že už mám dost, abych vás přesvědčil, že indexy jsou mnohem tvrdší, než si možná myslíte. Na tomto konkrétním snímku začnu v levé horní části diagramu a mám tabulku. A první věc, kterou musím rozhodnout, je, v závislosti na verzi vaší databáze a prodejci databáze, povolit tabulky objektů nebo jsou pouze relační? Jdu dolů po pravé straně a řeknu, že budujeme relační stůl. Nyní si musím položit otázku, je to v klastru? A mnozí z vás, kteří již nějakou dobu dělali Oracle, si budou pamatovat, že shluky byly zpět na Oracle 6 dní. Pravděpodobně se už dnes moc nepoužívají, ale nech mě nejdřív jít dolů po té větvi.

Pokud bych chtěl dát svou tabulku do klastru, musel bych mít v této tabulce klastrovaný index. Nyní, v Oracle, když jste seskupili tabulku, jste v podstatě ukládali řádky nebo byly řádky blízko sebe, kde byly hodnoty podobné. Takže musíte mít klastrovaný index a tento klastrovaný index by mohl být rozdělen na oddíly. Jinými slovy, ve skutečnosti neexistovaly žádné metody rozdělení disku, jak byste udělali seskupenou tabulku. Bylo to přísně nerozdělené. A protože to nebylo rozděleno, bylo to globální. Za minutu vysvětlím, co je globální. A byl to vždy B-strom. Jinými slovy, když jsem sestoupil z toho odvětví, bylo to docela jednoduché, neměl jsem mnoho možností. Teď, když jsem udělal index bez klastru na seskupené tabulce, což bylo v některých verzích povoleno, opět to nebylo rozděleno na oddíly; když není rozdělena, pak je jedinou možností globální. A tak máte na výběr B-strom nebo bitmapu. Opět to záleželo na vaší verzi databáze. Ale teď se vraťme zpět k relačnímu stolu a začneme zase dolů po pravé straně a teď budeme mít prostý, starý, pravidelný, hromadný stůl: relační. Bude to v tabulkovém prostoru. Nejdřív sem nejdřív dolů pravou stranou. Takže je to organizace, halda. Další otázku, kterou si musím položit, je: „Chci rozdělit tuto tabulku nebo ne?“ Nyní byste někdy rozdělili oddíl, protože jste si mysleli: „Hej, optimalizátor bude chytřejší o tom, jak dokáže optimalizovat dotazy. „Ale mnoho DBA vám řekne, že důvod, proč to děláte, je pro administrativní účely. Pokud máte tabulku 100 miliard řádků, pokud ji rozdělíte na oddíly nebo kbelíky, když chcete přidat data do posledního kbelíku, můžete přetáhnout a indexovat, což je jen několik milionů řádků. Můžete vložit tato data a pak můžete tento index znovu vytvořit pouze v tomto bloku.

I když pro některé to byla dobrá technika, optimalizační techniky, jako je eliminace diskových oddílů, její skutečná hodnota byla schopna spravovat nebo provádět administrativní úkoly na menších kusech. Když jdu do organizační hromady, první otázka byla: „Rozdělil jsem to nebo ne?“ Pojďme doleva, nebudu rozdělovat tabulku. Teď se to může zdát podivné, když vám to řeknu, ale můžete mít tabulku bez oddílů a index nelze rozdělit tak, jak jste zvyklí, nebo můžete index rozdělit. Zastavte se a přemýšlejte. Tabulka má v podstatě jednu kbelík, jak jste si vždy mysleli, a přesto váš index bude mít více kbelíků. Když k tomu dojde, pokud existuje nesoulad mezi počtem kbelíků a stolem a počtem kbelíků v indexu, znamená to globální. Pokud tedy tabulka není rozdělena na oddíly a index je rozdělen na oddíly, považuje se to za globální, protože existuje neshoda. Teď mi dovolte, abych se vrátil na hromadu své organizace a místo toho jsem sestoupil na stranu oddílu. Nyní, pokud mám tabulku oddílů a řekněme, že tabulka má čtyři kbelíky, čtyři oddíly, může mít můj index čtyři kbelíky, takže můj index odpovídá mému návrhu tabulky. A tak je po všem, na druhé straně, po pravé straně. To by bylo považováno za místní. Lokální index v podstatě znamená, že rozdělení tabulky a indexu se provádí stejným způsobem a má stejný počet segmentů. A jakmile budu mít místní index, může to být B-strom nebo bitmapa a ta zelená šipka, kterou tento druh stoupá, vám ukáže, že i když je to B-strom, stále existuje výběr, který by se mohl udělat. Mohlo by to být založeno na funkcích. A pokud je to bitmapa, existují různé typy bitmap. Existuje index nazývaný bitmapový index spojení. Pokud provádíte skladování dat, jedná se o velmi populární druh indexu pro schéma hvězd nebo design. Co se stane, je to, že index má ID řádků pro to, na co ukazuje v tabulce, ale také bude mít ID řádků pro nadřazené tabulky, takže když jste - musíte se podívat na návrh schématu hvězd a hledáte v tabulce faktů vám tento index v tabulce faktů ukazuje na data, která vás zajímají, a ukazuje vás na každý řádek ve vašich dimenzích, takže musíte mít pouze jeden index.

A vlastně to vzniklo kvůli Red Brick, což byla databáze před mnoha lety - spousta lidí si to může pamatovat. A tak, když se podíváte na tento obrázek - a mějte na paměti, že jsem do tohoto obrázku nevložil všechno, protože by byl obrázek mnohem větší - jsou zde ještě další problémy, které zde mám v textu přes pravou horní část . Je to index obráceného pořadí? A můžete říci: „Proč bych chtěl index obráceného pořadí? To nedává vůbec žádný smysl. “No, pokud jste v klastrovaném prostředí v Oracle, pokud děláte skutečné aplikační klastry, pokud udržujete své indexy v pořádku, takže bez obrácení, pokud máte hodně zpracování, které zasahuje stejné hodnoty nebo stejné hodnoty indexu, co by se stalo, měli byste horké oblasti vašeho B-stromu. Znamenalo by to, že byste měli mít svolení a případně zamykání, abyste se pokusili o přístup k těmto materiálům, a udělali byste to napříč uzly v síti. Pokud zadáte index obráceného pořadí, můžete to nyní vrátit zpět. Můžete říci: „No, podobné hodnoty jsou v různých částech stromů, takže nemám své samostatné uzly soutěžit o horké oblasti stromu.“ A pak si také všimněte, že jedinečný nefunguje s některými možnostmi . Když se podíváte, čísloval jsem tři, pět, osm a jedenáct, takže existují případy, kdy nemůžu mít jedinečný index. Stejně tak existují případy, kdy nemůžu mít reverzní index, a pak jsou tu další problémy, jako je protokolování nebo žádné protokolování, a paralelní a nerovnoběžné. Dokážu věci přiřadit ke konkrétní oblasti v paměti.

A to vynechává stále docela dost funkcí v Oracle. Řekl bych, že když se podíváte na Oracle 12, je tu asi opět asi půl tuctu věcí, které bych mohl přidat k tomuto obrázku. Indexování je opravdu složité a já opravdu souhlasím s předchozím řečníkem, abyste se v něm mohli pohybovat a udělat dobrý výběr, potřebujete nástroj. Možná je to třeba obrázek, jako je tento, a nějaký druh metodiky, jak byste si věci vybrali, a doufejme, že vám tento nástroj pomůže. A pak to bude pokus a omyl. Vždycky říkám lidem o indexování: „podívej se, než skočíš.“ A pak tady můžeš vidět malého pejska, že skáká, aniž by se díval, že skončí ve vodě se žralokem, nebo se chlap chystá skočit do vody, a on se chystá napíchnout. Musíte myslet na své indexování, protože vytvoření indexu neznamená vždy, že se věci zlepšují. Ve skutečnosti může vytvoření indexu věci zpomalit. A výkon dotazu může být řádově lepší s jednou volbou před druhou. A dám vám dobrý příklad. Pokud děláte hvězdné schéma designu a ve svých tabulkách rozměrů používáte rastrové indexy v jednom případě a v jiném případě řeknete: „Budu používat indexy stromu B, “ máte bitmapu versus B- strom. Mohu vám říci, že jedním řešením bude řádová velikost nebo možná několik řádů rychlejší než druhá. Ale mějte na paměti, co funguje v jednom prostředí, například v prostředí datového skladu, pravděpodobně není v prostředí OLTP dobrá volba.

Například, pokud byste měli vzít transakční tabulku a umístit bitmapové indexy na transakční tabulku, je drahé vypočítat a resetovat bitmapy, tyto dlouhé řetězce, a tak v tabulce OLTP, můžete zasáhnout tabulku tak silně, že bitmapa index se může poškodit a zpomalit váš systém, protože nejsou určeny pouze pro aktualizace. Jsou skvělé pro rychlý přístup, ale nejsou dobré pro aktualizace. Myslím, že index trvá pokus a omyl. Ve skutečnosti neexistuje žádné zlaté pravidlo - v této rovnici je příliš mnoho různých proměnných - a nakonec se budete muset podívat na provádění nebo vysvětlit plány v databázi, abyste zjistili, zda děláte dobrý výběr. A někdy může být analýza plánu téměř sama o sobě vědou. To se dnes nebudu zabývat - to je další téma -, ale neberte si návrh indexu jako samozřejmost. Existují legitimní důvody, proč existují všechny tyto šílené typy indexů, které jsem vám na předchozím obrázku ukázal a o kterých mluvil předchozí řečník. Nebyly vytvořeny pouze proto, že to byla elegantní funkce umístit někde kontrolní seznam pro dodavatele databáze; existují případy použití nebo scénáře, kde jsou tyto indexy důležité a významně změní. Nyní vám ukážu několik příkladů různých typů indexů v jednom z našich nástrojů. Dovolte mi jen zvednout obrazovku, abyste ji viděli. Dobře, tak tady sedím uvnitř - dovolte mi minimalizovat tuto aplikaci. Sedím uvnitř VMware a provozuji Windows Server 2012 VM.

A vidíte, mám téměř každý nástroj známý člověku. Jako produktový manažer si musím být stále vědom své konkurence, takže nejde jen o to, jaké nástroje mám, ale co udělají moji konkurenti? A tady máme tento nástroj s názvem DBArtisan, který už mám spuštěný, ale já jdu - tak to jen přivedu. A to, co vidíte, je opravdu pěkný nástroj, protože místo toho, abyste museli používat, řekněme podnikový manažer pro Oracle a SQL Management Studio pro SQL Server a MySQL Workbench pro MySQL a dvanáct dalších databází, které podporujeme, dobře mám všechny své databáze zabudované do tohoto jediného nástroje. Je tu DB2, MySQL, Oracle, Postgres, SQL Server a Sybase, a to je - mám v této konkrétní věci pouze šest databází, protože nemůžu - nástroj podporuje dvanáct databází, ale můj ubohý VM, běžící šest databází současně a zkouší udělat demo, je asi tolik, jak můj hardware usnadní. Dovolte mi tedy, abych se nyní vrátil zpět do Oracle, a pokud si všimnete, všechny tyto věci jsou stejné. Pokud chci měřit svůj výkon v produktu DB2, je to stejná volba jako v systému Oracle. Nyní pod pokrývkami děláme spoustu různých věcí, takže nemusíte vědět, co se děje, ale poskytujeme vám konzistentní rozhraní, takže můžete být odborníkem na více databázových platforem. A to by zahrnovalo práci s indexy, téma této diskuse.

Dovolte mi, abych sem přišel a nechal mě začít tím, že se podívám na některé tabulky, a mám databázi filmů, která má jen několik tabulek. A když se podívám na konkrétní tabulku, stejně jako na tabulku zákazníků, když ji přivedu sem, uvidím design své tabulky, zde jsou mé sloupce v tabulce a zde jsou informace o každém sloupci. Mám vlastnosti tabulky, ale všimněte si, že mám záložku pro indexy a vidím zde, jsou indexy v tabulce. Všimněte si, že jedním z těchto indexů je můj index PK, můj primární klíč. Tito další vypadají jako indexy pro zlepšení přístupu k dotazům, možná dotazujeme podle křestního jména nebo příjmení, nebo se podíváme na telefony a PSČ. A pokud si vyberu konkrétní index, jako je tento PSČ, a dvakrát na něj kliknu, nyní vidím, že je to neobjektivní index a zde jsou některé další typy, bitmapa, nejedinečné, jedinečný, ať už je tříděn, či nikoli, ať už je to protokolování, či je to v opačném pořadí, zda je to funkční základna. Oh, tady je zábava, kterou jsem nezakryl. Ve skutečnosti můžete mít neviditelné indexy. A řekli byste: „No, proč bych sakra chtěl udělat neviditelný index?“ Dobře, dám vám dobrý příklad. Jste ve svém výrobním systému a máte problém s výkonem a nejste si jisti, že vytvoření indexu problém vyřeší, takže nechcete vytvořit index a zpomalit výrobu, ale nějak nebo tak, jak chcete být schopen to vyzkoušet. Můžete vytvořit index ve výrobě jako neviditelný, což znamená, že ho nebude používat mnoho kódů aplikace, které volají optimalizátor. Byl vytvořen, je platný, ale nebude použit. Pak můžete položit dotaz, o kterém si myslíte, že by vám tento index pomohl, nebo sérii dotazů, a můžete vložit nápovědu a říct: „Hej, optimalizátor, tam je neviditelný index, který chci, abys použil a nechal já vím, jestli jsem věci vylepšil. “A teď jsem něco vyzkoušel ve výrobě, ale neporušil jsem spuštěné aplikace ve výrobě. To je použití pro neviditelný index. Když to poprvé slyšíte, zní to hloupě, ale má to smysl.

Na indexech můžeme také definovat, zda jsou rovnoběžné a také kolik případů jsou rovnoběžné. Nyní v prostředí bez clusterů nebo v reálných aplikačních klastrech, takže ne-stojan, by paralelní znamenalo, kolik dílčích procesů může můj dotaz vyvolat, aby se pokusily, a pracovní procesy, aby se pokusily získat věc rychleji nebo rychleji . A paralelní případy by byly, pokud jsem ve skutečném aplikačním klastru, řekněme, že mám deset uzlů, kolik uzlů mohu dělit práci? Možná jsou to čtyři z deseti a na každém z nich čtyři dílčí procesy. To je příklad. A pak máme kompresi kláves. Můžete skutečně komprimovat indexy? Ano nebo ne. A pak samozřejmě máte parametry úložiště, které můžete určit v indexech. Teď jsem je nepokryl, protože jsou ve skutečnosti spíše parametrem úložiště než problém s indexem. A pak konečně máme, zda je chceme rozdělit či nerozdělit. Nechte mě to na chvilku zahodit. Jdu na jiné schéma. Toto je hvězdné schéma a například tato tabulka období je tabulka rozměrů. Pokud jste někdy provedli návrh schématu hvězd, máte obvykle dimenzi času a tak v této databázi a této schématu hvězd je období časovou dimenzí. Teď vím, že to bude vypadat vtipně, řekneš: „Gee, podívej se na všechny ty sloupce - slyšel ten chlap normalizaci?“ No, když jsi v datovém skladu nebo ve schématu hvězdných schémat, ty obvykle máte non - máte tabulky, na které by se typický člověk podíval a řekl: „Gee, ty nejsou velmi dobře navrženy.“ Ale tak to děláte v prostředí datového skladu.

Nyní sledujte, co se stane, protože, dobře, jsou všechny tyto sloupce, podívej se na to, mám index na každém jednotlivém sloupci. Nyní v prostředí OLTP, které by bylo ne-ne. Zpomalilo by to všechny mé operace. V prostředí datového skladu bych je upustil během cyklů dávkového načítání. Načíst bez režie nebo indexů, a já bych znovu vytvořit indexy. A pokud jsem rozdělil svou tabulku, pak místo toho, abych musel vynechat index pro každý kbelík v tabulce, mohl bych prostě přetáhnout index na kbelík nebo kbelíky, kam se data během tohoto dávkového cyklu načítají. A pak znovu vytvořte pouze část indexu pro tyto vědra. A to je velmi zvládnutelné. A když se podívám na - tak tady je sloupec nazvaný „Holiday Flag“ a v podstatě to je ano nebo ne. Všimněte si, že se jedná o bitmapový index, a pro většinu z vás řeknete: „No, to dává smysl.“ Ano nebo ne, Y nebo N, existují pouze dvě hodnoty, které dává smysl. A protože když čtete dokumentaci pro bitmapové indexy, vždy vám řeknou, abyste si vybrali něco s nízkou kardinálností.

Teď mi dovolte jít do jedné z mých faktických tabulek, takže tady máme své rozkazy. A to jsou moje rozkazy denně. A teď se uvidíš, že zase mám docela pár sloupců a zase budu mít více než několik indexů. A právě tady máme něco, co se nazývá univerzální cenový kód. To bylo pro maloobchod, takže ty malé čárové kódy znáte, když něco koupíte v obchodě, jedná se o univerzální cenový kód. Nyní existují miliony univerzálních cenových kódů. Nyní pro tuto konkrétní společnost, která prodávala věci, měli pravděpodobně 1, 7 až 2 miliony univerzálních cenových kódů, takže budete očekávat, že se nejedná o bitmapový index, protože 1, 7 milionu odlišných hodnot zní jako vysoká mohutnost. Ve skutečnosti však v prostředí datového skladu chcete, aby to byla bitmapa. Teď mi dovolte vysvětlit proč. Pro tento univerzální cenový kód může existovat 1, 7 milionu zřetelných hodnot, počet řádků v této tabulce objednávek je ve stovkách milionů až miliardách řádků. Můj index je nízká mohutnost ve srovnání s velikostí nebo mohutností tabulky. Díky tomu je nízká mohutnost. Díky tomu je bitmapový index užitečný, i když je to kontraintuitivní s 1, 7 milionu odlišných hodnot, které byste si vybrali bitmapu. Teď, když jsem věděl, že chci použít index bitmapové mapy, v současné době to produkt nepodporuje, přidávám to přidané pro příští vydání, ale to by byla další alternativa. A v hvězdném schématu si pamatujte, že bitmapový index bude na tabulce faktů a že jeden index ve stromu B bude ukazovat na řádek v tabulce faktů a poté na každý řádek, který byl pro tuto skutečnost zřejmý v tabulce rozměrů . A tak máte jinou možnost. A tak se podívejme, chci nyní vyjít z tabulek a chci vám rychle ukázat, že mám stejné informace pod indexy a udělám stejnou základní věc.

Teď, důvod, proč jsem to vynalezl, je, že si můžete všimnout, hej, tady nejsou žádné primární klíče. Primární klíče se provádějí s omezením klíče, takže jsou ve skutečnosti pokryty definicemi omezení. Jednalo by se o indexy, které nejsou součástí omezení. Nyní můžete říci: „Počkejte minutu, což by mohlo vypadat jako cizí klíč, a cizí klíč je omezení, “ ale cizí klíče a většina databází automaticky nevytvoří index ve sloupci cizího klíče, i když je to vhodné, a tady to máte - znovu mám všechny stejné možnosti. A pokud chci změnit jen komprimovaný, můžu to udělat.

Nyní komprese funguje pouze na indexu B-stromu. To umožňuje, když se podíváte na různé uzly ve stromu B, umožní to komprimaci některých hodnot. Opravdu to není komprese jako komprese tabulky, je to komprese toho, co je uloženo ve stromu B v ne-listových uzlech. To nezachrání tunu prostoru, ale může to změnit. A s tím jsem si toho všiml, dostávám se docela blízko času, takže chci udělat to, že se chci vrátit zpět a zastavit sdílení. A máme tam náš produkt na čtrnáctidenní zkušební verzi na webu idera.com. Je to docela dobrý produkt, zejména pokud pracujete s více databázovými platformami. Pokud pracujete se dvěma nebo třemi různými databázemi, tento nástroj vám usnadní život. Máme nástroje, které vám pomohou s návrhem a výběrem indexu, máme nástroj s názvem DB Optimizer. To jsem dnes nemohl pokrýt, to by bylo příliš. A pokud mě chcete kontaktovat, je tu moje e-mailová adresa, je to, nebo mě můžete chytit na svém soukromém e-mailu a mám blogy, mám web a blogy a profil LinkedIn. Takže neváhejte a oslovte mě na cokoli, i když to nesouvisí s produktem, pokud chcete jen mluvit o databázích, jsem geek v srdci a rád se chopím technobabble.

Eric Kavanagh: Dobře, dobře, Dez, Robine, jsem si jistý, že každý z vás má alespoň pár otázek, zbývá nám pár minut. Dez, co myslíš?

Dez Blanchfield: Mám jednu velkou otázku, na kterou se musím zeptat, sedí to vzadu v mé mysli. Jaký nejbláznivější scénář jste viděli? Přečetl jsem váš blog, pozorně vás sleduji, jste - pravděpodobně jste jedním z mála lidí, kteří žili téměř v každé nepravděpodobné, a myslím, že Dr. Robin Bloor je druhý, se kterým jsem se setkal můj život. Ale, víte, pravděpodobně jste viděli každý bláznivý scénář, jaké jsou některé z těch nejbláznivějších scénářů, které jste viděli, že jste se setkali, a jako lidské bytosti, které se prostě nedokázaly vyrovnat, se vám podařilo chodit a vykonávat Jediho myšlenkové triky s tímto celým DBArtisanem?

Bert Scalzo: Měli jsme jednoho zákazníka, který ve svém návrhu databáze velmi přemýšlel, jak by si myslel v návrhu rozložení souboru, a tak to - když normalizujete databázi, první věcí, kterou se pokusíte udělat, je zbavit se opakujících se skupin. Měli sloupec a udělali to dlouhý, nebo BLOB nebo CLOB, a v tom by dali hodnotu, číslo jedna, středník, číslo číslo dva, středník, číslo hodnoty, středník, a měli by tisíce hodnot tam, ale museli hledat v tomto sloupci a jsou jako: „Proč ta věc běží tak pomalu?“ A já jsem rád: „No, nemůžete vytvořit index toho, co jste udělali, je to jen vlastně jsme jim ukázali, pomocí plánů, že to, co potřebují udělat, je normalizovat tu tabulku. Ne proto, že normalizace je nějaké akademické cvičení, které věci vylepšuje, ale proto, že chtěli dotaz na toto pole, což znamenalo, že ho chtěli indexovat, a nemohli jste to indexovat na opakující se skupině, nebo alespoň ne snadno . A to je asi to nejhorší, co jsem kdy viděl.

Dez Blanchfield: Jo, je zajímavé, jak často se setkáváte, myslím, že výzva s databázemi, lidé zapomínají, že je to věda. A jsou tu lidé, kteří dělají tituly a PhD v tomto celém prostoru, píšou na něj papíry a psali jste celý lup včetně vašich příruček TOAD a dalších věcí z paměti. Tendence směřující k druhům „velkých dat“ citovaných na nabídku - vidím, že mnoho lidí zapomíná základy databázové architektury a databázové technologie, databázové vědy, pokud chcete. Co vidíte v terénu, co se týče posunu od tradičních databázových platforem a tradičního databázového myšlení, že jsme efektivně přibili nehty k zemi, a to byl jen případ ladění výkonu a škálování. Vidíte mnoho lidí, kteří se znovu učí a mají zkušenosti, kde tam jen tak sedí a mají „a-ha“ okamžik, jako je moment Eureka, kde si uvědomují, že tento velký datový materiál je ve skutečnosti jen druh opravdu velkých databází? Je to něco tam venku a lidé vám odpovídají zpět a tak nějak: "Zapomněli jsme, co jsme věděli a můžete nás přivést zpět z temné stránky?"

Bert Scalzo: No, ne, a to je hrozné, musím to připustit, ale prodejci relačních databází pili také Kool-Aid. Pokud si vzpomínáte, nevím, asi před deseti lety jsme začali vkládat nestrukturovaná data do relačních databází, což bylo něco zvláštního, a pak data, relační databáze, nyní přidávají typ NoSQL. věci. Ve skutečnosti v Oracle 12, CR2 - vím, že to ještě není venku - ale pokud se podíváte na beta verzi, pokud jste v beta programu, podporuje stříhání. A tak teď máte relační databázi, která nepřidala koncept z NoSQL shardingu. A tak se moment „a-ha“ zdá být spíše pro lidi na relační straně, kteří jdou „a-ha“. Nikdo to nikdy neudělá správně, dokonce ani pro správce databází, takže jsme musím jít a připojit se k temné straně.

Dez Blanchfield: Správně, takže říkáte posun k mnoha chaotickým datům, pokud to chápu správně, když jsme se dostali do toho, čemu teď říkáme velké datové platformy, což je trochu vtipné, protože jsou není to tak staré, ale to neznamená, že se pak zaměřují na to, co dělají s jejich relační databází, aby získali větší ránu za své peníze?

Bert Scalzo: Ne, obvykle, pokud mají potřebu - to by bylo citátem „potřeba velkého datového typu“, zjišťují, že místo toho, aby museli jít na jinou databázovou platformu a dělat něco jiného než - relační způsob, jak jim dodavatelé databází nyní dávají stejné ne-relační techniky uvnitř své relační databáze, aby tyto věci dělali. Dobrým příkladem by bylo, kdybyste měli nestrukturovaná data, jako je datový typ JSON nebo nějaký jiný složitý datový typ, který má význam zabudovaný do samotných dat, dodavatelé databáze to nejen podporují, ale dají vám ACID dodržování nestrukturovaných údajů. Relační databáze přijaly novější techniky a technologie, a tak se opět zdá, že „a-ha“ není víc, že ​​„Hej, my, vývojáři aplikací, jsme se něco odučili a musíme se to znovu naučit, “ je to „ „Uděláme to tímto způsobem nyní, jak to mohu udělat ve vaší tradičně relační databázi a jak to udělám v této databázi tady?“ a to se stává převládajícím a jak jsem řekl, samotní prodejci databází umožňují že.

Dez Blanchfield: Správně, kdo jsou tradiční podezřelí v tomto prostoru pro nástroj DBArtisan a to? Udělal jsem nějaké domácí úkoly ohledně toho, co jste napsal nedávno, a z paměti jste napsali něco, myslím, že to byl jeden z vašich blogů, o extrémním výkonu databáze ve světě Oracle. Nemůžu si vzpomenout, kdy to bylo, myslím, že to bylo někdy v tomto roce z paměti, nebo z konce loňského roku, co jsi napsal. A zdálo se mi, že to byl tradiční, obvyklý podezřelý pro typ tématu, o kterém dnes mluvíme, kde lidé půjdou do velmi rozsáhlého databázového prostředí a hledají to, co v něm voláte extrémní zisky. Kdo jsou obvyklí podezřelí, že tam venku vidíte, kdo se ujme DBArtisana a dobře jej využívá?

Bert Scalzo: No, máme hodně zákazníků, dnes jsem byl ve skutečnosti s velmi velkou vládní agenturou, která - a oni mají doslova pravděpodobně téměř 1 000 kopií našeho softwaru, protože to lidem umožňuje soustředit se na to, co ' dělám, a ne jak na to. A je to v pořádku, myslím, že každý by měl vědět, jak něco udělat, ale produktivita je „hotová“. Pokud mě firma požádá o provedení úkolu, to je vše, o co se zajímají. Kdy jsem dostal zaškrtnutí, abych řekl, kdy byl úkol proveden? Ne jakou techniku ​​nebo jakou techniku ​​jsem použil, abych se tam dostal. Náš nástroj jim tedy umožňuje zaměřit se na to, co je mnohem produktivnější, a to je opravdu obrovská výhoda, a jak jsem řekl, některé databáze nabízejí nástroj jen pro jejich databázovou platformu. Nabízíme ji pro dvanáct databázových platforem. Mám stejný pracovní postup, stejné grafické uživatelské rozhraní, stejné navigace. Pokud víte, jak udělit uživateli oprávnění nebo jak vytvořit tabulku nebo vytvořit index v databázi, můžete to udělat ve všech dvanácti, protože je to stejný vzhled a dojem a stejný pracovní postup. To má pro naše zákazníky obrovskou hodnotu.

Dez Blanchfield: Jo, myslím, že lidé chtějí získat mnohem víc peněz za své peníze ze svých lidských zdrojů. A dny, kdy má individuální specialista na Oracle, Ingres a DB2, jsou pryč. Očekává se, že lidé budou Jackem všech obchodů, takže si myslím, že tato věc naprosto zachránila jejich životy.

Ještě jedna poslední rychlá věc, než jsem ji předal doktorovi Robin Bloorovi. Zmínil jsi, že čtrnáct dní je zdarma ke stažení, co se děje - pokud se chystám dopředu a udělám to, mimochodem, dám to do laboratoře Bloor tech a to roztoči a zvedni se na to sám - před dneškem jsem to neměl šanci. Zmínil jste se o čtrnáctidenní zkušební verzi, řekl jste, že ji provozujete na počítači VM, předpokládám, že je to notebook. Jaké jsou, jaké je výchozí nastavení pro někoho, aby se dostal do rukou a použil čtrnáctidenní zkušební verzi, těsně předtím, než se vrátím Robinovi na jeho otázky?

Bert Scalzo: Jakékoli prostředí Windows, takže Windows 7, virtuální stroj s jedním procesorem a čtyřmi koncerty paměti. Nejsme opravdu tlustý nebo drahý nástroj. Nyní, pokud jste chtěli spustit databázový server ve stejném virtuálním počítači pod stejným Windows, ano, budete muset přidat další, ale pokud provozujete databázi na databázovém serveru nebo na samostatném virtuálním počítači, VM se načte a spustit náš produkt je velmi lehký: jeden procesor, čtyři koncerty paměti, téměř jakákoli verze systému Windows - a podporujeme instalace třicet dva, šedesát čtyři bitů. Musíte však nainstalovat klienta dodavatele databáze. Pokud se tedy chcete připojit k Oracle, musíte nainstalovat síťového klienta SQL, protože to je to, co Oracle potřebuje, abyste mohli mluvit s databází.

Dez Blanchfield: Zní to docela jednoduše. Myslím si, že jedna věc z toho více než cokoli jiného, ​​v co doufám, že si lidé vezmou, kromě toho, že si uvědomí, že tento nástroj zachrání své životy, je to, že by měli jít a stáhnout si ho a hrát si s ním, vzhledem k tomu, že nabízíte čtrnáctidenní bezplatnou zkušební verzi. A to může běžet na jejich současném notebooku bez instalace nic navíc, protože pokud již dělají správu databáze, již pracují s databázemi, mají všechny tyto nástroje na svém místě a zda běží na lokálním VM nebo na jejich na místní ploše, zní to, jako by bylo bezbolestné nainstalovat a hrát si. Takže vřele doporučuji, aby to lidé dělali.

Robine, jsem si jistý, že máš otázky a Eriku, pravděpodobně máš nějaké od publika, takže Robine, co takhle předám tobě a pak zpátky Ericovi?

Robin Bloor: Ano, dobře, no, musím říct, myslím, vždy jsem tuto oblast fascinoval, protože to bylo - řezal jsem si na ni zuby. Ale pravdou je, že asi od roku 1998, 1999, jsem se obával toho, co je Oracle ve skutečnosti schopen. A věděl jsem, že Sybase a Microsoft SQL Server jsou oba ve srovnání s tím, co by Oracle mohl udělat, celkem jednoduché. Rozčilil jsi mě, když jsi - myslím, zakryl jsem si ústa, když jsi začal mluvit o stříhání. Oracle to udělal dříve. Oracle představil v určitém okamžiku, dostali nervozitu z objektově-relační myšlenky, takže zavedli schopnost vytvářet druh notace objektů a ukládání objektů v Oracle, a já jsem mluvil s jedním z jejich inženýrů, něco jako pár roky poté, co ji představili, jsem se zeptal, kolik lidí ji použilo, a řekl, že si myslím, že to zkusili dva zákazníci a to bylo vše. A myslím si, že to samé se stane, pokud se začnou pokoušet dělat trendy v NoSQL. Víš, myslím, že je to chyba, myslím, že mě trochu zajímá, jaké jsou vaše myšlenky. Jistě, pijí Kool-Aid. Cítí se, jako by museli být schopni dělat nároky podobné velkým databázím NoSQL, jako je Cassandra, ale víte, má to pro vás nějaký smysl?

Bert Scalzo: Ne, stiskl jsi hřebík přímo na hlavu. Pro mě bych chtěl, pokud budu dělat relační, vyberu si relačního dodavatele, jako je Oracle nebo SQL Server nebo DB2 nebo Postgres, ale pokud udělám něco, co není relační, ve velkém datovém prostoru nebo v prostoru NoSQL si vyberu ten správný nástroj pro správnou práci. A nemyslím si, že by to přirozeně šlo nejprve k prodejci relační databáze. A pak k tomu přidáte další vrásky, což je, co je dostupné v cloudu? Tolik lidí, kteří chtějí dostat své databáze z předpokladu. Pak se musíte podívat na svého poskytovatele cloudu a říci: „Dobře, co poskytujete, jaké databáze máte pro mě k dispozici, které vyhovují mým potřebám a jak prodejné jsou, a upřímně řečeno, jaká je sazba nebo poplatek za použití této databáze v cloudu za hodinu nebo za den. A na gigabajt nebo terabajt? “A co najdete, možná jsou některé z relativně novějších databází, jako je Mongo nebo Cassandra, možná jejich ceny jsou levnější, takže pokud se chystáte dělat velká data typu petabyte, možná musí - z hlediska nákladů - vzít v úvahu databáze NoSQL v cloudu, protože to může být nákladově nejefektivnější způsob.

Robin Bloor: Ano, správně. Myslím, můj druh - věc o relačních databázích v mé zkušenosti - která je dost dlouhá na to, abych měla jizvy, to je jisté - existuje spousta zdravého rozumu, že pokud ji začnete aplikovat a - chápete, co to vlastně relační je, že „Myslím, že si pamatuji, že jednou budu konzultovat s jedním zákazníkem, a vedli mě do místnosti a provedli jakýsi entitní diagram a vytvořili třetí normální formu, model toho, jaké byly primární systémy společnosti. Bylo tam asi dvě stě čtyřicet stolů a oni řekli: „No, co si o tom myslíš? Budeme pro to stavět databázi, “a řekl:„ Co si o tom myslíš? “Řekl jsem:„ Nemyslím si, že to bude fungovat. “A je to přesně tak, víte, protože končily nahoru za účelem vytvoření konkrétní struktury v jedenácti spojeních. A to je to, co je třeba pochopit o relačních. Zajímalo by mě tedy, kolik špatného designu narazíte. Myslím, že nemám žádný problém s DBArtisan - dělá to velmi rozumné věci a skutečnost, že se můžete skutečně zobrazit na více platformách, myslím, je úžasná - ale jak moc se tam setkáte tam, kde je problém s designem kde se lidé mohli vyřešit sami nejrůznějšími zármutky, pokud by přišli spíše na hvězdné schéma než aby se o tom dostali sněhová vločka?

Bert Scalzo: No, nechci, aby to znělo jako drzé nebo arogantní, ale řekl bych častěji než ne. Je zřejmé, že většina databází, se kterými se tam zabývám, má problémy nebo problémy. Což je dobré, protože naše nástroje, jako je náš nástroj pro optimalizaci databází, jim mohou pomoci tyto problémy vyřešit, a co je pro mě opravdu zábavné, je to, že mnoho problémů jsou stejné jednoduché problémy znovu a znovu. Jednoho dne jsem pracoval se zákazníkem, který měl dotaz na připojení jedenácti, a já jsem rád: „Dobře, proč jsi nepoužil klauzuli s klauzulí?“ A jsou jako „No, já jsem "Nevím, co to je." A pak jsem řekl: "A podívejte se na vaše dílčí výběry zde na vaší korelované a nekorelované, " řekl jsem: "V některých případech máte ve své klauzuli kde na nejhlubší úrovni, odkaz na tabulku z vnějšku. “Řekl jsem:„ To je, přesuňte ji na správnou úroveň, nevkládejte ji hlouběji, než to musí být, zaměňte optimalizátor. “A s několika málo vylepšeními jsme vzali něco, co běželo asi dvě hodiny a snížilo to na deset minut a bylo to jen - v tom případě jsme neudělali nic jiného než vylepšili SQL, které napsali. Myslím, že problém je v tom, že mnoho univerzit a mnoho lidí, kteří se učí programování v nekademickém prostředí, se učí jako zaznamenané procesy nebo procesy orientované na řádky a relační, je soubor orientovaný přírodou, a tak vy muset myslet v sadách, aby napsal dobrý SQL.

Robin Bloor: Ano, myslím, že je to přesně tak. A musíte pochopit, že to jsou věci, lidé by měli znát ABC takových věcí. Nezáleží na tom. Nebudete moci dělat racionální věci, pokud si neuvědomíte, že i dobře navržená, dobře modelovaná databáze, spojení bude nějakou dobu trvat, druh si vyžádá čas. Dělají to proto, že svět nikdy nenašel způsob, jak je urychlit. Našli způsoby, jak organizovat data, takže jdou rychleji než jinak, a hodně nadšení, které musím pro databáze NoSQL říci, je prostě to, že se vyhýbají připojování. Právě začnou stavět databáze se stejným šířením dat v nich, protože pokud se připojíte k žádné z databází NoSQL, budou mocně sát. Nemyslíš?

Bert Scalzo: Oh absolutně. A já se musím smát, protože jsem začal cestu zpět před relační databáze a zpět, když Ingres byl RTI, Relational Technology Institute, a my jsme neměli SQL, měli jsme před-SQL relační jazyky. Myslím, že v Ingresu se tehdy nazývalo Quel. Takže jste se dostali z těchto starých databázových paradigmat, jako je síť a vyšší grafický nebo hierarchický, a projdete relačními paradigmami po několika desetiletích a teď mi připadá, že se vracíme zpět k téměř hierarchickému. Je to skoro jako bychom se vrátili.

Robin Bloor: Ano, správně. Raději vám dáme Erica, já trávím příliš mnoho času, ale máme nějaké otázky od publika, Ericu?

Eric Kavanagh: Máme, máme pár. Jdeme tady trochu dlouho, ale hodím na tebe pár. O neviditelných indexech jsme měli několik otázek. Jedna otázka byla: „Musí někdo použít váš nástroj, aby je viděl?“ Další otázkou bylo: „No, co když jste slepí?“

Bert Scalzo: To je dobrý.

Eric Kavanagh: Zvědavá otázka, tak jen FYI.

Bert Scalzo: Ne, nemusíte mít naše nástroje. To je funkce Oracle, index invisibles. V podstatě v datovém slovníku si Oracle uchovává pouze část metadat, která říká: „Optimalizátor, tento index ignorujte. Je to tady, ale pokud nejste fyzicky instruováni pomocí nápovědy v, optimalizační nápověda v příkazu SQL, nepoužívejte to. “A tak ne, nemusíte mít naše nástroje a v každém ohledu to je obyčejný starý index, můžete jej vidět v jakémkoli nástroji, je to jen optimalizátor, který řekne: „Při normálním zpracování dotazu jej budeme ignorovat.“ Musíte ho nasměrovat, pokud chcete, aby si zvykl. Je to opravdu užitečné pro scénář, který jsem popsal, což znamená, že pokud jste chtěli vytvořit index ve výrobě, ale neriskovali byste rozbití zpráv nebo věcí, které již běží, ale chtěli jste je otestovat, mohli byste to udělat. To je to, pro co je to nejužitečnější.

Eric Kavanagh: To je dobré a pak tu byla další dobrá otázka. "A co některé z těchto nových databází v paměti?" Jak změní technologie in-memory databáze hru s ohledem na indexování? “

Bert Scalzo: Chlapče, dobře - nyní je to dobré, jsem rád, že se někdo zeptal na tuto otázku, budeme muset jít další půl hodiny. Ne, v paměti, záleží na dodavateli databáze. Nyní, normálně, nemluvím nic jiného než chválu o čemkoli, co Oracle dělá, protože je to úžasná technologie, kterou postavili, ale když se odtrhnete pod pokrývkami a podíváte se, co je v paměti v Oracle, v Oracle databáze, ve skutečnosti je to stále udržované řádkové úložiště na disku a získá načtený sloupcový úložiště v paměti, a pokud není dostatek paměti pro celou tabulku, vrátí se zpět k částem; nezapadá do paměti, do řádkového úložiště, takže můžete skutečně provést výběr proti stolu a pro polovinu tabulky používáte indexování zasažení tradičních řádků u stolu a pro druhou polovinu výběr je to vlastně jde ven a jen popadl všechno z vyhledávání v paměti, a tak, to je odlišné ve způsobu, jakým SQL Server, například implementovány pomocí jejich technologie Hekaton, víte, a SQL 2014, a to bylo vylepšeno v SQL 2016, ale v některých ohledech, je jejich verze pravdivější verzí v paměti, a každá implementace má sice klady a zápory, ale musíte se podívat pod kryty a uvědomit si. Protože jsem měl zákazníka, který řekl: „Ach, tato tabulka je v paměti - já budu sestavovat všechny indexy, “ a já jsem rád, „Tabulka je větší než paměť, kterou máte na serveru, takže v určitém okamžiku musí nějaký dotaz zasáhnout disk. “

Eric Kavanagh: To je dobrý popis; to je dobré. Lidi, budeme mít ještě pár webcastů s těmito kluky po zbytek letošního roku, vraťte se kdykoli budete slyšet o Bertovi na prezentaci, protože víme, že zná jeho věci. Je vždy zábavné mluvit s odborníky. Všechna tato webová vysílání archivujeme pro pozdější prohlížení. Zde jsou kontaktní informace Bert znovu a my se pokusíme tento odkaz stáhnout ke stažení a poslat jej také e-mailem, ale vždy můžete e-mailem zaslat opravdu:, máme pro to spoustu dalších webcastů rok a my teď děláme ed cal právě teď, takže, lidi, pokud existují nějaká témata, o kterých si chcete příští rok opravdu zaslechnout, nestyďte se: Postarej se, lidi, budeme si s tebou povídat příště. Ahoj.

Partner obsahu Techopedia

Zaměstnanci Techopedia jsou spojeni se společností Bloor Group a lze je kontaktovat pomocí možností na pravé straně. Informace o tom, jak spolupracujeme s průmyslovými partnery, najdete zde.

• Profil
• webová stránka