От персонала на Техопедия, 24 август 2016 г.
Вземане: Домакинът Ерик Кавана обсъжда тенденциите в базата данни с д-р Робин Блур, Дез Бланчфийлд и Скот Уолз в този епизод на Hot Technologies.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Дами и господа, привет и добре дошли в най-горещото шоу в света на предприемаческите ИТ, Hot Technologies от 2016 г. Да, наистина! Казвам се Ерик Кавана, днес ще бъда ваш домакин на шоу, озаглавено „Изкуството на видимостта: Разрешаване на управление на много платформи“, да. Няколко бързи бележки, има слайд за вашето наистина, общо взето, от преди пет години и достатъчно за мен, ме удари в Twitter @Eric_Kavanagh. Годината е гореща, това е нашият стандартен слайд за горещи технологии. Това, което направихме с това шоу е, че искахме програма, която да ни помогне да дефинираме конкретен вид технология, така че цялата идея е, че получаваме двама анализатори, които влизат и дават своето участие в определено пространство или определен тип функция от което се нуждае предприятието и тогава продавачът влиза и демонстрира какво са изградили и обяснява как се привежда в съответствие с това, което чувате от анализаторите.
И причината за това, както може би си представяте, е, че в света на маркетинга на корпоративния софтуер има термини, които се обвързват и това, което се случва неизменно, е, че продавачите се хващат за най-новия горещ термин, неща като големи данни или анализи за например или дори SOA или различни термини като платформа, а понякога тези думи са много точни за определена технология, а понякога не са. Това шоу беше създадено, за да ни помогне да изясним за вас, публиката, какви конкретни видове технологии правят, как работят и кога трябва да ги прилагате.
С това ще представя нашите оратори. Имаме наш собствен д-р Робин Блур, който се обажда от неговото местоположение в Остин, Тексас, Дез Бланчфийлд, обаждащ се от другата страна на планетата, и нашият гост Скот Уолз, който се обажда от Кентъки. И наистина ваше, аз всъщност съм извън Питсбърг, така че днес имаме напълно гео-локализирана организация от множество различни места. С това ще прокарам първия слайд на Робин, не се колебайте да задавате въпроси между другото, хора, не се срамувайте. Можете да го направите като използвате Q&A компонента на вашата конзола за уеб предаване. И с това ще го предам на д-р Блур. Подът е ваш.
Робин Блур: Добре, благодаря ти за това въведение, Ерик. Нека да стигна до първия слайд. Това е колекция от meerkats, които мислят за база данни. Цялата презентация, която наистина правя тук, е просто общ набор от мисли за базата данни, които имах наскоро, като въпросът беше, че наистина около 2000 г., изглежда, че играта с база данни е приключила в смисъл че по-голямата част от реализациите на базата данни се случват на релационна база данни. И тогава току-що се промени, знаете ли, изведнъж се появиха всички тези неща, за които мизерците мислят, магазини с колони, магазини с ключови стойности, бази данни с документи, база данни в паметта, база данни с графики и още много други неща. И почти като нов вид геологическа ера, в който изведнъж се появиха фосили от различни видове животни.
Новините от езерото Wobegon, наистина приключи за базата данни за един модел. Няма съмнение, че RDBMS все още доминират, но сега са създадени други видове бази данни. Наистина, това е почти прегледът на това, което ще кажа тук.
Размерите на базата данни, някои от тях всъщност станаха по-важни напоследък, но тези, за които бих могъл да се сетя, когато направих този слайд, така или иначе, дали той е мащабиран по отношение на ефективно използване на ресурсите на всеки сървър? Разширява ли се, за да може да преминава през големи клъстери? Използва ли наличния хардуер, че вид бази данни в паметта вървят в тази посока? Разпространява ли се? Съществуват редица бази данни, които са важни за променливостта за разпространение. Какви характеристики има? Основната характеристика на ACID на базата данни. Но сега, вместо да имат реална съгласуваност, редица бази данни имат евентуална съгласуваност, хората ги използват и нямат проблем с тях, така че са доказали, че ACID не е абсолютно необходима, а просто е добре да има в много ситуации.
По отношение на организацията на метаданните, цялата игра се промени. Имаме различни организации за метаданни, а не типична схема за RDBMS. По отношение на оптимизатора, има много много активност на оптимизатора в зависимост от структурите на данните, които се опитвате да оптимизирате. По отношение на управляемостта има много различия в това, за което ще разгледам по-късно, но по принцип цялата точка на СУБД е управляема и отново степента на нейната управляемост до известна степен определя степента на нейната полезност.
По отношение на хардуерните фактори, това наистина се казва - искам да кажа, че тук се прави само една точка - въпросът, който се прави тук, е, че това, което разглеждаме днес по отношение на архитектурата на бази данни, ще се промени. Може да са същите бази данни, но те ще трябва по един или друг начин да вземат предвид какво всъщност се случва на хардуерно ниво. В продължение на много, много години имахме тази сравнително проста ситуация на процесора, паметта и въртящия се диск - добре, че наистина го няма.
Въпросът е тук, на първо място имаме процесори, но те са много по-паралелни възможности, отколкото преди, с много, много различни ядра за обработка. Имаме и графични процесори, имаме и FPGA, различни видове силиций, но Intel се ожени за една FPGA с процесор в следващата си версия и - И - се ожени за GPU и процесори заедно на един и същ чип. Имате чипове с различни характеристики. Предимството на графичния процесор е, че той наистина е чудесен за тежък паралелизъм и особено за числено изчисление. FPGA можете по един или друг начин да поставите кода на чипа и той функционира далеч по-бързо, отколкото ако просто го подавате към чипа.
Има кръстосване на тези неща, което се случва. Имаме 3D XPoint от Intel и PCM от IBM, които са нови видове памет, които са по-бавни от RAM, по-евтини от RAM, но нестабилни. И това създава малко вълнение сред редица доставчици на софтуер, с които съм говорил. Имаме SSD дискове, но сега те стават много, много големи и осигуряват паралелен достъп. С паралелен достъп до много голям SSD можете да достигнете скорости на четене, подобни на скоростите на четене на RAM. Имаме тази възможност за три вида RAM за съхранение, 3D XPoint неща и SSD дискове, всички от които ще вървят изключително бързо. И тъй като скоростта е същността на базата данни, цялата технология на базата данни ще се опита и да ги използва възможно най-бързо. И това ще включва и е участвала паралелна архитектура, но мащабна паралелна архитектура. Производителността на ниво хардуер се ускорява непрекъснато, прави се в продължение на много години, продължава да го прави и общите разходи намаляват.
Следа от сълзи. Това са просто различни опити за бази данни, първите бази данни преди релационните обикновено се наричаха мрежови бази данни, след това дойдоха релационни бази данни, след това дойдоха бази данни на обект, те не получиха голяма степен на сцепление, след това дойдоха базите данни на колоните за съхранение, които бяха ли релационни бази данни, направени много различно. И тогава имахме базите данни на документи и SQL базите данни, които бяха обектни бази данни, направени по различен начин, или ако желаете, същата колона от обектни бази данни и те се хванаха. И наскоро имахме графични бази данни, набиращи сцепление и RDF бази данни. И това, което гледате, има поне три различни набора от структури от данни, които се приспособяват. Релационната база данни прави таблици и редове много добре. Базата данни с документи и базите данни на обекти - те правят много неудобна структура на данни, особено йерархични структури от данни. А графичните бази данни и RDF базите данни правят много добре мрежовите структури на данни. И тези различни, мисля за тях като три линии, тези редове ще продължат за неопределено време. Това няма да спре, защото двигателите, които вършат добре тези неща, не работят особено добре с другата структура на данни.
И тогава имаме развалящия фактор на Hadoop. Hadoop не е база данни, но има бази данни, които използват HDFS за своята структура за съхранение. И много неща, които прави Hadoop, са вида на нещата за управление, които трябва да се направят за база данни. Също така си струва да споменем, че Spark също не е база данни, но го има и е незрял, но има SQL оптимизатор и следователно е като ядрото на база данни, без непременно да знае къде ще съхранявате данните, но ако го залепите на HDFS, голяма част от изискването за база данни е изпълнено, просто от възможностите на базисната файлова система. По-конкретно, Spark стана част от екосистемата на базата данни и често е федерализирана с по-мощни бази данни, а причината за това наистина е анализа. Анализ - Spark е, добре, че върви много, много бързо в аналитиката. Анализ е основното приложение, в което повечето хора инвестират в момента, така че двамата вървят ръка за ръка. Федерация на данни, а не правила за концентрация, това би трябвало да е очевидно от факта, че имате поне три различни нужди, структурирани видове бази данни, и следователно, федерация на данни, ако искате да споделите данните между тях. Често е необходимо, но вие също имате бази данни, които мащабират и бази данни, които не го правят, наистина мощни двигатели като Teradata или Vertica имат много специално място, но по-малко двигатели, които могат да свършат страшно много работа, така че, федерация вероятно е там дълго и дълго време, дори между релационни бази данни.
Последното нещо, което трябва да кажа, IoT, не свърши, докато дебелата дама започне да обезобразява данните. IoT може да създаде по един или друг начин различна динамика в света на базата данни и това ще усложни нещата още повече. Да се надяваме, че по един или друг начин ще има някакво сближаване, но не виждам всичко да се събира, както стана с релационните бази данни. И така или иначе скоро.
И мисля, че това е всичко, което имам да кажа, затова ще го предам на Австралия.
Дез Бланчфийлд: Благодаря ти, Робин. Благодаря на всички, че се присъединихте към нас, благодаря, че ме приехте тази сутрин, или днес следобед, че прекарате времето си. Това е наистина гореща тема, защото преживяхме доста експлозия през последното десетилетие и малко, в количеството данни, с които трябва да се справим, и неизменно, че данните се намират в някаква форма на система, която за повечето случаи е база данни с някаква форма. Мислех, че бързо ще ни пренеса през много високо ниво на разходка как стигнахме до тук и проблема, който се създава, и типовете неща, които трябва да се справим сега, и тогава ще говорим за типовете решение, което може да се приложи за това. Нека просто се хвана за първия си слайд тук. Аз съм на мнение, че сега сме в момента, в който DB администратор 2.0 или администратор на база данни 2.0 е вид, в който сме в момента, веднъж администратор на база данни беше доста пряма роля и предизвикателство и бихте могли да тренирате някой доста бързо. В днешния свят това вече не е така и аз ще ви покажа защо това е така.
Веднъж администраторът на база данни би могъл да се свърже към задния край на БД и да направи бързо показване на бази данни и в системата ще има списък с бази данни, с които трябва да бъдат запознати и те могат много бързо да преминат тези бази данни и ги изберете и има малко пъп и сонда наоколо и използвайте превод, опишете таблицата, за да разберете какво има в таблица и всяка от колоните и редовете, и това беше сравнително лесно предизвикателство и ако прочетете средното две-триста страници книга за администриране на база данни за всяка платформа, вие бяхте в състояние почти да се обучите, без да се налага да правите ракетна научна степен.
Но това вече не е така и причината за това, според мен, е, че в света на базата данни има твърде много възможности за всеки човек да бъде експерт на специалист и да може ръчно да управлява и администрира, И причината за това е, че през последните четири до пет десетилетия, когато става дума за света на сървъри и системи за бази данни, сървъри на бази данни и пакети от приложения, изминахме много, много дълъг път. Някога имахме голямо желязо, което трябваше да се справя с това, което е ефективно малко данни, и смях малко, когато погледнем назад. Онзи ден видях наистина чиста снимка в Twitter на тази невероятна дама, която беше водещият програмист и разработчик за НАСА по времето, когато пускахме мъже на Луната, а нейният код беше отпечатан на сто тридесет - два реда за колони и сгънати вентилатори и тя стоеше всъщност по-висока от нея, количеството код, което написа.
И като се замислих, ми хареса, всъщност вероятно това е около две-триста мега данни, където тя трябваше да го въведе най-много, ако не и по-малко. И така общото количество данни, за да може да държи кода й, въпреки че физически изглеждаше по-високо от нея, когато беше разпечатано на хартия, всъщност беше много, много малко количество. Дори тези масивни компютри в стайни размери, а това е IBM System / 360 в този конкретен слайд, количеството данни, което всъщност може да притежава, беше малко в сравнение с днешния свят. Всъщност нашите смартфони притежават 60 и 128 и 256 гига и скоро ще имаме терабайти в телефоните си, преди дълго, когато цената на светкавицата спадне.
И така по онова време и онази ера администрирането на базата данни беше доста ясно. Ето моментна снимка на терминална сесия 3270 и за DBA, която е в състояние да влезете и да разгледа броя на файловете, които са свързани с базата данни, и индексите, които са били там, и редовете и колоните са прави. И тук можете да видите на тази екранна снимка, че контекста на тази е една таблица и няколко пространства от таблици, които биха били целия мейнфрейм, управляващ една таблица от база данни. Докато днес ние държим милиарди редове записи в системи от бази данни. И промяната настъпи чрез промяна в технологията, която ни позволи да изградим платформи за бази данни и системи за управление на данни.
Ако помислим за вида на оригиналните мейнфрейми и много компютри, работещи с база данни и евентуално релационни бази данни, така преди петдесет и повече години, и този голям железен вид на света и малките масиви от данни, които имахме, към момента, когато стигнахме до осемдесетте години, ние бяхме нещо подобно, минахме през мейнфреймите от мини към микро и имахме компютри, изпълняващи неща като dBase II и dBase III, и на DOS и CP / M и имахме много ранна релационна база данни- наличните технологии за стил и те се мащабират доста добре в сравнение с това, което бяхме свикнали в мейнфрейм. По времето, когато стигнахме до деветдесетте години, имахме харесвания на Oracle и DB2. И в края на деветдесетте години имахме хора, като тайни компютри, които могат да залепват като мрежов модел, много, много големи машини, машини с размер на шкафове заедно и да вземат харесвания и да създадат тези клъстери от компютри. Но дори и тогава тя беше все още малка в сравнение с това, което виждаме днес.
Но в слайда, на който се качих тук, това е клъстерът Hadoop и ефективно действа като една машина и по същество това е просто наистина, наистина голям компютър и може да побере типовете данни от уеб мащаби, с които сме свикнали сега, И така предизвикателството за администриране на бази данни, управление на бази данни на тези видове платформи наистина се превърна в моята наука в ракетна наука. Трябва да си изключително умен персонаж, за да можеш да разбереш технологията, на която работи, платформата, на която работи, данните, които има там, типовете употреби на тези данни. И да, видяхме тази експлозия от началото на 2000-те години, където Microsoft SQL се превърна в нещо, Lotus Notes беше доста добре установен и там, а броят на базите данни на Lotus Notes, които пълзеха около мястото, беше доста плашещ. И ние имахме обичайните членове на Oracle и DB2 и наистина започнахме да се хващаме. Някои от марки като започваха да избледняват. Но ние все още наистина правехме традиционно администриране на бази данни точно до този момент, около тази епоха от 2006 г., където, ако се върна към този образ на този клъстер, ние получихме това, което нарекохме клъстери Beowulf, да стане нещо, където можехме свалете компютрите от рафта и ги залепете заедно и направете големи супер компютри.
Но от този момент нататък пресякохме най-важната точка, при която човешките същества бяха в състояние да направят администрация на база данни в старата школа и - както казвам, според мен - мащабът стана много, много голям много, много бързо. Това е почти като че ли имахме това голямо събитие в технологиите, което доведе до възприемането на технологията за данни и технологията за управление на данни и по-специално в базите данни около тях. И тъй като ние всъщност изграждахме високоефективни клъстери в изчислителен стил, за да хостваме данни под различни форми. И за да подчертаем тази точка, ето кратка снимка на пейзажа от 2016 г. на технологиите за бази данни, които са достъпни за нас. Намира се от долния десен ъгъл и отворен код, чак до горния ляв ъгъл в инфраструктурата. И в горния десен ъгъл в решенията за приложения, които са достъпни за нас, и в долния ляв ъгъл, смес от инфраструктура и производителност, които правят анализи и т.н. И в средата има устройства като нашите смартфони, разбира се, които всъщност работят на много малки версии на бази данни, за да правят неща като управление на контактите си и така нататък, или нашите дневници на обаждания и други неща, които имаме.
И така в съзнанието ми е имало тази експлозия, подобна на камбрийска експлозия в подобно нещо, при което количеството технологично развитие, което се е случило в този много кратък период от време от 2006 г. до 2016 г. сега, което на практика е десетилетие, както си беше. Сега видяхме, че графичните бази данни се превръщат в голямо нещо, базите данни в паметта се превръщат в голямо нещо, SQL базите се събират. Преминаването към различни изчислителни модели, Hadoop възникна, имахме модела MapReduce, сега имаме Spark и поточна анализа и поточни компютри, еластични разпределени данни, рамки, които хората трябва да разработят за тях, за да стигнем до мащабите, от които се нуждаем, и когато се замислим за това пътуване, да преминем през вида, какви са системите за управление на релационни бази данни с обичайните заподозрени, Oracle, PostgreS, Sybase, IBM DB2, MySQL и платформата Microsoft SQL Server. Сега видяхме някои нови деца да идват на блока, Clustrix, Xeround, NuoDB, MemSQL и има десетки и десетки повече, както сте виждали на този слайд преди. Ако можете да си представите предизвикателството да се запознаете с тези платформи и ноу-хау, за да ги стартирате и да получите единния прозорец на изглед на стъкло, че трябва да сте DBA и да правите тези неща, предизвикателството далеч не е тривиално. И тогава изведнъж се появиха двигателите NoSQL, които са съвсем нова порода забавление.
И така, финалният слайд, който имам тук, е нещо като най-добрия удар от един-два-три нокаута и това е, че ние сме взели някои от тези технологии сега и сме създали способност за обслужване за тях, поставихме ги в облачни модели и те вече са достъпни като помощна програма, като услуга, можете по принцип да получите база данни като услуга, а обичайните марки, които виждаме там в уеб услугите на Amazon и платформата Cloud Compute на Google и Microsoft Azure, са тези, които идват при хората ум, но всъщност вече има десетки и десетки облачни платформи. А в Австралия например има нещо като сто и дванадесет компании, които са добросъвестни мащабни публични облаци, които предлагат услуга за бази данни под различни форми.
Да мислиш за предизвикателството, което средният DBA трябва да стане от леглото и да отиде на работа и да се справи сега, е доста умопомрачително предизвикателство. И така аз съм много на мнението сега, че както много неща в живота, ние сме разширили тези хоризонтално и вертикално, тоест мащабът на инфраструктурата в много хоризонтален, почти линеен модел на растеж и сложността на стека в вертикален смисъл, броят на платформите на базата данни, броят на приложните рамки и моделите, с които трябва да се справим, са надминали над това, което хората трябва да могат да се справят в един прозорец на стъклен изглед и от какво има значение сега администраторите на база данни цял набор от нови инструменти, за да можете да разговаряте с всички тези платформи, да ги управлявате, администрирате и да ги поддържате и вярвам, че това е цялата тема на нашите разговори тази сутрин или днес следобед, вашето време, и като имате предвид това, Ще предам на нашия гост, който ще говори много за техния продукт и как ще се справи с предизвикателството.
Ерик Кавана: Добре, Скот, ще подам ръка…
Скот Уолз: Благодаря ви много, добре, благодаря. Благодаря Дез, благодаря Робин и благодаря на всички, че се присъединиха и ме приехте на повикване днес. Искам да благодаря на Робин и Дез за това, че ме заведеха на разходка по памет, след като бяхме в космоса от началото на деветдесетте години, ти върна много добри спомени. Споменът, който не видях на нито един от тези слайдове и снимките, бяха перфокартите. И това беше първото нещо, което ми беше представено, когато за първи път започнах на първата си работа извън университета, моят колега в куба до мен ми каза да не пипам неговите перфокарти. Така че, да, абсолютно, и това наистина беше предизвикателство и предизвикателство, по което работим, за да помогнем на нашите клиенти да се справят и от средата на деветдесетте години, и това е продукт, за който искам да говоря днес. Нека да разгледаме многоплатформеното управление и това е само подмножество. Избрах графика, но докато Дез се изправи -
Ерик Кавана: Трябва да споделите екрана си.
Скот Уолз: О, аз наистина, благодаря.
Ерик Кавана: Без притеснения. И хора, не се срамувайте, задавайте въпроси, днес имаме три умни панталони, затова им изпратете тежките въпроси. Можете да използвате Q&A компонента на конзолата си за уеб предаване или можете да туитирате с хештега на BriefR. Добре, Скот, отнеси го.
Скот Уолз: Ето, благодаря. Грабнах този слайд и това изображение. Образът от Dez наистина ме взриви, защото това е наистина светът, в който живеем днес, и светът, в който се изпълняват DBA. И както те споменаха, всъщност вече не се борите да успеете да направя това само с груба сила. Наистина ви трябват инструментите и това е, влизаме да играем и виждаме целия този превключвател, промяната на импулса там, където беше рано и бяхме много затворени, както споменахте, и след това преминахме към работа с множество платформи за бази данни, така че това беше първият ни набег в инструментите, а след това се върна на мястото, където организациите, и след 2000 г. и когато някак се стесни малко. С организациите и исках да станем стабилни, но след това се върна и просто наистина се взриви, когато въведете всички тези нови платформи. И сега, вместо да бъде гълъб вложена в конкретна платформа или конкретна технология, никоя от тези организации не открива кое е най-доброто. Коя е най-добрата база данни за приложения, каква е най-добрата платформа за използване? И с казаното, искам да ви разведа малко за това, което правим с DBArtisan. И DBArtisan е нашият водещ продукт, управляващ, както се казва, кросплатформен среди повече от 20 години, и това е мястото, където живеем и това е мястото, където обичаме да наблягаме и работим с нашите клиенти и да им даваме инструментите, за да ги направят продуктивни и изпълнено.
Нека продължим напред и ще вляза вдясно. Показвам продукта повече, докато минавам през слайдове и мисля, че вероятно и вие го правите. За онези от вас, които не са виждали DBArtisan преди това, ние разглеждаме компа, и мисля, че Дез използваше термина „единично стъкло“ и това е нещо, с което се гордеем, че даваме на DBA един-единствен поглед всичките им платформи. Точно така, няма нужда да отваряте друго приложение, ние ще се свържем и ще ви вкараме там и ще започнем да работим с платформата. Разглеждайки изследователя на базата данни вляво, можем да създадем това, както сметнем за добре, можем да го организираме, колкото ни харесва. И ще видите, че имам микс, аз някои от моите сървъри на Oracle, имам MySQL, имам PostgreS тук, имам и един - това е етикетирани производствени сървъри, че някои включват част от MySQL сървърната среда. Отново можем да видим точно там, че сме се напаснали добре. Ако гледам да регистрирам нова база данни, ще видите една от платформите, които поддържаме, има двойка, която искам да представя. Ще забележите, когато това е вашият SQL, поддръжка за това, Teradata, Apache, PostgreS, ето генеричните материали, които поддържаме.
Ако имаме драйвер за JDBC или драйвер за LDBC към някоя от платформите, ние можем да се свържем, да ви дадем връзка и да ви позволим да работите с платформата от DBArtisan. Отново, оставяйки ви да се съсредоточите върху работата, а не върху това как ще я свършите. Преминете през всичко това. Но искам да покажа няколко неща за продукта. В такъв случай нека се отворим и ще се занимаваме например с Oracle. Това е само моята малка целева страница тук, но искам да отида и да разгледам някои от моите схеми, с които работя. Ще изтеглим една от по-големите схеми, така че отново ще върнем списъка с таблици. Точно в този случай аз ще отворя таблица, така че ние просто ще ги изберем и ще ги изведем в нашия редактор на обекти.
Сега Oracle е нещо, с което съм работил от години, това, което ще ви покажа, вероятно е лесно изявление за вас. Но ако Oracle е платформата или PostgreS е платформата, или Teradata е платформата, която току-що сте получили и трябва да достигнете скорост, задачата е да добавите колона. Или може би задачата под ръка е да изтриете колона. Но не искате да се притеснявате за синтаксиса, нали? Искаме да отидем, просто напишете това, което ни трябва, задайте го и оставяме DBArtisan да генерира. Тук ще натиснем „Alter.“ Ще генерира сценария за нас. Отново много прост пример, но въпросът е, че ще свършим работата за нас, за да генерираме и поставяме тази колона в таблицата.
Това, което също можем да направим, е да преместваме колони в таблицата. Ако някога сте се опитвали да направите това с традиционното, това е малко по-сложно, отколкото просто един ред код като този. Но отново DBArtisan ще работи зад кулисите, ще генерира кода за вас и отново ще произвежда SQL. Ще затворим оттук. Преди да го направя, забележете отново всички раздели в горната част, потребителският интерфейс е много интуитивен. Ако вляза в изследователя, ако скоча на PostgreS, нали? Ако вляза в режима на схемата си там, погледнете таблицата, много подобен вид и усещане, нали? Ще отворим това, отново ще видим информацията тук. Свойствата, предците, колоните. Ние сме специфични за платформата, ще ви дадем това, потребителския интерфейс, за да можете да показвате това и да работите с обектите. Ще знаете какво трябва да направите и това ще ви даде възможност да го направите ефективно и навреме, така че няма нужда да се притеснявате точно каква е клаузата, която трябва да отидете там, за да предоставете тази опция. Ние ще се погрижим за това за вас.
Освен това, когато погледнем, сега ще се появи на SQL Server и ще поговорим малко за някои от другите функции, така че всички ние трябва да наблюдаваме базата данни. И така, започнете го, нека видим всички сесии, които се случват, сесии, които се изпълняват. Как ще видим какви изявления се изпълняват и ще можем да имаме контрол над това? Трябва ли да спрем сесия? Необходимо ли е да виждаме брави, които биха могли да бъдат в базата данни? Някакви блокиращи брави? Отново имаме цялата тази информация тук на една ръка разстояние, за да можем бързо да реагираме, да предприемем коригиращи действия, ако е необходимо, и да я обърнем. Ще се върнем при нашия изследовател. Това е мястото, тук е точката на шофиране, тук винаги се връщам, това е мястото, където аз лично обичам да започвам нещата и да работя от тук. Тъй като съм свързан с база данни на SQL Server, за да разгледам помощните програми. Тъй като сме кросплатформен, можем да започнем да гледаме на извлечения, миграции. Можем да се движим през платформи, ако трябва да мигрираме обекти от една платформа на друга, можем да го направим, при условие че тези обекти съществуват на различните платформи. Извличайте схемите, публикувате в отчети, зареждайте и разтоварвайте данни и архивирайте бази данни.
Отново всичко това от потребителския интерфейс. И стигайки до инструментите, можете да видите пълен набор от инструменти, от които можем да работим, нали? Между „Намиране на файлове“ можем да извършим цялостно търсене в база данни, където търсим вътре в системните таблици, за да намерим този низ, който търсите. „Изпълнение на скрипт и файлове“, ако имате стандартно изявление, което може да бъде изпълнено срещу множество платформи, множество източници на данни, можем да го настроим направо от DBArtisan, насочен към целите, срещу които искаме да се изпълняват. Натиснете „Отиди“ и той ще се стартира и ще ни върне резултатите спрямо всички тези източници на данни. Отново, оставяйки ви да работите от тази единствена стъкла.
И „Аналитична серия“ отново, те са по-задълбочени. Те са насочени повече към релационните бази данни, тъй като започваме да навлизаме в повече от по-новите платформи, вие ще започнете да ни виждате как разширяваме тази функционалност и на тези арени. И като цяло, само много подобрения на потребителския интерфейс. Функции, предназначени специално за DBA. Елементи като ние имаме възможността да правим скриптова библиотека. Онези SQL скриптове, които изпълнявате често срещу множество платформи, запишете ги тук, плъзнете го, веднага щом получим нов ISQL прозорец, можем просто да плъзнем скрипта и вече имаме готов скрипт. Отново, като имате това под ръка, за да можете да правите и управлявате. Ще забележите, че ние доставяме с вече дефинирани скриптове за някои от платформите, така че по всяко време да можем да създадем толкова, колкото е необходимо.
Хубаво нещо, което харесвам и много от нашите клиенти правят, ако някога се интересувате, и аз получавам този въпрос много по отношение на: „Как да направя това? Това е много готино. Как DBArtisan прави това? "Тук има малка функция, " Logfile ", можете да регистрирате всички SQL оператори, които изпълняваме, така че ако искате да знаете как попълваме това проучване или как попълваме редактора за PostgreSQL таблица или таблица на Teradata, регистрирайте SQL и ще запишем всичко, което DBArtisan изпълнява спрямо базата данни и можете да се върнете и да погледнете този SQL и да имате всичко, от което се нуждаем. Може би искате да включите това като част от един от вашите скриптове. Абсолютно. Напълно добре.
Ние обичаме да сме много прозрачни с това, което правим и какво изпълняваме срещу базата данни, следователно ще ви позволим да запишете и запишете всичко, което прилагаме към базата данни. Имаме и опции за конфигуриране. Ще забележите, че съм го настроил като „Организиране от собственик на обект“. Мога да създам и от „Тип на обекта“. Ако вляза в моята среда PostgreSQL отново, влязох в схемата, ако погледнах SQLs вместо само моите GIM таблици, принадлежащи към тази схема, ще видя всички таблици, независимо от имената на схемата. Отново различни начини да организирате неща, които наистина го персонализират за вашия собствен работен процес и как искате да го видите.
И последното нещо, за което искам да говоря, е възможността да задавам „Отметки“. Ако тренирам, ако работя в една от моите платформи и искам да се съсредоточа само върху режима си на таблици, мога да добавя отметка. Знам, много проста функция, но толкова хубаво да имаш, особено когато работиш с толкова източници на данни и толкова платформи, колкото е днешната DBA. За да можете да влезете в системата, стартирайте DBArtisan и оставете мениджъра на отметките да ви отведе до мястото на дървото, където трябва да бъдете и да можете да работите. И тогава от тук бих могъл да създам нова таблица и отново на платформите, които поддържаме, които видяхте по-рано, и ние ще ви преведем през „Wizard“, за да ви позволим да шофирате и да развивате и създавате таблицата. И ние ще генерираме целия синтаксис, необходим за това зад кулисите, и след това ще ви го представим в края в прозореца за визуализация. Можете да получите валидиране, да видите какво точно ще генерираме. Можете да натиснете бутона „Изпълнение“, след това бутона „Край“, нека да се изпълни. Или можете да го запишете или да го преместите в друг прозорец на ISQL, така че направете го отново, може би трябва да е част от по-голям, по-голям скрипт, който искате да запазите и разгърнете по време на часовете на вашия пакет.
Това е преглед на DBArtisan. Когато говорим за това, отново това е продукт, на който се виждат много платформи, поддръжка за тези платформи и страхотно потребителско изживяване, чудесна обратна връзка от нашите клиенти. И ако се интересувате като един от участниците, но ако трябва да намерите нещо, свързано с IDERA или DBArtisan, не се колебайте да се свържете и със сигурност можете да ме намерите на моя имейл адрес.
Ерик Кавана: Добре, предполагам, че ще го отворя на Робин за въпроси и след това Дез и след това ще наблюдавам въпросите и отговорите от присъстващите. Робин, отнеси го.
Робин Блур: Добре, искам да кажа, първия въпрос, аз всъщност бях запознат с DBArtisan от доста време, така че някак съм наясно с възможностите му. Това, което бих се интересувал от вас да се обърнете е нейните, бъдещи пътеки оттук. Искам да кажа, виждам, знаете ли, че последния път, когато го погледнах, сигурно беше отдавна. Виждам, че поддържате поне три бази данни, за които не разбрах, че сте подкрепяли преди. Какъв е пътят за DBArtisan? Вероятно ли е просто да добавяте все повече и повече бази данни или това е нещо с разширение? Къде смятате да отидете с него?
Скот Уолз: Това е чудесен въпрос и бих искал всичко по-горе. Със сигурност ще продължим да изграждаме, защото традиционните RDBMS платформи не стоят неподвижно, нали? Те продължават да надграждат. Ще продължим да следваме този път. И тогава ще ни видите да започнем да търсим и вървим в тази посока на подкрепа на нови нови платформи. Тъй като ние признаваме, че въпреки че някои от тези платформи продължават да се разрастват, традиционните RDBMS, има определени ситуации, че новите платформи са подходящите платформи, с които клиентите могат да работят. Ние наистина следим внимателно този пазар, този сегмент и се опитваме да вземем правилни решения на кои платформи да отидем. Изглежда се променят всеки ден, на практика.
Робин Блур: Е, както казвахме аз и Дез, това е много оживен пазар, вероятно е един от начините за това. Друго нещо, което би ме интересувало - очевидно няма да можете да отговорите на този въпрос с подробности, но попаднах на сайтове по мое време, където има хиляди случаи на Oracle, а Oracle не беше Знаеш ли единствената база данни, която се разгръщаше. И когато всъщност разговарях с тях за това как на земята успявате да управлявате толкова много случаи, те казаха: „Е, знаете, има само около пет или шест големи инстанции и имаме около три DBA, които сме разпространили в това.“ аз се интересувам от гледна точка на използването на DBArtisan, тъй като можете да направите страшно много с него, колко бази данни се намира над, да кажем обикновено, или дори какви са най-големите примери за колко низове може да управлява наведнъж?
Скот Уолз: Е, виждал съм ситуации - и отново, това е малко сложно, този въпрос е, защото DBArtisan ми позволява да имам множество връзки или множество източници на данни, дефинирани към един екземпляр. Може би искам да направя syslogin и след това вход с по-ниски разрешения, но се справих с клиенти, че с всичко сривано става няколко екрана. Сега, когато ги попитах, въпросът, който ми зададохте, е: „Как се справяте с толкова много?“ И тогава той казва: „Не го правя“. „Управлявам това, което мога, но имам нужда от достъп до всичко.” Тепърва ще виждам всичко, което спира, знаете, горните граници на това, което хората могат да управляват, са наистина горната граница на това, което този човек, индивидът, може дръжка. Но знаете, както споменах, тези хора, с които аз предизвиквам, те открито признават, че имат всички тези връзки, но няма начин да го управляват. Те разчитат на своя екип. Както съм сигурен, че сте преживели, да.
Робин Блур: Ами аз самият всъщност съм бил DBA, въпреки че не съм го правил много дълго. И единственото нещо, което, знаете, помня, над и над всичко друго в релационните бази данни, е, че можете да правите огромно количество неща с SQL. Често повече, отколкото си мислите, че бихте могли. Което по един или друг начин обяснява част от функционалността, която DBArtisan има, защото просто се превежда директно в SQL. Но, знаете, сигурен съм, че правите и други неща. Всичко това е SQL скрипт или има други специални процедури, написани за езотерични ситуации?
Скот Уолз: Да, много от него, по-голямата част от него е SQL, това е само природата на това. Но ние пишем подпрограми, които могат да бъдат стартирани от команден ред, използвайки инструментите на доставчика, предните краища на доставчика. Ще поставим предните краища, например, за помощните програми за зареждане на данни в платформите, нали? Това не са SQL скриптове, нали, това са задания от командния ред. Той ще генерира тези и ще може да ги даде на DBA, които след това могат да изпълнят. Вижте да, ще направим малко от двете, но по-голямата част от тях са SQL скриптове.
Робин Блур: Като гледам, защото очевидно трябва по един или друг начин да се вгледате в развитието, което протича, което считам за сравнително ново. Искам да кажа, че едно от нещата, които ми се струват интересни, че се случва е, че Spark очевидно излита като ракета, но SQL на Spark, той премина от ужасно незрял начин да започне да изглежда малко по-зрял с малко повече SQL възможности. Гледаш ли на такива неща и се чудиш дали ще започнеш да управляваш тези с DBArtisan?
Скот Уолз: Със сигурност и аз. Това винаги е там. Знам, че нашият екип за управление на продукти винаги гледа къде да отидем и абсолютно всичко е на масата за нас, що се отнася до това, което гледаме в бъдеще.
Робин Блур: Добре, Дез, искаш ли да се натрупаш?
Дез Бланчфийлд: Да, всъщност има куп страхотни неща, които отворихте вратата за мен там, Робин. Благодаря ти много. Искам просто да проуча някои от нещата, които ми изскачат, когато гледам продукти като този и се вълнувам много. Когато двойно проверих домашната си работа, защото подобно на д-р Робин Блур, споменат преди, той, както и аз, следя това от известно време и си спомням, че видях вашите изисквания за спецификации на другия ден и мислех, всъщност това нещо работи само опира се до това, което всъщност прави. И аз си мисля от паметта - поправете ме, ако греша - мисля, че беше толкова малко, колкото производителността на лаптоп удобно да управлява DBArtisan и въпреки това беше в състояние да изпълни някои доста значими задни крайни бази данни. И много ми беше интересно да видя, че и сега имате Firebird и Greenplum. Бях доста впечатлен от изискването или спецификацията на хардуера, който може буквално да работи като концерт RAM в един гигагерцов процесор. Това беше доста впечатляващо.
Но случаите на употреба са нещо, в което искам да се задълбоча само малко. Виждате ли, че поглъщането на продукта е случай на нужда поради съществуваща среда, която току-що излезе извън контрол, или виждате, че хората сега са малко по-активни и казват, знаете, че изграждаме нещо много голям, той е сложен. И аз обмислям сливания и придобивания, например тук, където една организация може да купи куп фирми - малки, средни, големи, какви ли не - и в крайна сметка да наследи всички тези среди и да се наложи да изгради нова способност за БД. Какви са обикновено използваните случаи за това, що се отнася до типа организация и вида на приложението към нея? Дали това са предимно хора, които имат съществуваща среда и трябва просто да ги почистят и да получат контрол над тях или хората са малко по-инициативни и мислят за сложността, която предстои да построят и да ви качат на борда рано?
Скот Уолз: Виждаме повече да станем рано поради същата причина, която споменахте, консолидацията. С широтата на поддръжката на платформата, която имаме, това не е пълно бъдещо доказване, нали, но това поставя вас и вашите DBA в наистина добра ситуация, че когато те прегледат потенциална цел за придобиване, нали, те са малко по-малко, знаете ли, мисълта какви платформи можем да наследим, нали? Макар че е важно, нали, загрижеността там е малко по-малка от това, което ще означава за нашите DBA, нали? DBA имат продукт сега, след като знаят, че могат да се свържат и ако са запознати с използването на продукта, те ще бъдат запознати с свързването към тази платформа, която току-що са придобили. Така че това със сигурност е област, която виждаме, отново знаете ли, клиентите с това объркване на всички тези платформи, нали? Как ще разгърна това, нали? И те са го опитали, защото мисловният процес е всяка от платформите да има инструмент, нали? Можем да използваме собствен инструмент, нали? Но в крайна сметка се връща, че знаете какво, да можете, но не само аз ще трябва да науча всяка една от платформите, сега научавам всеки един от инструментите, които се предлагат с всяка една от платформите и така че току-що сложихте работата на DBA. Така че виждаме и онази ситуация, в която те се връщат при нас и казват: „Знаеш ли, ние трябва да се спрем на това. Нека да вземем един инструмент за DBA, защото имам по-важни неща за DBA, отколкото да науча потребителския интерфейс на нов инструмент. Или различни инструменти. "
Дез Бланчфийлд: Да, определено не. И, знаете ли, когато видите, мисля, че от паметта, когато вчера погледнах само за да проверя, че не съм сгрешил, помня, че сте подкрепили Sybase например, така че това нещо е известно време. Имам още един въпрос, който всъщност имах за вас - да, чудесно е да имате Greenplum и Firebird в списъка си, но вашият Sybase, такъв тип отлежава много бързо, показва, че е известно време и е свършил добра работа.
Клъстери. И така, едно от най-големите главоболия за DBA е, че те ще посочат по същество това, което прилича на IP адрес и куп API, или дали е JDBC или LDBC или каквото и да е, за което може да си говорим, но зад това има клъстер. Какво може или DBArtisan знае за това, което стои зад врата номер едно, както беше, когато влизам в задната част на базата данни, трябва ли да видя всички среди зад тях, и по-специално, така че има две части към въпрос, може би. Клъстерът например, когато се замислите, знаете, че поддържате IBM DB2 и Microsoft SQL Database Server и MySQL и PostgreSQL и Oracle и някои от тези традиционни RDBMS и, знаете ли, неизменно изпълняваме главен подчинен или главен мастър среда за излишък и висока наличност, а също и производителност. Знае ли DBArtisan, че зад врата номер едно има нещо, което само по себе си не е една база данни, а клъстер и ако да, какво знае за това? И да влезете в това бързо, за да можете да отговорите на същия въпрос, извинете. И така, зад клъстерите в някои от сценариите, които имате, как хората се справят с микса между производствена среда и среда за възстановяване при бедствия, доколкото се отнася до използването на DBArtisan?
Скот Уолз: Страхотни въпроси. Ще ви кажа, че това ще зависи от конкретните платформи, защото колкото и да се опитваме, ще имаме различни нива на поддръжка за някои от тези задълбочени, по-дълбоки функции надолу. За Oracle, например, и тяхната RAC среда, Real Application Cluster, можете да се свържете с основния възел в този клъстер, но все пак преминавайки през монитора на базата данни, който показах, ще ви позволим да видите SQL да работи и ние ' всъщност ще ви кажа на кой възел от клъстера работи, нали? За да ви покажем точно дали, знаете ли, бавно изпълняваната заявка, нека да следим за това, на кой възел работи? Тъй като неизбежно цялата причина за клъстера, нали, е за крайния потребител, той не се интересува къде е изпълнен, но за DBA трябва да следим този тип информация. Например можем да се спуснем до това ниво на детайлите в Oracle. Останалите платформи, които имаме, имат свързаност, вероятно не толкова подробни, отколкото за Oracle.
Що се отнася до производството и средата за развитие, това е добър въпрос. Ние предоставяме същото ниво на подкрепа. Истинският основен начин, по който ще помогнем, слоят за свързване ще е там, нали? Ще можем да се свържем и да направим всички функции. Имам клиенти, които използват някои от функциите в DBArtisan, за да категоризират своите източници на данни, нали? И отново това може да е малко за точния въпрос, който задавате, но ние ще им дадем възможност да се обозначат графично, докато работят. Тъй като това е едно от нещата за DBArtisan, бързо ли мога да се променя между източници на данни. И следващото нещо, което знаете, че се готвя да пусна изявление за прекъсване и гледам да видя дали съм свързан - направих ли това срещу производството или развитието? И така ние предлагаме някои функции в DBArtisan, за да помогнем на DBA там, както и да управляват това и да ги предпазват от проблеми, ако щете, с някои от дейностите на DBA.
Dez Blanchfield: Имайки това предвид, в дългия списък от платформи, които в момента поддържате, и съм сигурен, че ще избухне много скоро по очевидни причини. Искам да кажа, че подкрепяте харесванията на например DB2 на z / OS, например, на мейнфрейм, а след това очевидно подкрепяте харесванията на това, което използвахме да наричаме среден обхват, но сега само UNIX системи и нещо като по-модерни платформи, вие знайте, Linux и след това в крайна сметка той ще бъде пренесен на харесванията на Bluemix и на Cloud Foundry, така че ще завършите с DB2, работещ в Cloud Foundry на Bluemix, с IBM и облака на soft. Хората в момента управляват ли не само управлението и мониторинга, но и вие споменахте преди възможността за миграция и преместване на данни. Виждате ли хора как скачат в леглото с DBArtisan и казват: „Знаеш ли какво, ние имаме куп неща на старите мейнфрейми, които просто трябва да слезем и беше истинска кавга да направим това. Ако мога да насоча, щракнете и плъзнете от тук до там, всъщност мога да преместя и мигрирам моите данни и моята схема. “Това нещо, което хората правят?
Скот Уолз: Те наистина се движат, нали? Преместват данните, нали? Сега те използват DBArtisan като инструмент за това. Прави ли всичко за тях? Не. Започваме, знаете, влаченето и пускането, не точно там, но им даваме възможност да генерират някои скриптове, защото в идеалния случай ще искате да използвате - не искате тази работа да бъде работи на вашия клиент, на вашия лаптоп, по самата причина, която споменахте. Можем да бягаме по много нисък отпечатък, нали? Ние им помагаме да генерират скриптове и след това да ги обърнем и изградим и след това те могат да доставят този скрипт и да го пуснат на сървъра, нали? И вземете силата, конската сила зад сървъра, за да направите това. Помагаме им да генерират част от работата си, за да свършат част от тази работа.
Дез Бланчфийлд: Точно така. Няколко последни за вас и тогава може да се върнем назад. Нещото, което наистина ме порази, просто преживях вашето допълнение, което е фантастично, и всъщност бих искал да имаме още един час, за да разгледаме повече подробности. Наистина голямо предизвикателство за DBA, нали, е основното спазване, цялостното управление на инфраструктурата, одити, отчитане на текущото състояние, гледане на бъдещи подготовки за неща като, знаете ли, просто общ растеж на околната среда. Поразява ме, че макар че в основата на това, което изглежда вашият продукт, е просто да улесните живота, един стъклен прозорец, единствен поглед към света, и по същество мога да щраквам и насочвам и влача и обичам факта че бих могъл да обуча някого да прави това много бързо сега, той не трябва да чете наръчника, както беше. Поразява ме, че инструментът също ми дава възможността да правя цял куп неща около управлението и спазването и одитите, че се чудя дали хората наистина са се събудили, сигурен съм.
Но виждате ли хора сега да го погледнете и да отидете, и е като тази еврика, а-ха момент, отивайки: „Ей, знаеш ли какво, това прави живота на DBA наистина лесен от сега, или по-лесен от оперативна гледна точка или гледна точка на развитието. Но боже, всъщност можем просто да отчитаме всички наши бази данни сега и всички набори от данни и всички безсъдържателни данни и всички метаданни наоколо. Като например, кой има достъп, когато има достъп, защо има достъп и какъв тип достъп има. "И изведнъж се обърнете към някои предизвикателства около спазването. Особено когато имаме някои наистина големи неща, свързани с нарушения на данните. Имаме някои невероятни неща като глобалните финансови кризи, всички тези предизвикателства предстоят, но как, по принцип, ще измерваме и следим и решаваме спазването? Дали това е голямото нещо за хората все още или все още е, някак си, в ранни дни, що се отнася до прилагането на DBArtisan към него?
Скот Уолз: Имам клиенти, които не могат да кажа достатъчно за DBArtisan. Сега това са тези, които са осъзнали това. Крушката се запали. Те казват: „Чакай малко. Мога да отговоря и да отговоря и да генерирам някои от много отчетите, които споменахте, нали, всички от един инструмент. Имам го. “Сега има други, които тепърва ще се захващат с това и това може да е по различни причини, нали? Те може да не са още или може би това се обработва от някой друг, но нашите клиенти, които открихме, че го използват, това е момент от а-ха, нали? Това не само съм в състояние да създам таблица на всички тези неща. И абсолютно, при всички изисквания за съответствие, той е огромен. Това е работа сама по себе си.
Дез Бланчфийлд: Е, наистина. И знаете ли, искам да кажа, от върха на главата ми веднага се замислям, знаете, ако има някой, който казва, че е искал да създаде база данни за управление на конфигурацията, CMD, ако трябва да се срещнат с всичко от Sarbanes -Oxley да КОБИТ към ITIL, знаете, SWIFT спазването и банковото дело, дори се свежда до харесванията на Международната организация за стандарти, ISO 27001, 27002. Това са всички тези наистина големи рамки. Едно от предизвикателствата е просто да намеря къде са данните, кой ги управлява, в какъв формат е и мисля, има за мен, като за мен просто го гледам сега, когато момента на Eureka току-що излезе, беше като, виси на секунда, бих могъл да го вкарам дори в някой, който не е непременно DBA, но бих могъл да го тренирам бързо и да кажа: „Има инструмент за спазване на изискванията.“ Мисля, че е чудесно, че си върши работата в база данни на администрацията свят на управление.
Но аз седя тук и мисля, боже, знаете, факта, че можете да управлявате множество платформи като една в наши дни и можете да се гмурнете веднага, както казахте, да регистрирате транзакциите, които правите. Знаеш ли, представете си как да вземете този инструмент при инцидент с нарушаване на данни и вие ще накарате екипа си по сигурността да се опитва да намери какво е къде и защо и кой какво вижда. И докато се движат наоколо, те трябва да регистрират и проследяват всяко действие, което правят, защото могат да станат част от проблема, ако не могат друго. Да, мисля, че тук е невероятна способност, която, знаеш, веднага можеш да започнеш да правиш, знаеш. По-специално, когато разглеждаме предизвикателствата на одитите на данни, които знаете, ние имаме това огромно нещо като пълзене на функции, както беше, с набори от данни и данни.
И едно от нещата, за които говорихме в още няколко предавания, които направихме, е, знаете, как да отидете и да намерите данните си и често говорим за факта, че когато стартирате във всяка организация, вие сте склонни да изправете се в кабината си и сложете ръка във въздуха, вълната и отидете: „Някой знае ли къде е тази база данни? Как да стигна до този източник на данни? Къде е този файл? "" Отиди и поиска прием. " Инструментът ви може незабавно да предостави тази възможност да намери неща и да ги открие и дори да отчете за тях.
Върнете се накратко към един от въпросите и след това ще завъртя и ще се върна на Ерик. Поразява ме, че мащабът ще се превърне в предизвикателство през следващите 12 години за вас. Можете ли да ни дадете някаква представа, само на трийсет хиляди фута гледна точка, предполагам, в мащаба или в обхвата на мащаба, в който DBArtisan идва да работи. Мога да си представя, че когато сложа това на лаптопа си и се развих и го насочвам към среда, мога да го открия и мога да започна да правя нещата върху него. Представям си, че става като едно малко малко, знаете, отворено изходен код на малкия двигател на базата данни с няколко реда и таблици. Какъв мащаб ще стигне? Говорихте за DB2 в мейнфреймите, това е голямо. И клъстери. Какъв е обхватът на мащаба, с който можем да се справим тук? И Робин докосна това по-рано, но просто ще трябва да се спра на малко по-подробно за това колко големи можем да постигнем с DBArtisan.
Скот Уолз: Разбира се. Със сигурност ще бъдат вашите предизвикателства, защото това е клиентска част от софтуера. И така, отново, ако работя върху мейнфрейм, когато работя срещу нашата тестова система за основната рамка, която имаме, мога да я насоча към милиони редове и да правя кръстосано съединяване срещу милиони редове. Цялата работа ще се свърши на сървър, нали, защото ние предаваме тази команда и това е само въпрос на DBArtisan да борави с набора от резултати, нали? И така това е предизвикателството и това е красотата на това, което правим. По-голямата част от вдигането на тежки се извършва на сървъра. Ние просто обработваме всички резултати. И така, отново попадате в ситуации, разбира се, когато искате да стартирате десет заявки едновременно, които връщат милиони редове, да, абсолютно може да се окажете в някое представяне там, нали? Но в нито един момент нямам клиенти, които се страхуват да изпълняват големи заявки срещу DBArtisan, знаете ли, срещу тяхната база данни. Както вече казах, пробегът варира в зависимост от много фактори, нали, но отново, както казах, имам работа с милиони редове, които се връщат и стига да запълни мрежата, знаете ли, аз ' готов съм да тръгна. Но понякога очевидно трябва да чакам резултатите да се върнат.
Дез Бланчфийлд: Имам въпрос към вас, преди да приключа, защото ви отнех твърде много време и ви благодаря за това. Просто ни кажете малко повече наоколо, знаете, четене на най-новите спецификации вчера, само за да се уверите, че съм бил и до мен, както си мислех, че съм. Наблюдение на процесите и вид аларми и известия, знаете, планирането на капацитет създава всички големи проблеми с DBA, всеки ден всеки ден, знаете. Някой ще попълни ли тази таблица, ще попълни ли базата данни, ще запълни ли дисковото пространство, което имам, как да го управлявам? Дайте ни бърза крачка по вид наблюдение на процеса и по-специално мониторинг на сигналите, а в идеалния случай около планирането на капацитета. Мисля, че това е област, която мисля, че може да има голям интерес.
Скот Уолз: Мониторингът на процесите показа, че функцията, която повечето от нашите клиенти използват и това е монитор на база данни, за да може да покаже и направи това. И ние имаме някои в пакета с анализатор. Performance Analyst има някои сигнали, които можете да настроите, когато определени прагове са спазени. Може да ви предупреди. Може би X брой регистрационни файлове, грешки в лог файла, знаете, ще излезе предупреждение за вас. Пространството на таблицата удари определен процент пълно, можете да получите друг сигнал. И красотата на това е, че сте в един и същ инструмент, нали, той е част от DBArtisan, така че просто кликнете с десния бутон върху грешката, сигнала и управлявате с DBArtisan и това ви отвежда право до редактора на пространството на таблицата, И можете да се обърнете към проблема точно там.
Що се отнася до капацитета, абсолютно това е горещ бутон и анализаторът на капацитет, който в момента имаме, е пренесен на SQL Server, Oracle, DB2 LUW и Sybase ASE. И това прави точно това, което описахте. Можете да започнете, след като получим някои колекции, нали, и след като получим размер на извадката и може би нейният размер на редовете, може би броя на обектите й, много опции в инструмента, и тогава можете да започнете да се движите, нали? И как ще изглежда след шест месеца? Как ще изглежда след дванадесет месеца? Мога да направя тенденция към, просто тенденция към дата или мога да се стремя към стойност, нали? И пример, който имахте, имам X количество дисково пространство, въз основа на това, кога ще достигна тази граница? Въз основа на растежа, който имам, и тези колекции, които направих, кога ще достигна тази граница? Поне знам, че мога да започна да планирам това. Ще минат ли шест месеца, ще минат ли две години? Но отново можем да използваме анализатора на капацитет, за да се стремим към това.
Дез Бланчфийлд: Това е страхотно. Фантастична демонстрация. Наистина ми хареса. Ще се върна към Ерик, защото знам, че има няколко въпроса, които изскочиха от нашата невероятна публика днес. Благодаря ви много, наистина беше чудесно да се запознаете добре с продукта и с нетърпение очаквам да го наблюдавам много внимателно.
Ерик Кавана: Добре, добре. Имаме няколко добри въпроса. И ние вървим малко с времето, така че ще се опитаме да приключим бързо, защото знам, Скот, имаш затворен твърд стоп. Ето един голям въпрос. Какво ще кажете да работите върху стари хранилища на данни като VSAM и Model 205, IMS и IDMF и подобни неща? Виждате ли това много често в наши дни и колко добре работи?
Скот Уолз: Не искам да ти казвам, че си заседнал. Някои от тези среди, ако имат ODBC или JDBC и знам, че някои от тях са там, можем да се свържем с него и можете да работите с него по този начин. Но в по-голямата си част зеленият екран е начинът да продължите все още.
Дез Бланчфийлд: Обожавам зеления екран.
Ерик Кавана: Добре знаете, както Дез посочи с този слайд, където имаше всички онези различни приложения и инструменти, които са налични днес, това е много обезсърчаваща реалност за всеки, който иска отговорно да изпълнява функцията на администратор на база данни. И предполагам, че с течение на времето вие момчета можете да изградите конектори към всеки един от тези инструменти, както и когато клиентите изискват, и така нататък, нали? Така че можете да активирате онова стъкло.
Скот Уолз: И това беше големият ключ за създаването на DBArtisan оборудван, за да може да се справи с тези JDBC и ODBC връзки. Наистина го разширихме сега. Сега, докато имаме тази връзка, нали, стига да имаме този драйвер, можем да се свържем и да работим срещу него.
Ерик Кавана: Това са добри неща. Ами хора, архивираме ги всички за по-късен преглед. Публикувах линк към слайдовете, надявам се, че можете да го видите чрез SlideShare. Благодаря много за всичките ви усилия, господа. Чудесно излъчване днес отново. Много добри слайдове. Много добро съдържание. Обичах това демо. Наистина е интересно, че вие сте насочили много сладко място на пазара, тъй като в наши дни има такава експлозия от типове база данни. И просто ни е нужно, като мениджъри, някакво място, за да се справим с всичко това. Браво, момчета. Утре ще ви догоним за още една гореща технология. Надявам се, че сте издълбали час утре. Същото време. Същата станция. Ще те догоним следващия път, хора. Пази се. Чао чао.
