Співробітники компанії «Техопедія», 24 серпня 2016 року
Винос: Ведучий Ерік Кавана обговорює тенденції в базі даних з докторами Робіном Блором, Дезом Бланчфілдом та Скоттом Вальсом у цьому епізоді "Гарячих технологій".
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Дами та панове, привіт, вітайте на найгарячішому шоу світу IT підприємств, Hot Technologies 2016. Так! Мене звуть Ерік Кавана, я сьогодні буду вашим ведучим шоу на тему "Мистецтво видимості: увімкнення управління кількома платформами", так. Кілька швидких записок, слайд про ваш справді, правда, з п’яти років тому і досить про мене, зачепив мене на Twitter @Eric_Kavanagh. Рік гарячий, це наш стандартний слайд для Hot Technologies. Що ми зробили з цього шоу, ми хотіли, щоб програма, яка допомогла б нам визначити конкретний вид технології, тому вся ідея полягає в тому, що ми отримуємо двох аналітиків, які приїжджають і займаються певним простором або певним типом функції що потрібне підприємству, і тоді постачальник заходить і демонструє, що вони створили, і пояснює, як це відповідає тому, що ви чуєте від аналітиків.
І причина цього, як ви можете собі уявити, полягає в тому, що у світі маркетингу корпоративного програмного забезпечення існують терміни, які стають непростими, і те, що незмінно трапляється, полягає в тому, що постачальники захоплюються до останнього гарячого терміну, такі речі, як великі дані або аналітика для Наприклад, або навіть SOA або різні терміни, такі як платформа, а іноді ці слова є дуже точними для певної технології, а іноді й ні. Це шоу було покликане насправді допомогти нам сформулювати для вас, аудиторію, які конкретні види технологій працюють, як вони працюють і коли ви повинні їх застосовувати.
З цим я збираюся представити наших спікерів. У нас є наш власний доктор Робін Блер, який телефонує зі свого місця в Остіні, Техас, Дез Бланчфілд, що дзвонить з іншого боку планети, і наш гість Скотт Уолз, який заїжджає з Кентуккі. І по-справжньому, я фактично за межами Пітсбурга, тому у нас сьогодні існує цілком геологічна організація з різних місць. З цим я збираюся підштовхнути перший слайд Робіна, сміливо задайте питання, до речі, люди, не соромтеся. Це можна зробити за допомогою компонента Q&A на консолі веб-трансляції. І з цим я віддам його доктору Блору. Підлога ваша.
Робін Блор: Гаразд, дякую за вступ, Ерік. Дозвольте мені просто дістатися до першого слайду. Це колекція meerkats, що думають про базу даних. Ця презентація дійсно, що я тут роблю, це насправді лише загальний набір думок про базу даних, які я нещодавно мав на увазі, що справді близько 2000 року, здавалося, гра в базу даних закінчилася в сенсі що переважна більшість реалізацій баз даних відбувалася на реляційній базі даних. І тоді це просто змінилося, знаєте, всі ці речі, про які думають meerkats, магазини стовпців, сховища ключових значень, бази даних документів, база даних пам'яті, база даних графіків та ще багато іншого. І це було майже як новий вид геологічної епохи, коли раптом з'явилися копалини різних видів тварин.
Новини з озера Вобегон, для єдиної бази даних дійсно закінчено. Немає сумнівів, що RDBMS все ще домінують, але зараз створені інші види баз даних. Дійсно, це майже огляд того, що я збираюся тут сказати.
Розміри бази даних, деякі з них насправді стали більш важливими останнім часом, але ті, про які я міг подумати, коли я робив цей слайд, у будь-якому випадку, чи було це масштабування з точки зору ефективного використання ресурсів будь-якого сервера? Він масштабується, щоб він міг перетинати великі скупчення? Чи використовує він наявне обладнання, яке базу даних в пам'яті йде в цьому напрямку? Чи він розподілений? Існує ряд баз даних, які важливі за варіабельністю для розповсюдження. Які характеристики він має? Фундаментальна кислотна характеристика бази даних. Але тепер замість того, щоб мати реальну узгодженість, ряд баз даних має можливу узгодженість, люди користуються ними, і з ними не виникає проблем, тому вони продемонстрували, що кислотна кислота не є абсолютно необхідною, просто добре мати безліч ситуацій.
З точки зору організації метаданих, вся гра змінилася. У нас є різні організації метаданих, а не типова схема RDBMS. Що стосується оптимізатора, то надзвичайно багато активності оптимізатора відбувається в залежності від структури даних, яку ви намагаєтеся оптимізувати. Що стосується керованості, то в цьому є велика розбіжність, про яку я піде пізніше, але в основному вся суть СУБД є керованою, і знову-таки ступінь її керованості певною мірою визначає ступінь її корисності.
З точки зору апаратних факторів, це справді те, про що говорять - я маю на увазі, що тут робиться лише один момент - справа, яка робиться тут, полягає в тому, що все, що ми сьогодні дивимося, з точки зору архітектури баз даних, зміниться. Це можуть бути ті самі бази даних, але їм доведеться, так чи інакше, враховувати, що відбувається насправді на апаратному рівні. Протягом багатьох, багатьох років ми мали цю відносно просту ситуацію з процесором, пам'яттю та спінінг-диском - ну це вже пішло, насправді.
Справа в цьому, перш за все, у нас є процесори, але вони мають набагато більше паралельних можливостей, ніж раніше, з багатьма, різними ядрами обробки. У нас також є графічні процесори, у нас також є FPGA, різні види кремнію, але Intel одружилася на одній FPGA з процесором у наступному випуску, і - AND - одружилася разом з GPU та процесорами на одній мікросхемі. У вас є фішки з різними характеристиками. Перевага GPU полягає в тому, що він дійсно чудовий для важкого паралелізму і особливо для чисельного обчислення. FPGA ви можете, так чи інакше, поставити код на чіп, і він функціонує набагато швидше, ніж якщо ви просто подаєте його на чіп.
Там відбувається схрещування цих речей. У нас є 3D XPoint від Intel та PCM від IBM, це нові типи пам'яті, які повільніше, ніж оперативна пам'ять, менш дорогі, ніж оперативна пам'ять, але енергонезалежні. І це створює трохи хвилювання серед ряду постачальників програмного забезпечення, з якими я говорив. У нас є SSD, але тепер вони стають дуже, дуже великими і вони забезпечують паралельний доступ. При паралельному доступі до дуже великого SSD ви можете наблизитись до швидкості читання, подібної швидкості читання ОЗУ. У нас є така можливість оперативної пам’яті трьох типів пам’яті, речей 3D XPoint та SSD-дисків, які все пройдуть надзвичайно швидко. Оскільки швидкість є сутністю бази даних, всі технології бази даних намагаються використовувати їх якомога швидше. І це стосується паралельної архітектури, але масштабує паралельну архітектуру. Продуктивність апаратного рівня постійно прискорюється, це робиться протягом багатьох років, продовжує це робити, а загальні витрати падають.
Сльоза. Це просто різні спроби баз даних, перші бази даних перед реляційними в основному називали мережевими базами даних, потім прийшли реляційні бази даних, потім прийшли об'єктні бази даних, вони не отримали великої тяги, потім з'явилися бази даних, що зберігають стовпці, які чи були реляційні бази даних зроблені дуже по-різному. І тоді у нас були бази даних документів і бази даних SQL, які були об'єктними базами даних, зроблені по-іншому, або, якщо вам подобається, той самий стовпець об'єктних баз даних, і вони зачепилися. А нещодавно у нас були бази даних графіків, які набирають тягу та бази даних RDF. І те, на що ви дивитесь, - це принаймні три різні набори структур даних, які розміщуються. Реляційна база даних дуже добре виконує таблиці та рядки. База даних документів та бази даних об'єктів - вони дуже добре створюють структуру даних, особливо ієрархічні структури даних. І графічні бази даних та бази даних RDF дуже добре роблять мережеві структури даних. І ці різні, я вважаю їх трьома рядками, ці рядки триватимуть нескінченно. Це не зупиняється, оскільки двигуни, які добре роблять ці речі, не працюють на іншій структурі даних особливо добре.
І тоді ми отримали псуючий фактор Hadoop. Hadoop - це не база даних, але є бази даних, які використовують HDFS для своєї структури зберігання. І багато речей, які робить Hadoop, - це такі речі управління, які потрібно зробити для бази даних. Також варто згадати, що Spark теж не є базою даних, але вона є, і вона є незрілою, але в неї є оптимізатор SQL, і тому це як ядро бази даних, не обов'язково знаючи, де ви збираєтеся зберігати дані, але якщо вставити його на HDFS, багато вимог до бази даних реально задовольняються, просто можливостями базової файлової системи. Зокрема, іскри стали частиною екосистеми баз даних, і вона часто об'єднується з більш потужними базами даних, і причиною цього справді є аналітика. Аналітика - Іскра - це дуже добре, дуже швидко йде аналітика. Аналітика - це головний додаток, в який більшість людей зараз інвестує кошти, тому двоє йдуть на руку. Федерація даних, а не правила концентрації, має виглядати очевидно з того, що у вас є щонайменше три різні потреби, структуровані види баз даних, а отже, федерація даних, якщо ви хочете поділитися даними між ними. Це часто необхідно, але у вас також є бази даних, які масштабують масштаб, і бази даних, які не мають, дійсно потужні двигуни, такі як Teradata або Vertica, мають дуже особливе місце, але менші двигуни, які можуть виконати дуже багато роботи, отже, федерація швидше за все, існує навіть між реляційними базами даних.
І останнє, що потрібно сказати, IoT, це не закінчилося, поки товста леді не почне розбирати дані. IoT цілком може створити в тій чи іншій мірі різну динаміку у світі баз даних, що ще більше ускладнить справи. Сподіваємось, відбудеться - так чи інакше - якась конвергенція, яка продовжується, але я не бачу, щоб все це поєднувалося так, як це було з реляційними базами даних. Не так скоро, все одно.
І я думаю, що це все, що я маю сказати, тому я передам її Австралії.
Дез Бланчфілд: Дякую, Робін. Дякую всім, що приєдналися до нас, дякую за те, що я зібрався сьогодні вранці або вдень. Це дуже гаряча тема, тому що ми пережили досить вибух за останнє десятиліття і трохи, за кількістю даних, з якими нам доводиться мати справу, і незмінно, що дані знаходяться в якійсь формі системи, що для більшості випадків це база даних певної форми. Я думав, що швидко проведу нас через дуже високий рівень прогулянки через те, як ми потрапили сюди, і проблему, що створюється, і типи речей, які нам потрібно вирішити зараз, а потім ми поговоримо про типи рішення, яке можна застосувати до цього. Дозвольте мені просто захопити свій перший слайд тут. Я вважаю, що зараз ми знаходимось у тому, де адміністратор БД 2.0 або адміністратор бази даних 2.0 - це те, де ми зараз подібні, колись адміністратор бази даних був досить очевидною роллю та проблемою. і ви могли досить швидко тренувати когось. У сучасному світі це вже не так, і я збираюся показати вам, чому це так.
Колись адміністратору баз даних можна було б підключитися до заднього кінця БД і зробити швидке показ баз даних, і в системі з'явиться список баз даних, про які вони повинні бути обізнані, і вони можуть дуже швидко перейти цих баз даних, виберіть їх, а також трохи натисніть і зондуйте, і використовуйте перекладати, опишіть таблицю, щоб дізнатися, що є в таблиці та кожному зі стовпців і рядків, і це було досить простою проблемою, і якщо ви читаєте середню дві-триста сторінок книги про адміністрування баз даних для кожної платформи, ви змогли майже навчити себе, не маючи ступеня ракетної науки.
Але це вже не так, і, на мій погляд, причиною цього є те, що в світі баз даних є занадто багато варіантів, щоб будь-яка людина була фахівцем фахівця і змогла вручну керувати і адмініструвати. . І причиною цього є те, що за останні чотири-п’ять десятиліть, коли мова йде про світ серверів і систем баз даних, серверів баз даних і наборів програм, ми пройшли дуже-дуже довгий шлях. Колись у нас було велике залізо, що має справу з тим, що фактично мало даних, і смішно малим, коли ми озираємося назад. Днями я побачив по-справжньому акуратне фото у Twitter цієї дивовижної леді, яка була головним програмістом і розробником NASA в той час, коли ми ставили чоловіків на Місяць, а її код був надрукований у сто тридцять- два стовпчикові рядки для принтерів і складені вентиляторами, і він стояв фактично вище, ніж вона, кількість коду, яку вона написала.
І коли я подумав про це, мені це було схоже, насправді це, мабуть, близько двох-трьохсот мег даних, куди їй потрібно було все це набрати не більше, якщо не менше. І тому загальний об'єм даних для зберігання її коду, навіть якщо він фізично стояв вище за неї, коли він був надрукований на папері, насправді був дуже-дуже невеликим обсягом. Навіть ці масивні комп’ютери кімнатного розміру, а це 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 року, коли, якщо я повернусь до цього образу цього кластеру, у нас було те, що ми називали кластерами Беовульфа, стало річчю, де ми могли б зніміть на полиці ПК і склейте їх і зробіть основні суперкомп'ютери.
Але приблизно з цього моменту ми перетнули переломну точку, коли люди мали змогу здійснювати адміністрування баз даних старої школи і - як я кажу, на мій погляд, - масштаб став дуже, дуже великим, дуже швидким. Це майже так, як якщо б у нас відбулася така велика подія в галузі технологій, яка спричинила впровадження технології передачі даних та технологій управління даними, зокрема в базах даних навколо них. І тому, що ми фактично будували високопродуктивні кластери в обчислювальному стилі для розміщення даних у різних формах. І щоб підкреслити цю точку, ось короткий знімок пейзажу станом на 2016 р. Доступних нам технологій баз даних. Від нижнього правого кута та відкритого коду, аж до верхнього лівого кута в інфраструктурі. А у верхньому правому куті в доступних нам рішеннях прикладних програм, а в нижньому лівому куті - суміші інфраструктури та продуктивності, які роблять аналітику тощо. А в середині є такі пристрої, як наші смартфони, звичайно, які насправді працюють на дуже малих версіях баз даних, щоб робити такі речі, як управління нашими контактами тощо, або наші журнали викликів та інші речі, які ми маємо.
І тому в моїй думці стався цей вибух, подібний до кембрійського вибуху в такій речі, де кількість технологічного розвитку, що відбулася за той самий короткий проміжок часу, приблизно з 2006 по 2016 рік, який фактично становить десятиліття, як воно було. Зараз ми бачимо, що бази даних графіків стають великою справою, бази даних в пам'яті стають великою справою, бази даних SQL зближуються. Перехід до різних обчислювальних моделей, виник Hadoop, у нас була модель MapReduce, тепер ми маємо іскрову та потокову аналітику та потокові комп'ютери, стійкі розподілені дані, рамки, які люди повинні розробити для них, щоб дістатися до потрібних нам масштабів, і коли ми задумаємося про цю подорож, щоб пройти через щось таке, що стосується реляційних систем управління базами даних зі звичайними підозрюваними, 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, я пішов у схему, якщо я подивився на SQL замість тільки мої таблиці GIM, що належать до цієї схеми, я буду бачити всі таблиці, незалежно від назв схеми. Знову ж таки, різні способи впорядкування речей, які реально налаштовують їх під ваш робочий процес і на те, як ви хочете його бачити.
І останнє, про що я хочу поговорити, - це можливість встановити "Закладки". Якщо я буду працювати, якщо я працюю на одній із моїх платформ і хочу зосередитися лише на режимі моїх таблиць, я можу додати закладку. Я знаю, дуже проста функція, але її так приємно мати, особливо коли ви працюєте з якомога більшою кількістю джерел даних та такою ж кількістю платформ, як сьогоднішня DBA. Щоб мати можливість увійти в систему, запустіть DBArtisan і дозвольте менеджеру закладок перенести вас прямо на місце дерева, де вам потрібно бути і мати можливість працювати. І тоді я зможу створити нову таблицю, і знову на платформах, які ми підтримуємо, які ви бачили раніше, і ми збираємось провести вас через "Майстер", щоб ви могли рухатись та розробляти та створювати таблицю. І ми збираємося створити весь синтаксис, необхідний для цього за кадром, а потім представити його в кінці на панелі попереднього перегляду. Ви можете отримати перевірку, побачити, що саме ми збираємося створити. Ви можете натиснути кнопку "Виконати", потім кнопку "Готово", нехай вона виконана. Або ви можете зберегти його або відсунути його в інше вікно ISQL, тому зробіть це, знову ж таки, можливо, він повинен бути частиною більшого, більшого сценарію, який ви хочете зберегти та розгорнути протягом годин пакетного вікна.
Це огляд DBArtisan. Коли ми говоримо про це, знову ж таки, це продукт, на якому спостерігається багато платформ, підтримка цих платформ та чудовий досвід користувачів, чудові відгуки наших клієнтів. Якщо ви зацікавлені як один із учасників форуму, але якщо вам потрібно знайти що-небудь, пов’язане з ІДЕРА або DBArtisan, не соромтесь звернутися, і ви, звичайно, можете знайти мене за моєю електронною адресою.
Ерік Кавана: Добре, я думаю, я відкрию його Робіну для запитань, а потім Дез, а потім я буду моніторити питання та відповіді від присутніх. Робін, забирай його.
Робін Блор: Добре, я маю на увазі, перше питання, я фактично був знайомий з DBArtisan досить довгий час, тому я якось усвідомлював його можливості. Те, що мені було б цікаво, щоб ви зверталися, це її, такі, майбутні шляхи звідси. Я маю на увазі, я бачу, ви знаєте, востаннє, коли я це дивився, це, мабуть, було давно. Я бачу, що ви підтримуєте щонайменше три бази даних, які я не розумів, що ви підтримували раніше. Який шлях вперед для DBArtisan? Цілком ймовірно, що ви просто збираєтеся додавати все більше і більше баз даних чи це розширення функції? Куди ви збираєтесь піти з нею?
Скотт Уолз: Це чудове питання, і мені хотілося б всього сказаного. Ми, звичайно, будемо продовжувати розробляти, оскільки традиційні платформи RDBMS не сидять на місці, правда? Вони продовжують розбудовувати. Ми будемо продовжувати йти цим шляхом. І тоді ви побачите, як ми починаємо шукати та йти в тому напрямку підтримки нових нових платформ. Оскільки ми визнаємо, що хоча деякі з цих платформ продовжують рости, традиційні RDBMS, є певні ситуації, що нові платформи є правильними платформами для клієнтів. Ми дійсно пильно стежимо за тим ринком, на цьому сегменті і намагаємось приймати правильні рішення, на яких платформах рухатись. Вони, здається, змінюються щодня практично.
Робін Блор: Ну, як я і Дез говорили, це дуже жвавий ринок, можливо, це один із способів поглянути на нього. Ще одне, що мене зацікавило - очевидно, ви не зможете точно відповісти на це питання, але я свого часу натрапив на сайти, де є тисяча примірників Oracle, а Oracle не був Ви знаєте, єдину базу даних, яка використовувалася. І коли я насправді розмовляв з ними про те, як на Землі ти керуєш багатьма випадками, вони сказали: "Ну, ти знаєш, є лише близько п’яти-шести великих примірників, і у нас є близько трьох ОР, які ми поширюємо по цьому". м якось зацікавлений у використанні DBArtisan, тому що ви можете зробити дуже багато з ним, скільки баз даних він сидить, скажімо, як правило, або навіть які найбільші приклади того, скільки рядків він може керувати одночасно?
Скотт Уолз: Ну, я бачив ситуації - і знову ж таки, трохи складніше, це питання, тому що DBArtisan дозволяє мені мати декілька з'єднань або декілька джерел даних, визначених для одного екземпляра. Можливо, я хочу зробити syslogin, а потім менший логін дозволів, але я мав справу з клієнтами, що при всьому руйнуванні він переходить на кілька екранів. Тепер, коли я запитав їх, питання, яке ви мені задали, таке: "Як ти керуєш такою кількістю?" І тоді він каже: "Я не знаю". Так? "Я керую тим, що можу, але мені потрібен доступ до всього". Я ще не бачу нічого, що зупиняється, знаєте, верхня межа того, чим можуть керувати люди, - це справді верхня межа того, що може ця людина, людина ручка. Але ви знаєте, як я вже згадував, ті люди, з якими я кидаю виклик, вони відкрито визнають, що вони мають усі ці зв'язки, але немає ніякого способу, щоб ними управляти. Вони покладаються на свою команду. Як я впевнений, ви пережили, так.
Робін Блор: Ну, власне, я був DBA, хоча цього не робив дуже довго. І одне, що, ви знаєте, я пам’ятаю, що перебуває за межами всього іншого у реляційних базах даних, - це те, що ви можете робити величезну кількість речей за допомогою SQL. Часто більше, ніж ти думаєш, що міг. Що так чи інакше пояснює певну функціональність, яку отримав DBArtisan, оскільки він просто перекладається безпосередньо на SQL. Але, знаєте, я впевнений, що ви займаєтесь іншими справами. Це все сценарії SQL чи є інші спеціальні процедури, написані для езотеричних ситуацій?
Скотт Уолз: Так, багато чого, основна частина цього становить SQL, саме така природа. Але ми пишемо підпрограми, які можна запустити з командного рядка, використовуючи інструменти постачальника, торці спереду постачальника. Ми поставимо передні кінці, наприклад, для утиліт завантаження даних на платформах, правда? Це не сценарії SQL, правда, це завдання командного рядка. Це призведе до створення цих даних і зможе надати їх до DBA, які вони можуть потім виконати. Дивіться так, ми трохи зробимо обидва, але більшість це сценарії SQL.
Робін Блор: Дивлячись на це, тому що, очевидно, ви повинні так чи інакше подивитися на події, які відбуваються, я вважаю досить новими. Я маю на увазі, одна з речей, що мені здається цікавою, що відбувається, це те, що Spark, очевидно, злітає, як ракета, але SQL Spark, це пішло від жахливо незрілого, щоб почати виглядати трохи більш зрілим з трохи більшими можливостями SQL. Ви дивитесь на такі речі та цікавитесь, чи не збираєтесь ви починати керувати ними з DBArtisan?
Скотт Вальц: Звичайно, і я. Це завжди є. Я знаю, що наша команда з управління продуктами завжди дивиться, куди йти, і абсолютно все для нас столу, що стосується того, на що ми дивимось у майбутньому.
Робін Блор: Гаразд, Дез, ти хочеш заграти?
Дез Бланчфілд: Так, насправді, є маса чудових речей, які ти відкрив мені там двері, Робін. Велике спасибі. Мені дуже хочеться вивчити деякі речі, які вискакують на мене, коли я дивлюся на такі продукти, і я дуже схвильований. Коли я ще раз перевірив домашнє завдання, тому що, як згадував доктор Робін Блер, раніше, він, як і я, спостерігав це за деякий час, і я пам’ятаю, переглядаючи ваші вимоги до специфіки днями і думав, що насправді ця справа працює саме схиляється до того, що насправді робить. І я думаю, що з пам’яті - виправте мене, якщо я не помиляюся - я думаю, що це було так само мало, як продуктивність ноутбука комфортно запустила б DBArtisan, і все ж він міг запускати деякі досить значні кінці бази даних. І мені було дуже цікаво бачити, як у вас зараз є Firebird та Greenplum. Мене дуже вразило вимога або специфікація обладнання, яке може буквально працювати на зразок оперативної пам'яті на одному гігагерцовому процесорі. Це було досить вражаюче.
Але випадки використання - це те, про що я хочу поглибити трохи. Ви бачите, як поглинання продукту є потребою через існуючі середовища, які щойно вийшли з-під контролю, чи ви бачите, що люди зараз дещо активніші і говорять: знаєте, ми щось дуже будуємо великий, він складний. І я думаю про злиття та поглинання, наприклад, тут, де організація може придбати купу фірм - малих, середніх, великих, будь-яких інших - і в кінцевому підсумку успадковує всі ці середовища та потребує побудови нової можливості БД. Які типові випадки використання для цього стосуються типу організації та типу додатків до неї? Це переважно люди, у яких є існуюче середовище, і їм доведеться просто прибирати їх та отримувати контроль над ними, або люди трохи активніші і думають про складність, яку вони збираються будувати, і приїжджають вас на борт рано?
Скотт Уолз: Ми бачимо більше, щоб почати рано з тієї самої причини, яку ви згадали, консолідацію. Маючи широту підтримки платформи, яку ми маємо, це не загальна перевірка майбутніх, правда, але це ставить вас та ваших DBA в дуже гарну ситуацію, що коли вони дивляться на потенційну ціль придбання, правда, вони трохи менше Ви знаєте, думка про те, які платформи ми могли б успадкувати, правда? Хоча це важливо, правда, стурбованість тут трохи менша, ніж те, що це буде означати для наших DBA, так? DBA мають продукт тепер, коли вони знають, що вони можуть підключитися, і якщо вони знайомі з використанням продукту, вони будуть ознайомлені з підключенням до тієї платформи, яку вони тільки що придбали. Так що це, безумовно, область, яку ми бачимо, знову ж таки, знаєте, клієнти з таким розмахом усіх цих платформ, правда? Як я збираюся обійняти це, правда? І вони спробували це, оскільки продуманий процес кожної з платформ має інструмент, правда? Ми можемо використовувати власний інструмент, правда? Але врешті-решт повертається, що, ви знаєте, що, так, ви можете, але не тільки мені доведеться вивчати кожну платформу, тепер я вивчаю кожен із інструментів, які йдуть разом із кожною платформою і тож ви просто склали роботу DBA. Тож ми також бачимо ту ситуацію, коли вони повертаються до нас і говорять: «Ви знаєте, нам потрібно обійтись цим. Давайте отримаємо один інструмент для DBA, тому що для DBA у мене важливіші речі, ніж вивчення інтерфейсу нового інструменту. Або різні інструменти ».
Дез Бланчфілд: Так, точно. І, знаєте, коли ви бачите, я думаю, що з пам’яті, коли я вчора подивився, щоб ще раз перевірити, чи не помилився, я пам’ятаю, що ти підтримував Sybase, наприклад, так що ця річ була небагато часу. Є ще одне питання, яке я поставив до вас насправді просто так - так, це здорово, що у вашому списку є Greenplum та Firebird, але ваш Sybase такий вік дуже швидко, що свідчить про те, що він був деякий час і зробив хорошу роботу.
Скупчення. Отже, одна з найбільших головних болів для DBA полягає в тому, що вони в основному вказують на те, що схоже на IP-адресу та купу API-інтерфейсів, чи це JDBC чи LDBC, або все, що ми можемо говорити, але за цим стоїть кластер. Що може, або DBArtisan знає про те, що знаходиться за дверима номер один, як це було, як коли я підключаюсь до заднього кінця бази даних, чи можу я побачити всі середовища позаду, і зокрема, тож є дві частини до питання, можливо. Наприклад, кластер, коли ви думаєте, ви знаєте, ви підтримуєте IBM DB2 і Microsoft SQL Server Database Server, MySQL і PostgreSQL і Oracle, а також деякі традиційні RDBMS, і, знаєте, ми завжди запускаємо ведучий-підлеглий або мастер-майстер середовище для надмірності та високої доступності, а також продуктивність. Чи знає DBArtisan, що за дверима номер один є щось, що є не однією базою даних, а кластером, і якщо так, то що вона знає про це? І швидко вступати в це, щоб ви могли відповісти на те саме питання, вибачте. Отже, за кластерами у деяких зі складених вами сценаріїв, як люди справляються із поєднанням між виробничим середовищем та середовищем відновлення після аварій, наскільки це стосується використання DBArtisan?
Скотт Вальц: Чудові питання. Я скажу вам, що це буде залежати від конкретних платформ, тому що, наскільки ми намагаємось, ми матимемо різні рівні підтримки деяких глибших, глибших функцій. Наприклад, для Oracle та їх середовища RAC, Real Application Cluster, ви можете підключитися до основного вузла цього кластеру, але все ж переглядаючи монітор бази даних, який я показав, ми дозволимо вам побачити, як працює SQL, і ми ' насправді я вам скажу, на якому вузлі кластера він працює, правда? Щоб ви точно бачили, чи, знаєте, повільно запущений запит, давайте слідкуємо за цим, на якому вузлі він працює? Оскільки неминуче вся причина кластеру, правда, полягає в кінцевому користувачі, йому все одно, де він виконаний, але для DBA нам потрібно відслідковувати цей тип інформації. Наприклад, ми можемо знизитися до рівня деталізації в Oracle. Інші платформи, які ми маємо, мають підключення, ймовірно, не так багато деталей, ніж ми робимо для Oracle.
Що стосується виробництва та середовища розвитку, то це хороше питання. Ми надаємо той же рівень підтримки. Реальний основний спосіб, яким ми будемо допомагати, шар підключення буде там, правда? Ми зможемо підключитися та виконати всі функції. У мене є клієнти, які використовують деякі функції в DBArtisan для категоризації їх джерел даних, правда? Знову ж таки, це може бути трохи відхилене від точного питання, яке ви задаєте, але ми дозволимо їм графічно позначити, як вони працюють. Оскільки це одна з речей щодо DBArtisan, чи можу я швидко змінюватись між джерелами даних. І наступне, що ви знаєте, я готуюся виконати заяву про скорочення, і я дивлюсь, чи я пов’язаний - чи я просто запускав це проти виробництва чи розвитку? Таким чином, ми надаємо деякі функції в DBArtisan, щоб допомогти DBA там, а також керувати цим і утримувати їх від проблем, якщо ви хочете, з деякими діями DBA.
Дез Бланчфілд: Зважаючи на це, у довгому списку платформ, які ви зараз підтримуєте, і я впевнений, що вибухне дуже скоро з очевидних причин. Я маю на увазі, ви підтримуєте подібне, наприклад, DB2 на z / OS, наприклад, на мейнфреймі, а потім, очевидно, ви підтримуєте вподобання у тому, що ми звикли називати середнього діапазону, але тепер просто UNIX-систем та подібних сучасних платформ, ви знайте, Linux, а згодом він перейде вподобання Bluemix і Cloud Cloudry, тож ви закінчите, що DB2 працює в Cloud Foundry на Bluemix, з IBM та хмарою на софт. Чи в даний час люди працюють не лише управлінням та моніторингом, але й ви згадали раніше можливість міграції та переміщення даних. Ви бачите, як люди стрибають у ліжку з DBArtisan і кажуть: "Ви знаєте що, у нас є маса речей на старих мейнфреймах, які нам просто потрібно зняти, і це було справжнім клопотом. Якщо я можу вказувати, клацнути та перетягувати звідти туди, я можу насправді переміщувати та переміщувати свої дані та свою схему. "Це те, чим займаються люди?
Скотт Вальц: Вони справді рухаються, правда? Вони переносять дані, правда? Тепер вони використовують DBArtisan як інструмент для цього. Це все робить для них? Ні. Ми починаємо, перетягування не саме там, але ми дозволяємо їм генерувати деякі сценарії, тому що в ідеалі ви хочете використовувати їх - ви не хочете, щоб ця робота була працює на вашому клієнті, на вашому ноутбуці з тієї самої причини, яку ви згадали. Ми можемо бігати по дуже низькому сліду, правда? Ми допомагаємо їм генерувати сценарії, а потім перевертаємо їх і будуємо, а потім вони можуть доставити цей сценарій і запустити його на сервері, правда? І отримати силу, кінські сили за сервером, щоб це зробити. Ми допомагаємо їм створити певну роботу, щоб виконати якусь роботу.
Дез Бланшфілд: Правильно. Кілька останніх для вас, і тоді ми можемо обернутися назад. Те, що насправді вразило мене, просто переживаю ваше доповнення, яке є фантастичним, і насправді, я б хотів, щоб ми мали ще одну годину, щоб розглянути детальніше. Дійсно великим викликом для DBA, правда, є базове дотримання, загальне управління інфраструктурою, аудиторські перевірки, звітування про поточний стан, перегляд майбутніх підготувань до таких речей, як, знаєте, просто загальне зростання навколишнього середовища. Мене вражає те, що, хоча, що в основі того, що, здається, працює ваш продукт, - це просто зробити життя легким, та одна скляна склянка, єдиний погляд на світ, і я по суті можу натискати, вказувати та перетягувати, і я люблю факт що я можу навчити когось це робити дуже швидко зараз, вони не повинні читати посібник, як це було. Мене вражає, що інструмент також дає мені можливість робити цілу купу речей навколо управління, дотримання та аудиту, що мені цікаво, чи насправді люди прокинули, я впевнений, що вони є.
Але ви бачите, як люди зараз дивляться на це та йдуть, і це подібно до цієї еврики, а-ха-мить, йде: "Гей, ти знаєш що, це робить життя DBA справді легким відтепер, або простіше з оперативної точки зору. або точки зору розвитку. Але, на жаль, ми могли фактично просто звітувати про всі наші бази даних зараз і про всі набори даних, про всі бездослідні дані та всі метадані навколо. Мовляв, хто отримав доступ, коли отримав доступ, чому вони отримали доступ і який тип доступу вони отримали. "І раптом, вирішіть деякі проблеми, пов'язані з дотриманням вимог. Особливо, коли у нас трапляються дійсно великі речі, пов’язані з порушеннями даних. У нас є деякі дивовижні речі, такі як глобальні фінансові кризи, всі ці проблеми виникають, але як же ми будемо вимірювати, контролювати та вирішувати відповідність? Це є якась велика річ для людей, чи це все ж таки, як-то, перші дні, що стосується застосування DBArtisan до цього?
Скотт Уолз: У мене є клієнти, які не можуть сказати достатньо про DBArtisan. Зараз це ті, хто це зрозумів. Лампочка згасла. Вони кажуть: «Почекай хвилинку. Я можу відповідати та відповідати та генерувати деякі згадані вами звіти, правда, все з одного інструменту. Зараз я це отримав. "Зараз є ще інші, які ще не впораються з цим, і це може бути з різних причин, правда? Вони можуть ще не бути або, можливо, цим займається хтось інший, але наші клієнти, які ми знайшли, що використовують його, це момент а-ха, правда? Це не тільки я в змозі створити таблицю з усіх цих матеріалів. І абсолютно, з усіма вимогами відповідності, це величезна кількість. Це робота сама по собі.
Дез Бланчфілд: Ну, справді. І ви знаєте, я маю на увазі, вгорі голови я негайно замислююся, ви знаєте, якщо хтось підійде і каже, що вони хотіли створити базу даних управління конфігурацією, CMD, якщо їм доведеться відповідати всьому від Сарбанаса -Oxley, щоб COBIT в 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. І це робить саме те, що ви описали. Ви можете почати, як тільки ми отримаємо кілька колекцій, правда, і як тільки ми отримаємо розмір вибірки, а може бути і розмір рядка, можливо, кількість об'єктів, кількість варіантів в інструменті, і тоді ви можете почати тренди, чи не так? А як це буде виглядати через півроку? Як це виглядатиме через дванадцять місяців? Я можу тенденцію до, просто тенденція до побачення або я можу тенденцію до значення, правда? І прикладом, який ви мали, у мене є кількість дискового простору, виходячи з цього, коли я збираюся досягти цієї межі? Виходячи із зростання, який я маю, і цих колекцій, які я робив, коли я буду досягти цієї межі? Принаймні я знаю, що можу почати планувати це. Це буде півроку, чи буде два роки? Але знову ж таки, ми можемо використовувати аналітику потенціалу, щоб просуватися до цього.
Дез Бланчфілд: Це приголомшливо. Фантастична демонстрація. Мені дуже сподобалося. Я повернусь до Еріка, бо знаю, що сьогодні є кілька питань, які з'явилися у нашої дивовижної аудиторії. Дякую вам велике, дуже добре познайомитися з продуктом, і я з нетерпінням чекаю на нього дуже уважно.
Ерік Кавана: Добре, добре. У нас є кілька хороших питань. І ми трохи підемо з часом, тому ми спробуємо швидко завершити, тому що я знаю, Скотт, у тебе закрита упорна зупинка. Ось велике питання. Як щодо роботи зі старими сховищами даних, такими як VSAM, Model 205, IMS та IDMF та подібними речами? Ви бачите це дуже часто в ці дні і як добре це працює?
Скотт Уолз: Я не хочу сказати вам, що ви застрягли. Деякі з цих середовищ, якщо вони мають ODBC або JDBC, і я знаю, що деякі з них є там, ми можемо підключитися до нього, і ви можете працювати з ним таким чином. Але здебільшого зелений екран - це шлях, який потрібно продовжувати.
Дез Бланчфілд: Я люблю зелений екран.
Ерік Кавана: Ну, ви знаєте, як Дез вказував на тому слайді, де у нього були всі ті різні програми та інструменти, які є сьогодні, це дуже грізна реальність для тих, хто хоче відповідально виконувати функцію адміністратора бази даних. І я здогадуюсь, що з часом ви, хлопці, можете створити з'єднувачі до будь-якого з цих інструментів, як і коли клієнти вимагають, і так далі, правда? Щоб ви ввімкнули ту саму склопакет.
Скотт Уолз: І це було великим ключем, завдяки якому DBArtisan був оснащений, щоб мати можливість обробляти ці з'єднання JDBC та ODBC. Ми дійсно це продовжили зараз. Тепер, поки у нас є цей зв'язок, правильно, доки у нас є цей драйвер, ми можемо підключитися і працювати проти нього.
Ерік Кавана: Це хороші речі. Ну, люди, ми архівуємо все це для подальшого перегляду. Я опублікував посилання на слайди, сподіваємось, ви побачите це через SlideShare. Велике спасибі за всі ваші зусилля, панове. Чудова веб-трансляція сьогодні знову. Багато хороших слайдів. Багато хорошого змісту. Я любив цю демонстрацію. Дійсно цікаво, що ви, хлопці, націлили на дуже приємне місце на ринку, тому що зараз такий вибух типів баз даних. І нам просто потрібно, як менеджерам, десь впоратися з усім цим. Молодці, хлопці. Ми завтра наздоженемо вас за ще однією гарячою технологією. Сподіваємось, ви завтра вирізали годину. Водночас. Та сама станція. Ми наздоженемо вас наступного разу, люди. Піклуватися. Бувай.
