Di Techopedia Staff, 25 gennaio 2017
Da asporto: l' host Eric Kavanagh discute dell'informatica in memoria e di SAP HANA con gli ospiti Dr. Robin Bloor, Dez Blanchfield e Bill Ellis di IDERA.
Al momento non sei collegato. Accedi o registrati per vedere il video.
Eric Kavanagh: Okay, signore e signori. Ciao e bentornati ancora una volta. Sono le quattro in punto Eastern Time di mercoledì e gli ultimi due anni significano che è di nuovo l'ora di Hot Technologies. Sì, davvero, mi chiamo Eric Kavanagh, sarò il tuo ospite per la conversazione di oggi.
E gente, parleremo di alcune cose interessanti oggi. Ci immergeremo nel mondo della memoria, il titolo esatto è "Into the Future: An On-Ramp for In-Memory Computing". Di questi tempi è di gran moda, e con buone ragioni, soprattutto perché la memoria è molto più veloce che affidarsi ai dischi rotanti. La sfida, tuttavia, è che devi riscrivere un sacco di software. Perché il software di oggi, in gran parte, è stato scritto pensando al disco e questo cambia davvero l'architettura dell'applicazione. Se si progetta l'applicazione in attesa di un disco rotante, si fa semplicemente diversamente rispetto a se si dispone di tutta la potenza della tecnologia in-memory.
C'è davvero un punto nel tuo, colpiscimi su Twitter, @eric_kavanagh. Cerco sempre di seguire e anche di ritwittare ogni volta che qualcuno mi menziona.
Come ho detto, stiamo parlando in memoria oggi e in particolare su SAP HANA. Il tuo ha davvero trascorso l'ultimo anno a conoscere molto bene la comunità SAP, ed è un ambiente affascinante, devo dire. Tanto di cappello alle persone che eseguono quell'operazione e sono in prima linea, perché SAP è un'operazione incredibilmente buona. Ciò in cui sono veramente bravi è fare affari. Sono anche bravi nella tecnologia, ovviamente, e hanno davvero investito molto in HANA. In effetti, posso ricordare - probabilmente circa sei o sette anni fa - che stavamo effettivamente facendo un po 'di lavoro per la US Air Force, e abbiamo ottenuto qualcuno da SAP per entrare e darci una prima occhiata al mondo di HANA e ciò che era previsto. E per non dire altro, la gente dei SAP Labs aveva dedicato molto tempo e sforzi per capire come costruire questa architettura che è completamente diversa, ancora una volta, dagli ambienti tradizionali, perché hai tutto in memoria. Quindi, stanno parlando di fare sia transazionali che analitici sugli stessi dati in memoria, al contrario del modo tradizionale, che è estrarli, metterli in un cubo, ad esempio, analizzarli lì, rispetto alle transazioni, che succede in un modo molto diverso.
Questo è uno spazio interessante e lo scopriremo in realtà da un altro fornitore, IDERA, un po 'su come funzionerà tutta quella roba, e di cosa si occupi on-ramp, francamente. Quindi, avremo notizie dal Dr. Robin Bloor, il nostro analista capo qui al The Bloor Group; Dez Blanchfield, il nostro scienziato dei dati e poi il buon amico Bill Ellis di IDERA. Quindi, con ciò, consegnerò le chiavi al Dr. Robin Bloor, che lo porterà via.
Dr. Robin Bloor: Sì, come diceva Eric, il tempo in cui siamo stati informati per la prima volta da SAP HANA era tornato molti anni fa, ora. Ma è stato molto interessante, quel particolare momento è stato molto interessante. Ci saremmo imbattuti in una o due società che, in un modo o nell'altro, offrivano tecnologia in memoria. Era abbastanza chiaro che in memoria stava per arrivare. E non è stato fino a quando SAP si è alzato e ha lanciato improvvisamente HANA. Voglio dire, è stato scioccante quando ho visto SAP farlo. È stato come uno shock perché mi aspettavo che venisse da altrove. Mi aspettavo che sarebbe stato Microsoft o Oracle o IBM o qualcuno del genere. L'idea che SAP lo stesse facendo è stata davvero molto sorprendente per me. Suppongo che non avrebbe dovuto essere perché SAP è uno dei fornitori strategici e praticamente, sai, tutto ciò che accade nel settore proviene da uno di questi.
Ad ogni modo, l'intero punto della memoria, intendo, ci siamo resi conto, ne eravamo soliti parlarne, che non appena si entra effettivamente nella memoria - non si tratta di mettere i dati in memoria, si tratta di impegnarsi nel idea che il livello di memoria sia il record di sistema - non appena si migra il record di sistema in memoria, il disco inizia a diventare un supporto di trasferimento di un tipo e diventa una cosa diversa. E ho pensato che fosse molto eccitante quando ha iniziato a succedere. Quindi, davvero, è finita per girare il disco. Il disco rotante sarà presto disponibile solo nei musei. Non sono sicuro di quanto presto sarà, ma fondamentalmente, il disco a stato solido si trova ora sulla curva della legge di Moore, è già dieci volte più veloce della rotazione della ruggine, come ora lo chiamano, e abbastanza presto sarà ancora più veloce e quindi ciò significa che i casi d'uso per il disco ottengono sempre meno.
E il fatto curioso, DBMS tradizionale, in realtà, un sacco di software tradizionale è stato creato per il disco rotante, ha assunto il disco rotante. Possedeva ogni sorta di capacità a livello fisico programmate scrupolosamente per sfruttare il disco rotante e rendere il recupero dei dati il più veloce possibile. E tutto ciò viene lavato via. Sto solo scomparendo, lo sai? E poi, c'è stato ovviamente un molto - non lo so, redditizio, suppongo, sarà alla fine - l'apertura per un database in memoria che ha cercato di occupare la posizione che i grandi database, Oracle e Microsoft, SQL Server e IBM DB2, occupava lo spazio in memoria ed era molto interessante vederlo avanzare e farlo.
Parliamo della cascata della memoria; vale la pena menzionarlo. È anche, il motivo per menzionarlo, il motivo per cui l'ho lanciato, in realtà, era solo per far sapere a tutti, quando sto parlando di memoria, tutti questi strati di cui sto parlando sono in realtà memoria. Ma improvvisamente ti rendi conto quando lo guardi, questo è un negozio gerarchico, non è solo memoria. E quindi, si applica praticamente tutto ciò che abbiamo imparato molto, molto tempo fa sul negozio gerarchico. E significa anche che qualsiasi database in memoria deve farsi strada attraverso questo, alcuni lo percorrono semplicemente sulla RAM stessa, lo sai. Ed è appena diventato sempre più grande e più grande e ora è misurato in megabyte. Ma hai cache L1 che è cento volte più veloce della memoria, cache L2 30 volte più veloce della memoria e cache L3 circa 10 volte più veloce della memoria. Quindi, sai, c'è molta tecnologia - beh, una discreta quantità di tecnologia - ha adottato la strategia di utilizzare quelle cache come tipo di spazio di archiviazione sulla strada per eseguire le cose, in particolare la tecnologia di database. Quindi, sai, questa è un'influenza.
Quindi abbiamo avuto la nascita di 3D XPoint e IBM PCM. Ed è quasi alla velocità della RAM, è fondamentalmente ciò di cui entrambi questi fornitori si vantano. I casi d'uso sono probabilmente diversi. La sperimentazione precoce con questo deve ancora essere completata. Non sappiamo come influenzerà l'uso della RAM e la tecnologia del database in memoria per quella materia. Quindi hai RAM rispetto a SSD. Attualmente la RAM è circa 300 volte più veloce ma, naturalmente, il multiplo sta diminuendo. E SSD contro disco che è circa 10 volte più veloce, se lo capisco. Quindi, questo è il tipo di situazione che hai. È un negozio gerarchico. Guardarlo in un altro modo, in memoria, ovviamente, è completamente diverso. Quindi, il diagramma in alto mostra due applicazioni, entrambe che forse accedono a un database, ma certamente accedono ai dati sulla rotazione della ruggine. E il modo in cui fai effettivamente scorrere le cose attraverso la rete, a seconda di quali dipendenze ci sono, è che hai ETL. Quindi, questo significa che, sai, i dati vanno sulla ruggine che gira e poi si staccano dalla ruggine per andare ovunque, e per arrivare ovunque tornano alla ruggine che gira, che è tre movimenti. E tieni presente che la memoria può essere centomila volte più veloce dello spinning del disco, e certamente ti rendi conto che prendere i dati e metterli in memoria rende l'intera cosa molto diversa.
Quindi, potresti aver pensato che cosa sarebbe successo su ciò che è sullo schermo proprio qui, potresti aver pensato che, in un modo o nell'altro, l'ETL in realtà sarebbe passato dai dati ai dati in memoria. Ma in realtà potrebbe non farlo; in realtà potresti avere la situazione proprio qui dove due applicazioni possono effettivamente sparare dalla stessa memoria. Certamente un database in memoria potrebbe darti questa capacità, a patto che tu abbia il blocco e tutto il resto orchestrato attorno ad esso. Quindi, questo non altera solo la velocità delle cose, ma altera il modo in cui configuri effettivamente applicazioni e interi flussi di dati.
Quindi, è un enorme tipo di impatto. Quindi, in memoria è dirompente, giusto? E dovremmo prenderlo da quello che ho detto. L'elaborazione in memoria attualmente è un acceleratore, ma diventerà la norma. Verrà utilizzato, essendo applicato in base al valore dell'applicazione, ed è quindi molto, molto interessante, che SAP uscirà effettivamente con una versione del loro software ERP che è in memoria. E i miglioramenti della latenza fino a tre ordini di grandezza sono del tutto possibili, e in realtà anche più di quello è possibile, a seconda di come lo fai. Quindi, stai ottenendo enormi miglioramenti nella velocità andando in memoria. E il risultato, l'S / 4 di SAP HANA - che hanno rilasciato, penso, beh, la gente dice che è ancora in fase di rilascio, ma è stato sicuramente rilasciato l'anno scorso - è un punto di svolta rispetto alla base di clienti SAP. Voglio dire, ci sono 10.000 aziende là fuori che usano l'ERP di SAP e praticamente tutte sono grandi aziende, sai. Quindi, l'idea di tutti loro avere un incentivo per andare alla memoria e usare il loro fondamentale, perché ERP è quasi sempre un'applicazione fondamentale che le aziende stanno eseguendo, è solo un enorme cambio di gioco e sarà molto interessante. Ma ovviamente, tutto suona molto bene, ma deve essere configurato in modo intelligente e deve essere ben monitorato. Non è così semplice come sembra.
Detto questo, penso che passerò la palla a chi è questo ragazzo? Oh, ragazzo australiano, Dez Blanchfield.
Dez Blanchfield: molto divertente. Sempre un duro atto da seguire, dottor Robin Bloor. Grazie per avermi oggi. Quindi, grande argomento, ma eccitante. Quindi, ho scelto un'immagine che mi viene spesso in mente quando penso ai moderni data lake e ai data warehouse aziendali e alle mie piccole gemme di dati. Quindi qui ho questo bellissimo lago circondato da montagne e onde che escono, e le onde si infrangono su queste rocce. Questo è, in un certo senso, il modo in cui visualizzo mentalmente come appare all'interno di un grande lago di dati in questi giorni. Le onde sono lavori batch e l'analisi in tempo reale viene lanciata sui dati, essendo le rocce. E quando ci penso come un lago fisico, in qualche modo mi viene in mente un campanello d'allarme che, sai, la scala dei data warehouse che stiamo costruendo ora, il motivo per cui abbiamo inventato questo conio e il termine di un lago di dati è che sono molto grandi e molto profondi, e occasionalmente si possono avere tempeste al loro interno. E quando lo facciamo, devi sempre risolvere ciò che sta creando la tempesta.
Quindi, nel tema di questa cosa, a me sembra che questa chiamata della sirena del computing in memoria sia davvero molto forte e per una buona ragione. Produce così tanti significativi guadagni commerciali e tecnici. Questa è una discussione per un paio d'ore in un altro giorno. Ma il passaggio generale al computing in-memory, in primo luogo voglio solo capire come siamo arrivati qui e cosa lo rende possibile perché, in un certo senso, pone le basi di dove possono sorgere alcune delle sfide e di cosa dobbiamo essere consapevoli e pensando a, nel nostro mondo di allontanarci dai tradizionali vecchi dischi rotanti che contengono dati ed essere paginati dentro e fuori dal disco e nella memoria e nella memoria e nelle CPU, fino ad ora stiamo rimuovendo quasi uno di quegli interi strati, essendo il disco rotante. Perché ricorda, nei primissimi tempi dell'informatica, dal punto di vista architettonico, non ci siamo mossi per molto tempo dal mainframe o dal mondo dei midrange di ciò che originariamente pensavamo come memoria core e memoria del tamburo, sai.
Come ha affermato il Dr. Robin Bloor, l'approccio che abbiamo adottato per spostare i dati sull'architettura dei computer non è cambiato in modo drammatico per qualche tempo, in effetti per un paio di decenni. Se pensi al fatto che, tecnicamente, il computer moderno è in circolazione, se perdonerai il gioco di parole, per circa 60 anni, sai, sei decenni e più ed è nel senso che puoi compra una scatola dallo scaffale, per così dire. Il passaggio alla nuova architettura mi è davvero venuto in mente quando ci siamo spostati dal pensiero attorno a mainframe e midrange e architetture di memoria di memoria e batteria, verso il coraggioso o il supercalcolo, in particolare artisti del calibro di Seymour Cray, dove cose come i backplane dei crossbar è diventato una cosa. Invece di avere un solo percorso per spostare i dati sul backplane o sulla scheda madre, come viene chiamato in questi giorni. E la memoria in linea, sai, in questi giorni le persone non pensano davvero a cosa significhi effettivamente quando dicono DIMM e SIMM. Ma SIMM è una memoria in linea singola e DIMM è una memoria in linea doppia e da allora siamo diventati più complessi di così e ci sono dozzine di tipi di memoria diversi per cose diverse: alcuni per i video, altri solo per applicazioni generali, altri integrati nelle CPU.
Quindi, c'è stato questo grande passaggio a un nuovo modo in cui i dati sono stati archiviati e accessibili. Stiamo per attraversare lo stesso turno in un'altra intera generazione, ma non tanto nell'hardware stesso ma nell'adozione dell'hardware nella logica aziendale e nel livello della logica dei dati, ed è un altro grande cambiamento di paradigma nella mia mente .
Ma solo brevemente su come siamo arrivati qui. Voglio dire, la tecnologia hardware è migliorata e notevolmente migliorata. Siamo passati dall'avere CPU e l'idea di un core era un concetto abbastanza moderno. Diamo per scontato ora che i nostri telefoni hanno due o quattro core e che i nostri computer hanno due o quattro, o anche otto, core sul desktop e otto e 12 e più su, sai, i 16 e 32 anche nella piattaforma server . Ma in realtà è una cosa abbastanza moderna che i core sono diventati una capacità all'interno delle CPU e che siamo passati da 32 bit a 64 bit. Lì sono successe un paio di cose importanti: abbiamo ottenuto velocità di clock più elevate su più core in modo da poter fare le cose in parallelo e ognuno di quei core poteva eseguire più thread. All'improvviso abbiamo potuto eseguire molte cose sugli stessi dati contemporaneamente. La spaziatura degli indirizzi a sessantaquattro bit ci ha dato fino a due terabyte di RAM, che è un concetto fenomenale, ma ora è una cosa. Queste architetture backplane multipath, sai, schede madri, una volta, potevi fare le cose solo in una direzione: avanti e indietro. E come ai tempi con il Cray computing e alcuni dei progetti di supercomputer di quel tempo, e ora nei computer desktop e nei comuni PC pronti per l'uso, montati su rack, perché davvero, la maggior parte dei moderni I PC hanno attraversato questa era di mainframe, midrange e micro desktop e li abbiamo trasformati in server.
E molte di quelle capacità di supercomputer, quel design di livello supercomputer, sono state spinte in componenti standard già disponibili. Sai, in questi giorni, l'idea di prendere PC economici montati su rack e metterli in rack a centinaia, se non migliaia, e di eseguire software open source su di essi come Linux e di implementare simili SAP HANA su di te, tu sai, spesso lo diamo per scontato. Ma questa è una cosa molto nuova ed eccitante e viene fornita con le sue complessità.
Anche il software è migliorato, in particolare la gestione della memoria e il partizionamento dei dati. Non entrerò in molti dettagli al riguardo, ma se osservi il grande cambiamento negli ultimi 15 anni o anche meno, come viene gestita la memoria, in particolare i dati nella RAM e come i dati vengono partizionati nella RAM, in modo che, come ha indicato il dottor Robin Bloor in precedenza o alluso, le cose possono leggere e scrivere allo stesso tempo senza influenzarsi a vicenda, piuttosto che avere tempi di attesa. Molte funzionalità molto potenti come la compressione e la crittografia su chip. La crittografia sta diventando una cosa più importante e non dobbiamo necessariamente farlo nel software, nella RAM, nello spazio della CPU, ora che in realtà avviene sul chip in modo nativo. Ciò accelera notevolmente le cose. E l'archiviazione e l'elaborazione dei dati distribuiti, ancora una volta, cose che una volta assumevamo fossero roba da supercomputer ed elaborazione parallela, ora lo diamo per scontato nello spazio di SAP HANA, Hadoop e Spark e così via.
Quindi, il punto centrale di questo è questo calcolo ad alte prestazioni, le capacità di HPC sono arrivate all'azienda e ora l'azienda sta godendo i vantaggi che ne derivano in termini di guadagni in termini di prestazioni e spazio tecnologico e vantaggi tecnici e guadagni commerciali, perché, sai, il tempo di valutazione ridotto viene drasticamente ridotto.
Ma uso questa immagine di una storia che ho letto qualche tempo fa di un gentiluomo che ha realizzato un case per PC con Lego, perché mi viene sempre in mente quando penso ad alcune di queste cose. Ed è quello, sembra una grande idea quando inizi a costruirlo, e poi ci riesci a metà strada e ti rendi conto che in realtà è davvero complicato mettere insieme tutti i pezzi di Lego e creare una cosa solida, abbastanza solida mettere una scheda madre e così via, che costruirà un caso per un personal computer. E alla fine ti rendi conto che tutti i pezzetti non si attaccano bene e devi stare un po 'attento a quali pezzetti ti unisci per renderlo solido. Ed è un'idea molto carina, ma è una sveglia quando arrivi a metà strada e ti rendi conto, "Hmm, forse avrei dovuto comprare un case per PC da $ 300, ma lo finirò ora e imparerò qualcosa da esso."
Per me questa è una grande analogia per com'è costruire queste piattaforme molto complesse, perché va bene e bene costruirlo e finire con un ambiente in cui hai router, switch, server e rack. E hai CPU, RAM e sistema operativo raggruppati insieme. E ci metti qualcosa come HANA sopra per l'elaborazione distribuita in memoria e l'archiviazione e la gestione dei dati. Oltre a ciò, si crea lo stack SAP, si ottengono le funzionalità del database, quindi si caricano i dati e la logica aziendale e si inizia ad applicare alcune letture, scritture e query e così via. Devi tenerti aggiornato sull'I / O e devi pianificare le cose e gestire i carichi di lavoro e la multi-tenancy e così via. Questo stack diventa molto complesso, molto rapidamente. Questo è uno stack complesso in sé se è solo su una macchina. Moltiplicalo per 16 o 32 macchine, diventa molto, molto banale. Quando si moltiplicano fino a centinaia e infine migliaia di macchine, per passare da 100 terabyte a una scala di petabyte, è un concetto spaventoso e queste sono le realtà con cui abbiamo a che fare ora.
Quindi, finisci con un paio di cose che hanno anche contribuito a cambiare questo mondo, e cioè che lo spazio su disco è diventato ridicolmente economico. Sai, una volta spendii da 380 a 400 mila dollari su un gigabyte di hard disk quando era un tamburo enorme delle dimensioni di un - qualcosa che aveva bisogno di un carrello elevatore per raccoglierlo. Al giorno d'oggi, si tratta di una o due centesimi per gigabyte di spazio su disco. E RAM ha fatto la stessa cosa. Queste due curve a J in entrambi questi grafici, tra l'altro, sono un decennio ciascuna, quindi in altre parole, stiamo osservando due blocchi di 10 anni, 20 anni di riduzione del prezzo. Ma li ho suddivisi in due curve a J perché alla fine quella a destra è diventata una linea tratteggiata e non è stato possibile vedere i dettagli, quindi l'ho ridimensionata. Un gigabyte di RAM 20 anni fa era qualcosa nell'ordine di sei milioni e mezzo di dollari. In questi giorni, se si pagano più di tre o quattro dollari per un gigabyte di RAM per l'hardware delle materie prime, si viene derubati.
Questo significativo crollo della riduzione dei prezzi negli ultimi due decenni ha fatto sì che ora possiamo andare oltre lo spazio su disco e passare direttamente alla RAM, non solo a livello di megabyte, ma ora a livello di terabyte e trattare la RAM come se fosse un disco. La sfida, tuttavia, era che la RAM era nativamente effimera - ciò significa qualcosa che dura per un breve periodo di tempo - quindi, abbiamo dovuto trovare modi per fornire resilienza in quello spazio.
E quindi, il mio punto qui è che il calcolo in memoria non è per i deboli di cuore. Destreggiarsi con questi dati in memoria su larga scala e l'elaborazione attorno ad essi è una sfida interessante; come ho indicato prima, non è per i deboli di cuore. Quindi, una cosa che abbiamo imparato da questa esperienza con il calcolo in-memory su larga scala e ad alta densità è che la complessità che costruiamo genera rischi in una serie di aree.
Ma guardiamolo da un punto di vista del monitoraggio e della risposta. Quando pensiamo ai dati, iniziano nello spazio su disco, si trovano in database nei dischi, li inseriamo nella memoria. Una volta che è in memoria e distribuito e ce ne sono copie, possiamo usarne molte copie e, se vengono apportate modifiche, può essere riflesso a livello di memoria invece di dover accendere e spegnere e attraversare il backplane a due diversi livelli, entra e esce dalla memoria. Abbiamo finito con questa piattaforma hardware iperscale che ci consente di farlo ora. Quando parliamo di iperscaling, è più difficile a livelli ridicolmente densi e memoria ad altissima densità, conteggi ad altissima densità di CPU, core e thread. Ora abbiamo patologie di rete molto complesse per supportare questo perché i dati devono spostarsi attraverso la rete a un certo punto se vanno tra i nodi e i cluster.
Quindi, finiamo con la ridondanza dei guasti del dispositivo che diventa un problema e dobbiamo monitorare dispositivi e pezzi di esso. Dobbiamo avere una ridondanza di errore dei dati resiliente integrata su quella piattaforma e monitorarla. Dobbiamo avere la resilienza del database distribuito integrata, quindi dobbiamo monitorare la piattaforma del database e impilarla all'interno. Dobbiamo monitorare la pianificazione dell'elaborazione distribuita, ciò che sta accadendo all'interno di alcuni processi fino al polling e alla query e il percorso che la query prende e il modo in cui la query viene strutturata ed eseguita. Che aspetto ha, qualcuno ha fatto un SELECT * su "blah" o ha effettivamente fatto una query molto intelligente e ben strutturata che otterrà la quantità minima nominale di dati che attraversa l'architettura nel backplane? Abbiamo carichi di lavoro multi-tenancy, più utenti e più gruppi che eseguono gli stessi o più carichi di lavoro e processi batch e la pianificazione in tempo reale. E abbiamo questa miscela di elaborazione batch e in tempo reale. Alcune cose funzionano regolarmente - ogni ora, ogni giorno, settimanalmente o mensilmente - altre cose sono richieste. Qualcuno potrebbe essere seduto lì con un tablet che vuole fare un rapporto in tempo reale.
E ancora una volta, arriviamo a quel punto, che la complessità che si presenta in questi non è solo una sfida ora, è piuttosto spaventosa. E abbiamo questo controllo di realtà che un singolo problema di prestazioni, solo un problema di prestazioni a sé stante, può avere un impatto sull'intero ecosistema. E così, finiamo con questa sfida molto divertente di scoprire, beh, dove sono gli impatti? E abbiamo questa sfida: siamo reattivi o proattivi? Stiamo guardando la cosa in tempo reale e vedendo qualcosa che va "a sbattere" e rispondendo ad essa? Oppure abbiamo visto una qualche forma di tendenza e ci siamo resi conto che dobbiamo affrontarla in modo proattivo? Perché la chiave è che tutti vogliono qualcosa di veloce, economico e facile. Ma finiamo con questi scenari, ciò a cui mi piace fare riferimento e la mia linea preferita dell'enigma di Donald Rumsfeld - che nella mia mente si applica in tutti questi scenari di elevata complessità - e cioè che abbiamo conosciuto dei noti perché è qualcosa abbiamo progettato e costruito e funziona come previsto. Abbiamo conosciuto incognite in quanto non sappiamo chi gestisce cosa, quando e dove, se richiesto. E abbiamo incognite sconosciute e quelle sono le cose che dobbiamo monitorare e verificare. Perché la realtà è, lo sappiamo tutti, non puoi gestire qualcosa che non puoi misurare.
Quindi, per avere gli strumenti giusti e la giusta capacità di monitorare la nostra programmazione della CPU, cercare i tempi di attesa, scoprire perché le cose devono aspettare nelle code di pianificazione nelle condutture. Cosa sta succedendo nella memoria, che tipo di utilizzo viene eseguito, che tipo di prestazioni stiamo esaurendo la memoria? Le cose vengono partizionate correttamente, vengono distribuite, abbiamo abbastanza nodi che ne tengono copie per far fronte ai carichi di lavoro che vengono lanciati? Cosa succede con l'esecuzione del processo lontano dai processi del sistema operativo? I lavori stessi in esecuzione, le singole app e i demoni che li supportano? Che cosa sta accadendo all'interno di questi processi, in particolare la strutturazione delle query e come vengono eseguite e compilate tali query? E la salute di quei processi fino in fondo nello stack? Sai, ancora una volta, tornare ai tempi di attesa, sta pianificando correttamente, deve aspettare, dove sta aspettando, è in attesa di letture di memoria, I / O, CPU, I / O attraverso la rete per l'utente finale ?
E poi di nuovo a quel punto che ho appena citato poco prima di concludere e cioè, come ci stiamo avvicinando alla risoluzione dei problemi e ai tempi di risposta a quelli? Stiamo guardando in tempo reale e reagendo alle cose, che è lo scenario meno ideale, ma anche allora, è meglio farlo che non sapere e avere l'help desk chiamare e dire che qualcosa è andato storto e dobbiamo rintracciarlo ? O lo stiamo facendo in modo proattivo e stiamo osservando cosa sta succedendo? Quindi, in altre parole, stiamo vedendo che siamo a corto di memoria e abbiamo bisogno di aggiungere più nodi? Stiamo facendo analisi delle tendenze, stiamo pianificando la capacità? E in tutto ciò, stiamo monitorando i tempi di esecuzione storici e pensando alla pianificazione della capacità o la stiamo guardando in tempo reale e riprogrammando e facendo il bilanciamento del carico in modo proattivo? E siamo a conoscenza dei carichi di lavoro in esecuzione in primo luogo? Sappiamo chi sta facendo cosa nel nostro cluster e perché?
I calcoli in memoria sono molto potenti, ma con quel potere è quasi una di quelle cose, come una pistola carica e stai giocando con munizioni dal vivo. Alla fine puoi spararti al piede se non stai attento. Quindi, la potenza del calcolo in memoria significa solo che possiamo eseguire molto di più e rapidamente su set di dati molto distribuiti e discreti. Ma poi ciò ha una domanda più elevata guidata dagli utenti finali. Si abituano a quel potere e lo vogliono. Non si aspettano più che i lavori richiedano settimane per essere eseguiti e i rapporti vengono pubblicati su carta semplice. E poi, al di sotto di tutto ciò, abbiamo la manutenzione quotidiana circondata da patch, aggiornamenti e upgrade. E se pensi all'elaborazione 24/7 con elaborazione in memoria, gestione di quei dati, gestione dei carichi di lavoro su di essi, è tutto in memoria, tecnicamente in piattaforma effimera, se inizieremo ad applicare patch, aggiornamenti e upgrade in lì, ciò comporta anche tutta una serie di altre sfide di gestione e monitoraggio. Dobbiamo sapere cosa possiamo mettere offline, quando possiamo aggiornarlo e quando lo riportiamo online. E questo mi porta al mio ultimo punto e cioè che quando otteniamo sempre più complessità in questi sistemi, non è qualcosa che un essere umano può fare semplicemente succhiando il pollice e tirando più l'orecchio. Non ci sono più approcci di tipo intestino. Abbiamo davvero bisogno degli strumenti adeguati per gestire e fornire questo elevato livello di prestazioni nella gestione di elaborazione e dati.
E con questo in mente, consegnerò il nostro amico di IDERA e ascolterò come hanno affrontato questa sfida.
Bill Ellis: Mille Grazie. Sto condividendo il mio schermo e qui andiamo. Quindi, è davvero umiliante considerare solo tutta la tecnologia, e tutte le persone che ci hanno preceduto, per rendere disponibili queste cose che sono disponibili nel 2017. Parleremo dell'analisi del carico di lavoro per SAP HANA - in sostanza, una soluzione di monitoraggio del database: completa, senza agenti, fornisce in tempo reale e costruisce una cronologia, in modo da poter vedere cosa è successo in passato. SAP S / 4 HANA offre il potenziale per un migliore, più veloce ed economico. Non sto dicendo che è economico, sto solo dicendo che è meno costoso. Un po ', tradizionalmente, ciò che è accaduto è che avresti avuto un'istanza di produzione principale - probabilmente in esecuzione su Oracle in un negozio più grande, potenzialmente SQL Server - e quindi avresti usato quel processo ETL e avresti avuto più versioni di verità . E questo è molto costoso perché stavi pagando hardware, sistema operativo, licenza Oracle per ognuno di questi singoli ambienti. E poi dovresti avere delle persone per conciliare una versione della verità con la versione successiva della verità. E così, questa elaborazione ETL a versione multipla era solo lenta e molto ingombrante.
E così, HANA, sostanzialmente un'istanza di HANA, può potenzialmente sostituire tutte quelle altre istanze. Quindi, è meno costoso perché è una piattaforma hardware, un sistema operativo, anziché multipli. E così S / 4 HANA, in realtà, cambia tutto e in pratica stai osservando l'evoluzione di SAP da R / 2 a R / 3, i vari pacchetti di miglioramento. Ora, il sistema legacy è disponibile fino al 2025, quindi hai otto anni per essere davvero costretto a migrare. Anche se vediamo persone, sai, che si dilettano in questo perché sanno che sta arrivando e alla fine, sai, ECC funzionerà su HANA e quindi avresti davvero bisogno di essere preparato a questo e capire la tecnologia.
Quindi, un database, nessun processo ETL, nessuna copia da riconciliare. Quindi, ancora una volta, più veloce, migliore e più economico. HANA è in memoria. SAP fornisce il software, tu fornisci l'hardware. Non ci sono tabelle aggregate. Una delle cose che, in un certo senso, suggeriscono quando stai pensando a questo è che non vuoi entrare in questo, stiamo solo per acquistare il server più grande disponibile. Ti suggeriscono, in un certo senso, di dimensionare in anticipo il tuo panorama SAP in anticipo e in pratica dicono di non migrare dati di 20 anni. Penso che l'archiviazione sia qualcosa di sottoutilizzato nell'IT, in un certo senso, su tutta la linea, non solo nei negozi SAP. Quindi la prossima cosa è che SAP ha effettivamente impiegato molto tempo a riscrivere il proprio codice nativo per non utilizzare SELECT *. SELECT * restituisce tutte le colonne dalla tabella ed è particolarmente costoso in un database colonnare. E quindi, non è una buona idea per SAP HANA. Quindi, per i negozi che hanno molte personalizzazioni, molti report, questo è qualcosa che vorrai cercare e vorrai specificare i nomi delle colonne mentre procedi con la migrazione di tutto su HANA.
Ci piace dire che HANA non è una panacea. Come tutti i database, tutte le tecnologie, deve essere monitorato e, come accennato in precedenza, sono necessari numeri per gestire l'eccesso, misurazione per misurazione. E una delle cose di cui parlo nell'area IDERA è che ogni transazione commerciale interagisce con il sistema di registrazione e, in questo caso, sarà HANA. E così, HANA diventa la base per l'esecuzione delle tue transazioni SAP, l'esperienza dell'utente finale. Pertanto, è fondamentale che continui a funzionare alla massima velocità. Diventa un singolo punto di errore, e nel parlare con la gente, questo è qualcosa che può sorgere dove hai un utente finale e forse sta usando quei dati in tempo reale e hanno una query ad hoc che potenzialmente non è del tutto giusto. Forse non stanno unendo i tavoli e hanno creato un join esterno, un prodotto partigiano e sostanzialmente stanno consumando molte risorse. Ora, HANA lo riconoscerà alla fine e ucciderà quella sessione. E quindi c'è la parte cruciale della nostra architettura che ti consentirà di catturarlo nella storia, così puoi vedere cosa è successo in passato e riconoscere quelle situazioni.
Diamo quindi un'occhiata all'analisi del carico di lavoro per SAP HANA. Questa è la versione 1, quindi ti invitiamo moltissimo a unirti a noi nel viaggio, e questo è un prodotto di IDERA. È completo, ma semplice. In tempo reale con le tendenze. Integrità dell'host, integrità dell'istanza. Tracciamo gli stati di attesa, le query SQL, i consumatori di memoria e i servizi. Quindi, ecco come appare la GUI e puoi vedere subito che è abilitato per il web. In realtà ho aperto questa soluzione in esecuzione sul mio sistema. Ci sono alcune cose cruciali che vuoi dare un'occhiata. Abbiamo, in qualche modo, suddiviso in diverse aree di lavoro. Il tipo più cruciale è quello che sta accadendo a livello di host da un utilizzo della CPU e dall'utilizzo della memoria. Sicuramente non vuoi arrivare ad un punto di vista di scambio o thrashing. E poi fondamentalmente scendi verso quello che sta succedendo in trend, dai tempi di risposta, agli utenti, alle istruzioni SQL, cioè a cosa sta guidando l'attività sul sistema.
Una delle cose con IDERA è che, sai, non succede nulla su un database fino a quando non c'è attività. E quell'attività sono istruzioni SQL che provengono dall'applicazione. Quindi, misurare le istruzioni SQL è assolutamente vitale per poter rilevare la causa principale. Quindi, andiamo avanti e approfondiamo. Quindi, a livello di host, possiamo effettivamente dare un'occhiata alla memoria, tracciare nel tempo, l'utilizzo della CPU dell'host. Un passo indietro, puoi guardare le istruzioni COBSQL. Ora, una delle cose che vedrai nel nostro lato dell'architettura è che queste informazioni sono archiviate al di fuori di HANA, quindi se qualcosa dovesse accadere a HANA, fondamentalmente stiamo acquisendo informazioni fino a, Dio non voglia, una situazione di indisponibilità . Possiamo anche catturare tutto ciò che accade sul sistema in modo da avere una chiara visibilità. E una delle cose che faremo è presentare le istruzioni SQL in ordine ponderato. Quindi, questo prenderà in considerazione il numero di esecuzioni, e quindi questo è il consumo di risorse aggregate.
E così puoi entrare in singole metriche qui - quando è stata eseguita quell'istruzione SQL? E quindi il consumo di risorse è in gran parte guidato dal piano di esecuzione, e quindi siamo in grado di catturarlo su base continuativa. HANA è in memoria. È altamente parallelo. Ha indici primari su ogni tabella, che alcuni negozi scelgono di costruire un indice secondario per affrontare determinati problemi di prestazioni. E così, in qualche modo, sapere cosa è successo con il piano di esecuzione per determinate istruzioni SQL può essere molto prezioso. Esamineremo anche i servizi, il consumo di memoria ancora una volta, tracciato nel tempo. L'architettura: quindi, questa è una soluzione autonoma che puoi scaricare dal nostro sito Web e l'architettura è abilitata per il web.
Puoi avere più utenti connessi a un'istanza specifica. È possibile monitorare le istanze locali di SAP HANA. E conserviamo una cronologia di quattro settimane nel nostro repository, autogestita. Per distribuire questo, è piuttosto semplice. È necessario un server Windows. Devi scaricarlo. La maggior parte dei server Windows avrà un framework .NET incorporato e viene fornito in bundle con una licenza. E così andresti alla procedura guidata di installazione che è guidata da Setup.exe e in realtà si aprirà una schermata, un accordo di licenza, e semplicemente faresti questo schema facendo clic su "Avanti". E quindi, dove vorresti che HANA essere installato? Successivamente ci sono le proprietà del database e questa sarà la tua connessione a SAP HANA, quindi questo è il monitoraggio senza agenti dell'istanza HANA. E poi in pratica daremo un'anteprima, questa è la porta su cui comunichiamo di default. Fai clic su "Installa" e fondamentalmente avvia HANA e inizi a costruire la cronologia. Quindi, solo un po 'di informazioni sulla tabella delle taglie. Siamo in grado di monitorare fino a 45 istanze HANA e ti consigliamo di utilizzarlo su una scala mobile per determinare il numero di core, memoria e spazio su disco di cui avrai bisogno. E questo presuppone che tu abbia una cronologia completa a rotazione di quattro settimane.
Quindi, proprio come un breve riepilogo, stiamo esaminando l'integrità del server, l'integrità dell'istanza e l'utilizzo della CPU / memoria. Quali sono i consumatori di memoria, quali sono i driver di attività, quali sono i servizi? Le istruzioni SQL sono fondamentali: quali sono gli stati di esecuzione? Mostrami i piani di esecuzione, quando sono state eseguite le cose, hanno dato tendenza? Questo ti darà in tempo reale e una storia di quello che era successo. E come ho già detto, poiché la nostra storia è separata da quella di HANA, cattureremo cose che erano scadute ed erano state cancellate dalla storia di HANA. In modo che tu possa vedere il vero consumo di risorse sul tuo sistema a causa della cronologia separata.
Quindi, come ho già detto, il sito Web di IDERA, sotto Prodotti, lo puoi trovare facilmente. Se vuoi provarlo, sei sicuramente il benvenuto. Guarda come ti fornisce informazioni e ci sono ulteriori informazioni su quel sito web. Quindi, tutte le parti interessate sono più che felici di entrare in questo. Ora, nei prodotti in portafoglio offerti da IDERA, esiste anche un monitor delle transazioni SAP ECC, e questo si chiama Preciso per SAP. E quello che fa è, sia che tu stia utilizzando il portale o semplicemente ECC diretto, acquisirà effettivamente la transazione dell'utente finale dal clic al disco, fino all'istruzione SQL e ti mostrerà cosa sta succedendo.
Ora ti sto mostrando solo una schermata di riepilogo. Ci sono un paio di cose da asporto che voglio che tu abbia da questa schermata di riepilogo. È il tempo di risposta dell'asse Y, il tempo dell'asse X più il giorno, e in questa vista della transazione mostreremo il tempo del cliente, il tempo di accodamento, il tempo del codice ABAP, il tempo del database. Siamo in grado di acquisire ID utente finale, codici T e puoi effettivamente filtrare e mostrare i server attraverso una particolare transazione attraversata. E così, molti negozi gestiscono il front-end del paesaggio con VMware, quindi puoi effettivamente misurare ciò che sta accadendo su ciascuno dei server e ottenere analisi molto dettagliate. Pertanto, questa vista della transazione è per la transazione dell'utente finale attraverso l'intero panorama SAP. E puoi trovarlo sul nostro sito Web in Prodotti Strumenti APM e questa sarebbe la soluzione SAP che abbiamo. L'installazione per questo è un po 'più complicata, quindi non si tratta solo di scaricarla e provarla, come abbiamo fatto per HANA. Questo è qualcosa in cui collaboreremmo per fare, progettare e implementare la transazione complessiva per te.
Quindi, solo un terzo riepilogo rapido, analisi del carico di lavoro per SAP HANA, è completo, senza agenti, in tempo reale, offre una cronologia. Offriamo la possibilità di scaricare e provare per il tuo sito.
Quindi, con quello, passerò il tempo indietro a Eric, Dez e il dottor Bloor.
Eric Kavanagh: Sì, forse Robin, qualche domanda da parte tua, e poi Dez dopo Robin?
Dr. Robin Bloor: Ok. Voglio dire, la prima cosa che vorrei dire è che mi piace molto la vista delle transazioni perché è esattamente quello che vorrei in quella situazione. Ho fatto molto lavoro - beh, è passato molto tempo fa - facendo il monitoraggio delle prestazioni, ed è stato il genere di cose; non avevamo la grafica in quei giorni, ma era il tipo di cosa che volevo particolarmente poter fare. In modo che tu, in un modo o nell'altro, ti possa iniettare ovunque si verifichi il problema.
La prima domanda che ho è, sai, molte persone stanno implementando S / 4 in un modo o nell'altro, lo sai. Quando sei stato coinvolto in una determinata implementazione di S / 4, hai scoperto che è stato implementato bene o finisci, sai, scoprendo cose che potrebbero far desiderare la riconfigurazione del cliente? Voglio dire, come va tutto questo?
Bill Ellis: Beh, ogni negozio è un po 'diverso. E ci sono diversi modelli di utilizzo, ci sono diversi rapporti. Per i siti che hanno rapporti ad hoc, intendo che in realtà è un po 'come un jolly sul sistema. Quindi, una delle cose cruciali è iniziare la misurazione e scoprire qual è la linea di base, cosa è normale per un determinato sito, dov'è quel particolare sito, in base ai loro modelli di utilizzo, sottolineando il sistema. E quindi apportare modifiche da lì. In genere l'ottimizzazione del monitoraggio non è una tantum, è in realtà una pratica in corso in cui si sta monitorando, ottimizzando, perfezionando, rendendo il sistema migliore affinché la comunità degli utenti finali sia in grado di servire l'azienda in modo più efficace.
Dr. Robin Bloor: Okay, quindi quando realizzi - voglio dire, so che è una domanda a cui è difficile rispondere perché varierà a seconda delle dimensioni dell'implementazione - ma quante risorse ha la capacità di monitoraggio IDERA, quanto consuma ? Fa qualche differenza o no, semplicemente non interferisce? Come funziona?
Bill Ellis: Sì, direi che il sovraccarico è all'1-3% circa. Molti negozi sono molto disposti a sacrificarlo perché potenzialmente sarai in grado di riacquistarlo in termini di ottimizzazione. Dipende dai modelli di utilizzo. Se stai realizzando un panorama completo, dipende dalle singole tecnologie che vengono monitorate. Quindi, in qualche modo, il chilometraggio varia, ma come abbiamo già detto, è sicuramente meglio spendere un po 'per sapere cosa sta succedendo, piuttosto che correre alla cieca. In particolare, lo sai, eccoci qui a gennaio e inizi a elaborare il fine settimana e stai aggregando 12 mesi di dati. Sai, fare performance, far arrivare relazioni agli organismi regolatori, alle banche, agli azionisti, è assolutamente vitale in una performance aziendale critica.
Dr. Robin Bloor: Giusto. E solo in fretta, dal tuo punto di vista - perché immagino che tu sia coinvolto in un'intera serie di siti SAP - quanto è grande il movimento tra la base di clienti SAP verso S / 4? Voglio dire, è qualcosa che è, sai, che c'è una specie di valanga di clienti entusiasti che lo stanno provando, o è solo una goccia costante? Come lo vedi?
Bill Ellis: Penso che un paio di anni fa, direi che era un dito del piede. Ora direi che le persone sono, in un certo senso, fino al ginocchio. Penso che, dato il calendario, le persone saranno davvero immerse in HANA nei prossimi due anni. E quindi il monitoraggio, la trasformazione, sai, penso che la maggior parte dei clienti sia, in un certo senso, sulla curva di apprendimento insieme. E quindi penso che non siamo del tutto alla valanga come avevi dichiarato, ma penso che siamo sulla cuspide della grande trasformazione in HANA.
Dr. Robin Bloor: Okay, quindi in termini di siti che hai visto che sono andati per questo, stanno anche adattando HANA per altre applicazioni o, in un modo o nell'altro, sono completamente consumati nel realizzare questo roba di lavoro? Qual è l'immagine lì?
Bill Ellis: Sì, spesso le persone integrano SAP con altri sistemi, a seconda dei moduli e così via, quindi c'è un po '. In realtà non vedo ancora persone che distribuiscono altre applicazioni su HANA. È certamente possibile farlo. E quindi è più intorno al panorama intorno all'infrastruttura SAP.
Dr. Robin Bloor: Suppongo che farò meglio a consegnarti a Dez. Ti sto prendendo in giro. Dez?
Dez Blanchfield: grazie. No, va tutto bene. Due molto veloci, solo per cercare di impostare il tema. SAP HANA è in circolazione da un paio d'anni e le persone hanno avuto la possibilità di prenderlo in considerazione. Se dovessi darci una stima approssimativa della percentuale di persone che la gestiscono - perché ci sono molte persone che gestiscono questa roba - cosa pensi che la percentuale di mercato di cui sei a conoscenza è attualmente che è andata dalle semplici implementazioni SAP tradizionali a SAP su HANA? Stiamo guardando 50/50, 30/70? Qual è, in qualche modo, la percentuale del mercato che vedi delle persone che hanno effettuato la transizione e si sono mosse ora rispetto alle persone che stanno semplicemente trattenendo e aspettando che le cose migliorino o migliorino o cambino o qualunque sia il caso?
Bill Ellis: Sì, in realtà avrei messo, dal mio punto di vista, la percentuale intorno al 20 percento. SAP tende ad essere attività tradizionali. Le persone tendono ad essere molto conservatrici e quindi la loro gente trascinerà i piedi. Penso che dipenda anche da, sapete, che gestite SAP da molto tempo o siete un tipo di PMI che forse aveva implementato SAP più di recente? Quindi, ci sono una serie di fattori, ma nel complesso non credo che la percentuale sia 50/50. Direi che il 50 percento sta almeno dilettando e ha HANA in esecuzione da qualche parte nel loro data center.
Dez Blanchfield: L'interessante da asporto che ci hai dato in precedenza era che questo è un fatto compiuto in un certo senso e che il tempo passa fisicamente e letteralmente al momento della transizione. Nel processo di farlo, pensi che la gente l'abbia considerato? Qual è il senso generale della comprensione popolare che questo è uno spostamento di transizione nella piattaforma, non è solo un'opzione, sta diventando l'impostazione predefinita?
E dal punto di vista di SAP, sono sicuro che stanno spingendo in quel modo perché c'è un significativo vantaggio competitivo nelle prestazioni, ma è anche, suppongo, stanno lottando contro il controllo della piattaforma invece che andare a un terzo- database di party, ora lo stanno riportando sulla propria piattaforma. Pensi che le aziende abbiano effettivamente ricevuto quel messaggio? Pensi che la gente lo capisca e ora lo stanno preparando? O è ancora, in qualche modo, una cosa poco chiara, pensi, fuori dal mercato?
Bill Ellis: Non credo che SAP sia timido nel comunicare e le persone che sono andate a SAPPHIRE hanno visto HANA ovunque. Quindi, penso che le persone siano ben consapevoli, ma essendo la natura umana ciò che è, sai, alcune persone, in qualche modo, trascinano un po 'i piedi.
Dez Blanchfield: Perché penso il motivo per cui stavo ponendo quella domanda, e dovrai perdonarmi, ma è che sono d'accordo. Penso che non siano stati timidi nel comunicarlo. Penso che il segnale sia uscito in molti modi. E sono d'accordo con te - non so che tutti siano ancora saltati. Sai, le imprese tradizionali, le grandi imprese che gestiscono questo, sono ancora in molti modi, non trascinando completamente i piedi, ma solo cercando di affrontare la complessità del turno. Perché penso che l'unica cosa che il tuo strumento, e certamente la tua dimostrazione di oggi abbia messo in evidenza, e per me, una chiave da asporto, vorrei che tutti ascoltassero e si sintonizzassero oggi per sedersi e prestare attenzione in modo riflessivo, hai un strumento ora che ha semplificato quel processo nella mia mente. Penso che ci siano un sacco di CIO molto nervosi e i loro team sotto di loro che stanno pensando: "Come faccio a passare dal tradizionale RDBMS, sistemi di gestione di database relazionali, che conosciamo da decenni, a un nuovo paradigma di elaborazione e gestione dello storage in uno spazio ancora relativamente coraggioso? "nella mia mente. Ma è sconosciuto in molti modi e ci sono pochissime persone che hanno fatto questo spostamento in altre aree, che non è come se avessero un'altra sezione di business che ha già fatto un passaggio al calcolo in memoria. Quindi, è una mossa del tutto o niente nella loro mente.
Quindi, una delle cose che ho tolto da questo più di ogni altra cosa - ti colpirò con una domanda tra un minuto - è che la paura ora, penso, è dissipata in molti modi e che prima di oggi, se fossi un ascoltatore del CIO, penserei, in un certo senso, “Bene, come farò questa transizione? Come garantirò la stessa capacità che abbiamo nella piattaforma di gestione del database relazionale e anni di esperienza dei DBA, a una nuova piattaforma in cui non abbiamo le competenze attualmente? ”Quindi, la mia domanda è che, pensi che le persone abbiano capito che gli strumenti ci sono ora con quello che stai offrendo e che possono, in un certo senso, fare un respiro profondo e sospirare di sollievo che la transizione non è così spaventosa come avrebbe potuto essere prima a questo strumento è disponibile? Pensi che le persone abbiano capito che o è ancora, in qualche modo, una cosa che stanno solo affrontando con il passaggio al calcolo in-memory e all'archiviazione in-memory rispetto alle combinazioni di vecchia scuola di NVMe, flash e disk?
Bill Ellis: Sì, quindi c'è indubbiamente molta tecnologia e strumenti che possono mostrare graficamente questo, cosa sta succedendo e rendere molto semplice individuare i migliori consumatori di risorse. Voglio dire, aiuta a semplificare le cose e aiuta il personale della tecnologia ad avere una buona padronanza. Ehi, saranno in grado di sapere cosa sta succedendo e saranno in grado di comprendere tutta la complessità. Quindi, assolutamente, gli strumenti sul mercato sono sicuramente utili e quindi offriamo l'analisi del carico di lavoro per SAP HANA.
Dez Blanchfield: Sì, penso che la cosa grandiosa di ciò che ci hai mostrato oggi è che, nel monitorare il componente hardware, il componente del sistema operativo, anche monitorare parte del carico di lavoro che si muove attraverso, come hai detto, intendo, gli strumenti ci sono stato per un po 'di tempo. La cosa per me, in particolare all'interno di artisti del calibro di HANA, è che non abbiamo necessariamente avuto la possibilità di ottenere una lente d'ingrandimento e sbirciare dentro e vedere fino a che cosa fa il tuo strumento con ciò che sta accadendo con le query e come sono essere strutturato e dove si trova quel carico.
Con le distribuzioni che hai visto finora, dato che sei letteralmente il più autorevole in questo spazio nella tua piattaforma al mondo, alcune delle vittorie veloci che hai visto - hai qualche conoscenza aneddotica con cui puoi condividere attorno ad alcuni dei momenti di eureka, i momenti di aha, in cui le persone hanno distribuito il set di strumenti IDERA, hanno trovato cose che non erano a conoscenza delle loro piattaforme e delle loro esibizioni. Hai avuto grandi esempi aneddotici di dove le persone lo hanno appena distribuito, non sapendo davvero cosa hanno avuto e all'improvviso sono andati "Wow, in realtà non sapevamo che fosse lì?"
Bill Ellis: Sì, quindi una grande limitazione degli strumenti nativi è che se una query in fuga viene annullata, cancella le informazioni e quindi praticamente non hai la cronologia. Memorizzando la cronologia offline, come una query in fuga, avrai una cronologia, saprai cos'era successo, sarai in grado di vedere il piano di esecuzione e così via. E così, ciò ti consente, in un certo senso, di aiutare la comunità degli utenti finali a funzionare meglio, a scrivere report meglio, eccetera. E così, la storia è qualcosa di veramente bello da avere. E una delle cose che avevo intenzione di mostrare è che puoi guardare in tempo reale fino a quattro settimane e quindi puoi facilmente ingrandire qualsiasi periodo di interesse e quindi esporre l'attività di guida sottostante. Avere quella visibilità è qualcosa di molto utile per sapere quale sia il collo di bottiglia.
Dez Blanchfield: Hai detto che è multiutente, una volta che è stato distribuito, e sono rimasto piuttosto colpito dal fatto che è privo di agenti ed efficacemente zero touch in molti modi. È normale che un'unica distribuzione del tuo strumento sia quindi disponibile per tutti, dal centro operativo di rete del NOC, guardando l'infrastruttura di base alla base del cluster fino al team di applicazione e sviluppo? È la norma e la distribuisci una volta e la condivideranno, o prevedi che le persone potrebbero avere istanze del modello che guardano diverse parti dello stack? Che aspetto ha?
Bill Ellis: Quindi, il team di base avrà in genere un forte interesse per le basi tecnologiche di ciò che sta accadendo in SAP. Ovviamente ci sono più team che supporteranno interi paesaggi. Il pezzo di HANA si concentra solo su questo. Ho appena impostato il team di base SAP come principale consumatore di informazioni.
Dez Blanchfield: Giusto. Mi colpisce, tuttavia, che se ho un team di sviluppo o non solo a livello di codice, ma se ho un team di data scientist o analisti che svolgono un lavoro analitico sui set di dati, in particolare dato che c'è una spinta significativa alla scienza dei dati applicata a tutto ciò che è all'interno delle organizzazioni ora, nella mia mente - e correggimi se sbaglio - mi sembra che questo sarà di grande interesse anche per loro, perché in molti modi uno delle cose serie che puoi fare in un ambiente di data warehouse è scatenare un data scientist su di esso e consentirgli di iniziare a fare query ad hoc. Hai mai avuto esempi di quel genere di cose che accadono in cui i negozi ti hanno telefonato e hai detto: "Abbiamo lanciato un team di data science, è davvero doloroso, cosa possiamo fare per loro rispetto a quello che stiamo facendo solo monitoraggio e gestione operativi tradizionali? ”È anche una cosa?
Bill Ellis: Beh, sì, vorrei in qualche modo ribaltare un po 'e tagliare la mia risposta sarebbe che, guardando le prestazioni, essendo consapevole delle prestazioni nello sviluppo della produzione di QA, sai, prima immagazzini, meno problemi, meno sorprese che hai. Quindi assolutamente.
Dez Blanchfield: A seguito di ciò, molti degli strumenti con cui ho avuto esperienza - e sono sicuro che Robin sarà d'accordo - molti degli strumenti qui, se hai un RDBMS di grandi dimensioni hai davvero bisogno di DBA qualificati, competenti e con esperienza. Alcuni dei requisiti di infrastruttura e piattaforma che derivano da SAP HANA perché è attualmente supportato su particolari distribuzioni che si allineano da un determinato hardware e così via, per quanto ne so. Sai, ci sono persone con decenni di esperienza che non sono le stesse. Quello che vedo, però, è che non è necessariamente il requisito con questo strumento. Mi sembra che tu possa distribuire il tuo strumento e darlo ad alcune facce abbastanza nuove e dargli immediatamente il potere di trovare cose che non funzionano bene. È possibile che ci sia una curva di apprendimento piuttosto breve per mettersi al passo con questo e ottenere un valore dall'implementazione? Sai, il mio senso generale è che non devi avere 20 anni di esperienza nella guida di uno strumento per vedere immediatamente il valore. Sei d'accordo che è il caso?
Bill Ellis: Oh, assolutamente, e secondo te, penso che gran parte del successo di una distribuzione dipenda davvero dalla pianificazione e dalla progettazione dell'ambiente SAP HANA. E poi c'è senza dubbio molta complessità, molta tecnologia su cui si basa, ma poi si riduce al monitoraggio dei modelli di utilizzo di ciò che sta accadendo. Quindi, sebbene sia più complesso, in un certo senso è impacchettato e in qualche modo semplificato. È molto povero.
Dez Blanchfield: Sì, quindi prima di restituire Eric, perché so che ha un paio di domande, in particolare da alcune domande e risposte che sembrano interessanti e sono ansioso di sentire la risposta. Viaggio tradizionale per qualcuno - hai detto in precedenza che puoi ottenerlo, puoi scaricarlo e provarlo. Riesci a ricapitolare così rapidamente per l'ascolto della gente o oggi o gente che potrebbe ripeterlo in seguito? Quali sono i due o tre passaggi rapidi per mettere le mani su una copia e distribuirla e provarla nei loro ambienti prima di acquistarla? Che aspetto ha? Quali sono i passaggi per questo?
Bill Ellis: Sì. Quindi, IDERA.com e vai su Prodotti e vedrai Analisi del carico di lavoro per SAP HANA. C'è una pagina di download. Penso che ti chiederanno alcune informazioni di contatto e il prodotto è appena impacchettato con una chiave di licenza in modo da poterlo installare con Setup.exe e iniziare, credo, molto rapidamente.
Dez Blanchfield: Quindi, possono visitare il tuo sito Web, possono scaricarlo. Ricordo di averlo visto qualche tempo fa e ho ricontrollato anche la scorsa notte, puoi richiedere una demo, a memoria, dove qualcuno nella tua squadra, in un certo senso, ti guiderà attraverso di essa? Ma puoi effettivamente scaricarlo gratuitamente e distribuirlo localmente nel tuo ambiente, ai tuoi tempi, vero?
Bill Ellis: Sì.
Dez Blanchfield: eccellente. Beh, penso che, più di ogni altra cosa, è probabilmente la cosa che consiglierei personalmente alla gente di fare, è prendere una copia dal sito Web, prendere una parte della documentazione lì perché so che ci sono molti buoni contenuti lì per farlo, e provalo. Mettilo nel tuo ambiente e vedi cosa trovi. Ho il sospetto che una volta che hai dato un'occhiata sotto gli occhi ai tuoi ambienti SAP HANA con lo strumento IDERA, troverai cose che in realtà non sapevi fossero lì.
Senti, grazie mille per quello e grazie per il tempo solo per le domande e risposte con Robin e I. Eric, ti riporterò indietro perché so che anche alcune domande e risposte sono arrivate dai nostri partecipanti.
Eric Kavanagh: Sì, proprio molto veloce qui. Quindi, uno dei partecipanti fa un ottimo commento qui solo parlando di come stanno cambiando le cose. Dicendo in passato, la memoria stava soffocando, rallentando con frequenti paging, attualmente la CPU sta soffocando con troppi dati in memoria. Sai, ci sono problemi di rete. Sarà sempre un bersaglio mobile, giusto? Che cosa vedi oggi come la traiettoria in termini di dove saranno i colli di bottiglia e dove dovrai focalizzare la tua attenzione?
Bill Ellis: Sì. Fino a quando non si misura, è difficile da sapere. Una delle cose sulle dichiarazioni SQL è che saranno i driver del consumo di risorse. E così nella circostanza che avresti avuto, ad esempio, un grande consumo di memoria o di CPU, sarai in grado di capire quale attività ha causato tale consumo di risorse. Ora, non vorrai necessariamente ucciderlo, ma vuoi anche esserne consapevole e, in un certo senso, cosa succede, quanto spesso succede, eccetera. In un certo senso, siamo ancora nuovi in termini di risposta all'intero set o al ricettario di risposte a circostanze diverse. E così, è una grande domanda e il tempo lo dirà. Avremo più informazioni col passare del tempo.
Eric Kavanagh: Ecco fatto. Bene, ragazzi, siete in uno spazio molto interessante. Penso che vedrai molte attività nei prossimi mesi e nei prossimi due anni perché so che SAP, come hai suggerito nel nostro appello sui contenuti, ha fornito una buona lunga rampa per le persone a fare la transizione a HANA. Tuttavia, quella rampa ha un finale e ad un certo punto le persone dovranno prendere alcune decisioni serie, quindi prima è meglio, giusto?
Bill Ellis: Assolutamente.
Eric Kavanagh: Bene gente, abbiamo passato un'altra ora qui su Hot Technologies. Puoi trovare informazioni online, insideanalysis.com, anche techopedia.com. Concentrati su quel sito per molte informazioni interessanti, incluso un elenco di tutti i nostri archivi di questi webcast passati. Ma gente, un grande grazie a tutti voi là fuori, ai nostri amici di IDERA, a Robin e, naturalmente, Dez. E ci vediamo la prossima settimana, gente. Grazie ancora per il tuo tempo e la tua attenzione. Stai attento. Ciao ciao.
