Винос: Ведучий Ерік Кавана обговорює обчислення в пам'яті та SAP HANA з гостями д-ром Робіном Блором, Дез Бланчфілдом та IDERA Біллом Еллісом.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Добре, панове. Привіт і ще раз ласкаво просимо. Це четвертий східний час у середу, а останні кілька років - це означає, що знову пора гарячих технологій. Так, мене звати Ерік Кавана, я буду вашим господарем сьогоднішньої розмови.
І люди, ми сьогодні поговоримо про якісь цікаві речі. Ми збираємось зануритися у світ пам’яті, точний заголовок - «В майбутнє: на раму для обчислень в пам'яті». У наші дні це все лютує, і з поважних причин, головним чином тому, що пам'ять набагато швидше, ніж покладатися на спінінг-диски. Завдання полягає в тому, що вам доведеться переписати багато програмного забезпечення. Тому що програмне забезпечення сьогодні, більшість його, було написано з урахуванням диска, і це дійсно змінює архітектуру програми. Якщо ви розробляєте програму, щоб чекати спінінг-диска, ви просто робити щось інакше, ніж якщо у вас є вся потужність технології пам'яті.
Є місце про твою справді, вдари мене, @eric_kavanagh. Я завжди намагаюся піти назад, а також ретвітувати будь-коли, коли хтось згадає про мене.
Як я вже говорив, ми сьогодні говоримо про пам'ять, а саме про SAP HANA. Ви справді провели останній рік, дуже добре познайомившись із спільнотою SAP, і це захоплююче середовище. Капелюхи дітям, які виконують цю операцію і перебувають на передовій, тому що SAP - це надзвичайно хороша операція. У чому вони дуже хороші, - це бізнес. Вони, звичайно, також чудові в технології, і вони справді вкладають великі інвестиції в HANA. Насправді я пам'ятаю - це було, мабуть, близько шести-семи років тому - що ми робили якусь роботу для ВПС США, і ми змусили когось із SAP зайти і дати нам перший погляд на світ HANA та що планувалося. І найменше кажучи, люди в лабораторіях SAP вклали багато часу і зусиль, щоб зрозуміти, як побудувати цю архітектуру, що зовсім інше, з традиційних середовищ, адже у вас є все на пам'ять. Отже, вони говорять про те, щоб робити транзакційні та аналітичні на одних і тих же даних у пам'яті, на відміну від традиційного способу, який витягують, кладуть у куб, наприклад, аналізують його там, проти транзакційного, який відбувається зовсім по-іншому.
Це цікавий простір, і ми дізнаємось від іншого постачальника, насправді, IDERA, про те, як усі ці речі працюватимуть, і про що йдеться на пандусі, відверто кажучи. Отже, ми почуємо з доктором Робіном Блором, нашим власним головним аналітиком у групі The Bloor; Дез Бланчфілд, наш науковець з даних, а потім хороший друг Білл Елліс з IDERA. Отже, я маю передати ключі доктору Робіну Блору, який забере його.
Доктор Робін Блер: Так, як казав Ерік, час, коли ми вперше ознайомилися з SAP HANA, повернувся багато років тому. Але це було дуже цікаво, той конкретний час був дуже цікавим. Ми зіткнулися з однією або двома компаніями, які так чи інакше пропонували технологію пам'яті. Було цілком зрозуміло, що пам'ять збирається прийти. І справді це було, поки SAP не встав і раптом запустив HANA. Я маю на увазі, це було шоком, коли я побачив, як SAP це робить. Це було, мовляв, шоком, тому що я очікував, що він прийде з іншого місця. Я очікував, що це буде, знаєте, Microsoft чи Oracle, IBM чи хтось подібний. Думка, що SAP це робив, мене справді дуже здивувала. Я вважаю, що цього не повинно було бути, тому що SAP є одним із стратегічних постачальників, і, знаєте, все велике, що відбувається в галузі, походить від одного з таких.
У будь-якому випадку, вся суть про пам'ять, я маю на увазі, ми зрозуміли, що ми говорили про це, що як тільки ви фактично входите в пам'ять - це не про введення даних в пам'ять, це про прихильність до Ідея про те, що шар пам'яті є системним записом - як тільки ви переміщаєте системну запис у пам'ять, диск починає перетворюватися на носій одного типу, і він стає іншим. І я подумав, що це було дуже хвилююче, коли це почало відбуватися. Тож справді все закінчилося для спінінгу. Спінінг диск незабаром з’явиться лише в музеях. Я не впевнений, як скоро це скоро, але в основному твердотільний диск зараз знаходиться на кривій закону Мура, це вже вдесятеро швидше, ніж спінінг іржі, як вони зараз його називають, і досить скоро він буде швидше все-таки і то це означає, що використання випадків для диска стає все менше і менше.
І цікавий факт, що традиційні СУБД насправді було побудовано багато традиційного програмного забезпечення для спінінгу, він передбачав спінінг. У ньому були всілякі можливості фізичного рівня, які ретельно запрограмовані в програмі, щоб використовувати спінінг-диск, роблячи пошук даних максимально швидким. І все це змивається. Просто зникаєш, знаєш? І тоді, очевидно, було дуже - я не знаю, прибутковий, я думаю, це буде врешті-решт - відкриття для бази даних в пам'яті, яка намагалася зайняти позицію, що великі бази даних, Oracle та Microsoft, SQL Сервер та IBM DB2, він займав простір пам'яті, і було дуже цікаво спостерігати за тим, як вони йдуть вперед і роблять це.
Поговоримо про каскад пам'яті; це просто варто згадати. Це також причина, коли я згадую про це, тому, що я вклав це в дійсності, - це просто повідомити всім, коли я тут говорю про пам'ять, усі ці шари, про які я говорю, насправді є пам'яттю. Але ти раптом розумієш, коли дивишся на це, це ієрархічний магазин, це не просто пам'ять. І тому, майже все, що ми дізналися давно і давно про ієрархічний магазин, також стосується. А це також означає, що будь-яка база даних в пам'яті повинна проходити через це, деякі просто проходять її через оперативну пам'ять. І він просто збільшується, збільшується і збільшується, і тепер він вимірюється в мегабайтах. Але у вас є кеш L1, який в сто разів швидший за пам'ять, кеш-пам'ять L2 в 30 разів швидше, ніж пам'ять, а кеш-пам'ять L3 - приблизно в 10 разів швидше, ніж пам'ять. Отже, ви знаєте, що дуже багато технологій - ну, досить велика кількість технологій - прийняла стратегію використання цих кешів як, на зразок, місця для зберігання на шляху виконання завдань, зокрема технології бази даних. Отже, ви знаєте, це один вплив.
Тоді ми з'явилися поява 3D XPoint та PCM IBM. І це майже швидкість оперативної пам’яті, в основному тим, чим хвалиться обидва цих постачальника. Випадки використання, ймовірно, різні. Ранні експерименти з цим ще не завершені. Ми не знаємо, як це вплине на використання оперативної пам'яті та технології бази даних в пам'яті з цього питання. Потім у вас є оперативна пам’ять проти SSD. В даний час оперативна пам’ять приблизно в 300 разів швидша, але, звичайно, ця кратність зменшується. І SSD проти диска, який приблизно в 10 разів швидше, якщо я це розумію. Отже, така ситуація у вас є Це ієрархічний магазин. Дивлячись на це по-іншому, пам'ять, звичайно, зовсім інша. Отже, на верхній діаграмі показано два програми, обидва вони можуть мати доступ до бази даних, але, безумовно, доступ до даних про спінінг іржі. І те, як ви фактично змушуєте вас протікати через мережу, залежно від того, які залежності існують, це у вас ETL Отже, це означає, що, ви знаєте, дані переходять на прядильну іржу, а потім виходить з прядильної іржі, щоб піти куди завгодно, а щоб дістатися куди-небудь, вона повертається на прядильну іржу, яка є трима рухами. І майте на увазі, що пам'ять може бути в сто тисяч разів швидше, ніж спінінг-диск, і ви, звичайно, розумієте, що отримання даних і зберігання їх в пам’яті робить це все справді зовсім іншим.
Отже, ви могли подумати, що станеться на екрані прямо тут, ви могли подумати, що так чи інакше ETL фактично перейде від даних до даних в пам'яті. Але насправді це не може зробити; насправді у вас може виникнути ситуація праворуч тут, коли два додатки насправді можуть запускати одну пам'ять. Безумовно, база даних в пам'яті може надати вам цю можливість, доки ви маєте блокування та все інше, організоване навколо нього. Отже, це не просто змінює швидкість речей, це також змінює те, як ви насправді налаштовуєте програми та цілі потоки даних.
Отже, це величезний вплив. Отже, пам'ять руйнує, правда? І ми повинні отримати це з того, що я сказав. Зараз обробка пам’яті прискорювач, але це стане нормою. Він буде використовуватися, застосовуючись відповідно до значення програми, і тому дуже, дуже цікаво, що SAP дійсно вийде з версією свого програмного забезпечення ERP, що є в пам'яті. А покращення затримки до трьох порядків цілком можливо, а насправді навіть більше, ніж це можливо, залежно від того, як ви це зробите. Отже, ви отримуєте величезні покращення швидкості, ввімкнувши пам'ять. І підсумок, S / HANA S / 4 - який вони випустили, я думаю, що люди кажуть, що він все ще випускається, але він, звичайно, був випущений минулого року - це зміна ігор з огляду на клієнтську базу SAP. Я маю на увазі, там 10 000 компаній, які використовують ERP SAP, і майже всі вони великі компанії. Отже, ідея, що всі вони мають стимул увійти в пам'ять і використовувати їх фундаментальне, тому що ERP майже завжди є основними програмами, якими керує бізнес, це просто величезний чейнджер ігор, і це буде дуже цікаво. Але звичайно, це все звучить дуже добре, але це потрібно налаштувати розумно, і за ним потрібно добре контролювати. Це не так просто, як це звучить.
Сказавши це, я думаю, що передам бал тому, хто цей хлопець? О, австралійський хлопець, Дез Бланчфілд.
Dez Blanchfield: Дуже смішно. Завжди важкий вчинок, доктор Робін Блор. Дякую за те, що мене сьогодні взяли. Отже, велика тема, але хвилююча. Отже, я вибрав образ, який часто бачу на увазі, коли я замислююся про сучасні сховища даних про озеро та підприємства, а також про мої маленькі дорогоцінні камені даних. Так ось у мене це прекрасне озеро, оточене горами і хвилями, що виходять, і хвилі розбиваються над цими скелями. Це, начебто, як я подумки уявляю, як це виглядає всередині великого озера даних в ці дні. Хвилі - це пакетні завдання, а аналітика в режимі реального часу кидається на дані, будучи скелями. І коли я думаю про це як про фізичне озеро, воно нібито повертає мені сигнал про неспокій, що, знаєте, масштаб сховищ даних, які ми зараз будуємо, причина, по якій ми придумали цю монету та термін озеро даних полягає в тому, що вони дуже великі і вони дуже глибокі, а іноді в них можуть буріти бурі. І коли ми це робимо, ви завжди повинні вирішувати, що створює шторм.
Отже, в темі цієї речі мені здається, що цей виклик сирени в обчисленні пам'яті дійсно дуже сильний і з поважних причин. Це приносить стільки значних комерційних та технічних вигод. Це дискусія протягом декількох годин в інший день. Але загальний перехід на обчислення в пам'яті, по-перше, я просто хочу висвітлити, як ми потрапили сюди, і що це робить можливим, оскільки це, начебто, ставить основу, де деякі проблеми можуть бути в першу чергу і що нам потрібно знати мислення та думки про те, щоб у нашому світі відійти від традиційних старих спінінг-дисків, що зберігають дані, і підключаються до диску та вимикаються на диск, в пам’ять, і з пам'яті, і в процесори, до цього часу ми просто видаляємо майже один з цих цілих шарів, будучи спінінг-диском. Тому що пам’ятайте, що в самих ранніх часах обчислювальної роботи в архітектурному плані ми довго не рухалися з мейнфрейму чи середнього діапазону світу, про що ми спочатку вважали основну пам’ять і сховище барабана.
Як сказав доктор Робін Блур, підхід, який ми застосували до переміщення даних навколо архітектури комп’ютера, насправді не змінився кардинально протягом певного часу, протягом декількох десятків років. Якщо ви думаєте про те, що, знаєте, сучасні обчислення, технічно, існували, якщо ви будете пробачити каламбур протягом 60-ти років, знаєте, шість десятиліть і більше, і це в тому сенсі, що ви можете купіть ящик з полиці, як би. Перехід до нової архітектури дійсно стався в моїй свідомості, коли ми перейшли від мислення навколо мейнфреймів та середнього діапазону, основної архітектури пам’яті та барабанів, до сміливих чи надкомп'ютерних, особливо подібних до Сеймура Крей, де такі речі, як поперечні планки стала річ. Замість того, щоб мати лише один маршрут для переміщення даних по плані або материнській платі, як її називають сьогодні. І вбудована пам'ять, ви знаєте, в ці дні люди не замислюються над тим, що це насправді означає, коли кажуть DIMM і SIMM. Але SIMM - це одна вбудована пам'ять, а DIMM - це подвійна вбудована пам'ять, і ми отримали складніші можливості, оскільки існує кілька десятків типів пам'яті для різних речей: деякі для відео, деякі для загальних програм, деякі вбудовані в процесори.
Отже, відбувся такий великий перехід до нового способу зберігання та доступу до даних. Ми збираємось пройти той самий зсув у цілому цілому поколінні, але не стільки в апараті, скільки у прийнятті обладнання в бізнес-логіці та в рівні логіки даних, і це ще одна велика зміна парадигми в моєму розумі .
Але лише коротко про те, як ми потрапили сюди. Я маю на увазі, що апаратні технології вдосконалилися та значно покращилися. Ми пішли від того, щоб мати процесори, і ідея ядра була досить сучасною концепцією. Ми сприймаємо це як належне тепер, коли наші телефони мають два-чотири ядра, а наші комп’ютери - два чи чотири, а то й вісім, ядер на робочому столі та вісім та 12 і більше на, ви знаєте, 16 і 32 навіть на серверній платформі . Але насправді досить сучасна річ, що ядра стали здатністю всередині процесорів, і ми перейшли від 32-розрядної до 64-розрядної. Там сталося кілька великих речей: у нас більша тактова швидкість на декількох ядрах, щоб ми могли робити паралельно, і кожне з цих ядер могло запускати кілька потоків. Раптом ми змогли одночасно запустити багато речей на одних і тих же даних.Шістдесят чотири бітові проміжки адреси дали нам до двох терабайт оперативної пам’яті, що є феноменальною концепцією, але це вже справа. Ці багатошляхові архітектури, які ви знаєте, материнські плати, колись ви могли робити лише в одному напрямку: назад і вперед. Як і в дні з обчисленнями Cray та деякими конструкціями суперкомп'ютерів того часу, і тепер у настільних комп’ютерах та звичайних позаштатних, таких, настільних ПК, що встановлюються в стійку, адже справді більшість сучасних Тепер ПК пройшов цю епоху настільних, середніх, мікро настільних комп'ютерів, і ми повернули їх у сервери.
І багато з цих можливостей суперкомп'ютерів, такого дизайну класу суперкомп'ютерів, ввійшли в загальні нестандартні компоненти. Ви знаєте, в наші дні ідея взяти дуже дешеві комп'ютери, встановлені на стійці, і поставити їх у стійки на сотні, якщо не тисячі, і запустити на них програмне забезпечення з відкритим кодом, як Linux, і розгорнути на ньому подібні SAP HANA, ви знайте, ми часто сприймаємо це як належне. Але це дуже нова захоплююча річ, і вона має свої складності.
Програмне забезпечення також покращилося, зокрема управління пам'яттю та розділення даних. Я не буду вносити багато деталей з цього приводу, але якщо ви подивитеся на великий зсув за останні 15 років або навіть менше, як керується пам'яттю, зокрема, дані в оперативній пам’яті та як дані розподіляються в оперативній пам'яті, так що, як вказував доктор Робін Блур раніше або на що на нього згадували, ви можете знати, що речі можуть читати і писати одночасно, не впливаючи один на одного, а не мати часу очікування. Дуже багато потужних функцій, таких як стиснення та шифрування на мікросхемі. Шифрування стає важливішою справою, і нам не обов’язково робити це в програмному забезпеченні, в оперативній пам’яті, в просторі процесора, тепер це відбувається насправді на чіпі. Це значно прискорює справи. І розподілене зберігання та обробка даних, знову ж таки, те, що ми колись припускали, - це суперкомп'ютери та паралельна обробка, ми зараз сприймаємо це як належне в просторі подібних SAP HANA та Hadoop та Spark тощо.
Отже, вся суть у тому, що це високоефективні обчислення, можливості HPC прийшли на підприємство, і тепер підприємство користується вигодами, які приносяться цим у покращенні продуктивності та технологічному просторі, технічних вигодах та комерційній вигоді, тому що, знаєте, скорочений час до значення різко знижується.
Але я використовую цей образ історії, яку я прочитав деякий час тому про джентльмена, який створив корпус ПК із Лего, тому що це завжди спадає на думку, коли я думаю про деякі з цих речей. І це те, що здається чудовою ідеєю в той час, коли ви починаєте її будувати, а потім ви переходите на півдорозі і розумієте, що насправді дуже складно зібрати всі шматочки Lego і зробити міцну річ, достатньо міцну щоб поставити материнську плату тощо, це створить корпус для персонального комп'ютера. І зрештою ви розумієте, що всі шматочки не злипаються правильно, і вам потрібно бути трохи обережними, які маленькі шматочки ви злипаєте, щоб зробити їх міцними. І це дуже мила ідея, але це дзвінок, коли ви проходите на півдорозі і розумієте: "Хм, я, мабуть, я просто купив чохол для ПК на 300 доларів, але я закінчу його зараз і щось з нього навчуся".
Для мене це чудова аналогія того, як хочеться створити ці дуже складні платформи, тому що це все добре і добре створити її і створити середовище, де у вас є маршрутизатори та комутатори, сервери та стійки. І у вас об’єднані центральні процесори, оперативна пам’ять та операційна система. І ви поставите щось подібне до HANA над цим для розподіленої обробки пам’яті та зберігання даних та управління даними. Ви будуєте стек SAP поверх цього, отримуєте можливості бази даних, а потім завантажуєте свої дані та свою ділову логіку, і ви починаєте застосовувати деякі читання, записи та запити тощо. Ви повинні бути в курсі вводу-виводу, і вам потрібно планувати речі, керувати робочими навантаженнями та багатосторонньою діяльністю тощо. Цей стек стає дуже складним, дуже швидко. Це складний стек сам по собі, якщо він знаходиться лише на одній машині. Помножимо, що на 16 або 32 машини виходить дуже, дуже нетривіально. Коли ви помножите на сотні і, в кінцевому рахунку, тисячі машин, щоб перейти від 100 терабайт до петабайтної шкали, це страхітливе поняття, і це реалії, з якими ми зараз маємо справу.
Отже, ви закінчите пару речей, які також допомогли змінити цей світ, а це те, що дисковий простір став смішно дешевим. Знаєте, колись ви витрачали від 380 до 400 тисяч доларів на гігабайт жорсткого диска, коли це був величезний барабан розміром з - щось, що знадобилося навантажувачу, щоб забрати його. Цього дня знижується, на зразок, один-два центи за гігабайт товарного дискового простору. І оперативна пам’ять зробила те саме. Між іншим, ці два J-криві в обох цих графах - це десятиліття, тож іншими словами ми розглядаємо два блоки за 10 років, за 20 років зниження цін. Але я розбив їх на дві J-криві, оскільки врешті-решт той, що праворуч, просто став пунктирною лінією, і ти не міг побачити деталі, тому я повторно змінив її. Гігабайт оперативної пам’яті 20 років тому становив щось близько шести з половиною мільйонів доларів. Ці дні, якщо ви платите більше трьох-чотирьох доларів за гігабайт оперативної пам’яті за товарне обладнання, яке вас обікрали.
Це значне падіння зниження цін протягом останніх двох десятиліть означало, що тепер ми можемо вийти за межі дискового простору і прямо в оперативну пам’ять, не тільки на мегабайтному рівні, але тепер і на терабайтному рівні, і обробляти оперативну пам’ять як дискову. Завданням у цьому було те, що оперативна пам'ять була ефемерно ефемерною - це означає, що триває короткий проміжок часу - тому нам довелося придумати способи забезпечення стійкості в цьому просторі.
І тому, моя думка тут полягає в тому, що обчислення в пам'яті не для слабких людей. Жонглювання цих дуже масштабних даних в пам'яті та обробка їх навколо - цікавий виклик; як я вже говорив раніше, це не для слабких людей. Отже, одне, що ми дізналися з цього досвіду з широкомасштабними обчисленнями в пам’яті з високою щільністю, полягає в тому, що складність, яку ми будуємо, починає ризикувати в ряді областей.
Але давайте розглянемо це з точки зору моніторингу та реагування. Коли ми думаємо про дані, вони починаються в дисковому просторі, вони сидять в базах даних на дисках, ми підштовхуємо їх до пам'яті. Після того, як вона буде в пам'яті та розповсюджена, і є її копії, ми можемо використовувати безліч її копій, і якщо будь-які зміни будуть внесені, це може бути відображено на рівні пам'яті, замість того, щоб продовжувати і вимикати, і на задній площині в два різні рівні, це йде в пам'ять і виходить з неї. Ми закінчили цю апаратну платформу з високим масштабом, яка дозволяє нам це робити зараз. Коли ми говоримо про гіпермасштабування, це важче на смішно щільних рівнях і дуже високій щільності пам'яті, дуже високій кількості щільності процесорів, ядер і ниток. Зараз у нас є дуже складні мережеві патології для того, щоб це підтримати, оскільки дані повинні рухатися по мережі в певний момент, якщо вони будуть проходити між вузлами та кластерами.
Отже, ми закінчуємо те, що надмірність несправностей пристрою стає проблемою, і ми повинні контролювати пристрої та їх частини. У нас повинна бути вбудована надбудова помилок даних у цю платформу та відстежувати її. У нас має бути вбудована стійкість розподіленої бази даних, щоб нам слідкувати за платформою бази даних та утримуватися всередині неї. Ми повинні відслідковувати розподілене планування обробки, що відбувається в деяких процесах аж до опитування та запиту, і шлях, який проходить запит, і за способом структурування та виконання запиту. Як це виглядає, чи хтось зробив SELECT * на "бла", чи вони насправді зробили дуже розумний та добре структурований запит, який повинен отримати їм номінальний мінімальний об'єм даних, що надходить по архітектурі на задній план? У нас є багатонаціональне навантаження, кілька користувачів і декілька груп, які виконують одне і те ж чи кілька робочих навантажень, пакетні завдання та графіки в режимі реального часу. І ми отримали цю суміш пакетної та реальної обробки часу. Деякі речі працюють просто регулярно - щогодини, щодня, щотижня або щомісяця - інші - за запитом. Хтось може сидіти там за планшетом, який хоче зробити звіт у реальному часі.
І знову ми доходимо до всього цього, що складнощі, які виникають у них, є не просто викликом зараз, а досить лякають. І ми маємо цю перевірку реальності, що одне питання ефективності, лише одне питання щодо ефективності, може вплинути на всю екосистему. І ось, ми закінчуємо цей дуже цікавий виклик з’ясувати, ну, де такі наслідки? І ми маємо це завдання, чи реагуємо ми, чи є активними? Ми спостерігаємо за річчю в режимі реального часу і бачимо, що щось іде «на удар» і реагує на нього? Або ми бачили якусь форму тенденції і зрозуміли, що нам потрібно проактивно вступати в неї? Тому що ключовим є те, що кожен хоче чогось швидкого, дешевого та легкого. Але ми закінчуємо ці сценарії, до яких я люблю посилатися, і моя улюблена лінія загадки Дональда Рамсфельда - яка, на мій погляд, застосовується у всіх цих сценаріях з високою складністю - і це те, що ми знаємо, що це знає, тому що це щось ми розробили і побудували, і це працює як планувалося Нам відомі невідомі в тому, що ми не знаємо, хто працює, що, коли і де, якщо це потрібно. І у нас з'явилися невідомі невідомі. Це те, що нам потрібно стежити і перевіряти. Тому що насправді ми знаємо, що ти не можеш керувати чимось, чого не можеш виміряти.
Отже, щоб мати правильні інструменти та правильну можливість контролювати планування нашого процесора, шукайте строки очікування та з’ясовуйте, чому потрібно чекати в чергових чергах у конвеєрах. Що відбувається в пам’яті, яка утилізація виконується, яку ефективність ми отримуємо з пам’яті? Чи правильно розміщений матеріал, чи він розповсюджується, чи достатньо у нас вузлів, що містять його копії, щоб впоратися з навантаженнями, які на нього кидаються? Що відбувається з виконанням процесів далеко від процесів операційної системи? Самі робочі завдання, окремі додатки та демони, що їх підтримують? Що відбувається в цих процесах, зокрема, структурування запитів і як ці запити виконуються та складаються? І здоров'я цих процесів виходить у стеці? Ви знаєте, знову ж таки, повернення до часу очікування, чи правильно розкладено графік, чи потрібно чекати, де він чекає, чи чекає читання пам'яті, введення / виведення, процесор, введення / виведення через мережу до кінцевого користувача ?
А потім повернусь до того моменту, що я лише згадав перед тим, як завершити роботу, і це те, як ми підходимо до вирішення питання та часу відповіді на них? Ми спостерігаємо в режимі реального часу і чи реагуємо на речі, що є найменш ідеальним сценарієм, але навіть тоді, ми краще це робимо, ніж не знаємо, і зателефонуємо у службу довідки і скажемо, що щось пішло не так, і ми повинні відстежити це ? Або ми робимо це проактивно і дивимося, що йде на лінію? Інакше кажучи, чи ми бачимо, що у нас не вистачає пам’яті та нам потрібно додати більше вузлів? Ми робимо аналіз трендів, чи плануємо ми спроможність? І в усьому цьому ми спостерігаємо за історичними часами виконання та думаємо про планування потужностей чи спостерігаємо за ним у режимі реального часу та проактивним переплануванням та врівноваженням навантаження? І чи ми в курсі навантажень, які працюють в першу чергу? Ми знаємо, хто робить що в нашому кластері і чому?
Обчислення в пам'яті дуже потужні, але з цією потужністю це майже одна з таких речей, як, наприклад, завантажений пістолет, і ви граєте з боєприпасами. Зрештою ви можете стріляти собі в ногу, якщо не будете обережні. Отже, ця потужність обчислення в пам'яті просто означає, що ми можемо працювати набагато більше і швидше в дуже розподілених і дискретних наборах даних. Але тоді це викликає більш високий попит з боку кінцевих споживачів. Вони звикають до цієї сили і цього хочуть. Вони більше не сподіваються, що робочі місця потребують тижнів, а звіти з’являються на звичайній старій папері. І тоді, під усім цим, у нас є щоденне обслуговування, обведене навколо виправлення, оновлення та оновлення. І якщо ви думаєте про цілодобову обробку за допомогою обчислення в пам'яті, управління цими даними, управління навантаженнями через неї, це все в пам'яті, технічно на ефемерній платформі, якщо ми розпочнемо застосовувати патчі та оновлення та оновлення в там, що поставляється і з цілим рядом інших проблем управління та моніторингу. Нам потрібно знати, що ми можемо робити в режимі офлайн, коли ми можемо оновити його та коли повернемо його в Інтернет. І це підводить мене до моєї остаточної точки зору, і це те, що в міру набуття все більшої складності в цих системах людина не може зробити лише просмоктуючи великий палець і потягнувши за вухо. Більше немає таких підходів, як відчуття кишок. Нам дійсно потрібні відповідні інструменти для управління та забезпечення цього високого рівня продуктивності в обчисленні та управлінні даними.
І маючи це на увазі, я збираюся передати нашому другу від IDERA і почути, як вони підійшли до цього виклику.
Білл Елліс: Дуже дякую. Я ділюсь своїм екраном і ось ми йдемо. Отож, насправді дуже привабливо розглянути всю технологію та всіх людей, які прийшли до нас, щоб зробити цей матеріал доступним у 2017 році. Ми будемо говорити про аналіз завантаженості для SAP HANA - в основному, рішення для моніторингу баз даних: всеохоплююче, без агентів, забезпечує реальний час і створює історію, і таким чином ви можете бачити, що сталося в минулому. SAP S / 4 HANA пропонує потенціал кращого, швидшого та дешевшого. Я не кажу, що це недорого, я просто кажу, що він дешевший. Традиційно, що трапилось, це те, що у вас буде головний виробничий екземпляр - ймовірно, що ви працюєте на Oracle у більшій крамниці, потенційно SQL Server - і тоді ви будете використовувати цей процес ETL і у вас буде кілька, різновид, версій правди . І це дуже дорого, оскільки ви платили за апаратне забезпечення, операційну систему, ліцензію Oracle за кожне з цих окремих середовищ. І тоді, крім того, вам потрібно було б мати людей, щоб узгодити одну версію істини з наступною версією правди. Отже, ця багатоверсійна обробка ETL була просто повільною і дуже, дуже громіздкою.
Отже, HANA, в основному один екземпляр HANA, може потенційно замінити всі ці інші випадки. Отже, він дешевший, оскільки це одна апаратна платформа, одна операційна система, а не кілька. І тому S / 4 HANA, насправді, це все змінює, і ви, в основному, дивитесь на еволюцію SAP від R / 2 до R / 3, різні пакети вдосконалення. Тепер застаріла система доступна до 2025 року, тому у вас є вісім років, поки ви дійсно не змушені мігрувати.Хоча ми бачимо людей, що вони впираються пальцями у це, тому що вони знають, що це прийде, і врешті-решт, ECC працює на HANA, тож вам потрібно бути готовим до цього і розуміти технологію.
Отже, одна база даних, ніяких процесів ETL, жодних копій, які потрібно узгодити. Отже, ще раз, швидше, краще і дешевше. HANA - це пам'ять. SAP постачає програмне забезпечення, ви постачаєте обладнання. Немає сукупних таблиць. Одне з речей, яке вони, начебто, підказують, коли ви думаєте про це, це те, що ви не хочете вникати в це, ми просто збираємося придбати наймасштабніший доступний сервер. Вони пропонують, що ви, начебто, достроково розміщуєте свій ландшафт SAP достроково, і вони, по суті, говорять, не мігруйте дані, що варті 20 років. Я думаю, що архівація - це те, що недостатньо використовується в ІТ-сферах, як у всьому світі, а не тільки в магазинах SAP. Отже, наступне - SAP фактично витратив багато часу на перезапис свого рідного коду, щоб не використовувати SELECT *. SELECT * повертає всі стовпці з таблиці, і це особливо дорого в стовпчиковій базі даних. І так, це не дуже гарна ідея для SAP HANA. Отже, для магазинів, які мають багато налаштувань, багато звітів, це те, що ви хочете шукати, і вам потрібно вказати назви стовпців під час переходу до HANA.
Ми хочемо сказати, що HANA - це не панацея. Як і всі бази даних, всі технології, її потрібно контролювати, і, як згадувалося раніше, вам потрібні цифри для управління надлишком, вимірювання за допомогою вимірювання. І одна з речей, про яку я говорю в області IDERA, - це те, що кожна бізнес-транзакція взаємодіє із системою запису, і в цьому випадку це буде HANA. Таким чином, HANA стає основою для здійснення ваших трансакцій SAP, досвід кінцевого користувача. І так, дуже важливо, щоб він продовжував працювати з максимальною швидкістю. Це стає єдиною точкою невдач, і в розмові з людьми, це те, що може з’явитися там, де у вас є кінцевий користувач, і, можливо, використовується ці дані в реальному часі, і у них є спеціальний запит, який потенційно не зовсім правильно. Можливо, вони не приєднуються до таблиць, і вони створили зовнішнє з'єднання, партійний продукт, і вони в основному споживають багато ресурсів. Тепер, HANA визнає це врешті-решт і вб'є цей сеанс. І тому є найважливіша частина нашої архітектури, яка дозволить вам фактично зафіксувати це в історії, щоб ви могли бачити, що відбувалося в минулому, і розпізнавати ці ситуації.
Отже, давайте подивимось на аналіз навантаження для SAP HANA. Це версія 1, тому ми дуже запрошуємо приєднатися до нас у подорожі, і це продукт від IDERA. Це всеосяжно, але просто. В режимі реального часу з трендом. Здоров'я хазяїна, наприклад здоров'я. Ми відстежуємо стан очікування, запити SQL, споживачі пам'яті та послуги. Отже, так виглядає графічний інтерфейс, і ви можете бачити відразу, що він увімкнено в Інтернеті. Я фактично відкрив це рішення, що працює в моїй системі. Є кілька важливих речей, які ви хочете подивитися. Ми як би поділилися на різні робочі простори. Найважливішим є те, що відбувається на рівні хосту від використання процесора та використання пам'яті. Ви точно не хочете дістатися до точки зону заміни або обміну. А потім ви в основному працюєте над тим, що відбувається в тренді, починаючи з часу відгуку, користувачів, SQL-висловлювань, тобто того, що рухає активністю в системі.
Одне з IDERA - це те, що, знаєте, у базі даних нічого не відбувається, поки не буде активності. І ця діяльність - це заяви SQL, які надходять із програми. Отже, вимірювання операторів SQL є абсолютно важливим для того, щоб мати можливість виявити першопричину. Отже, давайте продовжимо і детальніше. Отже, на рівні хоста ми можемо реально переглянути пам'ять, відстежувати час, використання процесорного хосту. Крок назад, ви можете переглянути оператори COBSQL. Тепер одна з речей, яку ви збираєтеся побачити в нашій архітектурній частині, - це те, що ця інформація зберігається поза HANA, тож якщо з HANA щось трапилося, ми в основному збираємо інформацію аж до, не дай Бог, ситуації з недоступністю. . Ми також можемо зафіксувати все, що відбувається в системі, щоб ви мали чітку видимість. І однією з речей, яку ми збираємось робити, є те, що ми будемо представляти оператори SQL у зваженому порядку. Отже, це враховує кількість страт, і це сукупне споживання ресурсів.
І отже, ви можете потрапити сюди до окремих показників - коли виконується ця операція SQL? І тоді споживання ресурсів значною мірою визначається планом виконання, і тому ми можемо фіксувати це на постійній основі. HANA - це пам'ять. Це дуже паралельно. На кожній таблиці є первинні індекси, які деякі магазини вирішують створити вторинний індекс для вирішення певних проблем ефективності. І, от, знаючи, що сталося з планом виконання певних операторів SQL, може бути дуже цінним. Ми також розглянемо послуги, споживання пам’яті ще раз, зафіксовані в часі. Архітектура: отже, це автономне рішення, яке ви можете завантажити з нашого веб-сайту, а архітектура полягає в тому, що його ввімкнено в Інтернеті.
Ви можете мати декілька користувачів, які підключаються до певного екземпляра. Ви можете відстежувати місцеві випадки використання SAP HANA. І ми зберігаємо постійну чотиритижневу історію в нашому сховищі, і це самостійно. Розгорнути це досить просто. Вам потрібен сервер Windows. Вам потрібно завантажити його. Більшість серверів Windows матимуть вбудовану систему .NET, і вона постачається в комплекті з ліцензією. Отже, ви перейдете до майстра встановлення, який керує Setup.exe, і він фактично відкриє екран, ліцензійну угоду, і ви просто працюєте внизу цього контуру, натиснувши «Далі». І так, куди б ви хотіли HANA буде встановлено? Далі - властивості бази даних, і це буде вашим підключенням до SAP HANA, тож це без агентурний моніторинг екземпляра HANA. І тоді ми в основному надамо попередній перегляд, це порт, з яким ми спілкуємося за замовчуванням. Клацніть «Встановити», і в основному запускається HANA, і ви починаєте створювати історію. Отже, лише трохи інформації про діаграму розміру. Ми можемо відстежувати до 45 екземплярів HANA, і ви хочете скористатися цим видом у розсувному масштабі, щоб визначити кількість ядер, пам'ять, дисковий простір, який вам знадобиться. І це передбачає, що у вас є повна чотиритижнева історія прокатки.
Тож, як швидкий підсумок, ми дивимось на стан сервера, стан здоров'я, використання процесора / пам'яті. Що таке споживачі пам'яті, які драйвери активності, які послуги? Оператори SQL є життєво важливими - які стани виконання? Покажіть мені плани виконання, коли речі виконувались, надавали тенденцію? Це допоможе вам отримати в реальному часі та історію того, що сталося. І як я вже згадував, оскільки наша історія є окремою від HANA, ми збираємось захоплювати речі, які вичерпалися та вийшли з історії HANA. Так що ви можете бачити справжнє споживання ресурсів у вашій системі через окрему історію.
Отже, як я вже згадував, на веб-сайті IDERA в розділі Продукти це можна легко знайти. Якщо ви хочете спробувати це, ви неодмінно вітати. Подивіться, як вона надає інформацію для вас, і чи є додаткова інформація на цьому веб-сайті. Тож будь-які зацікавлені сторони із задоволенням беруться за справу. Тепер у портфельних продуктах, що пропонуються IDERA, також є монітор транзакцій SAP ECC, і це називається Precision for SAP. І те, що це робить - чи ви користуєтесь порталом, чи просто ECC прямого контенту - це фактично фіксує транзакцію кінцевого користувача від клацання до диска, аж до оператора SQL і показує вам, що відбувається.
Зараз я показую вам лише один підсумковий екран. З цього підсумкового екрану я хочу, щоб ви взяли кілька заходів. Це час відгуку на вісь Y, час осі X плюс день, і в цьому перегляді транзакції ми покажемо вам час клієнта, час черги, час коду ABAP, час бази даних. Ми можемо фіксувати ідентифікатори кінцевих користувачів, T-коди, а ви можете фактично фільтрувати та показувати сервери за допомогою певної транзакції, що проходить. І тому багато магазинів працюють під передньою частиною пейзажу під VMware, тож ви можете фактично виміряти, що відбувається на кожному з серверів, і отримати детальний аналіз. Отже, цей вид транзакції призначений для транзакції для кінцевого користувача через весь пейзаж SAP. І ви можете знайти це на нашому веб-сайті в розділі Продукти APM Tools, і це було б рішення SAP, яке ми маємо. Установка для цього трохи складніша, тому її не просто завантажувати та спробувати, як у нас для HANA. Це те, де ми би працювали разом, щоб зробити, розробити та реалізувати загальну для вас транзакцію.
Отже, лише третя швидка резюме, аналіз завантаженості для SAP HANA, це всеосяжний, без агентурний режим у реальному часі, пропонує історію. Ми пропонуємо можливість завантажити та спробувати його для вашого сайту.
Отже, з цим я поверну час назад до Еріка, Деза та доктора Блура.
Ерік Кавана: Так, можливо, Робін, якісь питання у вас, а потім Дез за Робіном?
Доктор Робін Блер: Добре. Я маю на увазі, перше, що я хотів би сказати, - це мені дуже подобається перегляд транзакцій, тому що це саме те, що я хотів би в цій ситуації. Я багато працював - ну, це було дуже давно зараз - робив моніторинг ефективності, і це було таке; у нас не було графіки в ті часи, але саме це я особливо хотів зробити. Так що ви можете, так чи інакше, вводити себе куди завгодно, де проблема.
Перше питання, яке у мене виникло, це, ви знаєте, більшість людей так чи інакше реалізують S / 4. Коли ви вступаєте в будь-яку реалізацію S / 4, чи виявили ви, що вона була впроваджена добре, чи ви, нарешті, знаєте, що може виявити речі, які можуть змусити клієнта змінити налаштування? Я маю на увазі, як все це йде?
Білл Елліс: Що ж, кожен магазин трохи інший. І існують різні моделі використання, є різні звіти. Для сайтів, які мають спеціальні звіти, я маю на увазі, що це фактично, як-небудь, підстановочна карта в системі. І так, одне з найважливіших речей - почати вимірювання та з’ясувати, що є базовою лінією, що нормально для певного сайту, де цей конкретний сайт, виходячи з моделей їх використання, підкреслюючи систему. А потім внесіть корективи звідти. Зазвичай оптимізація моніторингу не є одноразовою, це дійсно тривала практика, коли ви відстежуєте, налаштовуєте, налаштовуєте, покращуючи систему для кращої спільноти кінцевих користувачів, щоб мати можливість більш ефективно обслуговувати бізнес.
Доктор Робін Блер: Добре, тож коли ви реалізуєте - я маю на увазі, я знаю, що на це складний питання відповісти, оскільки він буде змінюватися залежно від розміру впровадження - але скільки ресурсів має можливість моніторингу IDERA, скільки вона споживає? Чи має це щось значення, чи це просто не втручається? Як це працює?
Білл Елліс: Так, я б сказав, що накладні витрати становлять приблизно 1–3 відсотки. Багато магазинів дуже готові пожертвувати цим, оскільки, можливо, ви зможете придбати його назад в плані оптимізації. Це залежить від моделей використання. Якщо ви робите повний пейзаж, це залежить від окремих технологій, які контролюються. Отже, пробіг різниться різним, але, як ми говорили, напевно краще витратити трохи, щоб знати, що відбувається, ніж просто осліпнути. Особливо це було б, ви знаєте, ось ми в січні, і ви переходите до обробки вдруге, і ви збираєте дані, варті 12 місяців. Ви знаєте, що досягнення ефективності, отримання звітів перед регулюючими організаціями, банками та акціонерами є надзвичайно важливим для важливих результатів бізнесу.
Доктор Робін Блер: Правильно. І лише швидко, з вашого погляду, - адже я думаю, ви там займаєтесь цілою низкою сайтів SAP - наскільки великий рух клієнтської бази SAP у напрямку S / 4? Я маю на увазі, це те, що відбувається, ви знаєте, що для цього йде якась лавина захоплених клієнтів, чи це просто невпинна струмка? Як ви це бачите?
Білл Елліс: Думаю, пару років тому я б сказав, що це пальчик ноги. Тепер я б сказав, що люди, наче, до коліна. Я думаю, що, знаєте, враховуючи часовий графік, люди дійсно будуть занурені в HANA протягом наступних двох років. І тому моніторинг, трансформація, ви знаєте, я думаю, що більшість клієнтів, начебто, на кривій навчання разом. І тому я думаю, що ми не зовсім на лавині, як ви заявляли, але я думаю, що ми знаходимося в результаті великої трансформації HANA.
Доктор Робін Блер: Гаразд, так що з точки зору сайтів, які ви бачили, що це було зроблено, вони також адаптують HANA для інших додатків, або вони, так чи інакше, є такими, що повністю споживаються для того, щоб цей матеріал працював? Яка картинка там?
Білл Елліс: Так, часто люди інтегруватимуть SAP з іншими системами, залежно від модулів тощо, тому є небагато. Наразі я ще не бачу людей, які розгортають інші програми на HANA. Це, безумовно, можна зробити. І так це більше навколо ландшафту навколо інфраструктури SAP.
Доктор Робін Блер: Думаю, я краще віддам вас Dez. Я твій час зависав. Дез?
Dez Blanchfield: Дякую. Ні, це все добре. Дві дуже швидкі, просто намагаючись задати тему. SAP HANA існує вже пару років, і люди мали шанс розглянути це. Якщо ви мали б дати нам приблизну оцінку відсотка людей, які ним керують - адже там багато людей, які керують цим матеріалом - як ви думаєте, наскільки відсоток ринку, про який ви знаєте, на даний момент пішов від просто традиційних реалізацій SAP до SAP на HANA? Ми дивимось на 50/50, 30/70? Який відсоток ринку ви бачите на людей, які перейшли та зробили цей крок, порівняно з людьми, які просто стримують і чекають, коли покращиться, покращиться або зміниться, або в будь-якому випадку?
Білл Елліс: Так, я б, власне кажучи, ставлю відсоток близько 20 відсотків. SAP, як правило, традиційний бізнес. Люди, як правило, дуже консервативні, і тому їх люди будуть тягнути ноги. Я думаю, це також залежить від того, ви знаєте, чи довго ви керуєте SAP, чи ви такий собі SMB, який, можливо, нещодавно розгорнув SAP? І так, існує ряд факторів, але в цілому я не думаю, що відсоток становить 50/50. Я б сказав, що 50 відсотків принаймні непросто і HANA працює десь у своєму центрі обробки даних.
Dez Blanchfield: Цікавим виводом, який ви давали нам раніше, було те, що це є фактом, що відповідає дійсності, і що годинник фізично і буквально тикає на час переходу.Як ви думаєте, в процесі цього ви думаєте, що люди це вважали? Яке загальне розуміння народного розуміння того, що це перехідна зміна платформи, це не лише варіант, це стає дефолтом?
І з точки зору SAP, я впевнений, що вони так намагаються, оскільки є значна конкурентна перевага в продуктивності, але, мабуть, вони також борються за управління платформою замість того, щоб перейти на третій- партійна база даних, тепер вони повертають її на власну платформу. Як ви думаєте, компанії насправді цього отримали? Як ви думаєте, люди це розуміють і зараз це ведуть до цього? Або це, як і раніше, незрозуміла річ, як ви думаєте, на ринку?
Білл Елліс: Я не думаю, що SAP не соромляться спілкування, і люди, які пішли до САПФІРУ, бачили HANA всюди. Отже, я думаю, що люди це добре знають, але людська природа є такою, якою вона є, ви знаєте, деякі люди є, начебто, трохи перетягуючи ноги.
Dez Blanchfield: Тому що я думаю, що я задав це питання, і вам доведеться пробачити мені, але я згоден. Я думаю, що вони не соромилися цього спілкуватися. Я думаю, що сигнал багато в чому вийшов І я з вами згоден - я не знаю, що всі ще стрибали. Ви знаєте, традиційні підприємства, дуже великі підприємства, які керують цим, все ще багато в чому не дуже тягнуть ноги, а просто намагаються зрозуміти складність зміни. Тому що я думаю, що одне, що вирішив ваш інструмент, і, безумовно, ваша демонстрація сьогодні, і для мене одним ключовим захопленням, я хотів би, щоб усі слухали і налаштовувались сьогодні, щоб сісти і обмірковувати увагу - це у вас є Інструмент тепер спростив цей процес. Я думаю, що в них є дуже багато нервових керівників та їхніх команд, які думають: «Як зробити перехід від традиційних RDBMS, реляційних систем управління базами даних, які ми знаємо десятиліттями, до цілком нової парадигми обчислень та управління пам’яттю в просторі, який досі є досить сміливим? ”на мою думку. Але це багато в чому невідомо, і дуже мало людей зробили цю зміну в інших областях, це не так, як у них є інший розділ бізнесу, який вже перейшов на обчислення пам'яті. Таким чином, це все, або нічого в їхньому розумі.
Отож, одне з речей, що я більше всього відібрав у цьому - я збираюся вразити вас питанням за хвилину - це страх зараз, я думаю, багато в чому перебуває і що до сьогодні, якби я слухав CIO, я б начебто подумав: «Ну як я зроблю цей перехід? Як я можу гарантувати ту саму здатність, яку ми отримали на платформі управління реляційними базами даних та багаторічний досвід роботи DBA, на нову платформу, в якій ми зараз не маємо навичок? "Отже, моє запитання з цього питання є , чи вважаєте ви, що люди зрозуміли, що інструменти є зараз із тим, що ви пропонуєте, і що вони можуть, начебто, зробити глибокий вдих і зітхнути з полегшенням, що перехід не такий страшний, як це було раніше доступний цей інструмент? Чи вважаєте ви, що люди зрозуміли це чи все-таки щось таке, що вони просто стикаються з переходом на обчислення в пам'яті та на зберігання в пам'яті порівняно зі старими комбінаціями NVMe, флеш-диску та диска?
Білл Елліс: Так, так що, безсумнівно, існує багато технологій та інструментів, які можуть графічно відобразити це, що відбувається, і зробити це дуже легко визначити топ-споживачів ресурсів. Я маю на увазі, це допомагає спростити речі, і це допомагає співробітникам технологій справді добре впоратися. Гей, вони зможуть дізнатися, що відбувається, і зможуть зрозуміти всю складність. Тож абсолютно інструменти на ринку безумовно корисні, тому ми пропонуємо аналіз завантаженості для SAP HANA.
Dez Blanchfield: Так, я думаю, що чудова річ у тому, що ви нам показали сьогодні, - це те, що під час моніторингу апаратної частини, частини операційної системи, навіть моніторингу деякого робочого навантаження, що рухається, як ви сказали, я маю на увазі, інструменти були там протягом деякого часу. Біль для мене, особливо у подібних до HANA, полягає в тому, що ми не обов'язково мали змогу дістати збільшувальне скло і зазирнути в нього, і зрозуміти, що саме робить ваш інструмент із тим, що відбувається з запитами та як вони структурований і де це навантаження.
З розгортанням, яке ви бачили досі, враховуючи, що ви буквально найавторитетніший у цьому просторі на своїй платформі у світі, деякі швидкі виграші, які ви бачили - чи маєте ви якісь анекдотичні знання, якими ви можете поділитися. нас навколо деяких моментів еврики, ага моментів, коли люди розгорнули набір інструментів IDERA, вони знайшли речі, про які вони просто не були обізнані, були у своїх платформах та виступах, які вони мали. Чи є у вас чудові анекдотичні приклади того, де люди просто розгорнули його, не знаючи, що вони там, і раптом пішли: "О, ми насправді не знали, що там було?"
Білл Елліс: Так, настільки велике обмеження натільних інструментів полягає в тому, що якщо скасувати відхилений запит, він видає інформацію, і, таким чином, у вас немає історії. Ми зберігаємо історію в режимі офлайн, як уникнутий запит, у вас буде історія, ви будете знати, що сталося, ви зможете побачити план виконання тощо. І так, що дозволяє, начебто, допомагати кінцевій спільноті користувачів в основному краще працювати, краще писати звіти, тощо. І так, історія - це щось приємне. І одна з речей, яку я мав на меті показати, - це те, що ви можете подивитися в режимі реального часу до чотирьох тижнів, а потім можете легко збільшити масштаб на будь-який цікавий часовий проміжок, і тоді ви можете розкрити основні рушійні дії. Просто мати таку видимість - це дуже корисне знання того, що виникло вузьке місце.
Dez Blanchfield: Ви згадали, що він багатокористувацький, як тільки він розгорнувся, і мене дуже вразило те, що він без агента і ефективно нульовий дотик багато в чому. Чи нормально для одного розгортання вашого інструменту потім бути доступним для всіх з мережевих операційних центрів у НОК, які переглядають основну інфраструктуру, що лежить в основі кластера, аж до команди програм та розробників? Це норма, і ви розміщуєте один раз, і вони поділять це, чи ви гадаєте, що у людей можуть бути екземпляри моделей, які дивляться на різні частини стека? Як це виглядає?
Білл Елліс: Отже, базовий колектив, як правило, буде дуже сильно зацікавлений у технології, що лежить в основі того, що відбувається в SAP. Очевидно, є кілька команд, які підтримуватимуть цілі пейзажі. Частина HANA саме зосереджена на цьому. Я просто збираюся за замовчуванням для команди SAP як основного споживача інформації.
Dez Blanchfield: Правильно. Мене вражає те, що якщо у мене є команда розробників або навіть не просто на рівні коду, але якщо у мене є команда науковців даних або аналітиків, які виконують аналітичну роботу над наборами даних там, особливо зважаючи на те, що там Суттєвий поштовх до наукових даних, що застосовується до всього, що знаходиться всередині організацій зараз, на мій погляд - і виправте мене, якщо я помиляюся - мені здається, що це також буде цікаво і для них, адже багато в чому це з серйозних речей, які ви можете зробити в середовищі сховища даних, це розкрити науковця даних і дозволити йому просто почати робити спеціальні запити. Чи були у вас приклади такого роду випадків, коли магазини зателефонували вам і сказали: «Ми кинули команду наукових даних на річ, це дійсно боляче, що ми можемо зробити для них порівняно з тим, що ми робимо традиційний оперативний моніторинг та управління? "Це навіть річ?
Білл Елліс: Ну так, я хотів би трохи перетворити це і вирізати мою відповідь - це, дивлячись на продуктивність, усвідомлюючи ефективність у розвитку виробництва QA, знаєте, чим раніше ви будете зберігати, тим менше проблем, тим менше сюрпризів . Отже, абсолютно.
Dez Blanchfield: Виходячи з цього, багато інструментів, з якими я мав досвід - і я впевнений, що Робін погодиться - багато інструментів тут, якщо у вас є великий RDBMS, вам потрібні справді висококваліфіковані, глибоко досвідчені, досвідчені DBA. Деякі вимоги до інфраструктури та платформи, які виникають із SAP HANA, оскільки він на даний момент підтримується на конкретних дистрибутивах, залежно від конкретного обладнання та інше, наскільки мені відомо. Знаєте, є люди з десятилітнім досвідом, які не однакові. Однак я бачу, що це необов’язково вимога цього інструменту. Мені здається, що ви можете розгорнути свій інструмент і надати його досить новим обличчям і дати їм сили відразу знайти речі, які не працюють добре. Чи буває так, що існує досить коротка крива навчання, щоб досягти швидкості з цим і отримати деяку цінність від його розгортання? Ви знаєте, моє загальне розуміння полягає в тому, що вам не потрібно мати 20 років досвіду керування інструментом, щоб негайно побачити цінність. Чи погоджуєтесь ви так?
Білл Елліс: Ну абсолютно, і на ваш погляд, я думаю, що багато успіху розгортання дійсно залежить від планування та архітектури середовища SAP HANA. І тоді, безсумнівно, є багато складності, багато технологій, на якій вона вбудована, але тоді вона зводиться лише до моніторингу моделей використання того, що відбувається. Тож хоч і складніше, але певний спосіб упакований і дещо спрощений. Це дуже погано
Dez Blanchfield: Так, перш ніж повернутись до Еріка, тому що я знаю, що у нього є кілька запитань, зокрема, з питань, які надходять через запитання, які виглядають цікавими, і я хочу почути відповідь. Традиційна подорож для когось - ви раніше згадували, що можете її отримати, можете завантажити і спробувати. Чи можете ви просто скористатись цим швидко для прослуховування народних альбо сьогодні, або для людей, які могли б повторити його пізніше? Які швидкі два-три кроки, щоб отримати копію та розгорнути її та спробувати у своїх середовищах, перш ніж купувати її? Як це виглядає? Які кроки для цього?
Білл Елліс: Так. Отже, IDERA.com та просто перейдіть до Продуктів, і ви побачите Аналіз навантаження для SAP HANA. Є сторінка для завантаження. Думаю, вони запитають у вас контактну інформацію, і продукт просто упакований ліцензійним ключем, щоб ви могли встановити його за допомогою Setup.exe і, як мені здається, дуже швидко прокрутити.
Dez Blanchfield: Отже, вони можуть перейти на ваш веб-сайт, вони можуть завантажити його. Пам’ятаю, я дивився на це деякий час тому, і я ще раз перевірив минулу ніч, ви можете запитати демонстраційну пам’ять із пам’яті, де хтось із вашої команди, як би, провів вас через це? Але ви можете фактично завантажити його безкоштовно і розмістити на локальному рівні у власному середовищі, у свій час, чи не так?
Білл Елліс: Так.
Dez Blanchfield: Відмінно. Я думаю, що більше за все, це, мабуть, те, що я особисто радив би народові зробити, це схопити копію з веб-сайту, взяти там частину документації, тому що я знаю, що там багато хорошого вмісту, щоб це зробити, і просто спробуйте. Покладіть його у своє оточення та подивіться, що ви знайдете. Я підозрюю, що після того, як ви заглянете під капот із середовищем SAP HANA за допомогою інструменту IDERA, ви знайдете речі, про які ви насправді не знали.
Подивіться, велике спасибі за це, і дякую за час лише на питання і відповіді з Робіном та І. Еріком, я повернуся до вас, бо знаю, що деякі запитання також надходять від наших відвідувачів.
Ерік Кавана: Так, тут просто справжній швидкий. Отож, один із присутніх робить тут дійсно хороший коментар, просто розмовляючи про те, як змінюються речі. Якщо говорити в минулому, пам'ять захлиналася, сповільнюючись частими пейджингами, в даний час процесор задихається із занадто великою кількістю даних в пам'яті. Знаєте, є проблеми з мережею. Це завжди буде рухомою ціллю, правда? Що ви вважаєте траєкторією в наші дні з точки зору того, де будуть вузькі місця і де вам потрібно буде зосередити свою увагу?
Білл Елліс: Так. Поки ви не вимірюєте, це важко знати. Одна з речей щодо SQL-операторів - це те, що вони стануть рушіями споживання ресурсів. Отже, за умови, що ви мали б, наприклад, велике споживання пам'яті або споживання процесора, ви зможете зрозуміти, яка діяльність спричиняла це споживання ресурсів. Тепер ви не обов’язково хотіли б його вбити, але ви також хочете бути в курсі цього і, що таке, що часто відбувається, і так далі. Ми, як і раніше, нові в питанні вирішення всього набору або кулінарної книги відповідей на різні обставини. І так, це чудове питання і час покаже. Ми будемо мати більше інформації, як пройде час.
Ерік Кавана: Це воно. Ну, ви, хлопці, у дуже цікавому просторі. Я думаю, що ви будете бачити багато активності в найближчі місяці та наступні пару років, тому що я знаю, що SAP, як ви запропонували в нашому дзвінку за вміст, забезпечив людям гарний довгий проїзд, щоб здійснити перехід до HANA. Але, тим не менше, цей пандус має закінчення, і в певний момент людям доведеться приймати якісь серйозні рішення, тож чим швидше, тим краще, правда?
Білл Елліс: Зовсім.
Ерік Кавана: Добре, люди, ми спалили ще одну годину тут, на Hot Technologies. Ви можете знайти інформацію в Інтернеті, insideanalysis.com, також techopedia.com. Зосередьтеся на цьому веб-сайті, щоб отримати багато цікавої інформації, включаючи перелік усіх наших архівів цих минулих веб-трансляцій. Але люди, велике спасибі всім вам там, нашим друзям з ІДЕРИ, Робіну і звичайно, Дез. І ми наздоженемо вас наступного тижня, люди. Ще раз дякую за ваш час та увагу. Піклуватися. Бувай.