Съдържание:
От служители на Techopedia, 5 октомври 2016 г.
Отнемане: Домакинът Ерик Кавана обсъжда индексирането на базата данни с д-р Робин Блур, Дез Бланчфийлд и Берт Скалцо на IDERA.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Партньор за съдържание на Techopedia
Персоналът на Techopedia е свързан с Bloor Group и може да се свърже с тях, като използвате опциите вдясно. За информация как работим с партньорите в бранша, кликнете тук.- Профил
- уебсайт
Ерик Кавана: Дами и господа, здравей, и добре дошли отново. Сряда, в четири часа източно, и тези от вас, които познават програмата, знаят какво означава това, време е за поредния епизод на Hot Technologies. Да, именно. Казвам се Ерик Кавана, ще бъда ваш модератор за днешната сесия: „Индекс на лудост: Как да избегнем хаос на базата данни“. Или както го споменах при последния взрив по електронната поща, който се разрастваше, „борба с база данни“. Горещ термин в наши дни, „борба“. Всички го правят. Има слайд за вашия наистина. И достатъчно за мен.
И така, серията Hot Technology наистина е създадена да определи определено пространство, за разлика от Briefing Room, който е само брифинг на живо за анализатори на живо, за Hot Tech получаваме двама анализатори. Днес това ще бъде нашия собствен доктор Робин Блур и нашия учен по данни Дез Бланчфийлд. И говорим за тема, която според мен наистина е доста емблематична за случващото се на пазара днес.
Изводът е, че днес сме в свят на сложност. Наистина, ако се сещате за петнайсет или двадесет години, тогава това беше съвсем различен свят, особено що се отнася до технологията на базата данни. Базите данни са били доста прости. Имаше само шепа от тях; повечето от тях бяха релационни. Сега имаме цялата тази панорама от бази данни технологии. Буквално има десетки опции на масата за всеки, който иска да изгради приложение или да направи нещо с данни. Всичко се променя и това се отразява на хората, които се опитват да управляват тези системи. Днес ще говорим с Берт Скалцо, който е истински експерт в тази област; той е старши мениджър на продукти за IDERA, за това какво можете да направите, за да се справите с всички тези данни. С това ще го предам на доктор Робин Блур, за да го отнеме. Робин, пода е твой.
Робин Блур: Добре, благодаря за това въведение. Мисля, че - тъй като това е нещо с две ръце, мисля, че просто бих говорил за оптимизация на базата данни като цяло като въведение в това Hot Tech шоу. Започнах живота - в технологиите и анализите - започнах живота, правейки това, защото писах статии за възможностите на базите данни на платформата DEC VAX. И по тази причина служителите на базата данни използваха, за да ме информират. И това, което ми се случва, е, че защо да имате база данни? Искам да кажа, че в онези дни страшно много хора използваха да създават ключови файлове със стойност и да използват такива, за да имат вид последователна грешка в индекса, както ги наричаме, но за да създадат вид способност на база данни и знаете ли, защо бихте имали нещо друго?
И отговорът на това, мисля, че Майкъл Стоунбракър даде най-добрия отговор на това и той каза: „Базата данни може да знае повече за това къде са данните и колко бързо да ги получи, отколкото някоя програма може да знае някога“. И мисля, че това е интересно; това е естеството на играта. Но през 19 - около 1989 г., който започнах в технологичния анализ и знаете, в този момент, базите данни бяха много прости и релационните бази данни бяха супер прости. Те имаха толкова малко възможности, искам да кажа, че можеха да съхраняват данни, очевидно, и вие можехте да архивирате и те имаха, те бяха съвместими с ACID, но наистина имаха много слаби оптимизатори. Всъщност би било трудно да се спори, че те изобщо са имали възможност за оптимизация.
По-късно те просто стават все по-добри и по-добри, но, знаете, когато база данни не функционира - тъй като тези кенгуру изглежда по един или друг начин указват - може да има ужасно много причини, поради които върви бавно. И това ме довежда дотам: Базите данни имат много функции, но най-важната е оптимизация на заявките. Ако те не го направиха, нямаше да ги използвате. Става въпрос за бързото получаване на информация, за това, че можете да го правите, когато има много едновременни потребители, и това е сериозен проблем. И когато всъщност погледнете към, нека ги наречем зрели бази данни, ако желаете - но със сигурност Oracle, в малко по-малка степен, Microsoft SQL Server, със сигурност Teradata и DB2 - оптимизаторите на тези бази данни са били десетилетия в сграда. Знаеш ли, те не - някой не седна на - шест момчета на двама души, година, проект и просто събори едно. Не работи така. Възможността за оптимизация постепенно нараства и отнема много растеж. Както и да е, нека да поговорим за фона на базата данни. Е, има много неща, които се говори за базата данни на NoSQL сега, и дори има голям ентусиазъм за графичната база данни. И използването на SQL над Hadoop и подобни неща. Но истината на въпроса е, че ако искате база данни в момента, ако искате напълно функционална, способна на OLTP и голям трафик на заявки, това е релационна база данни или това не е нищо.
Сред релационните бази данни Oracle е доминираща по популярност. Microsoft SQL Server, според мен, е на второ място. И двамата могат да се използват за OLTP и заявка за натоварване, но всъщност наистина не можете да избягате от смесването на тези натоварвания. Имате нужда от различни инциденти за OLTP натоварвания и заявки натоварвания. Има алтернативи на SQL и графика. Повечето компании се стандартизират в една конкретна база данни, поради което - искам да кажа, че след десетилетия на борбата с всички останали играчи Oracle стана най-доминиращата. Просто защото в крайна сметка успяха да продават корпоративни лицензи и така компаниите биха използвали само алтернативни продукти в изключителни продукти Oracle просто не биха ги направили. И базите данни са стратегически в това, че те също се развиват. И знаете, че направих малко проучване за тази презентация и това е нещо - ще дойда до нея след време, но е интересно как те се развиват, от гледна точка на това да го гледам от позицията на DBA. Това наричам невидимата тенденция. Законът на Мур е на кубчета. Това е приблизително така: Най-голямата база данни е и новите бази данни, няма стара база данни, която да има много повече данни за поглъщане. Обикновено това е база данни, която се прилага към нов проблем. И всъщност нарастват по отношение на обемите на данни. Грубо на куба на Мур закон. Така че законът на Мур е фактор десет пъти на всеки шест години. VLDB са склонни да нарастват фактор от хиляда на всеки шест години. През 1991, 1992 г. големите бази данни се измерват като мегабайти. През '97 и '98 г. гигабайти. 2003, '4, терабайти. 2009 г., 10 г., започнахте да виждате петабайтови бази данни. Мисля, че в момента е имало една или две екбабайтни бази данни, но най-голямото, за което съм чувал, е 200 петабайта навреме и знаете, не получаване на данни в петабайтови бази данни. Но повечето от това очевидно ще са новите големи уеб 2.0 компании, вероятно вие имате Facebook да се насочи в тази посока.
Но така или иначе, ако всъщност погледнете това, очаквайки база данни да премине през подобен вид ескалация, това изисква много. И забележително е, че със сигурност до ниво на петабайт те изглежда са се справили доста добре. Искам да кажа, че говоря за по-старите продукти, а не за нещо ново. Изглежда са се справили изключително добре. Ако погледнем производителността на базата данни, тесните места, това ме връща към времето, в което всъщност се грижех за тях, и трябваше да се тревожа за тях. Знаете, че това е по същество повредата на хардуера. Има затруднения на процесора, евентуално, има затруднения в паметта, евентуално, има и дискови затруднения. Може да бъде мрежата, която ви причинява мъка и можете също да получите проблеми с заключването, в зависимост от това какво правите, но обикновено това е така, защото програмата не знае на кого да се обади. Така че, ако ще настроите база данни, всъщност се опитвате да я настроите така, че да танцува между тези пет възможни затруднения, както и да прави. И това не е лесно, защото количеството памет, което бихте могли да конфигурирате на всеки даден сървър, се увеличава драстично. Тогава процесорите са станали многоядрени, дискови, добре, че сега можем да направим, мисля, че дори и на стоковите сървъри, мисля, че можете да направите стотици и стотици терабайти, четвърт петабайт, може би дори на стоков сървър. Така че от всички тези неща, с които можете да играете, мрежата, разбира се, може да върви с различна скорост, но най-вече, когато се занимавате с бази данни, наистина искате да имате кабелни влакна между сървърите и нищо друго да не работи на това, особено по този начин.
Фактори за ефективност на базата данни Искам да кажа, че изоставям за какво става дума, защото знам, че Дез ще говори за това, но лошият дизайн на база данни означава лошо работеща база данни. Лош дизайн на програмиране може да означава хвърляне на много глупав SQL в база данни, което просто ще отнеме доста страшно повече. Съвместното смесване и смесването на работното натоварване, твърде много паралелност ще доведе до проблеми с недостига на място. Смесването на работното натоварване, когато имате големи заявки с много малки, кратки, остри заявки, което причинява проблеми. Има проблем с балансирането на натоварването. Повечето бази данни се грижат за това, но ако нямате сложен продукт, тогава знаете, че просто добавянето на няколко сървъра не е всичко, което искате да направите, ако действително искате да увеличите размера на клъстер. Всъщност трябва да балансирате натоварването, преди да постигнете оптимална производителност. Трябва да направите планиране на капацитета. Абсолютно. Особено сега в тези дни, когато обема на данни се увеличава по-драматично, отколкото преди за базите данни. И има проблеми с целия слой данни за това как приемате данните, как премествате данни. Не получаването на данни в база данни навреме може да бъде проблем с производителността по-късно, тъй като сме преминали от бази данни, работещи в Windows, до двадесет и четири на седем от триста седемдесет и пет операции и няма прозорци, където да забавите забавянето база данни или е малко вероятно да има в днешно време.
Проблемът с OBA DBA. За това си мислех. Бил съм в DBA на Oracle с Oracle 7 и си спомням как да настроя това. И ако всъщност погледнете Oracle сега, това е начин, начин - има начин, начин повече възможности. Има индексиране на растерни карти и подобни неща, но всъщност отделих време да разгледам и видя колко параметри за настройка всъщност има в базата данни на Oracle в момента. И има над триста и петдесет настройки за настройка и има още сто скрити параметри, за които специалистите DBA може да знаят, но нормалните DBA за Oracle не знаят. А това означава, че настройката на този вид база данни е трудно. Това изобщо не е просто нещо. Трябва да имате усещане за това, трябва да го правите дълго, дълго време и трябва да знаете точно какъв проблем смятате, че решавате, защото настройката започва, когато представянето става лошо, но може да не е изпълнението на всичко. Може да са важни изпълнението на конкретни заявки и може да успеете да поправите това чрез фиксиране на определени данни и памет или може да се наложи да го поправите чрез индексиране или може да се наложи да започнете да правите дял по друг начин. Има много неща, които можете да направите, е въпросът. Така че, следователно, те няма да го правят в главата си - DBA се нуждаят от инструменти. Сега ще предам на Дез, който ще ви каже за индексирането, мисля.
Ерик Кавана: Добре Дез, отнеси го.
Дез Бланчфийлд: Благодаря ти, Робин, и аз обичам титулната страница. Мисля, че си хвърлил ръкавицата там, за да дойда дори да се приближа отдалеч до нещо толкова вълнуващо. Но използвах изображение на нашата малка галактика, като моето виждане за това, в което се превърна днешното предизвикателство за администраторите на бази данни, защото това е менталният образ, който съм склонен да си представя, когато попадна в среда и вече не съм в света на администриране на бази данни или проектиране на бази данни на това ниво вече. Но, като себе си, Робин и аз имахме много години да участваме в света на базите данни, като администратор или разработчик, или в крайна сметка архитект, и след това разбрах, че мога да направя по-добри неща, за да спечеля коричка. Но има чувството, че се взирате в тази плеяда от данни и още повече, че днес, когато сме тръгнали от, както очертахте, преминахме от мегабайти към петабайт и екзо-мащаб за много кратък период от време, в голямата схема на нещата. Но фразата, която имам в ума си, е, че индексите на базата данни вече са черно изкуство и всъщност не са такива неща, в които простосмъртните би трябвало да се занимават, за бизнес приложения и за типа на формулирането ви просто говореха. Но, исках да премина през бърза крачка от типа история, която съм имал със световете от бази данни, и да доведа контекста до мястото, където ще направим заключение, и след това да разгледаме материал днес с нашите приятели на IDERA, защото мисля, че има много различни мисли за това как да се настрои производителността на базата данни и една от тях е хвърляне на калай върху нещата. За много магазини, на които се натъквам, те неизменно стигат до това, че правят настройка на производителността на слоя база данни и по-специално индексния слой, докато не преминат през трудния начин на мислене, че могат да хвърлят тунер в него,
Много хора просто предприемат голям железен подход към него, и аз имам снимка на The Flash тук, защото ако някога сте гледали стари филми или със сигурност най-новото телевизионно шоу с The Flash, както в Флаш Гордън старият герой и сега, когато той се нарича „Светкавицата“, той е склонен да върви много, много бързо и неизменно енергията му изтича. И това се случва, когато хвърляте голямо желязо при изпълнение на базата данни. Неизменно от моя опит можете да поставите висока производителност, упорита работа в играта, можете да оптимизирате операционните си системи и да ги настроите до определен момент. Можете да гарантирате, че имате бързи многоядрени, многоредови процесори, за да накарате приложението да работи по-бързо, можете да хвърляте много RAM в него, можете да имате задни пластове с висока пропускателна способност, можете да преминете от твърди дискове до кеширане на твърди дискове в твърдо състояние и високоефективен масив за съхранение. И дори сега хората влагат неща като flash и NVMe в своите двигатели на базата данни, мислейки, че ще получат това влизане в пъти два печалби от производителността. И неизменно получават някаква печалба. Но всичко това се връща към същите основни проблеми с настройката на производителността. Много мрежови връзки с ниска латентност, така че клъстерите да работят бързо. И на клъстеризиране на база данни, така че имате повече от една машина, която върши цялата работа. Но вие сте склонни да се върнете към същия основен проблем с производителността, а това е четенето на данни. Писането на данни в по-голямата си част е доста линейно предизвикателство и освен ако не е направено правилно.
И тогава имаме предизвикателството в днешния свят: Не всички бази данни са създадени равни. Има бази данни и „база данни с цитат по цитат“. И когато мислим за двигатели на бази данни, хората често мислят за традиционните, обичайни заподозрени, каквито са били в света на SQL. Знаеш ли, ние имаме Oracle и Microsoft SQL Server и има няколко около него в света с отворен код с MySQL, който сега е собственост на Oracle, но все още е с отворен код. И тогава имаме не особено обичайните заподозрени, NoSQL двигателите, които все още имат проблем с индексирането и управлението на производителността, и аз няма да вляза в тях много подробно, но има все по-голям брой от тях нещата се появяват всеки ден и изглеждат и се чувстват като двигатели на база данни от гледна точка на разработчиците и от гледна точка на производителността, но те са много, много различни зверове и имат своя собствена малка ниша в света, която да издълбае или производителност в паметта или линейна скала на диска. Но така изглежда светът в света на базата данни. Това е 2016 г., това е версията три на картата на, от редица хора, които произвеждат тази текуща пейзажна карта на това как изглеждат базите данни, и това е мястото, където дори не може да има смисъл дори свръхчовешки архитект на база данни или администратор на база данни от него. Буквално стотици и стотици и стотици различни марки, модели, производители на бази данни, неизменно съвместими със SQL. И интересното е, че всички те се връщат към едно и също предизвикателство. Настройка на производителността и производителността около двигателя на базата данни и по-специално от начина на индексиране на данните.
Затова нека бързо да обхванем индексирането на базата данни, защото това е интересна тема и трябва да влезете в нея по-подробно с демонстрацията, вярвам. Но мисля, че е доста добре приета и стандартна индустриална практика, че настройката на производителността на индексите на базата данни е мястото, където светът започва и свършва до осигуряване на достъп до вашите данни в бърз и бърз формат. Но какво е индексиране на база данни? Ако мислим за индексиране под формата, с която сме свикнали като всекидневни хора, помислете за индексна страница в книга. Ако искате да намерите нещо в книга - по-специално харесвания на енциклопедия или нещо като референтен материал от някаква форма - ако търсите нещо като тази страница, където търся неща като темата на язовирите в енциклопедия. Искам да намеря всяка препратка към язовирите, водосбора и голяма застроена площ, създадена от човека като цяло. Ще отида отзад, ще го намеря в азбучен, подреден списък, от A до Z, отляво надясно и ще намеря D. Ще намеря думата „язовири“ и мога да видя това на страници 16, 38, 41 има препратка към тях и тогава мога да отида на тези страници, мога да сканирам очите си и ще намеря позоваването на думата „язовир“. По същество това е същата концепция в база данни, но това е ракетна наука по много начини. Толкова много, че всеки администратор на база данни, който някога съм познавал добре, счита, че индексите са единственият най-критичен инструмент за настройка на производителността във всеки свят на базата данни, независимо от това какъв е опитът им, що се отнася до хвърлянето на калай върху него, или какъвто и да е случаят.
Като цяло, когато говорим за индексиране на база данни, има редица общи подходи. И колкото по-сложни стават индексите на базата данни, толкова по-сложен е подходът за индексиране на данни. Но по същество, когато мислите за индексиране на данни - представете си, че имаме файл, който има списък с имена; те не могат да бъдат сортирани по азбучен ред. Нека си представим, че има двадесет от тях. Ако ще сортираме - ако ще търсим данни в този списък, отгоре надолу и нека кажем, че това е списък с имена. Ако избера произволно име и започнем да превъртам този списък отгоре надолу, в линеен формат и това е нередовен списък, има два критерия, за които мисля като средното ми време за търсене и максималното ми време за търсене - и Въведох грешка във втория ред, трябва да е „максимално време за търсене“, съжалявам - но средното ми време за търсене по същество е N плюс едно, разделено на две и това е средно, отнема ми петдесет процента от времето да сканирате от върха на списъка, до дъното на списъка, за да намерите всяко произволно нещо в този списък. И вторият ред там, под линеен, трябва да бъде „максимално време за търсене.“ Но максималното време за търсене по същество е броят на елементите и това е, че ако имам списък от двадесет неща, най-много време може да ми отнеме да търсите нещо в тази база данни е да отидете от върха към дъното, което е да речем 20 елемента в този опростен пример. И това е много бавен процес и наистина няма начин да се настрои това. И тогава има други видове начини за вземане на тези данни и създаване на индекс, който е накратко кратък списък от указатели на мястото, където са действителните данни, като двоични, B-дърво, растерна карта, хеширане, клъстерирани и некластерирани, и след това има различни видове данни като пространствени, филтрирани, XML и пълен текст.
Binary е много често използван за неща, при които данните се поддават на него. B-дървото е вероятно най-често срещаното в общ смисъл в исторически план, тъй като това е общ начин да се структурира индекс към всяка форма на данни и позволява на логърите, селекциите и вмъкванията и изтриванията да са сравнително лесни, докато местите указатели около позоваване на указателите, точките. Има и други типове, като растерна карта, при които типовете данни се отнасят, ако имаме свързан диапазон от някаква форма. Хеширането работи много добре за големи обекти, особено за блогове и изображения. И можете да видите, че има редица различни видове научни подходи, математически подходи за индексиране на данни. За простосмъртните те са интересно предизвикателство да говорят на това ниво. Когато говорите за това на ниво производителност за администратор на база данни, те наистина стават ракетен учен и хората правят степени в тях, и аз знам, че доктор Робин Блуър със сигурност е направил това и е написал книги за това за харесване на IBM и други големи марки през последните няколко десетилетия. И така, моето мнение, е, че всъщност сме минали време, в което, знаете, веднъж, аз лично бих могъл да седна пред една система и бих могъл да я разглобя и да ви покажа точно там, където проблемите с производителността са били в команден ред или в инструмент за стартиране на графичен потребителски интерфейс, и започнете да задълбочавате данните и да ви казвам къде са били проблемите, и изграждайте индекси, подиндекси или първични и вторични индекси в това данни и започнете да го използвате, за да намерите неща. Но когато мислите за този пейзаж, ви показах, където имаме стотици и стотици марки, марки и модели, производители и видове бази данни, ние сме добре и наистина миналото на това време, където човек може да направи усещане за типовете двигатели на бази данни, които имаме. По-специално, дори ако просто се върнем към харесванията на Oracle, преобладаващите марки в наши дни в релационни платформи от бази данни.
Броят на базите данни, с които трябва да се справят или от собствена платформа като ERP или HR или финансова система, или дали те са домашна платформа по различни причини, броя на базите данни и таблиците на бази данни и записи, които в крайна сметка да се занимавате само с астрономически и физически не можете да го направите на ръка. И сега имахме допълнително усложнение, където навремето сървър на база данни може просто да седи под бюрото ви. Знаеш ли, като малко дете след училище, аз ходех и работех върху софтуер за бази данни в първоначално Apple IIes, а след това и на базирани на DOS PC базирани системи, като dBase II, dBase III, премина през епоха с мейнфрейми и средна- обхват и дори VAXs и PDPs и лог файл за това. И подобно на Saber, и в крайна сметка, когато някои от SQL базите данни се появиха. Но тези дни, когато мислим за двигатели на базата данни, те изглеждат като долния ляв ъгъл. Сървърът на база данни вече не е само една машина, седнала на пода под бюро; това са стотици машини, работещи с копия на двигатели на бази данни и клъстери, и те мащабят до стотици и стотици терабайти данни, ако не петабайти данни, което е хиляди терабайти. И дори до крайност, както доктор Робин Блуър спомена, че някои конкретни случаи на употреба - авиокомпании, по-специално правителствени агенции - могат да стигнат до екзабайти. Те все още са доста ниши-у, но стотици терабайти и дори десетки петабайти вече не са необичайни, особено от бут дотком до сега, нещо като това, което наричаме уеб 2.0 компании, като Facebook, Google, Yahoo и така нататък.
Имаме и усложнението сега, когато нещата преминават към външно обслужване. Имаме инфраструктурна платформа и софтуер като сервизен подход, предоставящ инфраструктура. И по-специално платформа услуга, където не можем просто да купим за харесване на Oracle и тяхната облачна платформа, бази данни и сървъри. И така това ни позволява да правим много бързо развитие на приложението и просто да включим база данни обратно в сървърите. Не е нужно да мислим какво се крие под капака. Недостатъкът е, че често не се замисляме как да проектираме и внедряваме базата данни обратно, докато тя не навреди и производителността стане проблем и тогава трябва да търсим правилния инструмент, който да диагностицира защо нашата база данни боли и където са проблемите с представянето. И неизменно го връща към онзи често срещан проблем за това как сме индексирали тези данни и типовете индекси, които сме използвали за тези данни, и след това ни връща към изискването за свръхчовешко изпълнение. И някой, който има достъп до правилните системи и правилните инструменти за работа, настройва тези двигатели, и започне да намира гореща точка и да погледне къде са заявките, къде се движат данните, видовете заявки, как са структурирани заявките, кой прави заявките и дали заявките са поставени на опашка и трябва да бъдат кеширани. Каква репликация търсите?
И така според мен сме добре и наистина - според мен - в момента, в който дори най-добрите гурута на база данни в света, по същество нашите архитекти на бази данни и нашия администратор на бази данни и бази за производителност, според мен те много трябва да започнат да използват правилните инструменти за осигуряване на оптимална настройка на индекс на производителност за всеки двигател на база данни. Тъй като мащабът, с който се занимаваме, и скоростта, с която се движат нещата, ние просто не можем да го направим на ръка и опитът да го направим неизменно може да въведе други проблеми с производителността, защото може да нямаме опит в това пространство, ние се опитваме да разрешим проблем. И вярвам, че точно тук ще предадем на Берт и ще поговорим за това как са решили този разнообразен проблем и вида на нещата, които техният инструмент може направете, особено за света на Oracle. И с това там, Берт, ще предам на теб.
Берт Скалцо: Благодаря. Добре дошли всички, казвам се Берт Скалцо, работя за IDERA. Аз съм старши продуктов мениджър за някои от нашите продукти от база данни. Ще демонстрирам някои от тях днес. Но искам да говоря за индекси, защото съм съгласен с всичко, което всички казаха тук, особено последния слайд, че индексите са толкова сложни сега, че се нуждаете от инструмент и се надявам да ви убедя. Така че дизайнът на индекс Oracle не е толкова лесен, колкото преди. Много хора няма да са сигурни в себе си, когато погледнат вариантите, и ми харесва това, което казвах, че се оттеглих от историята, „по тези въпроси единствената сигурност е, че нищо не е сигурно.“ И така се чувствам помислете за индексите в наши дни, защото дори и да мислите, че знаете отговора на вас, трябва да индексирате X, Y или Z, наистина не можете да сте сигурни, докато не го изпробвате, защото тези оптимизатори понякога се държат по различен начин, както очаквате. И така при проектирането на индекси има много опити и грешки. Сега, в добрите стари времена, ако имате нужда от индекс, обикновено имаше само два въпроса или един въпрос. Уникален ли беше или не беше уникален? И може би сте се сетили за други неща като „Колко индекси мога да имам максимум на една таблица?“, Защото твърде много индекси забавят вашите вмъквания, актуализации и изтривания. Може също да сте били в системата на вашата база данни, да сте имали ограничения за това, колко колони могат да бъдат в много колонен индекс, защото понякога имаше ограничения въз основа на размера на страницата или блока на вашата машина на базата данни, но в действителност това беше доста просто обратно в добрите стари времена. Или сте го индексирали, или не сте го направили. И наистина всичко беше в B-дърво. Бихме могли да допуснем дублиранията или не и това беше за това. Животът беше добър, животът беше прост.
Е, днес животът не е толкова добър или толкова прост. Поставих червения знак Ghostbuster по начина, по който бяхме правили, защото сега имаме B-tree срещу bitmap, срещу bitmap. И ще ми обясня какви са някои от тях за миг. Клъстерирани и не клъстерирани, уникални или дублиращи се, напред или назад ред, базирани на функции, разделени или не разделени. Ако има дял, дали е глобален или локален дял? Ще обясня и това. И тогава също има нещо, наречено индексирана организирана таблица. И всъщност са останали половин дузина други, които съм оставил тук, защото мисля, че сега имам достатъчно, което трябва да ви убеди, че индексите са много по-трудни, отколкото може би сте предполагали. В този конкретен слайд ще започна в горната лява част на диаграмата и имам таблица. И първото нещо, което трябва да реша е, в зависимост от версията на вашата база данни и вашия доставчик на база данни, допускат ли обектни таблици или те са само релационни? Ще сляза от дясната страна и ще кажа, че изграждаме релационна таблица. Следващият въпрос, който трябва да си задам, е дали е в клъстер? И много от вас, които сте правили Oracle за известно време, ще си спомняте, че клъстерите са се върнали за Oracle 6 дни. Вероятно те вече не се използват много силно днес, но нека първо да спусна този клон.
Ако щях да сложа таблицата си в клъстер, ще трябва да имам клъстериран индекс на тази таблица. Сега в Oracle, когато обединявате таблица, основно съхранявате редовете или редовете бяха близо един до друг, където стойностите бяха сходни. И така, трябва да имате клъстериран индекс и този клъстериран индекс може да бъде неразделен. С други думи, всъщност нямаше никакви методи за разделяне за това как бихте направили клъстерирана таблица. Беше строго неразделен. И тъй като беше неразделна, беше глобална. Ще ви обясня какво е глобално след минута. И винаги беше B-дърво. С други думи, когато слязох в този клон, беше доста просто, нямах много възможности за избор. Сега, ако направих некластериран индекс на клъстерирана таблица, което беше разрешено в някои версии, отново беше неразделен; когато не е разделен, тогава единственият ви избор е глобален. И така, там имате избор на B-дърво или растерна карта. Отново, това зависи от вашата версия на базата данни. Но сега нека се върнем към релационната таблица и започнем да слизаме отново по дясната страна и сега просто ще имаме обикновена, стара, правилна, нагъната маса: релационна. Ще бъде в пространство на масата. Тук най-напред слизам по дясната страна. Така че това е организация, купи. Следващият въпрос, който трябва да си задам, е: „Искам ли да разделям тази таблица или не?“ Понякога понякога бихте разделили, защото си помислихте: „Ей, оптимизаторът ще бъде по-умен как може да оптимизира заявките. „Но много DBA ще ви кажат, че причината за това е за административни цели. Ако имате таблица със сто милиарда редове, ако я разделите на дялове или кофи, когато искате да добавите данни към последната кофа, можете да пуснете и индексирате това само на няколко милиона реда. Можете да поставите тези данни и след това можете да възстановите този индекс само в тази кофа.
Въпреки че беше добра техника за някои, техники за оптимизация като елиминиране на дялове, истинската му стойност беше в състояние да администрира или да извършва административни задачи на по-малки части. Когато отида на организационната купа, първият въпрос беше: „Разделих ли го или не?“ Нека отидем вляво, няма да разделям масата. Сега може да изглежда странно, когато ви кажа това, но бихте могли да имате неразделена таблица и тогава не можете да разделите индекса, както сте свикнали, или можете да разделите индекса. Спрете и помислете. Вашата маса има основно една кофа, както винаги сте мислили, и въпреки това вашият индекс ще има няколко кофи. Когато това се случи, когато има несъответствие между броя на кофите и таблицата и броя на кофите в индекса, това се разбира от глобалната. И така, ако таблицата не е разделена и ако индексът е разделен, това се счита за глобално, защото има несъответствие. Сега, нека да се върна обратно на групата на организацията си, и да сляза вместо на дяла. Сега, ако имам таблица с дялове и да кажем, че таблицата има четири кофи, четири дяла, индексът ми може да има четири кофи, така че индексът да съответства на дизайна на таблицата ми. И така, отдясно, от дясната страна. Това ще се счита за местно. Локален индекс означава основно, че разделянето на таблицата и индекса се извършва по един и същи начин и има един и същ брой кофи. И тогава, след като имам локалния индекс, това може да е B-дърво или растерна карта и тази зелена стрелка, която върви нагоре, ви показва, че дори и да е B-дърво, все още има избор, който би могъл да бъде направен. Може да се основава на функция. И също така, ако това е растерна карта, има различни видове растерни карти. Има нещо, наречено индекс на присъединяване към растерна карта. Ако правите съхранение на данни, това е много популярен вид индекс за звездна схема или дизайн. Това, което се случва, е, че индексът има идентификатори на редове за това, на което сочи в таблицата, но ще има и идентификатори на редове за родителските таблици, така че когато сте - трябва да стартирате дизайн на схемата със звезда и търсите в таблица с факти, този индекс на таблицата с факти ви насочва към данните, които ви интересуват, и ви насочва към всеки ред във вашите измерения, така че трябва да имате само един индекс.
И всъщност това се появи заради Red Brick, който беше база данни преди много години - много хора може да си спомнят това. И така, ако погледнете тази снимка - и имайте предвид, че не съм сложил всичко в тази картина, защото картината ще бъде много по-голяма - все още има допълнителни проблеми, които имам в текста тук в горната дясна част, Индексът с обратен ред ли е? И може да кажете: „Защо бих искал индекс на обратен ред? Това няма никакъв смисъл. "Е, ако сте в клъстерирана среда в Oracle, ако правите реални клъстери за приложения, ако поддържате индексите си в ред, така че да не са обърнати, ако имате много обработка, която е удряща. същите стойности или същите стойности на индекса, това, което би се случило, бихте имали горещи области на вашето B-дърво. Това означава, че бихте имали спор и евентуално заключване, за да опитате и да получите достъп до тези неща, и ще го правите през възли в мрежа. Е, ако поставите индекс с обратен ред, сега можете да отмените това. Можете да кажете: „Е, сходните стойности са в различни части на дърветата, така че нямам моите отделни възли да се състезават за горещи зони в дървото.“ И тогава забележете също, че уникалният не работи с някои от опциите, Ако погледнете, аз съм номерирал три, пет, осем и единадесет, така че има случаи, в които не мога да имам уникален индекс. По същия начин има някои случаи, при които не мога да имам обратен индекс, а след това има допълнителни проблеми като регистрация или не регистриране, както и паралелни и непаралелни. Мога да присвоя нещата на определена област в паметта.
И това оставя все още доста функции в Oracle. Бих казал, че когато погледнете Oracle 12, вероятно отново има около половин дузина неща, които бих могъл да добавя към тази картина. Индексирането е наистина сложно и наистина съм съгласен с предишния говорител, за да се ориентирате по това и да направите добър избор, ви е необходим инструмент. Имате нужда от, може би, подобна картина и някаква методология за това как бихте избрали нещата и се надяваме инструментът да ви помогне да стигнете до там. И тогава ще бъде опит и грешка. Винаги казвам на хората да индексират: „погледни, преди да скочиш“. И тогава можете да видите малкото куче тук, той скача без да гледа, ще се озове във водата с акулата или човекът, който се готви да скочи във водата и той ще се надуе. Трябва да помислите за индексирането си, защото създаването на индекс не винаги означава, че нещата се подобряват. Всъщност създаването на индекс може да забави нещата. И изпълнението на заявките може да бъде с порядък по-добър с един избор над друг. И ще ви дам един добър пример. Ако правите звездна схема на дизайна и в таблиците си с размерите използвате индекси на растерни карти в един случай, а в друг случай казвате: „Ще използвам индекси на B-tree“, имате битмап срещу B- дърво. Мога да ви кажа, че едно решение ще бъде с порядък или евентуално с няколко порядъка по-бързо от другото. Но имайте предвид, че това, което работи в една среда, например в среда за съхранение на данни, вероятно не е добър избор в OLTP среда.
Например, ако трябваше да вземете таблица на транзакциите и да поставите растерни индекси на транзакционна таблица, е скъпо да се изчислят и нулират растерни, тези дълги низове и така в OLTP таблица, можете да ударите таблицата толкова силно, че растерната карта индексът може да се повреди и да забави системата ви, защото те просто не са предназначени за актуализации. Те са чудесни за бърз достъп, но не са добри за актуализации. Наистина мисля, че индексът взема опити и грешки. Наистина вече няма златно правило - в това уравнение има твърде много различни променливи, за да знаете - и в крайна сметка ще трябва да погледнете изпълнението или да обясните планове в базата си, за да видите дали правите добър избор. И понякога анализът на плана почти може да бъде наука за себе си. Днес няма да обхващам това - това е друга тема - но не приемайте индексния дизайн за даденост. Има основателни причини, поради които има всички тези луди типове индекси, които ви показах, в предходната снимка и за това говори предишният оратор. Те не бяха просто създадени, защото беше чиста функция да се постави на контролен списък някъде за доставчик на база данни; има случаи или сценарии за използване, при които тези индекси са важни и ще направят значителна разлика. Сега с това ще ви покажа няколко примера за различни видове индекси в един от нашите инструменти. Нека просто вдигна екрана си, за да го видите. Добре, така че тук съм седнал - нека минимизирам това приложение. Седя вътре във VMware и изпълнявам VM на Windows Server 2012.
И можете да видите, имам почти всеки инструмент, познат на човека. Като продуктов мениджър трябва да съм наясно с конкуренцията си, така че не е само какви инструменти имам, а какво правят моите конкуренти? И тук имаме този инструмент, наречен DBArtisan, който вече пуснах, но отивам - така че просто ще го донеса. И това, което можете да видите, е, че това е наистина приятен инструмент, защото вместо да се налага да използвате, кажете корпоративен мениджър за Oracle и SQL Management Studio за SQL Server, MySQL Workbench за MySQL и дванадесет други бази данни, които поддържаме, добре, че имам вградени всички мои бази данни в този един инструмент. Има DB2, има MySQL, Oracle, Postgres, SQL Server и Sybase и това е - имам само шест бази данни в това конкретно нещо, защото не мога - инструментът поддържа дванадесет бази данни, но моят лош VM, работещ едновременно с шест бази данни и се опитва да направя демонстрация, е приблизително толкова, колкото хардуерът ми ще улесни. Нека сега се върна в Oracle и ако забележите, всички тези неща са еднакви. Ако искам да измервам ефективността си в DB2, това е същият избор, който бих имал и в Oracle. Сега под завивките правим много различни неща, така че не е нужно да знаете какво се случва, но ние ви даваме последователен интерфейс, за да можете да бъдете експерт с множество платформи за бази данни. А това ще включва работа с индекси, темата на тази дискусия.
Нека дойда тук и нека първо да започна като разгледам някои таблици и имам база данни за филми, която има само няколко таблици. И ако погледна определена таблица, като таблицата с клиентите, когато я донеса тук, мога да видя дизайна на таблицата си, ето моите колони в таблицата ми и ето информация за всяка колона. Имам свойства за таблицата, но имайте предвид, че тук имам раздел за индекси и виждам, че тук са индексите на таблицата. Забележете, че един от тези индекси е моят ПК индекс, моят основен ключ. Тези други изглеждат просто индекси за подобряване на достъпа до заявки, може би ние питаме по име или фамилия или гледаме телефони и пощенски кодове. И ако избера конкретен индекс, като този пощенски код тук, и щраквам двукратно върху него, сега виждам, че, ей, това е уникален индекс и ето някои от другите видове, растерни, не-уникални, уникален, независимо дали е сортиран или не, дали тази регистрация или не, независимо дали е обратен ред или не, независимо дали е база от функции. О, ето една забавна, която не покрих. Всъщност можете да имате невидими индекси. И бихте казали: „Е, защо по дяволите бих искал да направя невидим индекс?“ Е, ще ви дам добър пример. Вие сте във вашата производствена система и имате проблем с производителността и не сте сигурни, че създаването на индекса ще отстрани проблема, така че не искате да създавате индекса и да забавяте производството, но по някакъв начин или другото, което искате да бъдете в състояние да го тествате. Можете да създадете индекса в производството като невидим, което означава, че не много приложения код, обаждайки се на оптимизатора, ще използва този индекс. Той е създаден, валиден е, но няма да бъде използван. След това можете да вземете запитване, за което смятате, че този индекс ще ви помогне, или поредица от запитвания, и можете да вмъкнете намек и да кажете: „Ей, оптимизатор, там има невидим индекс, който искам да използвате и оставете знам дали съм направил нещата по-добри. ”И сега съм тествал нещо в производството, но не съм нарушил приложенията в производството, които течеха. Това е използването за невидим индекс. Звучи тъпо, когато за пръв път чуете за него, но има полза.
Можем също така на индекси да определим дали те са успоредни, както и колко екземпляри са паралелни в. Сега, в некластерирана или не-реална среда на клъстер на приложения, така че без паралел, паралел би означавал колко подпроцеси може да се появи моята заявка, за да се опита и работните процеси, за да се опита и да се разбере по-бързо или по-бързо, И паралелни случаи биха били, ако съм в истински клъстер на приложения, да речем, че имам десет възли, на колко от възлите ми е разрешено да разделя работата по цялата? Може би това е четири от десетте и на всеки от тях по четири подпроцеса. Това е пример. И тогава имаме компресия на ключове. Можете ли да компресирате индекси? Да или не. И тогава, разбира се, имате своите параметри за съхранение, които можете да посочите в индексите. Сега не ги покрих, защото те наистина са повече параметър за съхранение, отколкото проблем с индекс. И накрая, имаме дали да правим или не тези дялове или не. Нека го пусна тук за секунда. Ще отида на друга схема. Това е звездна схема и например тази таблица за периоди е таблица с измерения. Ако някога сте правили дизайн на звездна схема, обикновено имате измерение за времето и така в тази база данни и тази звезда схема, периодът е времево измерение. Сега знам, че ще изглежда смешно, ще кажете: „Боже, погледни всички тези колони - човекът чувал ли е за нормализиране?“ Е, когато сте в хранилище с данни или дизайн на звездна схема, вие обикновено имате не - имате таблици, които типичният човек би погледнал и казал: „Боже, те не са много добре проектирани.“ Но това е начинът, по който го правите в среда за съхранение на данни.
Сега, гледайте какво ще се случи, защото, добре, има всички тези колони, вижте това, имам индекс за всяка една колона. Сега в OLTP среда, която би била не-не. Това би забавило всичките ми операции. В среда за съхранение на данни бих ги пуснал по време на циклите си на пакетно зареждане. Заредете без режийни или индекси и аз бих пресъздал индексите. И ако аз разделих таблицата си, тогава вместо да се налага да изпускам индекса за всяка кофа в таблицата, бих могъл просто да пусна индекса върху кофата или кофите, в които щеше да влизат данни по време на този цикъл на партиден товар. И след това пресъздайте само индексната част за тези кофи. И така, че го прави много управляем. И ако погледна - така ето една колона, наречена „Ваканционно знаме“ и всъщност това е „да“ или „не“. Забележете, че това е растров индекс и за повечето от вас ще кажете: „Е, това има смисъл.“ Да или не, Y или N, има само две стойности, които имат смисъл. И тъй като, когато четете документацията за растерни индекси, те винаги ви казват да изберете нещо с ниска кардиналност.
Сега нека да вляза в една от моите таблици с факти, така че тук имаме моите заповеди. И това са моите поръчки на ден. И сега ще видите, че отново имам доста колони и отново ще имам повече от няколко индекса. И точно тук имаме нещо, наречено универсален ценови код. Това беше за магазин на дребно, така че знаете онези малки баркодове, когато купувате нещо в магазина, това е универсалният ценови код. Сега има милиони универсални ценови кодове. Сега, за тази конкретна компания, която продаваше неща, те вероятно имаха 1, 7 до 2 милиона универсални ценови кодове, така че ще очаквате, че това няма да бъде растрови индекс, тъй като 1, 7 милиона различни стойности звучат като висока кардиналност. Но в действителност в среда за съхранение на данни искате това да е растерна карта. Сега, нека да ви обясня защо. Е, може да има 1, 7 милиона различни стойности за този универсален ценови код, броят на редовете в тази таблица за поръчки е в стотиците милиони до милиарди редове. Индексът ми е с ниска кардиналност в сравнение с размера или кардиналността на таблицата. Това го прави ниска кардиналност. Това прави полезния индекс на растерната карта, въпреки че е противоположен на 1.7 милиона различни стойности, които бихте избрали тук. Сега, ако знаех, че искам да използвам индекс на присъединяване към растерна карта, в момента продуктът не поддържа това, получавам това добавено за следващото издание, но това би било друга алтернатива тук. И в звездна схема, не забравяйте, че индексът на растерната карта ще бъде в таблицата с факти и че един индекс в B-дървото ще посочва реда в таблицата с факти и след това към всеки ред, който е очевиден в таблицата с измерения за този факт, И така, вие имате друга опция там. И така, да видим, сега искам да изляза от таблиците и просто искам бързо да ви покажа, че имам същата информация, под индекси, и ще направя същото основно нещо.
Причината да изкажа това е, че може да забележите, хей, тук няма първични ключове. Първичните ключове се правят с ограничение на ключовете, така че те всъщност са обхванати от определенията на ограниченията. Това биха били индекси, които не са част от ограничението. Сега може да кажете: „Е, изчакайте малко, което може да изглежда като чужд ключ, а чуждият ключ е ограничение“, но чуждите ключове и повечето бази данни не създават автоматично индекс на колоната с чужд ключ, въпреки че е препоръчително и ето - отново имам едни и същи решения. И ако искам да се променя само за да съм компресиран, мога да направя това.
Сега компресията работи само върху индекс на B-tree. Това, което позволява е, когато погледнете различните възли в B-дървото, то позволява компресия на някои от стойностите. Това наистина не е компресия като компресия на таблица, а компресия на това, което се съхранява в B-дървото в не-листните възли. Това не спестява тон пространство, но може да доведе до промяна. И с това забелязах, че се приближавам доста време, така че това, което искам да правя е, искам да се върна назад и да спра да споделя. И ние имаме нашия продукт там за четиринадесетдневно изпитание в idera.com. Това е доста добър продукт, особено ако работите с множество платформи за бази данни. Ако работите с две или три различни бази данни, този инструмент ще направи живота ви много по-лесен. Имаме инструменти, които да ви помогнат при проектирането и избора на индекс, имаме инструмент, наречен DB Optimizer. Днес просто не успях да покрия това, това би било твърде много. И ако искате да се свържете с мен, има моят имейл адрес, е, или можете да ме хванете на моя личен имейл, и аз имам блогове, имам уебсайт и блогове и профил в LinkedIn там. Така че не се колебайте да се свържете с мен за каквото и да е, дори и да не е свързано с продукти, ако просто искате да говорите бази данни, аз съм маниер в сърцето си и обичам да се занимавам с technobabble.
Ерик Кавана: Добре, добре, Дез, Робин, сигурен съм, че всеки има поне няколко въпроса, остават ни няколко минути тук. Дез, какво мислиш?
Дез Бланчфийлд: Имам един страхотен въпрос, който трябва да ви задам, той седеше отзад на ума ми. Кой е най-лудият сценарий, който сте виждали? Прочетох вашия блог, следя ви отблизо, вие - вероятно сте един от малкото хора, които живеем в почти всяка вероятност, и мисля, че д-р Робин Блур е вторият, който срещнах в живота ми. Но, знаете, вероятно сте виждали всеки луд сценарий, кои са някои от най-лудите сценарии, които сте виждали, че сте попаднали и като хора, които просто не могат да се справят, сте успели да ходите и да изпълнявате трикове на джедаите с целия си DBArtisan?
Берт Скалцо: Веднъж имахме клиент, който в дизайна на своята база данни е мислил много по начина, по който биха помислили в дизайна на файлови оформления. И така, когато нормализирате база данни, първото нещо, което се опитвате да направите, е да се отървете на повтарящи се групи. Е, те имаха колона и я направиха дълга, или BLOB или CLOB, и в нея биха сложили стойност, номер едно, точка и запетая, стойност номер две, точка и запетая, число на запетая, и те биха имали хиляди стойности там, но те трябваше да търсят в тази колона и те са: „Защо това нещо работи толкова бавно?“ И аз съм като: „Е, не можеш да създадеш индекс за това, което си направил, просто е не им е позволено. ”Така всъщност им показахме, използвайки плановете, че това, което трябва да направят, е да нормализират тази таблица. Не защото нормализирането е някакво академично упражнение, което прави нещата по-добри, а защото искат заявка в това поле, което означава, че искат да могат да го индексират, а вие не можете да го индексирате на повтаряща се група или поне не лесно, И така това е може би най-лошото нещо, което съм виждал.
Дез Бланчфийлд: Да, интересно е колко често се сблъсквате, мисля, че предизвикателството с базите данни, хората забравят, че е наука. И има хора, които правят степени и доктори в цялото това пространство, пишат документи върху него и вие сте написали цял замах, включително вашите ръководства за TOAD и други неща от паметта. Тенденцията към сортиране на "големи данни" сега - виждам много хора да забравят основите на архитектурата на базата данни и технологията на базата данни, науката за базата данни, ако желаете. Какво виждате на полето, що се отнася до отдалечаването от традиционните платформи за бази данни и традиционното мислене на бази данни, което ние ефективно приковаваме към земята, а това беше просто случай на настройка и мащабиране на производителността. Виждате ли много хора да се учат и да имат опит, където те просто седят там и имат "а-ха" момент, като момент от еврика, където осъзнават, че тези големи данни са всъщност просто нещо като наистина големи бази данни? Това нещо ли е там и хората ви отговарят отзад и вид: „Забравихме, какво знаехме и можете ли да ни върнете от тъмната страна?“
Bert Scalzo: Е, не, и това е ужасно да се наложи да призная, но продавачите на релационни бази данни са пили и този Kool-Aid. Ако си спомняте, не знам, преди около десетилетие започнахме да поставяме неструктурирани данни в релационни бази данни, което беше нещо странно, а след това към данните, релационните бази данни, сега се добавя NoSQL тип неща. Всъщност, в Oracle 12, CR2 - знам, че все още не е излязъл - но ако погледнете бета, ако сте в бета програмата, той поддържа засилване. И така, сега имате релационна база данни, към която не е добавена концепцията от NoSQL заточване. И така, моментът „а-ха“ изглежда е повече за хората от релационната страна, които отиват „а-ха“. Никой никога няма да го направи отново, дори и мениджърите на базата данни, така че имаме трябва да премине и да се присъедини към тъмната страна.
Дез Бланчфийлд: Точно така, вие казвате да преминете към голяма част от разхвърляните данни, ако разбирам правилно, да бъдат пуснати в това, което ние наричаме големи платформи за данни, което е нещо смешно, защото те са не е толкова стара, но не означава ли това, че преосмислят това, което правят със своята релационна база данни, за да получат повече удар за долара си?
Bert Scalzo: Не, обикновено, ако имат нужда от - това би било цитиране на „голяма нужда от тип данни“, те откриват, че вместо да се налага да отиват на другата платформа на базата данни и да правят нещо в не -релационален начин, доставчиците на база данни сега им дават същите нерелационни техники в тяхната релационна база данни, за да правят тези неща. Искам да кажа, че добър пример би бил, ако имате неструктурирани данни, например тип данни JSON или някакъв друг сложен тип данни, който има смисъл вграден в самите данни, доставчиците на база данни не само поддържат това, но ще ви дадат ACID спазване на неструктурирани данни. Релационните бази данни са обхванали по-новите техники и технологии и така, отново „а-ха“ изглежда е не повече от това: „Ей ние, разработчиците на приложения, сме научили нещо и трябва да го научим отново“, това е „Ей, ние го правим по този начин сега, как мога да го направя по този начин във вашата традиционно релационна база данни и да го направя, както правя в тази база данни тук? “и това става все по-разпространено и, както казах, самите доставчици на база данни дават възможност че.
Дез Бланчфийлд: Да, кои са традиционните заподозрени в това пространство за инструмента DBArtisan и това? Направих някои домашни задачи по това, което написахте наскоро, и от паметта сте написали нещо, мисля, че това е един от вашите блогове, за екстремното представяне на база данни в света на Oracle. Не мога да си спомня кога беше, мисля, че някога тази година от паметта или от края на миналата година сте написали това нещо. И ми се стори, че това е традиционният, обикновен заподозрян за типа тема, за който говорим днес, където хората ще отидат в много мащабна среда на база данни и ще търсят това, което наричате екстремни печалби в нея. Кои са обичайните заподозрени, които виждате там, които приемат DBArtisan и го използват добре?
Bert Scalzo: Е, ние имаме много клиенти, всъщност днес бях на работа с много голяма правителствена агенция, която - и те буквално вероятно са близо 1000 копия на нашия софтуер, защото това позволява на хората да се съсредоточат върху това, което те правите, а не как да го направите. И това е добре, искам да кажа, всеки трябва да знае как да направи нещо, но производителността върши „това“. Ако бизнесът ме помоли да направя задача, това е всичко, което ги интересува. Кога получих отметка, за да кажа кога е изпълнена задачата? Не каква техника или каква технология използвах, за да стигна до там. И така, нашият инструмент им позволява да се съсредоточат върху какво и им позволява да бъдат далеч по-продуктивни и това е наистина огромното предимство и както казах, някои бази данни предлагат инструмент само за тяхната база данни. Ние го предлагаме за дванадесет платформи за бази данни. Имам един и същ работен процес, същия графичен потребителски интерфейс, същите навигации. Ако знаете как да предоставите привилегия на потребител или как да създадете таблица или да създадете индекс в база данни, можете да го направите във всички дванадесет, защото това е един и същ вид и усещане и същия работен процес. Това има огромна стойност за нашите клиенти.
Дез Бланчфийлд: Да, предполагам, хората искат да получат много по-голям удар за долара от човешките си ресурси. И дните на наличието на индивидуален специалист по Oracle, Ingres и DB2 отминаха. Очаква се хората да са Джакът на всички сделки, така че мисля, че това нещо им е спасило абсолютно живота.
Само едно последно бързо нещо, преди да го предам на доктор Робин Блур. Споменахте, че има безплатно изтегляне за четиринадесет дни, какво прави - ако ще продължа напред и ще направя това, между другото, ще го сложа в лабораторията на Bloor и ще въртя това нещо изправете се и се справете сами - не бях имал възможност да го направя преди днес. Споменахте четиринадесетдневно изпитание, казахте, че го управлявате на VM на компютъра си, предполагам, че е лаптоп. Какви са, каква е настройката на входното ниво, за да може някой да се заеме и да използва изпитанието за четиринадесет дни, точно преди да се върна на Робин на въпросите му?
Bert Scalzo: Всяка Windows среда, така че Windows 7, виртуална машина с един процесор и четири гига памет. Ние не сме наистина дебел или скъп инструмент. Сега, ако искате да стартирате сървъра на базата данни на същия този виртуален компютър под същия Windows, да, ще трябва да добавите още, но ако използвате вашата база данни на сървър на база данни или на отделен VM, VM ще се зареди и Изпълнете нашия продукт е много лек: един процесор, четири гига памет, почти всяка версия на Windows - и поддържаме тридесет и две и шестдесет и четири бита инсталации. Но трябва да инсталирате клиента на вашия доставчик на база данни. Така че, ако искате да се свържете с Oracle, трябва да инсталирате SQL нетния клиент, защото това изисква Oracle, за да разговаряте с база данни.
Дез Бланчфийлд: Звучи доста пряко. Мисля, че едно от това нещо повече от всичко, което се надявам, че хората ще отнемат, различно от осъзнаването, че този инструмент ще спаси живота им, е, че трябва да отидат и да го изтеглят и да си играят с него, като се има предвид, че предлагате четиринадесетдневна безплатна пробна версия. И може да работи на техния текущ лаптоп, без да инсталирате нищо допълнително, защото ако вече правят администриране на база данни, те вече работят с бази данни, те имат всички тези инструменти на мястото си и дали той работи на локален VM или на тяхната локален десктоп, звучи като безболезнено да инсталирате и да играете. Затова горещо препоръчвам на хората да го правят.
Робин, сигурен съм, че имаш въпроси и Ерик, вероятно имаш някои от публиката, така че Робин, какво ще кажеш да премина към теб и след това обратно към Ерик?
Робин Блур: Да, добре, добре, имам какво да кажа, искам да кажа, винаги съм намирал тази област за очарователна, защото беше - режа зъби по нея. Но истината е, че вероятно от около 1998, 1999 г. аз съм се интересувал от това, на което всъщност е способен Oracle. И, знаех Sybase и Microsoft SQL Server, и двете са сравнително прости в сравнение с това, което Oracle може да направи. Накара ме да се засмея, когато ти - искам да кажа, аз покрих устата си, когато започна да говориш за заточване. Oracle правеше това преди. Oracle, въведени в даден момент, те се изнервиха от идеята за връзката на обекта, така че те въведоха способността да създават един вид нотация на обекти и съхранение на обекти в Oracle, и аз говорих с един от техните инженери, нещо като няколко години след като го представиха и попитах колко хора го използват, а той каза, че мисля, че двама клиенти са го опитали и това беше. И мисля, че същото ще се случи, ако започнат да се опитват и да правят тенденциозни неща в NoSQL. Знаеш ли, мисля, че е грешка, искам да кажа, че някак ме интересува какви са твоите мисли. Със сигурност - те пият Kool-Aid. Те се чувстват сякаш трябва да могат да отправят претенции, подобни на големите бази данни NoSQL като Cassandra, но знаете ли, има ли смисъл за вас?
Берт Скалцо: Не, ударил си нокът точно по главата. За мен бих, ако ще направя релационни, ще избера продавач на релации като Oracle или SQL Server или DB2 или Postgres, но ако ще направя нещо, което не е релационно, в пространството с големи данни или в пространството NoSQL, ще избера правилния инструмент за правилната работа. И не мисля, че това естествено би било първо да отидете при моя доставчик на релационни бази данни. И след това добавяте другата бръчка към нея, която е, какво се предлага в облака? Толкова много хора искат да извадят базите си от помещения. След това трябва да погледнете вашия доставчик на облаци и да кажете: „Добре, какво предлагате, какви бази данни имате за мен, които отговарят на моите нужди и колко са продаваеми, и честно казано каква е тарифата или таксата за използване на тази база данни в облака на час или на ден. И на гигабайт или терабайт? ”И това, което ще намерите, е може би някои от сравнително по-новите бази данни като Монго или Касандра, може би тарифите им са по-евтини, така че ако ще правите големи петабайтови големи данни, може би трябва да - точно от гледна точка на разходите - трябва да обмислят базите данни от NoSQL в облака, защото те може да са най-рентабилният начин за това.
Робин Блур: Да, така е. Искам да кажа, моят вид - нещото за релационните бази данни от моя опит - което е достатъчно дълго, за да има белези, това е сигурно - има много здрав разум, че ако започнете да го прилагате и - разбирате какво релационно е всъщност, това, Искам да кажа, че си спомням, че веднъж веднъж направих консултации с един клиент, и те ме закараха в стая и бяха направили някаква схема на образувания и създадоха трета нормална форма, модел на това каква е основната система на компанията. Имаше около двеста и четиридесет маси и те казаха: „Е, какво мислиш за това? Ние ще изградим база данни за това "и казахте" Какво мислите за това? "Аз казах:" Не мисля, че ще работи. "И е точно така, знаете, защото те свършваха нагоре, за да се създаде определена структура в рамките на единадесет посоки. И това е нещото, което трябва да се разбере при взаимоотношенията. Така че ми е интересно по отношение на това колко лош дизайн срещате. Искам да кажа, че нямам проблем с DBArtisan - той прави много разумни неща и фактът, че всъщност можете да се показвате на множество платформи, мисля, е прекрасен - но колко срещате там, където е издаден дизайнът къде хората биха могли да си решат всякакъв вид сърдечна болка, ако стигнат до звездна схема, а не да получават снежинка-y за това, знаете ли?
Берт Скалцо: Е, не искам да звуча като самонадеян или арогантен, но бих казал по-често, отколкото не. Ясно е, че по-голямата част от базите данни, с които се занимавам там, имат проблеми или проблеми. Което е добре, защото нашите инструменти, като нашия инструмент за оптимизиране на бази данни, могат да им помогнат да разрешат тези проблеми и, но това, което наистина ми е смешно, е, че много от проблемите са едни и същи прости проблеми отново и отново. Аз просто работех с клиент онзи ден, който имаше единадесет посока за присъединяване, и аз съм като: „Добре, защо не сте използвали клауза?“ И те са като: „Е, не съм "Не знам какво е това." И тогава аз казах: "И погледнете под-избраните от вас тук на вашето корелирано и на вашето не-корелирано", казах: "В някои случаи имате клаузата си където на най-дълбоко ниво, справка на таблицата от външната. "Аз казах:" Това е, преместете го на правилното ниво, не го вграждайте по-дълбоко, отколкото трябва да бъдете, объркайте оптимизатора. "И с няколко няколко ощипвания ние взе нещо, което работи около два часа, и го намали до десет минути и беше просто - в този случай ние не направихме нищо друго, освен да подобрим SQL, който бяха написали. Мисля, че проблемът е, че много университети и много хора, които учат програмиране в неакадемична среда, те го учат като процеси в записано време или процес, ориентиран към редове, и релационният е набор, ориентиран от природата, и така вие трябва да мислят в комплекти, за да напишат добър SQL.
Робин Блур: Да, мисля, че е точно така. И трябва да разберете, такива неща са, хората трябва да знаят ABC-тата на такива неща. Няма значение. Няма да можете да правите рационални неща, ако не осъзнаете, че дори добре проектираната, добре моделирана база данни, присъединяването ще отнеме време, сортовете ще отнемат време. Това е така, защото светът никога не е намерил начин да ги накара да вървят бързо. Те са намерили начини да организират данните, така че те да отидат по-бързо от другото и много ентусиазъм, който трябва да кажа за базите данни NoSQL, е просто, че избягват да се присъединяват. Те просто започват да изграждат базите данни със същото разпространение на данни в тях, защото ако се присъедините към някоя от базите данни NoSQL, те смучат силно. Не мислите ли?
Берт Скалцо: О, абсолютно. И трябва да се смея, защото започнах обратно преди релационните бази данни и обратно, когато Ингрес беше РТИ, Институтът за релационни технологии и нямахме SQL, имахме релационни езици преди SQL. Мисля, че в Ингрес тогава се казваше Квел. Така че получихте от тези стари парадигми на базата данни като мрежа и по-висока графична, или йерархична, и преминавате през релационните парадигми след няколко десетилетия и сега за мен има чувството, че отново се връщаме към почти йерархична. Почти все едно сме се обърнали.
Робин Блур: Да, така е. По-добре предайте на Ерик, аз прекарвам твърде много време, но имаме ли въпроси от публиката, Ерик?
Ерик Кавана: Имаме, имаме няколко. Ще продължим малко тук, но ще ви хвърля няколко. Имахме няколко въпроса около невидимите индекси. Един въпрос беше: „Трябва ли някой да използва инструмента ви, за да ги види?“ Друг въпрос беше: „Е, какво ще стане, ако си сляп?“
Берт Скалцо: Това е добро.
Ерик Кавана: Любопитен въпрос също, така че просто FYI.
Берт Скалцо: Не, не е нужно да разполагате с нашите инструменти. Това е функция на Oracle, индексът на невидимите. Основно в речника на данни Oracle просто запазва част от метаданните, която казва: „Оптимизатор, игнорирайте този индекс. Тук е, но освен ако не бъдете инструктирани физически чрез намек в, намекът за оптимизатор в командата SQL, не използвайте това. "И така, не, не е нужно да разполагате с нашите инструменти и във всяко отношение е обикновен стар индекс, можете да го видите във всеки инструмент, просто оптимизаторът ще каже: „Ще го игнорираме при нормална обработка на заявки.“ Трябва да го насочите, ако искате да свикнете. Наистина е полезно за описания от мен сценарий, който е, ако искате да създадете индекс в производството, но не рискувате да счупите отчетите или нещата, които вече се изпълняват, но искате да ги тествате, бихте могли да го направите. За това е най-полезно.
Ерик Кавана: Това са добри неща и тогава се появи още един добър въпрос. „Какво ще кажете за някои от тези нови бази данни в паметта? Как технологията на базата данни в паметта променя играта по отношение на индексирането? “
Берт Скалцо: Момче, ами ние - сега това е добре, радвам се, че някой е задал този въпрос, ще трябва да продължим още половин час. Не, в паметта, това зависи от доставчика на база данни. Обикновено, аз съм, аз не говоря нищо, освен да похваля нещо, което Oracle прави, защото това е невероятна технология, която са изградили, но когато се откъснете под капаците и погледнете какво е памет в Oracle, в Oracle база данни, това, което е в действителност е, че все още се съхранява ред за съхранение на диска и ще се зареди в паметта на колоните в паметта и ако няма достатъчно памет, за да побере цялата таблица, тя ще се върне обратно към частите; тя няма да се впише в паметта, за да го направите съхранение на редове и така всъщност можете да направите селекция срещу таблицата и за половината от таблицата, използвате индексиране, удряйки традиционните редове в таблицата, и за другата половина на селектирането всъщност излиза и просто хваща всичко от търсене в паметта и така, различно е по начина, по който SQL Server например го внедри с тяхната технология Hekaton, знаете ли, и SQL 2014 и беше подобрен в SQL 2016, но в някои отношения тяхната е по-вярна версия на паметта и, но всяка реализация има плюсове и минуси, но трябва да погледнете под кориците и да осъзнаете. Защото имах клиент, който каза: „О, тази памет е в паметта - просто ще изготвя всички индекси“ и съм като: „Таблицата е по-голяма от паметта, която имате на сървъра, така че в един момент някои от запитването трябва да ударят диска. "
Ерик Кавана: Това е добро описание; това са добри неща. Е, хора, ще имаме още няколко уеб предавания с тези момчета през останалата част от тази година, върнете се винаги, когато чуете, че Берт е на презентация, защото знаем, че той знае нещата си. Винаги е забавно да се говори с експертите. Ние архивираме всички тези уеб предавания за по-късен преглед. Ето отново информацията за контакт на Берт и ние ще се опитаме да изкопаем тази връзка за изтеглянето и да я изпратим също по имейл, но винаги можете да изпратите имейла си наистина: ние имаме още много уеб предавания за това година и ние правим редакцията в момента, така че, хора, ако има теми, които наистина искате да чуете за следващата година, не се срамувайте: Внимавайте, хора, ще поговорим с вас следващия път. Чао чао.
Партньор за съдържание на Techopedia
Персоналът на Techopedia е свързан с Bloor Group и може да се свърже с тях, като използвате опциите вдясно. За информация как работим с партньорите в бранша, кликнете тук.- Профил
- уебсайт
