Sommario:
Di Techopedia Staff, 5 ottobre 2016
Takeaway: l' host Eric Kavanagh discute dell'indicizzazione del database con il Dr. Robin Bloor, Dez Blanchfield e Bert Scalzo di IDERA.
Al momento non sei collegato. Accedi o registrati per vedere il video.
Partner di contenuti Techopedia
Lo staff di Techopedia è affiliato a Bloor Group e può essere contattato utilizzando le opzioni sulla destra. Per informazioni su come lavoriamo con i partner del settore clicca qui.- Profilo
- Sito web
Eric Kavanagh: signore e signori, ciao e bentornati ancora una volta. È un mercoledì, alle quattro in punto orientale, e quelli di voi che conoscono il programma, sanno cosa significa, è tempo per un altro episodio di Hot Technologies. Si Certamente. Mi chiamo Eric Kavanagh, sarò il tuo moderatore per la sessione di oggi: "Index Insanity: How to Avoid Chaos Database". O, come ho fatto riferimento ad esso nell'ultima esplosione della posta elettronica per uscire, "wrangling del database". Termine in questi giorni, "wrangling". Lo fanno tutti. C'è davvero una diapositiva sulla tua. E abbastanza su di me.
Quindi, la serie Hot Technology è stata davvero progettata per definire uno spazio particolare, in contrapposizione alla Briefing Room, che è solo un briefing live tra analisti, per Hot Tech abbiamo due analisti. Oggi sarà il nostro dottor Robin Bloor e il nostro scienziato di dati Dez Blanchfield. E stiamo parlando di un argomento che penso sia davvero abbastanza emblematico di ciò che sta accadendo oggi sul mercato.
La linea di fondo è che in questi giorni siamo in un mondo di complessità. Davvero, se ripensate a quindici o venti anni, allora era un mondo molto diverso, specialmente per quanto riguarda la tecnologia dei database. I database erano abbastanza semplici. Ce n'erano solo una manciata di loro; la maggior parte erano relazionali. Ora, abbiamo tutta questa gamma di tecnologie di database. Decine di opzioni sul tavolo per chiunque voglia creare un'applicazione o fare qualcosa con i dati. Tutto sta cambiando e ciò influisce sulle persone che provano a gestire questi sistemi. Parleremo oggi con Bert Scalzo, che è un vero esperto nel settore; è il senior product management di IDERA, su ciò che puoi fare per ottenere una gestione di tutti quei dati. Detto questo, lo consegnerò al dottor Robin Bloor per portarlo via. Robin, il pavimento è tuo.
Robin Bloor: Okay, grazie per questa presentazione. Penso che - poiché è una cosa a due mani, penso che vorrei solo parlare dell'ottimizzazione del database in generale come introduzione a questo spettacolo Hot Tech. Ho iniziato la mia vita - nella tecnologia e nell'analisi - ho iniziato la mia vita facendo questo perché ero solito scrivere articoli sulle capacità dei database sulla piattaforma DEC VAX. E per questo motivo, i clienti del database mi informavano. E la cosa che mi viene in mente è che, perché dovresti avere un database? Voglio dire, a quei tempi un sacco di persone usavano creare file di valori chiave e usarli per avere una sorta di fallacia sequenziale dell'indice come li chiamiamo, ma per creare una sorta di capacità di database, e sai, perché dovresti qualunque altra cosa?
E la risposta a questo, penso che Michael Stonebraker abbia dato la migliore risposta a questo, e ha detto: "Un database può sapere di più su dove si trovano i dati e quanto velocemente ottenerli, di quanto qualsiasi programma possa mai sapere". E penso che sia interessante; è la natura del gioco. Ma nel 19 - beh, nel 1989, ho iniziato l'analisi tecnologica e sapete, in quel momento, i database erano molto semplici e i database relazionali erano super semplici. Avevano così poche capacità, intendo dire che potevano archiviare dati, ovviamente, e tu potevi fare il backup e loro avevano, erano ACID compatibili, ma avevano davvero degli ottimizzatori molto deboli. In effetti, sarebbe difficile sostenere che avevano la capacità di ottimizzazione.
E in seguito sono diventati sempre meglio, ma, sai, quando un database non funziona - dato che questi canguri sembrano essere in un modo o nell'altro che indicano - ci possono essere moltissimi motivi per cui sta andando piano. E questo mi porta al punto: i database hanno molte funzioni, ma il più importante è l'ottimizzazione delle query. Se non lo facessero, non li useresti. Si tratta di ottenere rapidamente informazioni, di poterlo fare quando ci sono molti utenti simultanei e questo è un problema difficile. E quando guardi davvero, chiamiamoli database maturi, se vuoi - ma certamente Oracle, in misura leggermente minore, Microsoft SQL Server, sicuramente Teradata e DB2 - gli ottimizzatori di quei database hanno, sono stati decenni nel edificio. Sai, non lo hanno fatto - qualcuno non si è seduto - sei ragazzi in un progetto di due uomini, un anno, e ne hanno semplicemente battuto uno insieme. Non funziona così. La capacità di ottimizzazione è gradualmente cresciuta e richiede molta crescita. Comunque, parliamo dello sfondo del database. Bene, adesso si dice molto sul database NoSQL e c'è persino molto entusiasmo per il database dei grafi. E l'uso di SQL su Hadoop e cose del genere. Ma la verità è che se si desidera un database in questo momento, se si desidera un database completamente funzionale, capace di OLTP e traffico di query di grandi dimensioni, si tratta di un database relazionale o nulla.
Tra i database relazionali, Oracle ha una popolarità dominante. Microsoft SQL Server, penso, è il secondo. Sono entrambi in grado di essere utilizzati per OLTP e per il carico di lavoro delle query, ma in realtà non si può davvero cavarsela mescolando quei carichi di lavoro. Sono necessari incidenti diversi per carichi di lavoro OLTP e carichi di lavoro di query. Esistono alternative a SQL e al grafico. La maggior parte delle aziende si standardizza su un database specifico, motivo per cui - intendo dopo decenni di combattimenti con tutti gli altri giocatori, Oracle è diventato il più dominante. Semplicemente perché hanno finito per essere in grado di vendere licenze aziendali, e quindi le aziende avrebbero usato prodotti alternativi solo in prodotti eccezionali, semplicemente Oracle non li avrebbe fatti. E i database sono strategici in quanto anche essi si evolvono. E sai che ho fatto un po 'di ricerca per questa presentazione, ed è un po' - ci arriverò tra un po ', ma è un po' interessante il modo in cui si evolvono, in termini di osservarlo dalla posizione di un DBA. Questo è ciò che chiamo la tendenza invisibile. È la legge di Moore al cubo. È più o meno così: il database più grande è, e nuovi database, non esiste un vecchio database che abbia molti più dati da ingerire. Di solito è un database che viene applicato a un nuovo problema. E in realtà crescono in termini di volumi di dati. Circa al cubo di Moore legge. Quindi la legge di Moore è un fattore dieci volte ogni sei anni. I VLDB tendono a crescere di un fattore mille ogni sei anni. Nel 1991, 1992, i grandi database sono misurati in termini di megabyte. Nel '97 e '98, gigabyte. 2003, '4, terabyte. 2009, '10, hai iniziato a vedere i database petabyte. Penso che ci siano probabilmente uno o due database exabyte là fuori in questo momento, ma il più grande di cui ho sentito parlare sono i 200 petabyte in tempo, e sai, non ottenere dati in un database petabyte. Ma la maggior parte di queste saranno ovviamente le nuove grandi aziende del web 2.0, forse, hai Facebook in quella direzione.
Ma comunque, se lo guardi davvero, aspettandoti che un database attraversi quel tipo di escalation di volume, lo sta chiedendo molto. E sorprendentemente, certamente fino al livello di petabyte, sembrano aver fatto ragionevolmente bene. Voglio dire, sto parlando dei prodotti più vecchi piuttosto che di qualcosa di nuovo. Sembrano aver fatto straordinariamente bene. Se osserviamo le prestazioni del database, i colli di bottiglia, questo mi riporta al tempo in cui mi occupavo davvero di loro e dovevo preoccuparmene. Sai che questo è fondamentalmente la rottura dell'hardware. Ci sono colli di bottiglia della CPU, possibilmente, ci sono colli di bottiglia della memoria, forse, ci sono colli di bottiglia del disco, possibilmente. Può essere la rete che ti causa dolore e puoi anche avere problemi con il blocco, a seconda di cosa stai facendo, ma di solito è perché il programma non sa chi chiamare il blocco. Quindi, se hai intenzione di ottimizzare un database, stai effettivamente cercando di ottimizzarlo in modo che balli tra questi cinque possibili colli di bottiglia, così come può fare. E questo non è facile, perché la quantità di memoria che è possibile configurare su un determinato server è aumentata notevolmente. Quindi le CPU sono diventate multicore, disco, ora possiamo fare, penso, anche su server di prodotti, penso che puoi fare centinaia e centinaia di terabyte, un quarto di petabyte, forse, anche su un server di prodotti. Quindi, di tutte queste cose, puoi giocare, la rete ovviamente può andare a velocità diverse, ma soprattutto quando hai a che fare con database, vuoi davvero avere cavi in fibra tra i server e nient'altro che gira su quello, particolare quel modo.
Fattori di prestazione del database. Voglio dire, sto tralasciando di cosa si tratta, perché so che Dez ne parlerà, ma una cattiva progettazione del database significa un database con scarse prestazioni. Una cattiva progettazione della programmazione può significare forse lanciare un codice SQL molto stupido in un database, che richiederà molto più tempo. Combinazione di concorrenza e carico di lavoro, troppa concorrenza causerà problemi di colli di bottiglia. Il mixaggio del carico di lavoro, quando hai query di grandi dimensioni con query molto piccole, brevi e precise, causa problemi. C'è un problema di bilanciamento del carico. La maggior parte dei database si occupa di questo, ma se non si dispone di un prodotto sofisticato, quindi, aggiungendo solo alcuni server, non è tutto ciò che si fa se si desidera effettivamente aumentare le dimensioni di un cluster. È necessario bilanciare il carico prima di ottenere prestazioni ottimali. Devi fare la pianificazione della capacità. Assolutamente. Soprattutto ora in questi giorni come quando i volumi di dati aumentano in modo più drammatico rispetto al passato per i database. E ci sono interi problemi a livello di dati su come ingerire i dati, su come spostarli. La mancata consegna puntuale dei dati a un database può essere un problema di prestazioni in seguito perché siamo passati dai database che funzionano in Windows, alle operazioni ventiquattro per sette per trecentosettantacinque e non ci sono finestre in cui è possibile rallentare database inattivo o è improbabile che ci sarà al giorno d'oggi.
Il problema Oracle DBA. Questo è ciò a cui stavo pensando. Sono stato nel DBA di Oracle con Oracle 7 e ricordo come ottimizzarlo. E se guardi davvero Oracle ora, è molto, molto, molto più capacità. Ha l'indicizzazione bitmap e cose del genere, ma in realtà mi sono preso il tempo di guardare e vedere quanti parametri di ottimizzazione ci sono attualmente in un database Oracle. E ci sono oltre trecentocinquanta parametri di ottimizzazione e ci sono altri cento parametri nascosti, che i DBA specializzati potrebbero conoscere, ma i normali DBA Oracle non sanno. Ciò significa che ottimizzare questo tipo di database è una cosa difficile. Non è affatto una cosa semplice. Devi provarlo, devi averlo fatto per molto, molto tempo e devi sapere esattamente quale problema pensi di risolvere, perché l'accordatura inizia quando il le prestazioni diventano scadenti, ma potrebbe non essere le prestazioni di tutto. Potrebbe essere la prestazione di query specifiche che contano e potresti essere in grado di risolverlo bloccando determinati dati e memoria, oppure potresti doverlo riparare indicizzando, oppure potresti dover iniziare a fare il partizionamento in un modo diverso. Ci sono molte cose che puoi fare, è questo il punto. Quindi, di conseguenza, non lo faranno nella loro testa - i DBA hanno bisogno di strumenti. Passerò ora a Dez che ti parlerà dell'indicizzazione, credo.
Eric Kavanagh: Va bene Dez, portalo via.
Dez Blanchfield: Grazie, Robin, e adoro la copertina. Penso che tu abbia gettato il guanto di sfida perché io possa avvicinarmi anche a qualcosa di così eccitante. Ma ho usato un'immagine della nostra piccola galassia, come la mia visione di ciò che la sfida di oggi per gli amministratori di database si è trasformata, perché questa è l'immagine mentale che tendo a evocare quando entro in un ambiente e non sono più nel mondo dell'amministrazione di database o della progettazione di database a quel livello. Ma, come te, Robin ed io abbiamo avuto molti anni di esperienza nel mondo dei database, sia come amministratore o sviluppatore, sia alla fine architetto, e poi ci siamo resi conto che avrei potuto fare cose migliori per guadagnare una crosta. Ma sembra che tu stia fissando questa galassia di dati, e ancora di più oggi, quando passiamo, come hai delineato, siamo passati da megabyte a petabyte ed exo-scale in un periodo di tempo molto breve, nel grande schema delle cose. Ma la frase che ho in mente è che gli indici dei database sono ora un'arte nera e non sono proprio il tipo di cose che i semplici mortali dovrebbero fare per dilettarsi, per applicazioni aziendali di livello aziendale e il tipo di formulazione di te stavamo solo parlando. Ma volevo passare attraverso una rapida carrellata del tipo di storia che ho avuto con i mondi del database e portare al contesto in cui trarremo una conclusione, e poi scorrere un po 'di materiale oggi con i nostri amici a IDERA, perché penso che ci siano molti pensieri diversi su come ottenere l'ottimizzazione delle prestazioni del database e uno di questi sta mettendo in discussione la cosa. Per molti negozi in cui mi imbatto, invariabilmente non arrivano al punto di eseguire l'ottimizzazione delle prestazioni a livello di database e in particolare a livello di indice fino a quando non hanno attraversato il difficile percorso di pensare di poter lanciare un sintonizzatore su di esso .
Molte persone hanno solo un grande approccio ironico ad esso, nella mia mente, e ho una foto di The Flash qui perché se hai mai visto vecchi film o sicuramente l'ultimo programma TV con The Flash, come in Flash Gordon, il vecchio personaggio, e ora che si chiama "The Flash", tende ad andare molto, molto velocemente e invariabilmente la sua energia si esaurisce. E questo è ciò che accade quando si lancia un grosso ferro alle prestazioni del database. Invariabilmente, nella mia esperienza, puoi mettere alte prestazioni, duro lavoro nel gioco, puoi ottimizzare i tuoi sistemi operativi e ottimizzarli fino a un certo punto. Puoi assicurarti di avere CPU multicore e multithreading veloci per rendere l'applicazione più veloce, puoi lanciare molta RAM, puoi avere backplane ad alto throughput, puoi passare dai dischi rigidi alla cache dei dischi rigidi allo stato solido e array di archiviazione ad alte prestazioni. E anche ora, le persone inseriscono cose come flash e NVMe nei loro motori di database, pensando che otterranno questo accesso per due volte il miglioramento delle prestazioni. E invariabilmente ottengono un certo guadagno. Ma tutto ritorna agli stessi problemi di ottimizzazione delle prestazioni di base. Molte connessioni di rete a bassa latenza, in modo che i cluster funzionino rapidamente. E dell'infrastruttura del database di clustering, quindi hai più di una macchina che fa tutto il lavoro. Ma tendi a tornare allo stesso problema di prestazioni di base, e cioè leggere i dati. La scrittura di dati è per lo più una sfida abbastanza lineare e, a meno che non sia eseguita correttamente.
E poi abbiamo la sfida nel mondo di oggi: non tutti i database sono creati uguali. Ci sono database e "database" quotazione su citazione. E quando pensiamo ai motori di database, le persone spesso pensano ai soliti sospetti tradizionali come erano nel mondo SQL. Sai, abbiamo Oracle e Microsoft SQL Server, e ce n'è un paio nel mondo open source con MySQL, che ora è di proprietà di Oracle, ma è ancora open source. E poi abbiamo i sospetti non così soliti, i motori NoSQL, che hanno ancora un problema con l'indicizzazione e la gestione delle prestazioni, e non entrerò in loro in molti dettagli, ma c'è un numero crescente di questi le cose spuntano ogni giorno e sembrano e si sentono come motori di database dal punto di vista degli sviluppatori e dal punto di vista delle prestazioni, ma sono bestie molto, molto diverse e hanno la loro piccola nicchia nel mondo per ritagliarsi prestazioni in memoria o scala lineare su disco. Ma questo è come appare il mondo nel mondo dei database. Questo è il 2016, questa è la versione tre della mappa di, da una serie di persone che producono questa mappa paesaggistica in corso di come appaiono i database, ed è qui che nemmeno un architetto di database sovrumano o un amministratore di database potrebbe avere senso di esso. Letteralmente centinaia, centinaia e centinaia di marche, modelli, produttori di database diversi, invariabilmente conformi a SQL. E la cosa interessante è che tornano tutti alla stessa sfida. Prestazioni e ottimizzazione delle prestazioni nel motore di database, in particolare in base al modo in cui i dati vengono indicizzati.
Quindi, copriamo rapidamente l'indicizzazione del database, perché è un argomento interessante e devi approfondire la demo, credo. Tuttavia, ritengo sia abbastanza accettata e la prassi standard del settore che l'ottimizzazione delle prestazioni dell'indice del database è il punto in cui il mondo inizia e finisce per garantire che i dati siano accessibili in un formato veloce e rapido. Ma cos'è l'indicizzazione del database? Se pensiamo all'indicizzazione nella forma a cui siamo abituati come esseri umani di tutti i giorni, pensa a una pagina di indice in un libro. Se vuoi trovare qualcosa in un libro - in particolare artisti del calibro di un'enciclopedia, o qualcosa come un materiale di riferimento in qualche forma - se stai cercando qualcosa come questa pagina, dove sto cercando cose come l'argomento delle dighe in un'enciclopedia. Voglio trovare ogni riferimento alle dighe, al bacino idrografico e ad una vasta area di accumulo, generalmente creata dall'uomo. Andrò sul retro, lo troverò in un elenco alfabetico, ordinato, dalla A alla Z, da sinistra a destra, e troverò D. Troverò la parola "dighe" e posso vederlo su pagine 16, 38, 41 c'è un riferimento a loro, e poi posso andare a quelle pagine, posso scrutare i miei occhi e troverò il riferimento alla parola "diga". È essenzialmente lo stesso concetto in un database, ma ora è una scienza missilistica in molti modi. Al punto che tutti gli amministratori di database che ho imparato a conoscere bene considerano gli indici lo strumento più critico per l'ottimizzazione delle prestazioni in qualsiasi mondo di database, indipendentemente da quale sia la loro esperienza per quanto riguarda il lancio di informazioni, oppure qualunque sia il caso.
Generalmente quando parliamo di indicizzazione del database, ci sono una serie di approcci comuni. E più gli indici di database diventano complessi, più complesso è l'approccio all'indicizzazione dei dati. Ma essenzialmente quando pensi all'indicizzazione dei dati, immagina di avere un file con un elenco di nomi; non possono essere ordinati in ordine alfabetico. Immaginiamo che ce ne siano venti. Se eseguiremo l'ordinamento, se cercheremo i dati in quell'elenco, dall'alto verso il basso, e diciamo che è un elenco di nomi. Se scelgo un nome casuale e comincio a scorrere l'elenco, dall'alto verso il basso, in un formato lineare ed è un elenco non ordinato, ci sono due criteri che penso come il mio tempo medio di ricerca e il mio tempo massimo di ricerca - e Ho un errore di battitura nella seconda riga, dovrebbe essere "tempo di ricerca massimo", mi dispiace, ma il mio tempo di ricerca medio è essenzialmente N più uno, diviso per due, e cioè in media, mi impiega il cinquanta percento delle volte per eseguire la scansione dalla cima dell'elenco, alla fine dell'elenco per trovare qualsiasi cosa casuale in quell'elenco. E la seconda riga lì, sotto lineare, dovrebbe essere il "tempo di ricerca massimo". Ma il tempo di ricerca massimo è essenzialmente il numero di elementi, e cioè se ho un elenco di venti cose, che il maggior tempo possibile mi impiegherà cercare qualcosa in quel database significa andare dall'alto verso il basso, vale a dire 20 elementi in questo esempio semplificato. Ed è un processo molto lento e non c'è davvero modo di ottimizzarlo. E poi, ci sono altri tipi di modi per prendere quei dati e creare un indice, che in realtà è un breve elenco di puntatori a dove si trovano i dati reali, come binario, B-tree, bitmap, hashing, cluster e non cluster, e poi ci sono diversi tipi di dati come spaziali, filtrati, XML e full-text.
Il binario è molto usato per cose in cui i dati si prestano ad esso. B-tree è probabilmente il singolo più comune in senso generale, storicamente, in quanto è un modo comune per strutturare un indice su qualsiasi forma di dati e consente a logger, selezioni e inserimenti ed eliminazioni sono relativamente facili mentre si spostano i puntatori riferimento ai puntatori, i punti. Esistono altri tipi, come bitmap, in cui i tipi di dati riguardano come se avessimo un intervallo associato in qualche forma. L'hashing funziona molto bene con oggetti di grandi dimensioni, in particolare blog e immagini. E puoi vedere che esistono diversi tipi di approcci scientifici, approcci matematici, all'indicizzazione dei dati. Per i semplici mortali, sono una sfida interessante di cui parlare a questo livello. Quando ne parli a livello di prestazioni per un amministratore di database, diventano davvero uno scienziato missilistico e le persone si diplomano in loro, e so che il dottor Robin Bloor lo ha sicuramente fatto, e ha scritto libri su di esso per artisti del calibro di IBM e altri grandi marchi negli ultimi due decenni. E quindi, il - mio punto di vista, è che in realtà abbiamo passato un tempo in cui, sapete, una volta sarei stato in grado personalmente di sedermi di fronte a un sistema e sarei in grado di smontarlo e mostrarvi esattamente dove si trovavano i problemi di prestazioni a una riga di comando o in uno strumento di avvio dell'interfaccia utente grafica, e inizia ad approfondire i dati e a dirti dove erano i problemi, a costruire indici, o sottoindici o indici primari e secondari in quello dati e inizia a usarli per trovare cose. Ma quando pensi a quel panorama che ti ho mostrato, in cui abbiamo centinaia e centinaia di marchi, marche e modelli, produttori e tipi di database, ora siamo davvero passati, dove un essere umano può fare senso dei tipi di motori di database che abbiamo. In particolare, anche se torniamo a artisti del calibro di Oracle, i marchi predominanti in questi giorni nelle piattaforme di database relazionali.
Il numero di database con cui hanno a che fare sia da una piattaforma proprietaria come un ERP o HR o un sistema finanziario, o se sono una piattaforma casalinga per vari motivi, il numero di database e tabelle di database e record che finiamo affrontare è solo astronomico e fisicamente non puoi farlo a mano. E ora abbiamo avuto un'ulteriore complicazione, dove una volta un server di database poteva semplicemente sedere sotto la tua scrivania. Sai, da ragazzino dopo la scuola, andavo a lavorare su software di database su, originariamente, Apple IIes e poi sistemi basati su PC DOS, come dBase II, dBase III, attraversavano un'era con mainframe e mid- gamma e persino VAX e PDP e file di registro su quello. E simili a Sabre, e poi alla fine quando arrivarono alcuni database SQL. Ma in questi giorni quando pensiamo ai motori di database, sembrano l'angolo in basso a sinistra. Un server di database non è più solo una macchina seduta sul pavimento sotto una scrivania; sono centinaia di macchine che eseguono copie di motori di database e cluster, e scalano fino a centinaia e centinaia di terabyte di dati, se non petabyte di dati, che sono migliaia di terabyte. E anche all'estremo, come ha detto il dottor Robin Bloor, che alcuni casi d'uso specifici - compagnie aeree, agenzie governative in particolare - possono arrivare a exabyte. Sono ancora abbastanza di nicchia, ma centinaia di terabyte e persino dozzine di petabyte non sono più insoliti, in particolare dal boom delle dotcom fino ad ora, una specie di ciò che chiamiamo società web 2.0, artisti del calibro di Facebook, Google, Yahoo e così via.
Abbiamo anche la complicazione ora che le cose si stanno spostando verso un servizio esterno. Abbiamo una piattaforma di infrastruttura e software come approccio di servizio che fornisce infrastruttura. E in particolare il servizio di piattaforma in cui non possiamo acquistare solo per artisti del calibro di Oracle e la loro piattaforma cloud, database e server. E così questo ci permette di fare uno sviluppo molto rapido dell'applicazione e ricollegare un database ai server. Non dobbiamo pensare a cosa c'è sotto il cofano. Il rovescio della medaglia è che spesso non pensiamo a come progettiamo e implementiamo il database fino a quando non inizia a danneggiare e le prestazioni diventano un problema e quindi finiamo per cercare lo strumento giusto per diagnosticare perché il nostro database sta danneggiando e dove sono i problemi di prestazioni. E invariabilmente lo riporta a quel problema comune di come abbiamo indicizzato quei dati e i tipi di indici che abbiamo usato per quei dati e che poi ci riporta ai requisiti di prestazioni sovrumane. E qualcuno che ha accesso ai sistemi giusti e agli strumenti giusti per ottimizzare le prestazioni di quei motori e iniziare a trovare un punto di riferimento e guardare dove si trovano le query, dove si spostano i dati, i tipi di query, come sono strutturate le query, chi sta eseguendo le query e se le query vengono messe in coda e devono essere memorizzate nella cache. Quale replica cerchi?
E quindi stiamo bene e veramente - a mio avviso - in un momento in cui anche i migliori guru di database del mondo, essenzialmente i nostri architetti di database e il nostro amministratore di database e basi di prestazioni, a mio avviso hanno davvero bisogno di iniziare a sfruttare gli strumenti giusti per ottimizzare l'ottimizzazione dell'indice delle prestazioni per qualsiasi motore di database. Poiché la scala con cui abbiamo a che fare e la velocità con cui le cose si stanno muovendo, semplicemente non possiamo farlo a mano, e tentare di farlo invariabilmente può introdurre altri problemi di prestazioni, perché potremmo non avere esperienza in quello spazio che stiamo cercando di risolvere un problema. E credo che sia lì che stiamo per consegnare a Bert, e stiamo per parlare di come hanno risolto questo vario problema e il tipo di cose che il loro strumento può fare, in particolare per il mondo Oracle. E con quello lì, Bert, passerò a te.
Bert Scalzo: Grazie. Benvenuti a tutti, mi chiamo Bert Scalzo, lavoro per IDERA. Sono il senior product manager di alcuni dei nostri prodotti di database. Dimostrerò alcuni di quelli oggi. Ma voglio parlare degli indici, perché sono d'accordo con tutto ciò che tutti hanno detto qui, in particolare l'ultima diapositiva, che gli indici sono così complessi ora che hai bisogno di uno strumento e spero di convincerti. Quindi, la progettazione dell'indice Oracle non è così semplice come una volta. Molte persone non sono sicure di se stesse quando guardano le opzioni, e mi piace dire che mi sono ritirato dalla storia, "in queste materie, l'unica certezza, è che nulla è certo". Ed è così che al giorno d'oggi sentite gli indici, perché anche se pensate di conoscere la vostra risposta dovreste indicizzare X, Y o Z, in realtà non potete essere certi fino a quando non lo provate, perché quegli ottimizzatori a volte si comportano in modo diverso da come vi aspettate. E così c'è un sacco di tentativi ed errori con la progettazione dell'indice. Ai vecchi tempi, se avevi bisogno di un indice, in genere c'erano solo due domande o una domanda. Era unico o non era unico? E potresti aver pensato ad altre cose come "Quanti indici posso avere il massimo su una singola tabella?" Perché troppi indici rallentano inserimenti, aggiornamenti ed eliminazioni. Potresti anche essere stato nel tuo sistema di database, avere restrizioni su quante colonne potrebbero essere in un indice multi-colonna, perché a volte c'erano dei limiti basati sulla pagina o sulla dimensione del blocco del tuo motore di database, ma in realtà era piuttosto semplice indietro ai bei vecchi tempi. O l'hai indicizzata o no. E davvero, tutto era in un albero a B. Potremmo consentire i duplicati o no, e questo è tutto. La vita era bella, la vita era semplice.
Bene, oggi la vita non è così bella o così semplice. Ho messo il segno Ghostbuster rosso attraverso il modo in cui lo facevamo, perché ora abbiamo B-tree contro bitmap, contro bitmap join. E ho intenzione di spiegare quali sono alcuni di questi in un momento. Cluster e non cluster, univoci o duplicati, ordine in avanti o indietro, basato sulle funzioni, partizionato o non partizionato. Se è coinvolto il partizionamento, è un partizionamento globale o locale? Lo spiego anche io. E poi c'è anche qualcosa chiamato tabella organizzata indicizzata. E in realtà ce ne sono una mezza dozzina di altre che ho lasciato fuori di qui, perché penso di averne abbastanza qui ora che dovrebbe convincerti che gli indici sono molto più difficili di quanto tu possa aver pensato. In questa diapositiva particolare, inizierò nella parte in alto a sinistra del diagramma e ho una tabella. E la prima cosa che devo decidere è, a seconda della versione del database e del fornitore del database, consentono le tabelle degli oggetti o sono solo relazionali? Scenderò sul lato destro e dirò che stiamo costruendo un tavolo relazionale. Ora, la prossima domanda che mi devo porre è: è in un cluster? E molti di voi che hanno fatto Oracle per un po 'di tempo ricorderanno che i cluster erano tornati per Oracle 6 giorni. Probabilmente non sono più molto usati oggi, ma prima lasciami andare giù per quel ramo.
Se avessi messo la mia tabella in un cluster, avrei dovuto avere un indice cluster su quella tabella. Ora, in Oracle, quando hai raggruppato una tabella, in pratica stavi memorizzando le righe o le righe erano vicine l'una all'altra in cui i valori erano simili. Pertanto, è necessario disporre di un indice cluster e tale indice cluster potrebbe non essere partizionato. In altre parole, non c'erano davvero metodi di partizionamento per come si farebbe una tabella in cluster. Era rigorosamente non partizionato. E poiché non era partizionato, era globale. Spiegherò cosa è globale in un minuto. Ed era sempre B-tree. In altre parole, quando sono andato giù per quel ramo, era abbastanza semplice, non avevo molte scelte. Ora, se facevo un indice non cluster su una tabella cluster, che era consentito in alcune versioni, era di nuovo non partizionato; quando non è partizionato, l'unica scelta è globale. E così, lì hai la scelta di B-tree o bitmap. Ancora una volta, dipendeva dalla tua versione del database. Ma ora, torniamo al tavolo relazionale e ricominciamo a scendere dal lato destro e ora avremo solo un tavolo semplice, vecchio, regolare, colmo: relazionale. Si troverà nel tavolo. In un certo senso vado prima a destra qui. Quindi è organizzazione, mucchio. La prossima domanda che mi devo porre è: "Voglio partizionare questa tabella o no?" Ora, a volte lo partizioneresti perché pensavi: "Ehi, l'ottimizzatore sarà più intelligente su come può ottimizzare le query. "Ma molti DBA ti diranno che il motivo per cui lo fai è a fini amministrativi. Se hai una tabella da cento miliardi di righe, se la suddividi in partizioni o bucket, quando desideri aggiungere dati all'ultimo bucket, puoi eliminare e indicizzare solo pochi milioni di righe. È possibile inserire quei dati e quindi è possibile ricostruire quell'indice solo su quel bucket.
Sebbene fosse una buona tecnica per alcuni, tecniche di ottimizzazione come l'eliminazione delle partizioni, il suo vero valore era la capacità di amministrare o fare compiti amministrativi su pezzi più piccoli. Quando vado all'heap dell'organizzazione, la prima domanda era: "Ho partizionato o no?" Andiamo a sinistra, non ho intenzione di partizionare la tabella. Ora, può sembrare strano quando te lo dico, ma potresti avere una tabella non partizionata e quindi non puoi partizionare l'indice come sei abituato, oppure puoi partizionare l'indice. Fermati e pensa. Il tuo tavolo ha sostanzialmente un bucket, come hai sempre pensato, eppure il tuo indice avrà più bucket. Quando ciò accade, dove esiste una discrepanza tra il numero di bucket e la tabella e il numero di bucket nell'indice, ecco cosa si intende per globale. Quindi, se la tabella non è partizionata, e se l'indice è partizionato, è considerato globale, perché non c'è corrispondenza. Ora, lasciami risalire sull'heap della mia organizzazione e scendi invece sul lato della partizione. Ora, se ho una tabella delle partizioni e diciamo che la tabella ha quattro bucket, quattro partizioni, il mio indice potrebbe avere quattro bucket in modo che il mio indice corrisponda al design della mia tabella. E così è finita, molto più in là, sul lato destro. Sarebbe considerato locale. Un indice locale significa sostanzialmente che il partizionamento della tabella e dell'indice è fatto allo stesso modo e ha lo stesso numero di bucket. E poi, una volta che ho l'indice locale, potrebbe essere un albero B o una bitmap e quella freccia verde che sale, mostra che anche se si tratta di un albero B, ci sono ancora delle scelte che potrebbero essere fatte. Potrebbe essere basato sulle funzioni. Inoltre, se si tratta di una bitmap, esistono diversi tipi di bitmap. C'è qualcosa chiamato un indice di join bitmap. Se stai eseguendo il data warehousing, questo è un tipo di indice molto popolare per lo schema a stella o il design. Quello che succede è che l'indice ha gli ID di riga per ciò a cui punta nella tabella, ma avrà anche gli ID di riga per le tabelle principali in modo che quando sei - devi iniziare a progettare lo schema e stai cercando in una tabella dei fatti, quell'indice nella tabella dei fatti ti punta ai dati che ti interessano e ti indirizza a ogni riga nelle tue dimensioni, in modo da avere un solo indice.
E in realtà, questo è nato grazie a Red Brick, che era un database molti anni fa - molte persone potrebbero ricordarlo. E quindi, se guardi questa immagine - e tieni presente che non ho messo tutto in questa immagine perché l'immagine sarebbe molto più grande - ci sono ancora problemi aggiuntivi, che ho nel testo qui nella parte in alto a destra . È un indice di ordine inverso? E potresti dire: “Perché dovrei desiderare un indice di ordine inverso? Non ha alcun senso. ”Beh, se ti trovi in un ambiente cluster in Oracle, se stai realizzando cluster di applicazioni reali, se mantieni i tuoi indici in ordine, quindi non invertiti, se hai un sacco di elaborazione che sta colpendo gli stessi valori o gli stessi valori di indice, ciò che accadrebbe è che avresti aree calde del tuo albero a B. Significa che avresti contese e possibilmente il blocco per provare ad accedere a quella roba e lo faresti attraverso i nodi in una rete. Bene, se inserisci un indice di ordine inverso, ora puoi annullarlo. Puoi dire: "Beh, i valori simili si trovano in diverse parti degli alberi, quindi non ho i miei nodi separati in competizione per le aree calde dell'albero". E poi noti anche che unico non funziona con alcune delle opzioni . Se guardi, ho numerato tre, cinque, otto e undici, quindi ci sono alcuni casi in cui non posso avere un indice univoco. Allo stesso modo, ci sono alcuni casi in cui non posso avere un indice inverso, e poi ci sono ulteriori problemi come la registrazione o nessuna registrazione, e parallela e non parallela. Posso assegnare cose a un'area specifica in memoria.
E questo lascia ancora un bel po 'di funzionalità in Oracle. Direi che quando guardi Oracle 12, probabilmente ci sono ancora circa un'altra mezza dozzina di cose che potrei aggiungere a questa immagine. L'indicizzazione è davvero complessa e sono davvero d'accordo con l'oratore precedente, per navigare attraverso questo e fare una buona scelta, hai bisogno di uno strumento. Forse hai bisogno di un'immagine come questa e di una sorta di metodologia su come sceglieresti le cose e speriamo che lo strumento ti aiuti ad arrivarci. E poi saranno tentativi ed errori. Dico sempre alle persone in fase di indicizzazione: "guarda prima di saltare." E poi puoi vedere il cagnolino qui, sta saltando senza guardare, finirà in acqua con lo squalo o il ragazzo si prepara a saltare in acqua e si impala. Devi pensare alla tua indicizzazione, perché la creazione di un indice non significa sempre che le cose migliorino. In effetti, la creazione di un indice può rallentare le cose. E le prestazioni delle query possono essere un ordine di grandezza migliore con una scelta piuttosto che un'altra. E ti darò un buon esempio. Se stai eseguendo uno schema a stella di progettazione e nelle tabelle delle dimensioni utilizzi gli indici bitmap in un caso e in un altro caso dici "Userò gli indici B-tree", avrai bitmap contro B- albero. Posso dirti che una soluzione sarà un ordine di grandezza o forse più ordini di grandezza più veloce dell'altra. Ma tieni presente ciò che funziona in un ambiente, come in un ambiente di data warehousing, probabilmente non è una buona scelta in un ambiente OLTP.
Ad esempio, se si dovesse prendere una tabella transazionale e inserire indici bitmap in una tabella transazionale, è costoso calcolare e ripristinare bitmap, queste stringhe lunghe, e quindi in una tabella OLTP, è possibile colpire la tabella così pesantemente che la bitmap L'indice può diventare corrotto e rallentare il sistema perché non sono pensati per gli aggiornamenti. Sono ottimi per un accesso veloce, ma non sono buoni per gli aggiornamenti. Penso che l'indice richieda tentativi ed errori. Non c'è davvero più una regola d'oro - ci sono troppe variabili diverse in questa equazione per sapere - e alla fine dovrai guardare l'esecuzione o spiegare i piani nel tuo database per vedere se stai facendo o meno buone selezioni. E a volte, l'analisi del piano può quasi essere una scienza a sé stante. Oggi non lo tratterò - questo è un altro argomento - ma non dare per scontato la progettazione dell'indice. Ci sono motivi legittimi per cui ci sono tutti questi tipi di indici pazzi che ti ho mostrato, nella figura precedente, e di cui parlava l'oratore precedente. Questi non sono stati creati solo perché era una caratteristica accurata mettere su una lista di controllo da qualche parte per un fornitore di database; ci sono casi d'uso o scenari in cui questi indici sono importanti e faranno una differenza significativa. Ora, con questo, ti mostrerò alcuni esempi di diversi tipi di indici in uno dei nostri strumenti. Fammi solo alzare lo schermo in modo che tu possa vederlo. Okay, quindi eccomi qui dentro - fammi minimizzare questa applicazione. Sono seduto all'interno del VMware e sto eseguendo una VM Windows Server 2012.
E puoi vedere, ho quasi tutti gli strumenti conosciuti dall'uomo. Come product manager, devo stare attento alla mia concorrenza, quindi non sono solo gli strumenti che ho, ma cosa fanno i miei concorrenti? E qui abbiamo questo strumento chiamato DBArtisan, che ho già avviato, ma lo farò - quindi lo farò apparire. E quello che puoi vedere è che questo è uno strumento davvero interessante, perché invece di doverlo usare, dire un gestore aziendale per Oracle e un SQL Management Studio per SQL Server, MySQL Workbench per MySQL e altri dodici database che supportiamo, bene ho tutti i miei database integrati in questo unico strumento. C'è DB2, c'è MySQL, Oracle, Postgres, SQL Server e Sybase, e questo è - ho solo sei database in questa cosa particolare perché non posso - lo strumento supporta dodici database ma la mia povera VM, eseguendo sei database contemporaneamente e provando fare una demo, è tutto ciò che il mio hardware faciliterà. Quindi fammi tornare su Oracle ora e, se noti, tutte queste cose sono uguali. Se voglio misurare le mie prestazioni in DB2, sono le stesse scelte che avrei fatto in Oracle. Ora sotto le copertine facciamo un sacco di cose diverse, quindi non devi sapere cosa sta succedendo, ma ti diamo un'interfaccia coerente in modo da poter essere un esperto con più piattaforme di database. E ciò includerebbe il lavoro con gli indici, l'argomento di questa discussione.
Fammi entrare qui e per prima cosa guardo alcune tabelle, e ho un database di film che ha solo alcune tabelle. E se guardo una tabella particolare, come la tabella dei clienti, quando la visualizzo qui, posso vedere il mio design della tabella, ecco le mie colonne nella mia tabella ed ecco le informazioni su ogni colonna. Ho proprietà per la tabella, ma nota che ho una scheda qui per gli indici e posso vedere qui ci sono gli indici sulla tabella. Si noti che uno di questi indici è il mio indice PK, la mia chiave primaria. Questi altri sembrano essere solo indici per migliorare l'accesso alle query, forse eseguiamo query per nome o cognome, oppure guardiamo telefoni e codici postali. E se scelgo un indice particolare, come questo codice postale qui, e faccio doppio clic su di esso, ora posso vedere che, ehi, è un indice non univoco e qui ci sono alcuni altri tipi, bitmap, non univoci, univoco, indipendentemente dal fatto che sia ordinato o meno, tale registrazione, indipendentemente dal fatto che sia o meno in ordine inverso, indipendentemente dal fatto che sia una base di funzioni. Oh, eccone uno divertente che non ho trattato. Puoi effettivamente avere indici invisibili. E diresti: "Beh, perché diamine dovrei fare un indice invisibile?" Bene, ti darò un buon esempio. Sei nel tuo sistema di produzione e hai un problema di prestazioni e non sei sicuro che la creazione dell'indice risolva il problema, quindi non vuoi creare l'indice e rallentare la produzione, ma in un modo o nell'altro vuoi essere in grado di testarlo. È possibile creare l'indice in produzione come invisibile, il che significa che non molti codici applicativi, chiamando l'ottimizzatore, utilizzeranno tale indice. È stato creato, è valido, ma non verrà utilizzato. Quindi puoi rispondere a una domanda che ritieni possa essere utile per questo indice o una serie di query e puoi inserire un suggerimento e dire: "Ehi, ottimizzatore, c'è un indice invisibile là fuori che voglio che tu usi e permetta io so se ho migliorato le cose. ”E ora ho testato qualcosa in produzione, ma non ho rotto le applicazioni in produzione che erano in esecuzione. Questo è l'uso di un indice invisibile. Sembra stupido quando ne senti parlare per la prima volta, ma è utile.
Possiamo anche, sugli indici, definire se sono paralleli e anche quante istanze sono parallele. Ora, in un ambiente di cluster di applicazioni non cluster o non reale, quindi non rack, parallelo significherebbe quanti sottoprocessi può portare la mia query a provare e processi di lavoro per provare a ottenere le cose più velocemente o più velocemente . E le istanze parallele sarebbero, se mi trovo in un vero cluster di applicazioni, dire che ho dieci nodi, quanti nodi sono autorizzati a suddividere il lavoro? Forse sono quattro dei dieci e su ciascuno di essi quattro sottoprocessi. Questo è un esempio. E poi abbiamo la compressione delle chiavi. Puoi effettivamente comprimere gli indici? Si o no. E poi ovviamente hai i tuoi parametri di archiviazione che puoi specificare sugli indici. Ora, non li ho trattati perché sono davvero più un parametro di archiviazione che un problema di indice. E infine, abbiamo se rendere o meno partizionate queste partizioni. Lasciami lasciarlo qui per un secondo. Vado a uno schema diverso. Questo è uno schema a stella e, ad esempio, questa tabella dei periodi è una tabella delle dimensioni. Se hai mai eseguito la progettazione dello schema a stella, in genere hai una dimensione temporale e quindi in questo database e in questo schema a stella, punto è una dimensione temporale. Ora, so che sembrerà divertente, dirai: "Accidenti, guarda tutte quelle colonne - il ragazzo ha mai sentito parlare di normalizzazione?" Bene, quando sei in un data warehouse o in uno schema a stelle, tu in genere non ci sono tabelle che una persona normale guarderebbe e dire: "Accidenti, queste non sono molto ben progettate". Ma è così che lo fai in un ambiente di data warehousing.
Ora guarda cosa succederà perché, okay, ci sono tutte queste colonne, guarda che ho un indice su ogni singola colonna. Ora, in un ambiente OLTP sarebbe un no-no. Rallenterebbe tutte le mie operazioni. In un ambiente di data warehousing, li lascerei cadere durante i miei cicli di caricamento batch. Carica senza l'overhead o gli indici e ricrea gli indici. E se partizionassi la mia tabella, invece di dover eliminare l'indice per ogni bucket nella tabella, potrei semplicemente rilasciare l'indice sul bucket o sui bucket in cui i dati sarebbero stati inseriti durante quel ciclo di caricamento batch. E poi ricrea solo la parte dell'indice per quei secchi. E questo lo rende molto gestibile. E se guardo - quindi ecco una colonna chiamata "Bandiera delle festività" e fondamentalmente si tratta di un sì o no. Si noti che questo è un indice bitmap e per la maggior parte di voi dirà: "Beh, ha senso." Sì o no, Y o N, ci sono solo due valori che hanno senso. E perché quando leggi la documentazione per gli indici bitmap, ti dicono sempre di scegliere qualcosa con cardinalità bassa.
Ora lasciami entrare in una delle mie tabelle dei fatti, quindi qui abbiamo i miei ordini. E questi sono i miei ordini al giorno. E ora vedrai che ho ancora alcune colonne e ancora, avrò più di qualche indice. E proprio qui, abbiamo qualcosa chiamato il codice dei prezzi universale. Questo era per un negozio al dettaglio, quindi conosci quei piccoli codici a barre quando acquisti qualcosa nel negozio, questo è il codice prezzo universale. Ora, ci sono milioni di codici di prezzo universali. Ora, per questa particolare azienda che vendeva roba, avevano probabilmente da 1, 7 a 2 milioni di codici di prezzo universali, quindi ti aspetteresti che questo non sarà un indice bitmap perché 1, 7 milioni di valori distinti sembrano alta cardinalità. Ma in realtà, in un ambiente di data warehousing, vuoi che sia una bitmap. Ora, lasciami spiegare perché. Bene, ci possono essere 1, 7 milioni di valori distinti per questo codice di prezzo universale, il numero di righe in questa tabella di ordine è compreso tra centinaia di milioni e miliardi di righe. Il mio indice è cardinalità bassa rispetto alla dimensione o cardinalità della tabella. Ciò lo rende cardinalità bassa. Ciò rende utile l'indice bitmap, anche se è controintuitivo con 1, 7 milioni di valori distinti che qui sceglieresti bitmap. Ora, se sapessi che volevo usare un indice di join bitmap, attualmente il prodotto non lo supporta, lo sto aggiungendo per la prossima versione, ma sarebbe un'altra alternativa qui. E in uno schema a stella, ricorda, l'indice bitmap si troverebbe nella tabella dei fatti e che un indice nell'albero B puntava alla riga nella tabella dei fatti e quindi a ogni riga che era evidente nella tabella delle dimensioni per quel fatto . E così, hai un'altra opzione lì. E quindi, vediamo, voglio uscire dai tavoli ora e voglio solo mostrarti rapidamente che ho le stesse informazioni, sotto gli indici, e ho intenzione di fare la stessa cosa di base.
Ora, il motivo per cui l'ho menzionato è che potresti notare, ehi non ci sono chiavi primarie qui. Le chiavi primarie vengono eseguite con un vincolo chiave, quindi sono effettivamente coperte dalle definizioni del vincolo. Questi sarebbero indici che non fanno parte del vincolo. Ora potresti dire: "Beh, aspetta un minuto, potrebbe sembrare una chiave esterna e una chiave esterna è un vincolo", ma le chiavi esterne e la maggior parte dei database non creano automaticamente un indice sulla colonna chiave esterna, anche se è consigliabile e il gioco è fatto: ho di nuovo tutte le stesse scelte. E se voglio cambiare solo per essere compresso, posso farlo.
Ora la compressione funziona solo su un indice B-tree. Ciò che consente è che, quando si osservano i vari nodi nella struttura ad albero B, consente la compressione di alcuni dei valori. In realtà non è la compressione come la compressione della tabella, è una compressione di ciò che è memorizzato nell'albero B nei nodi non foglia. Non risparmia un sacco di spazio, ma può fare la differenza. E con ciò l'ho notato, mi sto avvicinando molto al tempo, quindi quello che voglio fare è, voglio tornare indietro e interrompere la mia condivisione. E abbiamo il nostro prodotto disponibile per una prova di quattordici giorni su idera.com. È un prodotto abbastanza buono, specialmente se lavori con più piattaforme di database. Se lavori con due o tre database diversi, questo strumento ti renderà la vita molto più semplice. Disponiamo di strumenti per aiutarti con la progettazione e la selezione dell'indice, abbiamo uno strumento chiamato DB Optimizer. Non potrei proprio coprirlo oggi, sarebbe troppo. E se vuoi contattarmi, c'è il mio indirizzo e-mail, è, o puoi trovarmi nella mia e-mail privata, e ho dei blog, ho un sito Web e blog e un profilo LinkedIn lì. Quindi sentiti libero di contattarmi su qualsiasi cosa, anche se non è correlata al prodotto, se vuoi solo parlare di database, sono un fanatico del cuore e adoro parlarmi di tecnobabble.
Eric Kavanagh: Va bene, beh Dez, Robin, sono sicuro che almeno hai un paio di domande, ci restano pochi minuti qui. Dez, che ne pensi?
Dez Blanchfield: Ho una grande domanda che devo farti, è stato in fondo alla mia mente. Qual è lo scenario più folle che hai visto? Ho letto il tuo blog, ti seguo da vicino, il - tu sei, probabilmente sei una delle poche persone che ha vissuto in quasi ogni improbabile, e penso che il Dr. Robin Bloor sia il secondo in cui ho incontrato la mia vita. Ma, sai, probabilmente hai visto tutti gli scenari pazzi, quali sono alcuni degli scenari più folli che hai visto, che ti sei imbattuto e, come gli esseri umani che non sono riusciti a farcela, sei riuscito a camminare ed eseguire trucchi mentali Jedi con tutto questo DBArtisan?
Bert Scalzo: Una volta avevamo un cliente che, nella progettazione del suo database, pensava molto al modo in cui avrebbe pensato in una progettazione del layout dei file, e così, quando normalizzi un database, la prima cosa che provi a fare è liberarti di gruppi ripetuti. Bene, avevano una colonna e l'hanno resa lunga, o BLOB o CLOB, e in essa avrebbero messo valore, numero uno, punto e virgola, valore numero due, punto e virgola, numero valore, punto e virgola e avrebbero migliaia di valori lì dentro, ma avevano bisogno di cercare su quella colonna e dicevano: "Perché questa cosa funziona così lentamente?" E io sono tipo, "Beh, non puoi creare un indice su quello che hai fatto, è solo non è permesso. ”Quindi abbiamo effettivamente mostrato loro, usando i piani, che ciò che dovevano fare era normalizzare quella tabella. Non perché la normalizzazione sia un esercizio accademico che rende le cose migliori, ma perché volevano una query su quel campo, il che significava che volevano essere in grado di indicizzarlo, e non si poteva indicizzarlo su un gruppo ricorrente, o almeno non facilmente . E quindi questa è probabilmente la cosa peggiore che abbia mai visto.
Dez Blanchfield: Sì, è interessante quante volte ti imbatti, penso alla sfida con i database, la gente dimentica che è una scienza. E ci sono persone che fanno lauree e dottorati di ricerca in questo intero spazio, scrivono articoli su di esso e hai scritto un intero malloppo tra cui i tuoi manuali TOAD e altre cose dalla memoria. La tendenza verso una sorta di "big data" quotazione su quotazione ora - vedo molte persone che dimenticano i fondamenti dell'architettura del database e della tecnologia del database, scienza del database, se vuoi. Che cosa stai vedendo sul campo per quanto riguarda il passaggio dalle piattaforme di database tradizionali e dal database tradizionale pensando che abbiamo effettivamente inchiodato al suolo, ed è stato solo un caso di ottimizzazione e ridimensionamento delle prestazioni. Stai vedendo molte persone riapprendere e avere un'esperienza in cui siedono semplicemente lì e hanno un momento "a-ha", come un momento di eureka, in cui si rendono conto che questa roba sui big data è in realtà solo una specie di database davvero grandi? È una cosa là fuori e la gente ti sta rispondendo in un modo o nell'altro, "Abbiamo dimenticato, quello che sapevamo e puoi riportarci dal lato oscuro?"
Bert Scalzo: Beh, no, e questo è orribile da ammettere, ma i venditori di database relazionali hanno bevuto anche quel Kool-Aid. Se ricordi, non lo so, circa un decennio fa, abbiamo iniziato a inserire dati non strutturati in database relazionali, che era una specie di cosa strana da fare, e quindi i dati, i database relazionali, ora stanno aggiungendo il tipo NoSQL cose. In effetti, in Oracle 12, CR2 - so che non è ancora uscito - ma se guardi la beta, se sei nel programma beta, supporta lo sharding. E così, ora hai un database relazionale a cui non è stato aggiunto il concetto dallo sharding NoSQL. E così, il momento "a-ha" sembra essere più per le persone del lato relazionale che stanno andando "a-ha". Nessuno lo farà mai più, nemmeno i gestori del database, quindi abbiamo devo andare oltre e unirmi al lato oscuro.
Dez Blanchfield: Giusto, quindi stai dicendo un passaggio a molti dei dati disordinati, se ho capito bene, venendo inserito in quello che ora chiamiamo piattaforme di big data, il che è abbastanza divertente, perché sono non così vecchio, ma non significa che si stanno concentrando su quello che stanno facendo con il loro database relazionale per ottenere più soldi per il loro dollaro?
Bert Scalzo: No, di solito, se avessero bisogno di - sarebbe stato citato un "bisogno di tipo big data", stanno scoprendo che invece di dover andare sull'altra piattaforma di database e fare qualcosa in un non in modo relazionale, i fornitori di database ora stanno offrendo loro le stesse tecniche non relazionali all'interno del loro database relazionale, per fare queste cose. Voglio dire, un buon esempio sarebbe, se si hanno dati non strutturati, come un tipo di dati JSON o qualche altro tipo di dati complesso che ha significato incorporato nei dati stessi, i fornitori di database non solo lo supportano, ma ti daranno ACID conformità su dati non strutturati. I database relazionali hanno abbracciato le più recenti tecniche e tecnologie e quindi, di nuovo, gli "a-ha" sembrano essere più che "Ehi, gli sviluppatori di applicazioni, abbiamo disimparato qualcosa e dobbiamo imparare di nuovo", è "Ehi, lo facciamo in questo modo ora, come posso farlo in quel modo nel tuo database tradizionalmente relazionale e farlo come faccio io in questo database qui? ”e questo sta diventando sempre più diffuso e, come ho detto, i fornitori di database stessi stanno abilitando quello.
Dez Blanchfield: Giusto, chi sono i sospetti tradizionali in questo spazio per lo strumento DBArtisan e quello? Ho fatto alcuni compiti su quello che hai scritto di recente, e dalla memoria hai scritto qualcosa, penso che fosse uno dei tuoi blog, sulle prestazioni estreme del database nel mondo Oracle. Non riesco a ricordare quando fosse, penso che sia stato qualche anno dalla memoria, o dalla fine dell'anno scorso, hai scritto questa cosa. E mi è sembrato che fosse il tradizionale, solito sospetto per il tipo di argomento di cui stiamo parlando oggi, in cui le persone andranno in un ambiente di database su larga scala e cercheranno ciò che in questo caso si sta guadagnando in modo estremo. Chi sono i soliti sospetti che stai vedendo là fuori che stanno prendendo DBArtisan e lo stanno mettendo a frutto?
Bert Scalzo: Bene, abbiamo molti clienti, infatti, oggi stavo lavorando con un'agenzia governativa molto grande che - e hanno letteralmente probabilmente quasi 1.000 copie del nostro software, perché consente alle persone di concentrarsi su ciò che ' stai facendo, e non come farlo. Ed è ok, voglio dire, tutti dovrebbero sapere come fare qualcosa, ma la produttività sta ottenendo il "che cosa" fatto. Se l'azienda mi chiede di svolgere un'attività, è tutto ciò a cui sono interessati. Quando ho ricevuto un segno di spunta per dire quando l'attività è stata eseguita? Non quale tecnica o quale technobabble ho usato per arrivarci. E così, il nostro strumento consente loro di concentrarsi sul cosa e li rende molto più produttivi, e questo è davvero l'enorme vantaggio, e come ho detto, alcuni database offrono uno strumento solo per la loro piattaforma di database. Lo offriamo per dodici piattaforme di database. Ho lo stesso flusso di lavoro, la stessa interfaccia utente grafica, le stesse navigazioni. Se sai come concedere un privilegio a un utente o come creare una tabella o creare un indice in un database, puoi farlo in tutti e dodici perché ha lo stesso aspetto grafico e lo stesso flusso di lavoro. Questo ha un valore enorme per i nostri clienti.
Dez Blanchfield: Sì, immagino, le persone vogliono ottenere molto di più per il loro denaro dalle loro risorse umane. E i giorni in cui un singolo specialista in Oracle, Ingres e DB2 sono passati. Ci si aspetta che la gente sia il tuttofare, quindi penso che questa cosa abbia assolutamente salvato la vita.
Solo un'ultima cosa veloce prima di consegnarla al dottor Robin Bloor. Hai detto che c'è un download gratuito per quattordici giorni, cosa succede - se ho intenzione di andare avanti e lo farò, comunque, lo inserirò nel laboratorio tecnologico di Bloor e farò girare questa cosa e metterci le mani da solo - non avevo avuto la possibilità di farlo prima di oggi. Hai menzionato una prova di quattordici giorni, hai detto che la stai eseguendo su una VM sul tuo computer, presumo sia un laptop. Cosa sono, qual è la configurazione entry-level per qualcuno su cui mettere le mani e usare l'aspetto della prova di quattordici giorni, appena prima di restituire Robin alle sue domande?
Bert Scalzo: qualsiasi ambiente Windows, quindi Windows 7, macchina virtuale con una CPU e quattro GB di memoria. Non siamo uno strumento veramente grasso o costoso. Ora, se si desidera eseguire il proprio server di database su quella stessa VM in quella stessa Windows, sì, è necessario aggiungerne altri, ma se si esegue il database su un server di database o su una VM separata, la VM da caricare e eseguire il nostro prodotto è molto leggero: una CPU, quattro GB di memoria, praticamente qualsiasi versione di Windows - e supportiamo installazioni sia a trenta-due che a sessantaquattro bit. Ma devi installare il client del tuo fornitore di database. Quindi, se si desidera connettersi a Oracle, è necessario installare il client di rete SQL, perché è quello che Oracle richiede per poter parlare con un database.
Dez Blanchfield: sembra abbastanza semplice. Penso che una cosa, più di ogni altra cosa, che spero che la gente porti via, a parte la consapevolezza che questo strumento salverà la propria vita, è che dovrebbero andare a scaricarlo e giocarci, dato che stai offrendo una prova gratuita di quattordici giorni. E può funzionare sul loro attuale laptop senza installare nulla in più, perché se stanno già facendo l'amministrazione del database, stanno già lavorando con i database hanno tutti quegli strumenti sul posto e se è in esecuzione su una VM locale o sul loro desktop locale, sembra indolore da installare e con cui giocare. Quindi consiglio vivamente alle persone di farlo.
Robin, sono sicuro che hai domande ed Eric, probabilmente ne hai alcune dal pubblico, quindi Robin, che ne dici di passare da te, e poi di nuovo da Eric?
Robin Bloor: Sì, okay, beh, ho delle cose da dire, voglio dire, ho sempre trovato questa zona affascinante perché era - ci ho tagliato i denti. Ma la verità è che, probabilmente dal 1998, 1999, sono stato alla deriva di ciò che Oracle è effettivamente capace. E conoscevo Sybase e Microsoft SQL Server, entrambi abbastanza semplici rispetto a ciò che Oracle poteva fare. Mi hai fatto ridere quando … Voglio dire, mi sono coperto la bocca, quando hai iniziato a parlare di sharding. Oracle l'ha fatto prima. Oracle ha introdotto ad un certo punto nel tempo, si sono innervositi dell'idea relazionale con gli oggetti, quindi hanno introdotto la possibilità di creare una sorta di notazione e archiviazione degli oggetti in Oracle, e ho parlato con uno dei loro ingegneri, qualcosa come un paio di anni dopo l'hanno introdotto e ho chiesto quante persone lo usavano, e lui ha detto che penso che due clienti lo avessero provato e basta. E penso che accadrà la stessa cosa se inizieranno a provare e fare cose NoSQL di tendenza. Sai, penso che sia un errore, voglio dire, sono un po 'interessato a quali sono i tuoi pensieri. Certamente, bevono il Kool-Aid. Si sentono come se dovessero essere in grado di fare affermazioni simili ai grandi database NoSQL come Cassandra, ma sai, ha senso per te?
Bert Scalzo: No, hai colpito l'unghia proprio sulla testa. Per me, se avessi intenzione di fare relazionale, sceglierei un fornitore relazionale come un Oracle o un SQL Server o un DB2 o un Postgres, ma se ho intenzione di fare qualcosa che non è relazionale, nello spazio dei big data, o nello spazio NoSQL, sceglierò lo strumento giusto per il lavoro giusto. E non penso che sarebbe naturalmente prima il mio fornitore di database relazionale. E poi, aggiungi l'altra ruga ad essa, che è, cosa è disponibile nel cloud? Così tante persone che vogliono ottenere i loro database fuori premessa. Quindi devi guardare il tuo provider cloud e dire: "Okay, che cosa provider, quali database hai a disposizione per me che si adattano alle mie esigenze e quanto sono vendibili, e francamente qual è la tariffa o il costo per l'utilizzo di quel database nel cloud all'ora o al giorno. E per gigabyte o terabyte? ”E quello che troverai sono forse alcuni dei database relativamente più recenti come Mongo o Cassandra, forse le loro tariffe sono più economiche, quindi se hai intenzione di fare big data a più petabyte, potresti devono - solo dal punto di vista dei costi - prendere in considerazione i database NoSQL nel cloud perché potrebbero essere il modo più conveniente per farlo.
Robin Bloor: Sì, giusto. Voglio dire, il mio tipo di - la cosa sui database relazionali nella mia esperienza - che è abbastanza lungo da avere cicatrici, questo è certo - c'è molto buonsenso che se inizi ad applicarlo e - capisci cosa sia realmente relazionale, che Voglio dire, ricordo di aver fatto una consulenza con un cliente una volta, e mi hanno condotto in una stanza e avevano fatto una sorta di diagramma di entità e creato una terza forma normale, un modello di come erano i sistemi primari dell'azienda. Aveva circa duecentoquaranta tavoli e dissero: “Bene, che ne pensi? Costruiremo un database per questo ”, e ho detto“ Cosa ne pensi? ”Dissi:“ Non penso che funzionerà ”. Ed è esattamente giusto, sai, perché stavano finendo verso l'alto per creare una struttura particolare all'interno di unioni a undici vie. E questa è la cosa da capire sulla relazione. Quindi sono un po 'interessato in termini di cattiva progettazione che incontri. Voglio dire, non ho alcun problema con DBArtisan - sta facendo cose molto sensate e il fatto che tu possa effettivamente mostrarti su più piattaforme, penso, sia meraviglioso - ma quanto incontri là fuori dove il design è problematico dove le persone avrebbero potuto risolversi ogni sorta di angoscia se fossero scese a uno schema a stella piuttosto che ottenere un fiocco di neve a riguardo, sai?
Bert Scalzo: Beh, non voglio sembrare presuntuoso o arrogante, ma direi più spesso. Chiaramente, la maggior parte dei database con cui sono coinvolto, hanno problemi o problemi. Il che è positivo, perché i nostri strumenti, come il nostro strumento di ottimizzazione del database, possono aiutarli a risolvere questi problemi e, ma ciò che è davvero divertente per me, è che molti di questi problemi sono sempre gli stessi semplici problemi. L'altro giorno stavo solo lavorando con un cliente che ha avuto una query di join a undici direzioni e mi chiedo "Okay, perché non hai usato una clausola with?" E loro dicevano "Beh, non l'ho fatto non so cosa sia. "E poi ho detto:" E guarda i tuoi sotto-selettori qui sul tuo correlato e non correlato ", ho detto, " In alcuni casi hai nella tua clausola where al livello più profondo, un riferimento alla tabella dall'esterno ". Dissi:" Cioè, spostalo al livello giusto, non incorporarlo più in profondità di quanto deve essere, confonderai l'ottimizzatore ". E con un paio di modifiche abbiamo ci sono voluti qualcosa che stava funzionando per circa due ore e l'ho ridotto a dieci minuti ed è stato solo - in quel caso non abbiamo fatto altro che migliorare l'SQL che avevano scritto. Penso che il problema sia che molte università e molte persone che imparano la programmazione in un ambiente non accademico, lo imparano come processi a tempo registrato o processo orientato alle righe e relazionale è un insieme orientato dalla natura, e quindi tu pensare in set per scrivere un buon SQL.
Robin Bloor: Sì, penso che sia esattamente giusto. E devi capire, è cose del genere, le persone dovrebbero conoscere l'ABC di cose come questa. Non importa Non sarai in grado di fare cose razionali se non ti rendi conto che anche un database ben progettato e ben modellato, i join richiederanno tempo, una sorta di tempo richiederà. Lo fanno perché il mondo non ha mai trovato un modo per farli andare veloci. Hanno trovato il modo di organizzare i dati in modo che vadano più veloci degli altri, e gran parte dell'entusiasmo che devo dire per i database NoSQL è semplicemente che stanno evitando di fare join. Cominciano semplicemente a costruire i database con la stessa diffusione di dati, perché se ti unisci a uno dei database NoSQL fanno schifo potentemente. Non pensi?
Bert Scalzo: Oh assolutamente. E devo ridere perché, ho iniziato molto prima dei database relazionali e quando Ingres era RTI, Relational Technology Institute, e non avevamo SQL, avevamo linguaggi relazionali pre-SQL. Penso che in Ingres, allora, si chiamasse Quel. Quindi hai ottenuto da questi vecchi paradigmi di database come la rete e un superiore grafico, o gerarchico, e attraversi i paradigmi relazionali dopo un paio di decenni e ora per me sembra che stiamo tornando a quasi un nuovo gerarchico. È quasi come se fossimo tornati.
Robin Bloor: Sì, giusto. Meglio che ti dia ad Eric, sto consumando troppo tempo, ma abbiamo qualche domanda da parte del pubblico, Eric?
Eric Kavanagh: Sì, ne abbiamo alcuni. Stiamo andando un po 'lungo qui, ma te ne lancerò un paio. Avevamo un paio di domande sugli indici invisibili. Una domanda era: "Qualcuno deve usare il tuo strumento per vederli?" Un'altra domanda era: "Beh, cosa succede se sei cieco?"
Bert Scalzo: È una buona idea.
Eric Kavanagh: anche una domanda curiosa, quindi solo FYI.
Bert Scalzo: No, non devi avere i nostri strumenti. Questa è una funzione Oracle, l'indice invisibile. Fondamentalmente nel dizionario dei dati, Oracle mantiene solo un pezzo di metadati che dice: "Ottimizzatore, ignora questo indice. È qui, ma a meno che non sia fisicamente istruito tramite un suggerimento in, un suggerimento di ottimizzazione nel comando SQL, non utilizzarlo. ”E quindi, no, non devi avere i nostri strumenti, e sotto tutti gli aspetti esso è un semplice vecchio indice, puoi vederlo in qualsiasi strumento, è solo l'ottimizzatore a dire: "Lo ignoreremo nella normale elaborazione delle query". Devi dirigerlo se vuoi che venga utilizzato. È davvero utile per lo scenario che ho descritto, ovvero se si voleva creare un indice in produzione ma non rischiare di rompere i report o le cose che sono già in esecuzione, ma si voleva testarli, è possibile farlo. Questo è ciò per cui è più utile.
Eric Kavanagh: Questa è roba buona e poi c'era un'altra buona domanda qui. “Che dire di alcuni di questi nuovi database in memoria? In che modo la tecnologia del database in memoria cambia il gioco rispetto all'indicizzazione? "
Bert Scalzo: Ragazzo, beh, adesso è un bene, sono contento che qualcuno abbia fatto quella domanda, dovremo passare un'altra mezz'ora. No, in memoria, dipende dal fornitore del database. Ora, normalmente lo sono, non parlo altro che elogi di tutto ciò che Oracle fa perché è incredibile la tecnologia che hanno costruito, ma quando ti strappi sotto le coperte e guardi cosa c'è in memoria in Oracle, in Oracle database, quello che è in realtà è che conserva ancora l'archivio di righe sul disco, e verrà caricato l'archivio di colonne in memoria e, se non c'è memoria sufficiente per contenere l'intera tabella, tornerà indietro per le porzioni; non si adatterà alla memoria, per farlo archiviare le righe, e quindi potresti effettivamente fare una selezione rispetto alla tabella e per metà della tabella, stai usando un'indicizzazione che colpisce le righe tradizionali alla tabella e per l'altra metà di la selezione sta effettivamente uscendo e afferrando tutto da una ricerca in memoria, quindi è diverso nel modo in cui SQL Server, ad esempio, lo ha implementato con la sua tecnologia Hekaton, sai, e SQL 2014, ed è stato migliorato in SQL 2016, ma per alcuni aspetti, la loro è una versione più vera di in-memory e, ma ogni implementazione ha vantaggi e svantaggi, ma bisogna cercare sotto le coperte e rendersene conto. Perché, ho avuto un cliente che ha detto: "Oh, questo tavolo è in memoria - Sto solo per disegnare tutti gli indici", e sono tipo, "Il tavolo è più grande della memoria che hai sul server, quindi ad un certo punto alcune query devono colpire il disco. "
Eric Kavanagh: è una buona descrizione; questa è roba buona. Bene, gente, avremo qualche altro webcast con questi ragazzi nel resto di quest'anno, tornate ogni volta che sentirete parlare di Bert in una presentazione perché sappiamo che conosce le sue cose. È sempre divertente parlare con gli esperti. Archiviamo tutti questi webcast per una visualizzazione successiva. Ecco di nuovo le informazioni di contatto di Bert, e proveremo a cercare quel link per il download e a inviarlo anche via e-mail, ma puoi sempre e-mail davvero tuo: abbiamo un sacco di altri webcast per questo anno e stiamo facendo l'editore in questo momento, quindi gente, se ci sono argomenti che vorresti davvero conoscere l'anno prossimo, non essere timido: abbi cura di te, gente, ci sentiamo la prossima volta. Ciao ciao.
Partner di contenuti Techopedia
Lo staff di Techopedia è affiliato a Bloor Group e può essere contattato utilizzando le opzioni sulla destra. Per informazioni su come lavoriamo con i partner del settore clicca qui.- Profilo
- Sito web
