Índice:
Por Techopedia Staff, 5 de outubro de 2016
Takeaway: O anfitrião Eric Kavanagh discute a indexação do banco de dados com o Dr. Robin Bloor, Dez Blanchfield e Bert Scalzo do IDERA.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Parceiro de conteúdo Techopedia
A equipe do Techopedia é afiliada ao Bloor Group e pode ser contatada usando as opções à direita. Para informações sobre como trabalhamos com parceiros do setor, clique aqui.- Perfil
- Local na rede Internet
Eric Kavanagh: Senhoras e senhores, olá, e sejam bem-vindos novamente. É quarta-feira, às quatro horas da manhã, e aqueles que conhecem o programa sabem o que isso significa, é hora de outro episódio da Hot Technologies. Sim, de fato. Meu nome é Eric Kavanagh, serei seu moderador na sessão de hoje: "Insanidade de índice: como evitar o caos no banco de dados". Ou como eu me referi a ele na última explosão de e-mail a sair, "disputa de banco de dados". Termo quente nos dias de hoje, "disputa". Todo mundo faz isso. Há um slide sobre o seu verdadeiramente. E chega de mim.
Portanto, a série Hot Technology realmente foi projetada para definir um espaço específico, em oposição à Briefing Room, que é apenas um briefing individual de analistas ao vivo, para a Hot Tech, temos dois analistas. Hoje, será nosso próprio doutor Robin Bloor e nosso cientista de dados Dez Blanchfield. E estamos falando de um tópico que eu acho realmente bastante emblemático do que está acontecendo no mercado hoje.
O ponto principal é que estamos em um mundo de complexidade nos dias de hoje. Realmente, se você pensar em quinze ou vinte anos, era um mundo muito diferente naquela época, especialmente com relação à tecnologia de banco de dados. Bancos de dados costumavam ser bastante simples. Havia apenas um punhado deles; a maioria deles era relacional. Agora, temos toda essa panóplia de tecnologias de banco de dados. Literalmente, várias opções na tabela para quem deseja criar um aplicativo ou fazer alguma coisa com dados. Tudo está mudando e isso afeta as pessoas que tentam gerenciar esses sistemas. Hoje vamos conversar com Bert Scalzo, que é um verdadeiro especialista na área; ele é o gerente sênior de produtos da IDERA, sobre o que você pode fazer para controlar todos esses dados. Com isso, vou entregá-lo ao doutor Robin Bloor para levá-lo embora. Robin, o chão é seu.
Robin Bloor: Ok, obrigado por essa introdução. Acho que sim - porque é uma coisa de duas mãos, acho que gostaria de falar sobre otimização de banco de dados em geral como uma introdução a esse programa Hot Tech. Comecei a vida - em tecnologia e análise - comecei a fazer isso porque costumava escrever artigos sobre os recursos dos bancos de dados na plataforma DEC VAX. E por esse motivo, os gastadores de banco de dados costumavam me informar. E o que isso me ocorre é: por que você teria um banco de dados? Quero dizer, naqueles dias, muitas pessoas costumavam criar arquivos de valores-chave e usá-los para ter um tipo de falácia sequencial de índice, como os chamamos, mas para criar um tipo de capacidade de banco de dados, e você sabe, por que você teria algo mais?
E a resposta para isso, acho que Michael Stonebraker deu a melhor resposta para isso, e ele disse: "Um banco de dados pode saber mais sobre onde estão os dados e com que velocidade os obtém, do que qualquer programa pode saber". E eu acho isso interessante; é a natureza do jogo. Mas em 19 - bem por volta de 1989, eu comecei na análise de tecnologia e, naquele momento, os bancos de dados eram muito simples e os bancos de dados relacionais eram super simples. Eles tinham tão pouca capacidade, quero dizer, eles podiam armazenar dados, obviamente, e você podia fazer backup e eles tinham, eles eram compatíveis com ACID, mas eles realmente tinham otimizadores muito fracos. De fato, seria difícil argumentar que eles tinham a capacidade de otimização.
E, mais tarde, eles ficaram cada vez melhores, mas, quando um banco de dados não funciona - como esses cangurus parecem estar de uma maneira ou de outra -, pode haver muitas razões pelas quais está ficando lento. E isso me leva ao ponto: os bancos de dados têm muitas funções, mas a mais importante é a otimização de consultas. Se eles não fizessem isso, você não os usaria. Trata-se de obter informações rapidamente, é capaz de fazê-lo quando há muitos usuários simultâneos, e esse é um problema difícil. E quando você realmente olhar para, vamos chamá-los de bancos de dados maduros, se quiser - mas certamente Oracle, em uma extensão um pouco menor, Microsoft SQL Server, certamente Teradata e DB2 - que os otimizadores desses bancos de dados obtiveram, foram décadas. construção. Você sabe, eles não fizeram - alguém não sentou - seis caras em um projeto de dois homens, ano, e apenas batem um juntos. Não funciona assim. A capacidade de otimização aumentou gradualmente e é preciso muito crescimento. De qualquer forma, vamos falar sobre o plano de fundo do banco de dados. Bem, há muito o que dizer sobre o banco de dados NoSQL agora, e ainda há muito entusiasmo pelo banco de dados de gráficos. E o uso do SQL no Hadoop e coisas assim. Mas, a verdade é que, se você deseja um banco de dados agora, se deseja um OLTP totalmente funcional, capaz de OLTP e grande tráfego de consultas, é um banco de dados relacional ou não é nada.
Entre os bancos de dados relacionais, o Oracle é dominante em popularidade. O Microsoft SQL Server, eu acho, é o segundo. Ambos são capazes de serem usados para OLTP e carga de trabalho de consulta, mas na verdade você não pode se safar misturando essas cargas de trabalho. Você precisa de incidentes diferentes para cargas de trabalho OLTP e cargas de trabalho de consulta. Existem alternativas para SQL e gráfico. A maioria das empresas padroniza em um banco de dados específico, e é por isso - quero dizer, depois de décadas lutando com todos os outros participantes, a Oracle se tornou a mais dominante. Simplesmente porque eles acabaram vendendo licenças corporativas e, portanto, as empresas usariam apenas produtos alternativos em produtos excepcionais que a Oracle simplesmente não usaria. E os bancos de dados são estratégicos, pois também evoluem. E você sabe que eu fiz um pouco de pesquisa para esta apresentação, e é tipo - eu vou falar sobre isso daqui a pouco, mas é meio interessante como eles evoluem, em termos de olhar para ela da posição de um DBA. É isso que eu chamo de tendência invisível. É a lei de Moore em cubos. É mais ou menos assim: o maior banco de dados é, e novos bancos de dados, não há um banco de dados antigo que tenha muito mais dados para ingerir. Normalmente, é um banco de dados que está sendo aplicado a um novo problema. E eles realmente crescem em termos de volumes de dados. Aproximadamente no cubo de Moore lei. Portanto, a lei de Moore é um fator de dez vezes a cada seis anos. Os VLDBs tendem a crescer um fator de mil a cada seis anos. Em 1991, 1992, os grandes bancos de dados são medidos em termos de megabytes. Em 97 e 98, gigabytes. 2003, 4, terabytes. 2009, 10, você começou a ver bancos de dados de petabytes. Acho que havia possivelmente um ou dois bancos de dados de exabytes no mercado, mas o maior de que ouvi falar foram os 200 petabytes no prazo, e você sabe, não obtendo dados em bancos de dados de petabytes. Mas, é a maior parte disso, obviamente, serão as novas grandes empresas da web 2.0; possivelmente, você tem o Facebook indo nessa direção.
Mas de qualquer maneira, se você realmente olhar para isso, esperando que um banco de dados passe por esse tipo de escalada em volume, está pedindo muito. E notavelmente, certamente até o nível de petabytes, eles parecem ter se saído razoavelmente bem. Quero dizer, estou falando dos produtos mais antigos do que de algo novo. Eles parecem ter se saído extraordinariamente bem. Se observarmos o desempenho do banco de dados, os gargalos, isso me levará de volta ao tempo em que realmente me preocupava com eles, e tive que me preocupar com eles. Você sabe que isso é fundamentalmente o colapso do hardware. Existem gargalos na CPU, possivelmente, existem gargalos na memória, possivelmente, existem gargalos no disco, possivelmente. Pode ser a rede que causa luto e você também pode ter problemas com o bloqueio, dependendo do que estiver fazendo, mas normalmente isso ocorre porque o programa não sabe para quem chamar o bloqueio. Portanto, se você estiver ajustando um banco de dados, na verdade, está tentando ajustá-lo para que ele dance entre os cinco possíveis gargalos possíveis. E isso não é fácil, porque a quantidade de memória que você pode configurar em qualquer servidor aumenta consideravelmente. Então as CPUs se tornaram multicore, disco, bem, agora podemos fazer, acho, mesmo em servidores de commodities, acho que você pode fazer centenas e centenas de terabytes, quarto de petabyte, talvez, mesmo em um servidor de commodities. Então, de todas essas coisas, você pode brincar, a rede, é claro, pode ter velocidades diferentes, mas principalmente quando você lida com bancos de dados, você realmente deseja ter cabos de fibra entre os servidores e nada mais rodando nisso, em particular dessa maneira.
Fatores de desempenho do banco de dados. Quero dizer, estou deixando de fora o que tudo isso vai ser, porque sei que Dez vai falar sobre isso, mas o design ruim do banco de dados significa um banco de dados com desempenho ruim. Um projeto de programação ruim pode significar jogar SQL muito estúpido em um banco de dados, o que levará muito mais tempo. Simultaneidade e mistura de carga de trabalho, muita concorrência causará problemas de gargalo. A mistura de carga de trabalho, quando você tem consultas grandes com consultas muito pequenas, curtas e nítidas, que causam problemas. Há um problema de balanceamento de carga. A maioria dos bancos de dados cuida disso, mas se você não possui um produto sofisticado, sabe, basta adicionar alguns servidores, não é tudo o que você faz se realmente deseja aumentar o tamanho de um cluster. Você realmente precisa equilibrar a carga antes de obter o desempenho ideal. Você precisa fazer o planejamento da capacidade. Absolutamente. Especialmente hoje em dia, como quando os volumes de dados aumentam drasticamente do que costumavam ser nos bancos de dados. E há problemas de toda a camada de dados sobre como você ingere os dados, como você os move. Não levar os dados para o banco de dados a tempo pode ser um problema de desempenho mais tarde, porque passamos dos bancos de dados que funcionam no Windows para 24 horas por sete por trezentas e setenta e cinco operações e não há janelas nas quais você possa diminuir a velocidade da operação. banco de dados inativo ou é improvável que exista hoje em dia.
O problema do Oracle DBA. Era nisso que eu estava pensando. Estive no DBA da Oracle com o Oracle 7 e lembro-me de como ajustar isso. E se você realmente olhar para a Oracle agora, é muito, muito - muito, muito mais capacidade. Ele tem indexação de bitmap e coisas assim, mas na verdade, dediquei um tempo para ver e ver quantos parâmetros de ajuste realmente existem em um banco de dados Oracle no momento. E existem mais de trezentos e cinquenta parâmetros de ajuste e outros cem ocultos, que os DBAs especializados podem conhecer, mas os DBAs Oracle normais não conhecem. E isso significa que ajustar esse tipo de banco de dados é algo difícil. Não é uma coisa simples. Você precisa experimentá-lo há muito, muito tempo e precisa saber exatamente qual é o problema que pensa que está resolvendo, porque a sintonia começa quando o o desempenho fica ruim, mas pode não ser o desempenho de tudo. Pode ser o desempenho de consultas específicas importantes, e você pode consertar isso fixando determinados dados e memória, ou pode precisar corrigi-lo através da indexação, ou pode começar a particionar de uma maneira diferente. Há muitas coisas que você pode fazer, é o ponto. Portanto, consequentemente, eles não farão isso na cabeça - os DBAs precisam de ferramentas. Agora vou passar para Dez, que vai falar sobre indexação, eu acho.
Eric Kavanagh: Tudo bem Dez, leve embora.
Dez Blanchfield: Obrigado, Robin, e eu amo a capa. Eu acho que você jogou a luva lá em baixo para eu chegar remotamente perto de algo tão emocionante. Mas usei uma imagem de nossa pequena galáxia, como minha visão do que o desafio de hoje para os administradores de banco de dados se transformou, porque essa é a imagem mental que costumo invocar quando entro em um ambiente e não estou mais no mundo da administração de bancos de dados ou da criação de bancos de dados nesse nível. Mas, como você, Robin e eu tivemos muitos anos de envolvimento no mundo dos bancos de dados, como administrador ou desenvolvedor ou, eventualmente, arquiteto, e então percebemos que eu poderia fazer coisas melhores para ganhar uma crosta. Mas parece que você está olhando para esta galáxia de dados, e mais ainda hoje, quando passamos de, como você descreveu, passamos de megabytes para petabytes e expandimos em um período muito curto de tempo, no grande esquema das coisas. Mas a frase que tenho em mente é que os índices de banco de dados agora são uma arte negra e não são realmente o tipo de coisa que meros mortais deveriam envolver, para aplicativos de negócios de nível empresarial e o tipo de formulação de você estavam apenas falando. Mas eu queria passar por um rápido resumo do tipo de história que tive com os mundos dos bancos de dados e contextualizar para onde vamos chegar a uma conclusão e, em seguida, percorrer algum material hoje com nossos amigos em IDERA, porque acho que há muitos pensamentos diferentes sobre como obter o ajuste do desempenho do banco de dados e um deles está jogando lixo nessa coisa. Para muitas lojas com as quais me deparo, elas invariavelmente não chegam ao ponto de ajustar o desempenho na camada do banco de dados e, em particular, na camada de índice, até que passem pelo caminho difícil de pensar que podem usar um sintonizador. .
Muitas pessoas simplesmente adotam uma grande abordagem de ferro, e eu tenho uma foto do The Flash aqui porque se você já assistiu a filmes antigos ou certamente ao último programa de TV do The Flash, como em Flash Gordon, o personagem antigo, e agora que ele se chama "The Flash", ele tende a ir muito, muito rápido e invariavelmente sua energia acaba. E é isso que acontece quando você joga muito ferro no desempenho do banco de dados. Invariavelmente, na minha experiência, você pode colocar alto desempenho e muito trabalho no jogo, pode otimizar seus sistemas operacionais e ajustá-los a um determinado ponto. Você pode garantir que você tenha CPUs rápidas de vários núcleos e multithreading para acelerar a execução do aplicativo, você pode usar muita RAM, ter backplanes de alto rendimento, mudar de discos rígidos para cache de discos rígidos e para estado sólido e storage array de alto desempenho. E mesmo agora, as pessoas colocam coisas como flash e NVMe em seus mecanismos de banco de dados, pensando que obterão esse tempo de logon com dois ganhos de desempenho. E invariavelmente eles obtêm algum ganho. Mas tudo volta aos mesmos problemas básicos de ajuste de desempenho. Muitas conexões de rede de baixa latência, para que os clusters funcionem rapidamente. E da infraestrutura de banco de dados em cluster, para que você tenha mais do que apenas uma máquina fazendo todo o trabalho. Mas você tende a voltar ao mesmo problema básico de desempenho, e isso é a leitura de dados. A gravação de dados é, em grande parte, um desafio bastante linear e a menos que seja feito corretamente.
E então temos o desafio no mundo de hoje: nem todos os bancos de dados são criados iguais. Existem bancos de dados e "banco de dados entre aspas". E quando pensamos nos mecanismos de banco de dados, as pessoas costumam pensar nos suspeitos tradicionais e comuns como eram no mundo do SQL. Você sabe, temos o Oracle e o Microsoft SQL Server, e há alguns no mundo de código aberto com o MySQL, que agora é de propriedade da Oracle, mas ainda é de código aberto. E então temos os suspeitos não tão comuns, os mecanismos NoSQL, que ainda têm um problema de indexação e gerenciamento de desempenho, e eu não os abordarei com muitos detalhes, mas há um número crescente desses coisas aparecendo todos os dias e elas parecem motores de banco de dados do ponto de vista dos desenvolvedores e do ponto de vista do desempenho, mas são bestas muito, muito diferentes e têm seu próprio nicho no mundo para descobrir desempenho na memória ou escala linear no disco. Mas é assim que o mundo se parece no mundo dos bancos de dados. Este é o 2016, esta é a versão três do mapa de, por uma série de pessoas que produzem esse mapa de paisagem em andamento de como são os bancos de dados, e é aí que ele - nem mesmo um arquiteto ou administrador de banco de dados sobre-humano ou administrador de banco de dados poderia fazer sentido disso. Literalmente centenas, centenas e centenas de diferentes marcas, modelos, fabricantes de bancos de dados, invariavelmente compatíveis com SQL. E o interessante é que todos voltam ao mesmo desafio. Desempenho e ajuste de desempenho em torno do mecanismo de banco de dados e, principalmente, pela maneira como os dados são indexados.
Então, vamos cobrir rapidamente a indexação do banco de dados, porque é um tópico interessante, e você precisa entrar em detalhes com a demonstração, acredito. Mas acho que é bastante aceito e prática padrão da indústria que o ajuste do desempenho do índice de banco de dados é o lugar onde o mundo começa e termina, garantindo que seus dados sejam acessíveis em um formato rápido e rápido. Mas o que é indexação de banco de dados? Se pensarmos na indexação da forma que estamos acostumados a seres humanos comuns, pense em uma página de índice em um livro. Se você quiser encontrar algo em um livro - particularmente os gostos de uma enciclopédia, ou algo como um material de referência de alguma forma - se você estiver procurando algo como esta página, onde eu estou procurando coisas como o tópico de barragens em uma enciclopédia. Quero encontrar todas as referências a barragens, captação de água e uma grande área de construção, geralmente feita pelo homem. Eu vou para o fundo, vou encontrá-lo em uma lista alfabética e ordenada, de A a Z, da esquerda para a direita, e vou encontrar D. Vou encontrar a palavra “barragens” e vejo isso em páginas 16, 38, 41 há uma referência a elas, e então eu posso ir para essas páginas, posso escanear meus olhos e vou encontrar a referência à palavra "barragem". É essencialmente o mesmo conceito em um banco de dados, mas agora é uma ciência de foguetes de várias maneiras. Tanto que, efetivamente, todo administrador de banco de dados que eu já conheci bem, considera os índices a ferramenta mais crítica para o ajuste de desempenho em qualquer mundo de banco de dados, independentemente de qual seja a experiência deles até o momento, ou seja qual for o caso.
Geralmente, quando falamos sobre indexação de banco de dados, há várias abordagens comuns. E quanto mais complexos os índices de banco de dados se tornam, mais complexa é a abordagem para indexar dados. Mas, essencialmente, quando você pensa em indexar dados - imagine que temos um arquivo com uma lista de nomes; eles não podem ser classificados em ordem alfabética. Vamos imaginar que há vinte deles. Se vamos classificar - se vamos procurar dados nessa lista, de cima para baixo, e digamos que é uma lista de nomes. Se eu escolher um nome aleatório e começar a rolar a lista para baixo, de cima para baixo, em um formato linear e for uma lista não ordenada, há dois critérios que considero como o tempo médio de pesquisa e o tempo máximo de pesquisa - e Eu tenho um erro de digitação na segunda linha, deve ser o "tempo máximo de pesquisa", desculpe - mas meu tempo médio de pesquisa é essencialmente N mais um, dividido por dois, e isso é, em média, leva 50% do tempo para digitalizar do topo da lista até o final da lista para encontrar qualquer coisa aleatória nessa lista. E a segunda linha, abaixo de linear, deve ser "tempo máximo de pesquisa". Mas o tempo máximo de pesquisa é essencialmente o número de itens, e é que, se eu tiver uma lista de vinte coisas, é possível que demore mais tempo procurar algo nesse banco de dados é ir de cima para baixo, digamos 20 itens neste exemplo simplificado. E é um processo muito lento e realmente não há como ajustar o desempenho. Além disso, existem outros tipos de maneiras de obter esses dados e criar um índice, que é efetivamente uma pequena lista de indicadores para onde estão os dados reais, como binários, árvore B, bitmap, hash, agrupados e não agrupados, e existem diferentes tipos de dados, como espacial, filtrado, XML e texto completo.
O binário é muito usado para coisas em que os dados se prestam a ele. A árvore B é provavelmente a mais comum em sentido geral, historicamente, porque é uma maneira comum de estruturar um índice para qualquer forma de dados e permite que loggers, seleções e inserções e exclusões sejam relativamente fáceis à medida que você move os ponteiros pelo referência aos ponteiros, os pontos. Existem outros tipos, como bitmap, em que os tipos de dados se preocupam, como se tivéssemos um intervalo associado de alguma forma. O hash funciona muito bem para objetos grandes, principalmente blogs e imagens. E você pode ver que existem vários tipos diferentes de abordagens científicas, abordagens matemáticas, na indexação de dados. Para o mero mortal, eles são um desafio interessante a ser discutido nesse nível. Quando você fala sobre isso no nível de desempenho para um administrador de banco de dados, ele realmente se torna um cientista de foguetes e as pessoas fazem diplomas, e eu sei que o Dr. Robin Bloor certamente fez isso, e escreveu livros sobre ele para empresas como IBM e IBM. outras grandes marcas nas últimas duas décadas. E assim, a - a minha opinião, é que realmente passamos um tempo em que, você sabe, uma vez eu pessoalmente seria capaz de me sentar na frente de um sistema e seria capaz de separá-lo e mostrar a você exatamente onde os problemas de desempenho estavam em uma linha de comando ou em uma ferramenta gráfica de interface com o usuário, e comece a investigar os dados e informar onde estavam os problemas, além de criar índices ou subíndices ou índices primários e secundários. dados e comece a usá-los para encontrar coisas. Mas quando você pensa sobre esse cenário, eu mostrei a você, onde temos centenas e centenas de marcas, marcas e modelos, e fabricantes e tipos de bancos de dados, estamos bem e verdadeiramente além desse tempo agora, onde um ser humano pode criar senso dos tipos de mecanismos de banco de dados que temos. Particularmente, mesmo que apenas voltemos aos gostos da Oracle, marcas predominantes atualmente em plataformas de bancos de dados relacionais.
O número de bancos de dados com os quais eles precisam lidar a partir de uma plataforma proprietária, como um ERP, RH ou sistema financeiro, ou se são uma plataforma caseira por vários motivos, o número de bancos de dados e tabelas e registros de banco de dados que acabamos lidar com isso é apenas astronômico e você fisicamente não pode fazer isso manualmente. E tivemos uma complicação adicional agora, onde, uma vez, um servidor de banco de dados pode simplesmente ficar sob sua mesa. Você sabia que, quando criança, depois da escola, eu trabalhava em software de banco de dados nos sistemas Apple IIes e DOS baseados em PC, como o dBase II, o dBase III, passando por uma era com mainframes e mid- alcance e até VAXs e PDPs e arquivo de log sobre isso. E como o Sabre e, eventualmente, quando alguns dos bancos de dados SQL surgiram. Mas hoje em dia, quando pensamos nos mecanismos de banco de dados, eles se parecem com o canto inferior esquerdo. Um servidor de banco de dados não é mais apenas uma máquina sentada no chão, debaixo de uma mesa; são centenas de máquinas executando cópias de mecanismos de banco de dados e clusters, e elas escalam até centenas e centenas de terabytes de dados, se não petabytes de dados, que são milhares de terabytes. E até ao extremo, como o Dr. Robin Bloor mencionou, que alguns casos de uso específicos - companhias aéreas, agências governamentais em particular - podem chegar a exabytes. Eles ainda são bastante nicho-y, mas centenas de terabytes e até dezenas de petabytes não são mais incomuns, principalmente do boom das pontocom até agora, uma espécie do que estamos chamando de empresas da Web 2.0, como Facebook, Google, Yahoo. e assim por diante.
Também temos a complicação agora que as coisas estão mudando para um serviço externo. Temos plataforma de infraestrutura e software como uma abordagem de serviço que fornece infraestrutura. E, particularmente, serviço de plataforma, onde não podemos comprar apenas produtos como Oracle e suas plataformas, bancos de dados e servidores em nuvem. E, assim, isso nos permite desenvolver muito rapidamente aplicativos e apenas conectar um banco de dados aos servidores. Não precisamos pensar no que está por baixo. A desvantagem é que geralmente não pensamos em como projetamos e implementamos o banco de dados até que ele comece a prejudicar e o desempenho se torne um problema e, em seguida, acabamos precisando procurar a ferramenta certa para diagnosticar por que nosso banco de dados está sofrendo e onde estão os problemas de desempenho. E, invariavelmente, traz de volta ao problema comum de como indexamos esses dados e os tipos de índices que usamos para esses dados e, em seguida, nos traz de volta ao requisito de desempenho sobre-humano. E alguém que tenha acesso aos sistemas certos e às ferramentas certas para ajustar o desempenho desses mecanismos e comece a encontrar um ponto de acesso e analisar onde estão as consultas, onde os dados estão se movendo, os tipos de consultas, como as consultas são estruturadas, quem está fazendo as consultas e se as consultas estão sendo enfileiradas e precisam ser armazenadas em cache. Que replicação você procura?
E, portanto, estamos bem e verdadeiramente - na minha opinião - em um ponto em que até os melhores gurus de banco de dados do mundo, essencialmente nossos arquitetos de banco de dados e nossos administradores de banco de dados e bases de desempenho, na minha opinião, precisam muito começar a alavancar as ferramentas certas para oferecer o ajuste ideal do índice de desempenho para qualquer mecanismo de banco de dados. Como a escala com a qual estamos lidando e a velocidade com que as coisas estão se movendo, simplesmente não podemos fazer isso manualmente, e tentar fazer isso invariavelmente pode introduzir outros problemas de desempenho, porque podemos não ter experiência nesse espaço que estamos tentando resolver um problema. E acredito que é aí que estamos prestes a entregar a Bert, e estamos prestes a falar sobre como eles resolveram esse problema variado e o tipo de coisas que sua ferramenta pode oferecer., especialmente para o mundo Oracle. E com isso lá, Bert, eu vou passar para você.
Bert Scalzo: Obrigado. Sejam bem-vindos, meu nome é Bert Scalzo, trabalho para a IDERA. Sou o gerente sênior de produtos de alguns de nossos produtos de banco de dados. Vou demonstrar algumas delas hoje. Mas quero falar sobre índices, porque concordo com tudo o que todos disseram aqui, especialmente o último slide, que os índices são tão complexos agora que você precisa de uma ferramenta e espero convencê-lo. Portanto, o design do índice Oracle não é tão fácil como costumava ser nos velhos tempos. Muitas pessoas ficam inseguras quando olham para as opções, e eu gosto disso dizendo que saí da história: "nesses assuntos, a única certeza é que nada é certo". E é assim que eu meio que hoje em dia, sente-se em relação aos índices, porque, mesmo que você ache que sabe a resposta, deve indexar X, Y ou Z, realmente não pode ter certeza até experimentá-lo, porque esses otimizadores às vezes se comportam de maneira diferente da esperada. E, portanto, há muitas tentativas e erros no design do índice. Agora, nos bons velhos tempos, se você precisasse de um índice, geralmente havia apenas duas perguntas ou uma pergunta. Era único ou não era único? E você pode ter pensado em outras coisas como: "Quantos índices posso ter no máximo em uma única tabela?", Porque muitos índices atrasam suas inserções, atualizações e exclusões. Você também pode estar no sistema de banco de dados, ter restrições sobre quantas colunas podem estar em um índice de várias colunas, porque às vezes havia limites com base na página ou no tamanho do bloco do mecanismo de banco de dados, mas na realidade era bem simples nos bons velhos tempos. Você o indexou ou não. E realmente, tudo estava em uma árvore B. Poderíamos permitir as duplicatas ou não, e era isso. A vida era boa, a vida era simples.
Bem, hoje, a vida não é tão boa ou tão simples. Eu coloquei o sinal vermelho do Ghostbuster da maneira que costumávamos fazer, porque agora temos árvore B versus bitmap, versus junção de bitmap. E eu vou explicar o que algumas dessas são em um momento. Clusterizado e não clusterizado, exclusivo ou duplicado, ordem direta ou reversa, baseado em função, particionado ou não particionado. Se houver particionamento envolvido, é particionamento global ou local? Eu vou explicar isso também. E também há algo chamado tabela organizada indexada. E na verdade há meia dúzia de outras que eu deixei aqui, porque acho que já tenho o suficiente aqui agora para convencê-lo de que os índices são muito mais difíceis do que você imagina. Neste slide em particular, vou começar na parte superior esquerda do diagrama e tenho uma tabela. E a primeira coisa que tenho que decidir é que, dependendo da versão do banco de dados e do fornecedor do banco de dados, eles permitem tabelas de objetos ou são apenas relacionais? Vou descer pelo lado direito e dizer que estamos construindo uma tabela relacional. Agora, a próxima pergunta que devo me perguntar é: está em um cluster? E muitos de vocês que fazem o Oracle há algum tempo se lembram que os clusters estavam de volta pelos 6 dias do Oracle. Eles provavelmente não são muito usados hoje, mas deixe-me ir primeiro a esse ramo.
Se eu fosse colocar minha tabela em um cluster, teria que ter um índice em cluster nessa tabela. Agora, no Oracle, quando você agrupava uma tabela, basicamente estava armazenando as linhas ou as linhas estavam próximas umas das outras em que os valores eram semelhantes. E assim, você precisa ter um índice em cluster e esse índice em cluster pode não ser particionado. Em outras palavras, não havia realmente nenhum método de particionamento para como você faria uma tabela em cluster. Foi estritamente não particionado. E como não era particionado, era global. Vou explicar o que é global em um minuto. E sempre foi B-tree. Em outras palavras, quando desci naquele galho, era bem simples, não tinha muitas opções. Agora, se eu fiz um índice não agrupado em uma tabela em cluster, o que foi permitido em algumas versões, novamente ele não foi particionado; quando não está particionado, sua única opção é global. E assim, você tem a opção de árvore B ou bitmap. Novamente, isso dependia da sua versão do banco de dados. Mas agora, vamos voltar para a mesa relacional e começar a descer novamente pelo lado direito, e agora teremos uma mesa simples, antiga, regular e amontoada: relacional. Vai estar em um espaço de tabela. Estou meio que descendo pelo lado direito aqui primeiro. Então é organização, pilha. A próxima pergunta que devo me perguntar é: "Quero particionar esta tabela ou não?" Agora, às vezes, você particionava porque pensava: "Ei, o otimizador será mais inteligente sobre como otimizar consultas. ”Mas muitos DBAs dirão a você que o motivo é para fins administrativos. Se você possui uma tabela de cem bilhões de linhas, se a dividir em partições ou intervalos, quando desejar adicionar dados ao último intervalo, poderá eliminar e indexar apenas alguns milhões de linhas. Você pode inserir esses dados e, em seguida, reconstruir esse índice apenas nesse intervalo.
Embora fosse uma boa técnica para alguns, técnicas de otimização como a eliminação de partições, seu verdadeiro valor era poder administrar ou executar tarefas administrativas em partes menores. Quando vou para a pilha organizacional, a primeira pergunta foi: "Particionei ou não?" Vamos para a esquerda, não particionarei a tabela. Agora, pode parecer estranho quando eu digo isso, mas você pode ter uma tabela não particionada e não pode particionar o índice como está acostumado, ou pode particionar o índice. Pare e pense. Sua tabela possui basicamente um depósito, como você sempre pensou, e ainda assim seu índice terá vários depósitos. Quando isso acontece, onde há uma incompatibilidade entre o número de buckets e a tabela, e o número de buckets no índice, é isso que significa global. E assim, se a tabela não estiver particionada e se o índice estiver particionado, será considerado global, porque há uma incompatibilidade. Agora, deixe-me voltar ao heap da organização e descer no lado da partição. Agora, se eu tiver uma tabela de partição, e digamos que a tabela tenha quatro buckets, quatro partições, meu índice poderá ter quatro buckets para que meu índice corresponda ao meu design de tabela. E assim acabou, bem no lado direito. Isso seria considerado local. Um índice local significa basicamente que o particionamento da tabela e do índice é feito da mesma maneira e tem o mesmo número de buckets. E depois que eu tiver o índice local, pode ser uma árvore B ou um bitmap, e essa seta verde que meio que sobe mostra a você que, mesmo que seja uma árvore B, ainda existem opções que podem ser feitas. Pode ser baseado em funções. E também, se for um bitmap, existem diferentes tipos de bitmaps. Existe algo chamado índice de junção de bitmap. Se você estiver armazenando dados, esse é um tipo muito popular de índice para esquema ou design em estrela. O que acontece é que o índice tem os IDs de linha para o que aponta na tabela, mas também terá IDs de linha para as tabelas pai, para que, quando você - você precisar iniciar o design do esquema e procurar em uma tabela de fatos, esse índice aponta para os dados em que você está interessado e para todas as linhas de suas dimensões, de modo que você só precisa ter um índice.
E, na verdade, isso surgiu por causa do Red Brick, que era um banco de dados há muitos anos - muitas pessoas podem se lembrar disso. Então, se você olhar para esta foto - e lembre-se de que eu não coloquei tudo nessa foto porque a foto seria muito maior - ainda existem problemas adicionais, que eu tenho no texto aqui na parte superior direita . É um índice de ordem inversa? E você pode dizer: “Por que eu iria querer um índice de ordem inversa? Isso não faz o menor sentido. ”Bem, se você estiver em um ambiente em cluster no Oracle, se estiver fazendo clusters de aplicativos reais, se você mantiver seus índices em ordem, de forma invertida, se houver muito processamento em execução, os mesmos valores ou os mesmos valores de índice, o que aconteceria é que você teria áreas quentes da sua árvore B. Significando que você teria contenção e possivelmente bloqueio para tentar acessar essas coisas, e faria isso através dos nós em uma rede. Bem, se você inserir um índice de ordem inversa, agora poderá desfazer isso. Você pode dizer: “Bem, os valores semelhantes estão em diferentes partes das árvores, então não tenho meus nós separados competindo por áreas quentes na árvore.” E observe também que o exclusivo não funciona com algumas das opções . Se você olhar, eu tenho três, cinco, oito e onze, então há alguns casos em que não posso ter um índice exclusivo. Da mesma forma, há alguns casos em que não posso ter um índice reverso e, em seguida, há problemas adicionais, como o log ou não, e paralelo e não paralelo. Eu posso atribuir coisas a uma área específica na memória.
E isso deixa de fora ainda alguns recursos do Oracle. Eu diria que, quando você olha para o Oracle 12, provavelmente há mais uma meia dúzia de coisas que eu poderia adicionar a essa imagem. A indexação é realmente complexa e eu realmente concordo com o orador anterior. Para navegar por isso e fazer uma boa escolha, você precisa de uma ferramenta. Talvez você precise de uma imagem como essa, e algum tipo de metodologia sobre como escolher as coisas e, esperançosamente, a ferramenta o ajudará a chegar lá. E então será tentativa e erro. Eu sempre digo às pessoas na indexação: "olhe antes de pular". E então você pode ver o cachorrinho aqui, ele está pulando sem olhar, ele vai acabar na água com o tubarão, ou o cara se preparando para pular na água, e ele vai se empalar. Você precisa pensar em sua indexação, porque criar um índice nem sempre significa que as coisas melhoram. De fato, a criação de um índice pode desacelerar as coisas. E o desempenho da consulta pode ser uma ordem de magnitude melhor com uma escolha do que com outra. E eu vou te dar um bom exemplo. Se você estiver fazendo um esquema em estrela de design e, nas tabelas de dimensões, usar índices de bitmap em um caso e, em outro caso, você disser: "Vou usar índices da árvore B", você terá bitmap versus B- árvore. Posso dizer que uma solução será uma ordem de magnitude ou possivelmente várias ordens de magnitude mais rapidamente que a outra. Mas lembre-se do que funciona em um ambiente, como em um ambiente de data warehouse, provavelmente não é uma boa opção em um ambiente OLTP.
Por exemplo, se você pegar uma tabela transacional e colocar índices de bitmap em uma tabela transacional, é caro calcular e redefinir bitmaps, essas cadeias longas e assim em uma tabela OLTP, você pode atingir a tabela com tanta força que o bitmap O índice pode ficar corrompido e tornar seu sistema lento porque eles não são destinados a atualizações. Eles são ótimos para acesso rápido, mas não são bons para atualizações. Eu acho que o índice leva tentativa e erro. Realmente não existe mais regra de ouro - há muitas variáveis diferentes nesta equação para saber - e, finalmente, você precisará examinar a execução ou explicar os planos no banco de dados para ver se está fazendo boas seleções. E, às vezes, a análise do plano pode quase ser uma ciência em si mesma. Não vou abordar isso hoje - esse é outro tópico -, mas não tome como garantido o design do índice. Existem razões legítimas pelas quais existem todos esses tipos de índices malucos que eu mostrei na foto anterior e sobre os quais o orador anterior falou. Eles não foram criados apenas porque era um recurso interessante colocar uma lista de verificação em algum lugar para um fornecedor de banco de dados; existem casos de uso ou cenários em que esses índices são importantes e farão uma diferença significativa. Agora, com isso, mostrarei alguns exemplos de diferentes tipos de índices em uma de nossas ferramentas. Deixe-me apenas levantar minha tela para que você possa vê-la. Ok, então aqui estou eu sentado - deixe-me minimizar esta aplicação. Estou sentado dentro do VMware e estou executando uma VM do Windows Server 2012.
E você pode ver, eu tenho quase todas as ferramentas conhecidas pelo homem. Como gerente de produto, tenho que ficar atento aos meus concorrentes, para que não sejam apenas as ferramentas que tenho, mas o que meus concorrentes fazem? E nós temos essa ferramenta aqui chamada DBArtisan, que eu já tenho em execução, mas eu vou - então eu vou trazê-la. E o que você pode ver é que é uma ferramenta muito boa, porque, em vez de precisar usar, digamos, um gerente corporativo para Oracle e um SQL Management Studio para SQL Server, o MySQL Workbench para MySQL e outros doze bancos de dados que suportamos, bem, eu tenho todos os meus bancos de dados embutidos nessa ferramenta. Existe o DB2, existe o MySQL, Oracle, Postgres, SQL Server e Sybase, e é isso - eu só tenho seis bancos de dados nessa coisa em particular porque não posso - a ferramenta suporta doze bancos de dados, mas minha má VM, executando seis bancos de dados simultaneamente e tentando para fazer uma demonstração, é o máximo que meu hardware facilitará. Então, deixe-me voltar ao Oracle agora e, se você notar, todas essas coisas são iguais. Se eu quiser medir meu desempenho no DB2, são as mesmas opções que eu teria no Oracle. Agora, nos bastidores, fazemos muitas coisas diferentes para que você não precise saber o que está acontecendo, mas oferecemos uma interface consistente para que você possa ser um especialista em várias plataformas de banco de dados. E isso incluiria trabalhar com índices, o tópico desta discussão.
Deixe-me entrar aqui e deixe-me começar por olhar algumas tabelas, e eu tenho um banco de dados de filmes que tem apenas algumas tabelas. E se eu olhar para uma tabela específica, como a tabela do cliente, quando a trago aqui, posso ver o design da minha tabela, aqui estão minhas colunas na minha tabela e aqui estão as informações sobre cada coluna. Eu tenho propriedades para a tabela, mas observe que tenho uma guia aqui para índices e posso ver aqui os índices na tabela. Observe que um desses índices é o meu índice PK, minha chave primária. Esses outros parecem ser apenas índices para melhorar o acesso à consulta, talvez pesquisemos por nome ou sobrenome, ou observamos telefones e códigos postais. E se eu escolher um índice específico, como este CEP aqui, e clicar duas vezes nele, agora posso ver que, ei, é um índice não exclusivo e aqui estão alguns dos outros tipos, bitmap, não exclusivo, exclusivo, independentemente de ser ou não classificado, de registro ou não, de ordem inversa ou não, de base funcional. Oh, aqui está uma divertida que eu não cobri. Você pode realmente ter índices invisíveis. E você diria: "Bem, por que diabos eu gostaria de fazer um índice invisível?" Bem, eu vou lhe dar um bom exemplo. Você está no seu sistema de produção e tem um problema de desempenho e não tem certeza de que a criação do índice corrigirá o problema. Portanto, você não deseja criar o índice e desacelerar a produção, mas de uma forma ou de outra deseja ser capaz de testá-lo. Você pode criar o índice na produção como invisível, o que significa que muitos códigos de aplicativos, chamando o otimizador, usarão esse índice. Foi criado, é válido, mas não será usado. Em seguida, você pode fazer uma consulta que você acha que esse índice ajudaria, ou uma série de consultas, e pode dar uma dica e dizer: “Ei, otimizador, há um índice invisível por aí que eu quero que você use e deixe para saber se melhorei as coisas. ”E agora testei algo em produção, mas não quebrei os aplicativos em produção em execução. Esse é o uso de um índice invisível. Parece idiota quando você o ouve pela primeira vez, mas tem utilidade.
Também podemos, em índices, definir se são paralelos e também quantas instâncias são paralelas. Agora, em um ambiente de cluster de aplicativos não em cluster ou não real, portanto sem paralelo em rack, significaria quantos subprocessos minha consulta pode trazer para experimentar e processos de trabalho, para tentar obter algo mais rápido ou mais rápido . E instâncias paralelas seriam: se eu estiver em um cluster de aplicativos real, digamos que tenho dez nós, em quantos nós posso dividir o trabalho? Talvez seja quatro dos dez e, em cada um deles, quatro subprocessos. Esse é um exemplo. E então temos a compactação de chaves. Você pode realmente comprimir índices? Sim ou não. E é claro que você tem seus parâmetros de armazenamento que podem ser especificados nos índices. Agora, eu não cobri isso porque eles são realmente mais um parâmetro de armazenamento do que um problema de índice. E finalmente, temos que fazer ou não particionados ou não. Deixe-me largar isso aqui por um segundo. Eu vou para um esquema diferente. Este é um esquema em estrela e, por exemplo, esta tabela de período é uma tabela de dimensão. Se você já fez o design do esquema em estrela, normalmente possui uma dimensão de tempo e, nesse banco de dados e neste esquema em estrela, período é uma dimensão de tempo. Agora, eu sei que vai parecer engraçado, você dirá: “Nossa, olhe para todas essas colunas - o cara já ouviu falar em normalização?” Bem, quando você está em um data warehouse ou em um projeto de esquema em estrela, você normalmente não - você tem tabelas que uma pessoa comum consultaria e diria: "Nossa, elas não são muito bem projetadas". Mas é assim que você faz em um ambiente de data warehousing.
Agora, observe o que vai acontecer porque, ok, há todas essas colunas, veja isso, eu tenho um índice em cada coluna. Agora, em um ambiente OLTP, isso seria um não-não. Isso desaceleraria todas as minhas operações. Em um ambiente de data warehousing, eu os descartava durante meus ciclos de carregamento em lote. Carregue sem a sobrecarga ou os índices, e eu recriaria os índices. E se eu particionasse minha tabela, em vez de ter que soltar o índice de todos os buckets da tabela, poderia simplesmente soltar o índice no bucket ou buckets nos quais os dados seriam inseridos durante o ciclo de carregamento em lote. E, em seguida, recrie apenas a parte do índice para esses buckets. E isso torna muito gerenciável. E se eu olhar - então aqui está uma coluna chamada "Bandeira de férias" e basicamente isso é sim ou não. Observe que este é um índice de bitmap e, para a maioria de vocês, dirá: "Bem, isso faz sentido". Sim ou não, Y ou N, há apenas dois valores que fazem sentido. E porque quando você lê a documentação para índices de bitmap, eles sempre dizem para você escolher algo com baixa cardinalidade.
Agora, deixe-me entrar em uma das minhas tabelas de fatos, então aqui temos meus pedidos. E esses são meus pedidos por dia. E você verá agora que, novamente, tenho algumas colunas e, novamente, terei mais do que alguns índices. E bem aqui, temos algo chamado código de preço universal. Era para uma loja de varejo, então você conhece esses pequenos códigos de barra quando compra algo na loja; esse é o código universal de preços. Agora, existem milhões de códigos de preços universais. Agora, para essa empresa em particular que estava vendendo coisas, eles provavelmente tinham de 1, 7 a 2 milhões de códigos de preços universais, então você espera que este não seja um índice de bitmap, porque 1, 7 milhão de valores distintos parece uma alta cardinalidade. Mas, na realidade, em um ambiente de data warehousing, você deseja que este seja um bitmap. Agora, deixe-me explicar o porquê. Bem, pode haver 1, 7 milhão de valores distintos para esse código de preço universal, o número de linhas nesta tabela de pedidos está entre centenas de milhões e bilhões de linhas. Meu índice é baixa cardinalidade em comparação com o tamanho ou cardinalidade da tabela. Isso torna baixa cardinalidade. Isso torna o índice de bitmap útil, embora seja contra-intuitivo com 1, 7 milhão de valores distintos que você escolheria aqui. Agora, se eu soubesse que queria usar um índice de junção de bitmap, atualmente o produto não suporta isso, estou adicionando isso para a próxima versão, mas essa seria outra alternativa aqui. E, em um esquema em estrela, lembre-se, o índice de bitmap estaria na tabela de fatos e esse índice na árvore B apontaria para a linha na tabela de fatos e, em seguida, para todas as linhas aparentes na tabela de dimensões para esse fato . E então, você tem outra opção lá. Então, vejamos, quero sair das tabelas agora e só quero mostrar rapidamente que tenho as mesmas informações, nos índices, e farei a mesma coisa básica.
Agora, a razão pela qual eu trouxe isso à tona é que você pode perceber: ei, não há chaves primárias aqui. As chaves primárias são feitas com uma restrição de chave; portanto, elas são realmente cobertas pelas definições de restrição. Esses seriam índices que não fazem parte da restrição. Agora você pode dizer: "Bem, espere um minuto, isso pode parecer uma chave estrangeira, e uma chave estrangeira é uma restrição", mas as chaves estrangeiras e a maioria dos bancos de dados não criam automaticamente um índice na coluna da chave estrangeira, mesmo que seja aconselhável, e lá vai você - eu tenho as mesmas opções novamente. E se eu quiser mudar apenas para ser compactado, posso fazer isso.
Agora a compactação funciona apenas em um índice de árvore B. O que isso permite é que, quando você olha para os vários nós na árvore B, ele permite a compactação de alguns dos valores. Realmente não é compactação como a compactação de tabela, é uma compactação do que é armazenado na árvore B nos nós que não são folhas. Não economiza muito espaço, mas pode fazer a diferença. E com isso percebi que estou chegando bem perto do tempo, então o que quero fazer é voltar e interromper meu compartilhamento. Além disso, disponibilizamos nosso produto para um teste de catorze dias no idera.com. É um produto muito bom, especialmente se você trabalha com várias plataformas de banco de dados. Se você trabalha com dois ou três bancos de dados diferentes, essa ferramenta facilitará sua vida. Temos ferramentas para ajudá-lo com o design e a seleção do índice. Temos uma ferramenta chamada DB Optimizer. Eu simplesmente não poderia cobrir isso hoje, isso seria demais. E se você quiser entrar em contato comigo, existe o meu endereço de e-mail, ou você pode me pegar no meu e-mail particular, e eu tenho blogs, tenho um site e blogs e um perfil do LinkedIn lá. Portanto, sinta-se à vontade para me procurar sobre qualquer coisa, mesmo que não seja relacionado ao produto, se você quiser apenas falar sobre bancos de dados, sou um nerd de coração e adoro falar sobre technobabble.
Eric Kavanagh: Tudo bem, bem, Dez, Robin, tenho certeza de que cada um de vocês tem algumas perguntas, pelo menos, temos alguns minutos restantes aqui. Dez, o que você acha?
Dez Blanchfield: Eu tenho uma ótima pergunta que tenho para lhe fazer, ela está no fundo da minha mente. Qual é o cenário mais louco que você já viu? Eu li o seu blog, eu acompanho você de perto, você é provavelmente uma das poucas pessoas que viveu em quase todas as improváveis, e eu acho que o Dr. Robin Bloor é o segundo que eu conheci minha vida. Mas, você sabe, você provavelmente já viu todos os cenários malucos, quais são alguns dos cenários mais loucos que já viu, e se deparou com seres humanos que simplesmente não conseguiam lidar com isso, você conseguiu andar e executar truques mentais Jedi com todo esse DBArtisan?
Bert Scalzo: Certa vez, um cliente teve um cliente que, em seu design de banco de dados, pensava da mesma maneira que pensaria em um design de layout de arquivo, e por isso - quando você normaliza um banco de dados, a primeira coisa que você tenta fazer é se livrar de repetir grupos. Bem, eles tinham uma coluna e a tornavam longa, ou BLOB ou CLOB, e nela colocariam valor, número um, ponto e vírgula, valor número dois, ponto e vírgula, número de valor, ponto e vírgula, e teriam milhares de valores lá, mas eles precisavam pesquisar nessa coluna e pensavam: "Por que essa coisa corre tão devagar?" E eu fico tipo: "Bem, você não pode criar um índice sobre o que fez, é apenas não é permitido. ”Então, na verdade, mostramos a eles, usando os planos, que o que eles precisavam fazer era normalizar essa tabela. Não porque a normalização é um exercício acadêmico que melhora as coisas, mas porque eles queriam uma consulta nesse campo, o que significava que eles queriam poder indexá-la e você não podia indexá-la em um grupo repetido, ou pelo menos não facilmente. . E essa é provavelmente a pior coisa que eu já vi.
Dez Blanchfield: Sim, é interessante quantas vezes você se depara, acho que o desafio com bancos de dados, as pessoas esquecem que é uma ciência. E há pessoas que fazem diplomas e doutores em todo esse espaço, escrevem artigos sobre ele e você escreveu vários artigos, incluindo seus manuais do TOAD e outras coisas da memória. A tendência para o tipo de “big data” entre aspas agora - vejo muitas pessoas esquecendo os fundamentos da arquitetura e tecnologia de banco de dados, ciência de banco de dados, se você preferir. O que você está vendo em campo no que diz respeito à mudança das plataformas tradicionais de banco de dados e do pensamento tradicional de banco de dados que efetivamente acertamos no chão, e foi apenas um caso de ajuste e dimensionamento de desempenho. Você está vendo muitas pessoas reaprenderem e terem uma experiência em que apenas ficam sentadas e têm um momento de “a-ha”, como um momento eureka, em que percebem que esse material de big data é realmente apenas um tipo de banco de dados realmente grande? Isso é algo lá fora, e as pessoas estão respondendo a você de volta e meio que: "Esquecemos o que sabíamos e você pode nos trazer de volta do lado sombrio?"
Bert Scalzo: Bem, não, e isso é horrível de admitir, mas os fornecedores de bancos de dados relacionais também beberam esse Kool-Aid. Se você se lembra, não sei, cerca de uma década atrás, começamos a colocar dados não estruturados em bancos de dados relacionais, o que era uma coisa estranha de se fazer, e então os dados, os bancos de dados relacionais, agora estão adicionando o tipo NoSQL coisa. De fato, no Oracle 12, CR2 - eu sei que ainda não saiu -, mas se você olhar para o beta, se estiver no programa beta, ele suporta o sharding. E agora você tem um banco de dados relacional que não adicionou o conceito do shard NoSQL. E assim, o momento do “a-ha” parece ser mais para as pessoas do lado relacional que estão indo para o “a-ha”. Ninguém nunca fará o que é certo de novo, nem mesmo os gerentes de banco de dados. Tenho que ir e me juntar ao lado sombrio.
Dez Blanchfield: Certo, então você está dizendo uma mudança para muitos dados confusos, se bem entendi, sendo inseridos no que agora chamamos de plataformas de big data, o que é meio engraçado, porque eles são não tão velho, mas isso não significa que eles estão se concentrando no que estão fazendo com o banco de dados relacional para obter mais retorno sobre o investimento?
Bert Scalzo: Não, geralmente, se eles têm uma necessidade na - isso teria citado uma "necessidade de grande tipo de dados", eles estão descobrindo que, em vez de precisar ir para a outra plataforma de banco de dados e fazer algo de forma não De maneira relacional, os fornecedores de banco de dados agora estão dando a eles as mesmas técnicas não relacionais dentro de seu banco de dados relacional, para fazer essas coisas. Quero dizer, um bom exemplo seria, se você tiver dados não estruturados, como um tipo de dados JSON ou algum outro tipo de dados complexo que tenha significado incorporado nos próprios dados, os fornecedores de banco de dados não apenas suportam isso, mas também fornecem ACID conformidade com dados não estruturados. Os bancos de dados relacionais adotaram as técnicas e tecnologias mais recentes e, novamente, o “a-ha” parece não ser mais o seguinte: “Ei, nós, desenvolvedores de aplicativos, desaprendemos algo e precisamos aprender novamente”, é “Ei, fazemos dessa maneira agora, como posso fazer dessa maneira em seu banco de dados tradicionalmente relacional e fazê-lo como faço neste banco de dados por aqui? ”e isso está se tornando mais prevalente e, como eu disse, os próprios fornecedores de banco de dados estão permitindo naquela.
Dez Blanchfield: Certo, quem são os suspeitos tradicionais nesse espaço para a ferramenta DBArtisan e isso? Fiz uma lição de casa sobre o que você escreveu recentemente e, de memória, escreveu algo, acho que era um dos seus blogs, sobre desempenho extremo de banco de dados no mundo Oracle. Não me lembro quando, acho que foi em algum momento deste ano de memória, ou do final do ano passado, você escreveu isso. E pareceu-me que era o suspeito tradicional e usual do tipo de tópico sobre o qual estamos falando hoje, em que as pessoas vão para um ambiente de banco de dados de larga escala e procuram o que você está chamando de ganhos extremos. Quem são os suspeitos de sempre que estão pegando o DBArtisan e colocando-o em bom uso?
Bert Scalzo: Bem, na verdade, temos muitos clientes hoje em dia com uma agência governamental muito grande que - e eles têm literalmente provavelmente perto de 1.000 cópias do nosso software, porque permite que as pessoas se concentrem no que elas ' está fazendo, e não como fazê-lo. E está tudo bem, quero dizer, todos devem saber como fazer algo, mas a produtividade está fazendo o "o que". Se a empresa me pede para executar uma tarefa, é nisso que eles estão interessados. Quando recebi uma marca de seleção para dizer quando a tarefa foi concluída? Não que técnica ou qual technobabble eu usei para chegar lá. E assim, nossa ferramenta permite que eles se concentrem no quê e seja muito mais produtivo, e essa é realmente a grande vantagem e, como eu disse, alguns bancos de dados oferecem uma ferramenta apenas para sua plataforma de banco de dados. Oferecemos para doze plataformas de banco de dados. Eu tenho o mesmo fluxo de trabalho, a mesma interface gráfica do usuário, as mesmas navegações. Se você souber como conceder um privilégio a um usuário ou criar uma tabela ou criar um índice em um banco de dados, poderá fazê-lo nos doze, porque é a mesma aparência e o mesmo fluxo de trabalho. Isso tem um enorme valor para nossos clientes.
Dez Blanchfield: Sim, eu acho, as pessoas querem ganhar muito mais dinheiro com seus recursos humanos. E os dias de ter um especialista individual em Oracle, Ingres e DB2 se foram. Espera-se que as pessoas sejam o Jack de todos os negócios, então eu acho que essa coisa salvou absolutamente suas vidas.
Apenas uma última coisa rápida antes de entregá-la ao doutor Robin Bloor. Você mencionou que há um download gratuito por catorze dias, o que faz - se eu for em frente e fizer isso, a propósito, vou colocá-lo no laboratório de tecnologia da Bloor e girar essa coisa me levantar e pôr as mãos nele - eu não tinha tido a chance de fazer isso antes de hoje. Você mencionou uma avaliação de catorze dias, disse que está executando em uma VM no seu computador, presumo que seja um laptop. Qual é a configuração inicial para alguém ter as mãos e usar o teste de catorze dias, pouco antes de eu devolver a Robin as perguntas dele?
Bert Scalzo: Qualquer ambiente Windows, portanto Windows 7, máquina virtual com uma CPU e quatro GB de memória. Não somos uma ferramenta realmente gorda ou cara. Agora, se você deseja executar o servidor de banco de dados na mesma VM no mesmo Windows, é necessário adicionar mais, mas se estiver executando o banco de dados em um servidor de banco de dados ou em uma VM separada, a VM para carregar e executar nosso produto é muito leve: uma CPU, quatro GB de memória, praticamente qualquer versão do Windows - e suportamos instalações de trinta e dois e sessenta e quatro bits. Mas você precisa instalar o cliente do fornecedor do banco de dados. Portanto, se você quiser se conectar ao Oracle, precisará instalar o SQL net client, porque é isso que o Oracle exige para que você possa conversar com um banco de dados.
Dez Blanchfield: Parece bem direto. Eu acho que uma coisa disso, mais do que tudo, que eu espero que as pessoas tirem, além da percepção de que essa ferramenta vai salvar suas vidas, é que elas deveriam fazer o download e brincar com ela, considerando que você está oferecendo uma avaliação gratuita de catorze dias. E ele pode ser executado em seu laptop atual sem instalar nada extra, porque se eles já estão administrando o banco de dados, já estão trabalhando com bancos de dados, eles têm todas essas ferramentas no lugar e se estão sendo executadas em uma VM local ou na sua na área de trabalho local, parece indolor instalar e brincar. Então, eu recomendo que as pessoas façam isso.
Robin, tenho certeza que você tem perguntas e Eric, provavelmente você tem algumas da platéia, então Robin, que tal eu passar para você e depois voltar para Eric?
Robin Bloor: Sim, ok, bem, tenho coisas a dizer, quero dizer, sempre achei essa área fascinante porque era - eu cortei meus dentes nela. Mas a verdade é que, provavelmente desde 1998, 1999, estou à deriva do que a Oracle é realmente capaz. E eu conhecia o Sybase e o Microsoft SQL Server, ambos bastante simples em comparação com o que a Oracle poderia fazer. Você me fez rir quando você - quero dizer, eu cobri minha boca, quando você começou a falar sobre sharding. A Oracle fez isso antes. A Oracle, introduzida em algum momento, ficou nervosa com a idéia de relação objeto, então, eles introduziram a capacidade de criar um tipo de notação e armazenamento de objetos no Oracle, e conversei com um de seus engenheiros, algo como algumas anos depois que o introduziram, perguntei quantas pessoas o usaram, e ele disse que acho que dois clientes o experimentaram e foi isso. E acho que o mesmo acontecerá se eles começarem a tentar fazer as coisas mais importantes do NoSQL. Sabe, acho que é um erro, quero dizer, estou meio interessada em quais são seus pensamentos. Certamente, eles - eles bebem o Kool-Aid. Eles sentem que precisam ser capazes de fazer reivindicações semelhantes aos grandes bancos de dados NoSQL como o Cassandra, mas você sabe, isso faz algum sentido para você?
Bert Scalzo: Não, você acertou a unha na cabeça. Para mim, se eu for relacional, escolherei um fornecedor relacional como um Oracle, SQL Server, DB2 ou Postgres, mas se vou fazer algo não relacional, no espaço de big data ou no NoSQL, vou escolher a ferramenta certa para o trabalho certo. E eu não acho que isso seria naturalmente direcionado ao meu fornecedor de banco de dados relacional primeiro. E então, você adiciona outras rugas, ou seja, o que está disponível na nuvem? Tantas pessoas querendo tirar seus bancos de dados da premissa. Em seguida, você deve consultar o seu provedor de nuvem e dizer: “Ok, o que você fornece, quais bancos de dados você tem disponíveis para mim que atendem às minhas necessidades e quão vendáveis eles são e, francamente, qual é a taxa ou taxa pelo uso desse banco de dados? na nuvem por hora ou por dia. E por gigabyte ou terabyte? ”E o que você encontrará talvez sejam alguns dos bancos de dados relativamente mais novos, como Mongo ou Cassandra, talvez suas taxas sejam mais baixas, então, se você quiser fazer grandes dados com vários petabytes, talvez é necessário - apenas do ponto de vista dos custos - considerar os bancos de dados NoSQL na nuvem, porque eles podem ser a maneira mais econômica de fazer isso.
Robin Bloor: Sim, certo. Quero dizer, meu tipo de coisa sobre bancos de dados relacionais em minha experiência, que é longa o suficiente para ter cicatrizes, com certeza, há muito senso comum de que se você começar a aplicá-lo e entender o que realmente é relacional, Quero dizer, lembro de ter consultado uma vez um cliente e eles me levaram a uma sala, fizeram um tipo de diagrama de entidades e criaram uma terceira forma normal, um modelo de como eram os principais sistemas da empresa. Tinha duzentas e quarenta mesas e eles disseram: “Bem, o que você acha disso? Nós vamos construir um banco de dados para isso ”, e disse:“ O que você acha disso? ”Eu disse:“ Eu não acho que vai funcionar. ”E é exatamente certo, você sabe, porque eles estavam terminando para criar uma estrutura específica em junções de onze vias. E é isso que você precisa entender sobre relacional. Então, eu estou meio interessado em termos de quanto design ruim você encontra. Quero dizer, não tenho nenhum problema com o DBArtisan - ele está fazendo coisas muito sensatas e o fato de que você pode realmente exibir em várias plataformas, eu acho, é maravilhoso - mas o quanto você encontra por aí em que o design é problemático onde as pessoas poderiam ter resolvido todo o tipo de mágoa se se tratassem de um esquema estelar em vez de ficarem com o floco de neve, sabe?
Bert Scalzo: Bem, não quero parecer presunçoso ou arrogante, mas diria com mais frequência. Claramente, a maioria dos bancos de dados com os quais me envolvo por aí, eles têm problemas ou problemas. O que é bom, porque nossas ferramentas, como a ferramenta de otimização de banco de dados, podem ajudá-los a resolver esses problemas e, mas o que é realmente engraçado para mim, é que muitos dos problemas são os mesmos problemas simples, repetidamente. Outro dia, eu estava trabalhando com um cliente que tinha uma consulta de junção de onze vias, e eu fico tipo "Ok, por que você não usou a cláusula with?" E eles ficam tipo "Bem, eu não não sei o que é isso. ”E então eu disse:“ E olhe para as suas sub-seleções aqui no seu correlato e no seu não correlacionado ”, eu disse:“ Em alguns casos, você tem sua cláusula where no nível mais profundo, uma referência de tabela do exterior. ”Eu disse:“ É, mova para o nível certo, não o incorpore mais do que deveria, pois você confundirá o otimizador. ”E com alguns ajustes, pegou algo que estava rodando cerca de duas horas e reduziu para dez minutos e foi apenas - nesse caso, não fizemos nada além de melhorar o SQL que eles haviam escrito. Eu acho que o problema é que muitas universidades e muitas pessoas que aprendem programação em um ambiente não acadêmico, elas aprendem isso como processos em tempo gravado ou processos orientados a linhas e relacionais, e é um conjunto orientado pela natureza, e você tem que pensar em conjuntos para escrever um bom SQL.
Robin Bloor: Sim, eu acho exatamente isso. E você tem que entender, são coisas assim, as pessoas devem conhecer o ABC de coisas assim. Não importa. Você não será capaz de fazer coisas racionais se não perceber que, mesmo em um banco de dados bem projetado e bem modelado, as junções levarão tempo, as sortes levarão tempo. Eles o fazem porque o mundo nunca encontrou uma maneira de fazê-lo ir rápido. Eles descobriram maneiras de organizar os dados para que eles sejam mais rápidos do que o contrário, e muito do entusiasmo que tenho a dizer pelos bancos de dados NoSQL é simplesmente que eles estão evitando fazer junções. Eles apenas começam a construir os bancos de dados com a mesma propagação de dados, porque se você ingressar em qualquer um dos bancos de dados NoSQL, eles serão muito ruins. Você não acha?
Bert Scalzo: Ah, com certeza. E eu tenho que rir porque, eu comecei muito antes dos bancos de dados relacionais e quando Ingres era RTI, Relational Technology Institute, e não tínhamos SQL, tínhamos linguagens relacionais pré-SQL. Eu acho que em Ingres, naquela época, chamava-se Quel. Então, você pegou desses paradigmas antigos de banco de dados, como rede e um gráfico mais alto, ou hierárquico, e percorre os paradigmas relacionais depois de algumas décadas. Agora, para mim, parece que estamos voltando a um estado quase hierárquico novamente. É quase como se tivéssemos revertido.
Robin Bloor: Sim, certo. É melhor você falar com Eric, estou consumindo muito tempo, mas temos alguma dúvida da platéia, Eric?
Eric Kavanagh: Sim, temos alguns. Vamos demorar um pouco aqui, mas eu jogarei um par em você. Tivemos algumas perguntas sobre os índices invisíveis. Uma pergunta era: "Alguém precisa usar sua ferramenta para vê-la?". Outra pergunta era: "Bem, e se você é cego?"
Bert Scalzo: Essa é boa.
Eric Kavanagh: Pergunta curiosa também, então apenas para sua informação.
Bert Scalzo: Não, você não precisa de nossas ferramentas. Esse é um recurso da Oracle, o índice de invisíveis. Basicamente, no dicionário de dados, a Oracle mantém apenas um pedaço de metadado que diz: “Otimizador, ignore esse índice. Está aqui, mas, a menos que você seja instruído fisicamente por meio de uma dica no comando otimizador no comando SQL, não use isso. ”E, portanto, não, você não precisa ter nossas ferramentas e, sob todos os aspectos, é um índice antigo simples, você pode vê-lo em qualquer ferramenta, é apenas o otimizador que dirá: "Nós o ignoraremos no processamento normal de consultas". Você deve direcioná-lo se quiser que ele seja usado. É realmente útil para o cenário que descrevi, que é o seguinte: se você deseja criar um índice em produção, mas não corre o risco de quebrar os relatórios ou as coisas que já estão em execução, mas deseja testá-los, pode fazê-lo. É para isso que é mais útil.
Eric Kavanagh: Isso é bom e depois houve outra boa pergunta aqui. “E alguns desses novos bancos de dados em memória? Como a tecnologia de banco de dados na memória muda o jogo em relação à indexação? ”
Bert Scalzo: Rapaz, bem, nós - agora isso é bom, fico feliz que alguém tenha feito essa pergunta, teremos que passar mais meia hora. Não, a memória depende do fornecedor do banco de dados. Agora, normalmente, não falo nada além de elogios a qualquer coisa que a Oracle faça, porque é incrível a tecnologia que eles criaram, mas quando você se esconde atrás das cobertas e vê o que há na memória na Oracle, na Oracle banco de dados, o que é, na realidade, ainda é mantido o armazenamento de linhas em disco e será carregado na memória de armazenamento de colunas e, se houver memória insuficiente para armazenar toda a tabela, ele voltará para as partes; ele não cabe na memória, no armazenamento de linhas e, portanto, você pode realmente selecionar contra a tabela e, para metade da tabela, está usando uma indexação que bate nas linhas tradicionais da tabela e na outra metade de o select está realmente saindo e apenas pegando tudo, desde uma pesquisa na memória e, portanto, é diferente na maneira como o SQL Server, por exemplo, o implementou com a tecnologia Hekaton, você sabe, e o SQL 2014, e foi aprimorado no SQL 2016, mas em alguns aspectos, a deles é uma versão mais verdadeira da memória e, mas cada implementação tem prós e contras, mas é preciso olhar para os bastidores e perceber. Porque, eu tive um cliente que disse: "Oh, esta tabela está na memória - apenas elaborarei todos os índices" e fico tipo "A tabela é maior que a memória que você tem no servidor, então, em algum momento, algumas das consultas precisam atingir o disco ".
Eric Kavanagh: Essa é uma boa descrição; isso é bom. Bem, pessoal, teremos mais alguns webcasts com esses caras durante o resto do ano, voltem sempre que você ouvir que Bert está em uma apresentação porque sabemos que ele sabe o que quer. É sempre divertido conversar com os especialistas. Arquivamos todos esses webcasts para visualização posterior. Aqui estão as informações de contato de Bert mais uma vez, e tentaremos desenterrar esse link para o download e enviá-lo também por e-mail, mas você sempre pode enviar o seu por e-mail de verdade: temos mais webcasts alinhados para isso ano e estamos editando agora, então pessoal, se houver algum tópico que você realmente queira ouvir no próximo ano, não seja tímido: cuidado, pessoal, falaremos com você na próxima vez. Tchau tchau.
Parceiro de conteúdo Techopedia
A equipe do Techopedia é afiliada ao Bloor Group e pode ser contatada usando as opções à direita. Para informações sobre como trabalhamos com parceiros do setor, clique aqui.- Perfil
- Local na rede Internet
