Indice de locura: cómo evitar el caos de la base de datos

Por el personal de Techopedia, 5 de octubre de 2016

Para llevar: El anfitrión Eric Kavanagh discute la indexación de la base de datos con el Dr. Robin Bloor, Dez Blanchfield y Bert Scalzo de IDERA.

Actualmente no has iniciado sesión. Inicia sesión o regístrate para ver el video.

Socio de contenido de Techopedia

El personal de Techopedia está afiliado a Bloor Group y puede contactarse usando las opciones a la derecha. Para obtener información sobre cómo trabajamos con socios de la industria, haga clic aquí.

• Perfil
• Sitio web

Eric Kavanagh: Damas y caballeros, hola, y bienvenidos nuevamente. Es un miércoles a las cuatro en punto del este, y aquellos de ustedes que conocen el programa, saben lo que eso significa, es hora de otro episodio de Hot Technologies. Si, de hecho. Mi nombre es Eric Kavanagh, seré su moderador para la sesión de hoy: "Index Insanity: How to evitar el caos de la base de datos". O como lo mencioné en la última explosión de correo electrónico que salió, "disputa de base de datos". Término candente en estos días, "disputa". Todos lo hacen. Hay una diapositiva sobre la tuya de verdad. Y lo suficiente sobre mí.

Por lo tanto, la serie Hot Technology realmente fue diseñada para definir un espacio en particular, a diferencia de la Briefing Room, que es solo una sesión informativa individual para analistas en vivo, para Hot Tech tenemos dos analistas. Hoy será nuestro propio Doctor Robin Bloor y nuestro científico de datos Dez Blanchfield. Y estamos hablando de un tema que creo que es realmente emblemático de lo que está sucediendo en el mercado hoy.

La conclusión es que estamos en un mundo de complejidad en estos días. Realmente, si piensas en quince años, o veinte años, era un mundo muy diferente en ese entonces, especialmente con respecto a la tecnología de bases de datos. Las bases de datos solían ser bastante simples. Solo había un puñado de ellos; la mayoría de ellos eran relacionales. Ahora, tenemos toda esta panoplia de tecnologías de bases de datos. Literalmente, hay muchas opciones sobre la mesa para cualquier persona que quiera crear una aplicación o hacer algo con datos. Todo está cambiando y eso afecta a las personas que intentan administrar estos sistemas. Vamos a hablar hoy con Bert Scalzo, quien es un verdadero experto en el campo; él es el gerente de productos senior de IDERA, sobre lo que puede hacer para manejar todos esos datos. Con eso, se lo entregaré al Doctor Robin Bloor para que se lo quite. Robin, el piso es tuyo.

Robin Bloor: Bien, gracias por esa presentación. Lo creo, porque es una cuestión de dos manos, creo que solo hablaría sobre la optimización de la base de datos en general como una introducción a este espectáculo Hot Tech. Comencé mi vida, en tecnología y análisis, comencé a hacer esto porque solía escribir artículos sobre las capacidades de las bases de datos en la plataforma DEC VAX. Y por esa razón, los gastadores de bases de datos solían informarme. Y lo que me ocurre es que, ¿por qué tendrías una base de datos? Quiero decir, en esos días una gran cantidad de personas solía crear archivos de valores clave y usarlos para tener una especie de falacia secuencial de índice como los llamamos, pero para crear una especie de capacidad de base de datos, y ya sabes, ¿por qué tendrías ¿Algo más?

Y la respuesta a eso, creo que Michael Stonebraker dio la mejor respuesta a eso, y dijo: "Una base de datos puede saber más acerca de dónde están los datos y qué tan rápido obtenerlos, de lo que cualquier programa puede saber". Y creo que es interesante; Es la naturaleza del juego. Pero en el año 19, bueno, alrededor de 1989, que comencé en el análisis de tecnología y, ya sabes, en ese momento las bases de datos eran muy simples y las bases de datos relacionales eran súper simples. Tenían muy poca capacidad, es decir, podían almacenar datos, obviamente, y usted podía hacer una copia de seguridad y tenían, eran compatibles con ACID, pero realmente tenían optimizadores muy débiles. De hecho, sería difícil argumentar que tenían la capacidad del optimizador.

Y más tarde mejoraron cada vez más, pero, ya sabes, cuando una base de datos no funciona, ya que estos canguros parecen estar indicando de una forma u otra, puede haber muchas razones por las que va lento. Y eso me lleva al punto: las bases de datos tienen muchas funciones, pero la más importante es la optimización de consultas. Si no hicieran eso, no los usarías. Se trata de obtener información rápidamente, se trata de poder hacerlo cuando hay muchos usuarios concurrentes, y ese es un problema difícil. Y si realmente mira el, llamémoslas bases de datos maduras, si lo desea, pero ciertamente Oracle, en menor medida, Microsoft SQL Server, ciertamente Teradata y DB2, los optimizadores de esas bases de datos han tenido décadas en el edificio. Ya sabes, no lo hicieron, alguien no se sentó, seis chicos en un proyecto de dos hombres, año, y simplemente golpearon a uno juntos. No funciona así. La capacidad de optimización ha crecido gradualmente, y se necesita mucho crecimiento. De todos modos, hablemos sobre los antecedentes de la base de datos. Bueno, ahora se dice mucho sobre la base de datos NoSQL, e incluso hay mucho entusiasmo por la base de datos gráfica. Y el uso de SQL sobre Hadoop y cosas así. Pero, la verdad del asunto es que si quiere una base de datos en este momento, si quiere una OLTP completamente funcional, capaz de tráfico de consultas grandes, es una base de datos relacional, o no es nada.

Entre las bases de datos relacionales, Oracle es dominante en popularidad. Microsoft SQL Server, creo, es el segundo. Ambos son capaces de ser utilizados para OLTP y la carga de trabajo de consulta, pero en realidad no se puede evitar mezclar esas cargas de trabajo. Necesita diferentes incidentes para cargas de trabajo OLTP y cargas de trabajo de consulta. Hay alternativas a SQL y gráfico. La mayoría de las empresas se estandarizan en una base de datos específica, por eso, quiero decir, después de décadas de luchar con todos los demás jugadores, Oracle se convirtió en la más dominante. Simplemente porque terminaron siendo capaces de vender licencias corporativas, por lo que las empresas solo usarían productos alternativos en productos excepcionales, Oracle simplemente no los haría. Y las bases de datos son estratégicas porque también evolucionan. Y sabes que hice un poco de investigación para esta presentación, y es algo así como: lo haré en un tiempo, pero es interesante cómo evolucionan, en términos de verlo desde la posición de un DBA. Esto es lo que yo llamo la tendencia invisible. Es la ley de Moore en cubos. Es más o menos así: la base de datos más grande es, y nuevas bases de datos, no hay una base de datos antigua que tenga muchos más datos para ingerir. Normalmente es una base de datos que se aplica a un nuevo problema. Y en realidad crecen en términos de volúmenes de datos. Aproximadamente en el cubo de Moore ley. Entonces, la ley de Moore es un factor de diez veces cada seis años. Los VLDB tienden a crecer un factor de mil cada seis años. En 1991, 1992, las grandes bases de datos se miden en términos de megabytes. En el '97 y '98, gigabytes. 2003, '4, terabytes. 2009, '10, comenzaste a ver bases de datos de petabytes. Creo que posiblemente había una o dos bases de datos de exabytes en este momento, pero la más grande de la que he oído hablar es de los 200 petabytes a tiempo, y ya sabes, no obtener datos en una base de datos de petabytes. Pero, la mayor parte de eso obviamente serán las nuevas grandes empresas web 2.0, posiblemente, tienes a Facebook yendo en esa dirección.

Pero de todos modos, si realmente mira eso, esperando que una base de datos pase por ese tipo de escalada en volumen, está pidiendo mucho. Y notablemente, ciertamente hasta el nivel de petabytes, parece que les ha ido razonablemente bien. Quiero decir, estoy hablando de los productos más antiguos en lugar de algo nuevo. Parecen haberlo hecho extraordinariamente bien. Si observamos el rendimiento de la base de datos, los cuellos de botella, esto me lleva de vuelta al momento en que solía preocuparme por ellos y tenía que preocuparme por ellos. Sabes que esto es fundamentalmente el colapso del hardware. Hay cuellos de botella en la CPU, posiblemente, hay cuellos de botella en la memoria, posiblemente, hay cuellos de botella en el disco, posiblemente. Puede ser la red la que te causa dolor, y también puedes tener problemas con el bloqueo, dependiendo de lo que estés haciendo, pero normalmente es porque el programa no sabe a quién llamar bloqueo. Entonces, si va a ajustar una base de datos, en realidad está tratando de ajustarla para que baile entre estos cinco posibles cuellos de botella, así como puede hacerlo. Y eso no es fácil, porque la cantidad de memoria que puede configurar en un servidor dado aumenta drásticamente. Luego, las CPU se han convertido en multinúcleo, disco, bueno, ahora podemos hacerlo, creo, incluso en servidores básicos, creo que puedes hacer cientos y cientos de terabytes, un cuarto de petabyte, tal vez, incluso en un servidor básico. Entonces, de todas estas cosas, puede jugar, la red, por supuesto, puede ir a diferentes velocidades, pero sobre todo cuando se trata de bases de datos, realmente desea tener cables de fibra entre los servidores y nada más que se ejecute en eso, en particular de esa manera.

Factores de rendimiento de la base de datos. Quiero decir, estoy dejando de lado de qué se trata todo esto, porque sé que Dez va a hablar de eso, pero el mal diseño de la base de datos significa una base de datos de bajo rendimiento. El mal diseño de la programación puede significar arrojar SQL muy estúpido a una base de datos, lo que llevará mucho más tiempo. Concurrencia y mezcla de carga de trabajo, demasiada concurrencia causará problemas de cuello de botella. La mezcla de la carga de trabajo, cuando tiene consultas grandes con consultas muy pequeñas, cortas y nítidas, que causa problemas. Hay un problema de equilibrio de carga. La mayoría de las bases de datos se encargan de eso, pero si no tiene un producto sofisticado, entonces, solo agregar algunos servidores, no es todo lo que debe hacer si realmente desea aumentar el tamaño de un clúster. En realidad, debe equilibrar la carga antes de obtener el rendimiento óptimo. Necesita hacer planificación de capacidad. Absolutamente. Especialmente ahora en estos días como cuando los volúmenes de datos aumentan más dramáticamente de lo que solían hacerlo para las bases de datos. Y hay problemas de la capa de datos completos sobre cómo ingiere los datos, cómo mueve los datos. No llevar los datos a una base de datos a tiempo puede ser un problema de rendimiento más adelante porque hemos pasado de las bases de datos que funcionan en Windows, a las operaciones de veinticuatro por siete por trescientos setenta y cinco y no hay ventanas en las que pueda ralentizar el funcionamiento. base de datos abajo o es poco probable que haya hoy en día.

El problema de Oracle DBA. Esto es lo que estaba pensando. He estado en el DBA de Oracle con Oracle 7, y recuerdo cómo ajustar eso. Y si realmente mira Oracle ahora, es mucho, mucho más capacidad. Tiene indexación de mapa de bits y cosas por el estilo, pero en realidad me tomé el tiempo de mirar y ver cuántos parámetros de ajuste hay realmente en una base de datos Oracle en este momento. Y hay más de trescientos cincuenta parámetros de ajuste y hay otros cien parámetros ocultos, que los DBA especializados pueden conocer, pero los DBA Oracle normales no conocen. Y eso significa que ajustar este tipo de base de datos es algo difícil. No es una cosa simple en absoluto. Debes sentirlo, debes haberlo estado haciendo durante mucho, mucho tiempo, y debes saber exactamente cuál es el problema que crees que estás resolviendo, porque el ajuste comienza cuando el rendimiento se vuelve pobre, pero podría no ser el rendimiento de todo. Puede ser el rendimiento de consultas específicas lo que importa, y es posible que pueda solucionarlo fijando ciertos datos y memoria, o puede que necesite arreglarlo indexando, o puede necesitar comenzar a realizar particiones de una manera diferente. Hay muchas cosas que puedes hacer, es el punto. Por lo tanto, en consecuencia, no lo van a hacer mentalmente: los DBA necesitan herramientas. Ahora pasaré a Dez, que te contará sobre indexación, creo.

Eric Kavanagh: Muy bien Dez, quítatelo.

Dez Blanchfield: Gracias, Robin, y me encanta la portada. Creo que has arrojado el guante para que yo venga, incluso me acerque remotamente a algo tan emocionante. Pero he usado una imagen de nuestra pequeña galaxia, como mi punto de vista en lo que se ha convertido el desafío de hoy para los administradores de bases de datos, porque esta es la imagen mental que tiendo a conjurar cuando entro en un entorno y ya no estoy en el mundo de administrar bases de datos o diseñar bases de datos a ese nivel. Pero, como usted, Robin y yo hemos estado involucrados durante muchos años en el mundo de las bases de datos, ya sea como administrador o desarrollador, o eventualmente arquitecto, y luego nos dimos cuenta de que podía hacer mejores cosas para ganar una costra. Pero sí parece que estás mirando esta galaxia de datos, y más aún hoy, cuando pasamos de, como dijiste, hemos pasado de megabytes a petabytes y exoescala en un período de tiempo muy corto., en el gran esquema de las cosas. Pero la frase que tengo en mente es que los índices de bases de datos ahora son un arte negro y no son realmente el tipo de cosas en las que los simples mortales deberían meterse, para aplicaciones comerciales de nivel empresarial y el tipo de formulación solo estábamos hablando. Pero, quería analizar rápidamente el tipo de historia que he tenido con los mundos de las bases de datos y ponerlo en contexto para llegar a una conclusión, y luego revisar algunos materiales hoy con nuestros amigos en IDERA, porque creo que hay muchas ideas diferentes sobre cómo obtener el ajuste del rendimiento de la base de datos y una de ellas es arrojar estaño a la cosa. Para muchas tiendas con las que me encuentro, invariablemente no llegan al punto de hacer ajustes de rendimiento en la capa de base de datos y particularmente en la capa de índice hasta que hayan superado la difícil ruta de pensar que pueden lanzar un sintonizador. .

En mi opinión, mucha gente simplemente le da un gran enfoque, y tengo una foto de The Flash aquí porque si alguna vez has visto alguna película antigua o el último programa de televisión con The Flash, como en Flash Gordon, el viejo personaje, y ahora que se llama "The Flash", tiende a ir muy, muy rápido e invariablemente su energía se agota. Y esto es lo que sucede cuando arrojas mucho hierro al rendimiento de la base de datos. Invariablemente, en mi experiencia, puede poner un alto rendimiento, trabajo duro en el juego, puede optimizar sus sistemas operativos y ajustarlos a un cierto punto. Puede asegurarse de que tiene CPU multinúcleo y multiproceso rápidas para que la aplicación se ejecute más rápido, puede arrojar mucha RAM, puede tener placas posteriores de alto rendimiento, puede pasar de discos duros a discos duros en caché a estado sólido y matriz de almacenamiento de alto rendimiento. E incluso ahora, las personas lanzan cosas como flash y NVMe en sus motores de base de datos, pensando que van a obtener este inicio de sesión por dos aumentos de rendimiento. E invariablemente obtienen algo de ganancia. Pero, todo vuelve a los mismos problemas básicos de ajuste de rendimiento. Muchas conexiones de red de baja latencia, para que los clústeres funcionen rápido. Y de agrupar la infraestructura de la base de datos, para que tenga más de una máquina haciendo todo el trabajo. Pero tiende a volver al mismo problema de rendimiento básico, y eso es leer datos. Escribir datos, en su mayor parte, es un desafío bastante lineal y, a menos que se haga correctamente.

Y luego tenemos el desafío en el mundo de hoy: no todas las bases de datos se crean de la misma manera. Hay bases de datos y una "base de datos" entre comillas. Y cuando pensamos en los motores de bases de datos, las personas a menudo piensan en los sospechosos tradicionales y habituales como en el mundo SQL. Ya sabes, tenemos Oracle y Microsoft SQL Server, y hay un par de ellos en el mundo de código abierto con MySQL, que ahora es propiedad de Oracle, pero aún es de código abierto. Y luego tenemos los sospechosos no tan habituales, los motores NoSQL, que todavía tienen un problema en torno a la indexación y la gestión del rendimiento, y no los abordaré con mucho detalle, pero hay un número creciente de estos las cosas surgen todos los días y se ven y se sienten como motores de bases de datos desde el punto de vista de los desarrolladores y desde el punto de vista del rendimiento, pero son bestias muy, muy diferentes y tienen su propio pequeño nicho en el mundo para crear rendimiento en memoria o escala lineal en disco. Pero así es como se ve el mundo en el mundo de la base de datos. Este es el 2016, esta es la versión tres del mapa de, por una variedad de personas que producen este mapa de paisaje continuo de cómo se ven las bases de datos, y aquí es donde, ni siquiera un arquitecto de bases de datos sobrehumano o un administrador de bases de datos podría tener sentido de eso. Literalmente cientos, cientos y cientos de diferentes marcas, modelos, fabricantes de bases de datos, invariablemente compatibles con SQL. Y lo interesante es que todos vuelven al mismo desafío. Rendimiento y ajuste del rendimiento en torno al motor de base de datos, y particularmente por cómo se indexan los datos.

Así que cubramos rápidamente la indexación de la base de datos, porque es un tema interesante, y creo que debe profundizar en él con la demostración. Pero, creo que es bastante bien aceptado y una práctica estándar de la industria que el ajuste del rendimiento del índice de la base de datos es donde el mundo comienza y termina para garantizar que sus datos sean accesibles en un formato rápido y rápido. Pero, ¿qué es la indexación de bases de datos? Si pensamos en indexar en la forma en que estamos acostumbrados como humanos cotidianos, pensemos en una página de índice en un libro. Si desea encontrar algo en un libro, particularmente los gustos de una enciclopedia, o algo así como un material de referencia de alguna forma, si está buscando algo como esta página, donde estoy buscando cosas como el tema de las presas en una enciclopedia Quiero encontrar todas las referencias a las presas, la captación de agua y una gran área de acumulación, generalmente hecha por el hombre. Iré al final, lo encontraré en una lista ordenada alfabéticamente, de la A a la Z, de izquierda a derecha, y encontraré D. Encontraré la palabra "represas" y puedo ver eso en páginas 16, 38, 41 hay una referencia a ellos, y luego puedo ir a esas páginas, puedo escanear mis ojos y encontraré la referencia a la palabra "presa". Es esencialmente el mismo concepto en una base de datos, pero ahora es una ciencia espacial de muchas maneras. Tanto es así, que efectivamente todos los administradores de bases de datos que he conocido bien consideran que los índices son la herramienta más crítica para el ajuste del rendimiento en cualquier mundo de bases de datos, independientemente de cuál sea su experiencia en cuanto a tirar estaño, o cualquiera sea el caso.

En general, cuando hablamos de indexación de bases de datos, hay una serie de enfoques comunes. Y cuanto más complejos se vuelven los índices de la base de datos, más complejo es el enfoque para indexar datos. Pero esencialmente cuando piensa en indexar datos, imagine que tenemos un archivo que tiene una lista de nombres; no pueden clasificarse en orden alfabético. Imaginemos que hay veinte de ellos. Si vamos a ordenar, si vamos a buscar datos en esa lista, de arriba a abajo, y digamos que es una lista de nombres. Si elijo un nombre aleatorio y empiezo a desplazarme por esa lista, de arriba a abajo, en un formato lineal y es una lista desordenada, hay dos criterios que considero como mi tiempo de búsqueda promedio y mi tiempo de búsqueda máximo, y Tengo un error tipográfico en la segunda línea, debería ser "tiempo de búsqueda máximo", lo siento, pero mi tiempo de búsqueda promedio es esencialmente N más uno, dividido por dos, y eso es en promedio, me lleva el cincuenta por ciento del tiempo para escanear desde la parte superior de la lista, hasta el final de la lista para encontrar cualquier cosa aleatoria en esa lista. Y la segunda línea allí, debajo de lineal, debería ser "tiempo de búsqueda máximo". Pero el tiempo de búsqueda máximo es esencialmente el número de elementos, y eso es que si tengo una lista de veinte cosas, la mayor parte del tiempo puede llevarme buscar algo en esa base de datos es ir de arriba a abajo, es decir, 20 elementos en este ejemplo simplificado. Y es un proceso muy lento y realmente no hay forma de ajustar el rendimiento. Y luego, hay otros tipos de formas de tomar esos datos y crear un índice, que es efectivamente una lista corta de punteros a donde están los datos reales, como binario, árbol B, mapa de bits, hashing, agrupados y no agrupados, y luego hay diferentes tipos de datos como espacial, filtrado, XML y texto completo.

Binary es uno de uso muy común para cosas donde los datos se prestan a él. B-tree es probablemente el más común en un sentido general, históricamente, ya que es una forma común de estructurar un índice para cualquier forma de datos y permite que los registradores, selecciones e inserciones y eliminaciones sean relativamente fáciles a medida que mueve los punteros por el referencia a los punteros, los puntos. Hay otros tipos, como el mapa de bits, donde los tipos de datos se refieren como si tenemos un rango asociado de alguna forma. El hash funciona muy bien para objetos grandes, particularmente blogs e imágenes. Y puede ver que hay varios tipos diferentes de enfoques científicos, enfoques matemáticos, para indexar datos. Para el simple mortal, son un desafío interesante para hablar en este nivel. Cuando se habla sobre el nivel de rendimiento para un administrador de base de datos, realmente se convierten en científicos de cohetes y las personas obtienen títulos en ellos, y sé que el Doctor Robin Bloor ciertamente lo ha hecho, y ha escrito libros sobre él para los gustos de IBM y otras grandes marcas en las últimas décadas. Y así, mi punto de vista es que en realidad hemos pasado un tiempo en el que, una vez, yo personalmente podría sentarme frente a un sistema y podría separarlo y mostrarle exactamente dónde estaban los problemas de rendimiento en una línea de comandos o en una herramienta de inicio de interfaz gráfica de usuario, y comenzar a profundizar en los datos y decirle dónde estaban los problemas, y construir índices, o subíndices, o índices primarios y secundarios en ese datos y comenzar a usarlos para encontrar cosas. Pero cuando piensas en ese panorama que te mostré, donde tenemos cientos y cientos de marcas, marcas y modelos, y fabricantes y tipos de bases de datos, ahora estamos realmente y realmente pasados ​​ese tiempo, donde un ser humano puede hacer sentido de los tipos de motores de bases de datos que tenemos. Particularmente, incluso si volvemos a los gustos de Oracle, las marcas predominantes en estos días en las plataformas de bases de datos relacionales.

La cantidad de bases de datos con las que tienen que lidiar, ya sea desde una plataforma patentada como un ERP o RRHH o un sistema financiero, o si son una plataforma casera por varias razones, la cantidad de bases de datos y tablas y registros de bases de datos que terminamos tratar son astronómicos y físicamente no puedes hacerlo a mano. Y hemos tenido una complicación adicional ahora, donde una vez, un servidor de base de datos podría simplemente sentarse debajo de su escritorio. Sabes, cuando era niño después de la escuela, solía ir y trabajar en software de base de datos en, originalmente, Apple IIes y luego sistemas basados ​​en PC DOS, como dBase II, dBase III, pasaron por una era con mainframes y mid- rango e incluso VAX y PDP y archivo de registro en eso. Y lo mismo que Sabre, y finalmente cuando aparecieron algunas de las bases de datos SQL. Pero en estos días, cuando estamos pensando en los motores de bases de datos, se ven como la esquina inferior izquierda. Un servidor de base de datos ya no es solo una máquina sentada en el piso debajo de un escritorio; son cientos de máquinas que ejecutan copias de motores de bases de datos y clústeres, y escalan hasta cientos y cientos de terabytes de datos, si no petabytes de datos, que son miles de terabytes. E incluso hasta el extremo, como mencionó el doctor Robin Bloor, que algunos casos de uso específicos (aerolíneas, agencias gubernamentales en particular) pueden llegar a exabytes. Todavía son bastante nicho, pero cientos de terabytes e incluso docenas de petabytes ya no son inusuales, particularmente desde el boom de las puntocom hasta ahora, algo así como lo que llamamos compañías web 2.0, como Facebook, Google, Yahoo Etcétera.

También tenemos la complicación ahora que las cosas se están moviendo a un servicio externo. Tenemos una plataforma de infraestructura y un enfoque de software como servicio que proporciona infraestructura. Y particularmente el servicio de plataforma donde no podemos simplemente comprar para los gustos de Oracle y su plataforma en la nube, bases de datos y servidores. Y esto nos permite hacer un desarrollo muy rápido de la aplicación y simplemente conectar una base de datos a los servidores. No tenemos que pensar en lo que hay debajo del capó. La desventaja es que a menudo no pensamos en cómo diseñamos e implementamos la base de datos nuevamente hasta que comienza a doler y el rendimiento se convierte en un problema y luego terminamos buscando la herramienta adecuada para diagnosticar por qué nuestra base de datos está dañada y donde están los problemas de rendimiento. E invariablemente lo devuelve a ese problema común de cómo hemos indexado esos datos y los tipos de índices que hemos utilizado para esos datos y que luego nos devuelve al requisito de rendimiento sobrehumano. Y alguien que tiene acceso a los sistemas correctos y las herramientas adecuadas para el rendimiento ajusta esos motores, y comienza a encontrar un punto caliente y mira dónde están las consultas, dónde se mueven los datos, los tipos de consultas, cómo están estructuradas las consultas, quién está haciendo las consultas, y si las consultas se están poniendo en cola y si tienen que almacenarse en caché. ¿Qué replica buscas?

Y así, estamos bien y verdaderamente, en mi opinión, en un punto en el que incluso los mejores gurús de bases de datos del mundo, esencialmente nuestros arquitectos de bases de datos y nuestro administrador de bases de datos y bases de rendimiento, en mi opinión, necesitan comenzar a aprovechar las herramientas adecuadas para ofrecer un ajuste óptimo del índice de rendimiento para cualquier motor de base de datos. Debido a la escala con la que estamos tratando y la velocidad a la que se mueven las cosas, simplemente no podemos hacerlo a mano, e intentar hacerlo invariablemente puede introducir otros problemas de rendimiento, porque es posible que no tengamos experiencia en ese espacio que estamos tratando de resolver un problema. Y creo que ahí es donde estamos a punto de entregarle a Bert, y estamos a punto de hablar sobre cómo han resuelto este problema variado y el tipo de cosas que su herramienta puede hacer, particularmente para el mundo de Oracle. Y con eso allí, Bert, te voy a pasar.

Bert Scalzo: Gracias. Bienvenidos a todos, mi nombre es Bert Scalzo, trabajo para IDERA. Soy el gerente senior de productos de algunos de nuestros productos de bases de datos. Hoy demostraré algunos de esos. Pero quiero hablar sobre los índices, porque estoy de acuerdo con todo lo que todos han dicho aquí, especialmente la última diapositiva, que los índices son tan complejos ahora que necesita una herramienta, y espero convencerlo. Por lo tanto, el diseño del índice de Oracle no es tan fácil como solía ser en los viejos tiempos. Muchas personas no estarán seguras de sí mismas cuando vean las opciones, y me gusta decir que me retiré de la historia, "en estos asuntos, la única certeza es que nada es seguro". Y así es como yo piensa en los índices en estos días, porque incluso si crees que sabes que la respuesta debería indexar X, Y o Z, realmente no puedes estar seguro hasta que lo pruebes, porque esos optimizadores a veces se comportan de manera diferente a lo que esperas. Y entonces hay mucha prueba y error con el diseño de índice. Ahora, en los viejos tiempos, si necesitabas un índice, generalmente solo había dos preguntas, o una pregunta. ¿Fue único o no fue único? Y es posible que haya pensado en otras cosas como "¿Cuántos índices puedo tener como máximo en una sola tabla?" Porque demasiados índices ralentizan sus inserciones, actualizaciones y eliminaciones. También podría haber estado en su sistema de base de datos, tener restricciones sobre cuántas columnas podrían estar en un índice de varias columnas, porque a veces había límites basados ​​en el tamaño de página o bloque de su motor de base de datos, pero en realidad era bastante simple. en los viejos tiempos O lo indizaste o no lo hiciste. Y realmente, todo estaba en un árbol B. Podríamos permitir los duplicados o no, y eso fue todo. La vida era buena, la vida era simple.

Bueno, hoy la vida no es tan buena ni tan simple. Puse el signo rojo de Ghostbuster en la forma en que solíamos hacerlo, porque ahora tenemos B-tree versus bitmap, versus bitmap join. Y voy a explicar cuáles son algunos de estos en un momento. Agrupado y no agrupado, único o duplicado, orden directo o inverso, basado en funciones, particionado o no particionado. Si hay particiones involucradas, ¿es una partición global o local? Te lo explicaré también. Y luego también hay algo llamado una tabla organizada indexada. Y en realidad hay media docena más que he dejado fuera de aquí, porque creo que tengo suficiente aquí ahora que debería convencerlo de que los índices son mucho más difíciles de lo que podría haber pensado. En esta diapositiva en particular, voy a comenzar en la parte superior izquierda del diagrama y tengo una tabla. Y lo primero que tengo que decidir es, según la versión de su base de datos y su proveedor de base de datos, ¿permiten tablas de objetos o son solo relacionales? Voy a bajar por el lado derecho y decir que estamos construyendo una tabla relacional. Ahora, la siguiente pregunta que tengo que hacerme es, ¿está en un grupo? Y muchos de ustedes que han hecho Oracle por algún tiempo recordarán que los clústeres regresaron para los 6 días de Oracle. Probablemente ya no se usan mucho hoy en día, pero primero déjenme bajar esa rama.

Si iba a poner mi tabla en un clúster, tendría que tener un índice agrupado en esa tabla. Ahora, en Oracle, cuando agrupabas una tabla, básicamente estabas almacenando las filas o las filas estaban cerca unas de otras donde los valores eran similares. Por lo tanto, debe tener un índice agrupado y ese índice agrupado podría no estar particionado. En otras palabras, en realidad no había ningún método de partición de cómo haría una tabla en clúster. Fue estrictamente no particionado. Y debido a que no estaba particionado, era global. Explicaré qué es global en un minuto. Y siempre fue el árbol B. En otras palabras, cuando bajé esa rama, era bastante simple, no tenía muchas opciones. Ahora, si hice un índice no agrupado en una tabla agrupada, que estaba permitido en algunas versiones, nuevamente no estaba particionado; cuando no está particionado, entonces su única opción es global. Y así, allí tienes la opción de B-tree o bitmap. Nuevamente, dependía de su versión de la base de datos. Pero ahora, regresemos a la tabla relacional y comencemos a bajar por el lado derecho nuevamente, y ahora vamos a tener una tabla simple, antigua, regular, con pilas: relacional. Va a estar en una mesa. Voy a bajar por el lado derecho aquí primero. Entonces es organización, montón. La siguiente pregunta que tengo que hacerme es: "¿Quiero particionar esta tabla o no?". Ahora, a veces lo dividirías porque pensaste: "Oye, el optimizador será más inteligente acerca de cómo puede optimizar las consultas". ”Pero muchos DBA le dirán que la razón por la que lo hace es para fines administrativos. Si tiene una tabla de cien mil millones de filas, si la divide en particiones o cubos, cuando desea agregar datos al último segmento, puede soltar e indexar que son solo unos pocos millones de filas. Puede insertar esos datos y luego puede reconstruir ese índice solo en ese depósito.

Si bien era una buena técnica para algunos, técnicas de optimización como la eliminación de particiones, su valor real era poder administrar o realizar tareas administrativas en piezas más pequeñas. Cuando voy al montón organizativo, la primera pregunta fue: "¿Lo particioné o no?" Vayamos a la izquierda, no voy a dividir la tabla. Ahora, puede parecer extraño cuando te digo esto, pero podrías tener una tabla no particionada y luego no puedes particionar el índice como estás acostumbrado, o puedes particionar el índice. Para y piensa. Su tabla tiene básicamente un cubo, como siempre pensó, y sin embargo, su índice tendrá varios cubos. Cuando eso sucede, cuando hay una falta de coincidencia entre el número de depósitos y la tabla, y el número de depósitos en el índice, eso es lo que se entiende por global. Y así, si la tabla no está particionada, y si el índice está particionado, se considera global, porque hay una falta de coincidencia. Ahora, déjenme volver al montón de mi organización y bajar en el lado de la partición. Ahora, si tengo una tabla de particiones, y digamos que la tabla tiene cuatro cubos, cuatro particiones, mi índice podría tener cuatro cubos para que mi índice coincida con el diseño de mi tabla. Y así se acabó, muy por el lado derecho. Eso se consideraría local. Un índice local significa básicamente que la partición de la tabla y el índice se realiza de la misma manera y tiene el mismo número de depósitos. Y luego, una vez que tengo el índice local, podría ser un árbol B o un mapa de bits, y esa flecha verde que sube, te muestra que incluso si es un árbol B, todavía hay opciones que podrían hacerse. Podría estar basado en funciones. Y también, si se trata de un mapa de bits, hay diferentes tipos de mapas de bits. Hay algo llamado índice de unión de mapa de bits. Si está haciendo el almacenamiento de datos, ese es un tipo de índice muy popular para el esquema o diseño en estrella. Lo que sucede es que el índice tiene las ID de fila para lo que apunta en la tabla, pero también tendrá ID de fila para las tablas primarias, de modo que cuando esté, debe marcar el diseño del esquema y buscar en una tabla de hechos, ese índice en la tabla de hechos lo señala a los datos que le interesan y lo dirige a cada fila de sus dimensiones, de modo que solo tiene que tener un índice.

Y en realidad, esto surgió debido a Red Brick, que era una base de datos hace muchos años, mucha gente puede recordar eso. Entonces, si miras esta imagen, y tienes en cuenta que no puse todo en esta imagen porque la imagen sería mucho más grande, todavía hay problemas adicionales, que tengo en el texto aquí en la parte superior derecha . ¿Es un índice de orden inverso? Y usted podría decir: "¿Por qué querría un índice de orden inverso? Eso no tiene ningún sentido ”. Bueno, si está en un entorno en clúster en Oracle, si está haciendo clústeres de aplicaciones reales, si mantiene sus índices en orden, de manera no inversa, si tiene mucho procesamiento que está afectando los mismos valores o los mismos valores de índice, lo que sucedería es que tendría áreas calientes de su árbol B. Lo que significa que tendría contención y posiblemente bloqueo para intentar acceder a esas cosas, y lo estaría haciendo a través de nodos en una red. Bueno, si pones un índice de orden inverso, ahora puedes deshacer eso. Puede decir: "Bueno, los valores similares se encuentran en diferentes partes de los árboles, por lo que no tengo mis nodos separados compitiendo por áreas calientes en el árbol". Y luego noten también que lo único no funciona con algunas de las opciones . Si nos fijamos, he numerado tres, cinco, ocho y once, por lo que hay algunos casos en los que no puedo tener un índice único. Del mismo modo, hay algunos casos en los que no puedo tener un índice inverso, y luego hay problemas adicionales como registrar o no registrar, y paralelos y no paralelos. Puedo asignar cosas a un área específica en la memoria.

Y esto deja de lado muchas características en Oracle. Diría que cuando miras Oracle 12, probablemente haya otra media docena de cosas que podría agregar a esta imagen. La indexación es realmente compleja y estoy realmente de acuerdo con el orador anterior, para navegar a través de esto y hacer una buena elección, necesita una herramienta. Tal vez necesites, tal vez, una imagen como esta, y algún tipo de metodología sobre cómo elegirías las cosas y, con suerte, la herramienta te ayudará a llegar allí. Y luego será prueba y error. Siempre le digo a la gente en la indexación, "mira antes de saltar". Y luego puedes ver al perrito aquí, está saltando sin mirar, va a terminar en el agua con el tiburón, o el tipo que se está preparando para saltar al agua, y se va a empalar a sí mismo. Tienes que pensar en tu indexación, porque crear un índice no siempre significa que las cosas mejoren. De hecho, crear un índice puede ralentizar las cosas. Y el rendimiento de la consulta puede ser un orden de magnitud mejor con una opción sobre otra. Y te daré un buen ejemplo. Si está haciendo un esquema de diseño en estrella, y en sus tablas de dimensiones usa índices de mapa de bits en un caso, y en otro caso dice: "Usaré índices de árbol B", tiene un mapa de bits versus B- árbol. Les puedo decir que una solución será un orden de magnitud o posiblemente varios órdenes de magnitud más rápido que la otra. Pero tenga en cuenta lo que funciona en un entorno, como en un entorno de almacenamiento de datos, probablemente no sea una buena opción en un entorno OLTP.

Por ejemplo, si tuviera que tomar una tabla transaccional y colocar índices de mapa de bits en una tabla transaccional, es costoso calcular y restablecer mapas de bits, estas cadenas largas y, por lo tanto, en una tabla OLTP, puede golpear la tabla con tanta fuerza que el mapa de bits El índice puede corromperse y ralentizar su sistema porque simplemente no están destinados a actualizaciones. Son excelentes para un acceso rápido, pero no son buenas para las actualizaciones. Creo que el índice requiere prueba y error. Realmente ya no hay una regla de oro: hay muchas variables diferentes en esta ecuación para saber, y en última instancia, tendrá que mirar la ejecución o explicar los planes en su base de datos para ver si está haciendo buenas selecciones o no. Y a veces, el análisis del plan casi puede ser una ciencia en sí mismo. No voy a cubrir eso hoy, ese es otro tema, pero no dé por sentado el diseño de índice. Hay razones legítimas por las que hay todos estos tipos de índices locos que te mostré, en la imagen anterior, y de los que habló el orador anterior. Estos no solo se crearon porque era una característica interesante poner en una lista de verificación en algún lugar para un proveedor de base de datos; Hay casos de uso o escenarios en los que estos índices son importantes y marcarán una diferencia significativa. Ahora con eso, voy a mostrar algunos ejemplos de diferentes tipos de índices en una de nuestras herramientas. Permítanme que levante mi pantalla para que puedan verla. De acuerdo, así que aquí estoy sentado dentro de - déjame minimizar esta aplicación. Estoy sentado dentro de VMware y estoy ejecutando una VM de Windows Server 2012.

Y puedes ver, tengo casi todas las herramientas conocidas por el hombre. Como gerente de producto, tengo que estar al tanto de mi competencia, por lo que no es solo qué herramientas tengo, sino ¿qué hacen mis competidores? Y aquí tenemos esta herramienta llamada DBArtisan, que ya he ejecutado, pero voy, así que la mencionaré. Y lo que puede ver es que esta es una herramienta realmente buena, porque en lugar de tener que usarla, diga un gerente de empresa para Oracle y un SQL Management Studio para SQL Server, y MySQL Workbench para MySQL, y otras doce bases de datos que admitimos, Bueno, tengo todas mis bases de datos integradas en esta herramienta. Hay DB2, MySQL, Oracle, Postgres, SQL Server y Sybase, y eso es, solo tengo seis bases de datos en esta cosa en particular porque no puedo, la herramienta admite doce bases de datos pero mi pobre VM, ejecuta seis bases de datos al mismo tiempo e intenta hacer una demostración, es casi todo lo que facilitará mi hardware. Así que déjame volver a Oracle ahora, y si te das cuenta, todas estas cosas son iguales. Si quiero medir mi rendimiento en DB2, son las mismas opciones que tendría en Oracle. Ahora, debajo de las cubiertas, hacemos muchas cosas diferentes para que no tenga que saber lo que está sucediendo, pero le brindamos una interfaz consistente para que pueda ser un experto con múltiples plataformas de bases de datos. Y eso incluiría trabajar con índices, el tema de esta discusión.

Permítanme entrar aquí y comenzar primero mirando algunas tablas, y tengo una base de datos de películas que solo tiene algunas tablas. Y si veo una tabla en particular, como la tabla de clientes, cuando la traigo aquí, puedo ver el diseño de mi tabla, aquí están mis columnas en mi tabla y aquí hay información sobre cada columna. Tengo propiedades para la tabla, pero tenga en cuenta que tengo una pestaña aquí para los índices y puedo ver aquí los índices en la tabla. Tenga en cuenta que uno de estos índices es mi índice PK, mi clave principal. Estos otros parecen ser solo índices para mejorar el acceso a las consultas, tal vez consultamos por nombre o apellido, o miramos teléfonos y códigos postales. Y si elijo un índice particular, como este código postal aquí, y hago doble clic en él, ahora puedo ver que, hey, es un índice no único y aquí hay algunos de los otros tipos, mapa de bits, no único, único, ya sea que esté ordenado o no, ya sea ese registro, si es o no en orden inverso, ya sea una base de funciones. Oh, aquí hay una divertida que no cubrí. En realidad puedes tener índices invisibles. Y diría: "Bueno, ¿por qué diablos querría hacer un índice invisible?" Bueno, te daré un buen ejemplo. Está en su sistema de producción y tiene un problema de rendimiento y no está seguro de que crear el índice solucione el problema, por lo que no desea crear el índice y ralentizar la producción, pero de alguna manera u otra desea ser capaz de probarlo Puede crear el índice en producción como invisible, lo que significa que no muchos códigos de aplicaciones, que llaman al optimizador, usarán ese índice. Ha sido creado, es válido, pero no se usará. Luego, puede realizar una consulta con la que cree que este índice ayudaría, o una serie de consultas, y puede poner una pista y decir: "Oye, optimizador, hay un índice invisible por ahí que quiero que uses y dejes sé si he mejorado las cosas ”. Y ahora he probado algo en producción, pero no he roto las aplicaciones en producción que se estaban ejecutando. Ese es el uso de un índice invisible. Suena tonto cuando lo escuchas por primera vez, pero tiene un uso.

También podemos, en los índices, definir si son paralelos y también cuántas instancias son paralelas. Ahora, en un entorno de clúster de aplicaciones no agrupado o no real, por lo tanto, no en rack, en paralelo, significaría cuántos subprocesos puede traer mi consulta para probar, y procesos de trabajo, para tratar de hacer las cosas más rápido o más rápido . Y las instancias paralelas serían, si estoy en un clúster de aplicación real, digamos que tengo diez nodos, ¿en cuántos de los nodos puedo dividir el trabajo? Quizás sean cuatro de los diez, y en cada uno de ellos, cuatro subprocesos. Eso es un ejemplo. Y luego tenemos la compresión de teclas. ¿Realmente puedes comprimir índices? Si o no. Y, por supuesto, tiene sus parámetros de almacenamiento que puede especificar en los índices. Ahora, no los cubrí porque en realidad son más un parámetro de almacenamiento que un problema de índice. Y finalmente, tenemos si hacerlos con o sin particiones. Déjame dejar eso aquí por un segundo. Voy a ir a un esquema diferente. Este es un esquema en estrella y, por ejemplo, esta tabla de períodos es una tabla de dimensiones. Si alguna vez ha realizado un diseño de esquema de estrella, generalmente tiene una dimensión de tiempo y, por lo tanto, en esta base de datos y este esquema de estrella, el período es una dimensión de tiempo. Ahora, sé que se verá divertido, dirás: "Caramba, mira todas esas columnas. ¿Alguna vez el chico ha oído hablar de la normalización?" Bueno, cuando estás en un almacén de datos o en un diseño de esquema estelar, tú por lo general, tienen tablas que no son las que una persona típica miraría y diría: "Caramba, estas no están muy bien diseñadas". Pero así es como se hace en un entorno de almacenamiento de datos.

Ahora, mira lo que va a pasar porque, bueno, hay todas estas columnas, mira eso, tengo un índice en cada columna. Ahora, en un entorno OLTP eso sería un no-no. Disminuiría la velocidad de todas mis operaciones. En un entorno de almacenamiento de datos, los dejaría caer durante mis ciclos de carga por lotes. Carga sin la sobrecarga o los índices, y volvería a crear los índices. Y si particioné mi tabla, entonces, en lugar de tener que soltar el índice para cada cubo en la tabla, podría simplemente soltar el índice en el cubo o los cubos donde los datos entrarían durante ese ciclo de carga por lotes. Y luego recrear solo la porción de índice para esos depósitos. Y eso lo hace muy manejable. Y si miro, entonces aquí hay una columna llamada "Bandera de vacaciones" y básicamente eso es un sí o un no. Tenga en cuenta que este es un índice de mapa de bits, y para la mayoría de ustedes dirán: "Bueno, eso tiene sentido". Sí o no, S o N, solo hay dos valores que tienen sentido. Y porque cuando lees la documentación para los índices de mapas de bits, siempre te dicen que elijas algo con baja cardinalidad.

Ahora déjame entrar en una de mis tablas de hechos, así que aquí tenemos mis pedidos. Y estas son mis órdenes por día. Y verán ahora, que nuevamente tengo bastantes columnas, y nuevamente, tendré más de unos pocos índices. Y aquí mismo, tenemos algo llamado código de precio universal. Esto era para una tienda minorista, así que conoces esos pequeños códigos de barras cuando compras algo en la tienda, este es el código de precio universal. Ahora, hay millones de códigos de precios universales. Ahora, para esta compañía en particular que estaba vendiendo cosas, probablemente tenían 1.7 a 2 millones de códigos de precios universales, por lo que esperarán que esto no sea un índice de mapa de bits porque 1.7 millones de valores distintos suena como una alta cardinalidad. Pero en realidad, en un entorno de almacenamiento de datos, desea que esto sea un mapa de bits. Ahora, déjame explicarte por qué. Bueno, puede haber 1.7 millones de valores distintos para este código de precio universal, el número de filas en esta tabla de orden es de cientos de millones a miles de millones de filas. Mi índice es baja cardinalidad en comparación con el tamaño o la cardinalidad de la tabla. Eso lo hace de baja cardinalidad. Eso hace que el índice de mapa de bits sea útil, aunque es contradictorio con 1, 7 millones de valores distintos que elegiría aquí. Ahora, si supiera que quiero usar un índice de unión de mapa de bits, actualmente el producto no lo admite, lo agregaré para la próxima versión, pero esa sería otra alternativa aquí. Y en un esquema en estrella, recuerde, el índice de mapa de bits estaría en la tabla de hechos y ese índice en el árbol B apuntaría a la fila en la tabla de hechos y luego a cada fila que fuera aparente en la tabla de dimensiones para ese hecho . Y así, tienes otra opción allí. Entonces, veamos, quiero salir de las tablas ahora y solo quiero mostrarles rápidamente que tengo la misma información, bajo índices, y que voy a hacer lo mismo.

Ahora, la razón por la que mencioné esto es que te darás cuenta, oye, no hay claves principales aquí. Las claves primarias se realizan con una restricción de clave, por lo que en realidad están cubiertas por las definiciones de restricción. Estos serían índices que no son parte de la restricción. Ahora puede decir: "Bueno, espere un minuto, puede parecer una clave externa, y una clave externa es una restricción", pero las claves externas y la mayoría de las bases de datos no crean automáticamente un índice en la columna de clave externa, aunque sea aconsejable, y listo, tengo todas las mismas opciones nuevamente. Y si quiero cambiar solo para ser comprimido, puedo hacerlo.

Ahora la compresión solo funciona en un índice B-tree. Lo que eso permite es que, cuando observa los distintos nodos en el árbol B, permite la compresión de algunos de los valores. Realmente no es una compresión como la compresión de tabla, es una compresión de lo que está almacenado en el árbol B en los nodos no hoja. No ahorra una tonelada de espacio, pero puede marcar la diferencia. Y con eso me di cuenta de que me estoy acercando al tiempo, así que lo que quiero hacer es volver y dejar de compartir. Y tenemos nuestro producto disponible para una prueba de catorce días en idera.com. Es un producto bastante bueno, especialmente si trabaja con múltiples plataformas de bases de datos. Si trabaja con dos o tres bases de datos diferentes, esta herramienta le hará la vida mucho más fácil. Tenemos herramientas para ayudarlo con el diseño y la selección del índice, tenemos una herramienta llamada DB Optimizer. Simplemente no podría cubrir eso hoy, eso sería demasiado. Y si quieres contactarme, ahí está mi dirección de correo electrónico, o puedes encontrarme en mi correo electrónico privado, y tengo blogs, tengo un sitio web y blogs, y un perfil de LinkedIn allí. Así que siéntase libre de comunicarse conmigo sobre cualquier cosa, incluso si no está relacionado con el producto, si solo quiere hablar de bases de datos, soy un geek de corazón y me encanta hablar sobre technobabble.

Eric Kavanagh: Muy bien, Dez, Robin, estoy seguro de que cada uno tiene un par de preguntas al menos, nos quedan unos minutos aquí. Dez, ¿qué te parece?

Dez Blanchfield: Tengo una gran pregunta que tengo que hacerte, ha estado en el fondo de mi mente. ¿Cuál es el escenario más loco que has visto? He leído tu blog, te sigo de cerca, eres, probablemente eres una de las pocas personas que ha vivido en casi todos los improbables, y creo que el Dr. Robin Bloor es el segundo que conozco en mi vida. Pero, ya sabes, probablemente hayas visto todos los escenarios locos, cuáles son algunos de los escenarios más locos que has visto, que has encontrado y, como los seres humanos que simplemente no pudieron hacer frente, has logrado caminar y realizar trucos mentales Jedi con todo este DBArtisan?

Bert Scalzo: Una vez tuvimos un cliente que, en el diseño de su base de datos, pensaron mucho en la forma en que pensarían en un diseño de diseño de archivo, y así, cuando normaliza una base de datos, lo primero que intenta hacer es deshacerse de grupos repetitivos. Bueno, tenían una columna y la hicieron larga, o BLOB o CLOB, y en ella pondrían valor, número uno, punto y coma, valor número dos, punto y coma, número de valor, punto y coma, y ​​tendrían miles de valores. allí, pero necesitaban buscar en esa columna y dicen: "¿Por qué funciona esto tan lento?" Y yo digo: "Bueno, no puedes crear un índice de lo que hiciste, es solo no permitido ". Así que en realidad les mostramos, usando los planes, que lo que tenían que hacer era normalizar esa tabla. No porque la normalización sea un ejercicio académico que mejore las cosas, sino porque querían una consulta en ese campo, lo que significaba que querían poder indexarla, y no se podía indexar en un grupo repetitivo, o al menos no fácilmente . Y eso es probablemente lo peor que he visto.

Dez Blanchfield: Sí, es interesante la frecuencia con la que te encuentras, creo que el desafío con las bases de datos, la gente olvida que es una ciencia. Y hay personas que hacen títulos y doctorados en todo este espacio, escriben documentos sobre él, y usted ha escrito un botín completo, incluidos sus manuales TOAD y otras cosas de memoria. La tendencia hacia una especie de "big data" cita-a-cita ahora: veo a mucha gente olvidando los fundamentos de la arquitectura de la base de datos y la tecnología de la base de datos, la ciencia de la base de datos, si lo desea. ¿Qué está viendo en el campo en cuanto al alejamiento de las plataformas de bases de datos tradicionales y la base de datos tradicional pensando que efectivamente clavamos al suelo, y fue solo un caso de ajuste y escala del rendimiento? ¿Está viendo a mucha gente volver a aprender y tener una experiencia en la que simplemente se sientan allí y tienen un momento "a-ha", como un momento eureka, donde se dan cuenta de que este material de grandes datos es en realidad una especie de base de datos realmente grande? ¿Es algo ahí afuera y la gente te responde y dice: "Olvidamos lo que sabíamos y puedes traernos de vuelta del lado oscuro?"

Bert Scalzo: Bueno, no, y es horrible tener que admitirlo, pero los vendedores de bases de datos relacionales también han bebido ese Kool-Aid. Si recuerdan, no sé, hace aproximadamente una década, comenzamos a poner datos no estructurados en bases de datos relacionales, lo cual era algo extraño, y luego los datos, las bases de datos relacionales, ahora están agregando el tipo NoSQL cosas. De hecho, en Oracle 12, CR2, sé que aún no está disponible, pero si miras la versión beta, si estás en el programa beta, es compatible con el fragmentación. Y así, ahora tiene una base de datos relacional a la que no se le ha agregado el concepto de fragmentación NoSQL. Y así, el momento "a-ha" parece ser más para las personas en el lado relacional que se están volviendo "a-ha". Nadie volverá a hacerlo bien, ni siquiera los administradores de bases de datos, así que hemos tengo que ir y unirme al lado oscuro.

Dez Blanchfield: Correcto, entonces estás diciendo un cambio a una gran cantidad de datos desordenados, si entiendo bien, ser puesto en lo que ahora llamamos plataformas de big data, lo cual es algo gracioso, porque son no es tan antiguo, pero ¿eso no significa que se están reenfocando en lo que están haciendo con su base de datos relacional para obtener más por su dinero?

Bert Scalzo: No, por lo general, si tienen una necesidad en el - eso habría sido citar una "gran necesidad de tipo de datos", están descubriendo que en lugar de tener que ir a la otra plataforma de base de datos y hacer algo de manera relacional, los proveedores de bases de datos ahora les están dando las mismas técnicas no relacionales dentro de su base de datos relacional, para hacer esas cosas. Quiero decir, un buen ejemplo sería, si tiene datos no estructurados, como un tipo de datos JSON o algún otro tipo de datos complejo que tiene un significado incrustado en los datos, los proveedores de la base de datos no solo lo respaldan, sino que le darán ACID cumplimiento de datos no estructurados. Las bases de datos relacionales han adoptado las técnicas y tecnologías más nuevas y, por lo tanto, una vez más, el "a-ha" parece ser más que eso, "Hola, nosotros, los desarrolladores de aplicaciones, hemos aprendido algo y tenemos que aprenderlo de nuevo", es "Hola, lo hacemos de esta manera ahora, ¿cómo puedo hacerlo de esa manera en su base de datos tradicionalmente relacional y hacerlo como lo hago en esta base de datos aquí? ”y eso es cada vez más frecuente, y como dije, los propios proveedores de bases de datos están habilitando ese.

Dez Blanchfield: Correcto, ¿quiénes son los sospechosos tradicionales en este espacio para la herramienta DBArtisan y eso? Hice algunos deberes sobre lo que había escrito recientemente, y de memoria había escrito algo, creo que fue uno de sus blogs, sobre el rendimiento extremo de la base de datos en el mundo de Oracle. No recuerdo cuándo fue, creo que fue en algún momento de este año de memoria, o de fines del año pasado, habías escrito esto. Y me pareció que era el sospechoso tradicional y habitual para el tipo de tema del que hablamos hoy, donde las personas irán a un entorno de base de datos a gran escala y buscarán lo que ustedes llaman ganancias extremas. ¿Quiénes son los sospechosos habituales que estás viendo que están tomando DBArtisan y lo están usando bien?

Bert Scalzo: Bueno, tenemos muchos clientes, de hecho, hoy estuve con una agencia gubernamental muy grande que, y literalmente tienen cerca de 1, 000 copias de nuestro software, porque les permite a las personas concentrarse en lo que " re haciendo, y no cómo hacerlo. Y está bien, quiero decir, todos deberían saber cómo hacer algo, pero la productividad es hacer el "qué". Si el negocio me pide que haga una tarea, eso es todo lo que les interesa. ¿Cuándo obtuve una marca de verificación para decir cuándo se realizó la tarea? No qué técnica o qué technobabble usé para llegar allí. Y así, nuestra herramienta les permite enfocarse en qué y les permite ser mucho más productivos, y esa es realmente la gran ventaja, y como dije, algunas bases de datos ofrecen una herramienta solo para su plataforma de base de datos. Lo ofrecemos para doce plataformas de bases de datos. Tengo el mismo flujo de trabajo, la misma interfaz gráfica de usuario, las mismas navegaciones. Si sabe cómo otorgar un privilegio a un usuario o cómo crear una tabla o crear un índice en una base de datos, puede hacerlo en los doce porque tiene el mismo aspecto y el mismo flujo de trabajo. Eso tiene un gran valor para nuestros clientes.

Dez Blanchfield: Sí, supongo, la gente quiere sacar mucho más provecho de sus recursos humanos. Y los días de tener un especialista individual en Oracle, Ingres y DB2 se han ido. Se espera que las personas sean el Jack de todos los oficios, así que creo que esto les ha salvado la vida.

Solo una última cosa rápida antes de entregárselo al Doctor Robin Bloor. Usted mencionó que hay una descarga gratuita durante catorce días, ¿qué sucede? Si voy a seguir adelante y voy a hacer eso, por cierto, lo pondré en el laboratorio tecnológico de Bloor y haré girar esto levantarme y ponerme manos a la obra, no había tenido la oportunidad de hacerlo antes de hoy. Mencionaste una prueba de catorce días, dijiste que la estabas ejecutando en una VM en tu computadora, supongo que es una computadora portátil. ¿Cuál es, cuál es la configuración de nivel de entrada para que alguien tenga acceso y use la prueba de catorce días, justo antes de devolverle a Robin sus preguntas?

Bert Scalzo: Cualquier entorno de Windows, entonces Windows 7, máquina virtual con una CPU y cuatro conciertos de memoria. No somos una herramienta realmente gorda o costosa. Ahora, si desea ejecutar su servidor de base de datos en esa misma VM en ese mismo Windows, sí, necesitaría agregar más, pero si está ejecutando su base de datos en un servidor de base de datos o en una VM separada, la VM para cargar y ejecutar nuestro producto es muy liviano: una CPU, cuatro gigas de memoria, casi cualquier versión de Windows, y admitimos instalaciones de treinta y dos y sesenta y cuatro bits. Pero debe instalar el cliente del proveedor de su base de datos. Entonces, si desea conectarse a Oracle, debe instalar el cliente de red SQL, porque eso es lo que requiere Oracle para poder comunicarse con una base de datos.

Dez Blanchfield: Suena bastante sencillo. Creo que una cosa de esto, más que nada, que espero que la gente les quite, aparte de darse cuenta de que esta herramienta les va a salvar la vida, es que deberían ir y descargarla y jugar con ella, dado que está ofreciendo una prueba gratuita de catorce días. Y puede ejecutarse en su computadora portátil actual sin instalar nada adicional, porque si ya están haciendo la administración de la base de datos, ya están trabajando con las bases de datos, tienen todas esas herramientas en su lugar y si se está ejecutando en una VM local o en su escritorio local, parece que es fácil de instalar y jugar. Así que recomiendo que la gente haga eso.

Robin, estoy seguro de que tienes preguntas y Eric, probablemente tengas algunas de la audiencia, así que Robin, ¿qué tal si te paso y luego vuelvo a Eric?

Robin Bloor: Sí, está bien, bueno, tengo cosas que decir, quiero decir, siempre he encontrado esta área fascinante porque era, me corté los dientes. Pero la verdad es que, probablemente desde 1998, 1999, he estado a la deriva de lo que Oracle es realmente capaz de hacer. Y, conocía Sybase y Microsoft SQL Server, ambos son bastante simples en comparación con lo que Oracle podría hacer. Me hiciste reír cuando tú … quiero decir, me tapé la boca, cuando empezaste a hablar de fragmentación. Oracle hizo esto antes. Oracle introdujo en algún momento, se pusieron nerviosos de la idea de relación de objetos, por lo que introdujeron la capacidad de crear una especie de notación de objetos y almacenamiento de objetos en Oracle, y hablé con uno de sus ingenieros, algo así como un par de años después de que lo presentaron y le pregunté cuántas personas lo usaron, y él dijo que creo que dos clientes lo habían probado y eso fue todo. Y creo que sucederá lo mismo si comienzan a intentar hacer tendencias NoSQL. Sabes, creo que es un error, quiero decir, estoy un poco interesado en cuáles son tus pensamientos. Ciertamente, ellos beben el Kool-Aid. Sienten que tienen que poder hacer afirmaciones similares a las grandes bases de datos NoSQL como Cassandra, pero ya sabes, ¿tiene algún sentido para ti?

Bert Scalzo: No, has dado en el clavo en la cabeza. Para mí, si voy a hacer relaciones, elegiré un proveedor relacional como un Oracle o un SQL Server o un DB2 o un Postgres, pero si voy a hacer algo que no sea relacional, en el espacio de big data, o el espacio NoSQL, voy a elegir la herramienta adecuada para el trabajo correcto. Y no creo que eso vaya primero a mi proveedor de bases de datos relacionales. Y luego, le agregas la otra arruga, que es, ¿qué hay disponible en la nube? Tantas personas que desean obtener sus bases de datos fuera de las instalaciones. Luego, debe mirar a su proveedor de la nube y decir: "Bien, ¿qué proveedor, qué bases de datos tiene disponibles para mí que se ajusten a mis necesidades y qué tan vendibles son, y francamente, cuál es la tarifa o el cargo por usar esa base de datos? en la nube por hora o por día. ¿Y por gigabyte o terabyte? ”Y lo que encontrará es quizás algunas de las bases de datos relativamente más nuevas como Mongo o Cassandra, tal vez sus tarifas sean más baratas, por lo que si va a hacer big data de tipo multi-petabyte, podría tiene que, solo desde el punto de vista de los costos, tener que considerar las bases de datos NoSQL en la nube porque pueden ser la forma más rentable de hacerlo.

Robin Bloor: Sí, claro. Quiero decir, mi tipo de cosas sobre bases de datos relacionales en mi experiencia, que es lo suficientemente largo como para tener cicatrices, eso es seguro, hay mucho sentido común de que si comienzas a aplicarlo y entiendes qué es realmente relacional, eso Quiero decir, recuerdo haber consultado una vez con un cliente una vez, y me llevaron a una habitación y me hicieron una especie de diagrama de entidad y crearon una tercera forma normal, un modelo de cómo eran los sistemas primarios de la compañía. Tenía alrededor de doscientas cuarenta mesas y dijeron: “Bueno, ¿qué piensas de eso? Vamos a construir una base de datos para esto ", y dije" ¿Qué piensas de eso? ". Dije:" No creo que vaya a funcionar ". Y es exactamente correcto, ya sabes, porque estaban terminando para crear una estructura particular dentro de uniones de once vías. Y eso es lo que hay que entender sobre las relaciones. Así que estoy un poco interesado en cuanto al mal diseño que encuentre. Quiero decir, no tengo ningún problema con DBArtisan: está haciendo cosas muy sensatas y el hecho de que realmente se puede mostrar en múltiples plataformas, creo, es maravilloso, pero ¿cuánto te encuentras allí donde el diseño es un problema? donde las personas podrían haberse solucionado todo tipo de angustias si se redujeran a un esquema estelar en lugar de cobarde sobre eso, ¿sabes?

Bert Scalzo: Bueno, no quiero parecer presuntuoso o arrogante, pero diría más a menudo que no. Claramente, la mayoría de las bases de datos con las que me involucro tienen problemas o problemas. Lo cual es bueno, porque nuestras herramientas, como nuestra herramienta optimizadora de bases de datos, pueden ayudarlos a resolver esos problemas y, lo que es realmente divertido para mí, es que muchos de los problemas son los mismos problemas simples una y otra vez. El otro día estaba trabajando con un cliente que tenía una consulta de unión de once vías, y estoy como, "Está bien, ¿por qué no usaste una cláusula con?" Y dicen, "Bueno, no lo hice no sé qué es eso ". Y luego dije:" Y mira tus sub-selecciones aquí en tu correlacionado y no correlacionado ", le dije:" En algunos casos tienes en tu cláusula where en el nivel más profundo, una tabla de referencia desde el exterior ". Dije:" Eso es, moverlo al nivel correcto, no incrustarlo más profundo de lo necesario, confundirás al optimizador ". Y con algunos ajustes tomó algo que se ejecutó aproximadamente dos horas y lo redujo a diez minutos y fue solo, en ese caso, no hicimos nada más que mejorar el SQL que habían escrito. Creo que el problema es que muchas universidades y muchas personas que aprenden a programar en un entorno no académico, lo aprenden como procesos de tiempo registrado o procesos orientados a filas y el relacional es un conjunto orientado por naturaleza, por lo que Hay que pensar en conjuntos para escribir un buen SQL.

Robin Bloor: Sí, creo que eso es exactamente correcto. Y tienes que entender, son cosas como, la gente debería saber el ABC de cosas como esta. No importa. No podrá hacer cosas racionales si no se da cuenta de que incluso una base de datos bien diseñada y modelada, las uniones llevarán tiempo, las clases llevarán tiempo. Lo hacen porque el mundo nunca ha encontrado una manera de hacer que esos vayan rápido. Han encontrado formas de organizar los datos para que vayan más rápido que lo contrario, y mucho del entusiasmo que tengo que decir para las bases de datos NoSQL es simplemente que están evitando hacer uniones. Simplemente comienzan a construir las bases de datos con la misma extensión de datos en ellas, porque si te unes a cualquiera de las bases de datos NoSQL, son muy malas. ¿No te parece?

Bert Scalzo: Oh, por supuesto. Y me tengo que reír porque comencé mucho antes de las bases de datos relacionales y cuando Ingres era RTI, Relational Technology Institute, y no teníamos SQL, teníamos lenguajes relacionales pre-SQL. Creo que en Ingres, en aquel entonces, se llamaba Quel. Entonces obtuviste de estos viejos paradigmas de bases de datos como la red y un gráfico superior o jerárquico, y pasas por los paradigmas relacionales después de un par de décadas y ahora para mí parece que volveremos a casi una jerarquía nuevamente. Es casi como si hubiéramos revertido.

Robin Bloor: Sí, claro. Mejor pasarte a Eric, estoy consumiendo demasiado tiempo, pero ¿tenemos alguna pregunta de la audiencia, Eric?

Eric Kavanagh: Sí, tenemos algunos. Vamos un poco largo aquí, pero te arrojaré un par. Tuvimos un par de preguntas sobre los índices invisibles. Una pregunta era: "¿Alguien necesita usar su herramienta para verlos?" Otra pregunta era: "Bueno, ¿y si eres ciego?"

Bert Scalzo: Esa es buena.

Eric Kavanagh: Pregunta curiosa también, así que solo para tu información.

Bert Scalzo: No, no tienes que tener nuestras herramientas. Esa es una característica de Oracle, el índice de invisibles. Básicamente, en el diccionario de datos, Oracle solo guarda una pieza de metadatos que dice: “Optimizador, ignora este índice. Está aquí, pero a menos que se le indique físicamente a través de una sugerencia en el, una sugerencia de optimizador en el comando SQL, no use esto ”. Y así, no, no tiene que tener nuestras herramientas, y en todos los aspectos es un índice antiguo simple, puede verlo en cualquier herramienta, es solo que el optimizador dirá: "Lo ignoraremos en el procesamiento normal de consultas". Debe dirigirlo si desea que se use. Es realmente útil para el escenario que describí, que es, si desea construir un índice en producción pero no arriesgarse a romper los informes, o las cosas que ya se están ejecutando, pero quería probarlos, podría hacerlo. Para eso es más útil.

Eric Kavanagh: Eso es algo bueno y luego hubo otra buena pregunta aquí. “¿Qué pasa con algunas de estas nuevas bases de datos en memoria? ¿Cómo la tecnología de base de datos en memoria cambia el juego con respecto a la indexación?

Bert Scalzo: Chico, bueno, ahora eso es bueno, me alegra que alguien haya hecho esa pregunta, vamos a tener que ir otra media hora. No, la memoria interna depende del proveedor de la base de datos. Ahora, normalmente, no hablo más que elogios de todo lo que hace Oracle porque es sorprendente la tecnología que han construido, pero cuando desgarras las cubiertas y miras qué hay en la memoria de Oracle, en Oracle base de datos, lo que es en realidad es que todavía mantiene el almacén de filas en el disco, y se cargará en la memoria del almacén de columnas, y si no hay suficiente memoria para contener toda la tabla, volverá a las porciones; no cabe en la memoria, para hacerlo almacenar en filas, por lo que en realidad podría hacer una selección en la tabla y para la mitad de la tabla, está utilizando una indexación que golpea las filas tradicionales en la tabla, y para la otra mitad la selección en realidad está saliendo y solo toma todo, desde una búsqueda en memoria, y por lo tanto, es diferente en la forma en que SQL Server, por ejemplo, lo implementó con su tecnología Hekaton, ya sabes, y SQL 2014, y se ha mejorado en SQL 2016, pero en algunos aspectos, la suya es una versión más real de in-memory y, pero cada implementación tiene sus pros y sus contras, pero hay que mirar debajo de las cubiertas y darse cuenta. Porque, tuve un cliente que dijo: "Oh, esta tabla está en la memoria, solo voy a dibujar todos los índices", y dije: "La tabla es más grande que la memoria que tienes en el servidor, así que en algún momento algunas de las consultas deben llegar al disco ".

Eric Kavanagh: Esa es una buena descripción; Eso es bueno. Bueno, amigos, tendremos algunas transmisiones web más con estos tipos durante el resto de este año, regrese cada vez que escuchen que Bert está en una presentación porque sabemos que él sabe lo que hace. Siempre es divertido hablar con los expertos. Archivamos todos estos webcasts para verlos más tarde. Aquí está la información de contacto de Bert una vez más, e intentaremos desenterrar ese enlace para la descarga y enviarlo también por correo electrónico, pero siempre puede enviar la suya verdaderamente: tenemos muchos más webcasts para esto. año y estamos haciendo la edición en este momento, así que, amigos, si hay algún tema que realmente quieran escuchar el próximo año, no sean tímidos: tengan cuidado, amigos, hablaremos con ustedes la próxima vez. Adiós.

Socio de contenido de Techopedia

El personal de Techopedia está afiliado a Bloor Group y puede contactarse usando las opciones a la derecha. Para obtener información sobre cómo trabajamos con socios de la industria, haga clic aquí.

• Perfil
• Sitio web