Винос: Ведучий Ерік Кавана обговорює тенденції в базі даних з докторами Робіном Блором, Дезом Бланчфілдом та Скоттом Вальсом у цьому епізоді «Гарячих технологій».
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Шановні панове, привіт, вітаємо Вас на найгарячішому шоу у світі підприємств IT, Hot Technologies 2016. Так, справді! Мене звуть Ерік Кавана, я сьогодні буду вашим ведучим шоу на тему "Мистецтво видимості: увімкнення управління кількома платформами", так. Кілька швидких записок - слайд про ваш справді, правда, з п’яти років тому і достатньо про мене, вдарив мене на @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 цілком може створити в тій чи іншій мірі різну динаміку у світі баз даних, що ще більше ускладнить справи. Сподіваємось, у тому чи іншому випадку відбудеться якась конвергенція, але я не бачу, щоб все це поєднувалося так, як це було з реляційними базами даних. Не так скоро, все одно.
І я думаю, що це все, що я маю сказати, тому передам це Австралії.
Dez Blanchfield: Дякую, Робін. Дякую всім, що приєдналися до нас, дякую за те, що я зібрався сьогодні вранці або вдень. Це дуже гаряча тема, тому що ми пережили досить вибух за останнє десятиліття і трохи, за кількістю даних, з якими нам доводиться мати справу, і незмінно, що дані знаходяться в якійсь формі системи, що для більшості випадків це база даних певної форми. Я подумав, що швидко проведу нас через дуже високий рівень прогулянки через те, як ми потрапили сюди, і проблему, яка створюється, і типи речей, які нам зараз потрібно вирішити, і тоді ми поговоримо про типи рішення, яке можна застосувати до цього. Дозвольте мені просто захопити свій перший слайд тут. Я вважаю, що зараз ми знаходимось у тому, де адміністратор БД 2.0 або адміністратор бази даних 2.0 - це те, де ми зараз подібні, колись адміністратор бази даних був досить очевидною роллю та проблемою. і ви могли досить швидко тренувати когось. У сьогоднішньому світі це вже не так, і я вам покажу, чому це так.
Колись адміністратору баз даних можна було б підключитися до заднього кінця БД і зробити швидке показ баз даних, і в системі з'явиться список баз даних, про які вони повинні бути обізнані, і вони можуть дуже швидко перейти ці бази даних та виберіть їх, а також маєте трохи ткка та зонда навколо та скористайтесь перекладом, опишіть таблицю, щоб дізнатися, що є в таблиці та кожному зі стовпців та рядків, і це було досить простою проблемою, і якщо ви читаєте середню дві-триста сторінок книги про адміністрування баз даних для кожної платформи, ви змогли майже навчити себе, не маючи ступеня ракетної науки.
Але це вже не так, і, на мій погляд, причиною цього є те, що в світі баз даних є занадто багато варіантів, щоб будь-яка людина була фахівцем фахівця і змогла вручну керувати і адмініструвати. . І причиною цього є те, що за останні чотири-п’ять десятиліть, коли мова йде про світ серверів і систем баз даних, серверів баз даних і наборів програм, ми пройшли дуже-дуже довгий шлях. Колись у нас було велике залізо, що має справу з тим, що фактично мало даних, і смішно малим, коли ми озираємося назад. Днями я побачив по-справжньому акуратне фото цієї дивовижної леді, яка була головним програмістом і розробником 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, тепер у нас є 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, я пішов у схему, якщо я дивився на 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?
Скотт Вальц: Звичайно, і я. Це завжди є Я знаю, що наша команда з управління продуктами завжди дивиться, куди подітись, і абсолютно все, що є на столі, для того, на що ми дивимось у майбутньому.
Робін Блор: Гаразд, Дез, ти хочеш заграти?
Dez Blanchfield: Так, насправді, є купа чудових речей, які ти мені відкрив двері, Робін. Дуже дякую. Мені хочеться просто вивчити деякі речі, які вискакують на мене, коли я дивлюся на такі продукти, і я дуже схвильований. Коли я ще раз перевірив домашнє завдання, тому що, як згадував доктор Робін Блер, раніше, він, як і я, спостерігав це за деякий час, і я пам’ятаю, переглядаючи ваші вимоги до специфіки днями і думав, що насправді ця справа працює саме схиляється до того, що насправді робить. І я думаю, що з пам’яті - виправте мене, якщо я помиляюся - я думаю, що це було так само мало, як продуктивність ноутбука комфортно запустила б DBArtisan, але все-таки вона змогла запустити деякі досить значні кінці бази даних. І мені було дуже цікаво бачити, як у вас зараз є Firebird та Greenplum. Мене дуже вразило вимога або специфікація обладнання, яке може буквально працювати на зразок оперативної пам'яті на одному гігагерцовому процесорі. Це було досить вражаюче.
Але випадки використання - це те, про що я хочу поглибити трохи. Ви бачите, як поглинання продукту є потребою через існуючі середовища, які щойно вийшли з-під контролю, чи ви бачите, що люди зараз дещо активніші і говорять: знаєте, ми щось дуже будуємо великий, він складний. І я думаю про злиття та поглинання, наприклад, тут, де організація може придбати купу фірм - малих, середніх, великих, будь-яких - і в кінцевому підсумку успадкувати всі ці середовища та створити новий потенціал БД. Які типові випадки використання для цього стосуються типу організації та типу додатків до неї? Це переважно люди, які мають існуюче середовище і повинні просто прибирати їх та отримувати контроль над ними, або люди трохи активніші і думають про складність, яку вони збираються створити, і приймати вас на борт рано?
Скотт Вальц: Ми бачимо більше раннього початку з тієї причини, яку ви згадали, консолідації. Маючи широту підтримки платформи, яку ми маємо, це не загальна перевірка майбутніх, правда, але це ставить вас та ваших DBA в дуже гарну ситуацію, що коли вони дивляться на потенційну ціль придбання, правда, вони трохи менше Ви знаєте, думка про те, які платформи ми могли б успадкувати, правда? Хоча це важливо, правда, занепокоєння там трохи менше, ніж це буде означати для наших DBA, так? У DBA є продукт, коли вони знають, що вони можуть підключитися, і якщо вони знайомі з використанням продукту, вони будуть знайомі з підключенням до тієї платформи, яку вони щойно придбали. Тож це, безумовно, область, яку ми бачимо, знову ж таки, знаєте, клієнти з таким розмахом усіх цих платформ, правда? Як я збираюся обійняти це, правда? І вони спробували це, оскільки продуманий процес у кожної з платформ має інструмент, правда? Ми можемо використовувати власний інструмент, правда? Але врешті-решт повертається, що, ви знаєте, що, так, ви можете, але не тільки мені доведеться вивчати кожну платформу, тепер я вивчаю кожен із інструментів, які йдуть разом із кожною платформою і тож ви просто склали роботу DBA. Тож ми також бачимо ту ситуацію, коли вони повертаються до нас і говорять: "Ви знаєте, нам потрібно обійтися цим. Давайте один інструмент для DBA, тому що для DBA у мене важливіші речі, ніж вивчення нового інтерфейсу нового інструмента. Або різні інструменти ».
Dez Blanchfield: Так, точно. І, знаєте, коли ви бачите, я думаю, що з пам’яті, коли я вчора дивився, щоб ще раз перевірити, чи не помилявся, я пам’ятаю, що ти підтримував 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.
Dez Blanchfield: Зважаючи на це, у довгому списку платформ, які ви зараз підтримуєте, і я впевнений, що вибухне дуже скоро з зрозумілих причин. Я маю на увазі, ти підтримуєш подібне, наприклад, DB2 на z / OS, наприклад, на мейнфреймі, а потім, очевидно, ти підтримуєш подобається те, що ми звикли називати середнього діапазону, але тепер лише системи UNIX, а також більш сучасні платформи, ти знайте, Linux, а згодом він перейде вподобання Bluemix та Cloud Foundry, тож ви закінчите, що DB2 працює в Cloud Foundry на Bluemix, з IBM та хмарою на софт. Чи в даний час люди працюють не лише управлінням та моніторингом, але й ви згадали раніше можливість міграції та переміщення даних. Ви бачите, як люди стрибають у ліжку з DBArtisan і кажуть: "Ви знаєте що, у нас є маса речей на старих мейнфреймах, які нам просто потрібно зняти, і це було справжнім клопотом. Якщо я можу вказувати, клацнути та перетягувати звідти туди, я можу насправді переміщувати та переміщувати свої дані та свою схему. "Це те, чим займаються люди?
Скотт Вальц: Вони справді рухаються, правда? Вони переміщують дані, правда? Тепер вони використовують DBArtisan як інструмент для цього. Це все робить для них? Ні. Ми починаємо, перетягування, не саме там, але ми дозволяємо їм генерувати деякі сценарії, тому що в ідеалі ви хочете використовувати це - ви не хочете, щоб ця робота була працює на вашому клієнті, на вашому ноутбуці з тієї самої причини, яку ви згадали. Ми можемо бігати на дуже низькій нозі, правда? Ми допомагаємо їм генерувати сценарії, а потім перевертаємо їх і створюємо, а потім вони можуть доставити цей сценарій і запустити його на сервері, правда? І отримати силу, кінські сили за сервером, щоб це зробити. Ми допомагаємо їм створити певну роботу, щоб виконати якусь роботу.
Dez Blanchfield: Правильно. Кілька останніх для вас, і тоді ми можемо обернутися назад. Те, що мене насправді вразило, просто пережило ваше доповнення, яке є фантастичним, і насправді, я хотів би, щоб ми мали ще одну годину, щоб розібратися детальніше. Дійсно великим викликом для DBA, правда, є основна відповідність, загальне управління інфраструктурою, аудиторські перевірки, звітування про поточний стан, перегляд майбутнього підготування до таких речей, як, знаєте, просто загальне зростання навколишнього середовища.Мене вражає те, що, хоча, що в основі того, що, здається, працює ваш продукт, - це просто зробити життя легким, та одна скляна склянка, єдиний погляд на світ, і я по суті можу натискати, вказувати та перетягувати, і я люблю факт що я можу навчити когось це робити дуже швидко зараз, вони не повинні читати посібник, як це було. Мене вражає, що інструмент також дає мені можливість робити цілу купу речей навколо управління, дотримання та аудиту, що мені цікаво, чи насправді люди прокинули, я впевнений, що вони є.
Але ви бачите, як люди зараз дивляться на це та йдуть, і це подібно до цієї еврики, а-ха-мить, йде: "Гей, ти знаєш що, це робить життя DBA справді легким відтепер чи простіше з оперативної точки зору. або точки зору розвитку. Але, на жаль, ми могли фактично просто звітувати про всі наші бази даних зараз і про всі набори даних, про всі бездослідні дані та всі метадані навколо. Мовляв, хто отримав доступ, коли отримав доступ, чому вони отримали доступ і який тип доступу вони отримали. "І раптом вирішіть деякі проблеми, пов'язані з дотриманням. Особливо, коли у нас трапляються дійсно великі речі, пов’язані з порушеннями даних. У нас є деякі дивовижні речі, такі як глобальні фінансові кризи, усі ці проблеми випливають, але як же ми будемо вимірювати, контролювати та вирішувати відповідність? Це є якась велика річ для людей, чи це все ж таки, як-то, перші дні, що стосується застосування DBArtisan до цього?
Скотт Вальц: У мене є клієнти, які не можуть сказати достатньо про DBArtisan. Зараз це ті, хто це зрозумів. Лампочка згасла. Вони кажуть: «Почекай хвилинку. Я можу відповідати та відповідати та генерувати деякі згадані вами звіти, правда, все з одного інструменту. Зараз у мене це є. "Зараз є ще інші, які ще мають наздогнати це, і це може бути з різних причин, правда? Можливо, їх ще немає, а може, цим займається хтось інший, але наші клієнти, які ми виявили, що використовують його, це момент а-ха, чи не так? Це не тільки я в змозі створити таблицю з усіх цих матеріалів. І абсолютно, з усіма вимогами відповідності, це величезна кількість. Це робота сама по собі.
Dez Blanchfield: Ну, справді. І ви знаєте, я маю на увазі, вгорі голови я негайно замислююся, ви знаєте, якщо хтось підійде і каже, що вони хотіли створити базу даних управління конфігурацією, CMD, якщо їм доведеться відповідати всьому від Сарбанаса -Oxley, щоб COBIT в ITIL, ви знаєте, відповідність SWIFT та банківські послуги, навіть знизившись до подобань Міжнародної організації стандартів ISO 27001, 27002. Це всі ці дійсно великі рамки. Одне з викликів - це просто знайти, де дані, хто керує ними, у якому форматі він є, і я думаю, він має для мене, як для мене, просто дивлюсь його зараз, коли момент Eureka просто відійшов, це було як, повісити по-друге, я міг би вписати це навіть на когось, хто не обов'язково DBA, але я міг би навчити його швидко і сказати: "Є інструмент відповідності". Я думаю, це здорово, що він робить свою роботу в базі даних адміністрації світ управління.
Але я сиджу тут, думаючи, боже, ти знаєш, про те, що ти можеш керувати кількома платформами як одні ці дні, і ти можеш зануритися вниз, як ви вже говорили, записуючи транзакції, які ви робите. Ви знаєте, уявіть, як скористатися цим інструментом у випадку інциденту з порушенням даних, і ви змусили вашу команду безпеки розібратися, що знайти, де і чому, і хто що бачив. І коли вони рухаються, вони повинні реєструвати та відслідковувати всі дії, які вони роблять, тому що вони можуть стати частиною проблеми, якщо не можуть інакше. Так, я думаю, що це неймовірні можливості, які, ви знаєте, ви могли б відразу почати робити, знаєте. Особливо, коли ми дивимося на проблеми перевірок даних, які ви знаєте, у нас є такий масштабний, як, наприклад, повзучість функцій з наборами даних та даними.
І одна з речей, про яку ми говорили в декількох кількох показах, які ми зробили, - це, знаєте, як ви шукаєте свої дані, і часто ми говоримо про те, що коли ви починаєте в будь-якій організації, ви схильні встаньте в свою кабінку і покладіть руку в повітря, махайте і йдіть: "Хто-небудь знає, де ця база даних? Як мені дістатися до цього джерела даних? Де цей файл? "" Іди і запитай прийом. "Так? Ваш інструмент може негайно забезпечити можливість пошуку речей та їх відкриття та навіть звітування про них.
Поверніться до одного із запитань лише коротко, і тоді я завершу і повернусь до Еріка. Мене вражає, що масштаб стане викликом у наступному, начебто, 12 місяці для вас. Чи можете ви дати нам трохи зрозуміти, на тридцять тисяч футових точок зору, я думаю, в масштабі чи діапазоні масштабів, з якими працює DBArtisan. Я можу собі уявити, що коли я кладу це на свій ноутбук, і я гойдаюсь, і я вказую це на оточення, я можу це виявити, і я можу почати робити на ньому справи. Я уявляю, що це відбувається, як єдиний маленький, знаєте, відкритий джерело мінусового двигуна бази даних з кількома рядками та таблицями. Який масштаб він би підняв? Ви говорили про DB2 на мейнфреймах, який великий. І кластери. Який діапазон масштабів, з якими ми можемо впоратись тут? І Робін начебто зачіпав це раніше, але мені просто потрібно розібратися в цьому трохи детальніше, наскільки ми можемо досягти DBArtisan.
Скотт Вальц: Звичайно. Звичайно, перед вами будуть проблеми, адже це програмне забезпечення клієнта. І так, знову ж таки, якщо я працюю над мейнфреймом, коли я працюю проти нашої тестової системи на мейнфреймі, який у нас є, я можу вказати це на мільйони рядків і зробити перехресне з'єднання проти мільйонів рядків. Вся робота буде виконуватися на сервері, правда, тому що ми передаємо цю команду, і це лише питання DBArtisan, що обробляє набори результатів, правда? І тому це виклик, і це краса, що ми робимо. Більшість важких підйомів робиться на сервері. Ми просто обробляємо всі результати. І ось, знову ж таки, ви потрапляєте в ситуації, звичайно, коли ви хочете одночасно запускати десять запитів, які все повертають мільйони рядків, так абсолютно, ви можете опинитися там у якійсь виставі, правда? Але я не забуваю, щоб клієнти ухилялися від великих запитів щодо DBArtisan, проти їхньої бази даних. Знову, як я вже сказав, пробіг змінюється залежно від безлічі факторів, правда, але, знову ж таки, як я вже сказав, я маю справу з мільйонами рядків, що повертаються назад, і поки він заповнює сітку, знаєте, я ' м готова йти. Але іноді явно мені доводиться чекати, коли результати повернуться.
Dez Blanchfield: У мене є питання до вас, перш ніж завершити роботу, тому що я зайняв занадто багато вашого часу і дякую за це. Просто розкажіть нам трохи більше, знаєте, вчора читайте останні характеристики, щоб переконатися, що я перейшов так добре, як я вважав, що я. Моніторинг процесів і своєрідне оповіщення та сповіщення, ви знаєте, планування потенціалу спричиняє всі найважливіші проблеми з DBA, цілий день щодня, ви знаєте. Хтось збирається заповнити цю таблицю, він буде заповнювати базу даних, чи збирається він заповнити дисковий простір, який у мене є, як я ним керую? Дайте нам швидкий пробіг щодо моніторингу процесів, зокрема сповіщень про моніторинг, а потім в ідеалі щодо планування потужностей. Я думаю, що це напрямок, який, на мою думку, може зацікавити.
Скотт Вальц: Моніторинг процесів показав, ймовірно, що функція, яку використовує більшість нашої клієнтської бази, і це монітор бази даних, щоб можна було це показувати та робити. А в нас є кілька пакетів аналітиків. Performance Analyst має деякі сповіщення, які можна встановити, коли певні пороги будуть досягнуті. Це може вас попередити. Можливо, X кількість журналів, помилки у файлі журналу, ви знаєте, це надійде для вас сповіщення. Простір таблиці набрав певний відсоток, ви можете отримати ще одне попередження. І краса в тому, що ти в тому ж інструменті, правда, це частина DBArtisan, тому ти просто клацнеш правою кнопкою миші на помилку, оповіщення, і ти керуєш за допомогою DBArtisan, і це доставить тебе прямо до редактора простору таблиці . І ви можете вирішити проблему прямо там.
Що стосується ємності, то це абсолютно гаряча кнопка та аналітичний потенціал, який у нас зараз переноситься на SQL Server, Oracle, DB2 LUW та Sybase ASE. І це робить саме те, що ви описали. Ви можете почати, як тільки ми отримаємо кілька колекцій, правда, і як тільки ми отримаємо розмір вибірки, а може бути і розмір рядка, можливо, кількість об'єктів, кількість варіантів в інструменті, і тоді ви можете почати тренди, чи не так? А як це буде виглядати через півроку? Як це виглядатиме через дванадцять місяців? Я можу тенденцію до, просто тенденція до побачення або я можу тенденцію до значення, правда? І прикладом, який ви мали, у мене є кількість дискового простору, виходячи з цього, коли я збираюся досягти цієї межі? На основі зростання, який я маю, і цих колекцій, які я робив, коли я буду досягти цієї межі? Принаймні я знаю, що можу почати планувати це. Це буде півроку, чи буде два роки? Але знову ж таки, ми можемо використовувати аналітику потенціалу, щоб просуватися до цього.
Dez Blanchfield: Це круто. Фантастична демонстрація. Мені дуже сподобалося. Я повернусь до Еріка, тому що знаю, що сьогодні у нашої дивовижної аудиторії з’явилося кілька питань. Дякую вам, ми дуже добре познайомилися з продуктом, і я з нетерпінням чекаю на нього дуже уважно.
Ерік Кавана: Так добре. У нас є кілька хороших питань. І ми трохи підемо з часом, тому ми спробуємо швидко завершити, тому що я знаю, Скотт, у тебе закрита упорна зупинка. Ось велике питання. Як щодо роботи зі старими сховищами даних, такими як VSAM, Model 205, IMS та IDMF та подібними речами? Ви бачите це дуже часто в ці дні і як добре це працює?
Скотт Вальц: Я не хочу говорити тобі, що ти застряг. Деякі з цих середовищ, якщо вони мають ODBC або JDBC, і я знаю, що деякі з них є там, ми можемо підключитися до нього, і ви можете працювати з ним таким чином. Але здебільшого зелений екран - це шлях, який потрібно продовжувати.
Dez Blanchfield: Я люблю зелений екран.
Ерік Кавана: Ви знаєте, як Дез зазначив на тому слайді, де у нього були всі ті різні додатки та інструменти, які є сьогодні, це дуже грізна реальність для кожного, хто хоче відповідально виконувати функцію адміністратора бази даних. І я здогадуюсь, що з часом ви, хлопці, можете створити з'єднувачі до будь-якого з цих інструментів, коли і коли клієнти вимагають, і так далі, правда? Щоб ви ввімкнули ту саму склопакет
Скотт Вальц: І це було великим ключем, завдяки чому DBArtisan був оснащений, щоб мати можливість обробляти ці з'єднання JDBC та ODBC. Ми дійсно це продовжили зараз. Тепер, поки у нас є цей зв'язок, правильно, доки у нас є цей драйвер, ми можемо підключитися і працювати проти нього.
Ерік Кавана: Це добре. Ну, люди, ми архівуємо все це для подальшого перегляду. Я опублікував посилання на слайди, сподіваємось, ви побачите це через SlideShare. Велике спасибі за всі ваші зусилля, панове. Чудова веб-трансляція сьогодні знову. Багато хороших слайдів. Багато хорошого змісту. Я любив цю демонстрацію. Дійсно цікаво, що ви, хлопці, націлили на дуже приємне місце на ринку, тому що зараз такий вибух типів баз даних. І нам просто потрібно, як менеджерам, десь впоратися з усім цим. Молодці, хлопці. Ми завтра наздоженемо вас за ще однією гарячою технологією. Сподіваємось, ви завтра вирізали годину. Той же час. Та сама станція. Ми наздоженемо вас наступного разу, люди. Піклуватися. Бувай.