Співробітники компанії «Техопедія», 25 січня 2017 року
Винос: Ведучий Ерік Кавана обговорює обчислення в пам'яті та SAP HANA з гостями доктором Робіном Блором, Дез Бланчфілдом та Ідеєю Біллом Еллісом.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Добре, панове. Привіт і ще раз ласкаво просимо. Це чотири години східного часу в середу, і останні пару років, це означає, що час знову для гарячих технологій. Так, справді мене звуть Ерік Кавана, я буду вашим господарем сьогоднішньої розмови.
І люди, ми сьогодні поговоримо про якісь цікаві речі. Ми збираємось зануритися у світ пам’яті, точний заголовок - «В майбутнє: на раму для обчислень в пам'яті». У наші дні це все лютує, і з поважних причин, головним чином тому, що пам'ять набагато швидше, ніж покладатися на спінінг-диски. Завдання полягає в тому, що вам доведеться переписати багато програмного забезпечення. Тому що програмне забезпечення сьогодні, більшість його, було написано з урахуванням диска, і це дійсно змінює архітектуру програми. Якщо ви розробляєте програму, щоб чекати спінінг-диска, ви просто робити щось інакше, ніж якщо у вас є вся потужність технології пам'яті.
Є місце про твою справді, вдарив мене у Twitter, @eric_kavanagh. Я завжди намагаюся піти назад, а також ретвітувати будь-коли, коли хтось згадає про мене.
Як я вже говорив, ми сьогодні говоримо про пам'ять, а конкретно про SAP HANA. Ваш справді провів останній рік, дуже добре познайомившись із спільнотою SAP, і це я мушу сказати. Капелюхи дітям, які виконують цю операцію і перебувають на передовій, тому що SAP - це надзвичайно хороша операція. У чому вони дуже хороші, - це бізнес. Вони, звичайно, також чудово підходять до технологій, і вони справді вклали великі інвестиції в HANA. Насправді я пам'ятаю - це було, мабуть, близько шести-семи років тому - що ми робили якусь роботу для ВПС США, і ми змусили когось із SAP зайти і дати нам перший погляд на світ HANA та що планувалося. І найменше кажучи, люди в лабораторіях SAP вклали багато часу і зусиль, щоб зрозуміти, як побудувати цю архітектуру, що зовсім інше, з традиційних середовищ, адже у вас є все на пам'ять. Отже, вони говорять про те, щоб робити транзакційні та аналітичні в одній і тій же пам’яті даних, на відміну від традиційного способу, який витягують, кладуть у куб, наприклад, аналізують його там проти транзакційного, який відбувається зовсім по-іншому.
Це цікавий простір, і ми збираємось дізнатись від іншого продавця, насправді, IDERA, трохи про те, як усі ці речі працюватимуть, і про що на пандусі - це відверто. Отже, ми будемо слухати доктора Робіна Блура, нашого самого головного аналітика в The Bloor Group; Дез Бланчфілд, наш науковець з даних, а потім хороший друг Білл Елліс з 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 майже завжди є фундаментальними програмами, якими керує бізнес, це просто величезний чейнджер ігор, і це буде дуже цікаво. Але звичайно, це все звучить дуже добре, але це потрібно налаштувати розумно, і за ним потрібно добре контролювати. Це не так просто, як це звучить.
Сказавши це, я думаю, я передам бал тому, хто цей хлопець? О, австралійський хлопець, Дез Бланчфілд.
Дез Бланшфілд: Дуже смішно. Завжди важкий вчинок, доктор Робін Блор. Дякуємо, що мене сьогодні взяли. Отже, велика тема, але хвилююча. Отже, я вибрав образ, який часто бачу на увазі, коли я замислююся про сучасні сховища даних про озеро та підприємства, а також про мої маленькі дорогоцінні камені даних. Так ось у мене це прекрасне озеро, оточене горами і хвилями, що виходять, і хвилі розбиваються над цими скелями. Це, начебто, як я подумки уявляю, як це виглядає всередині великого озера даних в ці дні. Хвилі - це пакетні завдання, а аналітика в режимі реального часу кидається на дані, будучи скелями. І коли я думаю про це як про фізичне озеро, воно нібито повертає мені сигнал про неспокій, що, знаєте, масштаб сховищ даних, які ми зараз будуємо, причина, по якій ми придумали цю монету та термін озеро даних полягає в тому, що вони дуже великі і вони дуже глибокі, а іноді в них можуть буріти бурі. І коли ми це робимо, ти завжди повинен вирішити, що створює шторм.
Отже, в темі цієї речі мені здається, що цей виклик сирени в обчисленні пам'яті дійсно дуже сильний і з поважних причин. Це приносить стільки значних комерційних та технічних вигод. Це дискусія протягом пари годин в інший день. Але загальний перехід на обчислення в пам'яті, по-перше, я просто хочу висвітлити, як ми потрапили сюди, і що це робить можливим, оскільки це, начебто, ставить основу, де деякі проблеми можуть бути в першу чергу і що нам потрібно знати мислення та думки про те, щоб у нашому світі відійти від традиційних старих спінінг-дисків, що зберігають дані, і підключаються до диску та вимикаються на диск, в пам’ять, і з пам'яті, і в процесори, до цього часу ми просто видаляємо майже один з цих цілих шарів, будучи спінінг-диском. Тому що пам’ятайте, що в самих ранніх часах обчислювальної роботи в архітектурному плані ми довго не рухалися з мейнфрейму чи середнього діапазону світу того, що спочатку вважали основною пам'яттю та накопичувачем барабана.
Як сказав доктор Робін Блур, підхід, який ми застосували до переміщення даних навколо архітектури комп’ютера, насправді не змінився кардинально протягом деякого часу, фактично за пару десятків років. Якщо ви думаєте про те, що, знаєте, сучасні обчислення, технічно, існували, якщо ви будете пробачити каламбур протягом 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.
Доктор Робін Блор: Я думаю, я краще передам вас Дезу. Я гуляв твій час. Дез?
Дез Бланшфілд: Дякую. Ні, це все добре. Дві дуже швидкі, просто намагаючись задати тему. SAP HANA існує вже пару років, і люди мали шанс розглянути це. Якщо ви мали б дати нам приблизну оцінку відсотка людей, які ним керують - адже там багато людей, які керують цим матеріалом - як ви думаєте, наскільки відсоток ринку, про який ви знаєте, на даний момент пішов від просто традиційних реалізацій SAP до SAP на HANA? Ми дивимось на 50/50, 30/70? Який відсоток ринку ви бачите на людей, які перейшли та зробили цей крок, порівняно з людьми, які просто стримують і чекають, коли покращиться, покращиться або зміниться, або в будь-якому випадку?
Білл Елліс: Так, я б, з моєї точки зору, ставив би відсоток близько 20 відсотків. SAP, як правило, традиційний бізнес. Люди, як правило, дуже консервативні, і тому їх люди будуть тягнути ноги. Я думаю, це також залежить від того, ви знаєте, чи довго ви керуєте SAP, чи ви такий собі SMB, який, можливо, нещодавно розгорнув SAP? Отже, існує ряд факторів, але в цілому я не думаю, що відсоток становить 50/50. Я б сказав, що 50 відсотків принаймні непросто і HANA працює десь у своєму центрі обробки даних.
Дез Бланчфілд: Цікавий випуск, який ви нам давали раніше, полягав у тому, що це є фактом, який є певним чином, і що годинник фізично і буквально тикає на час переходу. Як ви думаєте, в процесі цього ви думаєте, що люди це вважали? Який загальний сенс народного розуміння того, що це перехідна зміна платформи, це не просто варіант, це стає дефолтом?
І з точки зору SAP, я впевнений, що вони так намагаються, оскільки є значна конкурентна перевага в продуктивності, але, мабуть, вони також борються за управління платформою замість того, щоб перейти на третій- партійна база даних, тепер вони повертають її на власну платформу. Як ви думаєте, компанії насправді отримали це повідомлення? Як ви думаєте, люди це розуміють і зараз це ведуть до цього? Або це, як і раніше, незрозуміла річ, як ви думаєте, на ринку?
Білл Елліс: Я не думаю, що SAP соромляться спілкування, і люди, які перейшли до САПФІРа, бачили HANA всюди. Отже, я думаю, що люди це добре знають, але людська природа є такою, якою вона є, ви знаєте, деякі люди є, начебто, трохи перетягуючи ноги.
Дез Бланчфілд: Тому що я думаю, що я поставив це питання, і вам доведеться пробачити мені, але я згоден. Я думаю, що вони не соромилися свого спілкування. Я думаю, що сигнал багато в чому вийшов. І я з вами згоден - я не знаю, що всі ще стрибали. Ви знаєте, традиційні підприємства, дуже великі підприємства, які керують цим, все ще багато в чому не дуже тягнуть ноги, а просто намагаються зрозуміти складність зміни. Тому що я думаю, що одне, що вирішив ваш інструмент, і, безумовно, ваша демонстрація сьогодні, і для мене одним ключовим захопленням, я хотів би, щоб усі слухали і налаштовувались сьогодні, щоб сісти і обмірковувати увагу - це у вас є Інструмент тепер спростив цей процес. Я думаю, що в них є дуже багато нервових керівників та їхніх команд, які думають: «Як зробити перехід від традиційних RDBMS, реляційних систем управління базами даних, які ми знаємо десятиліттями, до цілком нової парадигми обчислень та управління пам’яттю в просторі, який досі є досить сміливим? ”на мою думку. Але це багато в чому невідомо, і дуже мало людей зробили цей зсув в інших сферах, що це не так, як у них є інший розділ бізнесу, який вже перейшов до обчислення пам'яті. Отже, це все-або нічого, що рухається в їхній свідомості.
Отож, одне з речей, що я більше всього відібрав у цьому - я збираюся вразити вас питанням за хвилину - це страх зараз, я думаю, багато в чому перебуває і що до сьогодні, якби я слухав CIO, я б начебто подумав: «Ну як я зроблю цей перехід? Як я можу гарантувати ту саму здатність, яку ми отримали на платформі управління реляційними базами даних та багаторічний досвід роботи DBA, на нову платформу, в якій ми зараз не маємо навичок? "Отже, моє запитання з цього питання є, чи вважаєте ви, що люди зрозуміли, що інструменти є зараз із тим, що ви пропонуєте, і що вони можуть, начебто, зробити глибокий вдих і зітхнути з полегшенням, що перехід не такий страшний, як це було раніше доступний цей інструмент? Як ви думаєте, люди зрозуміли, що це чи все-таки щось таке, що вони просто бореться з переходом на обчислення в пам'яті та на зберігання в пам'яті порівняно зі старими шкільними комбінаціями NVMe, флеш-диску та диска?
Білл Елліс: Так, так що, безсумнівно, існує багато технологій та інструментів, які можуть графічно відобразити це, що відбувається і зробити це дуже легко визначити топ-споживачів ресурсів. Я маю на увазі, це допомагає спростити речі, і це допомагає співробітникам технологій справді добре впоратися. Гей, вони зможуть дізнатися, що відбувається, і зможуть зрозуміти всю складність. Тож абсолютно інструменти на ринку безумовно корисні, тому ми пропонуємо аналіз завантаженості для SAP HANA.
Дез Бланчфілд: Так, я думаю, що чудова річ у тому, що ви нам показали сьогодні, це те, що під час моніторингу обладнання, операційної системи, навіть моніторингу деякого робочого навантаження, що рухається, як ви сказали, я маю на увазі інструменти були там деякий час. Біль для мене, особливо у подібних до HANA, полягає в тому, що ми не обов'язково мали змогу дістати збільшувальне скло і зазирнути в нього, і зрозуміти, що саме робить ваш інструмент із тим, що відбувається з запитами та як вони структурований і де це навантаження.
З розгортанням, яке ви бачили досі, враховуючи, що ви буквально найавторитетніший у цьому просторі на своїй платформі у світі, деякі швидкі виграші, які ви бачили - чи маєте ви якісь анекдотичні знання, якими ви можете поділитися. нас навколо деяких моментів еврики, ага моментів, коли люди розгорнули набір інструментів IDERA, вони знайшли речі, про які вони просто не були обізнані, були у своїх платформах та виступах, які вони мали. Чи є у вас чудові анекдотичні приклади того, де люди щойно розгорнули це, не знаючи, що у них було, і раптом пішли: "О, ми насправді не знали, що там є?"
Білл Елліс: Так, настільки велике обмеження натільних інструментів полягає в тому, що якщо скасований запит скасований, він промиває інформацію, і, таким чином, у вас в основному немає історії. Ми зберігаємо історію в режимі офлайн, як уникнутий запит, у вас буде історія, ви будете знати, що сталося, ви зможете побачити план виконання тощо. І так, що дозволяє, начебто, допомагати кінцевій спільноті користувачів в основному краще працювати, краще писати звіти, тощо. І так, історія - це те, що насправді приємно мати. І одна з речей, яку я мав на меті показати, - це те, що ви можете подивитися в режимі реального часу до чотирьох тижнів, а потім можете легко збільшити масштаб на будь-який цікавий часовий проміжок, і тоді ви можете розкрити основні рушійні дії. Просто мати таку видимість - це дуже корисне знання того, яке виникло вузьке місце.
Дез Бланчфілд: Ви згадали, що це багатокористувацький раз, коли він розгорнувся, і мене дуже вразило те, що це без агента і ефективно нульовий дотик багато в чому. Чи нормально для одного розгортання вашого інструменту потім бути доступним для всіх з мережевих операційних центрів у НОК, які переглядають основну інфраструктуру, що лежить в основі кластера, аж до команди програм та розробників? Це норма, і ви розміщуєте один раз, і вони поділять це, чи ви гадаєте, що у людей можуть бути екземпляри моделей, які дивляться на різні частини стека? Як це виглядає?
Білл Елліс: Отже, базовий колектив, як правило, буде дуже сильно зацікавлений у технології, що лежить в основі того, що відбувається в SAP. Очевидно, є кілька команд, які підтримуватимуть цілі пейзажі. Частина HANA саме зосереджена на цьому. Я просто збираюся за замовчуванням для команди бази SAP як основного споживача інформації.
Дез Бланшфілд: Правильно. Мене вражає те, що якщо у мене є команда розробників або навіть не просто на рівні коду, але якщо у мене є команда науковців даних або аналітиків, які виконують аналітичну роботу над наборами даних там, особливо зважаючи на те, що там Суттєвий поштовх до наукових даних, що застосовується до всього, що знаходиться всередині організацій зараз, на мій погляд - і виправте мене, якщо я помиляюся - мені здається, що це також буде цікаво і для них, адже багато в чому це з серйозних речей, які ви можете зробити в середовищі сховища даних, це розкрити науковця даних і дозволити йому просто почати робити спеціальні запити. Чи були у вас приклади такого роду випадків, коли магазини зателефонували вам і сказали: «Ми кинули команду наукових даних на річ, це дійсно боляче, що ми можемо зробити для них порівняно з тим, що ми робимо традиційний оперативний моніторинг та управління? "Це навіть річ?
Білл Елліс: Ну, так, я хотів би трохи перетворити це і вирізати свою відповідь - це, дивлячись на продуктивність, усвідомлюючи ефективність у розвитку виробництва QA, знаєте, чим раніше ви будете зберігати, тим менше проблем, менше сюрпризи у вас є. Отже, абсолютно.
Дез Бланшфілд: Виходячи з цього, багато інструментів, з якими я мав досвід роботи - і я впевнений, що Робін погодиться - багато інструментів тут, якщо у вас є великий RDBMS, вам потрібні справді високі показники, кваліфіковані, глибоко обізнані досвідчені DBA. Деякі вимоги до інфраструктури та платформи, які виникають разом із SAP HANA, оскільки в даний час він підтримується на конкретних дистрибутивах, що відповідають певним обладнанням тощо, наскільки мені відомо. Знаєте, є люди з десятилітнім досвідом, які не однакові. Однак я бачу, що це не обов'язково вимога цього інструменту. Мені здається, ви можете розгорнути свій інструмент і надати його деяким досить новим обличчям і дати їм сили відразу знайти речі, які не працюють добре. Чи трапляється так, що існує досить коротка крива навчання, щоб досягти швидкості з цим і отримати деяку цінність від його розгортання? Знаєте, мій загальний сенс полягає в тому, що вам не потрібно мати 20-річний досвід керування інструментом, щоб негайно побачити цінність. Чи згодні ви, що так?
Білл Елліс: О, абсолютно, і, на вашу думку, я думаю, що багато успіху розгортання дійсно залежить від планування та архітектури середовища SAP HANA. І тоді, безсумнівно, є багато складностей, багато технологій, на яких вбудовано, але тоді це просто зводиться до моніторингу моделей використання того, що відбувається. Отже, хоча це і складніше, але певний спосіб він упакований і дещо спрощений. Це дуже бідно.
Дез Бланчфілд: Так, перед тим, як повернутись до Еріка, тому що я знаю, що у нього є кілька запитань, зокрема, з питань, які потрапляють у відповідь на питання, які виглядали цікавими, і я хочу почути відповідь. Традиційна подорож для когось - ви раніше згадували, що можете її отримати, можете завантажити і спробувати. Чи можете ви просто скористатись цим швидко для прослуховування народних альбо сьогодні, або для людей, які могли б повторити його пізніше? Які швидкі два-три кроки, щоб отримати копію та розгорнути її та спробувати у своїх середовищах, перш ніж купувати її? Як це виглядає? Які кроки для цього?
Білл Елліс: Так. Отже, IDERA.com і просто перейдіть до Продуктів, і ви побачите Аналіз робочого навантаження для SAP HANA. Є сторінка для завантаження. Думаю, вони запитають у вас контактну інформацію, і продукт просто упакований ліцензійним ключем, щоб ви могли встановити його разом із Setup.exe і просто прокотитись, я думаю, дуже швидко.
Дез Бланшфілд: Отже, вони можуть перейти на ваш веб-сайт, вони можуть завантажити його. Пам’ятаю, я дивився на це деякий час тому, і я ще раз перевірив минулу ніч, ви можете запитати демонстраційну пам’ять із пам’яті, де хтось із вашої команди, як би, провів вас через це? Але ви можете фактично завантажити його безкоштовно та розмістити на локальному рівні у своєму власному середовищі, у свій час, чи не так?
Білл Елліс: Так.
Дез Бланшфілд: Відмінно. Я думаю, що більше за все, це, мабуть, те, що я особисто радив би народові зробити, це схопити копію з веб-сайту, взяти там частину документації, тому що я знаю, що там багато хорошого вмісту, щоб це зробити, і просто спробуйте. Покладіть його у своє оточення та подивіться, що ви знайдете. Я підозрюю, що після того, як ви заглянете під капот із середовищем SAP HANA за допомогою інструменту IDERA, ви знайдете речі, про які ви насправді не знали.
Подивіться, велике спасибі вам за це, і дякую за час лише на питання і відповіді з Робіном та І. Еріком, я повернуся до вас, бо знаю, що деякі питання і відповіді надходять і від наших відвідувачів.
Ерік Кавана: Так, просто справжній швидкий. Отож, один із присутніх робить тут дійсно хороший коментар, просто розповідаючи про те, як змінюються речі. Якщо говорити в минулому, пам'ять захлиналася, сповільнюючись частими пейджингами, в даний час процесор задихається із занадто великою кількістю даних в пам'яті. Знаєте, є проблеми з мережею. Це завжди буде рухомою ціллю, правда? Що ви вважаєте траєкторією в наші дні з точки зору того, де будуть вузькі місця і де вам потрібно буде зосередити свою увагу?
Білл Елліс: Так. Поки ви не виміряєте, важко це знати. Одна з речей щодо SQL-операторів - це те, що вони стануть рушіями споживання ресурсів. І тому за тієї обставини, що вам довелося мати, як, наприклад, велике споживання пам'яті або споживання процесора, ви зможете зрозуміти, яка діяльність викликала споживання ресурсів. Тепер, ви не обов'язково хочете його вбити, але ви також хочете бути в курсі цього і, що таке, що часто відбувається, і так далі. Ми, начебто, ще нові в питанні вирішення всього набору або кухарської книги відповідей на різні обставини. І так, це чудове питання і час покаже. Ми будемо мати більше інформації, як пройде час.
Ерік Кавана: Це все. Ну, ви, хлопці, у дуже цікавому просторі. Я думаю, що ви будете бачити багато активності в найближчі місяці та наступні пару років, тому що я знаю, що SAP, як ви запропонували в нашому дзвінку за вміст, забезпечив людям гарний довгий проїзд, щоб здійснити перехід до HANA. Але, тим не менше, цей пандус має закінчення, і в певний момент людям доведеться приймати якісь серйозні рішення, тож чим швидше, тим краще, правда?
Білл Елліс: Абсолютно.
Ерік Кавана: Добре, люди, ми прогоріли ще одну годину тут, на Hot Technologies. Ви можете знайти інформацію в Інтернеті, insideanalysis.com, також techopedia.com. Зосередьтеся на цьому веб-сайті, щоб отримати багато цікавої інформації, включаючи перелік усіх наших архівів цих минулих веб-трансляцій. Але люди, велике спасибі всім вам там, нашим друзям з ІДЕРИ, Робіну і звичайно, Дез. І ми наздоженемо вас наступного тижня, люди. Ще раз дякую за ваш час та увагу. Піклуватися. Бувай.
