Индекс безумия: как избежать хаоса в базе данных

Сотрудники Techopedia, 5 октября 2016 г.

Вывод: ведущий Эрик Кавана обсуждает вопросы индексации базы данных с доктором Робином Блором, Дезом Бланчфилдом и Берт Скальцо из IDERA.

Вы не вошли в систему. Пожалуйста, войдите или зарегистрируйтесь, чтобы увидеть видео.

Techopedia Content Partner

Персонал Techopedia связан с Bloor Group, и с ним можно связаться, используя опции справа. Для получения информации о том, как мы работаем с отраслевыми партнерами, нажмите здесь.

• Профиль
• Интернет сайт

Эрик Кавана: Дамы и господа, привет, и еще раз добро пожаловать. Это среда в четыре часа по восточному времени, и те из вас, кто знает программу, знают, что это значит, пришло время для еще одного эпизода «Горячих технологий». Да, в самом деле. Меня зовут Эрик Кавана, я буду вашим модератором на сегодняшней сессии: «Индекс безумия: как избежать хаоса в базе данных». Или, как я упомянул в последнем электронном письме, чтобы выйти, «спор базы данных». Горячий термин в эти дни, «спор». Все это делают. Есть слайд о твоей правде. И хватит обо мне.

Таким образом, серия Hot Technology действительно была разработана для определения конкретного пространства, в отличие от комнаты для брифингов, которая является просто брифингом для одного аналитика один на один, для Hot Tech у нас есть два аналитика. Сегодня это будет наш собственный доктор Робин Блур и наш специалист по данным Дез Бланчфилд. И мы говорим о теме, которая, на мой взгляд, действительно символизирует то, что происходит на рынке сегодня.

Суть в том, что в наши дни мы находимся в мире сложности. Действительно, если вспомнить пятнадцать или двадцать лет назад, тогда это был совершенно другой мир, особенно в отношении технологий баз данных. Базы данных были довольно просты. Их было всего несколько; большинство из них были реляционными. Теперь у нас есть весь этот набор технологий баз данных. Буквально десятки вариантов на столе для тех, кто хочет создать приложение или что-то сделать с данными. Все меняется, и это влияет на людей, которые пытаются управлять этими системами. Сегодня мы поговорим с Бертом Скальцо, который является настоящим экспертом в этой области; он старший менеджер по продукту IDERA, о том, что вы можете сделать, чтобы справиться со всеми этими данными. После этого я передам это доктору Робину Блуру, чтобы забрать его. Робин, тебе слово.

Робин Блур: Хорошо, спасибо за это вступление. Я думаю это - потому что это двуручная вещь, я думаю, что я бы просто говорил об оптимизации базы данных в целом, как введение в это шоу Hot Tech. Я начал жизнь - в технологиях и анализе - я начал заниматься этим, потому что раньше писал статьи о возможностях баз данных на платформе DEC VAX. И по этой причине, спонсоры баз данных обычно информировали меня. И вот что мне кажется, это то, зачем вам база данных? Я имею в виду, что в те дни очень много людей создавали файлы значений ключей и использовали их для того, чтобы иметь своего рода ошибочную последовательность индексов, как мы их называем, но для создания своего рода возможностей базы данных, и вы знаете, зачем вам что-нибудь еще?

И ответ на этот вопрос, я думаю, Майкл Стоунбрейкер дал лучший ответ на это, и он сказал: «База данных может знать больше о том, где находятся данные и как быстро их получить, чем любая программа может когда-либо знать». И я думаю, что это интересно; это характер игры. Но в 19-м году, примерно в 1989 году, когда я начал заниматься технологическим анализом, вы знаете, что на тот момент базы данных были очень простыми, а реляционные базы данных были очень простыми. У них было так мало возможностей, я имею в виду, что они могли хранить данные, очевидно, и вы могли делать резервные копии, и они имели, они были совместимы с ACID, но у них действительно были очень слабые оптимизаторы. На самом деле было бы трудно утверждать, что у них вообще была возможность оптимизатора.

И позже они становились все лучше и лучше, но, вы знаете, когда база данных не функционирует - как эти кенгуру, так или иначе, указывают - может быть очень много причин, почему она идет медленно. И это подводит меня к вопросу: у баз данных много функций, но самая важная из них - оптимизация запросов. Если бы они этого не делали, вы бы их не использовали. Речь идет о быстром получении информации, о возможности сделать это при большом количестве одновременно работающих пользователей, и это сложная проблема. И когда вы на самом деле посмотрите, давайте назовем их зрелыми базами данных, если хотите - но, конечно, Oracle, в несколько меньшей степени, Microsoft SQL Server, определенно Teradata и DB2 - оптимизаторы этих баз данных получили, десятилетиями были в строительство. Вы знаете, они не - кто-то не сел - шесть парней в проекте по два человека, год, и просто собрали одного вместе. Это не работает так. Потенциал оптимизации постепенно расширяется, и для этого нужно много. Во всяком случае, давайте поговорим о фоне для базы данных. Что ж, сейчас очень много сказано о базе данных NoSQL, и даже есть большой энтузиазм по поводу базы данных графов. И использование SQL поверх Hadoop и тому подобное. Но правда в том, что если вам нужна база данных прямо сейчас, если вы хотите полностью функциональную, способную к OLTP и большому трафику запросов, это реляционная база данных или ничего.

Среди реляционных баз данных Oracle доминирует по популярности. Microsoft SQL Server, я думаю, второй. Они оба могут быть использованы для OLTP и рабочей нагрузки запросов, но на самом деле вы действительно не можете избежать смешивания этих рабочих нагрузок. Вам нужны разные инциденты для рабочих нагрузок OLTP и рабочих нагрузок запросов. Есть альтернативы SQL и графику. Большинство компаний стандартизируют одну конкретную базу данных, поэтому - я имею в виду, что после десятилетий борьбы со всеми остальными игроками Oracle стала наиболее доминирующей. Просто потому, что они в итоге смогли продать корпоративные лицензии, и поэтому компании будут использовать альтернативные продукты только в исключительных продуктах, которые Oracle просто не будет делать. И базы данных являются стратегическими в том, что они также развиваются. И вы знаете, что я провел небольшое исследование для этой презентации, и это отчасти - я подойду к этому через некоторое время, но довольно интересно, как они развиваются, с точки зрения взгляда на это с позиции DBA. Это то, что я называю невидимым трендом. Это закон Мура в кубе. Это примерно так: самая большая база данных, и новые базы данных, не существует старой базы данных, в которой было бы намного больше данных для приема. Обычно это база данных, которая применяется к новой проблеме. И они на самом деле растут с точки зрения объемов данных. Примерно в куб Мура закон. Таким образом, закон Мура имеет значение в десять раз каждые шесть лет. VLDB имеют тенденцию расти в тысячу раз каждые шесть лет. В 1991, 1992 годах большие базы данных измерялись в мегабайтах. В 97 и 98 годах гигабайт. 2003, '4, терабайт. 2009, '10, вы начали видеть петабайтные базы данных. Я думаю, что сейчас, возможно, существовала одна или две базы данных exabyte, но самое большое, что я слышал, это 200 петабайтов в срок, и вы знаете, не получая данные в петабайтные базы данных. Но, по большей части, это, очевидно, будут новые большие компании Web 2.0, возможно, у вас Facebook движется в этом направлении.

Но в любом случае, если вы действительно посмотрите на это, ожидая, что база данных будет проходить такую ​​эскалацию объема, это потребует много. И что примечательно, конечно, до уровня петабайт, они, кажется, справились достаточно хорошо. Я имею в виду, я говорю о старых продуктах, а не о чем-то новом. Они, кажется, сделали необычайно хорошо. Если мы посмотрим на производительность базы данных, узкие места, это возвращает меня к тому времени, когда я действительно заботился о них, и мне приходилось беспокоиться о них. Вы знаете, что это в основном поломка оборудования. Есть узкие места процессора, возможно, есть узкие места в памяти, возможно, есть узкие места на диске, возможно. Это может быть сеть, которая вызывает у вас горе, и вы также можете получить проблемы с блокировкой, в зависимости от того, что вы делаете, но обычно это происходит потому, что программа не знает, кому вызывать блокировку. Итак, если вы собираетесь настраивать базу данных, вы на самом деле пытаетесь настроить ее так, чтобы она танцевала между этими пятью возможными узкими местами настолько хорошо, насколько это возможно. И это нелегко, потому что объем памяти, который вы можете настроить на любом сервере, значительно увеличивается. Тогда процессоры стали многоядерными, дисковыми, что мы теперь можем делать, я думаю, даже на обычных серверах, я думаю, вы можете делать сотни и сотни терабайт, четверть петабайта, может быть, даже на обычном сервере. Итак, из всех этих вещей, с которыми вы можете играть, сеть, конечно, может работать на разных скоростях, но в основном, когда вы имеете дело с базами данных, вы действительно хотите иметь оптоволоконные кабели между серверами, и на них больше ничего не работает, особенно сюда.

Факторы производительности базы данных. Я имею в виду, я опускаю то, о чем все это будет, потому что я знаю, что Дез собирается говорить об этом, но плохой дизайн базы данных означает плохо работающую базу данных. Плохое программирование может означать бросание очень глупого SQL в базу данных, что займет намного больше времени. Параллелизм и смешивание рабочей нагрузки, слишком большой параллелизм вызовет проблемы узкого места. Смешивание рабочей нагрузки, когда вы получаете большие запросы с очень маленькими, короткими, острыми запросами, вызывает проблемы. Есть проблема с балансировкой нагрузки. Об этом заботится большинство баз данных, но если у вас нет сложного продукта, то, знаете, просто добавив несколько серверов, это не все, что вам нужно, если вы действительно хотите увеличить размер кластера. Вы действительно должны сбалансировать нагрузку, прежде чем вы получите оптимальную производительность. Вы должны сделать планирование мощности. Абсолютно. Особенно сейчас, в наши дни, когда объемы данных увеличиваются более резко, чем раньше для баз данных. И есть целый слой данных, который влияет на то, как вы принимаете данные и как перемещаете данные. Не своевременное получение данных в базу данных может привести к проблемам с производительностью позже, потому что мы перешли от баз данных, работающих в Windows, к работе двадцать четыре на семь на триста семьдесят пять, и нет окон, где можно было бы замедлить базы данных вниз или вряд ли будет в наши дни.

Проблема с Oracle DBA. Это то, о чем я думал. Я был в DBA Oracle с Oracle 7, и я помню, как это настроить. И если вы действительно посмотрите на Oracle сейчас, это путь, путь - у него есть путь, гораздо больше возможностей. Он имеет растровое индексирование и тому подобное, но я действительно потратил время, чтобы посмотреть и посмотреть, сколько на самом деле параметров настройки в базе данных Oracle на данный момент. И есть более трехсот пятидесяти параметров настройки, и есть еще одна сотня скрытых параметров, о которых могут знать специализированные администраторы баз данных, но не знают обычные администраторы баз данных Oracle. А это значит, что настройка базы данных такого типа - сложная задача. Это совсем не просто. Вы должны чувствовать это, вы должны делать это очень долго, и вы должны точно знать, какую проблему вы решаете, потому что настройка начинается, когда производительность ухудшается, но это может быть не все. Может иметь значение производительность определенных запросов, и вы можете исправить это, закрепив определенные данные и память, или вам может потребоваться исправить это с помощью индексации, или вам может понадобиться начать выполнять разбиение другим способом. Есть много вещей, которые вы можете сделать, это главное. Следовательно, они не собираются делать это в своих головах - администраторам нужны инструменты. Я сейчас передам слово Дезу, который, я думаю, расскажет вам об индексации.

Эрик Кавана: Хорошо, Дез, забери это.

Дез Бланчфилд: Спасибо, Робин, и мне нравится обложка. Я думаю, что вы бросили перчатку туда, чтобы я даже приблизился к чему-то столь захватывающему. Но я использовал образ нашей маленькой галактики, поскольку мое мнение о том, во что превратилась сегодняшняя задача для администраторов баз данных, потому что это ментальный образ, который я склонен вызывать, когда попадаю в среду, и я больше не в мире администрирования баз данных или проектирования баз данных на этом уровне больше. Но, как и вы, Робин и я много лет были вовлечены в мир баз данных, как администратор или разработчик, или, в конечном итоге, архитектор, и потом поняли, что я могу делать лучше, чтобы заработать немного. Но, как правило, у вас возникает ощущение, что вы смотрите на эту галактику данных, и тем более сегодня, когда мы перешли от мегабайтов к петабайтам и экзо-масштабам за очень короткий промежуток времени. В великой схеме вещей. Но фраза, которую я имею в виду, состоит в том, что индексы базы данных теперь являются черным искусством, и они не совсем то, с чем должны сталкиваться простые смертные, для бизнес-приложений корпоративного уровня и типа формулировки вас. только что говорили. Но я хотел бы кратко рассказать о типе истории, которую я имел с мирами баз данных, и познакомить с контекстом, в котором мы собираемся сделать вывод, а затем просмотреть некоторые материалы сегодня с нашими друзьями в IDERA, потому что я думаю, что есть много разных мыслей о том, как настроить производительность базы данных, и один из них бросается в ловушку. Для многих магазинов, с которыми я сталкиваюсь, они неизменно не доходят до точки настройки производительности на уровне базы данных и особенно на уровне индекса, пока они не прошли сложный путь, думая, что они могут бросить тюнер в него.,

На мой взгляд, многие люди используют железный подход к этому, и у меня здесь есть фотография «Вспышки», потому что, если вы когда-нибудь смотрели какие-нибудь старые фильмы или, конечно, последнее телешоу с «Вспышкой», как в Флэш Гордон, старый персонаж, и теперь, когда его зовут «Вспышка», он стремится очень, очень быстро и неизменно у него кончается энергия. И это то, что происходит, когда вы бросаете железо на производительность базы данных. По моему опыту, вы всегда можете добавить в игру высокую производительность, напряженную работу, оптимизировать свои операционные системы и настроить их до определенного уровня. Вы можете убедиться, что у вас есть быстрые многоядерные, многопоточные процессоры, чтобы приложение работало быстрее, вы можете использовать много оперативной памяти, иметь высокопроизводительные объединительные платы, переходить с жестких дисков на кеширование жестких дисков и переходить в твердотельное состояние. и высокопроизводительный массив хранения. И даже сейчас люди добавляют в свои движки баз данных такие вещи, как flash и NVMe, думая, что они получат этот логин в два раза больше производительности. И неизменно они получают некоторую выгоду. Но все это возвращается к тем же основным проблемам настройки производительности. Множество сетевых подключений с низкой задержкой, поэтому кластеры работают быстро. И кластерной инфраструктуры базы данных, так что у вас есть больше чем один компьютер, выполняющий всю работу. Но вы склонны возвращаться к той же самой базовой проблеме производительности, а именно к чтению данных. Запись данных, по большей части, довольно линейная задача, и если это не сделано должным образом.

И тогда у нас есть проблема в современном мире: не все базы данных созданы равными. Существуют базы данных и «база данных» по кавычкам. И когда мы думаем о механизмах баз данных, люди часто думают о традиционных, обычных подозреваемых, какими они были в мире SQL. Вы знаете, у нас есть Oracle и Microsoft SQL Server, и есть пара вокруг них в мире открытого исходного кода с MySQL, который сейчас принадлежит Oracle, но он все еще с открытым исходным кодом. Кроме того, у нас есть необычные подозреваемые, движки NoSQL, у которых все еще есть проблемы с индексированием и управлением производительностью, и я не буду вдаваться в подробности, но их становится все больше. вещи появляются каждый день, и они выглядят и чувствуют себя как движки баз данных с точки зрения разработчиков и с точки зрения производительности, но они очень, очень разные звери, и у них есть своя маленькая ниша в мире, чтобы выделять либо производительность в памяти или линейная шкала на диске. Но так выглядит мир в мире баз данных. Это 2016 год, это третья версия карты, созданная целым рядом людей, которые создают эту постоянную ландшафтную карту того, как выглядят базы данных, и вот где это - даже сверхчеловеческий архитектор баз данных или администратор баз данных не может иметь смысла этого Буквально сотни, сотни и сотни моделей разных производителей, производителей баз данных, неизменно совместимых с SQL. И что интересно, они все возвращаются к одной и той же задаче. Настройка производительности и производительности в зависимости от механизма базы данных, и в частности от того, как данные индексируются.

Итак, давайте просто быстро рассмотрим индексирование базы данных, потому что это интересная тема, и я думаю, что вам нужно более подробно в ней разобраться с демонстрацией. Но я думаю, что это довольно общепринятая и общепринятая отраслевая практика, когда настройка производительности индексов баз данных - это то, с чего начинается и заканчивается весь мир, чтобы обеспечить доступность ваших данных в быстром и быстром формате. Но что такое индексация базы данных? Если мы думаем об индексации в форме, к которой мы привыкли как обычные люди, подумайте об индексной странице в книге. Если вы хотите найти что-то в книге - например, энциклопедию или что-то вроде справочного материала какой-либо формы - если вы ищете что-то вроде этой страницы, где я ищу такие вещи, как тема о плотинах в энциклопедии. Я хочу найти все упоминания о плотинах, водосборных площадях и большой зоне застройки, созданной человеком в целом. Я пойду назад, найду его в алфавитном, отсортированном списке, от A до Z, слева направо, и я найду D. Я найду слово «плотины» и смогу увидеть это на на страницах 16, 38, 41 есть ссылка на них, и затем я могу перейти на эти страницы, отсканировать глаза и найти ссылку на слово «плотина». Это по сути та же самая концепция в базе данных, но сейчас это во многом ракетостроение. Настолько, что фактически каждый администратор базы данных, которого я когда-либо хорошо знал, считает, что индексы - это самый важный инструмент для настройки производительности в любом мире баз данных, независимо от того, что они испытывают, даже бросая на это жестокость, или в любом случае.

Обычно, когда мы говорим об индексации базы данных, существует ряд общих подходов. И чем сложнее становятся индексы базы данных, тем сложнее подход к индексации данных. Но, по сути, когда вы думаете об индексации данных - представьте, что у нас есть файл со списком имен; они не могут быть отсортированы в алфавитном порядке. Давайте представим, что их двадцать. Если мы собираемся отсортировать - если мы будем искать данные в этом списке, сверху вниз, и скажем, это список имен. Если я выбираю случайное имя и начинаю прокручивать этот список сверху вниз в линейном формате, и это неупорядоченный список, есть два критерия, о которых я думаю: среднее время поиска и максимальное время поиска - и У меня есть опечатка во второй строке, должно быть «максимальное время поиска», извините, но мое среднее время поиска по существу равно N плюс один, разделенное на два, и это в среднем занимает у меня пятьдесят процентов времени сканировать сверху списка, вниз списка, чтобы найти любую случайную вещь в этом списке. И вторая строка там, под линейным, должна быть «максимальное время поиска». Но максимальное время поиска - это, по сути, количество элементов, и это то, что, если у меня есть список из двадцати вещей, это может занять больше всего времени. искать что-то в этой базе данных - значит идти сверху вниз, то есть, скажем, 20 пунктов в этом упрощенном примере. И это очень медленный процесс, и на самом деле нет способа настроить производительность. И затем, есть другие типы способов получения этих данных и создания индекса, который фактически представляет собой короткий список указателей на то, где находятся фактические данные, такие как двоичные, B-дерево, растровое изображение, хеширование, кластеризованные и некластеризованные, и затем есть различные типы данных, такие как пространственные, отфильтрованные, XML и полный текст.

Двоичный код очень часто используется для вещей, где данные поддаются ему. Исторически B-дерево, вероятно, является наиболее распространенным в общем смысле в том смысле, что оно является общим способом структурирования индекса для любой формы данных и позволяет регистраторам, выборкам, а также вставкам и удалениям относительно легко перемещать указатели вокруг ссылка на указатели, точки. Существуют и другие типы, такие как растровое изображение, где типы данных имеют значение, например, если у нас есть связанный диапазон какой-либо формы. Хеширование работает очень хорошо для больших объектов, особенно блогов и изображений. И вы можете видеть, что существует целый ряд различных научных подходов, математических подходов к индексации данных. Для простых смертных это интересная задача для разговора на этом уровне. Когда вы говорите об этом на уровне производительности для администратора базы данных, они действительно становятся учеными-ракетостроителями, и люди получают степени в них, и я знаю, что доктор Робин Блур, безусловно, сделал это, и написал для него книги для таких как IBM и другие крупные бренды за последние пару десятилетий. И поэтому, на мой взгляд, мы действительно прошли то время, когда, вы знаете, когда-то я лично мог бы сидеть перед системой, и я мог бы разобрать ее и показать вам, именно там, где проблемы с производительностью были в командной строке или в инструменте запуска графического пользовательского интерфейса, и начали углубляться в данные и сообщать вам, где были проблемы, и создавать индексы, или субиндексы, или первичные и вторичные индексы в этом данные и начать использовать его, чтобы найти вещи. Но когда вы думаете об этом ландшафте, который я показал вам, где у нас есть сотни и сотни брендов, марок и моделей, а также производителей и типов баз данных, мы хорошо и действительно прошли то время, когда человек может создать Чувство типов движков баз данных у нас есть. В частности, даже если мы просто вернемся к подобным Oracle, доминирующие бренды в наши дни на платформах реляционных баз данных.

Количество баз данных, с которыми им приходится иметь дело, либо от проприетарной платформы, такой как ERP или HR или финансовая система, либо от того, являются ли они платформой собственного производства по разным причинам, количество баз данных и таблиц баз данных и записей, которые мы получаем иметь дело только с астрономией, и вы физически не можете сделать это вручную. И теперь у нас возникла дополнительная сложность: когда-то сервер базы данных мог просто сидеть под вашим столом. Знаете, когда я был маленьким ребенком после школы, я работал и работал над программным обеспечением для баз данных на первоначально Apple IIes, а затем на системах на базе DOS PC, таких как dBase II, dBase III, прошел через эру с мэйнфреймами и средним уровнем производительности. диапазон и даже VAX и PDP и файл журнала на этом. И, как в случае с Sabre, а затем, в конце концов, когда появились некоторые базы данных SQL. Но в наши дни, когда мы думаем о механизмах баз данных, они выглядят как левый нижний угол. Сервер базы данных - это уже не просто машина, лежащая на полу под столом; это сотни машин, на которых выполняются копии механизмов баз данных и кластеров, и они масштабируют до сотен и сотен терабайт данных, если не петабайт данных, а это тысячи терабайт. И даже до крайности, как отмечал доктор Робин Блур, некоторые конкретные случаи использования - авиалинии, в частности, правительственные учреждения - могут доходить до эксабайт. Они по-прежнему довольно нишевые, но сотни терабайт и даже десятки петабайт уже не являются чем-то необычным, особенно с момента бума доткомов, вроде того, что мы называем компаниями Web 2.0, такими как Facebook, Google, Yahoo и так далее.

У нас также есть осложнение сейчас, когда вещи переходят на внешний сервис. У нас есть инфраструктурная платформа и программное обеспечение как сервисный подход, обеспечивающий инфраструктуру. И особенно сервис платформ, где мы не можем просто купить такие, как Oracle и их облачные платформы, базы данных и серверы. И это позволяет нам очень быстро разрабатывать приложения и просто подключать базу данных обратно к серверам. Нам не нужно думать о том, что под капотом. Недостатком является то, что мы часто не задумываемся о том, как мы проектируем и внедряем базу данных, пока она не начнет ухудшаться, и производительность не станет проблемой, а затем нам придется искать правильный инструмент, чтобы диагностировать, почему наша база данных вредна и где проблемы с производительностью. И это неизменно возвращает нас к той распространенной проблеме, как мы проиндексировали эти данные и типы индексов, которые мы использовали для этих данных, а затем возвращает нас к сверхчеловеческим требованиям к производительности. И кто-то, у кого есть доступ к нужным системам и инструментам для настройки производительности, начинает настраивать эти движки и начинает находить горячую точку и смотреть, где находятся запросы, куда движутся данные, типы запросов, как структурированы запросы, кто выполняет запросы, и находятся ли запросы в очереди и должны ли их кэшироваться. Какую репликацию вы ищете?

И поэтому мы, на мой взгляд, в порядке и в настоящий момент - в тот момент, когда даже самые лучшие в мире гуру баз данных, в основном наши архитекторы баз данных и наши администраторы баз данных и базы производительности, на мой взгляд, им очень нужно начать использовать правильные инструменты обеспечить оптимальную настройку индекса производительности для любого механизма базы данных. Поскольку масштаб, с которым мы имеем дело, и скорость, с которой все движется, мы просто не можем сделать это вручную, и попытка сделать это неизменно может привести к другим проблемам с производительностью, потому что у нас может не быть опыта в этом пространстве, которое мы пытаемся решить проблему. И я считаю, что именно здесь мы собираемся передать Берту, и мы собираемся поговорить о том, как они решили эту разнообразную проблему и о том, что их инструмент может делать, особенно для мира Oracle. И с этим там, Берт, я собираюсь передать вам.

Берт Скальцо: Спасибо. Приветствую всех, меня зовут Берт Скальцо, я работаю в IDERA. Я старший менеджер по продукту для некоторых наших продуктов баз данных. Я буду демонстрировать некоторые из них сегодня. Но я хочу поговорить об индексах, потому что я согласен со всем, что все здесь сказали, особенно с последним слайдом, что индексы настолько сложны, что вам нужен инструмент, и я надеюсь убедить вас. Таким образом, разработка индексов Oracle не так проста, как раньше. Многие люди будут неуверены в себе, когда будут смотреть на варианты, и мне нравится, когда я говорю, что я вырвался из истории, «в этих вопросах единственная уверенность в том, что в этом нет ничего определенного». думайте об индексах в наши дни, потому что, даже если вы думаете, что знаете ответ, вам следует индексировать X, Y или Z, вы действительно не можете быть уверены, пока не попробуете, потому что эти оптимизаторы иногда ведут себя не так, как вы ожидаете. И так много проб и ошибок с дизайном индекса. Теперь, в старые добрые времена, если вам нужен был индекс, обычно было всего два вопроса или один вопрос. Было ли это уникальным или не уникальным? И вы могли бы подумать о других вещах, таких как «Сколько индексов я могу иметь максимум для одной таблицы?», Потому что слишком много индексов замедляет вставки, обновления и удаления. Вы также могли быть в вашей системе баз данных, иметь ограничения на количество столбцов в многоколоночном индексе, потому что иногда существовали ограничения, основанные на размере страницы или блока вашего механизма базы данных, но на самом деле это было довольно просто. в старые добрые времена Вы либо проиндексировали это, либо нет. И действительно, все было в B-дереве. Мы могли разрешить дубликаты или нет, и это было об этом. Жизнь была хорошей, жизнь была простой.

Что ж, сегодня жизнь не так хороша и не так проста. Я поместил красный знак Ghostbuster так, как мы это делали, потому что теперь у нас есть B-дерево против растрового изображения, против растрового соединения. И я собираюсь объяснить, что некоторые из них в данный момент. Кластеризованные и некластеризованные, уникальные или дубликаты, прямой или обратный порядок, на основе функций, разделены или не разделены. Если есть разделение, это глобальное или локальное разделение? Я тоже это объясню. А также есть нечто, называемое индексированной организованной таблицей. И на самом деле я оставил здесь еще полдюжины других, потому что я думаю, что у меня сейчас достаточно, чтобы убедить вас, что индексы намного сложнее, чем вы могли подумать. В этом конкретном слайде я собираюсь начать с верхней левой части диаграммы, и у меня есть таблица. И первое, что я должен решить, в зависимости от вашей версии базы данных и поставщика базы данных, разрешают ли они таблицы объектов или они только реляционные? Я пойду вниз по правой стороне и скажу, что мы строим реляционную таблицу. Теперь следующий вопрос, который я должен задать себе, это в кластере? И многие из вас, кто какое-то время пользовался Oracle, будут помнить, что кластеры вернулись к Oracle через 6 дней. Они, вероятно, сегодня не очень интенсивно используются, но сначала позвольте мне пройти по этой ветке.

Если бы я собирался поместить свою таблицу в кластер, мне пришлось бы иметь кластеризованный индекс для этой таблицы. Теперь в Oracle, когда вы кластеризовали таблицу, вы в основном хранили строки, или строки были близки друг к другу, где значения были похожи. Итак, у вас должен быть кластерный индекс, и этот кластерный индекс может быть неразделенным. Другими словами, на самом деле не было никаких методов разбиения для того, как бы вы работали в кластеризованной таблице. Это было строго неразделено. И поскольку он не был разделен, он был глобальным. Я объясню, что является глобальным через минуту. И это всегда было B-дерево. Другими словами, когда я шел по той ветке, это было довольно просто, у меня не было большого выбора. Теперь, если я сделал некластеризованный индекс для кластеризованной таблицы, что было разрешено в некоторых версиях, он снова был неразделенным; когда он не разделен, тогда ваш единственный выбор - глобальный. И так, у вас есть выбор B-дерева или растрового изображения. Опять же, это зависит от вашей версии базы данных. Но теперь давайте вернемся к реляционной таблице и снова начнем спускаться по правой стороне, и теперь у нас просто будет простая, старая регулярная таблица с кучей: реляционная. Это будет в табличном пространстве. Сначала я иду вниз по правой стороне. Так что это организация, куча. Следующий вопрос, который я должен задать себе: «Хочу ли я разделить эту таблицу или нет?» Теперь, иногда вы делите разделы, потому что думали: «Эй, оптимизатор будет умнее в том, как он может оптимизировать запросы. «Но многие администраторы баз данных скажут вам, что причина, по которой вы это делаете, - в административных целях. Если у вас есть таблица из ста миллиардов строк, если вы разбиваете ее на разделы или сегменты, когда вы хотите добавить данные в последний блок, вы можете удалить и проиндексировать только несколько миллионов строк. Вы можете вставить эти данные, а затем перестроить этот индекс только для этого сегмента.

В то время как для некоторых это была хорошая методика, такая как оптимизация, например, удаление разделов, ее реальная ценность заключалась в том, что она могла администрировать или выполнять административные задачи на небольших участках. Когда я перехожу к организационной куче, первый вопрос был: «Я разделил это или нет?» Давайте пойдем налево, я не собираюсь разбивать таблицу. Теперь, когда я вам это говорю, это может показаться странным, но у вас может быть однораздельная таблица, и вы не сможете разделить индекс, как вы привыкли, или вы можете разделить индекс. Остановись и подумай. Ваша таблица имеет в основном один сегмент, как вы всегда думали, и все же в вашем индексе будет несколько блоков. Когда это происходит, когда существует несоответствие между количеством сегментов и таблицей и количеством сегментов в индексе, это то, что подразумевается под глобальным. И так, если таблица не секционирована, и если индекс секционирован, она считается глобальной, потому что существует несоответствие. Теперь позвольте мне вернуться к куче моей организации, а вместо этого перейти на сторону раздела. Теперь, если у меня есть таблица разделов, и, скажем, таблица имеет четыре сегмента, четыре раздела, мой индекс может иметь четыре сегмента, чтобы мой индекс соответствовал моему дизайну таблицы. И так, все кончено, с правой стороны. Это будет считаться местным. Локальный индекс в основном означает, что разбиение таблицы и индекса выполняется одинаково и имеет одинаковое количество сегментов. И затем, когда у меня есть локальный индекс, это может быть B-дерево или растровое изображение, и эта зеленая стрелка, которая идет вверх, показывает, что, даже если это B-дерево, все же есть выбор, который можно сделать. Это может быть на основе функций. А также, если это растровое изображение, существуют разные типы растровых изображений. Есть нечто, называемое индексом растрового соединения. Если вы работаете с хранилищем данных, это очень популярный индекс для звездной схемы или дизайна. Что происходит, так это то, что индекс имеет идентификаторы строк для того, на что он указывает в таблице, но он также будет иметь идентификаторы строк для родительских таблиц, так что, когда вы - вы должны пометить дизайн схемы, и вы ищете в таблице фактов этот индекс таблицы фактов указывает на интересующие вас данные и указывает на каждую строку в ваших измерениях, поэтому у вас должен быть только один индекс.

И на самом деле, это произошло из-за Red Brick, который был базой данных много лет назад - многие могут помнить это. И так, если вы посмотрите на эту картинку - и имейте в виду, что я не поместил все в эту картинку, потому что картинка была бы намного больше - есть еще дополнительные проблемы, которые у меня есть в тексте здесь в верхней правой части, Это индекс обратного порядка? И вы можете сказать: «Зачем мне нужен индекс обратного порядка? Это не имеет никакого смысла ». Хорошо, если вы находитесь в кластеризованной среде в Oracle, если вы работаете с реальными кластерами приложений, если вы держите свои индексы в порядке, так что не обращайте внимания, если у вас много обработки, которая поражает те же значения или те же значения индекса, что произойдет, если у вас будут горячие области вашего B-дерева. Это означает, что у вас будет конфликт и, возможно, блокировка, чтобы попытаться получить доступ к этому материалу, и вы будете делать это через узлы в сети. Что ж, если вы введете индекс обратного порядка, теперь вы можете отменить это. Вы можете сказать: «Ну, аналогичные значения находятся в разных частях деревьев, поэтому у меня нет отдельных узлов, конкурирующих за горячие области в дереве». И затем обратите внимание, что unique не работает с некоторыми опциями, Если вы посмотрите, я насчитал три, пять, восемь и одиннадцать, так что в некоторых случаях у меня не может быть уникального индекса. Аналогично, в некоторых случаях у меня не может быть обратного индекса, а затем возникают дополнительные проблемы, такие как ведение журнала или отсутствие ведения журнала, а также параллельное и непараллельное. Я могу назначить вещи для определенной области в памяти.

И это оставляет еще немного функций в Oracle. Я бы сказал, что если вы посмотрите на Oracle 12, то, вероятно, снова увидите еще полдюжины вещей, которые я мог бы добавить к этой картине. Индексация действительно сложна, и я действительно согласен с предыдущим оратором, чтобы пройтись по ней и сделать правильный выбор, вам нужен инструмент. Вам, может быть, нужна картинка вроде этой, и какая-то методология того, как вы выбираете вещи, и, надеюсь, инструмент поможет вам туда добраться. И тогда это будет методом проб и ошибок. Я всегда говорю людям об индексации: «Смотри, прежде чем прыгнуть». И тогда вы можете увидеть здесь маленькую собачку, которая прыгает, не глядя, он в конечном итоге окажется в воде с акулой, или парень готовится прыгнуть в воду., и он собирается пронзить себя. Вы должны подумать о своей индексации, потому что создание индекса не всегда означает, что дела идут лучше. На самом деле, создание индекса может замедлить процесс. И производительность запросов может быть на порядок лучше при одном выборе над другим. И я приведу хороший пример. Если вы создаете звездообразную схему проектирования и в своих таблицах измерений вы используете растровые индексы в одном случае, а в другом случае вы говорите: «Я буду использовать индексы B-дерева», вы получаете растровое изображение по сравнению с B- дерево. Я могу сказать вам, что одно решение будет на порядок или, возможно, на несколько порядков быстрее, чем другое. Но имейте в виду, что то, что работает в одной среде, например в среде хранилищ данных, вероятно, не является хорошим выбором в среде OLTP.

Например, если вы взяли транзакционную таблицу и поместили растровые индексы в транзакционную таблицу, вычислить и сбросить точечные рисунки, эти длинные строки и т. Д. В таблице OLTP дорого, вы можете столкнуться с таблицей настолько сильно, что битовая карта Индекс может испортиться и замедлить работу вашей системы, потому что они просто не предназначены для обновлений. Они отлично подходят для быстрого доступа, но не подходят для обновлений. Я думаю, что индекс принимает проб и ошибок. На самом деле больше нет золотого правила - в этом уравнении слишком много разных переменных, чтобы знать - и в конечном итоге вам придется посмотреть на выполнение или объяснить планы в вашей базе данных, чтобы увидеть, правильно ли вы делаете выбор. И иногда анализ плана может быть почти само по себе наукой. Я не буду освещать это сегодня - это другая тема - но не принимайте дизайн индекса как должное. Есть законные причины, по которым есть все эти сумасшедшие типы индексов, которые я показал вам на предыдущем рисунке, и о которых говорил предыдущий оратор. Они были не просто созданы, потому что это была удобная функция, чтобы поставить контрольный список где-нибудь для поставщика базы данных; Существуют варианты использования или сценарии, в которых эти индексы важны и будут иметь существенное значение. Теперь я покажу вам несколько примеров различных типов индексов в одном из наших инструментов. Позвольте мне просто поднять мой экран, чтобы вы могли видеть это. Итак, я сижу внутри - позвольте мне свернуть это приложение. Я сижу внутри VMware и использую виртуальную машину Windows Server 2012.

И вы можете видеть, у меня есть почти все инструменты, известные человеку. Как менеджер по продукту, я должен быть в курсе своих конкурентов, так что дело не только в том, какие инструменты у меня есть, но что делают мои конкуренты? И у нас есть этот инструмент под названием DBArtisan, который я уже запустил, но я собираюсь - так что я просто подниму его. И вы можете видеть, что это действительно хороший инструмент, потому что вместо использования, скажем, корпоративного менеджера для Oracle и SQL Management Studio для SQL Server, а также MySQL Workbench для MySQL и двенадцати других баз данных, которые мы поддерживаем, Ну, у меня есть все мои базы данных, встроенные в этот инструмент. Есть DB2, есть MySQL, Oracle, Postgres, SQL Server и Sybase, и это - у меня есть только шесть баз данных, потому что я не могу - инструмент поддерживает двенадцать баз данных, но моя плохая виртуальная машина, одновременно запускает шесть баз данных и пытается сделать демо, это примерно столько, сколько облегчит мое оборудование. Итак, позвольте мне вернуться в Oracle сейчас, и если вы заметите, все эти вещи одинаковы. Если я хочу измерить свою производительность в DB2, это тот же выбор, что и в Oracle. Теперь под прикрытием мы делаем много разных вещей, поэтому вам не нужно знать, что происходит, но мы предоставляем вам согласованный интерфейс, чтобы вы могли быть экспертом с несколькими платформами баз данных. И это будет включать в себя работу с индексами, темой этого обсуждения.

Позвольте мне прийти сюда и позвольте мне сначала начать с просмотра некоторых таблиц, и у меня есть база данных фильмов, в которой всего несколько таблиц. И если я смотрю конкретную таблицу, например таблицу клиентов, когда я поднимаю ее здесь, я вижу дизайн моей таблицы, вот мои столбцы в моей таблице и информацию о каждом столбце. У меня есть свойства для таблицы, но обратите внимание, что у меня есть вкладка для индексов, и я вижу здесь индексы в таблице. Обратите внимание, что одним из этих индексов является мой индекс PK, мой первичный ключ. Эти другие выглядят просто как индексы для улучшения доступа к запросам, может быть, мы запрашиваем по имени или фамилии, или мы смотрим на телефоны и почтовые индексы. И если я выберу определенный индекс, такой как этот почтовый индекс, и дважды щелкну по нему, то теперь я вижу, что, эй, это неуникальный индекс, и вот некоторые другие типы, растровые, неуникальные, уникальный, независимо от того, отсортирован он или нет, ведение журнала или нет, обратный порядок или нет, является ли это функциональной базой. О, вот забавный, который я не освещал. Вы можете иметь невидимые индексы. И вы скажете: «Ну, чёрт возьми, зачем мне делать невидимый индекс?». Хорошо, я приведу хороший пример. Вы находитесь в своей производственной системе, и у вас есть проблема с производительностью, и вы не уверены, что создание индекса решит проблему, поэтому вы не хотите создавать индекс и замедлять производство, но так или иначе вы хотите быть в состоянии проверить это. Вы можете создать индекс в производственном процессе как невидимый, то есть не так много кода приложения, вызывающего оптимизатор, будут использовать этот индекс. Он был создан, он действителен, но не будет использоваться. Затем вы можете взять запрос, который, по вашему мнению, поможет с этим индексом, или серию запросов, и можете вставить подсказку и сказать: «Эй, оптимизатор, есть невидимый индекс, который я хочу, чтобы вы использовали, и позвольте я знаю, сделал ли я что-то лучше ». И теперь я что-то тестировал в производстве, но я не сломал приложения в работе, которые работали. Это использование для невидимого индекса. Звучит глупо, когда вы впервые слышите об этом, но это имеет смысл.

Мы также можем по индексам определить, параллельны ли они, а также сколько экземпляров они параллельны. Теперь в некластеризованной или нереальной кластерной среде приложений, не являющейся стойкой, параллель будет означать, сколько подпроцессов может вызвать мой запрос, чтобы попытаться, и рабочие процессы, чтобы попытаться выполнить задачу быстрее или быстрее, И параллельные экземпляры будут, если я нахожусь в реальном кластере приложений, скажем, у меня есть десять узлов, на скольких узлах я могу разделить работу? Может быть, это четыре из десяти, и на каждом из них четыре подпроцесса. Это пример. И тогда у нас есть сжатие ключей. Вы действительно можете сжать индексы? Да или нет. И, конечно, у вас есть параметры хранения, которые вы можете указать в индексах. Я не рассматривал их, потому что они на самом деле больше параметр хранения, чем проблема индекса. И, наконец, мы должны сделать или нет разделить их или нет. Позвольте мне бросить это здесь на секунду. Я собираюсь перейти на другую схему. Это звездообразная схема, и, например, эта таблица периодов является таблицей измерений. Если вы когда-либо проектировали схему типа «звезда», у вас обычно есть измерение времени, и поэтому в этой базе данных и этой схеме «звезда» период является измерением времени. Теперь, я знаю, это будет выглядеть смешно, вы скажете: «Ну и дела, посмотрите на все эти столбцы - слышал ли когда-нибудь парень о нормализации?». Ну, когда вы находитесь в хранилище данных или в проекте звездной схемы, вы как правило, есть не - у вас есть таблицы, на которые обычный человек посмотрел бы и сказал: «Ну и дела, они не очень хорошо спроектированы». Но именно так вы делаете это в среде хранилищ данных.

Теперь посмотрите, что произойдет, потому что, ладно, есть все эти столбцы, посмотрите, у меня есть индекс для каждого столбца. Теперь в среде OLTP это было бы нет-нет. Это замедлит все мои операции. В среде хранилищ данных я отбрасывал их во время циклов пакетной загрузки. Загрузите без издержек или индексов, и я воссоздаю индексы. И если я разделю свою таблицу, то вместо того, чтобы удалять индекс для каждого сегмента в таблице, я мог бы просто удалить индекс в сегменте или сегментах, куда будут собираться данные в течение этого цикла пакетной загрузки. А затем воссоздайте только часть индекса для этих сегментов. И это делает его очень управляемым. И если я посмотрю - вот колонка под названием «Праздничный флаг», и в основном это да или нет. Обратите внимание, что это растровый индекс, и для большинства из вас вы скажете: «Ну, это имеет смысл». Да или нет, Y или N, есть только два значения, которые имеют смысл. И потому что, когда вы читаете документацию для растровых индексов, они всегда говорят вам выбрать что-то с низким количеством элементов.

Теперь позвольте мне перейти к одной из моих таблиц фактов, так что здесь у нас есть мои заказы. И это мои заказы на день. И теперь вы увидите, что у меня снова довольно много столбцов, и снова у меня будет больше, чем несколько индексов. И здесь у нас есть нечто, называемое универсальным ценовым кодом. Это было для розничного магазина, так что вы знаете эти маленькие штрих-коды, когда покупаете что-то в магазине, это универсальный ценовой код. Сейчас существуют миллионы универсальных ценовых кодов. Теперь, для этой конкретной компании, которая продавала вещи, у них было, вероятно, от 1, 7 до 2 миллионов универсальных ценовых кодов, поэтому вы ожидаете, что это не будет растровый индекс, потому что 1, 7 миллиона различных значений звучат как высокая мощность. Но на самом деле в среде хранилищ данных вы хотите, чтобы это было растровое изображение. Теперь позвольте мне объяснить, почему. Ну, для этого универсального кода цены может быть 1, 7 миллиона различных значений, количество строк в этой таблице заказов составляет от сотен миллионов до миллиардов строк. Мой индекс - низкая мощность по сравнению с размером или количеством таблиц. Это делает его низким количеством элементов. Это делает полезным индекс растрового изображения, даже если он противоречит интуиции с 1, 7 миллионами различных значений, которые вы бы выбрали здесь. Теперь, если бы я знал, что хочу использовать индекс соединения растровых изображений, в настоящее время продукт не поддерживает это, я добавляю это для следующего выпуска, но здесь это будет другой альтернативой. И помните, что в звездообразной схеме индекс растрового изображения будет находиться в таблице фактов, и что один индекс в B-дереве будет указывать на строку в таблице фактов, а затем на каждую строку, которая была очевидна в таблице измерений для этого факта., И так, у вас есть другой вариант там. Итак, давайте посмотрим, я хочу сейчас выйти из таблиц, и я просто хочу показать вам быстро, что у меня есть та же самая информация по индексам, и я собираюсь сделать ту же самую основную вещь.

Итак, причина, по которой я поднял это, в том, что вы можете заметить, что здесь нет первичных ключей. Первичные ключи выполняются с ограничением ключа, поэтому они фактически охватываются определениями ограничения. Это будут индексы, которые не являются частью ограничения. Теперь вы можете сказать: «Ну, подождите минуту, это может выглядеть как внешний ключ, а внешний ключ - это ограничение», но внешние ключи и большинство баз данных не создают автоматически индекс для столбца внешнего ключа, даже если это желательно, и вы идете - у меня снова все те же варианты. И если я хочу измениться, просто чтобы быть сжатым, я могу это сделать.

Теперь сжатие работает только с индексом B-дерева. Это позволяет, когда вы смотрите на различные узлы в B-дереве, оно позволяет сжать некоторые значения. Это на самом деле не сжатие, как сжатие таблиц, это сжатие того, что хранится в B-дереве в неконечных узлах. Это не экономит массу места, но может иметь значение. И с этим я заметил, что я подхожу довольно близко ко времени, поэтому я хочу вернуться назад и прекратить делиться. И у нас есть наш продукт для четырнадцатидневной пробной версии idera.com. Это довольно хороший продукт, особенно если вы работаете с несколькими платформами баз данных. Если вы работаете с двумя или тремя различными базами данных, этот инструмент значительно облегчит вашу жизнь. У нас есть инструменты, которые помогут вам с дизайном и выбором индекса, у нас есть инструмент под названием DB Optimizer. Сегодня я просто не могу это осветить, это было бы слишком. И если вы хотите связаться со мной, есть мой адрес электронной почты, или вы можете поймать меня по моей личной электронной почте, и у меня есть блоги, у меня есть веб-сайт и блоги, и там есть профиль LinkedIn. Так что не стесняйтесь обращаться ко мне по любому вопросу, даже если это не связано с продуктом, если вы просто хотите поговорить с базами данных, я фанатик в душе, и я люблю болтать о техногенных словах.

Эрик Кавана: Хорошо, хорошо, Дез, Робин, я уверен, что у каждого из вас есть по крайней мере пара вопросов, у нас здесь осталось несколько минут. Дез, что ты думаешь?

Дез Бланчфилд: У меня есть один замечательный вопрос, который я должен задать вам, он сидит у меня в голове. Какой самый безумный сценарий ты видел? Я читал твой блог, внимательно слежу за тобой, - ты, ты, наверное, один из немногих людей, которые жили почти в каждом маловероятном, и я думаю, что доктор Робин Блур - второй, кого я встречал в моя жизнь Но, вы знаете, вы, наверное, видели каждый сумасшедший сценарий, какие самые сумасшедшие сценарии вы видели, с которыми вы сталкивались, и как люди, которые просто не могли справиться, вы сумели пройти и выполнять трюки ума джедаев с этим всем DBArtisan?

Берт Скальцо: Когда-то у нас был заказчик, который при разработке своей базы данных очень много думал о том, как он будет думать при разработке макета файла, и поэтому, когда вы нормализуете базу данных, первое, что вы пытаетесь сделать, это избавиться от повторяющихся групп. Ну, у них был столбец, и они сделали его длинным, или BLOB, или CLOB, и в него поместили бы значение, число один, точку с запятой, значение номер два, точку с запятой, число значения, точку с запятой, и у них были бы тысячи значений там, но им нужно было искать в этом столбце, и они как «Почему это работает так медленно?» И я, как, «Ну, вы не можете создать индекс того, что вы сделали, это просто не позволено ». Таким образом, мы фактически показали им, используя планы, что им нужно было нормализовать эту таблицу. Не потому, что нормализация - это некое академическое упражнение, которое делает вещи лучше, а потому, что они хотели запрос по этому полю, что означало, что они хотели иметь возможность индексировать его, и вы не могли индексировать его в повторяющейся группе, или, по крайней мере, нелегко, И это, наверное, худшее, что я когда-либо видел.

Дез Бланчфилд: Да, интересно, как часто вы сталкиваетесь, я думаю, что проблемы с базами данных, люди забывают, что это наука. И есть люди, которые делают ученые степени и докторские степени во всем этом пространстве, пишут бумаги на нем, и вы написали целый набор, включая ваши руководства TOAD и другие вещи из памяти. Сейчас наблюдается тенденция к «большим данным» типа «цитата по цитате» - я вижу, что многие люди забывают об основах архитектуры баз данных и технологии баз данных, науке баз данных, если хотите. Что вы видите в этой области в том, что касается отхода от традиционных платформ баз данных и традиционного подхода к базам данных, который мы действительно прижили к земле, и это был всего лишь случай настройки и масштабирования производительности. Видите ли вы, как многие люди переучиваются и имеют опыт, когда они просто сидят и переживают момент «а-ха», как момент эврики, когда они понимают, что эти большие данные на самом деле просто своего рода большие базы данных? Это то, что есть, и люди отвечают вам в ответ: «Мы забыли, что мы знали, и можете ли вы вернуть нас с темной стороны?»

Берт Скальцо: Нет, и это ужасно, признавать, но поставщики реляционных баз данных тоже пили эту Kool-Aid. Если вы помните, я не знаю, около десяти лет назад, мы начали помещать неструктурированные данные в реляционные базы данных, что было довольно странно, а затем данные, реляционные базы данных, теперь добавляют NoSQL-тип вещи. На самом деле, в Oracle 12, CR2 - я знаю, что он еще не вышел - но если вы посмотрите на бета-версию, если вы в бета-программе, она поддерживает шардинг. Итак, теперь у вас есть реляционная база данных, в которой не добавлена ​​концепция шардинга NoSQL. Итак, момент «а-ха», кажется, больше подходит для тех, кто находится на реляционной стороне, которые идут «а-ха». Никто никогда не сделает это снова правильно, даже менеджеры баз данных, поэтому мы нужно перейти и присоединиться к темной стороне.

Дез Бланчфилд: Да, так что вы говорите о переходе к большому количеству грязных данных, если я правильно понимаю, когда их вкладывают в то, что мы сейчас называем платформами больших данных, что довольно забавно, потому что они не настолько старый, но разве это не значит, что они переориентированы на то, что они делают со своей реляционной базой данных, чтобы получить больше отдачи от своих денег?

Берт Скальцо: Нет, обычно, если у них есть потребность в… это было бы процитировано как «потребность в большом типе данных», они обнаруживают, что вместо того, чтобы идти на другую платформу базы данных и делать что-то в Таким образом, поставщики баз данных теперь предоставляют им те же нереляционные методы внутри своей реляционной базы данных для выполнения этих задач. Я имею в виду, что хорошим примером будет, если у вас есть неструктурированные данные, такие как тип данных JSON или какой-либо другой сложный тип данных, который имеет значение, встроенное в сами данные, поставщики баз данных не только поддерживают это, но и дают вам ACID соответствие неструктурированным данным. В реляционных базах данных использовались более новые методы и технологии, и поэтому, опять же, «a-ha», скорее, не то, что «Эй, мы, разработчики приложений, что-то узнали, и нам нужно изучить это снова», это «Эй, мы делаем это таким образом сейчас, как я могу сделать это таким образом в вашей традиционно реляционной базе данных и сделать это так, как я делаю в этой базе данных здесь? », и это становится все более распространенным, и, как я уже сказал, сами поставщики баз данных позволяют тот.

Дез Бланчфилд: Верно, кто в этом месте является традиционным подозреваемым для инструмента DBArtisan и что? Я сделал несколько домашних заданий о том, что вы написали недавно, и по памяти вы написали что-то, я думаю, это был один из ваших блогов, посвященный экстремальной производительности баз данных в мире Oracle. Я не могу вспомнить, когда это было, я думаю, что это было где-то в этом году по памяти, или с конца прошлого года, ты написал это. И мне показалось, что это был традиционный, обычный подозреваемый тип темы, о которой мы говорим сегодня, когда люди пойдут в очень крупную среду баз данных и будут искать то, что вы называете экстремальными достижениями. Кто обычно подозревает, что вы видите там, кто принимает DBArtisan и использует его с пользой?

Берт Скальцо: Ну, у нас много клиентов, на самом деле, сегодня я работал в очень крупном правительственном агентстве, которое - и у них буквально около 1000 копий нашего программного обеспечения, потому что оно позволяет людям сосредоточиться на том, что они делаю, а не как это сделать. И это нормально, я имею в виду, что каждый должен знать, как что-то делать, но производительность - это то, что нужно делать. Если бизнес просит меня выполнить задачу, это все, что их интересует. Когда я получил галочку, чтобы сказать, когда задача была выполнена? Не то, какую технику или какую технику я использовал, чтобы добраться туда. И вот, наш инструмент позволяет им сосредоточиться на чем, и позволяет им быть намного более продуктивными, и это действительно огромное преимущество, и, как я сказал, некоторые базы данных предлагают инструмент только для их платформы баз данных. Мы предлагаем его для двенадцати платформ баз данных. У меня тот же рабочий процесс, тот же графический пользовательский интерфейс, те же навигации. Если вы знаете, как предоставить привилегию пользователю или как создать таблицу или создать индекс в базе данных, вы можете сделать это во всех двенадцати, потому что это тот же внешний вид и тот же рабочий процесс. Это имеет огромное значение для наших клиентов.

Дез Бланчфилд: Да, я думаю, люди хотят получить гораздо больше отдачи от своих человеческих ресурсов. И дни, когда у нас был отдельный специалист по Oracle, Ingres и DB2, прошли. Ожидается, что люди будут мастером на все руки, поэтому я думаю, что эта вещь абсолютно спасла их жизнь.

Еще одна короткая вещь, прежде чем я передам ее доктору Робину Блуру. Вы упомянули, что есть бесплатная загрузка в течение четырнадцати дней, что делает - если я собираюсь идти вперед, и я собираюсь сделать это, кстати, я собираюсь поместить это в техническую лабораторию Bloor и раскрутить эту штуку и сам взялся за дело - до сегодняшнего дня у меня не было возможности сделать это. Вы упомянули четырнадцатидневную пробную версию, вы сказали, что запускаете ее на виртуальной машине на своем компьютере, я предполагаю, что это ноутбук. Каковы настройки начального уровня для того, чтобы кто-то мог получить дело и использовать четырнадцатидневную пробную версию, как раз перед тем, как я вернусь к Робину на его вопросы?

Берт Скальцо: любая среда Windows, например Windows 7, виртуальная машина с одним процессором и четырьмя гигабайтами памяти. Мы не очень толстый или дорогой инструмент. Теперь, если вы хотите запустить сервер базы данных на той же виртуальной машине под той же самой Windows, да, вам нужно будет добавить больше, но если вы используете свою базу данных на сервере базы данных или на отдельной виртуальной машине, виртуальная машина для загрузки и запустить наш продукт очень легко: один процессор, четыре гигабайта памяти, практически любая версия Windows - и мы поддерживаем как 32, так и 64-разрядные установки. Но вам нужно установить клиент вашего поставщика базы данных. Поэтому, если вы хотите подключиться к Oracle, вам необходимо установить сетевой клиент SQL, потому что это то, что требуется Oracle для того, чтобы вы могли общаться с базой данных.

Дез Бланчфилд: Звучит довольно просто. Я думаю, что одна вещь из этого больше, чем все, что я надеюсь отнять у людей, кроме осознания того, что этот инструмент спасет их жизни, заключается в том, что они должны пойти и загрузить его и поиграть с ним, учитывая, что вы предлагаете четырнадцатидневную бесплатную пробную версию. И он может работать на их текущем ноутбуке, не устанавливая ничего лишнего, потому что, если они уже выполняют администрирование базы данных, они уже работают с базами данных, у них есть все эти инструменты на месте, и работает ли он на локальной виртуальной машине или на их локальный рабочий стол, кажется, что безболезненно установить и поиграть. Поэтому я настоятельно рекомендую людям сделать это.

Робин, я уверен, что у тебя есть вопросы, и Эрик, ты, вероятно, получил их от аудитории, так что, Робин, как насчет того, чтобы я перешел к тебе, а потом обратно к Эрику?

Робин Блур: Да, хорошо, у меня есть, что сказать, я имею в виду, что я всегда находил этот район очаровательным, потому что это было - я порезался на нем. Но правда в том, что примерно с 1998 по 1999 год я был в курсе того, на что способен Oracle. И я знал Sybase и Microsoft SQL Server, оба из которых довольно просты по сравнению с тем, что может сделать Oracle. Вы заставили меня смеяться, когда вы … я имею в виду, я закрыл рот, когда вы начали говорить о шардинге. Оракул делал это раньше. В какой-то момент Oracle появился, они стали нервничать из-за объектно-реляционной идеи, поэтому они представили возможность создавать некие обозначения объектов и хранилище объектов в Oracle, и я поговорил с одним из их инженеров, что-то вроде пары Спустя годы после того, как они его представили, я спросил, сколько людей им воспользовались, и он сказал, что я думаю, что два клиента попробовали это, и это все. И я думаю, что то же самое произойдет, если они начнут пробовать трендовые вещи NoSQL. Вы знаете, я думаю, что это ошибка, я имею в виду, меня интересует, что вы думаете. Конечно, они пьют Kool-Aid. Они чувствуют, что должны иметь возможность предъявлять претензии, похожие на большие базы данных NoSQL, такие как Cassandra, но вы знаете, имеет ли это для вас какой-то смысл?

Берт Скальцо: Нет, ты ударил гвоздь прямо в голову. Для меня, если бы я собирался делать реляционные, я бы выбрал реляционного поставщика, такого как Oracle, SQL Server, DB2 или Postgres, но если я собираюсь сделать что-то нереляционное, в пространстве больших данных или в пространстве NoSQL я выберу правильный инструмент для правильной работы. И я не думаю, что это, естественно, пойдет в первую очередь моему поставщику реляционных баз данных. И затем, вы добавляете другую морщинку, которая есть в облаке? Так много людей хотят получить свои базы данных вне помещения. Затем вы должны посмотреть на своего облачного провайдера и сказать: «Хорошо, какой у вас провайдер, какие базы данных у вас есть для меня, которые соответствуют моим потребностям и насколько они продаются, и, честно говоря, какова цена или плата за использование этой базы данных? в облаке за час или за день. И на гигабайт или терабайт? »И вы найдете, может быть, некоторые из относительно новых баз данных, таких как Mongo или Cassandra, возможно, их скорости дешевле, поэтому, если вы собираетесь делать большие данные мульти-петабайтного типа, вы можете необходимо - просто с точки зрения затрат - учитывать базы данных NoSQL в облаке, поскольку они могут быть наиболее экономичным способом сделать это.

Робин Блур: Да, верно. Я имею в виду, что мой вид - вещь о реляционных базах данных в моем опыте - которая достаточно длинна, чтобы иметь шрамы, это точно - есть много здравого смысла, что если вы начнете применять его и - вы поймете, что на самом деле такое реляционные Я имею в виду, я помню, что однажды собирался проконсультироваться с одним клиентом, и они привели меня в комнату, и они сделали своего рода диаграмму сущностей и создали третью нормальную форму, модель того, на что были похожи основные системы компании. Там было двести сорок столов, и они сказали: «Ну, что ты думаешь об этом? Мы собираемся создать базу данных для этого », и спросил:« Что вы об этом думаете? »Я сказал:« Я не думаю, что это сработает ». И это совершенно верно, вы знаете, потому что они заканчивались вверх, чтобы создать определенную структуру в одиннадцати путях. И это то, что нужно понимать о реляционных. Так что меня интересует, сколько плохого дизайна вы встретите. Я имею в виду, у меня нет никаких проблем с DBArtisan - он делает очень разумные вещи, и тот факт, что вы действительно можете отображать на нескольких платформах, я думаю, это замечательно - но сколько вы сталкиваетесь там, где дизайн является проблемой где люди могли бы решить все виды душевных страданий, если бы они спустились к звездной схеме, а не стали снежинкой об этом, понимаете?

Берт Скальцо: Ну, я не хочу звучать как самонадеянный или высокомерный, но я бы сказал чаще, чем нет. Понятно, что у большинства баз данных, с которыми я сталкиваюсь, есть проблемы или проблемы. И это хорошо, потому что наши инструменты, такие как инструмент для оптимизации баз данных, могут помочь им решить эти проблемы, и, что мне действительно смешно, так это то, что многие проблемы повторяются снова и снова. На днях я просто работал с клиентом, у которого был одиннадцатикратный запрос на присоединение, и я спрашивал: «Хорошо, почему вы не использовали предложение with?», А они говорили: «Ну, я не Я не знаю, что это такое ». И тогда я сказал:« И посмотрите на ваши подвыборы здесь на ваших коррелированных и некоррелированных », - сказал я, -« В некоторых случаях в вашем предложении where есть самый глубокий уровень, ссылка на таблицу из внешнего источника ». Я сказал:« То есть, переместите его на нужный уровень, не встраивайте его глубже, чем нужно, вы запутаете оптимизатор ». И с несколькими парами настроек мы потребовалось что-то, что работало около двух часов, и сократило его до десяти минут, и это было просто - в этом случае мы ничего не сделали, кроме как улучшили написанный ими SQL. Я думаю, что проблема заключается в том, что многие университеты и многие люди, которые изучают программирование в неакадемической среде, изучают его как процессы с записанным временем или как процесс с ориентацией на строки, а реляционный - это набор, ориентированный по своей природе, и поэтому вы нужно думать в наборах, чтобы написать хороший SQL.

Робин Блур: Да, я думаю, что это правильно. И вы должны понимать, что такие вещи, как, люди должны знать азбуку таких вещей, как это. Это не важно Вы не сможете делать рациональные вещи, если не понимаете, что даже хорошо спроектированная, хорошо смоделированная база данных, объединения займут время, сортировки - время. Они делают, потому что мир никогда не находил способ заставить их идти быстро. Они нашли способы упорядочить данные, чтобы они работали быстрее, чем в других случаях, и большой энтузиазм, который я должен сказать по поводу баз данных NoSQL, заключается в том, что они просто избегают объединений. Они просто начинают создавать базы данных с одинаковым разбросом данных, потому что, если вы присоединитесь к любой из баз данных NoSQL, они сильно отсосут. Ты не думаешь?

Берт Скальцо: О, конечно. И я должен смеяться, потому что я начал задолго до реляционных баз данных и еще тогда, когда Ingres был RTI, Институтом реляционных технологий, и у нас не было SQL, у нас были реляционные языки до SQL. Я думаю, что в Энгре тогда это называлось Кель. Итак, вы получили от этих старых парадигм базы данных, таких как сеть и более высокую графическую или иерархическую структуру, и через пару десятилетий вы проходите через реляционные парадигмы, и теперь мне кажется, что мы снова возвращаемся к почти иерархической структуре. Это почти как мы вернулись.

Робин Блур: Да, верно. Лучше передать тебя Эрику, я отнимаю слишком много времени, но есть ли у нас какие-то вопросы от аудитории, Эрик?

Эрик Кавана: Да, у нас есть несколько. Мы пойдем немного долго, но я брошу пару на тебя. У нас было несколько вопросов о невидимых индексах. Один вопрос был: «Нужно ли кому-то использовать ваш инструмент, чтобы увидеть их?» Другой вопрос был: «Ну, а если вы слепой?»

Берт Скальцо: Это хорошо.

Эрик Кавана: Любопытный вопрос, так что, к вашему сведению.

Берт Скальцо: Нет, вам не нужны наши инструменты. Это особенность Oracle, индекс невидимых. В основном в словаре данных Oracle просто хранит часть метаданных, которая говорит: «Оптимизатор, игнорируйте этот индекс. Это здесь, но если вы не получили физическую инструкцию через подсказку в, подсказку оптимизатора в команде SQL, не используйте это ». Итак, нет, вам не нужны наши инструменты, и во всех отношениях это это обычный старый индекс, вы можете увидеть его в любом инструменте, просто оптимизатор скажет: «Мы проигнорируем его при обычной обработке запросов». Вы должны указать его, если хотите, чтобы он использовался. Это очень удобно для сценария, который я описал, который заключается в том, что если вы хотите создать индекс в производственной среде, но не рискуете нарушить отчеты или что-то, что уже выполняется, но вы хотите протестировать их, вы можете это сделать. Вот для чего это наиболее полезно.

Эрик Кавана: Это хорошая вещь, и тут был еще один хороший вопрос. «Как насчет некоторых из этих новых баз данных в памяти? Как технология базы данных в памяти меняет игру в отношении индексации? »

Берт Скальцо: Мальчик, ну, мы - теперь это хорошо, я рад, что кто-то задал этот вопрос, нам нужно еще полчаса. Нет, в памяти, это зависит от поставщика базы данных. Теперь, обычно, я не говорю ничего, кроме похвалы за все, что делает Oracle, потому что удивительно, что технологии, которые они создали, но когда вы отрываетесь под одеялом и смотрите на то, что находится в памяти в Oracle, в Oracle база данных, в действительности это то, что она все еще хранит хранилище строк на диске, и она будет загружена в память хранилища столбцов, а если недостаточно памяти для хранения всей таблицы, она вернется обратно для порций; он не помещается в памяти для хранения строк, так что вы можете фактически сделать выборку для таблицы и для половины таблицы, вы используете индексирование, затрагивающее традиционные строки в таблице, а для другой половины выбор, который он фактически выводит и просто захватывает все из поиска в памяти, и поэтому, он отличается тем, как SQL Server, например, реализовал его с помощью своей технологии Hekaton, вы знаете, и SQL 2014, и он был улучшен в SQL 2016, но в некоторых отношениях они являются более верной версией в памяти, но каждая реализация имеет свои плюсы и минусы, но вам нужно как-то заглянуть под прикрытие и понять. Потому что у меня был клиент, который сказал: «О, эта таблица находится в памяти - я просто собираюсь составить все индексы», и я сказал: «Таблица больше, чем память, которую вы имеете на сервере, поэтому в какой-то момент некоторые запросы должны попасть на диск ».

Эрик Кавана: Это хорошее описание; это хорошо. Ну, ребята, мы собираемся провести еще несколько веб-трансляций с этими ребятами в оставшуюся часть этого года, возвращайтесь каждый раз, когда вы слышите о выступлении Берта на презентации, потому что мы знаем, что он знает свое дело. Всегда приятно общаться с экспертами. Мы архивируем все эти веб-трансляции для последующего просмотра. Вот еще раз контактная информация Берта, и мы попытаемся найти эту ссылку для загрузки и отправить ее по электронной почте, но вы всегда можете написать свою по-настоящему: у нас есть еще куча веб-трансляций для этого год, и мы сейчас проводим семинар, так что, ребята, если есть какие-то темы, о которых вы действительно хотите услышать в следующем году, не стесняйтесь: позаботьтесь, ребята, мы поговорим с вами в следующий раз. Пока-пока.

Techopedia Content Partner

Персонал Techopedia связан с Bloor Group, и с ним можно связаться, используя опции справа. Для получения информации о том, как мы работаем с отраслевыми партнерами, нажмите здесь.

• Профиль
• Интернет сайт