Emportar: L’amfitrió Eric Kavanagh discuteix sobre informàtica de memòria i SAP HANA amb els convidats el Dr. Robin Bloor, Dez Blanchfield i IDERAs Bill Ellis.
Actualment no teniu la sessió iniciada. Inicieu la sessió o registreu-vos per veure el vídeo.
Eric Kavanagh: D’acord, senyores i senyors. Hola i benvinguts de nou una vegada més Es tracta de les quatre hores de l'Est, un dimecres i els dos últims anys, cosa que significa que és una vegada més, per a les tecnologies calentes. Sí, efectivament, em dic Eric Kavanagh, seré el vostre amfitrió per a la conversa d'avui.
Avui, parlarem sobre algunes coses interessants. Ens endinsarem en el món de la memòria, el títol exacte és "Into the Future: An On Ramp for Computing In-Memory". És tota la ràbia en aquests dies i amb una bona raó, principalment perquè La memòria és molt més ràpida que confiar en discs girats. El repte, però, és que heu de reescriure molt programari. Perquè el programari d’avui, la majoria, s’ha escrit amb disc en ment i això realment canvia l’arquitectura de l’aplicació. Si dissenyes l’aplicació per esperar un disc girant, només fas les coses d’una altra manera que si tinguis tot aquest poder de la tecnologia a la memòria.
Hi ha un lloc sobre el teu realment, em toca, @eric_kavanagh. Sempre intento fer un seguiment i també retweetar sempre que algú m'esmenti.
Com he dit, avui parlem de memòria in-memory i específicament de SAP HANA. Va dir que el vostre últim any va conèixer la comunitat SAP realment i he de dir que és un entorn fascinant. Odia als usuaris que realitzen aquesta operació i estan a les primeres línies, perquè SAP és una operació increïblement bona. El que realment són molt bons és fer negocis. Per descomptat, també són excel·lents en tecnologia, i realment han invertit una gran inversió a HANA. De fet, puc recordar, probablement fa uns sis o set anys, que realment vam estar treballant per a la Força Aèria dels Estats Units i vam aconseguir que algú de SAP entrés i ens donés un primer cop d’ull al món de HANA i què estava previst. I, per dir-ho menys, la gent dels SAP Labs ha dedicat molt de temps i esforç a l’hora d’entendre com es construeix aquesta arquitectura que és totalment diferent, una vegada més, dels entorns tradicionals, perquè ho tens tot a la memòria. Així doncs, parlen de fer tant transaccionals com analítics a les mateixes dades a la memòria, en contraposició a la manera tradicional, que és treure-la, posar-la a un cub, per exemple, analitzar-la allà versus transaccional, que passa d’una manera molt diferent.
Aquest és un espai interessant i realment ho descobrirem a un altre venedor, IDERA, una mica sobre com funcionen totes aquestes coses i de què es tracta, de manera franca. Per tant, ens trobarem amb el doctor Robin Bloor, el nostre propi analista en cap aquí, al grup Bloor; Dez Blanchfield, el nostre científic de dades i després bon amic Bill Ellis de IDERA. Així, amb això, vaig a lliurar les claus al doctor Robin Bloor, que se’l traurà.
Robin Bloor: Sí, com deia Eric, el temps que vam rebre per primera vegada la informació de SAP HANA ja feia molts anys. Però era molt interessant, aquella època en concret va ser molt interessant. Vam trobar-nos amb una o dues empreses que, d’una manera o altra, oferien tecnologia a la memòria. Era ben clar que la memòria havia de venir. I realment no va ser fins que SAP es va aixecar i va llançar de sobte HANA. Vull dir, va ser un xoc quan vaig veure que SAP feia això. Va ser, com si va ser un xoc, perquè esperava que vingués d’altres llocs. Esperava que fos, ja ho sabeu, Microsoft o Oracle o IBM o algú així. La idea que ho feia SAP va ser realment sorprenent per a mi. Suposo que no hauria de ser perquè SAP és un dels venedors estratègics i, pràcticament, tot el que passa a la indústria prové d’un d’aquests.
De totes maneres, tot el tema sobre la memòria, vull dir, ens vam adonar, solíem parlar d’això, que tan bon punt aneu a la memòria, no es tracta de posar dades a la memòria, sinó que es tracta de comprometre’s amb la idea que la capa de memòria és el registre del sistema: tan bon punt migreu el registre del sistema a la memòria, el disc comença a convertir-se en un mitjà de transferència d'un tipus i es converteix en una cosa diferent. I em va semblar molt emocionant quan això va començar a passar. De manera que realment ha acabat per filar disc. El disc de filatura aviat existirà només als museus. No estic segur del més aviat possible, però, bàsicament, el disc d'estat sòlid es troba ara a la corba de la llei de Moore, ja és deu vegades més ràpid que fer girar el rovell, com ara ho diuen, i prou aviat serà encara més ràpid i doncs això vol dir que cada vegada són menys els casos d'ús del disc.
I el fet curiós, el SGBD tradicional, de fet, es va crear una gran quantitat de programari tradicional per a filar disc, que va suposar que es girés en disc. Tenia tota mena de capacitats a nivell físic programades amb rigor per tal d’explotar el disc girant, fent la recuperació de dades el més ràpidament possible. I tot això s’està rentant. Només desapareixent, saps? I aleshores, evidentment, hi hagué una gran cosa –no ho sé, lucrativa, suposo que serà al final– que s’obriria una base de dades en memòria que intentava ocupar la posició que les grans bases de dades, Oracle i Microsoft, SQL. El servidor i l'IBB de l'IBM, estaven ocupats a l'espai a la memòria i era molt interessant veure qui avançava i fer això.
Parlem de la cascada de memòria; només cal esmentar. També és la raó per esmentar-ho, la raó per la qual vaig introduir-ho, realment, era només fer saber a tothom que, quan parlo de memòria aquí, totes aquestes capes de les que parlo són de fet memòria. Però de sobte t’adones quan ho veus, es tracta d’una botiga jeràrquica, no només és memòria. I per tant, també s'aplica pràcticament tot el que vam aprendre fa temps, sobre botiga jeràrquica. I també vol dir que qualsevol base de dades a la memòria ha de navegar per això, alguns només cal que us passeu per la memòria RAM. I tot seguit ha estat cada vegada més gran i cada vegada més gran i ara es mesura en megabytes. Però teniu la memòria cau L1 que és cent vegades més ràpida que la memòria, la memòria cau L2 30 vegades més ràpida que la memòria i la memòria cau L3 aproximadament 10 vegades més ràpida que la memòria. Així que, ja sabeu, hi ha molta tecnologia (bé, una bona quantitat de tecnologia) que ha adoptat l’estratègia d’utilitzar aquests caché com a, un tipus d’espai d’emmagatzematge per a executar coses, sobretot tecnologia de bases de dades. Així, ja ho sabeu, aquesta és una influència.
Després hem aconseguit l’aparició de 3D XPoint i PCM d’IBM. I té gairebé velocitat de RAM, és bàsicament el que es vanten tots dos venedors. Els casos d’ús són probablement diferents. La primera experimentació amb això encara s’ha d’acabar. No sabem com afectarà l'ús de la RAM i la tecnologia de la base de dades en memòria a la memòria. Aleshores, tindreu RAM vers SSD. Actualment, la RAM és aproximadament 300 vegades més ràpida però, per descomptat, aquest múltiple està disminuint. I SSD versus disc que és aproximadament 10 vegades més ràpid, si ho entenc. Així, aquest és el tipus de situació que teniu. És la botiga jeràrquica. Mirar-ho d'una altra manera, la memòria, per descomptat, és completament diferent. Així doncs, el diagrama superior mostra dues aplicacions, ambdues que potser accedeixen a una base de dades, però sens dubte que accedeixen a dades sobre el rovell giratori. I la manera en què realment flueixen les coses per la xarxa, segons quines dependències hi hagi, és ETL. Així doncs, això vol dir que, ja ho sabeu, les dades passen al rovell filat i després surten al rovell girant per anar a qualsevol lloc i per arribar a qualsevol lloc es remunten al rovell girant, que són tres moviments. I tingueu en compte que la memòria pot ser cent mil vegades més ràpida que filar un disc, i de ben segur que us adonareu que prendre dades i posar-les a la memòria fa que tota aquesta cosa sigui realment diferent.
Per tant, potser haureu pensat què passaria en el que hi ha a la pantalla aquí mateix, podríeu haver pensat que, d’una manera o altra, l’ETL passaria de fet de dades a dades de memòria. Però, de fet, potser no ho farà; de fet, és possible que tingueu la situació de la dreta, on dues aplicacions poden desencadenar la mateixa memòria. Sens dubte, una base de dades a la memòria us pot proporcionar aquesta capacitat, sempre que tingueu el bloqueig i tot el que hi hagueu orquestrat al seu voltant. Per tant, això no només modifica la velocitat de les coses, sinó que modifica la forma en què configureu les aplicacions i els fluxos de dades sencers.
Per tant, té un impacte enorme. Aleshores, la memòria és pertorbadora, oi? I ho hauríem de treure del que he dit. El processament a la memòria actualment és un accelerador, però es convertirà en la norma. S’utilitzarà, aplicant-se segons el valor de l’aplicació i, per tant, és molt interessant que SAP surti realment amb una versió del seu programari ERP que es troba a la memòria. I la latència millora fins a tres ordres de magnitud del tot possible, i en realitat fins i tot més que això sigui possible, segons com ho facis. Per tant, obteniu grans millores en la velocitat si aneu a la memòria. I el tret de sortida, SAP HANA's S / 4, que ja han llançat, crec, bé, la gent diu que encara es llança, però certament es va llançar l'any passat, sinó que és un canvi de joc donat la base de clients SAP. Vull dir, hi ha 10.000 empreses que utilitzen l’ERP de SAP i gairebé totes són empreses grans, ja sabeu. Així, doncs, la idea de que tots tinguin un incentiu per endinsar-se en la memòria i fer servir el seu fonamental, ja que ERP gairebé sempre són aplicacions fonamentals que les empreses funcionen, és només un gran canvi de jocs i serà molt interessant. Però és clar que tot sona molt bé, però s'ha de configurar de manera intel·ligent i s'ha de controlar bé. No és tan senzill com sembla.
Dit això, crec que passaré la pilota a qui és aquest noi? Oh, australià, Dez Blanchfield.
Dez Blanchfield: Molt divertit. Robin Bloor, sempre un acte dur a seguir. Gràcies per tenir-me avui. Per tant, un gran tema, però emocionant. Així, doncs, he escollit una imatge que sovint em recorda quan penso en el modern llac de dades i els magatzems de dades empresarials i les meves petiteses de dades. Així que aquí tinc aquest bell llac envoltat de muntanyes i onades sorteixen, i les ones s'estanquen sobre aquestes roques. Això és, una mena de, com visualitzo mentalment el que sembla dins d’un llac de dades gran. Les ones són feines de lots, i les analítiques en temps real es llancen a les dades, sent les roques. I quan penso com un llac físic, em torna a fer una crida de despertar que, ja sabeu, l'escala dels magatzems de dades que estem construint ara, el motiu pel qual vam trobar aquest moneda i el terme de un llac de dades és que són molt grans i són molt profundes, i ocasionalment podeu tenir tempestes. I quan ho fem, sempre heu de resoldre el que està creant la tempesta.
Així, en el tema d'aquesta cosa, em sembla que aquesta crida de sirena de computació a la memòria és realment forta i per una bona raó. Aporta tants avantatges comercials i tècnics importants. Es tracta d’una discussió durant un parell d’hores un altre dia.Però, el canvi general cap a la informàtica a la memòria, només vull abordar com hem arribat fins aquí i què ho fa possible perquè, per exemple, posa els fonaments d’on es poden situar primer alguns dels reptes i què hem de tenir coneixement. i en el nostre pensament, al nostre món d'allunyar-nos dels discs filats antics que contenen dades i de deixar-los en disc i fora del disc, a la memòria i a la memòria i a les CPU, ara només eliminem gairebé una d'aquestes capes senceres, sent el disc girant. Com que recordeu, ja ho sabíeu, des dels primers temps de la computació, arquitectònicament, no ens vàrem desplaçar durant el temps principal o el món de gamma mitjana del que inicialment pensàvem com a memòria principal i emmagatzematge de bateria.
Com va dir el doctor Robin Bloor, l'enfocament que vam adoptar per moure les dades sobre l'arquitectura de l'ordinador no va canviar de manera espectacular durant un cert temps, des de fa un parell de dècades, de fet. Si penses en el fet que, ja ho sabeu, l’informàtica moderna, tècnicament, ha estat al voltant, si perdoneu el puny, durant uns 60 anys imparells, ja ho sabeu, sis dècades i més i és en el sentit que podeu compra una caixa a la prestatgeria, com era. El canvi a la nova arquitectura es va produir en el meu cap quan ens vam apartar del pensament entorn dels quadres principals i de la gamma mitjana, i les arquitectures de memòria bàsica i emmagatzematge de tambor, a la valentia o al supercomputació, en especial els gustos de Seymour Cray, on es fan coses com els plans posteriors. es va convertir en una cosa. En comptes de tenir només una ruta per moure les dades pel pla posterior o la placa base, tal com s'ha anomenat en aquests dies. I la memòria en línia, ja sabeu, en aquests dies la gent no pensa realment el que significa realment quan diuen DIMM i SIMM. Però, la SIMM és una memòria inline única i DIMM és una memòria inline dual i som més complexos que això, ja que hi ha desenes de tipus de memòria diferents per a coses diferents: algunes per a vídeo, algunes per a aplicacions generals, algunes integrades a CPU.
Així doncs, hi va haver un gran canvi cap a una nova manera de guardar i accedir a les dades. Estem a punt de passar per aquest mateix canvi en una altra generació sencera, però no tant en el maquinari en si, sinó en l'adopció del maquinari en la lògica comercial i en la capa de lògica de dades, i és un altre canvi de paradigma en la meva ment. .
Però, breument, sobre com hem arribat fins aquí Vull dir, la tecnologia del maquinari va millorar i va millorar notablement. Vam passar de tenir CPU i la idea d’un nucli era un concepte força modern. Es dóna per fet ara que els nostres telèfons tenen dos o quatre nuclis i els nostres ordinadors disposen de dos o quatre, o fins i tot vuit, nuclis a l'escriptori i vuit i 12 i més, ja sabeu, els 16 i 32 fins i tot a la plataforma del servidor. . Però en realitat és una cosa bastant moderna que els nuclis es van convertir en una capacitat dins de CPU i que vam passar de 32-bit a 64-bit. Hi van passar un parell de coses importants: obteníem velocitats de rellotge més elevades en diversos nuclis, de manera que podríem fer les coses en paral·lel i cadascun d’aquests nuclis podia tenir diversos fils. De sobte, podrem fer moltes coses amb les mateixes dades alhora. Una seixantena de quatre bits d’adreces ens va proporcionar fins a dos terabytes de RAM, que és un concepte fenomenal, però ara és una cosa. Ja sabeu que aquestes arquitectures de plànol de diverses vies, que eren, de vegades, només podríeu fer les coses en una direcció: endarrere i endavant. I com passava els dies amb la informàtica Cray i alguns dels dissenys de supercomputadors d’aleshores, i ara en ordinadors d’escriptori i ordinadors fora de la plataforma, una mena d’ordinadors de muntatge en rack de qualitat, ja que realment, la majoria dels moderns Els PC ara han passat per aquesta època de mainframe, midrange, microescriptoris i els hem convertit en servidors.
I moltes d'aquestes capacitats de supercomputador, aquell disseny de grau de supercomputador, es van abocar a components comuns fora de la prestatgeria. Ja sabeu, en aquests dies, la idea d’agafar ordinadors de muntatge en rack molt barats i posar-los en racks per centenars, si no milers, i fer servir programes de codi obert com Linux i implementar-hi els gustos de SAP HANA? ho sabem, sovint ho donem per fet. Però això és una cosa molt emocionant i que es presenta amb les seves complexitats.
El programari també ha millorat, sobretot la gestió de la memòria i el particionat de dades. No aprofundiré en molts detalls al respecte, però si ens fixem en el gran canvi dels darrers 15 anys o més o menys, com es gestiona la memòria, especialment les dades en memòria RAM i com es divideixen les dades en memòria RAM, de manera que, com ja va indicar el doctor Robin Bloor, ja ho heu fet al·lusió, les coses poden llegir i escriure alhora sense afectar-se les unes a les altres, en comptes de tenir temps d'espera. Hi ha moltes funcions molt potents, com ara compressió i xifratge en xip. El xifrat s'està convertint en una cosa més important i no ho hem de fer necessàriament al programari, a la RAM, a l'espai de la CPU, ara que realment passa al xip de forma nativa. Això accelera les coses de manera espectacular. I l’emmagatzematge i el processament de dades distribuïts, de nou, les coses que abans suposàvem eren coses de supercomputadors i processament paral·lel, ara ho donem per fet a l’espai del gust de SAP HANA i Hadoop i Spark, etc.
Així doncs, tot el que és això és aquesta computació d’alt rendiment, les capacitats de HPC van arribar a l’empresa i ara l’empresa gaudeix dels avantatges que comporta en els guanys de rendiment i l’espai tecnològic i els avantatges tècnics i els guanys comercials, perquè, ja ho sabeu, el temps reduït de valor es redueix dràsticament.
Però faig servir aquesta imatge d’una història que vaig llegir fa un temps d’un senyor que va construir una funda de PC fora de Lego, perquè sempre em ve al cap quan penso en algunes d’aquestes coses. I això és que sembla una idea fantàstica en el moment en què comenceu a construir-lo, i aleshores arribeu a la meitat i us adoneu que és realment complicat posar tots els bits Lego junts i fer una cosa sòlida, prou sòlida. per posar una placa base etcètera, que construirà una funda per a un ordinador personal. I, finalment, t’adones que tots els bits no s’uneixen bé i hauràs d’anar amb compte amb quins trossos s’enganxen perquè sigui sòlid. I és una idea molt maca, però és una trucada despertadora quan arribeu a la meitat i us adoneu: "Hmm, potser només hauria d'haver comprat una funda per a ordinadors de 300 dòlars, però ho acabaré ara i n'aprenc alguna cosa."
Per a mi, és una excel·lent analogia amb el que és crear aquestes plataformes molt complexes, perquè és bo i construït i acabi amb un entorn on disposeu d’encaminadors i commutadors, servidors i racks. I teniu les CPU i la RAM i el sistema operatiu agrupats entre si. I heu posat una cosa així com HANA per al tractament distribuït en memòria i emmagatzematge de dades i la gestió de dades. Comenceu la pila SAP, obteniu les capacitats de la base de dades i, a continuació, carregueu les dades i la lògica empresarial i comenceu a aplicar-hi algunes lectures, escriptures i consultes, etc. Heu de mantenir al màxim les I / O i heu de programar les coses i gestionar les càrregues de treball i la multitenància, etc. Aquesta pila esdevé molt complexa, molt ràpidament. Es tracta d'una pila complexa per si mateixa si només es troba en una màquina. Multiplicar-ho per 16 o 32 màquines, és molt, molt no trivial. Quan multipliqueu fins a centenars i, finalment, milers de màquines, per passar de 100 terabytes a escala de petabyte, és un concepte espantós i aquestes són les realitats que tractem ara.
Aleshores, acabareu amb un parell de coses que també han ajudat a canviar aquest món, i és que l’espai del disc es convertí en ridículament barat. Ja sabeu, una vegada que gastàveu entre 380 i 400 mil dòlars en un gigabyte de disc dur quan es tractava d’un tambor massiu de la mida d’un… cosa que necessitava un carretó elevador per recollir-lo. Aquests dies es tracta de, un tipus o dos cèntims per gigaquetat d'espai de disc de productes bàsics. I la memòria RAM va fer el mateix. Per descomptat, aquestes dues corbes J en ambdues gràfiques, per cert, tenen una dècada cadascuna, és a dir, estem analitzant dos blocs de 10 anys, 20 anys de reducció de preus. Però les vaig dividir en dues corbes J, perquè finalment la de la dreta només es va convertir en una línia de punts i no podríeu veure el detall, així que el vaig tornar a escalar. Un gigabyte de RAM fa 20 anys era quelcom d’ordre de sis milions i mig de dòlars. Avui dia, si pagueu més de tres o quatre dòlars per un gigabyte de RAM per al maquinari de productes bàsics que se us ve a robar.
Aquest important descens de preus en les dues darreres dècades ha fet que ara puguem anar més enllà de l’espai del disc i directament a la memòria RAM, no només al nivell de megabyte, sinó ara al nivell de terabyte i a la RAM com el disc. Tot i això, el desafiament era que la memòria RAM era originàriament efímera, cosa que significa una cosa que dura un curt període de temps, així que havíem de trobar maneres de resiliència en aquest espai.
Per tant, el meu punt aquí és que la informàtica a la memòria no és per als tímids. El fet de fer malabarisme amb aquestes dades a gran escala a la memòria i el processament al seu voltant és un repte interessant; com he indicat anteriorment, no és per als més descarats. Així doncs, una cosa que hem après d’aquesta experiència amb informàtica de memòria a gran escala i d’alta densitat és que la complexitat que construïm genera un risc en diverses àrees.
Però anem a mirar-ho des d’un punt de vista de seguiment i resposta. Quan pensem en les dades, s’inicien a l’espai del disc, s’assenten a bases de dades en discos, que l’emportem a la memòria. Una vegada que estigui en memòria i distribuït i hi hagi còpies, podem utilitzar moltes còpies, i si es fan algun canvi, es pot reflectir a nivell de memòria en lloc d’haver d’anar endavant i fora i a través del pla posterior. dos nivells diferents, entra i surt de la memòria. Hem acabat amb aquesta plataforma de maquinari d’àmplia escala que ens permet fer-ho ara. Quan parlem d’hipercalació, és més difícil a nivells ridículament densos i a una memòria de densitat molt elevada, comptes de densitat molt elevats de CPU i nuclis i fils. Ara disposem de patologies de xarxa molt complexes per donar-hi suport perquè les dades han de moure's per la xarxa en algun moment si es passa entre nodes i clústers.
Així doncs, acabem amb la redundància de falles del dispositiu que es va convertir en un problema i hem de supervisar els dispositius i peces del mateix. Haurem de tenir integrada la redundància de falles de dades resistent a la plataforma i controlar-la. Haurem de tenir integrada la resiliència de bases de dades distribuïda, de manera que hem de controlar la plataforma de bases de dades i apilar-la. Hem de controlar la programació de processament distribuït, el que passa dins d'alguns processos, fins a la consulta i la consulta, així com el camí que realitza la consulta i la manera com s'estructura i s'executa la consulta. Com sembla, algú ha fet un SELECT * a "bla" o ha realment realitzat una consulta molt intel·ligent i ben estructurada que els permetrà obtenir la quantitat mínima de dades nominals que coincideixin amb l'arquitectura del pla posterior? Tenim càrregues de treball multitenceries, diversos usuaris i diversos grups que exerceixen la mateixa o múltiples càrregues de treball i treballs per lots i programació en temps real. I tenim aquesta combinació de processament per lots i en temps real. Algunes coses funcionen regularment (cada hora, diàriament, setmanalment o mensualment), i altres són a la carta. Algú podria estar assegut allà amb una tauleta que vulgui fer un informe en temps real.
I, de nou, arribem a aquest punt complet, que la complexitat que es presenta en aquests casos no és només un repte ara, és bastant espantosa. I tenim aquesta comprovació de la realitat que un problema de rendiment únic, només un problema de rendiment, pot afectar a tot l’ecosistema. I, per tant, acabem amb aquest repte molt divertit de saber, on són els impactes? I tenim aquest repte: estem reactius o proactius? Estem veient la cosa en temps real i veiem que alguna cosa va "desenfadat" i li responem? O hem vist alguna forma de tendència i ens hem adonat que hem de compondre's proactivament? Perquè la clau és que tothom vulgui una cosa ràpida, barata i fàcil. Però acabem amb aquests escenaris, al que m’agrada referir-me i a la meva línia preferida del conundrum de Donald Rumsfeld, que al meu entendre s’aplica en tots aquests escenaris d’alta complexitat, i és que, hem conegut coneguts perquè és una cosa vam dissenyar i construir i funciona tal i com estava previst. Ens consta que es coneixen incògnites perquè no sabem qui està executant què, quan i on, si ho sol·licita. I tenim incògnites desconegudes i aquestes són les coses que hem de controlar i comprovar. Com que tots sabem, la realitat és que no podeu gestionar alguna cosa que no pugueu mesurar.
Per tant, per tenir les eines adequades i la capacitat adequada per supervisar la nostra programació de la CPU, busqueu els temps d’espera, esbrineu per què s’han d’esperar les coses a les cues de programació dels oleoductes. Què passa a la memòria, quin tipus d’utilització s’està realitzant, quin tipus de rendiment estem treient de la memòria? Es reparteixen correctament les coses, es distribueixen, tenim suficients nodes que en contenen còpies per poder fer front a les càrregues de treball que s’hi llancen? Què passa amb l'execució del procés fora dels processos del sistema operatiu? Les feines pròpies en funcionament, les aplicacions individuals i els dimonis suportats? Què passa dins d’aquests processos, en particular l’estructuració de les consultes i com s’executen i compilen aquestes consultes? I la salut d’aquests processos tot sortint en pila? Ja sabeu, de nou, els temps d’espera, s’està planificant correctament, s’ha d’esperar, on s’espera, s’espera que es llegeixi memòria, E / S, la CPU, E / S a tota la xarxa per a l’usuari final. ?
Aleshores, he esmentat amb prou feines abans d’enllestir-ho i, és a dir, com abordem els temps de resolució i resposta dels problemes? Estem veient en temps real i reaccionem a les coses, que és l’escenari menys ideal, però, fins i tot, és millor fer-ho que no saber-ho i fer una trucada al servei d’assistència i dir que alguna cosa ha anat malament i hem de fer un seguiment ? O ho estem fent de manera proactiva i estem buscant què hi ha en línia? D’altra manera, estem veient que estem mancant de memòria i hem d’afegir més nodes? Anem fent anàlisis de tendències, estem planificant capacitat? I tot això, estem supervisant els temps d’execució històrica i pensem en la planificació de les capacitats o ho estem veient en temps real i reprogramant i realitzant de forma proactiva el balanç de càrregues? I som conscients de les càrregues de treball que s’executen en primer lloc? Sabem qui fa què al nostre clúster i per què?
Els càlculs a la memòria són molt potents, però amb aquest poder és gairebé una d’aquestes coses, com ara, una pistola carregada i jugueu amb munició en directe. Si no teniu compte, podeu disparar-vos al peu. Així doncs, aquest poder de càlcul a la memòria només significa que podem executar molt més ràpidament entre conjunts de dades molt distribuïts i discrets. Però aleshores es produeix una demanda més gran derivada dels usuaris finals. S’acostumen a aquest poder i el volen. Ja no esperen que les feines triguin setmanes a funcionar i que els informes apareguin en un paper antic i senzill. I tot seguit, a sota de tot això, tenim el manteniment del dia a dia envoltat de pegats, actualitzacions i actualitzacions. I si teniu pensat en el processament 24/7 amb càlcul a la memòria, administrant aquestes dades, gestionant les càrregues de treball que hi ha, tot és a la memòria, tècnicament en una plataforma efímera, si començarem a aplicar pedaços i actualitzacions i actualitzacions a Allà, també s'hi inclouen tota una gamma d'altres reptes de gestió i supervisió. Hem de saber què podem agafar fora de línia, quan la podem actualitzar i quan la tornem a fer en línia. I això em porta al meu punt final i és que, a mesura que adquirim cada cop més complexitat en aquests sistemes, no és una cosa que un humà pugui fer només xucant el polze i tirant-se l’orella. Ja no hi ha cap tipus d’aproximació del sentiment intestinal. Realment necessitem les eines adequades per gestionar i oferir aquest alt nivell de rendiment en computació i gestió de dades.
I amb això, vaig a lliurar al nostre amic d'IDERA i escoltaré com han abordat aquest repte.
Bill Ellis: Moltes gràcies. Estic compartint la meva pantalla i aquí anem. Per tant, és veritablement humilístic tenir en compte només tota la tecnologia i totes les persones que han vingut davant nostre perquè estiguin disponibles aquestes coses disponibles el 2017. Parlarem de l’anàlisi de la càrrega de treball de SAP HANA: bàsicament, una solució de control de bases de dades: completa, sense agent, proporciona temps real i genera una història, de manera que podreu veure què ha passat en el passat. SAP S / 4 HANA ofereix el potencial de millor, més ràpid i més barat. No dic que sigui barat, només dic que és menys costós. Tradicionalment, el que va passar és que tindríeu una instància de producció principal (probablement funcionant amb Oracle en una botiga més gran, potencialment SQL Server), i després utilitzaries aquest procés ETL i tindríeu diverses versions de la veritat. . I això és molt car perquè pagueu el hardware, el sistema operatiu, la llicència Oracle per a cadascun d’aquests entorns. I, a més a més, caldria que la gent reconcilies una versió de la veritat amb la següent versió de la veritat. Així doncs, aquest processament ETL de diverses versions era lent i molt, molt feixuc.
Així, doncs, HANA, bàsicament una instància HANA, pot substituir totes aquestes altres instàncies. Per tant, és menys car perquè és una plataforma de maquinari, un sistema operatiu en lloc de múltiples. Així, doncs, l’HANA S / 4, realment, canvia tot i bàsicament estàs mirant l’evolució de SAP des de R / 2 a R / 3, els diversos paquets de millora. Ara, el sistema llegat està disponible fins al 2025, de manera que teniu vuit anys fins que realment no sereu obligats a migrar. Tot i que veiem gent, ja ho sabeu, aprofitant els dits dels peus perquè saben que arribarà i, finalment, sabeu, ECC funcionarà a HANA i, per tant, haureu d’estar preparats per això i comprendre la tecnologia.
Així doncs, una base de dades, sense processos ETL, ni còpies que s’han de conciliar. Així, una vegada més, més ràpid, millor i més barat. HANA és a la memòria. SAP subministra el programari, subministreu el maquinari. No hi ha taules agregades Una de les coses que suggereixen, quan pensem en això, és que no voldries accedir a això, només comprem el servidor més gran disponible. Ells suggereixen que, amb la mida adequada del vostre paisatge SAP abans del temps i, bàsicament, diuen que no migreu les dades de 20 anys.Crec que l’arxivatge és una cosa infrautilitzada en TI, de qualsevol manera, no només a les botigues SAP. I el següent és que SAP ha passat molt de temps reescrivint el seu codi natiu per no utilitzar SELECT *. SELECT * retorna totes les columnes de la taula i és especialment costós en una base de dades columnar. Per tant, no és una bona idea per a SAP HANA. Així, per a les botigues que tinguin molta personalització, molts informes, és el que voldreu buscar i voldreu especificar els noms de les columnes a mesura que avanceu a migrar tot a HANA.
Ens agrada dir que HANA no és una panacea. Com totes les bases de dades, totes les tecnologies, s’ha de controlar i, com s’ha esmentat anteriorment, es necessiten números per tal de gestionar l’excés, mesurament per mesurament. I una de les coses de què parlo a l'àrea IDERA és que totes les transaccions comercials interactuen amb el sistema de registre i, en aquest cas, serà HANA. Així, HANA es converteix en el fonament per a l'execució de les vostres transaccions SAP, l'experiència de l'usuari final. Per tant, és vital que es mantingui funcionant a la màxima velocitat. Es converteix en un únic punt de fracàs i, en parlar amb persones, es pot fer un recorregut allà on teniu un usuari final i potser està utilitzant aquestes dades en temps real i tenen una consulta ad hoc que potencialment no és del tot dret. Potser no s’uneixen a taules i han creat una unió externa, un producte partidista, i bàsicament consumeixen molts recursos. Ara, HANA ho reconeixerà i acabarà matant aquesta sessió. I, per tant, hi ha la part crucial de la nostra arquitectura que us permetrà plasmar realment aquesta història, de manera que podreu veure què havia passat en el passat i reconèixer aquestes situacions.
Per tant, mirem l’anàlisi de la càrrega de treball de SAP HANA. Aquesta és la versió 1, per la qual cosa us convidem molt a unir-vos a nosaltres en el viatge, i aquest és un producte d’IDERA. És complet, però senzill. En temps real amb tendència. Salut de l'amfitrió, salut de les instàncies Realitzem un seguiment dels estats d’espera, de les consultes SQL, dels consumidors i dels serveis de memòria. Així, això és el que sembla la interfície gràfica i es pot veure a la dreta de la ratlla que té habilitada la web. De fet, vaig obrir aquesta solució en funcionament al meu sistema. Hi ha algunes coses crucials que voleu fer un cop d'ull. Estem subdividits en diferents espais de treball. El tipus més important és el que succeeix a nivell d'amfitrió a partir d'un ús de CPU i un ús de memòria. Definitivament, no voldreu arribar a un punt de vista canviant o important. Aleshores, bàsicament aprofundeix en el que succeeix en els trending, des del temps de resposta, els usuaris, les declaracions SQL, és a dir, en què condueix l’activitat al sistema.
Una de les coses amb IDERA és que, ja sabeu, no passa res a la base de dades fins que no hi hagi activitat. I aquesta activitat són sentències SQL que provenen de l’aplicació. Per tant, mesurar les instruccions SQL és absolutament vital per poder detectar la causa arrel. Per tant, anem endavant i aprofundim. Així, a nivell d’amfitrió, realment podem fer una ullada a la memòria, el seguiment del temps, l’ús de la CPU de l’amfitrió. Pas enrere, podeu consultar les instruccions de COBSQL. Ara, una de les coses que veureu en el nostre costat d’arquitectura és que aquesta informació s’emmagatzema fora de HANA, de manera que si passés alguna cosa a HANA, bàsicament estem captant informació fins que Déu ho vulgui, una situació de no disponibilitat. . També podem capturar tot el que passa al sistema per tenir una visibilitat clara. I una de les coses que farem és que presentarem les instruccions SQL en ordre ponderat. Per tant, tindrà en compte el nombre d'execucions i, per tant, es tracta del consum total de recursos.
I podeu accedir a mètriques individuals aquí: quan es va executar aquesta sentència SQL? Aleshores, el consum de recursos es basa principalment en el pla d’execució i, per tant, ho podem capturar de manera continuada. HANA és a la memòria. És molt paral·lel. Té alguns índexs primaris a cada taula, que algunes botigues opten per crear un índex secundari per solucionar determinats problemes de rendiment. I, per tant, saber què va passar amb el pla d'execució d'algunes instruccions SQL pot ser molt valuós. També mirarem els serveis, el consum de memòria de nou, que es mostraran al llarg del temps. L’arquitectura: es tracta d’una solució autònoma que podeu descarregar del nostre lloc web i l’arquitectura és que està habilitada per a la web.
Podeu tenir diversos usuaris connectats a una instància determinada. Podeu supervisar les instàncies locals de SAP HANA. A més, mantenim una història de quatre setmanes al nostre dipòsit i de manera autogestionada. Per implementar-ho, és bastant simple. Necessiteu un servidor Windows. Cal descarregar-lo. La majoria de servidors de Windows tenen un framework .NET integrat i inclou una llicència. Per tant, aniríeu a l'assistent d'instal·lació dirigit per Setup.exe i realment obriria una pantalla, un acord de llicència i simplement treballaríeu aquest esquema fent clic a "Següent" i, per tant, a on us agradaria que HANA instal·lar-se? A continuació, es mostrarà les propietats de la base de dades, i aquesta serà la vostra connexió a SAP HANA, de manera que es tracta de la supervisió sense agent de la instància HANA. I aleshores, bàsicament donarem una vista prèvia, aquest és el port que comuniquem de manera predeterminada. Feu clic a "Instal·la" i, bàsicament, s'inicia HANA i comença a crear l'historial. Per tant, només una mica de la informació del gràfic de mida. Podem supervisar fins a 45 instàncies HANA i voldreu utilitzar-ho, a escala lliscant, per determinar el nombre de nuclis, memòria i espai de disc que necessitareu. Això suposa que teniu una història completa de quatre setmanes en curs.
De manera que, tan sols amb una ràpida recuperació, ens fixem en la salut del servidor, la salut de les instàncies, l'ús de CPU / memòria. Quins són els consumidors de memòria, quins són els motors d’activitat, quins són els serveis? Les sentències SQL són vitals: quins són els estats d’execució? Mostra'm els plans d'execució quan es van executar les coses? Això us donarà un temps real i una història del que havia passat. I com he esmentat, com que la nostra història està separada de HANA, anem a capturar coses que havien estat retardades i que s'havien esborrat de la història de HANA. Perquè pugueu veure el consum real de recursos al vostre sistema a causa de l’historial independent.
Així, com he dit anteriorment, al lloc web d’IDERA, a Productes, podeu trobar-ho fàcilment. Si voleu provar-ho, és benvingut. Consulteu com us proporciona informació i hi ha informació addicional en aquest lloc web. Per tant, les parts interessades estan molt més que contents de participar-hi. Ara, als productes de cartera que ofereix IDERA, també hi ha un monitor de transaccions de SAP ECC, i això es diu Precise for SAP. I el que fa és, tant si utilitzeu un portal com si només s’utilitza un ECC directe, capturarà realment la transacció de l’usuari final des del clic al disc, fins a la declaració SQL i us mostrarà el que passa.
Ara, us mostro una sola pantalla resum. Hi ha un parell de productes per emportar-los que vull que tingueu en aquesta pantalla resum. És el temps de resposta de l’eix Y, l’hora X de l’eix X més el dia, i en aquesta visualització de transaccions us mostrarem hora del client, hora de la cua, temps del codi ABAP, temps de la base de dades. Podem capturar identificadors, codis T d'usuari final i realment es poden filtrar i mostrar servidors mitjançant una transacció particular travessada. Per tant, moltes botigues utilitzen el front paisatge de VMware, de manera que podeu mesurar el que passa a cadascun dels servidors i aprofundir en una anàlisi molt detallada. Per tant, aquesta vista de transacció és per a la transacció de l'usuari final a tot el paisatge SAP. I podeu trobar que al nostre lloc web es mostra Eines APM de productes i aquesta seria la solució SAP que tenim. La instal·lació per a això és una mica més complicada, per la qual cosa no només cal descarregar-la i provar-la, com la que tenim a HANA. És el cas en què treballaríem junts per fer, dissenyar i implementar la transacció general.
Així doncs, només una tercera recuperació ràpida, l’anàlisi de càrrega de treball de SAP HANA, és una informació completa, sense agent en temps real, que ofereix un historial. Oferim la possibilitat de descarregar i provar-lo per al vostre lloc.
Així, doncs, passaré el temps a Eric, Dez i el doctor Bloor.
Eric Kavanagh: Sí, potser Robin, alguna pregunta de vostè, i després Dez després de Robin?
Robin Bloor: Bé. Vull dir, el primer que vull dir és que m’agrada molt la vista de transaccions perquè és exactament el que voldria en aquesta situació. Vaig fer molta feina - bé, fa molt de temps, ara mateix, fent vigilància del rendiment i això va ser; no vam tenir els gràfics en aquells dies, però era el que volia fer. Perquè, d’una manera o altra, s’injecti a qualsevol lloc on passi el problema.
La primera pregunta que tinc és, ja ho sabeu, que la majoria de la gent implementa S / 4 d’alguna manera o d’altra manera fora de caixa, ja ho sabeu? Quan vau implicar-vos en alguna implementació determinada de S / 4, vau descobrir que s’ha implementat bé o bé, ja sabeu, descobrint coses que podrien fer que el client volgués configurar-se? Vull dir, com va tot això?
Bill Ellis: Bé, cada botiga és una mica diferent. I hi ha diferents patrons d’ús, hi ha diferents informes. Per als llocs que tinguin informes ad hoc, vull dir que és realment un tipus de comodins al sistema. I, per tant, una de les coses crucials és començar a mesurar i esbrinar quina és la línia de referència, el que és normal per a un lloc en particular, on aquest lloc en particular, basat en els seus patrons d’ús, subratlla el sistema. A continuació, feu els ajustaments a partir d’allà. Normalment l’optimització de la supervisió no és una única vegada, sinó que és realment una pràctica continuada en què fa la supervisió, l’ajustament, la visualització, fent que el sistema sigui millor perquè la comunitat d’usuaris finals pugui servir el negoci de manera més eficaç.
Robin Bloor: Està bé, així que quan implementeu (vull dir), sé que es tracta d’una pregunta difícil de respondre, ja que variarà segons la mida de la implementació, però, quant de recursos té la capacitat de control IDERA, quant consumeix? Fa alguna cosa de diferència o és que no interferiu? Com funciona això?
Bill Ellis: Sí, diria que les despeses generals són aproximadament d’un 1-3 per cent. Moltes botigues estan molt disposades a sacrificar-ho, perquè potencialment podreu tornar a comprar en termes d'optimització. Depèn dels patrons d’ús. Si feu un paisatge complet, depèn de les tecnologies que s'estan supervisant. Així doncs, el tipus de quilòmetre varia, però, com hem parlat, és millor gastar una mica per saber què passa, que no pas fer cegues. En particular, seria, ja ho sabem, que estem al gener i entreu en el processament de rendiments íntegres i agregeu dades de 12 mesos. Ja sabeu, que això és el rendiment, fer arribar els informes a organitzacions reguladores, els bancs, als accionistes, és absolutament vital en un rendiment crític empresarial.
Robin Bloor: Dret. I només ràpidament, des de la vostra perspectiva –perquè suposo que hi esteu involucrats amb tota una sèrie de llocs SAP–, com és de gran el moviment entre la base de clients de SAP cap a S / 4? Vull dir, és que alguna cosa està sent, ja hi ha, que hi ha una mena d'allaus de clients entusiastes per això, o és simplement un truc constant? Com ho veieu?
Bill Ellis: Crec que fa un parell d’anys diria que era puntera. Ara diria que la gent està, fins i tot, fins al genoll. Crec que, ja ho sabeu, tenint en compte que la gent es veurà immersa en HANA durant els propers dos anys. Així doncs, el seguiment, la transformació, ja ho sabeu, crec que la majoria dels clients són, de la mateixa manera, junts en la corba d’aprenentatge. Així, doncs, crec que no ens trobem amb l'allau tal com havíeu afirmat, però crec que estem a la base de la transformació important de HANA.
Robin Bloor: D’acord, pel que fa als llocs que heu vist que han estat per això, també estan adaptant HANA per a altres aplicacions o, d’una manera o altra, es consumeixen completament per fer que això funcioni? Quina foto hi ha?
Bill Ellis: Sí, sovint la gent integrarà SAP amb altres sistemes, segons quins mòduls i altres, de manera que hi ha una mica. Realment no veig que la gent desplegui altres aplicacions a HANA encara. Això és certament possible. Així, doncs, es mou més al paisatge de la infraestructura SAP.
Robin Bloor: Suposo que us convindria millor a Dez. T'estic enganxant el temps. Dez?
Dez Blanchfield: Gràcies. No, tot va bé. Dos molt ràpids, només per intentar definir el tema. SAP HANA ha estat fora d’un parell d’anys i la gent ha tingut l’oportunitat de considerar-ho. Si ens haguéssiu de fer una estimació aproximada del percentatge de persones que s’executen –perquè hi ha molta gent que gestiona aquestes coses–, de què creieu que el percentatge del mercat de què coneixeu és actualment. Des de les implementacions SAP tradicionals fins a SAP a HANA? Estem mirant 50/50, 30/70? Quin percentatge del mercat veieu de les persones que van fer la transició i que es van moure ara envers els populars que tan sols mantenen la marxa i esperen que les coses milloren o milloren o canvien o sigui el cas?
Bill Ellis: Sí, en realitat, en la meva perspectiva, hauria posat el percentatge al voltant del 20 per cent. SAP acostuma a ser negocis tradicionals. La gent sol ser molt conservadora i, per tant, la gent se li arrossegarà els peus. Crec que també depèn, ja ho sabeu, heu estat executant SAP durant molt de temps o sou d’alguna manera una SMB que potser s’havia desplegat recentment SAP? I hi ha una sèrie de factors, però no crec que el percentatge sigui de 50/50. Diria que un 50 per cent com a mínim estan empassant-se i que HANA funciona en algun lloc del seu centre de dades.
Dez Blanchfield: L’interessant emport que ens vau donar abans era que es tracta d’un fet complit en un cert sentit i que el rellotge marca físicament i literalment el moment de la transició. En aquest procés, creus que la gent ho ha considerat? Quin és el sentit general de comprendre que es tracta d’un canvi transitori en la plataforma, no és només una opció, sinó que s’està convertint en el valor predeterminat?
I des del punt de vista de SAP, estic segura que segueixen fent aquesta marxa perquè hi ha un avantatge competitiu important en el rendiment, però també ho suposo, estan lluitant contra el control de la plataforma en lloc d’anar a un tercer- base de dades de festes, ara la tornen a portar a la seva pròpia plataforma. Creus que les empreses ho han aconseguit? Creus que la gent ho entén i ara s’està adaptant? O segueix sent una cosa no clara, del mercat?
Bill Ellis: No crec que el SAP sigui tímid per comunicar-se i les persones que han anat a SAPPHIRE han vist HANA a tot arreu. Així doncs, crec que la gent és conscient, però és que la naturalesa humana és el que és, ja ho sabeu, hi ha algunes persones que arrosseguen una mica els peus.
Dez Blanchfield: Perquè crec que la raó per la qual vaig fer aquesta pregunta i em hauràs de perdonar, però estic d'acord. Crec que no han estat tímids en comunicar-ho. Crec que el senyal s'ha extingit de moltes maneres. I estic d’acord amb tu: no sé que tothom ha saltat encara. Ja sabeu, les empreses tradicionals, les empreses molt grans que funcionen, encara són de moltes maneres, no només arrossegant els peus, sinó simplement tractant de comprendre la complexitat del canvi. Perquè crec que l’única cosa que ha destacat la vostra eina i, certament, la vostra demostració d’avui en dia, i per a mi, una de les claus per emportar-me voldria que tothom escoltés i sintonitzés avui en dia per asseure’s i prestar atenció de manera reflexiva és: L’eina ara simplifica aquest procés a la meva ment. Crec que hi ha un munt de CIO molt nerviosos i els seus equips que pensen: "Com puc fer la transició dels tradicionals sistemes de gestió de bases de dades relacionals, que hem conegut des de fa dècades, a un paradigma completament nou i computacional. gestió d’emmagatzematge en un espai que és relativament valent? ”. Però és un desconegut en molts aspectes, i hi ha molt poques persones que han fet aquest canvi en altres àrees, que no és com si haguessin aconseguit una altra secció de negoci que ja hagi realitzat una tasca de càlcul a la memòria. Per tant, es tracta d'una decisió total o gens de la seva ment.
Per tant, una de les coses que he tret de tot això, més que res, us posaré una qüestió en un minut, és que ara, segons crec, la por es veu calmada de moltes maneres i que abans d’avui, Si jo escoltés un CIO, pensaria, sort, pensaria: “Bé, com faré aquesta transició? Com vaig a garantir la mateixa capacitat que tenim a la plataforma de gestió de bases de dades relacional i anys d’experiència dels DBA, a una nova plataforma en la qual actualment no tenim les habilitats? ”Així doncs, la meva pregunta amb això és , creieu que la gent ha entès que les eines hi són ara amb allò que oferiu, i que poden respirar profundament i sospirar un alleujament que la transició no és tan espantosa com podia haver estat anterior. aquesta eina està disponible? Creus que la gent ha entès o segueix sent una cosa que simplement s’acosta amb la transició a l’emmagatzematge en la memòria de càlculs i emmagatzematge a la memòria versus combinacions de NVMe, flash i disc antigues?
Bill Ellis: Sí, de manera que hi ha sens dubte moltes tecnologies i eines que poden mostrar-ho gràficament, el que està passant i fer que sigui molt fàcil identificar els principals consumidors de recursos. Vull dir, ajuda a simplificar les coses i ajuda al personal tecnològic a tenir un bon maneig. Ei, podran saber què passa i podran comprendre tota la complexitat. Així, absolutament, les eines del mercat són sens dubte útils i, per tant, oferim una anàlisi de càrrega de treball per a SAP HANA.
Dez Blanchfield: Sí, crec que el més important del que ens has demostrat avui és que, en controlar la peça de maquinari, la peça del sistema operatiu, fins i tot controlar una mica de la càrrega de treball que passa, com heu dit, vull dir que les eines hi han estat durant algun temps. La part per a mi, sobretot en el que m’agrada de HANA, és que no necessàriament hem tingut la possibilitat d’obtenir una lupa i mirar-la i veure què fa la vostra eina amb el que passa amb les consultes i com estan. estant estructurat i on es troba aquesta càrrega.
Amb els desplegaments que heu vist fins ara, ja que és literalment el més autoritari d’aquest espai de la vostra plataforma del món, algunes de les victòries ràpides que heu vist: teniu cap coneixement anecdòtic amb el qual pugueu compartir nosaltres al voltant d'alguns dels moments eureka, els moments aha, on la gent ha desplegat el conjunt d'eines IDERA, han trobat coses que no sabien que eren a les seves plataformes i actuacions que han tingut. Teniu exemples anecdòtics fantàstics sobre allà on la gent l’acaba de desplegar, sense saber realment què havien tingut i de sobte, “Wow, en realitat no sabíem que hi havia allà?”
Bill Ellis: Sí, per tant, una gran limitació de les eines natives és que si es cancel·la una consulta desaprofitada, es redueix la informació i, per tant, bàsicament no en teniu l'historial. Si emmagatzemem l’historial fora de línia, com una consulta desaparició, tindreu un historial, sabreu què ha passat, podreu veure el pla d’execució i així successivament. I, per tant, això permet ajudar a la comunitat de l'usuari final bàsicament a funcionar millor, redactar informes millor, etcètera. Així doncs, la història és una cosa que és realment agradable. I una de les coses que havia volgut mostrar és que es pot mirar en temps real fins a quatre setmanes i, a continuació, es pot fer zoom en qualsevol període d’interès i, a continuació, es pot exposar l’activitat de conducció subjacent. Només tenir aquesta visibilitat és molt útil per saber quins colls d’ampolla han sorgit.
Dez Blanchfield: Heu esmentat que és multi-usuari, un cop desplegat i em va quedar molt impressionat pel fet que és intacte i efectivament zero en molts aspectes. És normal que un únic desplegament de l’eina estigui a l’abast de tothom des del centre d’operacions de xarxa del NOC que vegi la infraestructura bàsica que es basa en el clúster fins a l’equip d’aplicació i desenvolupament? És la norma i ho implementeu una vegada i ho compartireu, o preveieu que la gent pot tenir instàncies de model que busquin diferents parts de la pila? Com és això?
Bill Ellis: Així, normalment, l'equip bàsic tindrà un interès molt fort en la base de la tecnologia de què passa a SAP. Obbviament, hi ha diversos equips que admetran paisatges sencers. La peça HANA està centrada en això. Acabo per defecte a l’equip de base SAP com a principals consumidors de la informació.
Dez Blanchfield: Dret. Em sembla, però, que si tinc un equip de desenvolupament o no només a nivell de codi, però si tinc un equip de científics o analistes de dades que treballin analíticament en els conjunts de dades que hi ha, sobretot, tenint en compte que hi ha Una important empenta perquè ara s’aplica la ciència de dades a tot allò que es troba dins de les organitzacions, i em corregiu si m’equivoco, em sembla que també els interessarà molt, perquè de moltes maneres un de les coses serioses que podeu fer en un entorn de magatzem de dades és que es descarregui un científic que li permeti començar a fer consultes ad hoc. Heu tingut algun exemple d’aquest tipus de coses que succeeixen on les botigues us hagin dit i digueu: “Hem llançat a un equip de ciències de dades, és molt dolent, què podem fer per ells enfront del que estem fent només control i gestió operatius tradicionals? ”És fins i tot una cosa?
Bill Ellis: Bé, sí, hauria de donar una mica més a la volta i reduir la meva resposta seria que, a la vista del rendiment, que tingui consciència de rendiment en el desenvolupament de la producció de QA, ja sabeu, com més aviat emmagatzeneu, menys problemes, menys sorpreses tingueu. . Així, absolutament.
Dez Blanchfield: A continuació, hi ha moltes eines amb les que he tingut experiència (i estic segur que Robin hi estarà d’acord): moltes eines aquí, si teniu un gran RDBMS, necessiteu una gran qualificació, profundament DBA experimentats i experimentats. Alguns dels requisits d’infraestructura i plataforma que s’apleguen amb SAP HANA, ja que actualment és compatible amb distribucions particulars que s’alineen des de maquinari particular i així successivament, segons el que he sabut. Ja ho sabeu, hi ha persones amb dècades d’experiència que no són el mateix. El que estic veient, però, és que no és necessàriament aquesta exigència amb aquesta eina. Em sembla que podeu desplegar l'eina i donar-la a algunes cares força noves i donar-los el poder immediatament per trobar coses que no funcionin bé. Es dóna el cas que hi hagi una corba d’aprenentatge força breu per agilitar-se amb rapidesa i obtenir algun valor per desplegar-la? Ja sabeu, el meu sentit general és que no heu de tenir 20 anys d’experiència en la conducció d’una eina per veure el valor immediatament. Esteu d’acord que aquest és el cas?
Bill Ellis: Ah, del tot, i segons el vostre punt, crec que molt de l’èxit d’un desplegament depèn realment de la planificació i l’arquitectura de l’entorn SAP HANA. I, sens dubte, hi ha molta complexitat, molta tecnologia en la qual es basa, però només es pot controlar els patrons d’ús del que passa. Així, tot i que és més complex, en certa manera està empaquetat i una mica simplificat. És molt pobre.
Dez Blanchfield: Sí, així que abans de retornar-li a Eric, perquè sé que ha rebut un parell de preguntes, sobretot d’algunes que han arribat a través de preguntes i preguntes que semblaven interessants, i estic desitjat escoltar la resposta. Viatge tradicional per a algú a qui heu mencionat anteriorment que podeu obtenir-lo, podeu descarregar-lo i provar-lo. Podeu aprofitar-ho ràpidament per escoltar cançons actuals o per a folk que pugui reproduir-ho més tard? Quins són els dos o tres passos ràpids per posar les mans sobre una còpia i desplegar-la i provar-la als seus entorns abans de comprar-la? Com és això? Quins són els passos per aconseguir-ho?
Bill Ellis: Sí. Per tant, IDERA.com només cal que aneu a Productes i podreu veure l’anàlisi de càrrega de treball per a SAP HANA. Hi ha una pàgina de descàrrega. Crec que us demanaran informació sobre el contacte i el producte només s’empaqueta amb una clau de llicència perquè pugueu instal·lar-lo amb el Setup.exe i només pugueu fer servir, crec, ràpidament.
Dez Blanchfield: Per tant, poden anar al vostre lloc web, poden descarregar-lo. Recordo que el vaig mirar fa un temps i vaig comprovar ahir a la nit també el doble. Podeu demanar una memòria a la memòria, on algú del vostre equip us guiarà? Però realment el podeu descarregar gratuïtament i desplegar-lo localment al vostre propi entorn, al vostre temps, no?
Bill Ellis: Sí.
Dez Blanchfield: Excel · lent. Bé, crec que, més que res, probablement és el que jo recomanaria personalment a la gent, és agafar una còpia del lloc web, agafar una mica de la documentació allà perquè sé que hi ha molt bon contingut. i només ho proveu. Posa-ho al teu entorn i mira què trobes. Sospito que un cop analitzat els seus entorns SAP HANA amb l'eina IDERA hi trobareu coses que realment no sabíeu.
Mireu, moltes gràcies per això i gràcies pel temps només de fer una pregunta de preguntes i preguntes amb Robin i jo. Eric, us passaré de nou perquè sé que algunes preguntes i respostes també provenen dels nostres assistents.
Eric Kavanagh: Sí, només hi ha una cosa ràpida aquí. Així doncs, un dels assistents fa un comentari realment bo només parlant de com canvien les coses. Dient que en el passat, la memòria es va sufocar, es va alentir amb la cerca de pàgines freqüents, actualment la CPU s’ofega amb massa dades a la memòria. Ja ho sabeu, hi ha problemes de xarxa. Sempre serà un objectiu en moviment, oi? Com veieu la trajectòria en aquests dies en què seran els colls d'ampolla i on us haureu de centrar l'atenció?
Bill Ellis: Sí. Fins que no mesures, és difícil saber-ho. Una de les coses sobre les instruccions SQL és que seran els motors del consum de recursos. Així, en el cas que hagueu de tenir, com ara, un gran consum de memòria o un CPU, podreu esbrinar quina activitat va causar aquell consum de recursos. Ara, no voldríeu necessàriament matar-lo, però també voleu ser-ne conscients i, què passa, quina freqüència passa, etc. Som, una mena de, encara nous quant a abordar tot el conjunt o el llibre de cuina de respostes a diferents circumstàncies. Així, és una gran pregunta i el temps ho dirà. Amb el temps, tindrem més informació.
Eric Kavanagh: Això és. Bé, vostès estan en un espai molt interessant. Crec que veuràs molta activitat durant els pròxims mesos i els propers dos anys perquè sé que SAP, com has suggerit en la nostra convocatòria de contingut, ha proporcionat una bona llarga durada a la gent per fer la transició. a HANA. Però, tanmateix, aquesta rampa té un final i, en un moment determinat, les persones hauran de prendre decisions serioses, de manera que més aviat millor, no?
Bill Ellis: Absolutament.
Eric Kavanagh: Molt bé, hem cremat una altra hora aquí en Hot Technologies. Podeu trobar informació en línia, dins l'analisis.com, també techopedia.com. Centreu-vos en aquest lloc per obtenir molta informació interessant, incloent-hi una llista de tots els nostres arxius d’aquests transmissions web anteriors. Però, moltes gràcies, a tots els que esteu fora, als nostres amics d’IDERA, a Robin i, per descomptat, a Dez. I us atendrem la setmana que ve, amics. Gràcies de nou pel vostre temps i atenció. Cuida't. Adeu.