Joc de performance: acomiadar-se de la latència

Per personal de Techopedia, 9 de maig de 2016

Takeaway: l' amfitrió Eric Kavanagh entrevista a Mark Madsen, Dez Blanchfield i Bullett Manale sobre la latència i el rendiment.

Actualment no teniu la sessió iniciada. Inicieu la sessió o registreu-vos per veure el vídeo.

Soci de contingut de Techopedia

El personal de Techopedia està afiliat a Bloor Group i es pot contactar amb les opcions de la dreta. Per obtenir més informació sobre com treballem amb els socis de la indústria, feu clic aquí.

• Perfil
• Lloc web

Eric Kavanagh: Senyores i senyors, hola i benvinguts de nou a Hot Technologies! Sí, efectivament! Em dic Eric Kavanagh, aquest és el nostre programa de "Hot Tech", una col·laboració amb els nostres bons amics de Techopedia. Saltar en línia a Techopedia.com per obtenir totes les novetats en l'àmbit ampli de la tecnologia empresarial; naturalment, també cobreixen coses de consum. Ens centrem en l’empresa aquí en el nostre programa, per això és el que farem avui.

Hi ha un lloc sobre el vostre veritablement i prou sobre mi, xateu-me a Twitter @eric_kavanagh, m'encanta el Twitter, m'encanta revisar aquestes coses, és una manera fantàstica de mantenir-vos en contacte amb la gent i de tenir bones converses i una sola. -una conversa.

Aleshores, de què parlem? Aquest any és calorós, tot un univers d’oportunitats que contemplem avui en el món de la gestió de la informació i, del que parlem avui, seran consultes, s’acceleraran les consultes.

Crec que vaig oblidar de mencionar el títol, "Performance Play: Say Goodbye to Latency". Bé, qui vol la latència? Ningú vol latència, la latència és quan s’asseu allà, feu clic al botó i espereu que passi alguna cosa i ningú no vol. Als nens no els agrada, tampoc no els fa gràcia, als adults tampoc els agrada. Tots ens hem espatllat per la velocitat de la web i volem les coses ràpidament, volem les coses ara, i avui en parlarem al programa.

L’analista Mark Madsen ens acompanya avui de Third Nature, un dels nostres habituals. El nostre nou científic de dades, Dez Blanchfield, va trucar des de Sydney, Austràlia. I després Bullett Manale, sí, efectivament, aquest és el seu nom, en realitat se suposa que són dues T's. Bullett Manale és la nostra convidada d'Idera, una empresa molt interessant, que fa moltes coses. Ja sé d’ells, un dels quals van comprar una empresa anomenada Precise fa un temps. Sabia que el seu director general es deia Zohar Gilad, com és això per a un nom? Ell era un noi intel·ligent.

Tanmateix, és important que tingueu un paper important en aquesta transmissió web en les preguntes que us plantegeu, així que si us plau, no sigueu tímids, envieu les vostres preguntes en qualsevol moment. Podríeu fer-ho mitjançant el component de Q&A de la consola webcast. a la part inferior dreta. També podeu conversar amb mi i us en faré una conversa amb els altaveus. Ja tenim algú que truca des d'Itàlia així que "Ciao, ciao. Veniu stai? ”Bé, amb això vaig a llançar la primera línia de Mark, vaig a lliurar el pont a Mark. Marca, ja teniu WebEx. Treu-ho, el terra és teu.

Mark Madsen: Gràcies, Eric. No vaig a començar pel mig, però, començaré al principi. Així doncs, només alguns comentaris per establir la discussió amb Dez i Idera, una mena d'estat de l'estat amb desenvolupament, i bases de dades i operacions. I ja sabeu: Si us fixem en això, tenim aquests dos problemes mundials encara al mercat de bases de dades i aplicacions, perquè els desenvolupadors veuen els DBA com les persones que els molesten. Heu de crear models de dades, no podeu accedir a això, no podeu crear aquesta cosa, no podeu posar un índex a cada columna de cada taula de la base de dades per fer-la més ràpida. I, per descomptat, per què necessitem els models? Es tracta només d’estructures de dades, si les canviem, no es pot escriure només en un format de serialització?

El problema és que els desenvolupadors coneixen el codi i les aplicacions, però dues coses que sovint no saben són la concurrència, la programació simultània i les bases de dades i els sistemes operatius que hi ha sota. Després d’haver estat desenvolupador del nucli i sistemes operatius i bases de dades, puc dir que la concurrència i el paral·lelisme són realment difícils i, per tant, moltes de les coses que aprenen a obtenir un bon rendiment del vostre codi, comencen a desaparèixer quan sigueu treballar amb una base de dades. I el rendiment té un aspecte excel·lent, l’entorn de prova té un aspecte excel·lent, i l’entorn de Q&A, i aleshores arriba al sistema real i, de sobte, no és tan bo. Com que és polifacètic, com funciona el codi amb la base de dades, com funciona amb l'entorn i realment petites pràctiques senzilles poden tenir efectes dràstics segons quina escala s'execute.

I quan comences a parlar d’aplicacions externes, per descomptat, aplicacions enfrontades externament, aplicacions web, poden ser realment difícils perquè les coses són excel·lents fins que de cop i volta s’aplanen i no ho són. Arribareu a aquests interessants altiplans que requereixen molta matèria per entendre-ho.

La visió clara de les coses és la visió del DBA. L'opinió de DBA és que hi ha operacions, que passen la major part del seu temps, del 80 al 90 per cent, en opcions, i potser del 10 al 20 per cent tractant les coses de desenvolupament que estan passant a la primera. Des d'aquesta perspectiva, pagueu ara o pagueu més endavant, i si esteu passant tot el temps per endavant, més endavant tindreu una molt millor oportunitat, a diferència del desenvolupament que tendeix a explorar una característica. l’espai i intentant esbrinar la millor manera de fer les coses. Així, doncs, tenim problemes, i ara tenim metodologies incompatibles: desplegament continu, desplegament de les aplicacions sempre que estiguin llestes, fent pressions de codi de forma periòdica, treballant en una botiga que practica serveis operatius. Aquest tipus de coses accelereixen el desenvolupament, però totes les pràctiques al voltant de la base de dades, què fan els DBA i què han estat formats els gestors del sistema, les pràctiques d’operacions informàtiques no han mantingut el ritme.

Si hi penses, la majoria dels DBA funcionen sota un entorn de control de canvis vers un entorn de desplegament continu. Es tracta d’estabilitat i control, versus velocitat de canvi i reversibilitat. Desplegament continuat, si no podeu tornar al canvi, teniu problemes, de manera que tot s’ha de crear de manera que sigui fàcilment reversible i que es pugui canviar de codi, cosa que no és la manera de funcionar la base de dades relacional, les pràctiques de desenvolupament i les pràctiques de gestió. .

També us trobeu amb aquests problemes d’haver de ser més proactiu si podeu, com a DBA, ja que quan escolteu un problema, cent mil persones omplen formularis de reclamació al vostre lloc web. Això et fa necessitar algunes coses noves que no surtis del teu entorn antic. Ja ho sabeu, com ara un millor control i alerta. Al mateix temps, les bases de dades s’han multiplicat, tenim més aplicacions que mai per admetre més coses que mai, estan dins, estan fora, estan per tot arreu. I més conjunts de dades independents per a anàlisis, la gent està iniciant bases de dades arreu perquè, per descomptat, ara és fàcil, podeu configurar una màquina virtual. Si teniu un proveïdor de núvols o un núvol intern, podeu aparèixer immediatament les coses, i això canviarà tota la ruta de compra.

L’antic camí de contractació era: “Tinc temps d’aconseguir un servidor, d’enfilar-lo en un cremallera, de reservar espai, d’emmagatzemar, d’instal·lar la base de dades i de fer coses”, davant d’algú que passa una targeta de crèdit i passarà en cinc minuts. Si ho fas, aquell entorn de desenvolupament modern funciona amb un ritme molt diferent, de manera que és fàcil crear bases de dades i això només crea aquest problema de proliferació, com res que hem vist abans. I això ja fa deu anys que no és novetat per a ningú, però també significa que els entorns operatius han crescut en complexitat.

Tot l’entorn del servidor client ha canviat realment, perquè ja no és un món del servidor client. Aleshores teníeu un servidor, teníeu una base de dades, si alguna cosa anava malament, sabíeu a quin servidor havia de dirigir-vos, sabíeu com gestionar els recursos que hi havia, perquè les bones pràctiques eren una base de dades, un servidor. La virtualització va començar a separar-se, el núvol el trenca encara més, perquè el que creieu que és un servidor de bases de dades, és només un programari. Per tant, el medi ambient no és real. El que conté l’entorn que és la realitat, i que potser pot ser un bloc de fulles o un gran servidor tallat a trossos, que realment no ho sabeu.

Tot sobre l’administració de bases de dades i la gestió del rendiment i les bases de dades que s’han creat al voltant d’un control estricte amb un servidor, o un bon grapat de servidors i un parell de bases de dades, no es pot controlar tot. Hi esteu asseguts a una màquina, però els administradors virtuals no es poden repartir l’ample de banda fàcilment, de manera que tot pot estar bé amb la memòria i la CPU, però teniu en compte algun recurs que no es pot tractar, i quan intentes arreglar-lo, l'antic model hauria estat molt dur, aconseguir un servidor més gran i fer una cosa així, ara podria ser realment senzill, només cal afegir un curs virtual, només afegir memòria a la màquina virtual i es resol. Però, què passa si la vostra màquina virtual està en un servidor sobreagregat i ha de migrar? O què passa si teniu la mida d’un sistema AWS i s’ha aconseguit la mida màxima, ara on aneu?

Així, doncs, teniu tots aquests problemes en què l’entorn forma part de la base de dades ara, empaqueu un entorn amb una base de dades, tots els recursos especials, tot allò de l’aplicació que forma part de la configuració, la configuració es fa fora. Això és de l’entorn de la base de dades, és molt més difícil de gestionar i controlar.

Si ens fixem en què han estat els centres de bases de dades, han estat asseguts a les mans, no? Ens hem allunyat d’aquesta idea de tractar bases de dades i servidors com animals de companyia. Els servidors tenen noms, els tractes com si fossin coses úniques, les tractes com el bestiar, és gestionar una rajada. I el problema per gestionar els ramats és que si no els controles, eventualment poden estampar-se, i una estampida no és bona cosa. Necessitem millors eines de control, necessitem maneres millors per afrontar aquestes coses i saber què ha estat afectat. Al model antic, era més fàcil perquè els vostres operadors i tots els vostres sistemes de control us ho deien, però quan el nom del vostre servidor és un codi UPC, és molt difícil esbrinar les coses.

No es poden permetre falses alertes, no es poden permetre les coses que diuen: "Hi ha un problema amb aquesta màquina i que la màquina allotja 30 bases de dades." No es pot permetre que les coses no tinguin antecedents. Les consoles de control són fantàstiques quan s’encenen, però si la llum vermella torna a ser verda i no sabeu per què, i no teniu cap historial per tornar a veure què hi havia, i què? context, teniu problemes. Necessitem sistemes que ens facin un seguiment, necessitem un millor control, tractant els problemes intermitents cursius que mantenen l’historial de dades.

Coses millors i llindars de mètrica senzilla que ens proporcionen mètriques clau, però no ens guien directament cap a allò normal, què és anormal i amb quina freqüència es produeixen aquests problemes. De què parlem realment és una combinació de l’entorn de vigilància i el rendiment amb el rendiment i els venedors s’han assegut a les mans. No ens han proporcionat eines millors. Tenim sistemes amb més CPU i memòria del que sabem què fer amb tot i, tot i així, encara confiem en models d'intervenció manual, no hem posat la màquina en funcionament, per guiar-nos, per arribar al punt de problemes., no hem arribat a aquest nou estil, és a dir, "Hi ha un problema aquí, podeu fer-ho per solucionar-ho", o "Hi ha un problema de rendiment, en realitat és amb aquesta instrucció SQL específica, aquí hi ha tres coses que podríeu fer utilitzeu per arreglar aquesta declaració SQL. ”Aplicant heurístiques, aplicant models d’aprenentatge automàtic que puguin mirar els patrons d’ús del vostre sistema per detectar problemes i evitar falses alertes. Utilitzar la màquina per fer el que la màquina pot fer millor, augmentar el DBA o augmentar la persona que ha de fer front a problemes de rendiment.

Aquesta és la nova manera, en contraposició a l’antic estil. Hi ha un problema amb aquesta base de dades, les coses són lentes i, per tant, tenim noves tècniques, noves maneres de fer-ho, i hauríem d’aplicar-les, i és cap al mercat. Estàs veient que comença a créixer, no amb els grans venedors, sinó amb empreses de tercers, i això reflecteix alguna cosa que va passar fa vint anys quan els venedors de bases de dades no van proporcionar cap cosa per ajudar a gestionar els sistemes. Així és com és la direcció del mercat i, per tant, m'agradaria tornar a Eric.

Eric Kavanagh: Està bé, vaig a lliurar-ho a Dez. I Dez, traieu-lo, el pis és vostre.

Dez Blanchfield: Gràcies, Mark. Heu fet un treball fantàstic de cobrir el component tècnic del mateix. Hi abordaré un angle lleugerament diferent per posar en relleu el que ha passat a la resta del món, pel que fa a l'impacte sobre les empreses i les bases de dades que els envolten. Permetin-me només saltar a la primera diapositiva.

A la part posterior del que acabeu de tractar des de la vessant tècnica de les coses i des del punt de desenvolupament de les coses, estic veient que les empreses han de fer front al repte de les dades i les bases de dades, i, evidentment, hem tingut aquest canvi important cap a aquest concepte de dades grans, però les bases de dades segueixen sent efectivament el nucli i l’ànima d’on les organitzacions conserven la seva informació comercial, i és des de la porta principal fins a l’oficina. Totes les parts de l’organització estan tocades per una base de dades d’algun tipus i alimentades per una base de dades, i molt poques vegades entro en discussions de projecte o en alguna forma de conversa estratègica innovadora en una organització on el tema de la base de dades o el sistema de bases de dades. no apareix, i sempre hi ha preguntes al voltant del tipus de coses que acabem de parlar, de rendiment i seguretat, i com s’acosta el desenvolupament a aquest repte, i on s’ajusten les bases de dades i la nostra consciència d’entorns i aplicacions. els entorns en què parlem, i els dispositius i la mobilitat?

No deixa de ser un tema molt intens, i ha estat un des de fa molt de temps en el gran esquema de coses pel que fa a la tecnologia moderna. Fins a aquest punt, crec que és gairebé tot el que fem en el nostre dia a dia, és a dir, la nostra vida diària, que ara té el suport d’alguna forma de base de dades. Quan pensem en tot allò que ens envolta, tant si es tracta d’una factura que arriba al correu cada dia per algun servei que estem comprant, inevitablement s’està imprimint per un sistema que parli amb una base de dades i hi som. Els nostres telèfons disposen de bases de dades amb contactes i registres de trucades, entre d'altres.

Allà on anem, hi ha alguna forma de base de dades al darrere de la xerrada i els sistemes que utilitzem i, sovint, són prou transparents per a nosaltres, però el fet és que hi són. Així que he pensat en cobrir ràpidament per què s’ha convertit en una qüestió molt poc en un període de temps molt curt. Al principi, el concepte de base de dades provenia d’aquest encantador cavaller, Edgar Codd. Mentre treballava a IBM, canviava el món pel que fa a la gestió de dades creant un concepte al qual es coneix com a base de dades relacional.

Al principi, la base de dades era una base de dades i la vida era bona, era bastant senzilla tant en columnes com en referències, etcètera, i taules, i el programari de desenvolupament era bastant senzill i el rendiment no era tan important. era una nova tecnologia apassionant. Vam accedir a les bases de dades a través d'alguna forma de terminal, i només es pot crear tants estralls al final d'un terminal 3270 en un mainframe i, invariablement, altres tipus de terminals. I en la majoria dels casos, els terminals d’estil antic eren molt similars als que hi ha actualment als entorns web, i és que faríeu un formulari a la pantalla del terminal i feu clic a Enter i desactivar-lo. disparar com un sol paquet, com a sol·licitud i el sistema de fons el tractaria. Això és essencialment el que passa en un navegador web en aquests dies, quan escriviu un enllaç en un navegador web i aquest formulari no sol tornar en temps real al sistema, tot i que amb AJAX aquests dies, això no és completament el Caixa.

Però després va passar alguna cosa, va arribar el futur, i més recentment Internet, i gairebé ahir, en una secció web 2.0, i a tocar de la banda, tenim Internet de les coses. I en el procés que el futur succeeix, el món de les bases de dades acaba d'explotar, i les interaccions amb les bases de dades han esdevingut una cosa que tots vam fer de manera predeterminada, no era el cas que anéssiu a algun lloc a fer alguna cosa, com comprar. un bitllet per a un avió i voldria viatjar a l’altra banda del planeta, algú va haver d’escriure al terminal totes les seves dades i entrar a una base de dades i imprimir un bitllet.

Gairebé tot el que fem ara, tant si es tracta d’una cabina a Google amb una aplicació, com si s’està saltant a la banca d’internet, tot el que fem dia a dia, amb algun tipus de sistema, funciona amb una base de dades. I quan va arribar internet, això ens va resultar una mica més fàcil, la nostra vida quotidiana a través d’un navegador web, i la web 2.0 apareixia, i les coses es feien mòbils i la dimensió de les coses acabava d’explotar. De fet, la meva línia preferida en aquest tema és que, "Internet connectava tot, la web 2.0 la convertia en mòbil i social, i les coses es van fer molt, molt grans i ara tenim internet i coses i, i IoT … Yikes !!" Ni tan sols hem començat a imaginar l'impacte d'Internet de les coses quan es tracta del món en els sistemes de bases de dades.

Així, en termes moderns, el que abans pensàvem com un terminal s’ha convertit efectivament en aquestes coses, són els telèfons mòbils, es tracta de diverses classes de tauletes, ja sigui tauletes de gran pantalla personal de consum gran o d’empresa, es tracta d’ordinadors portàtils i és l’escriptori tradicional. d’alguna forma. En aquesta imatge es poden veure gairebé totes les formes d’interfície que ara estem utilitzant per parlar amb sistemes de bases de dades i aplicacions que són alimentades per aquests, des dels petits gadgets de les nostres mans que semblen enganxats i a tots els quals sembla que estiguem enganxats. el pas fins a versions lleugerament més grans, i iPads, i altres tauletes i superfícies de Microsoft, fins a portàtils quotidianes, que ara sempre són el cas en entorns professionals, etc. Les persones solen aconseguir un ordinador portàtil i no un ordinador d’escriptori fix, però són els moderns criteris que crec que són part del motiu pel qual les bases de dades pateixen tot tipus de reptes en el rendiment de gestió de la nostra vida i no només en el desenvolupament.

Per tant, suposo que és un dels grans reptes que encara tenen davant les empreses el dia a dia. Tothom pensava que les bases de dades eren els nostres únics problemes, no ho són. I doncs, de què ha estat l’enrenou? Doncs quan passem d’un extrem a l’altre amb totes les coses relacionades amb bases de dades, des d’un sentit comercial, i Mark’s va cobrir els components tècnics molt, molt bé, però en el sentit comercial, com a organització, pensem en bases de dades. Estem tractant totes les coses des del front endavant del disseny i el desenvolupament bàsic. Quan comenci una empresa, pensarà en desenvolupar aplicacions, desenvolupar una capacitat o, fins i tot, implementar una aplicació existent d’alguna forma. S'ha de produir una forma de disseny i desenvolupament, i s'ha de pensar molt en la manera com aquests sistemes de bases de dades s'aplicaran, seran recolzats i gestionats, i les actuacions seguides, etc.

La integració de l’entorn i les aplicacions de bases de dades, i els tipus d’API, els tipus d’accés que s’ofereixen ara són cada cop més complexos i més difícils. Administració, suport i còpies de seguretat quotidianes, de nou, es tracta de coses que pensàvem solucionades, però tot seguit l'escala es va fer molt més gran i les coses es van moure més ràpidament i el volum és molt més gran; la mida dels entorns, els sistemes de bases de dades havien de suportar la velocitat amb la qual es mouen les transaccions.

Penseu en una base de dades en un entorn comercial molt freqüent i molt alt, no hi ha cap manera que els humans puguin fer-ne un seguiment, només és un grup de màquines que lluiten contra un altre cúmul de màquines per fer operacions de compra, venda i venda d’alta freqüència. que es produeixen aquestes transaccions. Penseu en un escenari actual, com un llançament primerenc d'una pel·lícula de Netflix on no parleu només de centenars o milers, o fins i tot de centenars de milers, possiblement milions de persones que vulguin veure la pel·lícula des del primer moment que es publica. Tota aquesta informació és capturada, rastrejada, registrada i analitzada en una plataforma de bases de dades.

I després hi ha el món permanent en què vivim ara, les 24 hores del dia, no només seguim el Sol, sinó que sempre hi ha algú a mitjanit amb ganes de fer alguna cosa, i els horaris comercials segueixen el Sol a tot el món. Així, doncs, el temps i la disponibilitat són per defecte, és un clima ara, tenir una interrupció realment no és gens acceptable. I la redundància, si hi ha un problema de rendiment o si necessitem una finestra de manteniment per fer una actualització o un pegat, o una seguretat, realment, hem de ser capaços de tallar d’un entorn de base de dades a un altre i fer-ho de manera perfecta i automàtica.

Seguretat i estàndards i compliment, hem tingut algunes coses força importants en el món tardà, en particular, GFC, i per tant, tenim un ventall de nous reptes per afrontar el compliment i la seguretat i els estàndards de concordança, i necessitem per informar sobre els usuaris en temps real i, idealment, en un quadre de comandament. No volem enviar un equip de micos a un centre de dades per intentar trobar coses, necessitem que el sistema ens ho expliqui immediatament, en temps real.

I els dos grans divertits dels quals gairebé ningú parla, generalment els empenyem sota la catifa i esperem que no aixequin mai el cap lleig, sinó la recuperació de desastres i la continuïtat del negoci, també són coses que haurien de en la seva majoria, que es produeixi automàticament, en cas de sorgir la necessitat.

Podríem passar dies parlant del tipus de coses que poden funcionar malament als entorns de bases de dades i que els humans generalment han respost, però ara necessitem sistemes i eines per fer-ho. Un exemple és un incompliment de dades, i així, quan pensem en bases de dades i em plantejo aquesta pregunta de manera obert en diverses formes: què passa amb les bases de dades quan treiem els ulls de la pilota i alguna cosa crítica passa malament? En particular, si no hi ha cap sistema que miri el rendiment i la seguretat i altres aspectes importants de l'execució de bases de dades.

Bé, el que podria passar és això, es tracta d’una captura de pantalla d’alguns dels incompliments recents dels darrers dos o tres anys. Invariablement, tots provenen d’un sistema de bases de dades i, invariablement, hi ha hagut algun problema en seguretat o control, o en l’accés que es produeix, i a la part superior esquerra estem buscant 152 milions de comptes d’Adobe, on es detallen tots els detalls. d'aquests clients es va incomplir. Si hagués estat el cas de les eines adequades per rastrejar i capturar l'incident i controlar la seguretat, podríem haver evitat alguns d'aquests, el primer parell de centenars de registres robats ens podrien haver alertat i hauríem tingut va detenir els prop de cent cinquanta milions.

A continuació, arribem al punt clau de tot aquest viatge, que ens han dut a terme, és a dir: per què necessitem sistemes millors? Per què no podem llançar més cossos a aquesta cosa, que hem cregut bé i realment el punt de mira, i, certament, crec que hi ha un cas que ha estat una evidència tardana, que llança més DBA, administradors i més gent. aquesta cosa no soluciona el problema. Necessitem un millor conjunt d’eines i un millor conjunt de sistemes.

A continuació, es mostren els cinc principals motius pels quals crec que això ho recolza i es classifiquen per ordre d’importància, en funció del que estic veient a través d’aquestes empreses privades i estats que són entorns governats, els reptes que tenen els entorns de bases de dades, i gestionar-los.

Seguretat i compliment: número u. Ja sabeu, controlant qui té accés, d’on tenen accés, quan tenen accés, de quina freqüència tenen accés, des d’on han accedit. Potencialment els dispositius que han tocat, els tipus de coses que han vist i el compliment que hi ha al voltant. Si els éssers humans realitzen informes 30 dies després per dir-nos si les coses estan bé, ja no és adequat, ha de passar en temps real.

Rendiment i monitoratge: sembla que no s’explica, però sempre no ho és. Tant si estem utilitzant eines de codi obert com algunes eines comercials de tercers, sempre no ens hem perdut el bot, de moltes maneres, amb els tipus de control de rendiment que cal i el detall que i la capacitat de resposta a temps .

Detecció i resposta d’incidents: ha de ser una cosa instantània en temps real, i sempre necessitem un sistema que ho faci per nosaltres, o com a mínim, ens avisi ràpidament perquè puguem tractar-ho, de manera que es tractin els pocs problemes que es plantegen. amb rapidesa i no caure fora de control.

Administració i administració: de nou, pensem que aquests problemes es resolen, no ho són. L’objectiu dels problemes als quals s’enfronten els equips de bases de dades, en especial els DBA on un sistema hauria de tenir cura de nosaltres, encara no hem solucionat aquest problema, no deixa de ser una cosa real.

I des del primer moment amb el disseny i desenvolupament, quan comencem a construir aquestes eines, construïm entorns de bases de dades, podrem llançar les eines adequades al desenvolupament i proves i la integració de plataformes. Tot això no és fàcil per a nosaltres, i tot aquest viatge ens porta a un mateix missatge que, en la meva ment, necessitem sistemes i eines millors per ajudar-nos a obtenir els resultats que necessitem. el nostre entorn de bases de dades, de manera que les empreses que impulsen el valor dels nostres clients. No podem simplement tirar més cossos i més DBA, l'escala és massa gran, la velocitat massa ràpida i el volum massa elevat. Amb això, Eric potser us tornarà a passar.

Eric Kavanagh: M'encanta, tenim molts terrenys coberts, molta oportunitat, i passem les claus a Bullett en només un segon.

Bullett Manale: D' acord.

Eric Kavanagh: Ah, deixem-ho i Bullett, ara us ho lliuro i el pis és vostre.

Bullett Manale: D' acord, gràcies. Crec que s’han fet molts bons punts. Vaig voler parlar ràpidament només per un segon sobre Idera, qui som, i després saltarem. Va a parlar de l'eina que crec que moltes coses d'aquestes coses parlem, podem el tipus de conjunt i el tipus de discussió d'algunes de les àrees en què s'alineen, amb aquesta eina, el producte Gestor de diagnòstic.

Ara, el que vull fer primer és simplement una mica de fons sobre qui és Idera; portem aproximadament des del 2003 i, per tant, hem començat només amb les eines de SQL Server, i en què ens centrem avui en dia, és el producte del Gestor de diagnòstic. Però podeu veure tots els cubells de coses que tenim aquí, i recentment, com s’ha dit anteriorment, vam adquirir Precise i mitjançant l’adquisició, també tenim Embarcadero, de manera que tenim una cartera de productes força bona.

En termes de supervisió de rendiment, en termes de SQL Server, el producte del qual vull parlar, que alinea aquests temes que tractem, és el Gestor de diagnòstic. Ara, aquest és un producte que ha estat força prop del principi dels dies d'Idera, i he tingut la sort de formar-ne part des del 2005. I he vist molts canvis en termes de SQL Server, passa de físic a virtual, tot aquest tipus de coses que han passat i també les necessitats dels DBA a mesura que creixen els entorns i aquest tipus de coses.

Amb el que vaig començar, va ser que l’usuari típic del nostre producte és el DBA i, per tant, quan parlem amb gent per primera vegada, clients potencials, és la majoria dels DBA amb què parlem. No estem parlant amb els responsables d’informàtica o els directors, pot ser que en algun moment arribin a aquest nivell, però l’inici inicial és que l’ABD té un problema, l’ABD intenta solucionar el problema i moltes vegades ho fem. Ja baixareu i descarregueu i provareu el producte com a part d’això. Obteniu el gestor de dades o el DBA o el DBA en funcions, el tipus que té la sort de ser el més tècnic de la sala, en alguns casos. Ara, quan arribeu als entorns empresarials més grans, òbviament, llavors obtindreu els DBA completament bufats, normalment seran els que utilitzen l'eina. I vaig avançar i només vaig afegir una mica de trucada aquí des de la Viquipèdia. És una mena de responsabilitat sobre el DBA com diu Wikipedia, això és el que fan.

Si visiteu el llistat aquí, moltes coses, no les vaig a llegir, però obteniu moltes de les coses típiques en les que pensaríeu, i en una d’elles, teniu un seguiment i optimitzar el rendiment de la base de dades, i és bastant important. I el que és interessant, és quan parles amb el DBA, sempre són els que es culpa primer, quan es tracta de problemes, i potser no és culpa seva, però quan hi ha un problema de rendiment, normalment amb una aplicació que està relacionat amb una base de dades de DBA, són els que tenen la culpa, de manera que sempre busquen els motius pels quals no és culpa seva. En molts casos, això és el que poden utilitzar aquesta eina, Gestor de diagnòstic, per ajudar-los a fer-los.

Però, al final del dia, també, si la base de dades no funciona, moltes altres coses no importen, les vostres aplicacions no funcionen, i en realitat no importa moltes d’aquestes coses. En primer lloc, volem ser capaços d’assegurar-nos que l’usuari experimenta la manera com ho coneixem, no disminueixi, és una cosa que sempre fan els DBA. I crec que, si ens fixem en les raons per les quals la gent normalment compra i utilitza el producte del Gestor de diagnòstic de SQL, una de les primeres raons, probablement no és la més important, ni per últim, però és igual d’igual a tots els membres del tauler, i depenent amb qui parli, aquestes raons, gairebé una o dues d'elles són sempre, hi ha algun tipus de necessitat.

Però el primer és que només es pot tenir aquesta visió centralitzada de les instàncies com a SQL que gestionen. I el més curiós és que en molts casos, si preguntes a un DBA, "Quantes instàncies gestiones?" El nombre canvia tan sovint, que en alguns casos no són segurs. Per això, necessiteu alguna cosa més que poder llençar-ho tot a la pantalla. Voleu agafar aquesta informació, voleu donar-vos compte i, per tant, una de les coses que definitivament us pot ajudar el Gestor de diagnòstic és poder proporcionar-vos aquest tipus de vista sobre l’entorn.

I no es tracta només d’una visió sobre l’entorn, sinó que és el que l’Administrador de la base de dades es mostra còmode i és una consola centrada en el DBA, si ho voleu. Està pensat per a un administrador de bases de dades. Hi ha moltes eines de control per fora, hi ha moltes eines de rendiment, però, com he dit, al final del dia, el DBA vol una eina dissenyada per a un DBA, perquè hi ha moltes coses específiques per a què fan. en el seu dia a dia.

I amb això dit, teniu SCOM, teniu HPF, totes aquestes altres tecnologies, però volen alguna cosa que sigui particular del que fan. Crec que podem ajudar-nos en aquest àmbit amb aquest producte, que veuràs quan ens endinsem en un segon. L’altra cosa que veiem amb el DBA que definitivament també és una de les coses que hem tocat abans, és que han de ser capaços de veure el que està passant, òbviament, i que han de poder veure a tota l’empresa. i tingueu tranquil·litat en saber què passa. Però, al mateix temps, no estan asseguts allà mirant les consoles.

Recordeu tots els punts que heu vist en aquesta llista que he acabat de treure? Han de fer aquestes altres coses, per la qual cosa no es tracta només d’esperar que s’apagin els incendis. En molts casos hi haurà reunions o moltes de les finestres de manteniment relacionades amb l’administrador de la base de dades s’executen al mig de la nit quan dormen, de manera que han de tenir la capacitat de tornar enrere i veure què va passar. . En molts casos, si no agafeu alguna cosa quan passa, un cop desaparegut el problema, o almenys amb SQL Server, es converteix en un problema on es tracta la situació en què no ho feu ja teniu restes d'aquest problema. I aquests problemes desapareixen, i també ho fan les restes, la qual cosa significa que amb els que resoleu menys, amb menys informació per treballar.

Dit això, sens dubte una de les coses que pot ajudar el Gestor de diagnòstic és donar-li aquesta visió al passat per consultar la informació del passat: "Tenia una alerta amb bloqueig, he tingut problemes amb bloqueig, teníem coses que estaven passant quant als nostres recursos? ”Puc tornar i consultar aquesta informació. Puc perforar en moments puntuals. Podria fer totes aquestes coses directament des de l’eina.

Totes aquestes coses, malgrat que sigui o no una aplicació interna o externa, els DBA volen saber-ho, perquè volen ser capaços de veure què causa el problema. No importa si va ser algú de dins de l’organització o algú fora de l’organització que va escriure el codi; encara volen poder aïllar-lo, perquè sàpiguen que el problema està passant i saben d’on ve.

Així doncs, el rendiment i la rendició de comptes són una part clau del que fa el nostre producte. Podem proporcionar tots aquests detalls, i el que és bo, és que teniu la capacitat de recórrer. Si hi ha un coll d’ampolla, podeu correlacionar-ho amb l’aplicació, l’usuari, la base de dades, la consulta. I una vegada més, és una mena de pistola per fumar. Obteniu una correlació directa entre quan s’executa aquesta consulta, què fa? I no només es tracta de la consulta en si, ja que s’executa en si mateixa, sinó que la consulta amb el pas del temps empitjora? I també es poden respondre aquestes coses, amb el producte, que és definitivament una cosa que si intenteu ser proactiu, és bo poder dir: "Hola, aquí teniu una consulta que va funcionar malament, però el noi mira. com que va més enllà, podem veure que funciona encara pitjor i pitjor, puc fer alguna cosa per això. "

Si entrem a la zona següent aquí; i aquest és probablement, diria que aquest és un dels grans. Una de les preguntes que em plantejo, quan mostro el nostre producte és, sempre preguntaré a l’administrador de la base de dades: "Com se sent un problema relacionat amb les bases de dades de SQL Server?" I és molt graciós, ja que la majoria del temps, ara concedit, la majoria de vegades es mira el nostre producte, ja que en molts casos intenten solucionar una determinada necessitat. Però és interessant escoltar el tipus inicial de coses, almenys amb SQL Server, és que era el que tenia, ja ho sabeu, en els primers temps de SQL Server teníeu SQL Server i després teníeu Oracle. I tothom tenia Oracle, i SQL Server era com el que, per no tenir una millor expressió, el grup de cap de pell de les bases de dades, quan va començar.

I, a continuació, quan Microsoft li va afegir més funcions, es va convertir en una mica més en una eina empresarial. I, òbviament, ha recorregut un llarg camí des de llavors. Però la qüestió és que una vegada podríeu argumentar que les bases de dades no es consideraven critiques en aquell moment. I això ha canviat amb el pas del temps. Ara per això, en molts casos la gent està intentant posar-se les mans al voltant i li va dir: "Sabeu què? Tinc totes aquestes bases de dades SQL Server, estic tractant de manejar-lo. "I més que escoltar problemes sobre el servei d'assistència o escoltar problemes de persones específiques que, com els propis usuaris, " Estan buscant formes per evitar-ho, i estan buscant maneres de donar-se a conèixer abans d'aquestes situacions.

I, per tant, amb Diagnostic Manager, aquesta és una de les coses que, intentem fer, també és capaç de fer que el DBA sigui el primer que sàpiga sobre aquestes situacions o aquests problemes, perquè puguin fer-ho. alguna cosa al respecte, bé quan passin, o fins i tot fer un pas més, per analitzar aquests sistemes que vetlla. I per poder-vos donar consells proactius que milloriran el rendiment d’aquesta instància i podreu fer-ho de manera regular. Per exemple, hem d’afegir un índex, en funció de la càrrega de treball; aquest tipus de coses, les eines que també poden fer-ho. Així doncs, veurem molt d’això a l’eina.

L’altra cosa i l’últim que hi ha en aquesta llista, que és una descripció general, però és sens dubte una cosa que cal destacar. I sobretot, a mesura que entris en situacions més grans a nivell d’empresa, en què hi ha moltes instàncies, sempre hi haurà alguna cosa obscura que voldré controlar, si sóc l’administrador de bases de dades, per exemple. Per tant, el que intentem fer és preveure el que el DBA típic vol monitoritzar.

Dit això, també podríeu fer-ho: sempre hi haurà alguna cosa nova. Així, us proporcionem una manera d'afegir les mètriques que necessiteu per controlar i gestionar després que es pugui afegir el punt d'instal·lació. De manera que qualsevol comptador PerfMon, comptadors WMI, contadors d'objectes SQL Server; totes aquestes es poden incorporar a l'eina. Podeu afegir consultes addicionals que es puguin incorporar als vostres intervals de votació.

I, l’últim que també cal destacar és que podem afegir i comunicar-nos realment tant amb vCenter com amb Hyper-V per poder treure les mètriques d’aquests entorns. Com que una de les coses que hem identificat amb el DBA, és que normalment no formen part de les operacions específicament. I no necessàriament solen tenir, ja ho sabeu, l’entorn de vCenter al seu abast, ni aquest tipus de coses disponibles.

I el problema és que si es tracta d'una instància de SQL Server i se'ls han assignat recursos, però aquesta instància està virtualitzada, pot semblar que tenen tots els recursos del món quan només controlen el que és al sistema operatiu convidat. La realitat és que, a l'amfitrió, hi podria haver 30, o 40, o 50 o 100 altres VMM que intenten accedir i tenir contenciós dels mateixos recursos. I l'única manera de veure-ho realment és comunicar-se amb aquells altres entorns i amb aquestes interfícies, en aquest cas, que fem.

Podeu afegir altres tipus de comptadors a l'eina. Ara no es tracta només de controlar aquests comptadors, sinó de fer que aquests comptadors nous, que introduïu al producte, els facin part de l’eina, com si fossin una mètrica fora de caixa . Una cosa excepcional que voldríeu supervisar; de manera que això significa poder incorporar-los als seus taulers. Significa poder afegir-los als vostres propis informes personalitzats, poder definir llindars i alertar evidentment, però també basar-los i poder establir uns llindars amb cert coneixement, d’on establir-los en funció de coses com la vostra bases bàsiques i el que és normal. Per tant, teniu moltes coses d’aquest tipus que també estan en producte.

El que us he proporcionat és el que anomeno "els principals lliuraments de Diagnostic Manager", i puc avançar i donar-vos una mica de gust tot entrant al producte. El que faré és compartiu la pantalla, d’acord i només arrossegueu aquesta opció. Així que el que veureu, aquesta és la consola de Diagnostic Manager. I com he comentat abans, anireu a aquest primer nucli distribuïble, podent mirar coses que siguin del tipus d’empresa: hi ha molts exemples diferents dins de l’eina. Tenim una mena de vista en miniatura, tenim més que una graella de vista. També tenim, en termes de flexibilitat, També hi ha una consola basada en la web. La consola basada en la web té altres vistes a la vostra disposició, com ara mapes clau i coses així, però el cas és que és capaç de mirar i veure les coses. a un nivell elevat, però a mesura que es produeixen problemes, aneu a endinsar-vos una mica més a l’eina i veureu la prova específica lems i tenen alguna manera d’entendre i saber què passa. I, òbviament, és molt important.

Ara, en termes de poder veure realment què va passar en el passat; Si estic buscant un problema que va passar ahir, o fa una setmana, en aquesta situació, ja ho sabeu, tindreu la necessitat de poder sortir a una instància determinada d’SQL. I la bona notícia és que, si sabeu a quina hora va passar aquest problema dins del producte, podeu dirigir-vos directament al navegador d'historial. I puc assenyalar una hora determinada del dia; podria ser des de fa un parell de setmanes, podria ser des d’ahir. Però el dia que trieu al calendari, em presentaré els diferents intervals de votació. En aquest cas, efectivament estic veient el que hauria vist si hagués vist la consola el 20 d’abril a les 13.37 hores

Per tant, puc tornar enrere en el temps i, una vegada que ho faco, totes les diferents pestanyes que veiem aquí reflectiran aquest moment en concret, incloses les consultes que podrien haver estat mal funcionant, incloses, potser, si Vaig tenir sessions amb bloqueig. Tot aquest tipus de coses apareixerien a l'eina i em permetrà aprofitar òbviament aquesta informació històrica per poder resoldre el problema. Ara en aquesta nota, quan parlem d’historial, l’altra cosa que cal destacar és que no només usem l’historial per solucionar problemes. És evident que aquesta història és molt valuosa, per altres motius. Un dels principals és poder prendre decisions de manera eficient i poder prendre decisions ràpidament, amb la informació adequada. Així, doncs, de tota la història, de tota la informació que estem recopilant, podem presentar en contra.

Si algú ve a mi i em diu: "Tinc aquesta nova aplicació realment fantàstica. Va a canviar el món tal com la coneixem. Oh, per cert, necessitarà una base de dades i, per cert, va a enganxar realment la I / O a la màquina on es troba aquesta base de dades. " Si sé que hi entra, aleshores puc aprofitar aquesta informació per poder proporcionar una classificació de tots els meus servidors de producció, basada potser en els darrers set dies de recollida. I seria capaç d’arribar a la conclusió de quins casos té més sentit utilitzar aquesta base de dades. De manera que aquest tipus d'informació històrica també és òbviament molt valuosa.

Pel que fa a les pròpies consultes; pel que fa a les consultes, hi ha moltes maneres diferents de fer-ho a l'eina. I el que més m’agrada mirar és la Query Waits View, perquè la Query Waits View és molt útil pel que fa a la possibilitat de valorar. Si tinc un coll d'ampolla, es pot identificar fonamentalment totes les diferents àrees que afecten aquesta consulta específica; No només la consulta en si i quin és l’impacte d’aquella consulta, sinó que, ja sabeu, de quina aplicació va sorgir, de quina sessió va venir, que l’usuari va anomenar i de totes aquestes coses, puc veure que, òbviament, és informació. en temps real, però també tinc la possibilitat de mirar aquestes dades del passat. I aquí és una de les coses, i he tret un guió, però he d'esperar que aparegui.

Mentre esperem això, vull - i sé que som breus, així que he volgut parlar una mica també sobre alertar que les notificacions siguin proactives. I quan parleu d'aquest tipus de coses, com he dit, que són la part proactiva, hi ha moltes eines que permeten alertar. La part difícil no és enviar un correu electrònic. La part difícil no és escriure al registre d'esdeveniments ni generar una trampa SNMP. La part difícil és saber quan s’ha d’enviar aquesta alerta en els moments adequats. De manera que es tracta d’haver de fer alguns càlculs, havent d’entendre: "Què es tracta d’aquella instància en concret i què és normal pel que fa a aquesta instància?"

Per tant, per a totes les mètriques que tenen sentit fer-ho, basem les mètriques. En realitat us mostrem la línia de referència, us mostrarem el llindar al qual s’estableix actualment. I l’altra cosa interessant, és que diguem, en aquest cas he establert els meus llindars sis i deu només per a aquest exemple. D’aquí a sis setmanes, si torno a aquesta instància, aquesta línia de base pot canviar completament, perquè una de les coses que fem quan calculem la línia de base, per defecte, és un càlcul de set dies set. Per tant sempre em proporciona una versió actualitzada de la línia de referència. I què passa si aquesta línia de base s'amplia als meus llindars? En aquest cas, puc veure i alertar recomanacions que bàsicament diuen: "Hola, teniu un llindar que probablement s'ha establert incorrectament, específic per a on veiem que està el llindar i, òbviament, on es troba la línia de base, probablement aneu a rebre una alerta per alguna cosa que és normal. "

I, en lloc de tractar un símptoma d'alguna cosa normal, sóc capaç d'identificar aquest tipus de situacions en què el llindar real es defineix de manera incorrecta. I el que em permet fer, òbviament, és establir els llindars d'acord a on vaig a rebre una alerta. És una cosa que sé més que una crida a l'acció versus una investigació per veure si realment és un problema. I crec que una part de l’eina és realment útil pel que fa a la línia de referència pròpia i és capaç de calcular.

Ara, amb aquest producte teniu la capacitat de tenir diverses bases bàsiques; podeu definir-los per a períodes de temps diferents i podeu ajustar dinàmicament els llindars en funció de les vostres línies bàsiques, cosa que també és molt important per adaptar-vos als canvis que es produeixen dia a dia a les instàncies del vostre SQL Server . Ara, en aquest cas, es tracta d'una gran quantitat de paràmetres de llindars i us mostrem les línies bàsiques. Però, pel que fa a les alertes reals, la notificació per si mateixa, el més interessant del Gestor de diagnòstic, és que us proporciona diversos perfils d'alerta. Així, si per exemple teniu un perfil de trucada que és de 2:00 am a 5:00 am, puc tenir un perfil específic per a aquest interval de temps i puc establir totes les condicions i la configuració adequada aquí per la meva resposta

Ara bé, el que respon a la resposta és que, en alguns casos, sí que puc enviar un correu electrònic o puc disparar i generar un parany SNMP o escriure al registre d’esdeveniments. Hi ha moltes altres coses que podem fer, però, mentre parlo amb els DBA, el que realment els agrada és que en la majoria dels casos molta de la feina que es realitzi sigui repetitiva. Són coses que saben exactament quan passa el problema, què fer per solucionar-ho. Només han d’anar i intervenir. Així, a mesura que creixes el teu entorn, a mesura que tinguis més casos, és molt més difícil fer-ho. Una de les coses que podeu fer dins de l’eina que crec que val la pena destacar, és que teniu la possibilitat de configurar una condició, però basada en aquesta condició per poder definir una resposta per executar un guió, per executar un treball, per executar un executable. I, és cert, si decidiu executar un script, puc fer servir paràmetres, dins d'aquest script que estarà en temps d'execució, replet de la informació real.

Per tant, si hi ha problemes amb una base de dades específica, l'script es dissenyarà per funcionar només contra la base de dades on es produeix el problema. Així doncs, podeu resoldre els problemes de manera dinàmica de manera automatitzada i, a continuació, puc rebre un correu electrònic per tornar-me a dir-me que "Hola hi va haver un problema, però, per cert, ja es va solucionar". El guió es va executar i com a DBA ho sabeu, però en realitat no havíeu d’introduir ni intervenir. Ara, sobre aquesta mateixa nota sobre ser proactius, òbviament també tenim una altra característica aquí que és la funció "Analitzar". I el que farà és fer una revisió regular contra la instància de SQL. I, en alguns casos, farà una immersió més profunda en termes del que busca. Es faran coses com l’anàlisi d’índexs hipotètics. Afegeixo un índex? Elimino un índex? I, tot aquest tipus de coses, òbviament ajudaran amb la meva actuació, però, una vegada més, es tracta de ser proactiu. Es tracta de poder prendre decisions abans de les pauses de coses i fer que funcioni millor. I, en molts casos, això és el que intentem fer aquí.

Tornant a Query Waits de què parlem abans; com veieu, hi ha una gran taca aquí. Vaig exercir un guió anteriorment que només provocava alguna activitat d’espera i, com he comentat abans, tenim una manera realment única de descobrir aquesta informació. Si vull veure quina aplicació tenia; Puc veure que provenia de l’aplicació NoSQL. Podríem veure la base de dades a la qual estava vinculat, la sessió, l’usuari i, si vull, també puc classificar-ho en termes de les meves expectatives. Aleshores, puc dir, de totes les expectatives que estaven passant en aquella finestra del temps, quines eren les que passaven més? I si veig que quan ha passat el més important, el més maco és que puc aprofitar aquest tipus d'espera i puc veure totes les ordres. Si mireu aquí, feien que aquesta espera es produís. També puc veure principalment, quina aplicació tenia, que feia que aquesta espera es produís.

De manera que es queda com un polze adolorit. Immediatament puc anar a dir "Aquesta és l'aplicació que causa el meu coll d'ampolla. Ara, quina era la consulta que es va executar? Quin usuari l'ha executat? Quina base de dades s'executava?", Etcètera. Així que esperem que tingui sentit, i també serveix per assegurar-se que no teniu la latència dins del vostre entorn, ja que es relaciona amb les vostres bases de dades, espero que us sigui útil. Vaig a avançar en aquest moment i us ho passo, i suposo podem continuar des d'allà.

Eric Kavanagh: Certament. Per tant, suposo que només ho llençaré als nostres experts del dia. Marca, potser primer vol fer comentaris i fer un parell de preguntes. Aleshores, Dez, podeu entrar-hi.

Mark Madsen: Sí, gràcies, em va agradar molt veure-ho. És un monitoratge molt més intel·ligent del que estic acostumat a veure. Tinc curiositat per la gestió de les dades que hi ha al darrere; la gestió de les mètriques que podeu fer el seguiment i, ja ho sabeu, busqueu coses com ara canviar les línies bàsiques, en especial, que és un dels meus punts de dolor per a mascotes, amb taulers de taula. Com podeu fer front a aquestes dades, i la segona part, amb les mètriques de base, com ara el tipus de canvi, també podeu canviar automàticament els llindars, de manera que no he de fer-ho torneu a tornar i restabliu els llindars a mà quan canvia una línia de base?

Bullett Manale: Sí, i per això el més maco és que podeu decidir-ho. Vostè pot fer qualsevol. Puc establir un llindar i fer-ne una configuració estàtica o puc marcar la casella per dir: "Fes que aquest llindar sigui dinàmic, que canviarà a mesura que canvien les meves línies de referència." I tinc la capacitat i l'eina de configurar una finestra predeterminada. però, si ho necessito, podria tenir una finestra de base diferent, per exemple, de la finestra de manteniment de les 2:00 am, diguem-ne fins a les 5:00 am, perquè em tributaré CPU, les meves unitats i tota la resta perquè és quan fem tot el nostre manteniment. A continuació, automàticament, si ho tingués seleccionat, ajustaria automàticament els meus llindars per estar fora d’allò que sigui normal per a les mètriques que Tinc la decisió de fer-ho. Em permetria fer-ho, bàsicament, teniu la possibilitat de fer servir l'eina per configurar les finestres del temps, és a dir, les vostres finestres bàsiques i cada finestra es pot tractar com una entitat separada en funció de la l'ajust dinàmic de la línia de línia que es pot fer i podeu afegir tantes finestres de la vostra línia de base com jo necessiteu, si té sentit. Podeu tenir una finestra de cap de setmana, un dia feiner durant l’horari laboral, una finestra de manteniment que es produeix a mitja nit i així successivament.

Mark Madsen: Gràcies.

Bullett Manale: suposo que tornaré a la primera part de la pregunta, la tenim i recopilem tota aquesta informació. Realment no parlava sobre l'arquitectura, però sí que tenim un dipòsit de fons, que teniu un control complet sobre la retenció d'aquestes dades, però també tenim un servei que s'executa al mig de la nit. tots els nostres càlculs de base i es prenen aquestes dades, les recopilen i tenen sentit. I, òbviament, juntament amb això, també teniu nombrosos informes que podem utilitzar per informar en relació amb les vostres línies de referència, per obtenir mètriques concretes. I, fins i tot, podeu tenir la possibilitat de comparar les vostres línies de referència del mateix servidor, per a la mateixa mètrica durant diferents períodes de temps. Podeu veure si hi ha diferències que s’han produït o què és el delta. Hi ha molts d'aquests tipus d'opcions.

Eric Kavanagh: Dez.

Dez Blanchfield: Una pregunta ràpida que tinc per a tu: hi ha un ampli espectre de què pot fer aquesta eina. Actualment, esteu detectant un ús en l'etapa inicial del desenvolupament, o encara és principalment una eina de medi ambient de producció? És a dir, els desenvolupadors tenen accés i utilització mitjançant el seu desenvolupament primerenc i, a continuació, provant la fase d’integració? O encara s’utilitza predominantment en entorns de producció?

Bullett Manale: Diria que, la majoria de vegades ho veiem en entorns de producció. Depèn de les situacions, però, en la seva majoria, diria principalment producció i ho fem, i també és, ja sabeu, just esmentar que tenim preus diferents per a entorns de dev i test, de manera que és una mica més atractiu. Veiem que la gent s’utilitza per a aquests entorns, però diria que, si hagués de donar-vos una resposta d’una manera o d’una altra, diria que principalment encara són entorns de producció on veiem que la gent inverteix per aquest producte. .

Dez Blanchfield: Clar, sí, i va ser interessant escoltar que teniu diferents punts de preu, perquè òbviament hi ha càrregues de treball diferents i el que més pesarà serà on es fa tota la feina real. Però estic veient moltes organitzacions, sobretot en el govern i, certament, en defensa, on el desenvolupament ara aconsegueix el mateix nivell d'inversió en eines i sistemes que els entorns de producció, perquè fan proves molt més avantguardes. En defensa, per exemple, hi ha equips que realitzen milers de milions de proves, centenars de milers de milions de proves en aplicacions i sistemes i eines, i els supervisen abans que fins i tot es facin proves d’integració, perquè volen assegurar-se que hi ha un codi construït i la base de dades. està assegut per sota. S'arriba a la iteració del cent i un milió o alguna cosa, mentre que al camp disparen a algú, no es produeix "cop".

Bullett Manale: Segur.

Dez Blanchfield: En el món de la base de dades de les antigues escoles, segons la meva experiència, pensar que l’entorn de la base de dades és una cosa que acaba de deixar en les dades i que alguns de vostès saben, són molt rares i es parla molt poques vegades, així quan arribem al punt d’eines les aplicacions es desenvolupen, sobretot amb plataformes analítiques, ara es troben als nostres telèfons mòbils i als nostres dispositius. Esteu veient que els clients aporten la conversa del rendiment de la base de dades i de la gestió de bases de dades en una discussió més quotidiana que no pas a tecnologies exclusives? I sé que havíeu comentat abans que parleu principalment amb els DBA, però ara hi ha una tendència en el vocabulari general. Veieu gent on discuteixen aquests temes, a diferència dels només geeks?

Bullett Manale: És difícil dir-ho. Vull dir, com he dit en la seva major part, que la gent amb qui ens ocupem pel que fa al procés de venda és, de totes maneres, amb els professionals, que són els DBA. Així que en termes de la teva pregunta, només dius: "En termes generals, la gent de l'organització informàtica, és que cada vegada són més conscients de la base de dades?" Suposo que és la pregunta i diria que probablement la resposta és "sí". Probablement no ho veig tant, basat en el que estic, dia a dia, però crec que si entenc la vostra pregunta, seria la meva resposta, suposo.

Dez Blanchfield: Sí, està bé. Probablement és una pregunta carregada, ho sento, perquè òbviament els vostres interessos predominants, en el vostre món, són el costat tècnic de les coses. Tinc curiositat en què en les activitats del dia a dia estic veient que les organitzacions comencen a portar-ho a la conversa molt aviat. Així, quan es parla de noves iniciatives, nous projectes, nous programes de treball, una de les coses que vénen immediatament és: "Com el seguim, com el seguim, com tractem els problemes que sorgeixen, en contraposició a llançar-se, anar en directe? "

Bullett Manale: diria que …

Dez Blanchfield: Ho sento, endavant.

Bullett Manale: Vaig a dir que veig una tendència suposo que hauria de dir-ho - ja ho sabeu, moltes vegades en el passat, voldríeu dir: "Teníem un problema, i ara necessitem una eina. " I crec que estem veient una mica més d’acceptació per tenir l’eina a lloc abans que passi el problema, si això té sentit. Així que diria que definitivament és més normal que sigui, ja ho sabeu, "Hola, necessitem una eina de control, necessitem alguna cosa". I la gent està veient definitivament el valor d'aquest producte, perquè com vau dir anteriorment, només afegiu DBA i Afegint noves instàncies, necessiteu alguna cosa que pugui gestionar-ho. Necessiteu quelcom que ajudi a la seva gestió i, per això, també estem acceptant molta acceptació al voltant d’aquest producte, o bé ho tenim.

Dez Blanchfield: Pregunta ràpida. On necessita viure això? Ha de seure just a la part posterior de la graella de la LAN, dins del centre de dades, el més a prop possible dels entorns de la base de dades, o és còmode situat en algun lloc, potencialment al núvol, en un núvol de tercers amb algun tipus de túnel VPN o accés remot a diversos entorns? On cal situar-se, pel que fa als entorns i al monitoratge?

Bullett Manale: En termes d’arquitectura, hi ha un dipòsit de fons i és una base de dades de SQL Server. Tenim la consola que pot ser un client gros o un client prim; us oferim l’opció d’ambdós. I també tenim un client prim que està dirigit específicament a dispositius mòbils. Però pel que fa a on pot situar-se això; pot situar-se en un entorn, realment el més complicat és que, des de molta informació que necessitem recopilar, es necessiten drets administratius, en alguns casos o en molts casos. Ara no us fem fer això; si voleu, podeu recopilar dades i només per a les coses que no podem recopilar, perquè no tenim drets d’administració, us deixarem que no veieu aquesta informació, si és l’elecció que feu.

Depenent del sabor, com si es tractés d'AWS, d'alguns entorns, funciona millor que d'altres, però pel que fa al propi entorn, normalment cal fer servir l'autenticació SA per recopilar les dades contra les instàncies. O si es tracta d’un domini sense confiança, normalment és quan voldríeu fer-ho, sinó diversos dominis; sempre que hi hagi confiança entre ells, podrem recollir-los. Realment no importa si es troba en una xarxa LAN o es troba a la xarxa WAN, la col·lecció real en si és força insignificant quant a la quantitat de dades que estem recopilant. Si tenim connexió WAN de mida suficient, no és cap problema. He vist entorns on tenen sucursals on tenen servidors SQL arreu dels Estats Units. I és que hi ha un servidor a cadascuna de les ubicacions diferents i el controlen de manera central. La part complicada és només assegurar-se que teniu una quantitat decent de connectivitat per fer-ho. Tant de bo, això respongui a la vostra pregunta, ha estat una mica ampla a tot el mapa.

Dez Blanchfield: Ho fa, absolutament. Gràcies. Així doncs, dues preguntes ràpides que han arribat als assistents aquest matí; un és: quin és l’impacte de: sovint veiem que les eines de control del sistema es generen carregades amb només controlar les coses, així que la pregunta era, ho sentim, ja que es va desplaçar de la pantalla ara, però simplement parafrasejar-la; mitjançant el control, ens estem generant càrrega? Hi ha un impacte mesurable de l’eina, només observar l’entorn, o és un impacte insignificant?

Bullett Manale: Sempre hi haurà una mica d’impacte perquè ha de consultar la instància del SQL Server per retirar les dades. La pregunta que vau dir és: "És insignificant o és important?" En cas que apunteu a una instància, és insignificant. Ja fa temps que ho feim, com deia. Tenim més de 20.000 clients i puc assegurar-vos que, si provoca un impacte significatiu en el rendiment, no estaríem en negoci. Dit això, també permetem a l’usuari decidir què vol monitoritzar. Així que crec que és important esmentar que cada entorn és una mica diferent.

Un exemple seria, amb el component de control de consultes, una de les coses que podem fer, és que podem establir el llindar del que considereu que és el vostre límit de la normalitat. De manera que es podria basar en el temps de l’execució de la consulta. Es podria basar en la CPU, E / S, però com a exemple, diguem que he definit el meu temps d’execució a zero mil·lisegons. Efectivament, el que estic dient a l’eina a fer és recollir totes les consultes publicades des de l’últim interval de tracció i fer aquesta part del meu recull històric.

Ara, quan fem això, recollirem la quantitat de consultes que hem estat publicant al quadre des de l’última votació. Ara és optatiu, i l'usuari té la possibilitat de fer-ho. Diem: "Això és el que hauríeu de fer"? No. Però també us oferim l'opció de fer-ho en cas que vulgueu una mostra de dades que us permeti recopilar aquesta informació. De manera general, teniu els mitjans dins del eina per configurar-la i ajustar-la exactament com vulgueu en funció del que us resulti còmode, però podeu tenir la possibilitat d'obrir-la realment si voleu i recopilar molta informació addicional que necessàriament no necessàriament amb regularitat. recollir, si té sentit.

Dez Blanchfield: Sí, absolutament. Sé que anem fent una mica de temps, però hi ha dues preguntes realment fantàstiques que vull llançar abans que m’acabi. Els dos vénen directament a mi, però crec que és millor si els responguis. La pregunta generalment era: "Quin és l'abast de l'abast de l'eina fins al coneixement dels sistemes existents?", Doncs podem simplement connectar-ho, i detectar automàticament la plataforma que hi ha i saber què és normal per a aquesta plataforma i immediatament. recollir-ho quan Mark parlava anteriorment? Alguns dels coneixements bàsics de les plataformes, ja que, no ho sé, podria ser Microsoft Dynamics. Què és l’abast del coneixement de la plataforma amb el que és normal i en algunes de les eines fora de la plataforma que s’utilitzen al voltant de les empreses?

Bullett Manale: Jo diria que, en termes generals, quan comencem a recopilar dades sobre la instància SQL, treballem amb les bones pràctiques per començar, quant als nostres llindars i on s’estableixen. Dit això, també reconeixem que amb qui parleu, en termes de bones pràctiques, cada entorn és diferent. El que farem inicialment només recollim les dades, i el que recomanem que faci la gent, podeu provar el producte durant 14 dies més si ho necessiteu. Però al cap d’uns dos dies, començareu a veure que les dades de la línia de referència estan emplaçades. Una vegada que tingui prou informació d’exemple per treballar, llavors us començarà a proporcionar el context en termes de la línia de base, on es troba l’interval i tot aquest tipus de coses. A partir d’aquí, si voleu, podeu configurar automàticament els seus llindars a partir de la informació que s’ha recollit. Es necessita una mica de recollida i sondeig inicial per poder començar a determinar el que és normal, de manera que podeu començar a canviar els llindars.

Però el que crec que val la pena destacar també és que, quan canvieu aquests llindars, es pot fer grup per grup de les vostres instàncies. Pot ser específic per a una instància o pot fer-ho contra totes les instàncies, així com la capacitat de crear coses com les plantilles, de manera que podeu dir: "Aquesta és una instància de producció, però aquesta és la plantilla que vull. assignar-lo. " Per tant, quan una nova instància de producció arriba en línia, se li apliquen automàticament aquests llindars, ja que té el mateix tipus de maquinari, i normalment té les mateixes càrregues de treball, de manera que també podríem fer-ho. Esperem que això ajudi en termes de la pregunta.

Dez Blanchfield: Ho fa, absolutament. De fet, en realitat heu respost a una altra pregunta que em venia de fer i que era: "Hi ha una prova de descàrrega?" Hi ha, ho puc respondre, ja ho sé. Estic segur que confirmareu que hi ha una descàrrega gratuïta i crec que heu dit que feia 14 dies del lloc web. Podeu descarregar-lo i jugar amb ell. Suposo que amb prou feines, "Quin tipus d'entorn necessito per poder fer la prova? Puc executar-lo al portàtil i jugar amb ell o necessito realment un servidor?"

Bullett Manale: El principal que necessita és un dipòsit, una base de dades de SQL Server que és de 2005 o superior. A part d’això, hi ha uns requisits mínims de recursos, un requisit .NET, i ja ho és. Per tant, només es tracta d’instal·lar el producte i crear una base de dades.

Dez Blanchfield: Perfecte. Una darrera pregunta que us llançaré, perquè acabem de temps, però ràpidament, unes dues o tres persones em van preguntar: "He de ser un DBA per poder ser capaç de posar-me en marxa amb això, i jugar amb ell? ”

Bullett Manale: No. Diria que, si ets un DBA, tindràs diferents usos de l'eina. Vull dir, probablement hi haurà una mica més de valor si sou un DBA experimentat. Veureu molt més a fons l’eina que podríeu aprofitar. Però també com a nou DBA, o fins i tot una persona que, això no és un DBA, tenim moltes recomanacions i ara estic a la pàgina. Aquestes recomanacions es presentaran regularment, i el més bonic de les recomanacions, és que us proporcionen les raons per les quals es fan les recomanacions. Però, a més d'això, també tindran enllaços a continguts externs que descriuen amb més detall els motius pels quals també es fan aquestes recomanacions. De manera que enllaçarà amb llocs web externs de Microsoft, blocs i tot tipus de coses, això és extern.

Però, per respondre a la vostra pregunta, és com, ja sabeu, si sou un DBA sènior, aquí hi haurà coses que probablement aprofiteu, que probablement no seríeu com a principiants del DBA. Però, alhora, també és una mena d’eina d’aprenentatge, ja que a mesura que aprofiteu aquestes recomanacions, començareu a recollir algunes d’aquestes coses pel vostre compte mitjançant l’ús de les recomanacions.

Dez Blanchfield: Fantàstic. Gràcies. Em va agradar molt la part de demostració. La presentació va ser genial. La demostració va ser fantàstica. Ràpidament des de la memòria, hi ha un centre de recursos complet al vostre lloc web que recomano que les persones també ho facin. Recordo haver passat aquesta nit passada per obtenir alguns detalls. Teniu tot un ventall de coses, només des dels vostres blocs i dades i converses fins a la memòria, també teniu la major part de la documentació del vostre producte en línia, sí?

Bullett Manale: Sí, és correcte i el formulari que crec que feu referència és el lloc web community.idera.com. I una cosa que esmentaria també, abans, haureu preguntat sobre: ​​"Reconeixerà el medi ambient?" Pel que fa a noves instàncies o afegir instàncies, hi ha una altra eina que ofereix el descobriment d’instàncies. I tot es tracta d'inventar i gestionar el vostre inventari. M'agradaria apuntar-vos en aquesta direcció pel que fa a descobrir casos. Però, pel que fa al rendiment i al monitoratge, de tot el que hem parlat, és aquí on entraria en joc el Gestor de diagnòstic.

Dez Blanchfield: Fantàstic. Mira, gran cobertura. Va agradar molt la vostra presentació. M’ha encantat la demostració en directe i tot això m’ha sortit d’aquest matí, ja que sé que probablement hem passat 10 minuts amb el pas del temps. Eric, et passaré de nou.

Eric Kavanagh: Bé. Em va encantar la demostració. Estic content que hagis fet la demostració. Estic contenta que haguem de fer una bona i dur aspecte al passar per la pregunta i la pregunta.

Bullett Manale: Genial.

Eric Kavanagh: Perquè això dóna a la gent una idea del que estàs veient, i realment em sorprèn pensar que encara estem aprenent sobre com parlar amb aquests ordinadors quan arribes bé. Vull dir, aquest nivell de diagnòstic és força sofisticat, i cada dia millora. Estem aprofitant molt més el que està passant. Però realment necessiteu una persona que passa per alt aquestes coses, que la llegeixi, posant aquesta capacitat cognitiva darrere del que feu, oi?

Bullett Manale: Sí, vull dir en molts casos, voldria que us pogués dir que es tracta d’un DBA a la caixa, però hi ha massa coses que passen. Vull dir, donem orientació i ajudem, però, al final, cal que la gent prengui decisions sobre les dades que presentem. No crec que aviat canviï en cap moment.

Eric Kavanagh: Bé, aquestes són les bones notícies per a la gent real que hi ha, persones.

Bullett Manale: És així.

Eric Kavanagh: Voleu que algú miri això, un equip que ho vegi, i aprendreu, com heu sentit a parlar de Bullett aquí, mirant aquestes recomanacions que recollireu el que passa. I suposo que d’aquella història i crec que heu tocat això, Bullett, però molt ràpidament, que la història us permet reconèixer patrons significatius i, per tant, poder identificar-los quan es produeixin en el futur, oi?

Bullett Manale: És correcte. Una de les coses que podem fer és fer un seguiment del rendiment de la consulta al llarg del temps. També, òbviament, podem mirar altres coses, com les línies de referència i veure com canvien, i, òbviament, rebre alertes i coses així quan això succeeix, així que definitivament tindreu aquesta capacitat.

Eric Kavanagh: Sona bé, la gent. No hi hauríem estat gaire temps, però volia posar-me en qüestió. Moltes gràcies pel vostre temps i atenció. Arxivem tots aquests transmissions web. Salteu en línia a Techopedia.com o a InsideAnalysis.com, podreu veure enllaços de tots dos llocs.

I amb això, us acomiadem. Gràcies de nou, amics, us posarem al dia de la setmana que ve, tres transmissions web més la setmana que ve, dimarts, dimecres, dijous. Així que us en parlarem la setmana que ve. Cuida't. Adeu.

Soci de contingut de Techopedia

El personal de Techopedia està afiliat a Bloor Group i es pot contactar amb les opcions de la dreta. Per obtenir més informació sobre com treballem amb els socis de la indústria, feu clic aquí.

• Perfil
• Lloc web