Insanitat de l’índex: com evitar el caos de bases de dades

Per personal de Techopedia, 5 d'octubre de 2016

Take away: L' amfitrió Eric Kavanagh discuteix la indexació de bases de dades amb el doctor Robin Bloor, Dez Blanchfield i IDERA, Bert Scalzo.

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. És un dimecres a les quatre de la nit de l'est i els que coneixeu el programa, sabeu què vol dir, és el moment d'un altre episodi de Hot Technologies. Sí, efectivament. Em dic Eric Kavanagh, seré el seu moderador per a la sessió d’avui: "Índex Insanitat: Com evitar el caos de bases de dades". O com el vaig referir a la darrera explosió de correu electrònic que va sortir, "basar-se en la base de dades". Terme calent en aquests dies, "lluitar". Tothom ho fa. Hi ha una diapositiva sobre el vostre de veritat. I prou amb mi.

Així doncs, la sèrie Hot Technology va ser realment dissenyada per definir un espai en concret, a diferència del Briefing Room, que és només una presentació individualitzada d’analistes en directe, per a Hot Tech obtenim dos analistes. Avui serà el nostre propi doctor Robin Bloor i el nostre científic científic de dades, Dez Blanchfield. I estem parlant d’un tema que crec que és força emblemàtic del que passa actualment al mercat.

La conclusió és que avui dia estem en un món de complexitat. Realment, si penses en quinze anys o vint anys, aleshores era un món molt diferent, sobretot pel que fa a la tecnologia de bases de dades. Les bases de dades solen ser bastant senzilles. N’hi havia només un grapat; la majoria eren relacionals. Ara, tenim tota aquesta panoplia de les tecnologies de bases de dades. Hi ha literalment nombroses opcions a la taula per a qualsevol persona que vulgui crear una aplicació o fer alguna cosa amb dades. Tot està canviant i això afecta les persones que intenten gestionar aquests sistemes. Avui parlarem amb Bert Scalzo, que és un autèntic expert en la matèria; és l’administrador de productes més gran d’IDERA, sobre què podeu fer per obtenir un control de totes aquestes dades. Amb això, ho lliuraré al doctor Robin Bloor per treure'l. Robin, el pis és teu.

Robin Bloor: D'acord, gràcies per la introducció. Ho crec, perquè és una cosa a dues mans, penso que només parlaria sobre l’optimització de bases de dades en general com a introducció a aquest programa de tecnologia calenta. Vaig començar la vida -en tecnologia i anàlisi-, vaig començar la vida fent això perquè escrivia articles sobre les capacitats de les bases de dades a la plataforma DEC VAX. I per això, els gastadors de bases de dades solien informar-me. I el que em passa a mi és que, per què tindries una base de dades? Vull dir que, en aquells dies, molta gent solia crear fitxers de valor clau i utilitzar-los per tenir una mena de fal·làcia seqüencial d’índex com els anomenem, però per crear una mena de capacitat de base de dades, i ja sabeu, per què tindríeu? Alguna cosa més?

I la resposta a això, crec que Michael Stonebraker va donar la millor resposta a això, i va dir: "Una base de dades pot saber més sobre on són les dades i la rapidesa per obtenir-la, del que qualsevol programa pot saber mai". I crec que això és interessant; és la naturalesa del joc. Però al 19, aproximadament, sobre el 1989 que vaig començar a l'anàlisi tecnològica i ja sabeu, en aquell moment, les bases de dades eren molt senzilles i les bases de dades relacionals eren molt senzilles. Tenien poca capacitat, vull dir, podrien emmagatzemar dades, òbviament, i podríeu fer una còpia de seguretat i tenien, eren compatibles amb l’ACID, però realment tenien optimitzadors molt febles. De fet, seria difícil discutir que tinguessin la capacitat d’optimitzador.

I més tard només van anar millorant, però, ja sabeu, quan una base de dades no funciona (ja que aquests cangurs semblen indicar-se d’una manera o d’una altra), hi pot haver moltes raons per les quals va lent. I això em porta al punt: les bases de dades tenen moltes funcions, però la més important és l’optimització de consultes. Si no ho fessin, no els faríeu servir. Es tracta d’aconseguir informació ràpidament, es tracta de poder-ho fer quan hi ha molts usuaris concurrents i això és un problema difícil. I, quan realment ens fixem en, anomenem bases de dades madures, si voleu, però certament Oracle, en una mesura menor, Microsoft SQL Server, certament Teradata i DB2, els optimitzadors d'aquestes bases de dades han estat dècades a la edifici. Ja sabeu, no hi va haver algú: sis nois en un projecte de dos homes i un any i només van juntar un. No funciona així. La capacitat d’optimització ha crescut gradualment, i necessita molt créixer. De totes maneres, parlem sobre els antecedents de la base de dades. Bé, ara es diu molt sobre la base de dades de NoSQL i fins i tot hi ha molta il·lusió per la base de dades de gràfics. I l’ús d’SQL sobre Hadoop i coses així. Però, la veritat és que si voleu una base de dades en aquest moment, si voleu una funcionalitat totalment funcional, capaç d’OLTP i de gran tràfic de consultes, és una base de dades relacional o no és res.

Entre les bases de dades relacionals, Oracle és dominant en popularitat. Crec que el Microsoft SQL Server és el segon. Ambdós poden ser utilitzats per a la càrrega de treball OLTP i per a consultes, però realment no es pot deixar de barrejar aquestes càrregues de treball. Necessiteu incidents diferents per a càrregues de treball OLTP i càrregues de treball de consulta. Hi ha alternatives a SQL i a gràfics. La majoria de les empreses s’estandarditzen en una base de dades específica, i és per això que vull dir que, després de dècades lluitant contra la resta de jugadors, Oracle es va convertir en la més dominant. Simplement perquè van acabar venent llicències corporatives i, per tant, les empreses només utilitzaran productes alternatius en productes excepcionals, Oracle simplement no els faria. I les bases de dades són estratègiques perquè també evolucionen. I sabeu que vaig fer una mica d’investigació per a aquesta presentació, i és una mena de: hi acudiré d’aquí a un temps, però és interessant com evolucionen, quant a mirar-ho des de la posició d’un DBA. Això és el que jo anomeno tendència invisible. És la llei de Moore cubada. És més o menys així: la base de dades més gran és que, i les bases de dades noves, no hi ha una base de dades antiga que tingui moltes més dades per ingerir. Normalment, una base de dades s’està aplicant a un nou problema. I realment creixen en termes de volums de dades. Aproximadament al cub de Moore Llei. De manera que la llei de Moore és un factor de deu vegades cada sis anys. Els VLDB solen créixer un factor de mil cada sis anys. El 1991, 1992, les grans bases de dades es mesuren en termes de megabytes. El '97 i el '98, gigabytes. 2003, '4, terabytes. El 2009, el 10, vau començar a veure bases de dades de petabytes. Crec que hi havia possiblement una o dues bases de dades exabytes ara mateix, però el més gran que he sentit a parlar són els 200 petabytes a temps, i ja ho sabeu, no rebre dades a una base de dades de petabytes. Però, òbviament, serà, òbviament, les noves grans empreses de web 2.0, possiblement, ja teniu el Facebook cap a aquesta direcció.

Però de totes maneres, si realment ho observeu, si espereu que una base de dades passi per aquest tipus d’escalada de volum, demana molt. I és notablement que, certament, fins al nivell dels petabytes, semblen haver-ho anat bé. Vull dir, estic parlant dels productes més antics en lloc de qualsevol cosa nova. Sembla que s’ho han passat extraordinàriament bé. Si ens fixem en el rendiment de la base de dades, els colls d’ampolla, això em fa tornar al temps que realment tenia importància per tenir-los cura i havia de preocupar-me per ells. Ja sabeu que això és fonamentalment el desglossament del maquinari. Hi ha colls d’ampolla de la CPU, possiblement, hi ha colls d’ampolla de memòria, possiblement, hi ha colls d’ampolla de disc, possiblement. Pot ser la xarxa que us faci mal, i també podeu tenir problemes amb el bloqueig, depenent del que feu, però normalment és perquè el programa no sap a qui trucar al bloqueig. Per tant, si voleu ajustar una base de dades, esteu intentant ajustar-la perquè balli entre aquests cinc colls d'ampolla possibles. I això no és fàcil, perquè la quantitat de memòria que podríeu configurar en un servidor determinat augmenta notablement. Aleshores les CPU s’han convertit en multicor, en disc, bé, ara ho podem fer, crec, fins i tot en servidors de mercaderies, crec que podeu fer centenars i centenars de terabytes, un quart de petabyte, potser, fins i tot en un servidor de mercaderies. De manera que, amb totes aquestes coses, es pot jugar amb la xarxa, per descomptat, pot anar a diferents velocitats, però principalment quan es tracta de bases de dades, realment voleu tenir cables de fibra entre els servidors i res més que això funcioni. d'aquesta manera.

Factors de rendiment de la base de dades. Vull dir, deixo fora de què es tractarà tot això, ja que sé que Dez parlarà sobre això, però un mal disseny de bases de dades significa una base de dades amb un bon funcionament. Un mal disseny de programació pot significar llançar un SQL molt estúpid a una base de dades, cosa que trigarà molt més. La barreja de concurrència i càrrega de treball, massa concurrència provocarà problemes d'ampolla. La barreja de càrrega de treball, quan teniu consultes grans amb consultes molt petites, curtes i nítides, això causa problemes. Hi ha un problema de l'equilibri de càrregues. La majoria de bases de dades s’ocupen d’això, però si no teniu un producte sofisticat, ja ho sabeu, només afegir alguns servidors, no és tot el que feu si realment voleu augmentar la mida d’un clúster. En realitat, haureu d'equilibrar la càrrega abans d'obtenir el rendiment òptim. Cal que planifiqueu la capacitat. Absolutament. Sobretot ara en aquests dies, quan els volums de dades augmenten de forma més espectacular del que abans solien per a les bases de dades. I hi ha problemes sencers de la capa de dades sobre com ingeriu les dades, com us moveu les dades. No obtenir dades a una base de dades a temps pot ser un problema de rendiment més endavant perquè hem passat de bases de dades que funcionen a Windows, a vint-i-quatre per set per tres-cents setanta-cinc operacions i no hi ha finestres on es pugui retardar la base de dades a la baixa o és poc probable que hi hagi avui dia.

El problema DBA d’Oracle. Això ho pensava. He estat al DBA d’Oracle amb l’Oracle 7, i recordo com afinar-ho. I si realment mires Oracle ara, és de forma, és molt, és molt, molt més capacitat. Té indexació de mapes de bits i coses així, però en realitat vaig prendre el temps per mirar i veure quants paràmetres d’afinació hi ha en la base de dades d’Oracle actualment. I hi ha més de tres-cents cinquanta paràmetres d’afinació i hi ha un centenar més de paràmetres ocults, que els DBA especialistes poden conèixer, però els DBA Oracle normals no en saben. I això vol dir que l’actualització d’aquest tipus de bases de dades és una cosa difícil. No és una cosa senzilla. Haureu de tenir sensació, heu de fer-ho durant molt de temps i heu de saber exactament quin és el problema que creieu que solucioneu, perquè la sintonia comença quan el el rendiment és dolent, però pot ser que no sigui el rendiment de tot. És possible que sigui el rendiment de consultes específiques que tinguin importància, i és possible que pugueu arreglar-ho mitjançant la fixació de determinades dades i memòria, o potser haureu d’arreglar-lo indexant-lo, o bé, haureu de començar a fer particions d’una altra manera. Hi ha moltes coses que pots fer. Així, per tant, no ho faran al cap: els DBA necessiten eines. Crec que ara passaré a Dez que us explicarà la indexació.

Eric Kavanagh: Bé, Dez, treu-ho.

Dez Blanchfield: Gràcies, Robin, i m'encanta la portada. Crec que heu llençat el protector allà mateix perquè pogués apropar-me de forma remota a una cosa tan emocionant. Però he utilitzat una imatge de la nostra petita galàxia, segons la visió del que ha estat el repte actual per als administradors de bases de dades, perquè aquesta és la imatge mental que tendeixo a conjurar quan entro en un entorn i ja no ho sóc al món de l'administració de bases de dades o el disseny de bases de dades a aquest nivell. Però, com vosaltres mateixos, Robin i jo hem tingut molts anys implicats en el món de les bases de dades, com a administrador o desenvolupador, o eventualment arquitectes, i llavors ens vam adonar que podia fer coses millors per obtenir una crosta. Però acostuma a tenir la sensació que esteu mirant aquesta galàxia de dades, i més encara avui, quan passem, tal com heu destacat, hem passat de megabytes a petabytes i exoescala en un període de temps molt curt., en el gran esquema de les coses. Però la frase que tinc al cap és que els índexs de bases de dades són ara un art negre i no són realment els tipus que els simples mortals haurien de treballar per a aplicacions empresarials de tipus empresarial i el tipus de formulació que us ofereix. només estaven parlant. Tanmateix, volia aprofundir ràpidament sobre el tipus d’història que he tingut amb els mons de bases de dades i portar-los al context on traurem una conclusió i, a continuació, recórrer algun material avui amb els nostres amics. IDERA, perquè crec que hi ha moltes coses diferents sobre com es pot ajustar el rendiment de les bases de dades i un d’ells és llançar aquest tema. A moltes botigues que em trobo, sempre no arriben al punt de fer l’afinació del rendiment a la capa de la base de dades i, en particular, a la capa d’índex fins que no han passat per la difícil ruta de pensar que poden tirar-hi un sintonitzador. .

Molta gent només fa un gran enfocament al meu parer, i jo tinc una foto de The Flash aquí perquè si alguna vegada heu vist pel·lícules antigues o, certament, els últims programes de TV amb The Flash, com en Flash Gordon, el vell personatge, i ara que es diu “The Flash”, acostuma a anar molt, molt ràpidament i la seva energia s’esgota sempre. I això és el que succeeix quan es llança ferro a la prestació de la base de dades. Invariablement, segons la meva experiència, podeu incorporar al joc un gran rendiment, un treball dur, podeu optimitzar els vostres sistemes operatius i ajustar-los a un cert punt. Podeu assegurar-vos que disposeu de CPU ràpides multicorre i multitreading per fer que l'aplicació funcioni més ràpidament, podeu llançar molta memòria RAM, podeu tenir plànols posteriors de gran rendiment, podeu anar des de discs durs a caché de discs durs a estat sòlid. i matriu d’emmagatzematge d’alt rendiment. I fins i tot ara, la gent llança coses com flash i NVMe als seus motors de base de dades, pensant que obtindran aquest rendiment de temps d’inici de sessió dos temps de rendiment. I, sempre, aconsegueixen algun guany. Però, tot es torna als mateixos problemes bàsics d’afinació del rendiment. Hi ha connexions de xarxa de baixa latència, de manera que els clústers funcionin ràpidament. I d’agrupar infraestructures de bases de dades, de manera que teniu més d’una sola màquina que fa tot el treball. Però acostuma a tornar al mateix problema bàsic de rendiment, i és llegir dades. L’escriptura de dades és, en la seva majoria, un repte bastant lineal i tret que es faci correctament.

I després tenim el repte del món actual: no totes les bases de dades es creen iguals. Hi ha bases de dades i "base de dades" de cotització a cotització. I quan pensem en motors de bases de dades, la gent sovint pensa en els sospitosos tradicionals com eren al món SQL. Ja sabeu, tenim Oracle i Microsoft SQL Server, i hi ha un parell al món de codi obert amb MySQL, que ara és propietat d'Oracle, però encara és de codi obert. I després tenim els sospitosos no tan habituals, els motors NoSQL, que encara tenen un problema al voltant de la indexació i la gestió del rendiment, i no els entraré en molts detalls, però cada vegada hi ha més. les coses apareixen cada dia i semblen motors de bases de dades des del punt de vista dels desenvolupadors i des del punt de vista del rendiment, però són bèsties molt, molt diferents i tenen un nínxol propi al món per talar-les. rendiment a la memòria o escala lineal al disc. Però això és el que sembla el món al món de la base de dades. Aquesta és la versió 2016 del 2016, aquesta és la versió tres del mapa, de diverses persones que produeixen aquest mapa de paisatge en curs del que semblen les bases de dades, i aquí és on, ni tan sols un arquitecte sobre bases de dades o un administrador de bases de dades poden tenir sentit. d’ella. Literalment, centenars i centenars de models diferents, fabricants de bases de dades, sempre compatibles amb SQL. I l’interessant és que tots tornen al mateix repte. Sintonització del rendiment i el rendiment al voltant del motor de bases de dades, i en particular per la indexació de les dades.

Així que només abastem ràpidament la indexació de bases de dades, perquè és un tema interessant i heu d’introduir-lo amb més detall amb la demostració, crec. Però crec que és una pràctica indústria estàndard força ben acceptada que la sintonia del rendiment de l'índex de bases de dades és allà on el món comença i acaba fins que garanteix que les vostres dades siguin accessibles amb un format ràpid i ràpid. Però, què és la indexació de bases de dades? Si pensem en la indexació de la forma que estem acostumats a ésser humans quotidians, pensem en una pàgina d’índex d’un llibre. Si voleu trobar alguna cosa en un llibre, en especial els gustos d’una enciclopèdia, o alguna cosa com un material de referència d’alguna forma, si busqueu alguna cosa com aquesta pàgina, estic buscant coses com el tema de les preses. en una enciclopèdia Vull trobar totes les referències a les preses, a la captació d’aigua i a una gran zona d’acumulació, creada generalment per l’home. Aniré al darrere, el trobaré en una llista ordenada alfabetitzada, A a Z, d’esquerra a dreta, i trobaré D. Trobaré la paraula “preses” i puc veure que pàgines 16, 38, 41 hi ha una referència a ells, i després puc anar a aquestes pàgines, puc buscar els meus ulls i trobar la referència a la paraula "dam". Es tracta, bàsicament, del mateix concepte en una base de dades, però ara és una ciència de coets de moltes maneres. Tant és així, que efectivament tots els administradors de bases de dades que he conegut alguna vegada, consideren que els índexs són l’única eina més crítica per ajustar el rendiment en qualsevol món de bases de dades, independentment de quina sigui la seva experiència fins al punt de llançar-los. sigui quin sigui el cas.

Generalment, quan parlem d’indexació de bases de dades, hi ha diversos enfocaments habituals. I com més complexos són els índexs de bases de dades, més complex serà l'enfocament de la indexació de dades. Però, fonamentalment, quan penseu en la indexació de dades, imagineu-vos que tenim un fitxer amb una llista de noms; no es poden ordenar per ordre alfabètic. Imaginem que n’hi ha vint. Si anem a ordenar, si anem a cercar les dades d'aquesta llista, de dalt a baix, diguem que és una llista de noms. Si trio un nom aleatori i començo a desplaçar-me per la llista, de dalt a baix, en un format lineal i és una llista no ordenada, hi ha dos criteris que pensen com el temps mitjà de cerca i el temps màxim de cerca. Tinc una tipografia a la segona línia, hauria de ser el "temps màxim de cerca", ho sento, però el meu temps mitjà de cerca és bàsicament N més un, dividit per dos, i això és, de mitjana, el cinquanta per cent del temps. escanejar des de la part superior de la llista fins al final de la llista per trobar qualsevol cosa aleatòria en aquesta llista. I la segona línia, sota lineal, hauria de ser el “temps màxim de cerca”. Però el temps màxim de cerca és essencialment el nombre d’elements, i és que si tinc una llista de vint coses, el màxim temps que em puc portar cercar alguna cosa en aquesta base de dades és anar de dalt a baix, és a dir, diguem 20 ítems en aquest exemple simplificat. I és un procés molt lent i realment no hi ha manera d’afinar el rendiment. I, a continuació, hi ha un altre tipus de maneres d’agafar aquestes dades i de crear un índex, que és efectivament una llista curta d’indicadors fins on es troben les dades reals, com ara binari, arbre B, mapa de bits, hashing, cluster i no agrupats, i després hi ha diferents tipus de dades com ara el text espacial, el filtrat, l'XML i el text complet.

El binari és un ús molt comú per a les coses en què les dades es presten. L’arbre B és probablement l’únic més comú en un sentit general, històricament, ja que és una manera comuna d’estructurar un índex a qualsevol forma de dades i permet que els registradors, seleccions i les insercions i esborracions siguin relativament fàcils a mesura que es mouen els indicadors al voltant. referència als indicadors, els punts. Hi ha altres tipus, com el mapa de bits, en què els tipus de dades es preocupen com si tinguem una gamma associada d'alguna forma. El hashing funciona molt bé per a objectes grans, sobretot blocs i imatges. I podeu veure que hi ha diversos tipus d’enfocaments científics, enfocaments matemàtics per indexar dades. Per als simples mortals, és un repte interessant parlar-ne a aquest nivell. Quan parleu a un nivell de rendiment per a un administrador de bases de dades, realment es converteixen en científics de coets i la gent fa estudis en ells, i sé que el doctor Robin Bloor, certament, ho ha fet i hi ha escrit llibres sobre els gustos d'IBM i altres grans marques dels darrers dos decennis. I, segons el meu parer, és que realment hem passat un temps en què, ja sabeu, de vegades, jo seria capaç de seure davant d’un sistema i seria capaç de separar-lo i mostrar-vos exactament on es trobaven els problemes de rendiment en una línia d’ordres o en una eina d’inici de la interfície d’usuari gràfica i comenceu a aprofundir en les dades i us indicaran on eren els problemes, i creeu índexs o subíndexs o índexs primaris i secundaris en això. dades i comença a utilitzar-lo per trobar coses. Però quan penses en aquell paisatge que et vaig mostrar, on tenim centenars i centenars de marques, marques i models, i fabricants i tipus de bases de dades, ara estem bé i realment passats aquell temps, on un ésser humà pot fer sentit dels tipus de motors de bases de dades que tenim. En particular, encara que només tornem al gust d'Oracle, avui dia hi ha marques predominants en plataformes relacionals de bases de dades.

El nombre de bases de dades amb què han de fer front ja sigui des d’una plataforma propietària com un sistema ERP o RRHH o un sistema de finançament, o bé si són una plataforma de cuina casolana per diverses raons, el nombre de bases de dades i taules i registres de bases de dades que acabem tractar són només astronòmics i físicament no ho pots fer a mà. I hem tingut una complicació addicional ara, quan una vegada, un servidor de bases de dades podria estar només a l'escriptori. Ja sabeu que, de jove després de l'escola, solia anar a treballar amb programari de bases de dades als sistemes originals d'Apple II i després de sistemes basats en PC DOS, com dBase II, dBase III, van passar una època amb fotogrames principals i mitjans. fins i tot VAXs i PDP i fitxer de registre en això. I com Saber, i després quan van aparèixer algunes de les bases de dades SQL. Però en aquests dies, quan estem pensant en motors de bases de dades, semblen l'extrem inferior esquerre. Un servidor de bases de dades ja no és una sola màquina asseguda al terra sota un escriptori; es tracta de centenars de màquines que utilitzen còpies de motors de base de dades i clústers, i fan escala fins a centenars i centenars de terabytes de dades, si no petabytes de dades, que són milers de terabytes. I fins i tot fins a l’extrem, com va mencionar el doctor Robin Bloor, que alguns casos d’ús específics (companyies aèries, sobretot agències governamentals) poden arribar a exabytes. Segueixen sent bastant nínxols, però ja no és estrany centenars de terabytes i fins i tot desenes de petabytes, sobretot des del boom del puntcom fins ara, com és el que anomenem empreses web 2.0, com Facebook, Google, Yahoo i així successivament.

També tenim la complicació ara que les coses es traslladen al servei extern. Tenim una plataforma i programari d’infraestructura com a enfocament de serveis que proporcionen infraestructures. I, en particular, el servei de plataformes on no podem comprar només els objectius d'Oracle i la seva plataforma en núvol, bases de dades i servidors. D'aquesta manera, ens permet fer un desenvolupament d'aplicacions molt ràpid i simplement connectar una base de dades als servidors. No hem de pensar en què hi ha sota el capó. L’inconvenient és que sovint no pensem en com dissenyem i implementem la base de dades fins que no comenci a fer-nos mal i el rendiment es converteixi en un problema, i després acabem havent de buscar l’eina adequada per diagnosticar el perjudici de la nostra base de dades i on es troben els problemes de rendiment. De manera invariable, es torna a trobar aquest problema comú de com hem indexat aquestes dades i els tipus d'índexos que hem utilitzat per a aquestes dades, i que ens torna a obtenir els requisits de rendiment sobrehumà. I algú que tingui accés als sistemes adequats i a les eines adequades per ajustar els motors, comenci a buscar un punt calent i mira cap a on són les consultes, on es mouen les dades, els tipus de consultes, com s’estructuren les consultes, qui fa les consultes i si les consultes estan fent cua i cal haver-lo en memòria cau. Quina replicació busqueu?

Així doncs, estem bé i de debò, segons el meu parer, en un moment en què fins i tot els millors gurús de bases de dades del món, essencialment els nostres arquitectes de bases de dades, els nostres administradors de bases de dades i bases de rendiment, segons el meu parer, necessiten molt aprofitar les eines adequades. per proporcionar una optimització d'índex de rendiment òptim per a qualsevol motor de base de dades. Com que l’escala amb la qual tractem i la velocitat amb què es mouen les coses, simplement no ho podem fer a mà i intentar fer-ho de forma invariable pot introduir altres problemes de rendiment, perquè és possible que no tinguem experiència en aquest espai. estem intentant solucionar un problema. I crec que és aquí on estem a punt de lliurar-li a Bert, i estem a punt de parlar de com han resolt aquest problema tan variat i el tipus de coses que pot tenir la seva eina. fer, especialment pel món d’Oracle. I amb això, Bert, us passaré.

Bert Scalzo: Gràcies. Benvingut a tothom, em dic Bert Scalzo, treballo per a IDERA. Sóc el principal responsable de productes d'alguns dels nostres productes de la base de dades. Ja en demostraré algunes d’aquestes. Però vull parlar d’índexs, perquè estic d’acord amb tot el que tothom ha dit aquí, sobretot la darrera diapositiva, que els índexs són tan complexos ara que necessiteu una eina i espero convèncer-vos. Així, doncs, el disseny de l’índex d’Oracle, no és tan fàcil com ho feia antigament. Molta gent no se sap segura quan estudiï les opcions i m’agrada dir que em vaig treure de la història, “en aquestes qüestions, l’única certesa, és que res és segur”. penseu sobre els índexs en aquests dies, perquè, encara que creieu que sabeu la resposta, hauríeu d’indexar-vos X, Y o Z, realment no podreu estar segurs fins que no ho proveu, perquè de vegades aquests optimitzadors es comporten de manera diferent a la manera que espereu. I hi ha molts processos i errors amb el disseny de l'índex. Ara bé, als bons vells temps, si necessitaves un índex, generalment hi havia només dues preguntes o una pregunta. Era únic o no era únic? I és possible que hagis pensat en altres coses com: "Quants índexs puc tenir com a màxim en una sola taula?", Perquè hi ha massa índexs que alenteixen les teves insercions, actualitzacions i supressions. També podríeu haver estat al vostre sistema de bases de dades, teniu restriccions a la quantitat de columnes que podrien estar en un índex de diverses columnes, perquè de vegades hi havia límits basats en la mida de la pàgina o del bloc del vostre motor de base de dades, però en realitat era força senzill. en els bons vells temps. O ho heu indexat o no ho heu fet. I realment, tot estava en un arbre B. Podríem permetre els duplicats o no, i es tractava. La vida era bona, la vida era senzilla.

Doncs avui, la vida no és tan bona ni tan senzilla. He posat el signe vermell Ghostbuster a través de la forma en què solíem fer-ho, perquè ara tenim arbre B versus mapa de bits, o unió de mapa de bits. I vaig a explicar què són alguns d'aquests moments. Agrupats i no agrupats, únics o duplicats, en ordre endavant o invers, basats en funcions, particionats o no compartits. Si hi ha particions, hi ha un particionat global o local? T’explicaré també. I també hi ha una cosa que s’anomena taula organitzada indexada. I hi ha realment mitja dotzena d’altres que m’han deixat fora, perquè crec que en tinc prou aquí, que hauria de convèncer que els índexs són molt més durs del que podríeu pensar. En aquesta diapositiva en particular, vaig a començar a la part superior esquerra del diagrama i tinc una taula. I el primer que he de decidir és que, segons la versió de la vostra base de dades i el venedor de la base de dades, permetin taules d’objectes o només són relacionals? Vaig a baixar pel costat dret i diré que construïm una taula relacional. Ara, la següent pregunta que m’he de plantejar és: és en un clúster? I molts dels que heu fet Oracle durant algun temps recordareu que els clústers estaven de tornada durant l’Oracle 6 dies. Avui en dia no es fan servir gaire, però deixa’m baixar primer d’aquesta branca.

Si hagués de posar la meva taula en un clúster, hauria de tenir un índex agrupat a la taula. Ara, a Oracle, quan vau agrupar una taula, bàsicament teníeu que emmagatzemar les files o les files eren properes entre elles, on els valors eren similars. Per tant, heu de tenir un índex agrupat i aquest índex en clúster podria no ser particionat. Dit d’una altra manera, no hi havia realment mètodes de particions sobre com faríeu una taula agrupada. Era estrictament no compartit. I com que no estava partit, era global. Us explicaré què és global en un minut. I sempre va ser B-tree. És a dir, quan vaig abandonar la branca, era bastant senzill, no vaig tenir moltes opcions. Ara, si feia un índex no agrupat en una taula agrupada, permesa en algunes versions, de nou, no era particionada; quan no estigui dividit, l’única opció és global. I, per tant, podeu triar el B-tree o el mapa de bits. De nou, depenia de la vostra versió de la base de dades. Però ara, tornem a pujar a la taula relacional i comencem a baixar pel costat dret de nou i ara només tindrem una taula senzilla, antiga i regular, plena: relacional. Serà a un espai de taula. Aquí sóc una mica pel baixador dret. Així doncs, és organització. La següent pregunta que em plantejaré és: "Vull particionar aquesta taula o no?" Ara bé, de vegades us repartireu perquè pensàveu: "Hola, l'optimitzador serà més intel·ligent sobre com pot optimitzar les consultes. ”Però moltes DBA diran que la raó per fer això és amb finalitats administratives. Si teniu una taula de cent mil milions de files, si la podeu dividir en particions o cubetes, quan voleu afegir dades a l'últim cub, podeu treure i indexar només uns milions de files. Podeu inserir aquestes dades i, a continuació, podeu reconstruir l'índex només en la cubeta.

Si bé era una bona tècnica per a alguns, tècniques d’optimització com l’eliminació de particions, el seu valor real era poder administrar o fer tasques administratives en peces més petites. Quan vaig a fer un munt d’organització, la primera pregunta era: “La vaig repartir o no?” Anem a l’esquerra, no vaig a dividir la taula. Ara, pot semblar estrany quan us ho dic, però podríeu tenir una taula no particionada i, després, no podreu particionar l’índex tal com estàveu acostumats o podeu particionar l’índex. Parau-vos i penseu. La taula té bàsicament un cub, com sempre heu pensat, i, tot i així, el vostre índex tindrà diversos cubells. Quan això passa, hi ha un desajust entre el nombre de cubetes i la taula i el nombre de cubetes a l'índex, això és el que significa global. Per tant, si la taula no està dividida i si l'índex està dividit, es considera global, perquè no hi ha un desajust. Ara, permeteu-me fer una còpia de seguretat a la pila d'organitzacions i baixar al costat de la partició. Ara, si tinc una taula de particions i diguem que la taula té quatre cubetes, quatre particions, el meu índex podria tenir quatre cubetes de manera que el meu índex coincideixi amb el meu disseny de taula. I així s'ha acabat, a la banda dreta. Això es consideraria local. Un índex local significa bàsicament que el particionat de la taula i l’índex es fa de la mateixa manera i té el mateix nombre de cubetes. Aleshores, un cop tingui l’índex local, podria ser un arbre B o un mapa de bits, i la fletxa verda que puja d’aquest tipus us mostra que, encara que sigui un arbre B, encara hi ha opcions que es puguin fer. Es podria basar en funcions. I també, si es tracta d’un mapa de bits, hi ha diferents tipus de mapes de bits. Hi ha alguna cosa que es diu índex d’unió de mapa de bits. Si feu magatzem de dades, aquest és un tipus d’índex molt popular per esquema o disseny d’estrelles. El que passa és que l'índex té els ID de fila per al que apunta a la taula, però també tindrà ID de fila per a les taules pares de manera que quan siguis, haureu de dissenyar l'esquema d'estrella i busqueu en una taula de dades, aquest índex de la taula de dades us indica les dades que us interessen i us indica totes les files de les vostres dimensions, de manera que només haureu de tenir un índex.

I en realitat, això va néixer a causa de Red Brick, que era una base de dades fa molts anys, molta gent potser ho recorda. I, si us fixeu en aquesta imatge, i tingueu en compte que no he posat tot en aquesta imatge, perquè la imatge seria molt més gran, encara hi ha problemes addicionals, que tinc aquí al text a la part superior dreta. . És un índex d’ordre invers? I podríeu dir: “Per què voldria un índex d’ordre invers? Això no té cap sentit. ”Bé, si teniu un entorn agrupat a Oracle, si feu clústers d’aplicacions reals, si manteniu els vostres índexs en ordre, de manera que no s’inverteixin, si teniu molts processats que estan colpejant. els mateixos valors o els mateixos valors d'índex, el que passaria és que tindríeu zones calentes del vostre arbre B. Això vol dir que tindríeu contenció i possiblement bloquejat per provar i accedir a aquestes coses, i ho faríeu a través dels nodes d'una xarxa. Bé, si introduïu un índex d'ordre invers, ara podeu desfer-ho. Podeu dir, "Bé, els valors similars es troben en diferents parts dels arbres, així que no tinc els meus nodes separats per competir per àrees calentes de l'arbre". I, a continuació, noteu que l'únic no funciona amb algunes de les opcions. . Si us fixeu, he numerat tres, cinc, vuit i onze, així que hi ha alguns casos en què no puc tenir un índex únic. De la mateixa manera, hi ha alguns casos en què no puc tenir un índex invers, i hi ha problemes addicionals com el registre o el registre, i paral·lel i no paral·lel. Puc assignar coses a una àrea específica de la memòria.

I això deixa a veure algunes característiques d’Oracle. Diria que, quan mireu l'Oracle 12, probablement hi hagi una altra mitja dotzena de coses que podria afegir a aquesta imatge. La indexació és realment complexa i estic d’acord amb l’altaveu anterior, per navegar per això i fer una bona elecció, necessiteu una eina. Potser necessiteu, potser, una imatge com aquesta i algun tipus de metodologia sobre com escollireu les coses i, per tant, l'espera us ajudarà a arribar-hi. I aleshores, serà prova i error. Sempre els dic a la gent que s’indexi: “mira abans de saltar”. I, ​​a continuació, pots veure el gos petit aquí, que salta sense mirar, s’acabarà a l’aigua amb el tauró, o el tipus que es disposa a saltar a l’aigua., i ell s'impulsarà. Heu de pensar en la vostra indexació, ja que crear un índex no sempre significa que les coses milloren. De fet, crear un índex pot alentir les coses. I el rendiment de les consultes pot ser millor per un ordre de magnitud amb una opció sobre una altra. I et posaré un bon exemple. Si feu un esquema de disseny estrella i a les taules de dimensió utilitzeu índexs de mapa de bits en un cas i, en un altre cas, dius: "Faré servir índexs de l'arbre B", teniu mapa de bits contra B. arbre. Puc dir-vos que una solució serà un ordre de magnitud o possiblement diversos ordres de magnitud més ràpids que l'altre. Però tingueu en compte el que funciona en un entorn, com en un entorn d’emmagatzematge de dades, probablement no és una bona opció en un entorn OLTP.

Per exemple, si voleu agafar una taula transaccional i posar índexs de mapa de bits a una taula transaccional, és costós calcular i restablir mapes de bits, aquestes cadenes llargues i, per tant, en una taula OLTP, podeu colpejar la taula tan fortament que el mapa de bits índex es pot corrompre i retardar el sistema, perquè no són destinats a actualitzacions. Són excel·lents per accedir ràpidament, però no són bons per a actualitzacions. Crec que l'índex té proves i errors. En realitat, ja no hi ha cap regla daurada (hi ha massa variables diferents en aquesta equació) i, en última instància, hauràs de mirar l'execució o explicar els plans de la base de dades per veure si fas o no bones seleccions. I de vegades, l’anàlisi del pla gairebé pot ser una ciència per a si mateixa. No vaig a tractar-ho avui, aquest és un altre tema, però no tinguis per descomptat el disseny de l'índex. Hi ha raons legítimes per les quals us he mostrat tots aquests tipus d’index bojos a la imatge anterior i dels quals parlava l’orador anterior. No es van crear només perquè era una característica perfecta posar en una llista de comprovació en algun lloc per a un proveïdor de bases de dades; hi ha casos d'ús o escenaris en què aquests índexs són importants i faran una diferència important. Ara amb això, us mostraré alguns exemples de diferents tipus d'índexs en una de les nostres eines. Permeteu-me que només pugueu la pantalla perquè la veieu. Està bé, així que estic aquí dins, permeteu-me minimitzar aquesta aplicació. Estic a l’interior del VMware i estic executant una màquina virtual de Windows Server 2012.

I podeu veure, tinc gairebé totes les eines conegudes per l’home. Com a responsable de producte, he de mantenir-me al corrent de la meva competència, per tant, no només quines eines tinc, sinó què fan els meus competidors? I tenim aquesta eina que es diu DBArtisan, que ja tinc en marxa, però vaig, així que només la faré arribar. I el que podeu veure és que és una eina realment agradable, perquè en lloc d’haver d’utilitzar, digueu un gestor d’empresa per a Oracle i un SQL Management Studio per a SQL Server, i el MySQL Workbench per a MySQL i dotze bases de dades més que admetem, bé, tinc totes les meves bases de dades integrades en aquesta eina. Hi ha DB2, hi ha MySQL, Oracle, Postgres, SQL Server i Sybase, i això és que només tinc sis bases de dades en aquest tema perquè no puc; l’eina admet dotze bases de dades, però la meva pobre màquina virtual, executant sis bases de dades de forma simultània i intentant fer una demostració és aproximadament el que el meu maquinari us facilitarà. Per tant, deixeu-me tornar a l’Oracle i, si us adoneu, totes aquestes coses són iguals. Si vull mesurar el meu rendiment a DB2, són les mateixes opcions que tindria a Oracle. Ara a les portades fem moltes coses diferents per la qual cosa no heu de saber què passa, però us oferim una interfície coherent perquè pugueu ser un expert amb diverses plataformes de bases de dades. I inclouria treballar amb índexs, el tema d'aquesta discussió.

Permeteu-me entrar aquí i deixar-me començar primer per anar a veure algunes taules, i tinc una base de dades de pel·lícules que només compta amb algunes taules. I si miro una taula en concret, com la taula de clients, quan la porto aquí, puc veure el disseny de la meva taula, aquí les meves columnes a la meva taula i aquí la informació sobre cada columna. Tinc propietats per a la taula, però tingueu en compte que hi tinc una pestanya per als índexs i que veig aquí els índexs de la taula. Observeu que un d’aquests índexs és el meu índex PK, la meva clau principal. Aquests altres semblen només índexs per millorar l'accés a les consultes, potser consultem per nom o cognom o mirem telèfons i codis postals. I si trieu un índex en concret, com aquest codi postal aquí, i hi faig doble clic, ara puc veure que, hey, és un índex no únic i aquí en teniu alguns dels altres tipus, mapa de bits, no únic, únic, estigui ordenat o no, que tingui o no aquest registre, tant si és d’ordre invers, com si és una base de funcions. Oh, aquí és una diversió que no vaig cobrir. En realitat podeu tenir índexs invisibles. I em diries: "Bé, per què diables voldria fer un índex invisible?" Bé, et posaré un bon exemple. Esteu al vostre sistema de producció i teniu un problema de rendiment i no esteu segurs que la creació de l’índex us solucioni el problema, així que no voleu crear l’índex i retardar la producció, però d’alguna manera o l’altra que voleu poder provar-ho. Podeu crear l'índex de la producció com a invisible, és a dir, que no hi ha molts codis de l'aplicació, anomenant l'optimitzador, que l'utilitzaran. S'ha creat, és vàlid, però no s'utilitzarà. Aleshores, podeu fer una consulta que cregueu que podria ajudar-vos amb aquest índex o una sèrie de consultes i podeu introduir-hi una idea i dir: "Hola, optimitzador, hi ha un índex invisible que vull que utilitzeu i que deixeu Sé si he millorat les coses millor. ”I ara he provat alguna cosa en producció, però no he trencat les aplicacions en producció que s’executaven. Aquest és l’ús d’un índex invisible. Sembla tonto quan ho escoltes per primera vegada, però té un ús.

També podem definir, en els índexs, si són paral·lels i també quantes instàncies són paral·leles. Ara, en un entorn de clúster d’aplicacions no clúster o no real, per tant, en paral·lel, no significa rack, significa quants subprocessos que la meva consulta pot provocar i processos de treballadors, per intentar obtenir coses més ràpidament o més ràpidament. . I els casos paral·lels serien, si estic en un clúster d’aplicacions reals, digués que tinc deu nodes, a quants nodes se’m permet dividir el treball? Potser són quatre dels deu i, en cadascun d’ells, quatre subprocessos. Aquest és un exemple. I després tenim compressió de tecles. En realitat podeu comprimir índexs? Sí o no. I, per descomptat, teniu els paràmetres d'emmagatzematge que podeu especificar als índexs. Ara, no vaig cobrir-los perquè són realment més un paràmetre d'emmagatzematge que un problema d'índex. I, finalment, tenim que fer o no fer aquestes particions o no particions. Permetin deixar aquí un segon. Va a anar a un esquema diferent. Aquest és un esquema d'estrelles i, per exemple, aquesta taula de períodes és una taula de dimensions. Si alguna vegada heu realitzat un disseny d’esquemes d’estrelles, normalment teniu una dimensió per temps i així en aquesta base de dades i en aquest esquema estrella, el període és una dimensió de temps. Ara, sé que semblarà graciós, diràs: "Gee, mira totes aquestes columnes: alguna vegada el tipus ha sentit parlar de normalització?" Bé, quan esteu en un magatzem de dades o en un disseny d'esquema d'estrella, normalment no teniu taules que una persona típica hauria de mirar i dir: "Gee, no estan molt ben dissenyades". Però així ho feu en un entorn d'emmagatzematge de dades.

Ara, mira què passarà perquè, d’acord, hi ha totes aquestes columnes, mira això, tinc un índex a cada columna. Ara, en un entorn OLTP que seria un no-no. Alentiria totes les meves operacions. En un entorn d'emmagatzematge de dades, les deixaria durant els cicles de càrrega per lots. Carregueu sense la despesa ni els índexs, i jo tornaria a crear els índexs. I si particionés la meva taula, aleshores en lloc d’haver de deixar caure l’índex per a cada cub a la taula, només podria deixar caure l’índex a la galleda o cubetes on es podrien introduir les dades durant aquest cicle de càrrega per lots. A continuació, recreeu només la part de l’índex d’aquests cubs. I així ho fa molt manejable. I si mireu, així que aquí teniu una columna anomenada "Flag Flag" i, bàsicament, sí o sí. Tingueu en compte que aquest és un índex de mapa de bits i, per a la majoria de vosaltres, direu: "Bé, això té sentit". Sí o no, Y o N, només hi ha dos valors. I perquè quan llegeixis la documentació per als índexs de mapa de bits, sempre et diuen que esculls alguna cosa amb baixa cardinalitat.

Ara deixeu-me entrar en una de les meves taules de dades, així que aquí tenim les meves ordres. I això són les meves ordres al dia. I ja veuràs, que de nou tinc bastants columnes i, de nou, tindré més que alguns índexs. I aquí mateix, tenim alguna cosa que es diu codi de preu universal. Això va ser per a una botiga al detall, de manera que coneixeu aquests petits codis de barres quan compreu alguna cosa a la botiga, aquest és el codi de preu universal. Ara, hi ha milions de codis de preus universals. Ara, per a aquesta empresa en concret que venia coses, probablement tenien codis de preus universals d’1, 7 a 2 milions, així que espereu que aquest no sigui un índex de mapa de bits perquè 1, 7 milions de valors diferents semblen una alta cardinalitat. Però, en realitat, en un entorn d’emmagatzematge de dades, voleu que aquest sigui un mapa de bits. Ara, deixa'm explicar per què. Doncs bé, pot haver-hi 1, 7 milions de valors diferents per a aquest codi de preu universal, el nombre de files d'aquesta taula de comandes se situa entre els centenars de milions i milers de milions de files. El meu índex és de baixa cardinalitat en comparació amb la mida o la cardinalitat de la taula. Això fa que sigui una baixa cardinalitat. Això fa que l’índex de mapes de bits sigui útil, tot i que és contraintuïdor amb 1, 7 milions de valors diferents que escolliríeu aquí. Ara, si sabia que volia utilitzar un índex d’adhesió de mapes de bits, actualment el producte no és compatible amb això, obtindré això afegit per a la propera publicació, però aquí seria una altra alternativa. I recordeu que, en un esquema d'estrelles, recordeu que l'índex de mapa de bits es trobaria a la taula de dades i que un índex a l'arbre B apuntaria a la fila de la taula de fets i a cada fila que apareixia a la taula de dimensions per aquest fet. . I així, teniu una altra opció allà. I, a veure, ara vull sortir de taules i només vull mostrar-los ràpidament que tinc la mateixa informació, sota índexs, i vaig a fer el mateix.

Ara, la raó per la qual vaig plantejar és que potser es nota, no hi ha claus primàries aquí. Les claus primàries es realitzen amb una restricció de clau, de manera que en realitat estan cobertes per les definicions de restricció. Aquests serien índexs que no formen part de restriccions. Ara podríeu dir: "Bé, espera un minut, que pot semblar una clau estrangera i una clau estrangera és una restricció", però les claus estrangeres i la majoria de bases de dades no creen automàticament un índex a la columna de clau estrangera. recomanable, i hi aneu, he tornat a tenir totes les mateixes opcions. I si vull canviar només per comprimir-ho, puc fer-ho.

Ara la compressió només funciona en un índex d'arbre B. El que permet és que, quan mireu els diversos nodes de l'arbre B, permet comprimir alguns dels valors. Realment no és compressió com la compressió de taula, sinó que és la compressió del que s’emmagatzema en l’arbre B als nodes que no són de fulla. No estalvia un munt d'espai, però pot marcar la diferència. I amb això em vaig adonar que, m’acosto prou amb el temps, així que el que vull fer és que vull tornar i deixar de compartir. I, a més, tenim el nostre producte per a un assaig de catorze dies a idera.com. És un producte força bo, sobretot si es treballa amb diverses plataformes de bases de dades. Si treballes amb dues o tres bases de dades diferents, aquesta eina us facilitarà la vida. Tenim eines per ajudar-vos en el disseny i la selecció d’índexs, tenim una eina anomenada Optimitzador de DB. Simplement no podria cobrir això, que seria massa. I si voleu posar-vos en contacte amb mi, hi ha la meva adreça de correu electrònic, o bé, o em podeu agafar al meu correu electrònic privat, i tinc blogs, tinc un lloc web i blocs i un perfil de LinkedIn. Per tant, no dubteu en comunicar-me amb qualsevol cosa, encara que no tingui relació amb el producte, si només voleu parlar de bases de dades, sóc molt friki i m'encanta informar-me de la tecnologia.

Eric Kavanagh: D' acord, bé, Dez, Robin, estic segur que cada vegada tens dues preguntes com a mínim, ens queden uns minuts aquí. Dez, què en penses?

Dez Blanchfield: Tinc una gran pregunta que us he de fer, és que se m'ha quedat al darrere de la meva ment. Quin és l’escenari més boig que heu vist? He llegit el teu bloc, et segueixo de prop, probablement ets una de les poques persones que ha viscut gairebé totes les probabilitats i crec que el doctor Robin Bloor és el segon que he conegut la meva vida. Però, ja sabeu, probablement heu vist tots els escenaris bojos, quins són alguns dels escenaris més bojos que heu vist, i com éssers humans que no aconsegueixen fer front, heu aconseguit caminar i realitzar trucs mentals Jedi amb tot aquest DBArtisan?

Bert Scalzo: Un cop teníem un client que, en el seu disseny de bases de dades, pensava molt com pensaria en un disseny de disposició de fitxers, i així, quan normalitzis una base de dades, el primer que intentes fer és desfer-se. de grups repetidors. Bé, tenien una columna i la feien llarga, o BLOB o CLOB, i hi posarien valor, número u, punt i coma, valor número dos, punt i coma, nombre de valor, punt i coma, i tindrien milers de valors. Allà, però necessitaven cercar en aquella columna i són com: "Per què això funciona tan lent?" I jo sóc com: "Bé, no podeu crear un índex sobre el que vau fer, simplement no està permès. ”Així, en realitat els vam mostrar, fent servir els plans, que el que havien de fer era normalitzar la taula. No perquè la normalització sigui algun exercici acadèmic que millori les coses, sinó perquè volien fer una consulta en aquest camp, cosa que volia dir que podien indexar-la i no podríeu indexar-la en un grup que es repeteix, o almenys no fàcilment. . I així és probablement el pitjor que he vist.

Dez Blanchfield: Sí, és interessant la freqüència amb què us trobeu, crec que el repte amb les bases de dades, la gent oblida que és una ciència. I hi ha persones que fan títols i doctorats en tot aquest espai, hi escriuen papers i heu escrit tot un intercanvi inclòs els vostres manuals TOAD i altres coses de la memòria. La tendència cap a "big data" de tipus "quote-on-quote" ara, veig molta gent oblidant els fonaments de l'arquitectura de bases de dades i la tecnologia de bases de dades, la ciència de bases de dades, si voleu. Què veieu en el terreny en allunyar-me de les plataformes de bases de dades tradicionals i de les bases de dades tradicionals, pensant que vam fer un ús eficaç al terreny, i va ser només un cas d’ajustament i escalada de rendiment. Veus que molta gent s’està relacionant i té una experiència on només s’asseuen allà i tenen un moment “a-ha”, com un moment eureka, on s’adonen que aquestes coses de grans dades només són una base de dades de grans dimensions? És una cosa per aquí i la gent t’està responent i una mica de: “Ens oblidem, què sabíem i ens pots portar de la part fosca?”

Bert Scalzo: Bé, no, i això és horrible haver de reconèixer, però els proveïdors de bases de dades relacionals també han begut aquest Kool-Aid. Si recordeu, no ho sé, fa una dècada, vam començar a posar dades no estructurades a bases de dades relacionals, cosa que era una cosa estranya, i les dades, les bases de dades relacionals, ara s’afegeixen al tipus NoSQL. coses. De fet, a l’Oracle 12, CR2 (sé que encara no està fora), però si us fixeu en la beta, si esteu dins del programa beta, és compatible amb l’aprimament. Així, doncs, ara teniu una base de dades relacional que no ha afegit el concepte d’agudització NoSQL. Així, el moment "a-ha" sembla ser més per a les persones del costat relacional que van a "ha-ha". Ningú no ho tornarà a fer bé, ni tan sols els gestors de bases de dades, així que ha de passar per sobre i unir-se al costat fosc.

Dez Blanchfield: Va, de manera que estàs dient un canvi a moltes de les dades desordenades, si entenc bé, pel que ara anomenem plataformes de dades grans, cosa que és divertit, perquè són No és tan antic, però això no vol dir, doncs, que es concentren en el que fan amb la seva base de dades relacional per aconseguir més avantatge?

Bert Scalzo: No, normalment, si tenen una necessitat al que hauria estat citant una "necessitat de tipus de dades gran", estan trobant que en lloc d'haver d'anar a l'altra plataforma de bases de dades i fer alguna cosa en un no de manera relacional, els proveïdors de bases de dades ara els ofereixen les mateixes tècniques no relacionals dins de la base de dades relacionals per fer aquestes coses. Vull dir, un bon exemple seria si teniu dades no estructurades, com un tipus de dades JSON o algun altre tipus de dades complexe que tingui sentit incrustat a les dades mateixes, els proveïdors de bases de dades no només admeten això, sinó que us donaran ACID. compliment de dades no estructurades. Les bases de dades relacionals han abastat les tècniques i tecnologies més noves i, per tant, sembla que no és més que "a-ha", "Hey, els desenvolupadors d'aplicacions, hem descobert alguna cosa i hem de tornar-la a aprendre", és "Hola, ho fem d'aquesta manera, com puc fer-ho d'aquesta manera a la vostra base de dades tradicionalment relacional i com ho faig en aquesta base de dades aquí? "I això és cada vegada més prevalent, i com he dit, els propis venedors de bases de dades estan habilitant això.

Dez Blanchfield: Just, qui són els sospitosos tradicionals en aquest espai per a l'eina DBArtisan i això? Vaig fer alguns deures sobre allò que havíeu escrit recentment i, de la memòria, havíeu escrit alguna cosa, crec que era un dels vostres blocs sobre un rendiment extrem de la base de dades del món d’Oracle. No puc recordar quan era, crec que en algun moment va ser per memòria o des de finals de l'any passat, hauríeu escrit això. I em va semblar que era el sospitari tradicional i habitual del tipus de tema que parlem avui, on la gent acudirà a un entorn de bases de dades a gran escala i buscarà el que en diuen beneficis extrems. Qui són els sospitosos habituals que veieu per aquí, que prenen DBArtisan i ho utilitzen?

Bert Scalzo: Bé, tenim molts clients, de fet, avui estava amb una agència governamental molt gran que, i probablement tenen prop de 1.000 còpies del nostre programari, perquè permeten a les persones centrar-se en el que ells. ho estic fent, i no com fer-ho. I està bé, vull dir, tothom hauria de saber fer alguna cosa, però la productivitat està fent “allò”. Si l'empresa em demana que faci una tasca, tot això els interessa. Quan vaig rebre una marca de verificació per dir quan es va fer la tasca? No quina tècnica ni quina tecnologia que he fet servir per arribar-hi. I, per tant, la nostra eina els permet centrar-se en el que, i els permet ser molt més productius, i això és realment l’enorme avantatge, i com he dit, algunes bases de dades ofereixen una eina només per a la seva plataforma de bases de dades. L’oferem per dotze plataformes de bases de dades. Tinc el mateix flux de treball, la mateixa interfície gràfica d’usuari, les mateixes navegacions. Si sabeu atorgar un privilegi a un usuari o com podeu crear una taula o crear un índex en una base de dades, podeu fer-ho en dotze perquè té el mateix aspecte i el mateix flux de treball. Això té un gran valor per als nostres clients.

Dez Blanchfield: Sí, suposo que la gent vol guanyar-se molt més pels seus recursos humans. I els dies de tenir un especialista individual en Oracle, Ingres i DB2 ja han desaparegut. S'espera que la gent sigui el Jack de tots els comerços, així que crec que aquesta cosa els ha salvat absolutament la vida.

Només un últim ràpid abans de lliurar-lo al doctor Robin Bloor. Heu comentat que hi ha una descàrrega gratuïta durant catorze dies. Què fa, si vaig a tirar endavant i vaig a fer-ho, per cert, vaig a posar-ho al laboratori tecnològic Bloor i fer-ho aixecar-me i posar-me a la mà jo mateix, fins ara no havia tingut l'oportunitat de fer-ho. Heu esmentat un judici de catorze dies, heu dit que l'executeu amb una màquina virtual a l'ordinador, suposo que és un ordinador portàtil. Què són, quina és la configuració de primer nivell perquè algú es posi mans i utilitzi el procés de prova de catorze dies, just abans de tornar a Robin les seves preguntes?

Bert Scalzo: qualsevol entorn de Windows, de manera que Windows 7, màquina virtual amb una CPU i quatre concerts de memòria. No som una eina molt grassa ni costosa. Ara, si voleu executar el servidor de base de dades en la mateixa màquina virtual sota el mateix Windows, sí, haureu d’afegir-ne més, però si esteu executant la base de dades en un servidor de bases de dades o en una màquina virtual independent, la màquina virtual es carregarà i executar el nostre producte és molt lleuger: una CPU, quatre programes de memòria, pràcticament qualsevol versió de Windows, i admetem instal·lacions de trenta-dos i seixanta-quatre-bit. Però cal instal·lar el client del venedor de bases de dades. Per tant, si voleu connectar-vos a Oracle, heu d’instal·lar el client SQL Net, perquè és el que requereix Oracle per parlar amb una base de dades.

Dez Blanchfield: Sona força senzill. Crec que una cosa d’això és més que qualsevol cosa que espero que la gent se’ls emporti, a part que la constatació que aquesta eina estarà per salvar-se la vida, és que haurien d’anar a descarregar-la i jugar amb ella, atès que oferiu una prova gratuïta de catorze dies. I pot funcionar al seu portàtil actual sense instal·lar res addicional, ja que si ja estan fent administració de bases de dades, ja treballen amb bases de dades, tenen totes aquestes eines al seu lloc i si funcionen en una màquina virtual o en una Escriptori local, sembla que sense dolor d'instal·lar i jugar. Així que recomano molt que la gent ho faci.

Robin, estic segur que teniu preguntes i Eric, probablement haureu rebut algunes de l'audiència, així que Robin, què em passa a vosaltres, i després a Eric?

Robin Bloor: Sí, està bé, bé, tinc coses a dir, vull dir, sempre he trobat aquesta zona fascinant perquè era així: em vaig tallar les dents. Però la veritat és que, probablement des del 1998, el 1999, he estat capaç de desenvolupar Oracle. I, sabia Sybase i Microsoft SQL Server, tots dos són bastant simples en comparació amb el que pot fer Oracle. Em vas fer riure quan vós, vull dir, em vaig tapar la boca quan vau començar a parlar d’aguts. Oracle ho feia abans. Oracle va introduir-los en algun moment del temps, es van posar nerviosos per la idea relacional d’objectes, de manera que van introduir la capacitat de crear una espècie de notació d’objectes i d’emmagatzematge d’objectes a Oracle, i vaig parlar amb un dels seus enginyers, una cosa com un parell de anys després que el van introduir i em vaig preguntar quantes persones l’utilitzaven, i va dir que crec que dos clients ho havien provat i que va ser. I crec que passarà el mateix si comencen a provar coses de tendència NoSQL. Ja ho sabeu, crec que és un error, vull dir que estic interessat en saber quins són els vostres pensaments. Certament, els beuen del Kool-Aid. Se senten com si hagin de poder reclamar semblants a les grans bases de dades NoSQL com Cassandra, però ja sabeu, té sentit?

Bert Scalzo: No, t'has tocat l'ungla al cap. A mi, jo, si vaig a fer relacionals, escolliré un venedor relacional com un Oracle, un SQL Server o un DB2 o un Postgres, però si faré alguna cosa que no sigui relacional, a l’espai de dades gran o a l’espai NoSQL, vaig a triar l’eina adequada per al treball adequat. I no crec que això sigui naturalment el meu proveïdor de bases de dades relacional. I, a continuació, hi afegiu l’altra arruga, és a dir, què hi ha al núvol? Tanta gent vol tenir les seves bases de dades fora de les premisses. A continuació, heu de mirar al vostre proveïdor de núvols i dir: "D'acord, què proveïu, quines bases de dades teniu disponibles per a mi que s'ajusten a les meves necessitats i com són vençables, i francament quina és la tarifa o el càrrec per utilitzar aquesta base de dades. al núvol per hora o per dia. I per gigabyte o terabyte? ”I el que trobareu és potser algunes de les bases de dades relativament més recents com Mongo o Cassandra, potser les seves tarifes són més barates, així que si aneu a fer grans dades de tipus multi-petabyte, potser haureu de tenir, només des del punt de vista del cost, les bases de dades NoSQL del núvol, perquè poden ser la manera més rendible de fer-ho.

Robin Bloor: Sí, no. Vull dir, el meu tipus de coses, el de les bases de dades relacionals de la meva experiència, que és prou llarg per tenir cicatrius, és cert, hi ha molt de sentit comú que si comenceu a aplicar-lo i comprendreu què és realment relacional, Vull dir, recordo haver fet una mica de consultoria amb un client un cop i em van portar a una habitació i havien fet una mena de diagrama d’entitats i van crear un tercer formulari normal, un model de com eren els sistemes primaris de l’empresa. Tenia dues-centes quaranta taules al voltant i em van dir: “Bé, què en penses d’això? Crearem una base de dades per a això ", i vaig dir" Què en penses d'això? "Vaig dir:" No crec que funcioni ". I és correcte, ja ho sabeu, perquè estaven acabant per crear una estructura particular dins d'unitats d'onze vies. I això és el que cal entendre sobre relacional. Així doncs, estic interessat pel que fa al mal disseny que tens. Vull dir, no tinc cap problema amb DBArtisan, és que fa coses molt assenyades i el fet que realment es pot mostrar a diverses plataformes, crec, és meravellós, però quant trobareu allà on és el disseny. En què la gent hauria pogut resoldre’s tota mena de cor si baixessin a un esquema d’estrelles en lloc de rebre cops de neu, això?

Bert Scalzo: Bé, no vull sonar, presumptuós ni arrogant, però diria més sovint. És evident que la majoria de les bases de dades amb les que hi participo tenen problemes o problemes. La qual cosa és bo, perquè les nostres eines, com la nostra eina d’optimitzador de bases de dades, poden ajudar-los a resoldre aquests problemes, i, el que realment em fa gràcia, és que molts dels problemes són els mateixos problemes simples. L'altre dia, només treballava amb un client que tenia una consulta d'unió amb una forma d'onze i em sento com: "Està bé, per què no utilitzaves una clàusula amb?" I són com: "Bé, no ho vaig fer No sé què és això. I després vaig dir: "I mireu les vostres subeleccions aquí relacionades amb les vostres correlacions i les no correlacionades", vaig dir, "En alguns casos teniu la vostra clàusula on el nivell més profund, Una forma de referència de la taula exterior. "Vaig dir:" És a dir, traslladeu-la al nivell adequat, no incorporeu-la més a fons del que ha de ser, confondreu l’optimitzador. ”I amb uns quants cops de retocs, Es va prendre una cosa que estava funcionant al voltant de dues hores i es va reduir a deu minuts i va ser just, en aquest cas, no vam fer res més que millorar el SQL que havien escrit. Crec que el problema és que moltes universitats i molta gent que aprenen la programació en un entorn no acadèmic, l’aprenen com a processos de temps enregistrat o procés orientat a fila i relacional és un conjunt orientat per la naturalesa, i així que ha de pensar en conjunts per escriure un bon SQL.

Robin Bloor: Sí, crec que és exactament. I heu d’entendre, són coses així, la gent hauria de conèixer els ABC d’aquestes coses. No importa. No podreu fer coses racionals si no us adoneu que fins i tot una base de dades ben dissenyada i ben modelada s'uneix al temps, les sorts necessitaran temps. Ho fan perquè el món mai no ha trobat una manera de fer que aquests vagin ràpid. Han trobat maneres d’organitzar les dades perquè vagin més ràpidament que d’altra manera, i l’entusiasme que he de dir per les bases de dades NoSQL és simplement que s’eviten fer ajuntaments. Tot just comencen a crear les bases de dades amb la mateixa difusió de dades en elles, perquè si s’uneixen a qualsevol de les bases de dades NoSQL, xuclen força. No ho creus?

Bert Scalzo: Oh, absolutament. I he de riure, perquè vaig començar el camí abans de les bases de dades relacionals i quan Ingres era RTI, Relational Technology Institute, i no teníem SQL, teníem llenguatges relacionals pre-SQL. Crec que a Ingres, en aquell moment, es deia Quel. De manera que heu obtingut aquests antics paradigmes de bases de dades com la xarxa i un gràfic més alt o jeràrquic, i aneu a través dels paradigmes relacionals al cap d'un parell de dècades, i ara a mi em sembla que tornaríem a gairebé una jerarquia. És gairebé com si haguéssim revertit.

Robin Bloor: Sí, no. Millor transmetre-li a Eric, estic consumint massa temps, però tenim alguna pregunta del públic, Eric?

Eric Kavanagh: Nosaltres, en tenim alguns. Anem una mica llarg aquí però us en faré un parell. Vam tenir un parell de preguntes al voltant dels índexs invisibles. Una de les preguntes va ser: "Algú necessita utilitzar la vostra eina per veure-les?" Una altra pregunta va ser: "Bé, què passa si sou cecs?"

Bert Scalzo: És bo.

Eric Kavanagh: Pregunta curiosa, per tant, només FYI.

Bert Scalzo: No, no cal tenir les nostres eines. Aquesta és una característica d’Oracle, l’índex d’invisibles. Bàsicament al diccionari de dades, Oracle només conserva un tros de metadades que diu "Optimitzador, ignora aquest índex. Ja és aquí, però a no ser que us hagueu indicat físicament a través d’un suggeriment a l’opció, un suggeriment d’optimitzador de l’ordre SQL, no utilitzeu-ho. ”I, per tant, no, no heu de tenir les nostres eines i, en tots els aspectes, és un índex senzill, es pot veure a qualsevol eina, només l’optimitzador dirà: “Ho ignorarem en el processament normal de consultes”. Heu de dirigir-lo si voleu que s’acostumi. És realment útil per a l’escenari que he descrit, que és si volguéssiu crear un índex en producció però no arriscar-vos a trencar els informes o les coses que ja s’executen, però voleu provar-los. Per això és més útil.

Eric Kavanagh: Això és bo, i aquí hi havia una altra bona pregunta. Què passa amb algunes d'aquestes noves bases de dades a la memòria? Com canvia el joc de la base de dades en memòria de la memòria pel que fa a la indexació? "

Bert Scalzo: Noi, bé, ara, això és bo, estic content que algú em fes aquesta pregunta, haurem de passar una mitja hora més. No, la memòria in-depend, depèn del venedor de bases de dades. Ara, normalment, ho sóc, no parlo més que elogis de tot el que Oracle fa perquè és increïble la tecnologia que han construït, però quan tornes a esquinçar-se sota les portades i mires el que hi ha a la memòria a Oracle, a l'Oracle en la base de dades, el que és en realitat és que encara es manté el magatzem de files al disc i es carregarà la memòria de columnes carregada a la memòria, i si no hi ha memòria suficient per contenir tota la taula, es tornarà a referir a les porcions; no s'ajustarà a la memòria, per fer-ho a la botiga de files, de manera que realment podríeu fer una selecció contra la taula i, per la meitat de la taula, utilitzeu una indexació que colpeja les files tradicionals a la taula i, per a l'altra meitat, el selecte en realitat s’apaga i només agafar-ho tot d’una cerca a la memòria i, per tant, és diferent a la manera en què SQL Server, per exemple, l’ha implementat amb la seva tecnologia Hekaton, ja ho sabeu, i SQL 2014, i s’ha millorat. a SQL 2016, però en alguns aspectes, la seva és una versió més veritable de la memòria i, però, cada implementació té avantatges i contres, però heu de mirar sota les portades i adonar-vos. Perquè, vaig tenir un client que va dir: "Oh, la taula és a la memòria; només vaig a elaborar tots els índexs", i em sembla que "La taula és més gran que la memòria que teniu al servidor" de manera que en algun moment alguna de la consulta ha arribat al disc. "

Eric Kavanagh: Aquesta és una bona descripció; això és bo. Bé, gent, tindrem uns quants transmissions web més amb aquests nois durant la resta d’enguany, que torni en qualsevol moment que sentiu que Bert està de presentació perquè sabem que sap les seves coses. Sempre és divertit parlar amb els experts. Arxivem tots aquests transmissions web per a la seva posterior visualització. Aquí teniu la informació de contacte de Bert una vegada més, i intentarem esbrinar aquest enllaç per a la descàrrega i enviar-lo també per correu electrònic, però sempre podeu enviar-vos per correu electrònic la vostra veritat: tenim molts transmissions web alineades per això. any i ja estem fent l’edició en aquest moment, així que, persones, si hi ha temes que realment vulgueu escoltar sobre l’any vinent, no siguis tímid: tingueu cura, gent, en parlarem la propera vegada. 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