Винос: Ведучий Ерік Кавано обговорює нововведення в технології баз даних з експертами Дез Бланчфілд, Робін Блор та Бертом Скальцо.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Пані та панове, це середа, о чотири східного часу. Я в Новому Орлеані, приходить літо, це означає, що спекотно! Настав час гарячих технологій, так, справді, так. Мене звуть Ерік Кавана, я буду твоїм господарем. Я поверну м'яч сюди для Hot Technologies. Сьогодні тема - «Наперед Момент: Переміщення релаксації понад традиційне». Народо, сьогодні у нас є троє експертів із баз даних, тому будь-які запитання у вас, їх важкі, не соромтеся. У нас сьогодні вишикується купа хорошого вмісту. Є місце про твою справді, достатньо про мене. Звичайно, цей рік гарячий. Ми говоримо про гарячі технології в цьому шоу, яке є партнерством з нашими друзями з Techopedia. І ми сьогодні йдемо повністю до основи управління інформацією, що, звичайно, є базою даних. Ми поговоримо про те, як ми потрапили сюди, що відбувається сьогодні і що відбувається вперед. Багато цікавих речей відбувається.
Очевидно, що у просторі бази даних є серйозні нововведення. На деякий час було тихо; якщо ви поговорите з деякими аналітиками в бізнесі, я б сказав, мабуть, з року, як, наприклад, з 2005 по 2009 рік або з «10 року, не здавалося, що надто багато відбувається в інноваціях.І раптом це просто вибухнуло, як у в'язниці чи щось таке, і зараз трапляються всілякі цікаві речі. Дуже багато це через масштабність Інтернету та всі цікаві веб-властивості, які роблять різні цікаві речі. Звідси походить концепція NoSQL. А це означає дві різні речі: це означає відсутність SQL, оскільки в ньому не підтримується SQL, це також означає не тільки SQL. Існує термін "NewSQL", який використовували деякі люди. Але очевидно, що SQL - структурована мова запитів - це справді основа, це основа запитів.
І цікаво, що всі ці двигуни NoSQL, що сталося? Ну, вони вийшли, було дуже хвилювання з цього приводу, а потім через кілька років, що ми всі почали чути? О, SQL на Hadoop. Ну, всі ці компанії почали плескати інтерфейси SQL на свої інструменти NoSQL, і кожен, хто перебуває у світі програмування, знає, що це призведе до певних проблем і певних труднощів, а також до деяких схрещених проводів тощо. Тож ми сьогодні дізнаємося про багато цього матеріалу.
Є наші три ведучі: до нас дзвонить Дез Бланшфілд із Сіднея, наш власний Робін Блор, який знаходиться в Техасі, а також Берт Скальцо, він також у Техасі. Тож насамперед ми почуємо від Дез Бланшфілд. Люди, ми будемо твітувати за хештегом #HotTech, тому сміливо ставитеся до своїх коментарів чи запитань через компонент Q&A на консолі веб-трансляції чи навіть через вікно чату. І з цим, Дез Бланчфілд, забирай це.
Dez Blanchfield: Дякую, Еріку. Привіт всім. Тож я спробую встановити сцену на точці зору 30 000 футів, що трапилось за останнє десятиліття, і значні зрушення, які ми спостерігали - або принаймні десять з половиною в будь-якому випадку - системи управління базами даних, а також деякі наслідки з комерційної чи технічної точки зору, а також деякі тенденції, про які ми пізно пережили, і ведуть нас до розмови, яку ми сьогодні маємо вести навколо цієї теми.
Моє зображення на обкладинці - це піщана дюна, і над її верхом віє маленькі шматочки піску. І в результаті цього відбувається те, що піщана дюна повільно переходить з одного простору в інший. І це дивовижне явище, де ці масивні 40- та 50-футові високі піщані гори фактично пересуваються. І вони рухаються дуже повільно, але рухаються напевно, і, рухаючись, вони змінюють пейзаж. І на те, що слід дивитися, якщо ви взагалі проводите час у місцевості, де піщані дюни - це природна річ. Тому що ти можеш зазирнути у вікно одного дня і зрозуміти, що ця масивна гора з піску, маленькі крихітні зерна перенесли все само собою, насправді, і що вітер повільно переміщує її з одного місця на інше.
І я думаю, що багато разів це був світ систем баз даних. До зовсім-зовсім недавно той зовсім невеликий зсув у вигляді піщаних зерен переміщав гігантську піщану гору у вигляді піщаної дюни. Протягом багатьох років на платформах баз даних потрапили невеликі зрушення, і це було досить стабільним і міцним середовищем навколо систем та платформ баз даних через мейнфрейм епохи середнього діапазону. Але пізно, у нас відбулися деякі досить важливі речі з нашими комерційними потребами та нашими технічними драйверами. Я пройду нас через них.
У мене є думка, що основна концепція бази даних, як ми її знали багато, багато років, і, як ви, можливо, чули на попередній виставі, наші двоє експертів, які сьогодні спілкуються зі мною, прожили все життя цей простір, і вони цілком вірно діляться хвастощними правами перебування там, коли все почалося на початку 80-х. Але ми спостерігали цей масовий зсув в останнє десятиліття і трохи, і я збираюся швидко пройти нас, перш ніж передати його доктору Робіну Блору.
Ми переживали це, що я називаю, «більший, кращий, швидший, дешевший» досвід. Як я вже сказав, визначення бази даних змінилося. Ландшафт, у якому платформи баз даних мали відповідати продуктивності, а також змінилися технічні та комерційні вимоги. Ми спостерігали збільшення попиту на рішення, що стосуються або складніших комерційних, або складніших технічних вимог. І так по-справжньому швидкий погляд на те, що це насправді означає, на мій погляд, це те, що ми почали своєрідні 90-ті, і ми побачили, що технологія баз даних впливає впровадженням Інтернету, і щось, що ми викликали тоді Інтернет масштаб. Ми говорили не про людей, що сидять перед терміналами, спочатку подібні до телевізійних терміналів із вбудованими в них фізичними елементами та 132 колонками, що виходять у папері. Потім ранні термінали зеленого екрану, пробиваючи клавіатури.
Але ви знаєте, наш світ тривалий час були терміналами та послідовними кабелями або мережевими кабелями, що розмовляли з комп'ютерами. Потім з'явився Інтернет, і це вибухонебезпечне зростання зв’язку, що вам більше не потрібно було підключатися до комп'ютера. Щоб потрапити в систему бази даних, вам просто знадобився веб-браузер. Таким чином, технологію баз даних довелося кардинально змінити, щоб розібратися з масштабом всього, починаючи від основних технологій пошукових систем, які використовувались для індексації світу, і зберігати індекс інформації на прикладі шкали формату бази даних. І такі люди, як Google та інші, забезпечили платформу для цього. І були створені всі нові типи зберігання баз даних, запитів та індексування. І тоді у нас були музичні сайти, і разом із ними з'являються сайти з кіно.
І тоді, у 2000-х, ми побачили крапку дот-ком, і це призвело до ще більш різкого вибуху в кількості людей, що користуються системами, які незмінно працювали за допомогою бази даних певної форми. Цей етап, реляційні бази даних, як і раніше справляються з більшою частиною навантаження, ми просто поклали їх на більшу олово, і ми наче пішли на дуже-дуже-дуже великі системи середнього діапазону, на яких працює платформа Unix від таких людей, як IBM та Sun тощо. . Бут dot-com просто зробив речі більші та швидші з апаратної точки зору, з точки зору продуктивності, і в двигунах бази даних відбулися деякі суттєві зміни, але, з іншого боку, це все одно було те саме, що ми бачили довгий час.
І тоді ми отримали цю епоху Web 2.0, як ми її посилаємося. І це було жахливим зрушенням, адже раптом нам знадобилися набагато простіші платформи баз даних, і в горизонтальній формі мав бути масштаб. І це було настільки суттєвим зрушенням у тому, що ми підійшли до ідеї, що таке база даних. На наш погляд, ми все ще дійсно наздоганяємо. І тепер ми маємо справу з цілою цією трясовиною, і я кажу, що з позитивним обертанням, а не негативною конотацією, цією трясовиною того, що ми називаємо великими даними, і величезним вибухом, і я маю на увазі вибух. Це обурливе зміщення вертикально на графіку кількості варіантів, які ми маємо, коли ми говоримо про базу даних та певну форму можливості реляційного запиту.
І що цікаво, я особисто вважаю, що вважаю, що великі дані справді є лише вершиною айсберга. Ми, як правило, трохи захоплюємось впливом великих даних і типи варіантів, які ми маємо в наявності зараз. У нас є все від двигунів NoSQL, у нас є графічні двигуни, у нас є всі ці різні типи платформ, на які ми можемо перекидати дані і робити з ними справи. Навіть до того моменту, коли насправді одна з перших розмов, яку я мав з Еріком Кавана, який сьогодні тут з нами, проходила навколо розмови, що стосувалася речі під назвою Apache Drill, що є проектом з відкритим кодом, який дозволяє запитувати. дані всередині моделі різних типів даних: все - від необроблених файлів CSE, що сидять на жорсткому диску, до файлових систем HDFS в петабайтовому масштабі. І ви знаєте, це дозволяє вам робити ці запити в стилі SQL за структурованими та неструктурованими даними всіх видів захоплюючих рослин.
Ми збираємось побачити, що "розумна будівля" стала річчю, і ми хотіли б подумати, що у нас є розумні будівлі безпеки та управління теплом, але я говорю про розумні будівлі, які знають набагато більше про те, хто ти і де ти знаходишся, коли заходиш і робиш усілякі акуратні речі на цьому рівні, через розумні міста - цілі екосистеми на рівні міста - які вміють робити речі розумно. І крім цього, у нас є ця неймовірна річ, яку я не думаю, що ніхто в світі повністю зрозумів, і це форма Інтернету речей. Протягом останнього десятиліття відбулися всі ці різні зміни, можливо, два десятиліття приблизно, якщо ми їх округлили, які, на мій погляд, просто вплинули на світ того, що ми вважаємо базами даних.
Існувало кілька важливих речей, які зробили це можливим. Вартість жорстких дисків різко знизилася, і це багато в чому дозволило керувати деякими еталонними архітектурами, такими як модель Hadoop, завдяки чому ми беремо безліч даних і поширюємо їх на безліч жорстких дисків, і робити з цим розумні речі. Насправді те, що стало загостреним, на мій погляд, реляційною базою даних або традиційною моделлю одиниць БД. І оперативна пам’ять вийшла дуже-дуже дешевою, і це дало нам зовсім нову можливість пограти з різними референтними архітектурами, такими як пам'ять, і робити такі речі, як розділення дуже, дуже великих грудок даних.
Отже, це дало нам цю маленьку картину, яку ми зараз дивимось, а це діаграма, яка показує типи платформ, які доступні, якщо ви перебуваєте у просторі великих даних. І це дуже, дуже важко читати, і причиною цього є дуже багато інформації про це. Існує так багато варіантів виготовлення, моделювання та виготовлення способів введення даних у будь-які форми систем баз даних та запитів на них, а також традиційного читання-запису. І вони не всі сумісні, адже мало хто з них навіть відповідає будь-якому базовому стандарту стилю, але вони все ще вважають себе базою даних. І я збираюсь показати вам кілька екранів за секунду, щоб дати вам певну думку про те, що я маю на увазі під переходом від 90-х та масштабу Інтернету, до Інтернету 2.0, а потім усього зростання за допомогою великих даних. Якщо ми вважаємо, що цей краєвидний графік технології великих даних є захоплюючим, оскільки на ньому є багато варіантів, давайте просто подивимось на одну ключову вертикаль.
Давайте розглянемо маркетингові технології. Ось варіанти систем управління базами даних або управління даними всередині простору технологій, тому технології, пов'язані з маркетингом. Зараз це було в 2011 році, так кілька років тому; п’ять років тому таким виглядав пейзаж. Якщо я коротко повернуся до одного слайда, ось так виглядає сьогоднішній пейзаж даних у різних брендах та пропозиціях, які ми отримали в технологіях баз даних. Ось як виглядала одна вертикаль п’ять років тому, просто в маркетингових технологіях.
Тепер, якщо я переходжу до сьогоднішнього погляду, це виглядає так, і це абсолютно непроникно. Це лише ця стіна брендів і варіантів, і це тисячі і тисячі комбінацій програмного забезпечення, яке вважає себе в класі баз даних, що дозволяє захоплювати, створювати або зберігати та отримувати дані в різних формах. І я думаю, ми зараз вступаємо в дуже, дуже цікавий і сміливий час, коли колись ви могли знати основних брендів, ви могли знати п'ять-шість різних платформ від Oracle і Informix, DB2 тощо, і бути майже експерт з усіх брендів, які були доступні десь 20 років тому. Десять років тому це стало трохи простіше, тому що деякі бренди випали, і не всі бренди могли впоратися зі масштабом бут-ком-буму, а деякі компанії просто зірвалися.
Сьогодні абсолютно неможливо бути експертом у всіх існуючих технологіях баз даних, будь то реляційні бази даних або стандартні платформи управління базами даних, про які ми знали протягом останніх кількох десятиліть. Або, мабуть, так, більш сучасні двигуни, такі як Neo4j і такі типи. І тому я думаю, що ми вступаємо в дуже сміливий світ, де доступно багато варіантів, і у нас є платформи в масштабі на горизонтальній основі, або в пам'яті, або на диску зараз. Але я вважаю, що це час для людей, які приймають рішення щодо технологій та бізнес-рішень, непростий, адже їм потрібно прийняти дуже великі рішення щодо технологічних наборів, які в деяких випадках існують лише протягом багатьох місяців. Вісімнадцять місяців не є страшним числом для деяких більш захоплюючих і нових платформ баз даних з відкритим кодом. І вони починають об’єднувати платформи і стають ще новішими та захоплюючими.
Я думаю, що сьогодні ми проведемо велику розмову про те, як це все вплинуло на традиційні платформи баз даних і як вони реагують на неї, і типи технологій, які на це кидаються. І маючи це на увазі, я зараз передам доктору Робіну Блору і отримаю його розуміння. Робін, до тебе.
Робін Блор: Гаразд, дякую за це. Так, це занадто велика тема. Я маю на увазі, якби ти просто взяв на себе одну з ілюстрацій, яку Дез тобі щойно показав, ти можеш вести довгу розмову лише про один зі славерів. Але ви знаєте, ви можете зайти в базу даних - я дивився бази даних, я не знаю, починаючи з 1980-х, і ви можете дивитися на базу даних по-різному. І одна з речей, яку я вважав, що буду робити, просто кидаю сьогодні в розмову, - це говорити про причину того, що руйнівні речі сталися на рівні апаратних засобів. І ви повинні мати на увазі, дуже багато руйнівних речей насправді траплялося і на рівні програмного забезпечення, тому це не повне уявлення про що-небудь, це лише апаратне.
Я теж не збирався розмовляти особливо довго, я просто хотів дати вам фотографію обладнання. База даних - це можливості пошуку даних, що охоплюють процесор, пам'ять та диск, і це різко змінюється. І причиною цього я вважаю, що я навчився розуміти базу даних з точки зору того, що ти насправді робив. Ви знаєте, різниця у затримці між даними, які насправді є центральним процесором, і даними, які витягуються в ЦП з пам'яті, і даними, які перетягуються з диска в пам'ять і через процесор. І старі архітектури баз даних просто намагалися збалансувати це. Ви знаєте, вони просто казали: "Ну, це йде дуже повільно, ми будемо кешувати дані на диску, щоб це було в пам'яті. Ми постараємось зробити це по-справжньому точним чином, щоб дійсно гарна частина запитуваних нами даних вже була в пам’яті. І ми будемо марширувати дані на процесор так швидко, наскільки насправді це можливо ».
А бази даних писалися за старих часів, машини пишуться для невеликих кластерів. А тепер - за неосвіченого паралелізму. Тому що якщо ви збираєтеся отримати деяку ефективність із кластера, вам доведеться робити різні дії паралельно. Паралелізм - це частина гри, не така, як зараз. Я просто пройдуся через те, що сталося.
Перш за все, диск. Ну диск закінчений, дійсно. Що стосується баз даних. Я думаю, що існує багато мінусів для архівації даних, і навіть дуже великі озера даних, що працюють на Hadoop, найгірший спінінг-диск, мабуть, життєздатний в наш час. Дійсно, проблема зі спінінг-диском полягала в тому, що швидкість читання не особливо покращилася. І коли процесор піднімався, швидкість закону Мура, на зразок порядку, швидше кожні шість років. І пам'ять якось стежила за нею, тоді ці двоє розумно йшли в ногу один з одним, це було не зовсім гладко, але вони.
Але випадкове зчитування на диску, де голова летить про диск, я маю на увазі, крім усього іншого, це фізичний рух. І якщо ви робите випадкові зчитування з диска, це надзвичайно повільно порівняно з читанням з пам'яті, це як у 100 000 разів повільніше. І зовсім недавно більшість архітектур баз даних, які я переглянув у будь-якій глибині, насправді щойно серійно читали з дисків. Ви дуже хочете, так чи інакше, просто кешувати з диска стільки, скільки зможете, і витягніть його з цього повільного пристрою і покладіть на швидкий пристрій. І є багато розумних речей, які ви можете зробити з цим, але все закінчилося.
І твердотільні диски, або флешки, справді, є такими, якими вони є, дуже швидко замінюють спінінг. І це знову змінюється повністю, адже спосіб організації даних на диску - це впорядкованість відповідно до способу роботи диска. Це насправді про головку, що рухається по прядильній поверхні, насправді кілька головок, що рухаються по декількох прядильних поверхнях, і збирання даних під час руху. Твердотільний накопичувач - це лише блок речей, який ви можете прочитати. Я маю на увазі, перше, що всі традиційні бази даних були розроблені для обертання диска, і тепер вони перепроектовані для SSD. Можливо, нові бази даних - будь-хто, хто зараз пише нову базу даних, може ігнорувати спінінг, а не думати про це взагалі. Але Samsung, головний виробник SSD, говорить нам, що SSD-диски фактично перебувають на кривій закону Мура.
Вони, на мою думку, вже були в три-чотири рази швидшими, ніж спінінг, але в основному вони збираються набагато швидше кожні 18 місяців. Подвійна в швидкості і в 10 разів швидкість до приблизно шести років. Якщо це було тільки це, то це не так, як я вам скажу за мить. Спінінг-диск, безумовно, стає архіваційним середовищем.
Про пам’ять. Перш за все, оперативна пам'ять. Коефіцієнт процесора між ОЗП на процесор постійно зростає. І це, звичайно, певним чином забезпечує набагато більше швидкості, тому що акри пам'яті, які ви можете мати зараз, можуть зберігати набагато більше. Це насправді - це, таким чином, зменшує тиск на додатки типу MLTP або випадкові програми, які читаються, тому що їх простіше обслуговувати, тому що у вас зараз багато пам'яті, і таким чином ви можете кешувати все, що є ймовірно, буде прочитаний в пам'яті. Але у вас виникають проблеми з великою масою даних, так що великі дані насправді не так просто.
І тоді у нас є Intel з 3D Xpoint, і IBM з тим, що вони називають PCM, це пам'ять фазових змін, постачає щось, на що вони вважають, - ну, принаймні, у 10 разів швидше, ніж нинішні SSD, і вони вірять, що це отримає дуже близький до тієї ж швидкості, що і ОЗП. І звичайно, це дешевше. Тож раніше у вас була структура бази даних процесора, пам'яті та диска, а тепер ми рухаємося до структури, яка має чотири шари. У нього є процесор, пам'ять або оперативна пам’ять, а потім ця швидкість, ніж SSD-пам'ять, яка насправді є енергонезалежним, а потім SSD. І ці нові технології є енергонезалежними.
І є пам’ятник HP, якого ще немає, знаєте, оскільки він був оголошений близько семи років тому, але він ще не з’явився. Але чутки, які я чую, - це те, що компанія HP також трохи змінить гру з пам’ятником, тож у вас просто нова ситуація з пам’яттю. Це не так, як у нас швидші речі, це як у нас новий новий шар. І тоді ми отримали той факт, що доступ до SSD ви можете читати паралельно. Ви не можете читати спінінг паралельно, за винятком того, що є багато різних спінінг-дисків. Але блок SSD ви можете насправді читати паралельно. І тому, що ви можете читати, що паралельно, це проходить набагато швидше, ніж його прості швидкості читання, якщо ви насправді налаштовуєте кілька процесів у різних процесах на одному процесорі, і просто у нього є SSD.
За підрахунками, ви можете досягти майже швидкості оперативної пам’яті, зробивши це. І все, про що це говорить, майбутнє архітектури пам’яті незрозуміле. Я маю на увазі, реальність така, що різні домінуючі постачальники, ким би вони не виявилися, ймовірно, визначать напрям обладнання. Але ніхто не знає, куди йде в даний момент часу. Я розмовляв з деякими інженерами бази даних, які кажуть: "Я не боюся того, що відбувається", але вони не знають, як оптимізувати це під час роботи. І ти завжди так робив, так що цікаво
А потім є процесор. Ну, багатоядерні процесори були не просто багатоядерними процесорами. У нас також є значні обсяги кешів L1, L2 та L3, зокрема L3, який становить, я не знаю, десятків мегабайт. Ви можете багато покласти туди, знаєте. Отже, ви можете реально використовувати чіп як засіб кешування. Отже, це змінило гру. І звичайно, векторна обробка та стиснення даних, багато постачальників насправді зробили це, перетягнувши цей матеріал на процесор, щоб це все пройшло набагато швидше в процесорі. Тоді ви отримуєте той факт, що, ну, процесори з графічними процесорами дійсно добре прискорюють аналітику. І вони дуже хороші в певних видах запитів, це просто залежить від вашого запиту.
Ви можете створювати плати з процесорами та графічними процесорами, або, як це робить AMD зараз, ви виробляєте щось, що називається APU, що є своєрідним шлюбом CPU і GPU; у нього є обидва види можливості. Таким чином, це різні види процесорів. І тоді нещодавнє повідомлення від Intel, що вони збираються поставити FPGA на чіп, це робило мою голову. Я думав: "Як на землі це станеться?" Тому що якщо у вас є можливість CPU, GPU, і у вас є можливість CPU, FPGA - і, до речі, якщо ви дійсно хочете, на одній платі ви можете поставити процесор, і GPU, і FPGA. Я не маю уявлення, як би ви насправді працювали чим-небудь таким чином, але я знаю компаній, які роблять подібні дії, і вони отримують дуже, дуже швидкі відповіді на запити. Це не те, що буде ігноруватися, це те, що використовуються усталеними постачальниками та, можливо, новими постачальниками. СУБД завжди були паралельними, але тепер паралельні можливості просто вибухнули, оскільки це дозволяє паралелізувати це з тим, з тим, з цим різними способами.
Нарешті, масштабувати або масштабувати? Масштабування - це дійсно найкраще рішення, але з одного боку. Ви отримуєте набагато кращу ефективність вузла, якщо зможете просто оптимізувати продуктивність процесора та пам'яті на диску на одному вузлі. І ви будете використовувати менше вузлів, тож це буде дешевше, правда? І це буде простіше в управлінні. На жаль, це дизайн, що залежить від обладнання, і коли зміни апаратних засобів це стає все менше і менше можливо, якщо тільки ваші інженери не зможуть працювати так швидко, як обладнання змінюється. І у вас виникають проблеми з навантаженням, оскільки, коли ви збільшуєте масштаб, ви робите різні припущення щодо того, яке навантаження буде робити.
Якщо ви масштабуєте масштаб, тобто якщо ваша архітектура підкреслює масштаб, перш ніж збільшувати масштаб - насправді вам доведеться робити їх і те, і інше. Тоді ви отримаєте кращі показники роботи мережі, тому що архітектура буде цим займатися. Це буде дорожче в апаратному відношенні, оскільки буде більше вузлів, але буде менше проблем із завантаженням, і буде більш гнучка конструкція.
І я просто думав, що я б це кину, тому що якщо ви насправді думаєте про всі апаратні зміни, я просто вказав пальцем на вас, а потім ви задумалися, як ви збираєтеся масштабувати та масштабувати це? Тоді ви розумієте, що інженери бази даних, на мою думку, принаймні недостатньо оплачені. Тож якщо ви просто розглядаєте апаратний рівень, проблеми з базою даних зрозумілі. Тепер я передаю це Берту, який змусить усіх нас почувати себе освіченими.
Ерік Кавана: Це воно! Берт?
Берт Скальцо: Дуже дякую. Дозвольте мені просто перейти до цих слайдів. У мене є багато слайдів, щоб пройти, тому на досить багатьох з них я можу пройти досить швидко. Ми будемо говорити про це "Момент вперед: Перехід релаксації понад традиційний". Це вже не база даних вашого батька. Все змінилося, і, як говорив раніше спікер, за останні шість-сім років пейзаж докорінно змінився.
Я сам займався базами даних з середини 80-х. Я писав книги про Oracle, SQL Server, бенчмаркінг та багато інших речей. «Світ змінюється дуже швидко. Великі вже не будуть бити малих. Це буде швидке побиття повільного. "Я додав" адаптуватися ". Це було від Руперта Мердока. Я дуже вірю, що це буде правдою. Ви не зможете робити дані з бази даних так, як ви робили 10, 15, 20 років тому. Вам доведеться робити це так, як хоче бізнес зараз.
Я спробую залишитися трохи загальним у тому, що я представляю, але більшість функцій, про які я говорю, ви знайдете в Oracle, ви знайдете в SQL Server, MySQL, MariaDB та деяких інших великих гравців. Революція реляційних баз даних я знов погоджуюсь з більш ранніми спікерами. Якщо ви добре подивитесь близько 2010 року, ми перейшли від червоної гоночної машини до жовтої гоночної машини. Були суттєві зміни, і 2020 рік, я вважаю, ви побачите ще одну кардинальну зміну. Ми дуже цікавий час.
Тепер цей слайд є ключовим, тому я поставив там ключ. Все це відбувається, і з лівого боку у мене є технологія, а з правого - у мене бізнес. І питання полягає в тому, хто кого викликає, а хто підтримує? У нас є всі ці апаратні зміни: диски знижуються, збільшується розмір диска, нові типи дисків, так що це стосувалося попередніх динаміків. Ціна пам'яті падає, всі ці новіші версії баз даних. Але з правого боку ми маємо захист та дотримання даних, зберігання даних, бізнес-аналітику, аналітику, обов'язкове зберігання даних. Обидві сторони рівняння є рушійними, і обидві сторони рівняння будуть використовувати всі ці нові функції.
Перш за все, у нас є наш типовий спінінг-диск SAS, вони зараз до 10 терабайт. Якщо ви не бачили, Western Digital, HGST має те, що вони називають гелієвим накопичувачем, який зараз доходить приблизно до 10 терабайт. Витрати на прядильний диск стають досить низькими. Як уже згадувалося раніше, ви можете отримати твердотілі диски розміром приблизно до двох терабайт, однак у Samsung незабаром з'явиться 20-терабайтний блок. Витрати стають розумними. Одне, що я збираюся поговорити про інших, не було, це концепція флеш-дисків. PCIe, тобто PCI Express, порівняно з NVMe, ви можете або не чули про це, енергонезалежний експрес пам'яті. В основному, NVMe стане заміною SAS і SATA, і це дійсно більше протокол зв'язку, ніж будь-що інше. Але на цих дисках зараз є близько трьох терабайт.
Можливо, ви також бачили, що деякі накопичувачі SAS тепер мають роз'єми U.2, який є іншим роз'ємом, ніж SAS або SATA, який підтримує NVMe зі звичайним диском - диск, звичайно, також повинен підтримувати його. А потім SATA з роз'ємами M.2, і вони починають отримувати NVMe. Насправді є продавці ноутбуків, які зараз продають ноутбуки, на яких є флеш-диск NVMe, і вони будуть кричати в порівнянні з технологією, яку ви використовували раніше.
Дуже багато людей не знають, що це за різні спалахи. Якщо ви подивитесь у нижньому правому куті, це приклад M.2. Ви можете сказати: «Ну, бо, це схоже на диск mSATA зліва від нього». Але, як ви бачите, у нього є два проміжки в штифтах, на відміну від одного, і він трохи більший. А також, M.2 може поставлятися в трьох різних розмірах.
А потім спалах PCI Express і спалах NVMe. Тепер спалах NVMe - це також PCI Express, але PCI Express, як правило, все ще є алгоритмом контролера типу SAS або SATA, який був написаний для спінінг-диску, а NVMe - алгоритми або методи, написані спеціально для спалаху. І знову, ви побачите все це.
NVMe пропонує досить багато речей. Я думаю, що два найбільші покращення полягають у тому, що у верхньому правому куті затримка знижується на цілих 70 відсотків. Я насправді бачив навіть вище за це. Крім того, якщо ви дивитесь у нижньому правому куті, коли ваша операційна система розмовляє з диском NVMe, вона проходить набагато менше рівнів програмного забезпечення. По суті, ви переглядаєте драйвер NVMe, який зараз включений в операційну систему, і він спілкується прямо з медіа. Є багато причин, через які ця технологія докорінно змінить світ баз даних.
І багато разів люди скажуть: "Ну, як швидко NVMe?" Ви знаєте, старі добрі часи, ще в 2004 році і раніше, ми були схвильовані, якщо у нас був Ultra-320 SCSI, 300 мегабайт в секунду. Сьогоднішньою швидкістю, багато з вас, ймовірно, на волокні або InfiniBand, і такі види виходять найкраще. NVMe там справа, починається там, де закінчуються сучасні технології. Що я отримую, це те, що PCI Express 3.0 з восьмиполосною посиланням починається майже з 8000, і він підніметься, коли ми отримаємо новіші версії PCI Express, версії чотири тощо. NVMe нікуди подітись, окрім вгору.
Тепер, які речі змінюються в базі даних? Тепер у верхньому правому куті моїх слайдів я викладаю ділові причини, на які я думаю, що технології з'явилися. У цьому випадку через зберігання даних та через регуляторні причини обов'язкового зберігання даних бази даних починають надавати стиснення в них. Тепер деякі бази даних пропонують стиснення як доповнення, деякі пропонують його як вбудоване до стандартного, скажімо, корпоративного видання своєї бази даних, і все ж деякі бази даних, як в Oracle, можуть навіть мати ще кращу версію стиснення, що є скажімо, на їх платформі Exadata, тому вони фактично створили апаратне забезпечення, яке може підтримувати дуже спеціалізовану компресію, і те, що в Exadata, наприклад, отримує 40-кратний коефіцієнт стиснення, і це дуже важливо. І я думаю, що це обов’язкове зберігання даних, люди просто хочуть даних довше. Підприємствам для того, щоб робити аналітику та біологічну допомогу, їм потрібні останні 5, 10, 15 років даних.
Тепер ще одна особливість, яка почала з'являтися приблизно в той період 2008, 2009 років, була розділенням. Знову ви знайдете це в таких базах даних, як Oracle, SQL Server, і в обох тих, за які вам доведеться заплатити. В Oracle вам потрібно придбати опцію розділення, а в SQL Server ви повинні бути у версії центру обробки даних. Це ваша традиційна техніка «ділити і перемагай», і те, що ви робите, - у вас є концепція логічної великої таблиці вгорі, і коли її ставлять на диск, вона насправді розбивається на відра. І ви можете бачити, що ці відряди організовані за деякими критеріями розділення, як правило, посилаються на них або називаються вашою функцією розділення, і тоді також ви можете підрозділяти на деяких платформах баз даних, і ви можете піти ще далі.
Знову ж таки, я думаю, що і зберігання даних, і обов'язкове зберігання даних підштовхнули це, і в деяких з цих баз даних ви можете мати до 64 000 розділів, і я вважаю, що в деяких інших базах даних навіть до 64 000 підрозділів. Це дозволяє розбити дані на керовані частини. Ви також розділите індекси; це варіант, вам не потрібно, але ви також можете розділити свої індекси. Однією з причин цього може бути те, що у вас є розсувне вікно даних. Ви хочете зберегти дані вартістю 10 років, але для того, щоб знизити індекси для запуску пакетного навантаження сьогодні, вам не потрібно скидати індекси на кожен ряд, лише на рядки, які знаходяться в поточному відрізку. Розмежування насправді є дуже хорошим адміністративним інструментом, хоча більшість людей вважає, що його велика користь полягає у тому, щоб пройти усунення розділів у ваших планах і, отже, прискорити запити. Це справді вид глазурі на торті.
Тепер ви, мабуть, чули про загострення і, напевно, думаєте: «Ну, чому ви поставили цей слайд сюди?» Це один із тих NoSQL - це одне з таких середовищ типу Hadoop. Oracle 12c випустив два, які ще не є G8, але які демонструються чи попередньо переглядаються, насправді в ньому є різкість. Ви будете мати традиційну систему баз даних, як Oracle, і ви зможете осколити, як у моделі Hadoop, і тому у вас буде інша техніка розділення і перемоги, яка поділить ваш Таблиця по рядках в групування по вузлу, і це буде так само, як і те, що ви бачите в деяких своїх базах даних NoSQL. І насправді MySQL, ви можете реально досягти цього, використовуючи одну з методів їх кластеризації, але він переходить до традиційної бази даних, і я гадаю, що Microsoft не захоче залишатися позаду. Ці дві гри весь час стрибають між собою, тому я б сподівався побачити загострення в, можливо, наступній версії SQL Server.
Управління життєвим циклом даних, знову обов'язкове збереження даних, але також для бізнес-аналітики та аналітики. Дійсно, це техніка розділення і перемоги, і зазвичай DBA роблять це вручну, і це: "Я збираюся зберігати дані цього року на швидких дисках, минулорічні дані на трохи повільніших дисках, можливо, я йду щоб зберегти останні два роки до цього на ще повільніших дисках, і тоді я буду мати якийсь архівний метод ". Зазвичай це більше не записано на магнітофон, як правило - у вас є якийсь мережевий накопичувач або пристрій, у якого багато зберігання, і це, ви знаєте, економічно вигідний, але він все ще крутиться на диску.
І тепер ви можете насправді - і в Oracle, і на SQL Server - ви можете придбати опцію, де ви визначаєте правила, і це відбувається автоматично у фоновому режимі. Вам більше не потрібно писати сценарії, нічого не потрібно робити. І якщо ви бачили SQL Server 2016, який щойно вийшов першим червня, є нова функція, яка називається "Stretch Databases", яка в основному дозволяє вам робити - у правому нижньому куті там - ви можете переміщатися з декількох шарів прямо в хмару і знову це функція, вбудована в базу даних, ви просто говорите щось на кшталт: "Якщо даним більше 365 днів, будь ласка, перемістіть їх у хмару і, знаєте, зробіть це автоматично для мене".
Це буде дуже цікавою особливістю, адже я думаю, що це може бути те, що ми побачимо в майбутньому, а це те, що ти будеш мати гібридні бази даних, де ти будеш зберігати деякі локальні а деякі в хмарі. До цього люди думали: "О, я або збираюся робити приміщення або я збираюся робити на хмарі". Зараз ми бачимо шлюб двох технологій таким гібридним способом. Я думаю, що це буде досить багато, і Microsoft першим дістався.
Повторна реакція, це пов'язано із захистом та дотриманням даних. Зараз у старі добрі часи ми могли б сказати: "Ей, розробник додатків, коли ви показуєте це у звіті, коли ви відображаєте це на екрані, ось деякі речі безпеки, які ви повинні перевірити. Будь ласка, ви знаєте, лише показуйте дані вони повинні бачити або маскувати або редагувати дані, які вони не повинні бачити ". Ну, як це зазвичай, коли ви висуваєте їх до програми, це не робиться в одному місці, так що це робиться інакше, або це не робить У деяких місцях не закінчуються. І тепер ви фактично отримали цю можливість у своїх системах баз даних.
Тепер у SQL Server 2016 ця функція вбудована, тому вона ще не є додатковою статтею витрат, яка повинна бути в додатку центру обробки даних; і в Oracle 12 ви повинні придбати їх додаток для управління життєвим циклом, але це щось нове, і знов його керує бізнес. І тим більше, що зараз ви зберігаєте стільки даних, і ви займаєтеся обробкою даних, таким чином, BI та аналітика, ви повинні знати, хто має доступ до яких даних, і переконайтеся, що їм дозволяється лише бачити, що їх дозволяють бачити.
Аналогічно, ще раз погляньте на це, захист та дотримання даних. Ви побачите, що багато систем баз даних зараз будують стиснення, або, вибачте, шифрування безпосередньо в базі даних, і що важливо в цьому шифруванні, якщо подивитися на стрілку вниз та стрілку вгору на схемі, що вона пише це вниз до зашифрованого диска, а потім він зчитує його резервне копіювання в пам'ять і розшифровує. Це насправді одна модель, є інша модель, яка насправді робить це лише тоді, коли вона передає ці дані по мережі фактичному клієнтському додатку.
У такому випадку навіть на сервері баз даних у пам'яті він може бути зашифрований і розшифрований лише тоді, коли він буде надісланий клієнтській програмі. Тут є дві різні моделі, і ви знайдете їх у базах даних, а насправді однією з баз даних, яка нещодавно додала це нещодавно, була MariaDB у їх версії 10.X; Я вважаю, що зараз 10.1 або 10.2. І я фактично зробив деякий тест на це шифрування, і щоб отримати це шифрування, я відчув лише приблизно на 8 відсотків зниження пропускної здатності або швидкості. У тесті тестування на шифрування, шифрування не викликало такої великої кількості, і це дуже корисна функція.
Зараз ми вже згадували про флеш-пам’ять та SSD-диски тощо. Однією з функцій Oracle і SQL Server, яку багато людей не усвідомлюють, є те, що ви можете взяти flash або SSD, який знаходиться на вашому сервері баз даних, і ви можете сказати базі даних: "Використовуйте це так, ніби вони були пам'яттю. Ставитесь до оперативної пам’яті як до переважних, але прикидайтесь, що це повільна пам’ять, і використовуйте її як розширений кеш. ”Тепер у SQL Server 2014 це з'явилося і отримало назву“ Розширення буферного пулу ”, це безкоштовно. В Oracle він з'явився в 11g R2 і називався "Flash Data Cache", і він також був безкоштовним.
Моя порада, однак, полягає в тому, щоб перевірити цю функцію ретельно. Кожен раз, коли ви збільшуєте кеш-пам'ять, коли ви переходите до пошуку, це займає більше часу. Якщо ви покладете три терабайтну флеш-карту і скажете базі даних: "Додайте це до пам’яті", ви насправді зможете виявити, що щось сповільнилося через час заглянути і побачити, чи це спалах, чи це брудно чи чистим? Існує точка зменшення віддачі. Моя порада - це знову тест-драйв, подивіться, що працює для вас, але знову ж таки, це у вашій базі даних, а у випадку з Oracle, як у SQL Server, так і в Oracle, він там уже пару років.
І тоді це приводить нас до дідуся, який був базою даних пам'яті, і це тому, що ціни на бази даних знизилися. Інша причина, за якою ви, мабуть, могли б подумати, що це сталося, полягає в тому, що багато аналітики вимагає, щоб дані були дуже швидко доступними, і тому вони повинні бути в пам'яті. Зверніть увагу, що алгоритми, якими користуються бази даних, щоб отримати доступ до цих даних, стискати їх, шифрувати, зберігати, ви знаєте, що в деяких випадках деякі бази даних можуть продовжувати зберігати в пам'яті як рядок.
У деяких випадках деякі бази даних можуть розбити це на орієнтований на стовпчик, і причиною цього є те, що вони отримують набагато вищий рівень стиснення, десь біля 11 до 12X, зберігаючи його в порядку стовпців проти порядку рядків. Це вперше з'явилося в SQL Server 2014, воно отримало назву "Хекатон". Це було кардинально збільшено в SQL Server 2016, вони побачать на нього посилання на різні імена, і він з'явився в Oracle 12c; Я кажу тут другий реліз, а не R2. Існували два різні версії Oracle 12c, 12.1.0.1 та 12.1.0.2. Це другий випуск версії бази даних R1.
І спосіб, який ви визначаєте, об'єкт пам'яті схожий в обох базах даних. Тут ви бачите у правому верхньому куті, я створюю SQL Server, і ви бачите, що він говорить, що оптимізовано пам'ять і довговічність є лише схемою. Я не збираюся перебирати всі ці значення синтаксису, а в Oracle це насправді навіть простіше, ви просто змінюєте таблицю і говорите в пам'яті чи ні, і ви можете це змінити. Я можу сьогодні сказати, що це пам'ять, а завтра це не так, і це дуже гнучко.
Я робив кілька тестів на Oracle за допомогою таблиць пам'яті, у мене були кілька тестів, на які запустили майже 40 хвилин, там, у верхньому ряду. Тепер важливо - до моменту, коли я дістався до двох нижчих рядків, я збільшив час виконання або зменшив його, слід сказати, приблизно на п’ять хвилин, і коли я подивився на коефіцієнт стиснення, дані в пам'яті фактично складали 3,6 в 4,6 рази менше. Це важливо, оскільки в цьому випадку я використовував формат, орієнтований на стовпці, і це стиснення. І так здогадайтесь, що? Я фактично вміщував майже 4–5 разів більше даних у своїй пам’яті. Не тільки я отримав перевагу в пам'яті, перевагу, орієнтовану на стовпці, але і перевагу набагато більшої кількості даних - до п'яти разів більше даних у кеш-пам'яті, тому це досить потужна методика. Знову ж Oracle та SQL Server, ви хочете подивитися на них, вони справді цікаві функції. І з цим я думаю, що відкрию це питання.
Ерік Кавана: Ну, Берт, по-перше, ти був дуже самовідданий у всій цій чудовій освіті. Не могли б ви поговорити хвилинку про те, що ви робите? Тому що у вас є якась технологічна технологія, яка може полегшити те, про що ви говорили. Просто поговоріть хвилину про те, що ви робите, а потім давайте Дез і Робін вниз в рівнянні.
Берт Скальцо: Так, я працюю в компанії під назвою IDERA. Ми в Техасі, штаб-квартира в Х'юстоні, і я зараз сиджу в Остіні, але я базуюсь у Далласі. Ми робимо засоби для баз даних і робимо інструменти для баз даних, щоб допомогти вам вирішити проблеми. Ця проблема може бути настільки ж простою, як продуктивність, і в цьому випадку у нас є інструмент під назвою DBArtisan, який дозволяє виконувати адміністративні завдання вашої бази даних, і це один інструмент, який дозволяє вам керувати 12 різними платформами баз даних. Я можу керувати SQL Server, я можу керувати Oracle, я можу керувати MySQL, DB2, Postgres, і я використовую один інструмент, один виконуваний файл, один дизайн GUI і один послідовний набір робочих процесів. Ми також робимо інструменти для дотримання відповідності, у нас є інструмент, який називається SQL Compliance Manager, який допоможе вам задовольнити ваші потреби у відповідності. Ще один інструмент під назвою SQL Security, тому ми намагаємося зробити інструменти, які допоможуть вам бути ефективними та ефективними, і що насправді приємно, якщо ви зайшли на наш веб-сайт, у нас є ціла купа безкоштовних програм, тому якщо нічого іншого, перейдіть на завантаження - Я думаю, у нас як 20 або 25 автострад. Там є кілька справді хороших безкоштовних програм, як-от там є SQL-сервер та довідка Windows, яка в основному розбере, що у вас є, і скаже вам, у вас є проблеми чи речі, і це абсолютно безкоштовно.
Ерік Кавана: І ти справді такий -
Берт Скальцо: Безумовно, перший матеріал -
Ерік Кавана: Ви сьогодні говорите про неоднорідність на ринку, колись було своєрідне рівняння одного розміру, яке, власне, я пам’ятаю, опитував доктора Майкла Стоунбракера ще в 2005 році, коли він продовжував великий поштовх говорив про вердикт щодо руху баз даних, орієнтованих на стовпці, і він говорив про те, як реляційна модель одного розміру-підходить домінувала протягом багатьох років, і він передбачив, що все зміниться, і хлопчик мав на це право. Зараз у нас є справді різноманітна та цікава середовище з безліччю різних варіантів та можливостей, але вам потрібен хтось, хто керує всім цим, і мені здається, що ваша компанія досить гостро зосереджена на вирішенні математичних задач, тим самим є активізатором заголовок неоднорідності, правда?
Берт Скальцо: Абсолютно. Я маю на увазі, що завжди будуть DBA, які говорять: "Я не хочу використовувати інструмент GUI, я все роблю зі сценаріями", ви знаєте? Вони думають, що вони є надменним типом DBA, і це добре, але для більшості з нас ми хочемо просто виконати роботу, і я знаю, що я використовую Microsoft Word для написання своїх документів. Я використовую Microsoft Outlook, щоб зробити своє. Я маю на увазі, у мене є інструменти для виконання завдань. Ми будуємо таку ж концепцію, ми створюємо інструменти для адміністраторів баз даних та розробників, щоб допомогти їм зосередитися на тому, що вони хочуть робити, а не на тому, як їм це робити.
Ерік Кавана: Це має сенс, але дозвольте передати вас до наших експертів, і люди можуть зануритися. У нас є кілька коментарів, що надходять від аудиторії. Може, Дез, пара питань і Робін кілька питань?
Dez Blanchfield: Звичайно. Одне з перших питань, яке я хочу кинути вам, враховуючи величезний досвід, який ви отримали, чи незабаром ви бачите момент, коли щось із цього сповільниться? Або ти думаєш, що ми справді просто в точці вступу цієї постійної лінії росту змін? Я думаю, що одне з найбільших проблем, з яким стикаються компанії, а потім незмінно люди, які намагаються підтримати технологію, яка надається цим компаніям для ведення свого бізнесу, - це те, що швидкість змін настільки драматична, що вони просто не можуть йти в ногу з усіма різні функції, і програмне забезпечення, і системи, і рамки, і архітектури, і новий код з'являються, а потім апаратне забезпечення під цим, чи бачите ви, що поточна швидкість змін взагалі сповільнюється? Я маю на увазі, ви маєте справу з настільки широким діапазоном платформ з усім набором IDERA, чи скоро ми будемо гальмувати або ми вже давно ходимо в цей божевільний побіжний вантажний поїзд?
Берт Скальцо: Я думаю, що ми знаходимося на перших 20 відсотках від цієї кривої зростання, і нам належить довгий шлях, і дві речі її підштовхують. Технологія постійно розвивається. Ви згадали про деякі нові типи пам’яті, які вийдуть, це буде фантастично. Samsung незабаром тут має 20-терабайтну флешку. Це змінить речі. У нас є всі ці бази даних NoSQL та хмари, це просто продовжуватиметься. Щось цікавого, однак, коли я дивлюся на бази даних, такі як Oracle та SQL Server та деякі інші, вони вже не є реляційними базами даних. Я можу вносити неструктуровані дані в Oracle і все ж підтримувати відповідність ACID. Якби ви сказали мені це 20 років тому, я би просто сказав, що ви вживаєте наркотики.
Dez Blanchfield: Так, так, вони круті. Ну навіть зараз ті двигуни, які мають досить гарну нішеву вертикаль, як ГІС, просто кращу, ніж рідні можливості тепер. Ви зробили кілька чудових коментарів щодо викликів, з якими стикаються DBA, і різних часів DBA, які ми сподіваємося побачити навколо цього місця, але як виглядає світ із таким шаром бізнесу, з яким ви маєте справу? Я маю на увазі, це люди, які використовують різні платформи від вашого діагностичного менеджера, до інструментів інвентаризації, і аж до наступного до дефрагментації, як DBA впораються з цією зміною і як вони - це ви знаєте , що вони роблять з вашими інструментами, щоб вирішити цю істотну зміну їхнього ландшафту?
Берт Скальцо: Ну, я повернусь майже 20 років тому, тоді я скажу, що АТД вирішують дуже конкретну роль в організації. Зазвичай вони працюють з однією платформою баз даних, можливо, двома, і вони керували відносно невеликою кількістю баз даних. Тепер швидкий перехід до сьогодні та адміністратора бази даних, він насправді знає 10 платформ баз даних. Він керує, і це не жарт, в деяких випадках тисячі баз даних; що більше в світі SQL Server або MySQL. Але все ж у світі Oracle вони могли управляти сотнями баз даних. І тому у них з’являються всі ці нові функції, у них всі ці нові платформи, і вони мають усі ці бази даних, за які вони відповідають. Вони шукають інструменти для підвищення їх продуктивності, а також, щоб допомогти їм навчитися чомусь.
І я наведу вам приклад - якщо я хочу розділити таблицю, це досить незрозумілий синтаксис, і якщо я хочу її розділити, синтаксис стає ще складніше. Я знаю, що хочу зробити, хочу створити відра. Якщо у мене є такий інструмент, як DBArtisan, який говорить: "Ей, ось приємний екран, який дозволяє зосередитись на тому, що ви намагаєтеся зробити, а не на тому, як ви намагаєтеся це зробити, і, до речі, натисніть на Покажіть кнопку SQL, коли ви закінчите, і ми покажемо вам, що таке SQL, щоб ви могли по-справжньому вчитися та освоювати це ».
DBA виявляють, що інструменти, які допомагають їм виконати роботу, але також допомагають навчити їх усім цим новим речам, які вони використовують, і те саме було б правдою - скажімо, я хлопець Oracle, і я переходжу до MySQL і скажу: «Добре, створіть базу даних, DBArtisan. Тепер покажіть мені SQL, бо мені цікаво, що це таке, як створити базу даних на MySQL, і я просто навчився синтаксису ". І тому ми не тільки допомагаємо їм працювати в базі даних, а й навчаємо їх у базі даних.
Dez Blanchfield: Це стає ще цікавіше, коли ви переходите до якогось із сучасних - чи не сучасніших, про це не чесно сказати - але колись база даних є базою даних. Ці дні я бачу все, про що ви там говорите, з додатковим викликом, що технологія, яку ми традиційно бачимо у постачальників, і ви на зразок відкритого джерела, а також, що вони хороші. Ви не просто маєте справу з двигунами бази даних та мовами запитів, але вони також стосуються типів даних, структурованих та неструктурованих, ви знаєте, завдання мати справу з усім, що знаходиться з дальнього кінця спектру багатодетабайтної HDFS оточення для маленьких крихітних контейнерів, пакетних файлів та різних форматів файлів журналів.
І я думаю, що це те, що зараз ми бачимо, де просто жодна людина, незалежно від того, скільки супермена, супер-жінки, як би вони не думали, фізично вони просто не можуть подумки боротися з такою швидкістю змін і масштаб варіацій. Я думаю, що набір інструментів, які ви зараз пропонуєте, дістанеться до того, що вони багато в чому будуть знаходитись у наборі за замовчуванням, так що ми не можемо запустити без них середовища баз даних, тому що ми просто фізично не може кинути на них стільки тіл. Мені дуже сподобалася ваша презентація. Я перейду до доктора Робін Блора, я впевнений, що у нього також багато питань, щоб на вас звернутись.
Робін Блор: Добре. Ну, я звичайно маю запитання. Берт, я не знаю, куди ти їдеш - я пару днів тому провів справді цікаву розмову, коли хтось почав мені розповідати про останній захист даних про ДУ, і мені здалося, що вони говорять, що це неймовірно драконівські з точки зору речей, на яких вони наполягали. Мені було цікаво, чи ти насправді на це подивився; це щось вам знайоме?
Берт Скальцо: Абсолютно. Так.
Робін Блор: 2016 рік, Гаразд, розкажи нам про це.
Берт Скальцо: І я насправді ...
Робін Блор: Глибоко цікаво.
Берт Скальцо: Я фактично деякий час працював у постачальника флеш-пам'яті, в їхній базі даних, допомагаючи їм створювати флеш-продукти для баз даних, і я можу вам сказати, що драконієць іде зовсім вниз. Що я маю на увазі, якщо ви пам'ятаєте мій один слайд, я казав, що в деяких базах даних він буде робити шифрування, але він вкладає його в пам'ять сервера, а в деяких базах даних - шифрування - воно все ще зашифроване в пам'яті сервера, воно розшифровується лише тоді, коли він надсилається клієнту. Що ж, ви також знайдете деякі з цих державних стандартів, особливо Міністерства оборони чи військових тут, у США, вони також знижуються до рівня спалаху, і вони хочуть знати не тільки про те, що ви підтримуєте шифрування та дешифрування в ваше обладнання, але якщо хтось вкрав чіпи, це - ви знаєте, витягнув їх із речі з вашого сервера, що те, що там зашифроване, і тому, хоча у них є сховище, цього не може бути, і вони б аж до фактичного - не до самої флеш-частини, а до окремих мікросхем. Вони хотіли знати, що чіп за чіпом, все було зашифровано.
Робін Блор: Ого. Я маю на увазі, що є багато речей, які - ви знаєте, я думаю, що ви створили це лише один-два слайди, але це був щось, сценарій, який, на мою думку, є справді цікавим. Наприклад, редагування інформації повинно бути трохи розумнішим, ніж просто маскувати різні сфери, тому що, особливо, завдяки машинному навчанню в даний час, ви можете робити дедуктивні речі, які дозволяють вивести на поверхню інформацію, яку раніше не можна було виводити на поверхню.
Якщо ви намагаєтеся захистити, скажімо, інформацію про здоров’я, то це дуже-дуже драконічні правила в США щодо інформації про здоров'я, але ви, фактично, використовуючи різні методи машинного навчання, ви можете часто визначити, хто чию медичну інформацію насправді є. Мені було просто цікаво, чи є у вас щось про це, бо всі вони думають, що це цікава область.
Берт Скальцо: Так, абсолютно, і я просто використовую це як приклад, я не намагаюся сказати, що одна база даних краще, ніж інша, але це дуже хороший приклад для того, що ви просто запитали. Якщо в Oracle мені не дозволяють бачити ряд даних, наприклад, мені не дозволяють бачити медичну документацію Джона Сміта. У Oracle, якщо я скажу: "Виберіть цей запис", я буду заблокований або мені дозволять бачити те, що мені дозволено бачити, і він буде відредагований. І якщо я скажу: "Виберіть зірку облікового запису з таблиці, де дорівнює Джон Сміт", я отримаю нуль.
У SQL Server він може робити редагування, але в ньому є деякі отвори. Якщо я скажу: "Виберіть зірку облікового запису з таблиці, де вона дорівнює Джону Сміту", я фактично отримаю одну, тому я знаю, що є Джон Сміт. Один більш безпечний, ніж інший. Тепер я очікую, що вони це виправлять, вони завжди грають у стрибкову жабу між собою. І знову: я не намагаюся розмежовувати бази даних, окрім як показувати приклад - подивіться, про що ми говоримо зараз, щось таке просте, як вибір облікового запису, також має бути скорочене редакцією, хоча технічно кажучи, нічого не редагується, крім існування рядка.
Робін Блор: Так, це правда. Це цікаво. Я маю на увазі, ще одне загальне питання, оскільки я не маю багато часу, насправді стосується вдосконалень.Я маю на увазі, що ви були в одному, де я знаю, що ви показували нам приклади різних результатів тестів, які ви запускаєте - чи вважаєте ви, що традиційні бази даних, давайте назвемо їх домінуючими базами даних, SQL Server та Oracle, чи не так? думаєте, що вони залишаться до завершення? Або ти думаєш, що насправді вони потраплять через ті чи інші різного роду збої на ринку, які справді працюють на них? Яка твоя думка?
Берт Скальцо: У мене є думка, і це - знаєте, знову ж таки, я можу сказати, що це моя думка - Microsoft, наприклад, в епоху після Баллмера просто вражає життя, яке переживає мене. Я маю на увазі, що ця розтяжна база даних переходить на SQL Server в Linux, переходить на .NET в Linux, переходить PowerShell на Linux; Я не думаю, що традиційні виробники баз даних не залишаться позаду. Я думаю, що вони вирішили: «Ей, нехай нові хлопці, стартапи щось визначають. Дозвольте їм розібратися, що таке загострення, і як його слід удосконалити, і як тільки вони виконали всі дослідження та розробки, ми точно знаємо, чого хочуть користувачі, тепер давайте додамо різкість до Oracle. "Я думаю, що вони просто розумні і кажучи: "Ей, бути другим чи третім не є поганим, коли ти домінуючий гравець, тому що тоді люди не переселяться з тебе".
Робін Блор: Так, я маю на увазі, що це стратегія, яка використовується. Я маю на увазі, що раніше це робило IBM і цілий - для всього їхнього асортименту продукції, і це робиться досить добре, поки хтось не придумає щось, що просто повністю зі стіни, про що ніхто ніколи не думав, але ви не можете планувати проти цього все одно.
Питання аудиторії, Еріку?
Ерік Кавана: Так, але у вас є час, я думаю, що для одного, можливо, і я знаю, що Берт повинен бігати. Тут було щось про - гаразд, загострювальна архітектура Oracle 12c - це вказівка - або що це, на вашу думку, про те, що, на вашу думку, відбувається там?
Берт Скальцо: Ну, Oracle поглинає або пропонує все, що є у всіх інших постачальників баз даних. Наприклад, я можу помістити неструктуровані дані в Oracle. Я не знаю, як можна вводити неструктуровані дані, а потім називати це реляційною базою даних, тому це не має сенсу, але ви можете. І тепер Oracle додає різкості, тому Oracle каже: "Ви знаєте що? Що б не хотів ринок, ми зробимо нашу базу даних, оскільки ринок хоче того, що хоче ринок, і ми хочемо забезпечити рішення, ми хочемо, щоб вони залишилися з нами ».
Я думаю, що ви збираєтеся бачити додаткові елементи. Я не був би здивований, побачивши кластеризацію вузлів баз даних, схожих на Hadoop, не в стійці Oracle або в реальному кластерному додатку, а в основному в більшості традиційних кластеризованих типів Hadoop, які роблять це заточування. І тому я думаю, ви зможете розгорнути базу даних, як Oracle, як Hadoop, і такі тенденції продовжуватимуться. Ці великі постачальники баз даних, вони заробляють мільярди доларів, і вони не хочуть втрачати свій ринок, тому вони готові пристосовуватися до чого-небудь або приймати що-небудь.
Ерік Кавана: Ну, знаєте, це смішно, бо я досить довго стежив за постачальниками з відкритим кодом та цікавився, що, наскільки великий вплив він матиме на традиційну технологію із закритими дверима, і на деякий час це впевнено відчував продавці з відкритим кодом робили серйозний прогрес, і тепер, дивлячись на ринок, я бачу щось таке, про що ви говорите, що великі хлопці зробили математику, заточили олівці і зрозуміли, як вони можуть плести. багато цього матеріалу в їх архітектурі. Будь це IBM, або Oracle, або SAP - я щойно був на конференції SapphireNow минулого місяця, і Стів Лукас, який очолює половину цієї компанії, похвалився тим, що SAP тепер є в своїй хмарній платформі HANA, більше компонентів з відкритим кодом, ніж будь-який їхній конкуренти. Якщо ви займаєтесь математикою, це дуже вражаюче твердження, і це говорить мені, що великі хлопці не збираються нікуди швидше.
Берт Скальцо: Ні, я б став би свої гроші на обидва. Я маю на увазі, якщо ви подивитесь, акції Microsoft недавно склали близько 50 доларів, і, знаєте, всього кілька років тому це було 25. Ви не подвоюєте свою ціну акцій за короткий період, якщо ви не робите хороших справ, і ви знайте, від того, щоб робити все від Windows 10 протягом першого року безкоштовно до всіх інших розумних речей, які вони роблять, ця функція бази даних розтягнутих даних, я думаю, просто феноменальна. Я думаю, що відбудеться, що багато людей збираються в Лазурі, а не прямо, не так, як вони сказали: "Давайте перенесемо мою базу даних на Azure". там, використовуючи цю нову функцію бази даних розтяжок, і тому прийняття Azure буде просто швидким.
Ерік Кавана: Ну, це одна з тенденцій на ринку, яку я бачу навіть на вашому Mac. Коли ви переходите на свій Mac, щоб зберегти деякі документи, вони зараз - і новіші Macs просто слідують за хмарою, правда? Я маю на увазі, що в цій стратегії є багато сенсу, і я також дивлюся на неї і йду: «Добре, хлопці, ви намагаєтесь заманити мене по частинах у ваше хмарне середовище, а потім колись, коли я хочу подивитися якийсь фільм, якщо термін моєї кредитної картки закінчився, я зіткнуся з проблемою. "
Берт Скальцо: Так, але ти це робиш на.
Ерік Кавана: Так. Це правда.
Берт Скальцо: Ви все поклали.
Ерік Кавана: Ну, не зовсім все.
Берт Скальцо: Ні, я маю на увазі -
Ерік Кавана: Так, далі.
Берт Скальцо: Ці соціальні тенденції охоплюють бізнес. Зараз у бізнесу є ще багато іншого, що вони мають зробити, але вони бачать ці тенденції і роблять ті ж речі. Я не бачу ні Oracle, ні Microsoft. Насправді я збираюсь купувати акції на обидва рази, коли трапляється порив.
Ерік Кавана: Так, справді. Ну, люди, перейдіть на idera.com, I-D-E-R-A крапка ком. Як сказав Берт, у них є ціла купа безкоштовних речей, і це одна з нових тенденцій на ринку - дайте вам кілька безкоштовних речей, з якими можна пограти, підчепите, а потім підете купувати справжні речі.
Люди, це була ще одна гаряча технологія. Дякуємо за Ваш сьогоднішній час, Берт, Дез, звичайно, і Робін. Ми поговоримо з вами на наступному тижні, люди, багато чого іншого. Якщо у вас є якісь ідеї, сміливо ставитесь до своїх,. Ми поговоримо з вами наступного разу, бережіть. Бувай.