Індексація божевілля: як уникнути хаосу в базі даних

Співробітники компанії «Техопедія», 5 жовтня 2016 року

Винос: Ведучий Ерік Кавана обговорює індексацію баз даних з докторами Робіном Блором, Дезом Бланчфілдом та Бертом Скальцо IDERA.

На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.

Партнер з вмісту Techopedia

Персонал Techopedia пов'язаний з Bloor Group і з ним можна зв’язатися, скориставшись опціями праворуч. Для отримання інформації про те, як ми працюємо з галузевими партнерами, натисніть тут.

• Профіль
• Веб-сайт

Ерік Кавана: Дами та панове, привіт, і ще раз вітаємось. Це середа, о четвертій східній годині, і ті з вас, хто знає програму, знають, що це означає, настав час ще одного епізоду Hot Technologies. Так, справді. Мене звуть Ерік Кавана, я буду вашим модератором сьогоднішньої сесії: "Індекс божевілля: як уникнути хаосу в базі даних". Або, як я згадував про це в останньому вибуху електронної пошти, щоб вийти, "базування баз даних". Гарячий термін в ці дні, "сварка". Всі це роблять. Слайд про ваш справді. І про мене досить.

Отже, серія «Гарячі технології» дійсно була розроблена для визначення конкретного простору, на відміну від «Брифінгу», який є лише інструктажем у прямому ефірі аналітика, для «Hot Tech» ми отримуємо двох аналітиків. Сьогодні це буде наш власний доктор Робін Блор і наш науковець Дез Бланчфілд. І ми говоримо про тему, яка, на мою думку, насправді є досить символічною для того, що відбувається сьогодні на ринку.

Суть полягає в тому, що ми сьогодні в світі складності. Дійсно, якщо подумати п'ятнадцять чи двадцять років, тоді це був зовсім інший світ, особливо стосовно технології баз даних. Бази даних використовувались досить просто. Їх було лише кілька; більшість з них були реляційними. Тепер у нас є цілий спектр технологій баз даних. Буквально набирає кількість варіантів на столі для всіх, хто хоче створити додаток або зробити щось із даними. Все змінюється, і це впливає на людей, які намагаються керувати цими системами. Ми сьогодні поговоримо з Бертом Скальцо, який є справжнім експертом у цій галузі; він старший менеджер продукту для IDERA, про те, що ви можете зробити, щоб отримати обробку всіх цих даних. З цим я збираюся передати його доктору Робіну Блору, щоб забрати його. Робін, підлога твоя.

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

І відповідь на це, я думаю, Майкл Стоунбрейкер дав найкращу відповідь на це, і він сказав: "База даних може знати більше про те, де дані і як швидко їх отримати, ніж будь-яка програма може коли-небудь знати". І я думаю, що це цікаво; це природа гри. Але в 19 - приблизно 1989 році, коли я почав займатися аналізом технологій, і ви знаєте, в той час, бази даних були дуже простими, а реляційні бази даних були дуже простими. У них було так мало можливостей, я маю на увазі, вони могли зберігати дані, очевидно, і ви можете створити резервну копію і вони мали, вони сумісні з кислотами, але вони справді мали дуже слабкі оптимізатори. Насправді важко буде стверджувати, що вони взагалі мали можливість оптимізатора.

Пізніше вони просто стають все кращими і кращими, але, знаєте, коли база даних не функціонує - як ці кенгуру так чи інакше вказують - може бути дуже багато причин, чому це відбувається повільно. І це доводить мене до того, що Бази даних мають багато функцій, але найважливішою з них є оптимізація запитів. Якби вони цього не зробили, ви не використовували б їх. Йдеться про швидке отримання інформації, це про те, щоб мати змогу це робити, коли багато одночасних користувачів, і це складна проблема. І коли ви насправді дивитесь на, давайте назвемо їх зрілими базами даних, якщо вам подобається - але, звичайно, Oracle, дещо меншою мірою, Microsoft SQL Server, звичайно Teradata і DB2 - оптимізатори цих баз даних, були десятиліттями в будівля. Ви знаєте, вони цього не зробили - хтось не сідав - шість хлопців на двоє людини, рік, проект і просто збили одного. Це не працює так. Можливість оптимізації поступово зростала, і це потребує значного зростання. У будь-якому випадку давайте поговоримо про передумови до бази даних. Що ж, про базу даних NoSQL зараз сказано дуже багато, і навіть базується графіка. І використання SQL через Hadoop та подібні речі. Але правда полягає в тому, що якщо ви хочете отримати базу даних прямо зараз, якщо ви хочете повністю функціональну, здатну до OLTP і великого трафіку запитів, це реляційна база даних, або це нічого.

Серед реляційних баз даних Oracle є домінуючою популярністю. Microsoft SQL Server, я думаю, є другим. Вони обидва можуть бути використані для OLTP та запиту навантаження, але насправді ви не можете піти від змішування цих навантажень. Вам потрібні різні випадки для навантажень OLTP та завантаження запитів. Є альтернативи SQL та графіку. Більшість компаній стандартизуються на одній конкретній базі даних, саме тому - я маю на увазі після десятиліть боротьби з усіма іншими гравцями, Oracle став найбільш домінуючим. Просто тому, що вони в кінцевому підсумку змогли продавати корпоративні ліцензії, і тому компанії використовуватимуть лише альтернативні продукти у виняткових продуктах, Oracle їх просто не зробить. І бази даних є стратегічними в тому, що вони також розвиваються. І ви знаєте, що я трохи дослідив цю презентацію, і це свого роду - я приїду до неї через деякий час, але цікаво, як вони розвиваються, з погляду на це з позиції DBA. Це я називаю невидимою тенденцією. Це закон Мура в кубиках. Це приблизно так: Найбільша база даних, і нові бази даних, не існує старої бази даних, яка б отримала набагато більше даних. Зазвичай це база даних, яка застосовується до нової проблеми. І вони фактично зростають за обсягом даних. Приблизно за кубом Мура закон. Тож закон Мура є фактором десять разів кожні шість років. ЛШП мають тенденцію до зростання в тисячу кожні шість років. У 1991, 1992 роках великі бази даних вимірюються в мегабайтах. У '97 і '98 роках гігабайти. 2003, '4, терабайт. 2009, 10 років, ви почали бачити бази даних петабайт. Я думаю, що там, можливо, є одна-дві екзабайтові бази даних, але найбільший, про який я чув, - це 200 петабайт вчасно, і ви знаєте, не отримуючи дані до петабайтних баз даних. Але, швидше за все, це, очевидно, нові великі компанії в Інтернеті 2.0, можливо, у вас є напрямок Facebook у цьому напрямку.

Але в будь-якому випадку, якщо ви насправді на це подивитесь, очікуючи, що база даних пройде через такий об'єм ескалації, це багато запитує. І примітно, що, напевно, до рівня петабайт, вони, здається, зробили досить добре. Я маю на увазі, я кажу про старіші продукти, а не про щось нове. Вони, здається, зробили надзвичайно добре. Якщо ми подивимось на ефективність бази даних, вузькі місця, це поверне мене до того часу, який я насправді дбав про них, і мені довелося переживати про них. Ви знаєте, що це принципово несправність обладнання. Є вузькі місця процесора, можливо, є вузькі місця в пам’яті, можливо, є й вузькі місця на диску. Це може викликати у вас мережу, і ви також можете отримати проблеми з блокуванням, залежно від того, що ви робите, але зазвичай це відбувається тому, що програма не знає, кого викликати блокування. Отже, якщо ви збираєтеся налаштувати базу даних, ви насправді намагаєтесь налаштувати її так, щоб вона танцювала між цими п’ятьма можливими вузькими місцями, а також це могла зробити. І це непросто, адже кількість пам'яті, яку ви могли налаштувати на будь-якому сервері, різко збільшується. Тоді процесори стали багатоядерними, дисковими, і ми можемо це зробити, я думаю, навіть на товарних серверах, я думаю, ви можете робити сотні і сотні терабайт, чверть петабайт, можливо, навіть на товарному сервері. Отже, з усіма цими речами, з якими можна грати, мережа, звичайно, може працювати з різною швидкістю, але в основному, коли ви маєте справу з базами даних, вам дуже хочеться мати волоконні кабелі між серверами і нічого іншого, що працює на цьому, зокрема цей шлях.

Фактори ефективності бази даних. Я маю на увазі, я залишаю, про що це все буде, бо я знаю, що Дез буде про це говорити, але поганий дизайн бази даних означає погано працюючу базу даних. Погана програма програмування, можливо, може означати перекидання дуже дурного SQL у базу даних, що просто займе набагато довше. Змішання паралельності та навантаження, занадто велика кількість паралельних сумнівів спричинить проблеми з вузькими місцями. Змішування робочого навантаження, коли у вас є великі запити з дуже маленькими, короткими, гострими запитами, що спричиняє проблеми. Існує проблема балансування навантаження. Більшість баз даних про це піклуються, але якщо у вас немає продуманого продукту, знаєте, просто додавання кількох серверів - це не все, що ви робите, якщо дійсно хочете збільшити розмір кластера. Ви насправді повинні збалансувати навантаження, перш ніж отримати оптимальні показники. Вам потрібно зайнятися плануванням потужностей. Абсолютно. Особливо зараз у ці дні, коли обсяг даних значно зростає, ніж раніше для баз даних. Є цілі проблеми рівня даних щодо того, як ви передаєте дані, як рухаєте дані. Не вчасно отримувати дані в базі даних може бути проблемою з продуктивністю пізніше, тому що ми перейшли від баз даних, що працюють в Windows, до двадцяти чотирьох на сім на триста сімдесят п’ять операцій, і немає вікон, де можна сповільнити база даних або навряд чи це буде сьогодні.

Проблема OBA DBA. Це те, про що я думав. Я був у DBA Oracle з Oracle 7, і я пам'ятаю, як це настроїти. І якщо ви насправді дивитесь на Oracle зараз, це шлях, спосіб - це спосіб, спосіб більше можливостей. У ньому є індексація растрових зображень і подібні речі, але я фактично знайшов час, щоб подивитися і подивитися, скільки налаштувань параметрів насправді є в базі даних Oracle на даний момент. І є понад триста п’ятдесят параметрів настройки, і є ще сто прихованих параметрів, про які можуть знати спеціалізовані DBA, але звичайні Oracle DBA не знають про це. А це означає, що налаштування такого роду баз даних - важка справа. Це зовсім не проста річ. Ви повинні відчути це, ви повинні це робити давно, довго, і ви повинні точно знати, яку проблему, на вашу думку, ви вирішуєте, адже настройка починається, коли продуктивність стає поганою, але це може бути не виконанням всього. Це може бути важливим для виконання конкретних запитів, і ви зможете це виправити, зафіксувавши певні дані та пам'ять, або, можливо, вам доведеться виправити це шляхом індексації, або вам може знадобитися почати робити розділення іншим способом. Можна багато чого зробити, в чому справа. Отже, вони не збираються робити це в голові - DBA потребують інструментів. Зараз я передам Дезу, який збирається розповісти вам про індексацію, я думаю.

Ерік Кавана: Добре Дез, забирай це.

Дез Бланчфілд: Дякую, Робін, і я люблю титульну сторінку. Я думаю, що ти кинув туди рукавичку, щоб я прийшов навіть віддалено близько до чогось захоплюючого. Але я використав зображення нашої маленької галактики, як мій погляд на те, в що сьогодні перетворився виклик для адміністраторів баз даних, тому що це ментальний образ, який я схильний створювати, коли потрапляю в оточення, і я більше не у світі адміністрування баз даних або проектування баз даних на цьому рівні. Але, як і ви, ми з Робіном багато років брали участь у світі баз даних, як адміністратор чи розробник, чи врешті-решт архітектор, і тоді зрозуміли, що я можу зробити кращі речі, щоб заробити кірку. Але, як правило, відчувається, що ти дивишся на цю плеяду даних, і тим більше сьогодні, коли ми переходимо, як ви відзначили, ми перейшли від мегабайт до петабайт і екзо-масштабів за дуже короткий проміжок часу., у грандіозній схемі речей. Але фраза, про яку я маю на увазі, полягає в тому, що індекси баз даних зараз є чорним мистецтвом, і вони насправді не такі речі, про які повинні подужати просто смертні, для бізнес-додатків класу підприємств та типу формулювання вас просто говорили. Але я хотів пройти короткий пробіг того типу історії, який був у мене зі світами баз даних, і довести до контексту туди, де ми збираємось зробити висновок, а потім проглянути сьогодні деякі матеріали з нашими друзями на ІДЕРА, тому що я думаю, що існує багато різних думок про те, як налагодити налаштування продуктивності бази даних, і одна з них - це метати олово. Для багатьох магазинів, з якими я стикаюся, вони незмінно не доходять до того, щоб робити налаштування продуктивності на рівні бази даних, а особливо на рівень індексу, поки не пройдуть важкий шлях думки, що вони можуть кинути на нього тюнер. .

Багато людей просто підходять до цього великого залізного підходу, і я маю тут картину The Flash, тому що якщо ви коли-небудь дивилися будь-які старі фільми або, звичайно, останні телевізійні шоу із The Flash, як у Флеш Гордон, старий персонаж, і тепер, коли його називають "Спалахом", він, як правило, йде дуже, дуже швидко і незмінно його енергія витрачається. І ось що відбувається, коли ви кидаєте велике залізо на продуктивність бази даних. Незмінно, на мій досвід, ви можете докласти високу продуктивність, копітку роботу в грі, ви можете оптимізувати свої операційні системи та налаштувати їх на певний момент. Ви можете переконатися, що у вас є швидкі багатоядерні багатопотокові процесори, щоб програма запустила швидше, ви можете кинути на неї багато оперативної пам’яті, у вас можуть бути високопропускні планки, ви можете перейти від жорстких дисків до кешування жорстких дисків на твердому стані та високоефективний масив пам’яті. І навіть зараз люди запускають такі речі, як flash та NVMe у своїх двигунах баз даних, думаючи, що вони отримають це вхід у два рази підсилення продуктивності. І незмінно вони отримують певний прибуток. Але все це повертається до тих же основних проблем з налаштуванням продуктивності. Багато мережевих з'єднань з низькою затримкою, так що кластери працюють швидко. І з кластеризацією інфраструктури баз даних, тому у вас є більше ніж одна машина, яка виконує всі роботи. Але ви, як правило, повертаєтесь до тієї ж основної проблеми продуктивності, а це - читання даних. Запис даних здебільшого є досить лінійним завданням, і якщо це не зроблено належним чином.

І тоді у нас є виклик у сучасному світі: Не всі бази даних створюються рівними. Існують бази даних і "база даних із цитатами". Коли ми думаємо про двигуни бази даних, люди часто замислюються про традиційних, звичайних підозрюваних, як вони були у світі SQL. Ви знаєте, у нас є Oracle і Microsoft SQL Server, а навколо нього є пара у світі з відкритим кодом з MySQL, який зараз належить Oracle, але він все ще є відкритим кодом. І тоді у нас з’являються не настільки звичні підозрювані, двигуни NoSQL, які все ще мають проблеми навколо індексації та управління продуктивністю, і я не буду в них детально описуватись, але їх кількість зростає. речі вискакують щодня, і вони виглядають і відчувають себе движками баз даних з точки зору розробників і з точки зору продуктивності, але вони є дуже-дуже різними звірами, і у них є своя маленька ніша у світі, щоб вирізати будь-який продуктивність в пам'яті або лінійна шкала на диску. Але так виглядає світ у світі баз даних. Це 2016 рік, це версія третьої карти, представленої низкою людей, які створюють цю поточну краєвидну карту того, як виглядають бази даних, і ось тут це - навіть не надлюдський архітектор бази даних чи адміністратор бази даних не можуть мати сенсу з нього. Буквально сотні, сотні і сотні різних марок, моделей, виробників баз даних, незмінно сумісних з SQL. І цікаво те, що всі вони повертаються до того ж виклику. Налаштування продуктивності та продуктивності навколо двигуна бази даних, особливо, як індексуються дані.

Тож давайте просто швидко висвітлимо індексацію баз даних, оскільки це цікава тема, і вам доведеться детальніше розібратися в ній з демонстрацією. Але я вважаю, що це досить добре прийнята і загальноприйнята галузева практика, що налаштування продуктивності індексу баз даних - це місце, де починається і закінчується світ, наскільки забезпечити доступ ваших даних у швидкому та швидкому форматі. Але що таке індексація баз даних? Якщо ми думаємо про індексацію у формі, до якої ми звикли як звичайні люди, подумайте про індексну сторінку в книзі. Якщо ви хочете знайти щось у книзі - зокрема, подібні до енциклопедії, або щось на зразок довідкового матеріалу якоїсь форми - якщо ви шукаєте щось подібне на цій сторінці, де я шукаю речі, подібні до теми дамб в енциклопедії. Я хочу знайти будь-яку згадку про греблі, водозбір води та велику площу забудови, вироблену техногенним. Я повернуся назад, знайду його в алфавітному, відсортованому списку, від А до Я, зліва направо, і знайду D. Я знайду слово "дамби", і я можу це побачити на на сторінках 16, 38, 41 є посилання на них, і тоді я можу перейти на ці сторінки, можу сканувати очі і знайду посилання на слово "гребля". Це, по суті, те саме поняття в базі даних, але це зараз багато раціональна наука. Настільки, що фактично кожен адміністратор бази даних, якого я коли-небудь добре знав, вважає індекси єдиним найважливішим інструментом для настройки продуктивності в будь-якому світі баз даних, незалежно від того, який їхній досвід може стосуватися викидання олова на нього, або в будь-якому випадку.

Як правило, коли ми говоримо про індексацію баз даних, існує ряд загальних підходів. І чим складніші індекси баз даних стають, тим складнішим є підхід до індексації даних. Але по суті, коли ви думаєте про індексацію даних - уявіть, що у нас є файл, який має список імен; вони не можуть бути відсортовані за алфавітом. Уявімо, що їх двадцять. Якщо ми будемо сортувати - якщо ми будемо шукати дані в цьому списку, зверху вниз, і скажімо, що це список імен. Якщо я вибираю випадкове ім'я і починаю прокручувати цей список, зверху вниз, у лінійному форматі, і це не упорядкований список, є два критерії, про які я думаю як мій середній час пошуку та максимальний час пошуку - і У мене друкарська помилка у другому рядку, має бути "максимальний час пошуку", вибачте - але мій середній час пошуку фактично N плюс один, розділений на два, і це в середньому, це займає у мене п'ятдесят відсотків часу сканувати зверху списку, внизу списку, щоб знайти будь-яку випадкову річ у цьому списку. А другий рядок, під лінійним, повинен бути "максимальним часом пошуку". Але максимальний час пошуку - це, по суті, кількість елементів, і це те, що якщо у мене є список з двадцяти речей, це найбільше часу може зайняти мене шукати щось у цій базі даних - це переходити зверху донизу, тобто 20 пунктів у цьому спрощеному прикладі. І це дуже повільний процес, і насправді немає можливості виконати цю настройку. А потім існують інші типи способів отримання цих даних та створення індексу, що фактично є коротким списком покажчиків на те, де є фактичні дані, такі як двійкові, B-дерева, растрові карти, хешування, кластеризовані та некластеризовані, а потім є різні типи даних, такі як просторові, відфільтровані, XML та повний текст.

Бінарний дуже поширений для речей, коли дані піддаються йому. B-дерево - це, мабуть, єдине найбільш поширене в загальному сенсі, в історичному плані - це загальний спосіб структурувати індекс до будь-якої форми даних і дозволяє реєстраторам, виділенням, вставленням і видаленням відносно легко, коли ви переміщуєте покажчики навколо посилання на покажчики, бали. Є й інші типи, наприклад, растрова карта, де типи даних стосуються, якби у нас асоційований діапазон якоїсь форми. Хешинг дуже добре працює для великих об'єктів, зокрема блогів та зображень. І ви можете бачити, що існує ряд різних типів наукових підходів, математичних підходів до індексації даних. Для простого смертного вони цікаві завдання говорити на цьому рівні. Коли ви говорите про це на рівні продуктивності для адміністратора бази даних, вони дійсно стають вченим-ракетом, і люди роблять в них ступеня, і я знаю, що доктор Робін Блур, безумовно, це зробив, і написав про це книги на зразок IBM і інші великі бренди за останні пару десятиліть. І так, - на мій погляд, - ми насправді минули час, коли, знаєте, колись я особисто міг би сісти перед системою, і я міг би розірвати її і показати вам саме там, де проблеми щодо продуктивності були в командному рядку або у інструменті запуску графічного інтерфейсу користувача, і почніть заглиблюватися в дані та повідомляти, де були проблеми, і будуйте в цьому індекси, або підіндекси, або первинні та вторинні індекси дані та почати використовувати їх для пошуку речей. Але коли ви думаєте про цей пейзаж, я показав вам, де у нас є сотні і сотні марок, марок, моделей, виробників і типів баз даних, ми добре і справді минули цей час, де людина може зробити розуміння типів двигунів баз даних у нас. Зокрема, навіть якщо ми просто повернемося до подібних даних Oracle, переважними брендами в наші дні на реляційних платформах баз даних.

Кількість баз даних, з якими їм доводиться працювати, або з власної платформи, наприклад ERP, HR або фінансової системи, або незалежно від того, чи є вони домашньою платформою з різних причин, кількість баз даних та таблиць баз даних та записів, які ми закінчуємо мати справу з астрономічними, і ви фізично не можете це зробити вручну. Зараз у нас виникло додаткове ускладнення, коли колись сервер бази даних може просто сидіти під вашим столом. Ви знаєте, я, будучи маленькою дитиною після школи, коли-небудь ходив і працював над програмним забезпеченням баз даних, спочатку Apple IIes, а потім на базі DOS-систем на базі ПК, таких як dBase II, dBase III, пройшов епоху з мейнфреймами та середнім діапазон і навіть VAX та PDP та файл журналу. І подібне до Saber, а згодом, коли з'явилися деякі бази даних SQL. Але в наші дні, коли ми думаємо про двигуни бази даних, вони виглядають як нижній лівий кут. Сервер бази даних вже не один апарат, який сидить на підлозі під робочим столом; це сотні машин, що працюють з копіями двигунів баз даних і кластерів, і вони масштабують до сотень і сотень терабайт даних, якщо не петабайт даних, а це тисячі терабайт. І навіть до крайності, як зазначив доктор Робін Блер, що деякі конкретні випадки використання - авіакомпанії, зокрема, державні установи - можуть потрапити до екскабайт. Вони все ще досить ніша-у, але сотні терабайт і навіть десятки петабайт вже не є незвичайною, особливо від буму дотком до теперішнього часу, такого, як ми називаємо компанії Web 2.0, як у Facebook, Google, Yahoo і так далі.

У нас також є складність, коли все переходить до зовнішньої служби. У нас є інфраструктурна платформа та програмне забезпечення в якості сервісного підходу, що забезпечує інфраструктуру. І особливо платформенний сервіс, де ми не можемо просто придбати для себе подібні Oracle та їх хмарну платформу, бази даних та сервери. І тому це дозволяє нам зробити дуже швидку розробку програми та просто підключити базу даних назад на сервери. Нам не треба думати про те, що знаходиться під кришкою. Мінусом є те, що ми часто не замислюємося над тим, як ми розробляємо та впроваджуємо базу даних назад, поки вона не пошкодить і продуктивність не стане проблемою, і тоді ми нарешті шукаємо правильний інструмент для діагностики, чому наша база даних болить і де питання про продуктивність. І це незмінно повертає це до спільної проблеми того, як ми проіндексували ці дані та типи індексів, які ми використовували для цих даних, і потім повертаємо нас до надлюдських вимог щодо продуктивності. А хтось, хто має доступ до потрібних систем та правильних інструментів для налаштування продуктивності, налаштовує ці двигуни, і починає знаходити гарячу точку та дивитись, де запити, куди рухаються дані, типи запитів, як запити структуровані, хто виконує запити та чи запитуються в черзі та чи потрібно кешувати. Яку реплікацію ви шукаєте?

І тому ми добре і по-справжньому - на мій погляд - зараз, коли навіть найкращі гуру баз даних у світі, по суті, наші архітектори бази даних та наш адміністратор бази даних та бази продуктивності, на мій погляд, їм дуже потрібно почати використовувати правильні інструменти для забезпечення оптимальної настройки індексу продуктивності для будь-якого двигуна бази даних. Оскільки масштаб, з яким ми маємо справу, і швидкість, з якою рухаються речі, ми просто не можемо це зробити вручну, і спроба зробити це незмінно може ввести інші проблеми продуктивності, тому що ми можемо не мати досвіду в цьому просторі, ми намагаємося вирішити проблему. І я вважаю, що саме тут ми збираємося передати Берту, і ми збираємось поговорити про те, як вони вирішили цю різноманітну проблему та тип речей, які їх інструмент може робити, особливо для світу Oracle. І з цим там, Берт, я переходжу до тебе.

Берт Скальцо: Дякую. Вітаю всіх, мене звати Берт Скальцо, я працюю в IDERA. Я старший менеджер продуктів для деяких наших баз даних. Я сьогодні демонструю деякі з них. Але я хочу поговорити про індекси, тому що я погоджуюся з усім, що всі тут сказали, особливо останнім слайдом, що індекси настільки складні зараз, що вам потрібен інструмент, і я сподіваюся переконати вас. Тож дизайн індексу Oracle - це не так просто, як це було раніше. Дуже багато людей будуть не впевнені в собі, коли вони дивляться на варіанти, і мені подобається ця приказка, яку я витягнув з історії, "в цих питаннях єдина впевненість, що нічого не визначено". І ось, як я Думайте про індекси в ці дні, тому що навіть якщо ви думаєте, що знаєте, що відповідь на вас має індексувати X, Y або Z, ви дійсно не можете бути впевнені, поки не спробуєте, тому що ці оптимізатори іноді поводяться по-іншому так, як ви очікуєте. І тому при розробці індексу є багато спроб та помилок. Тепер, у старі добрі часи, якщо вам потрібен індекс, то, як правило, було всього два запитання, або одне питання. Це було унікальним чи не унікальним? І ви могли подумати про інші речі на кшталт "Скільки індексів я маю максимум на одній таблиці?", Оскільки занадто багато індексів уповільнює вставки, оновлення та видалення. Ви також, можливо, були у вашій системі баз даних, мали обмеження щодо кількості стовпців у індексному стовпчику, тому що іноді існували обмеження залежно від розміру сторінки чи блоку двигуна вашої бази даних, але насправді це було досить просто в старі добрі часи. Ви або проіндексували це, або не зробили. І справді, все було в B-дереві. Ми могли дозволити дублікати чи ні, і це було про це. Життя було добре, життя було простим.

Що ж, сьогодні життя не таке гарне чи таке просте. Я поставив червоний знак Ghostbuster так, як ми це робили, тому що тепер у нас є B-дерево проти растрових зображень проти бітової карти. І я збираюся пояснити, що таке з них за мить. Кластеризовані та некластеризовані, унікальні або дублікати, в прямому чи зворотному порядку, на основі функцій, розділені або не розділені. Якщо є розділ, це глобальний чи локальний розділ? Я це також поясню. А потім ще є щось, що називається індексованою організованою таблицею. І насправді півтора десятка інших я залишив тут, тому що я думаю, що зараз мене тут достатньо, що повинно переконати вас, що індекси набагато жорсткіші, ніж ви могли подумати. У цьому конкретному слайді я розпочну з лівої верхньої частини діаграми, і у мене є таблиця. І перше, що я мушу вирішити, - це, залежно від версії вашої бази даних та вашого постачальника баз даних, чи дозволяють вони об'єктні таблиці або вони є лише реляційними? Я збираюся спуститися праворуч і сказати, що ми будуємо реляційну таблицю. Тепер наступне запитання, яке я повинен собі задати, - це це кластер? І багато з вас, хто певний час займався Oracle, пам’ятатимуть, що кластери поверталися на Oracle 6 днів. Вони, мабуть, вже не дуже активно використовуються сьогодні, але дозвольте мені спуститися спочатку по цій гілці.

Якби я збирався помістити свою таблицю в кластер, я мав би мати кластерний індекс на цій таблиці. Тепер, в Oracle, коли ви кластеризували таблицю, ви в основному зберігали рядки або рядки були близько один до одного, де значення були схожі. Отже, ви повинні мати кластерний індекс, і цей кластерний індекс може бути нерозподіленим. Іншими словами, не було насправді жодних методів розподілу того, як ви робили б кластерну таблицю. Це було суворо нерозділене. І тому, що вона була нерозподілена, вона була глобальною. Я поясню, що таке глобальне за хвилину. І це було завжди B-дерево. Іншими словами, коли я спускався по цій гілці, це було досить просто, у мене не було багато варіантів. Тепер, якщо я зробив некластеризований індекс на кластеризованій таблиці, що було дозволено в деяких версіях, знову це було нерозбитим; коли він не розділений, то ваш єдиний вибір - глобальний. Отже, там у вас є вибір B-дерева або растрової карти. Знову ж таки, це залежало від вашої версії бази даних. Але тепер повернемося до реляційної таблиці і почнемо спускатись правою частиною знову, і тепер ми просто матимемо звичайний, старий, звичайний, нагромаджений стіл: реляційний. Це буде в просторі таблиці. Я ніби спочатку спускаюсь правою частиною. Так що це організація, купа. Наступне запитання, яке я повинен собі задати, це: "Я хочу розділити цю таблицю чи ні?" Тепер, іноді ви розділите, тому що ви думали: "Ей, оптимізатор буде розумнішим щодо того, як можна оптимізувати запити. "Але багато DBA скажуть вам, що ви так робите в адміністративних цілях. Якщо у вас сто-мільярдна таблиця, якщо ви розділите її на розділи чи відрі, коли ви хочете додати дані до останнього відра, ви можете опустити та індексувати лише кілька мільйонів рядків. Ви можете вставити ці дані, а потім зможете відновити індекс лише у цьому відрі.

Незважаючи на те, що для деяких це була хороша техніка оптимізації, наприклад, усунення розділів, її справжня цінність полягала в тому, щоб управляти або виконувати адміністративні завдання на більш дрібні частини. Коли я переходжу до організаційної купи, першим питанням було: «Я розділив це чи ні?» Перейдемо ліворуч, я не збираюся розділяти стіл. Тепер це може здатися дивним, коли я вам про це скажу, але ви можете мати таблицю, яка не є розділеною, і тоді ви не можете розділити індекс, як ви звикли, або ви можете розділити індекс. Зупиніться і подумайте. У вашому столі в основному є одне відро, як ви завжди думали, і все ж ваш індекс матиме кілька відра. Коли це трапляється, коли між кількістю відра та таблицею та кількістю відра в індексі є невідповідність, саме це означає глобальний. І так, якщо таблиця не розділена і якщо індекс розміщений, це вважається глобальним, оскільки є невідповідність. Тепер, дозвольте мені повернутися назад на групу моєї організації та спуститися замість неї на сторону розділу. Тепер, якщо у мене є таблиця розділів, і скажімо, у таблиці є чотири відра, чотири розділи, мій індекс може мати чотири відра, щоб мій індекс відповідав моєму дизайну таблиці. І так все закінчилося, на правій стороні. Це вважатиметься місцевим. Локальний індекс в основному означає, що розділення таблиці та індексу виконується однаково і має однакову кількість відер. І тоді, коли я маю локальний індекс, це може бути B-дерево або растрова карта, і зелена стрілка, яка йде вгору, показує вам, що навіть якщо це B-дерево, все ж є вибір, який можна зробити. Це може бути засноване на функціях. А також, якщо це растрове зображення, існують різні типи растрових зображень. Існує щось, що називається індексом об'єднання растрових карт Якщо ви зберігаєте дані, це дуже популярний вид індексу для зіркової схеми чи дизайну. Що відбувається, що індекс має ідентифікатори рядків для того, на що він вказує в таблиці, але він також матиме ідентифікатори рядків для батьківських таблиць, щоб, коли ви - вам доведеться створити схему зірочок і шукати у таблиці фактів цей індекс у таблиці фактів вказує на дані, які вас цікавлять, і вказує на кожен рядок у ваших вимірах, так що вам потрібно мати лише один індекс.

Насправді це виникло через Red Brick, який багато років тому був базою даних - про це може пам’ятати багато людей. І тому, якщо ви подивитеся на цю картину - і майте на увазі, що я не вклав все на цю картину, оскільки зображення було б набагато більшим - все ще є додаткові питання, про які я маю в тексті тут угорі праворуч . Це індекс зворотного порядку? І ви можете сказати: «Чому я хочу індекс зворотного порядку? Це не має сенсу ". Добре, якщо ви знаходитесь в кластерному середовищі в Oracle, якщо ви робите реальні кластери додатків, якщо ви тримаєте свої індекси в порядку, настільки неперевернені, якщо у вас багато обробки, яка вражає. ті ж самі значення або однакові значення індексу, що трапиться, у вас є гарячі ділянки вашого B-дерева. Це означає, що у вас виникнуть суперечки та, можливо, блокування, щоб спробувати отримати доступ до цього матеріалу, і ви б це робили через вузли мережі. Що ж, якщо ви введете індекс зворотного порядку, тепер ви можете скасувати це. Ви можете сказати: "Ну, подібні значення є в різних частинах дерев, тому у мене немає окремих моїх вузлів, які змагаються за гарячі ділянки на дереві". І тоді також помітите, що унікальний не працює з деякими з варіантів. . Якщо ви подивитесь, я пронумерував три, п'ять, вісім і одинадцять, тож є випадки, коли я не можу мати унікальний індекс. Крім того, є деякі випадки, коли я не можу мати зворотний індекс, а потім виникають додаткові проблеми, такі як реєстрація або відсутність журналу, а також паралельні та непаралельні. Я можу віднести речі до певної області пам'яті.

І це залишає ще досить багато можливостей в Oracle. Я б сказав, що коли ви подивитесь на Oracle 12, то, мабуть, знову є ще півдесятка речей, які я міг би додати до цієї картини. Індексація дійсно складна, і я дійсно погоджуюся з попереднім доповідачем, для того, щоб перейти через це і зробити хороший вибір, вам потрібен інструмент. Можливо, вам потрібна така картина, і якась методологія того, як ви б вибирали речі, і, сподіваємось, інструмент допоможе вам потрапити туди. І тоді це буде проба та помилка. Я завжди кажу людям, що індексують, "дивись, перш ніж стрибнеш". І тоді ти можеш побачити маленьку собачку тут, він стрибає, не дивлячись, збирається потрапити у воду з акулою, або хлопець, що готується стрибнути у воду, і він збирається надушити себе. Вам потрібно подумати над своїм індексуванням, оскільки створення індексу не завжди означає, що все покращується. Насправді створення індексу може сповільнити ситуацію. А ефективність запитів може бути на порядок кращою при виборі іншого. І я наведу вам гарний приклад. Якщо ви робите схему дизайну зірок, а у своїх розмірних таблицях ви використовуєте індекси растрових мап в одному випадку, а в іншому ви говорите: "Я буду використовувати індекси B-дерева", ви отримали растрову карту проти B- дерево. Я можу вам сказати, що одне рішення буде на порядок або, можливо, на кілька порядків швидше, ніж інше. Але майте на увазі те, що працює в одному середовищі, як, наприклад, в середовищі зберігання даних, ймовірно, не є вдалим вибором в середовищі OLTP.

Наприклад, якщо ви взяли таблицю транзакцій і помістили растрові індекси на транзакційну таблицю, дорого обчислювати і скидати растрові карти, ці довгі рядки і так у таблиці OLTP, ви можете потрапити в таблицю настільки сильно, що растрова карта індекс може стати корумпованим і сповільнити вашу систему, оскільки вони просто не призначені для оновлень. Вони чудово підходять для швидкого доступу, але не корисні для оновлень. Я думаю, що індекс приймає проби та помилки. Насправді вже немає жодного золотого правила - у цьому рівнянні є занадто багато різних змінних, і, зрештою, вам доведеться переглянути виконання або пояснити плани у вашій базі даних, щоб побачити, чи робите ви чи ні. І іноді аналіз плану майже може бути наукою сам по собі. Я сьогодні не збираюся висвітлювати це - це вже інша тема, - але не сприймайте дизайн індексу як належне. Є законні причини, чому існують усі ці шалені типи індексів, які я вам показав, на попередній фотографії, і про яку говорив попередній спікер. Вони були створені не просто тому, що це була акуратна функція, щоб десь поставити контрольний список для постачальника баз даних; є випадки використання або сценарії, коли ці індекси важливі і суттєво зміниться. Тепер із цим я збираюся показати вам кілька прикладів різних типів індексів в одному з наших інструментів. Дозвольте мені просто налаштувати екран, щоб ви могли його бачити. Гаразд, ось тут я сиджу всередині - дозвольте мінімізувати цю програму. Я сиджу всередині VMware і запускаю Windows Server 2012 VM.

І бачите, у мене є майже кожен відомий людині інструмент. Як менеджер із продуктів, я повинен бути в курсі своєї конкуренції, тож це не лише інструменти, які я маю, а що роблять мої конкуренти? І у нас є цей інструмент під назвою DBArtisan, який я вже запустив, але я йду - тож я просто підведу його. І що ви можете побачити, це справді приємний інструмент, тому що замість того, щоб використовувати, скажіть менеджер підприємств для Oracle і SQL Management Studio для SQL Server, MySQL Workbench для MySQL та ще дванадцять інших баз даних, які ми підтримуємо, добре, я маю всі свої бази даних вбудовані в цей один інструмент. Є DB2, є MySQL, Oracle, Postgres, SQL Server і Sybase, і це - у мене є лише шість баз даних у цій конкретній речі, тому що я не можу - інструмент підтримує дванадцять баз даних, але мій поганий VM, який працює шість баз даних одночасно і намагається робити демо - це приблизно стільки, скільки полегшить моє обладнання. Тож дозвольте мені повернутися в Oracle зараз, і якщо ви помітили, всі ці речі однакові. Якщо я хочу оцінити свою ефективність у DB2, це вибір, який я мав би в Oracle. Зараз під обкладинками ми робимо багато різноманітних речей, тому вам не потрібно знати, що відбувається, але ми надаємо вам послідовний інтерфейс, щоб ви могли бути експертом у кількох платформах баз даних. І це включало б роботу з індексами, темою цієї дискусії.

Дозвольте мені зайти сюди, і дозвольте мені спершу почати з перегляду деяких таблиць, і у мене є база фільмів, у якій є лише кілька таблиць. І якщо я дивлюся на конкретну таблицю, наприклад на таблицю клієнтів, коли я її вивожу сюди, я бачу дизайн своєї таблиці, ось мої стовпці в моїй таблиці, і ось інформація про кожен стовпчик. У мене є властивості таблиці, але зауважте, що у мене тут вкладка для індексів, і я можу побачити, що тут є індекси в таблиці. Зауважте, що один із цих індексів - це мій індекс ПК, мій первинний ключ. Ці інші виглядають лише як покажчики для покращення доступу до запитів, можливо, ми запитуємо за ім'ям чи прізвищем, або дивимось на телефони та поштові індекси. І якщо я вибираю тут певний індекс, як-от цей поштовий індекс, і двічі клацну по ньому, тепер я бачу, що, ей, це не унікальний індекс, і ось деякі інші типи, растрові, не унікальні, унікальний, незалежно від того, сортується він чи ні, ведеться чи ні ведення журналу, незалежно від того, чи це зворотний порядок, чи це база функцій. О, ось весела, яку я не висвітлював. Насправді ви можете мати невидимі індекси. А ви б сказали: "Ну, чому б, хоч я хотів би зробити невидимий індекс?" Ну, я дам вам хороший приклад. Ви знаходитесь у своїй виробничій системі, і у вас є проблеми з продуктивністю, і ви не впевнені, що створення індексу виправить проблему, тому ви не хочете створювати індекс і сповільнювати виробництво, але так чи інакше ви хочете вміти тестувати це. Ви можете створити індекс у виробництві як невидимий, це означає, що не багато код програми, викликаючи оптимізатор, буде використовувати цей індекс. Він створений, він дійсний, але він не буде використовуватися. Тоді ви можете взяти запит, на який ви думаєте, що цей індекс допоможе, або ряд запитів, і ви можете вставити підказку і сказати: "Ей, оптимізатор, там є невидимий індекс, я хочу, щоб ви використовували і нехай я знаю, чи зробив я щось краще. "І тепер я щось випробував у виробництві, але я не порушив застосувань у виробництві, які працювали. Це використання невидимого індексу. Це звучить німо, коли ви вперше почуєте про це, але це має користь.

Ми також можемо за індексами визначити, чи є вони паралельними, а також скільки примірників вони паралельні поперек. Тепер, у некластеризованому або не реальному середовищі кластерних додатків, так що не є стійка паралель, це означатиме, скільки підпроцесів може викликати мій запит, щоб спробувати, і робочі процеси, щоб спробувати вирішити все швидше або швидше . І паралельні екземпляри будуть, якщо я перебуваю в реальному кластерному додатку, скажіть, у мене є десять вузлів, на скільки з цих вузлів мені дозволено розділити роботу по всій? Можливо, це чотири з десяти, і на кожному з них чотири підпроцеси. Ось приклад. І тоді у нас стискання клавіш. Ви дійсно можете стискати індекси? Так чи ні. І тоді, звичайно, у вас є параметри зберігання, які ви можете вказати в індексах. Тепер я не висвітлював це, оскільки вони насправді більше для зберігання, ніж для індексу. І тоді, нарешті, ми маємо робити чи не робити це розділені чи нерозчленовані. Дозвольте мені кинути це на секунду. Я збираюся перейти до іншої схеми. Це схема зірки, і, наприклад, ця таблиця періодів є таблицею розмірів. Якщо ви коли-небудь робили дизайн схеми зірки, у вас зазвичай є розмірність для часу, і тому в цій базі даних і в цій зірковій схемі період - це часовий вимір. Тепер я знаю, що це буде виглядати смішно, ви скажете: "Боже, поглянь на всі ці стовпці - хлопець коли-небудь чув про нормалізацію?" Ну, коли ти знаходишся в сховищі даних або зірковій схемі, ти як правило, у вас немає таблиць, на які типова людина дивилася б і казала: "Боже, це не дуже добре розроблено". Але це так, як ви це робите в середовищі зберігання даних.

А тепер дивіться, що буде, бо добре, там є всі ці стовпці. Подивіться, у мене є індекс на кожний стовпець. Тепер, у середовищі OLTP, яке було б ні-ні. Це сповільнило б усі мої операції. У середовищі зберігання даних я б скидав їх під час циклів завантаження пакетних даних. Завантажуйте без накладних витрат або індексів, і я б відтворив індекси. І якби я розділив свою таблицю, то замість того, щоб скидати індекс для кожного відра в таблиці, я міг би просто скинути індекс на відро або відра, куди збиралися дані збиратися протягом цього циклу пакетного навантаження. А потім відтворити лише індексну частину для цих відро. І так це робить його дуже керованим. А якщо я дивлюсь - ось ось стовпець під назвою "Прапор свята", і це, так, ні. Зауважте, що це растровий індекс, і для більшості з вас ви скажете: "Ну, це має сенс". Так чи ні, Y або N, є лише два значення, які мають сенс. І тому, коли ви читаєте документацію для растрових індексів, вони завжди говорять вам вибрати щось із низькою кардинальністю.

Тепер дозвольте мені зайти до однієї з моїх таблиць фактів, тож тут у нас є мої накази. І це мої замовлення на день. І ти зараз побачиш, що я знову маю досить багато стовпців, і знову, у мене буде більше кількох покажчиків. І тут ми маємо щось, що називається універсальним кодом цін. Це було для магазину роздрібної торгівлі, тому ви знаєте ті маленькі штрих-коди, коли купуєте щось у магазині, це універсальний код цін. Зараз є мільйони універсальних цінових кодів. Тепер для цієї конкретної компанії, яка продавала речі, вони мали, мабуть, 1, 7-2 млн. Універсальних цінових кодів, тож ви очікуєте, що це не буде растровим індексом, оскільки 1, 7 мільйона чітких значень звучать як висока кардинальність. Але насправді в умовах зберігання даних ви хочете, щоб це було растровим зображенням. Тепер дозвольте мені пояснити, чому. Ну, може бути 1, 7 мільйона чітких значень для цього універсального коду цін, кількість рядків у цій таблиці замовлень становить сотні мільйонів до мільярдів рядків. Мій індекс - низька кардинальність порівняно з розміром або кардинальністю таблиці. Це робить її низькою кардинальністю. Це робить індекс растрових зображень корисним, навіть якщо він є протиінтуїтивним із 1, 7 мільйонами різних значень, які ви вибрали б тут. Тепер, якщо я знав, що хочу використовувати індекс приєднання растрових карт, наразі продукт не підтримує це, я додаю це до наступного випуску, але це була б інша альтернатива тут. А в зірковій схемі, пам’ятайте, індекс растрових зображень міститиметься у таблиці фактів, і один індекс у B-дереві вказуватиме на рядок у таблиці фактів, а потім на кожен рядок, який був очевидним у таблиці розмірів для цього факту. . І так, у вас є інший варіант. І ось, давайте подивимось, я хочу зараз вийти з таблиць, і я просто хочу вам швидко показати, що я маю ту саму інформацію під індексами, і я збираюся робити те саме основне.

Тепер, чому я придумав це, це те, що ви можете помітити, ей, тут немає первинних ключів. Первинні ключі виконуються з обмеженням ключа, тому вони фактично охоплені визначеннями обмежень. Це були б індекси, які не є частиною обмеження. Тепер ви можете сказати: "Ну, почекайте хвилину, це може виглядати як зовнішній ключ, а зовнішній ключ - обмеження", але зовнішні ключі та більшість баз даних не створюють автоматично індекс у стовпці іноземного ключа, навіть якщо це доцільно, і там ви йдете - у мене знову є однакові варіанти. І якщо я хочу змінитись лише для стиснення, я можу це зробити.

Тепер стискання працює лише на індексі B-дерева. Що це дозволяє, коли ви дивитесь на різні вузли B-дерева, це дозволяє стиснути деякі значення. Це насправді не стиснення, як стиснення таблиці, це стиснення того, що зберігається на B-дереві в нелистових вузлах. Це не економить ні тонни місця, але може змінити значення. І з цим я помітив, що я доволі близький за часом, тож, що я хочу зробити, це хочу повернутися назад і припинити спільний доступ. І ми маємо наш продукт там для чотирнадцятиденного випробування на idera.com. Це досить хороший продукт, особливо якщо ви працюєте з декількома платформами баз даних. Якщо ви працюєте з двома-трьома різними базами даних, цей інструмент значно полегшить ваше життя. У нас є інструменти, які допоможуть вам розробити та вибрати індекс, у нас є інструмент під назвою Оптимізатор БД. Я просто не могла сьогодні це покрити, це було б занадто багато. І якщо ви хочете зв’язатися зі мною, є моя адреса електронної пошти, вона є, або ви можете наздогнати мене на мою приватну електронну пошту, і в мене є блоги, у мене є веб-сайт і блоги та профіль LinkedIn. Тож не соромтесь звертатися до мене з будь-чим, навіть якщо це не стосується товарів, якщо ви просто хочете поговорити з базами даних, я прислухаюся до душі і люблю бавитись про технобабл.

Ерік Кавана: Добре, добре, Дез, Робін, я впевнений, що у вас щонайменше є кілька питань, у нас тут залишилось кілька хвилин. Дез, як ти думаєш?

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

Берт Скальцо: Одного разу у нас був клієнт, який у своєму дизайні баз даних дуже думав, як вони думають у дизайні файлових файлів, і так, коли ви нормалізуєте базу даних, перше, що ви намагаєтеся зробити, - це позбутися повторюваних груп. Ну, у них був стовпчик, і вони зробили його довгим, або BLOB або CLOB, і в ньому вони поставили б значення, номер один, крапка з комою, значення номер два, крапка з комою, число значення, крапка з комою, і вони мали б тисячі значень там, але їм потрібно було шукати в цьому стовпчику, і вони виглядають так: "Чому ця річ працює так повільно?" І мені подобається: "Ну, ти не можеш створити індекс того, що ти робив, це просто Не дозволено ". Отже, ми фактично показали їм, використовуючи плани, що потрібно було нормалізувати цю таблицю. Не тому, що нормалізація - це деяка академічна вправа, яка робить речі кращими, а тому, що вони хотіли запиту в цьому полі, а це означало, що вони хочуть мати можливість його індексувати, а ви не могли індексувати його на групі, що повторюється, або принаймні не просто . І тому це, мабуть, найгірше, що я бачив.

Дез Бланчфілд: Так, цікаво, як часто ви стикаєтесь, я думаю, що проблема з базами даних, люди забувають, що це наука. І є люди, які займаються науковими ступенями та докторами наук у всьому цьому просторі, пишуть на ньому документи, і ви написали цілий штрих, включаючи ваші підручники TOAD та інші речі з пам'яті. Зараз тенденція до "великих даних", яка базується на цитатах, - я бачу, що багато людей забувають основи архітектури баз даних та технології баз даних, якщо ви хочете. Що ви бачите на місцях, що стосується відхилення від традиційних платформ баз даних і традиційного мислення бази даних, яке ми ефективно прибивали до землі, і це було лише випадком налаштування та масштабування продуктивності. Ви бачите, як багато людей переучуються і мають досвід, коли вони просто сидять там і мають “а-ха” момент, як момент еврики, де вони усвідомлюють, що ця велика кількість даних насправді є просто своєрідною великою базою даних? Це щось там, і люди відповідають вам на відповідь і подібні: "Ми забули, що ми знали, і чи можете ви повернути нас з темної сторони?"

Берт Скальцо: Ну, ні, і це жахливо доводиться визнавати, але постачальники реляційних баз даних також випили цей Kool-Aid. Якщо ви пам’ятаєте, я не знаю, десь десять років тому ми почали вносити неструктуровані дані в реляційні бази даних, що було щось дивно, і тоді дані, реляційні бази даних, тепер додають тип NoSQL речі. Насправді, в Oracle 12, CR2 - я знаю, це ще не вийшло - але якщо ви подивитеся на бета-версію, якщо ви в бета-програмі, вона підтримує шардінг. Отже, тепер у вас є реляційна база даних, до якої не додано поняття від загострення NoSQL. І так, "а-ха" момент здається більше для людей з реляційної сторони, які йдуть "а-ха". Ніхто ніколи не збирається це зробити знову, навіть навіть менеджери баз даних, тому у нас є треба перейти і приєднатися до темної сторони.

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

Берт Скальцо: Ні, зазвичай, якщо у них є потреба - це було б цитування "великої потреби типу даних", вони вважають, що замість того, щоб перейти на іншу платформу бази даних і зробити щось не -реляційним шляхом, зараз постачальники баз даних надають їм ті самі нереляційні прийоми всередині їх реляційної бази даних, щоб робити це. Я маю на увазі, хорошим прикладом може бути, якщо у вас є неструктуровані дані, наприклад, тип даних JSON або інший складний тип даних, який має сенс, вбудований у самі дані, то постачальники баз даних не лише підтримують це, але й дадуть вам ACID відповідність неструктурованим даним. Реляційні бази даних охопили новіші методи та технології, і тому, знову-таки, «а-га» здається, що не більше, «Ей, ми, розробники додатків, щось навчилися, і нам потрібно це знову вивчити», - це «Ей, ми робимо це так зараз, як я можу зробити це так у вашій традиційно реляційній базі даних і робити це, як я роблю в цій базі даних тут? ", і це стає все більш поширеним, і, як я вже сказав, самі постачальники баз даних дозволяють що.

Дез Бланчфілд: Так, хто традиційний підозрюваний у цьому просторі за інструментом DBArtisan і це? Я зробив домашнє завдання з того, що ви написали нещодавно, і з пам’яті ви щось написали, я думаю, що це був один із ваших блогів, щодо надзвичайної продуктивності бази даних у світі Oracle. Я не можу згадати, коли це було, я думаю, що це було колись цього року з пам’яті чи з кінця минулого року, ви це написали. І мені здалося, що це традиційний, звичайний підозрюваний тип теми, про який ми сьогодні говоримо, коли люди будуть відвідувати дуже масштабне середовище баз даних і шукати те, що ви називаєте в ньому надзвичайними вигодами. Хто є звичайними підозрюваними, які ви бачите там, хто приймає DBArtisan і корисно використовує його?

Берт Скальцо: Ну, у нас багато клієнтів, насправді я сьогодні був у дуже великому урядовому відомстві, яке - і вони буквально, мабуть, близько 1000 копій нашого програмного забезпечення, тому що це дозволяє людям зосередитись на тому, що вони ' робиш, а не як це зробити. І це добре, я маю на увазі, кожен повинен знати, як щось робити, але продуктивність - це те, що робиться. Якщо бізнес попросить мене виконати завдання, це все, що їм цікаво. Коли я отримав галочку, щоб сказати, коли завдання було виконано? Не те, якою технікою чи технічним бабуванням я користувався, щоб потрапити туди. Отже, наш інструмент дозволяє зосередитись на чомусь, і дозволяє їм бути набагато продуктивнішими, і це справді величезна перевага, і, як я вже сказав, деякі бази даних пропонують інструмент саме для їх платформи баз даних. Ми пропонуємо його для дванадцяти платформ баз даних. У мене той самий робочий процес, той же графічний інтерфейс користувача, ті ж навігації. Якщо ви знаєте, як надати привілею користувачеві або як створити таблицю або створити індекс у базі даних, ви можете це зробити у всіх дванадцяти, оскільки це однаковий вигляд та відчуття та однаковий робочий процес. Це має величезне значення для наших клієнтів.

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

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

Берт Скальцо: Будь-яке середовище Windows, тому Windows 7, віртуальна машина з одним процесором та чотирма гігабайтми пам'яті. Ми не дуже жирний чи дорогий інструмент. Тепер, якщо ви хотіли запустити сервер баз даних на тому самому VM під тією самою Windows, так, вам потрібно буде додати більше, але якщо ви запускаєте свою базу даних на сервері баз даних або на окремому VM, VM завантажується і запуск нашого продукту дуже легкий: один процесор, чотири гіга пам’яті, майже будь-яка версія Windows - і ми підтримуємо як тридцять два, так і шістдесят чотири біти. Але вам доведеться встановити клієнта постачальника вашої бази даних. Отже, якщо ви хотіли підключитися до Oracle, вам доведеться встановити чистий клієнт SQL, тому що Oracle вимагає, щоб ви могли спілкуватися з базою даних.

Дез Бланчфілд: Це звучить досить прямо. Я думаю, що одне з цього більше, ніж усе, що я сподіваюся, що люди збираються забрати, окрім усвідомлення того, що цей інструмент врятує їхнє життя, - це те, що вони повинні зайти і завантажити його та пограти з ним, враховуючи, що ви пропонуєте чотирнадцятиденну безкоштовну пробну версію. І він може працювати на їх теперішньому ноутбуці, не встановлюючи нічого зайвого, тому що якщо вони вже займаються адмініструванням баз даних, вони вже працюють з базами даних, у них є всі ці інструменти на місці та незалежно від того, чи працює він на локальній машині виправлення або на їх локальний робочий стіл, це здається, що безболісно встановлювати і грати. Тому я дуже рекомендую це зробити людям.

Робін, я впевнений, що у тебе є питання, Ерік, ти, мабуть, отримав кілька глядачів, тож Робін, а як же я перейти до тебе, а потім назад до Еріка?

Робін Блор: Так, добре, добре, я маю на що сказати, я маю на увазі, я завжди вважав цю область захоплюючою, бо вона була - я різав зуби на ній. Але правда - це, мабуть, приблизно з 1998, 1999 рр. Я суперечив тому, на що насправді Oracle здатний. І я знав, що Sybase і Microsoft SQL Server, обидва з них досить прості в порівнянні з тим, що може зробити Oracle. Ти змусив мене сміятися, коли ти - я маю на увазі, я закрив рот, коли ти почав говорити про заточування. Oracle робив це раніше. Оракул, який був представлений в якийсь момент часу, вони нервували об'єктно-реляційну ідею, тому вони ввели можливість створювати своєрідну нотацію об'єкта та зберігання об'єктів в Oracle, і я поговорив з одним із їхніх інженерів, щось на зразок пари років після того, як вони представили його, і я запитав, скільки людей використовує його, і він сказав, що я думаю, що два клієнта спробували це, і це було все. І я думаю, що те ж саме станеться, якщо вони почнуть пробувати і робити тенденційні речі NoSQL. Ви знаєте, я думаю, що це помилка, я маю на увазі, мене цікавить, які ваші думки. Безумовно, вони - п'ють Kool-Aid. Їм здається, що вони повинні мати можливість подавати претензії, схожі на великі бази даних NoSQL, такі як Кассандра, але ви знаєте, чи має це для вас сенс?

Берт Скальцо: Ні, ти вдарив цвях прямо по голові. Для мене я б, якщо я збираюся робити реляційні, я виберу реляційного постачальника, як Oracle або SQL Server, DB2 чи Postgres, але якщо я буду робити щось, що є нереляційним, у просторі великих даних, або в просторі NoSQL, я підберу потрібний інструмент для правильної роботи. І я не думаю, що це, природно, спочатку перейде до мого постачальника реляційних баз даних. А потім, ви додаєте до нього іншу зморшку, тобто, що є у хмарі? Так багато людей хочуть отримати свої бази даних від приміщення Тоді ви повинні подивитись на свого постачальника хмар і сказати: «Гаразд, що ви надаєте, які бази даних у вас є для мене, які відповідають моїм потребам і наскільки вони є придатними, і, чесно кажучи, яка ставка або плата за використання цієї бази даних у хмарі на годину чи на день. І на гігабайт, або на терабайт? "І те, що ви знайдете, - це, можливо, деякі порівняно новіші бази даних, такі як Монго чи Кассандра, можливо, їхні тарифи дешевші, тому, якщо ви збираєтеся робити великі дані з петабайтним рівнем, ви можете доведеться - лише з точки зору витрат - розглянути бази даних NoSQL у хмарі, оскільки це може бути найвигіднішим способом це зробити.

Робін Блор: Так, правильно. Я маю на увазі, мій досвід - що стосується реляційних баз даних, на мій досвід - який досить довгий, щоб мати шрами, це точно - є багато здорового глузду, що якщо ви почнете його застосовувати і - ви розумієте, що таке реляційне насправді, це, Я маю на увазі, я пам’ятаю, що колись хотів провести консультацію з одним клієнтом, і вони завели мене до кімнати, і вони зробили своєрідну схему сутності та створили третю нормальну форму - модель того, як виглядали первинні системи компанії. У ній було двісті сорок столів, і вони сказали: «Ну, що ти думаєш про це? Ми збираємося створити для цього базу даних ", і сказав" Що ви думаєте про це? "Я сказав:" Я не думаю, що це спрацює ". І це точно так, знаєте, бо вони закінчувалися вгору, щоб створити конкретну структуру в межах одинадцятисторонніх приєднань. І це те, що потрібно зрозуміти щодо реляційних. Тож я начебто зацікавлений щодо того, наскільки поганий дизайн ви стикаєтесь. Я маю на увазі, що у мене немає жодних проблем з DBArtisan - він робить дуже розумні речі, і те, що ви насправді можете показувати на багатьох платформах, я думаю, є чудовим - але наскільки ви стикаєтесь там, де проблема з дизайном де люди могли самі вирішити всілякі душевні болі, якби вони зійшли до зіркової схеми, а не отримували про це сніжинку, знаєте?

Берт Скальцо: Ну, я не хочу звучати як самонадеяний або зухвалий, але хотів би сказати частіше, ніж ні. Зрозуміло, що у більшості баз даних, якими я займаюся там, у них є проблеми або проблеми. Що добре, тому що наші інструменти, як наш інструмент оптимізатора баз даних, можуть допомогти їм вирішити ці проблеми, але, що мені справді смішно, це те, що багато проблем - це ті самі прості проблеми знову і знову. Я днями працював із клієнтом, у якого був запит приєднатись в одинадцять разів, і я начебто: «Добре, чому ти не використав клауз?», І вони на кшталт «Ну, я не "Я не знаю, що це таке". І тоді я сказав: "І подивіться на ваш суб-вибір тут, на ваш корельований і ваш неспоріднений", - сказав я, "У деяких випадках у вас є пункт де на найглибшому рівні, Довідник таблиці формується із зовнішнього. "Я сказав:" Отож, перенесіть його на потрібний рівень, не вкладайте його глибше, ніж це має бути, ви переплутаєте оптимізатор ". І за допомогою декількох налаштувань ми взяв щось, що працювало близько двох годин, і знизив його на десять хвилин, і це було просто - в такому випадку ми не зробили нічого іншого, крім вдосконалення написаного ними SQL. Я думаю, що проблема полягає в тому, що багато університетів і багато людей, які вивчають програмування в неакадемічному середовищі, вони вивчають це як записаний час або процес, орієнтований на рядки, і реляційний - це набір, орієнтований на природу, і так ви доведеться думати наборами, щоб написати хороший SQL.

Робін Блор: Так, я думаю, що це точно так. І ви повинні зрозуміти, це такі речі, як люди повинні знати ABC такі речі. Це не має значення. Ви не зможете робити раціональні речі, якщо ви не усвідомлюєте, що навіть добре спроектована, добре спроектована база даних, приєднання потребує часу, сортування займе час. Вони роблять це тому, що світ ніколи не знайшов способу змусити їх йти швидко. Вони знайшли способи впорядкування даних, щоб вони проходили швидше, ніж інакше, і великий ентузіазм, який я маю сказати для баз даних NoSQL, просто полягає в тому, що вони уникають приєднання. Вони просто починають створювати бази даних з однаковим розповсюдженням в них даних, тому що якщо ви приєднаєтесь до будь-якої з баз даних NoSQL, вони сильно смокчуть. Ти не думаєш?

Берт Скальцо: Безумовно. І мені слід сміятися, тому що я почав шлях до реляційних баз даних і назад, коли Інгрес був РТІ, Інститут реляційних технологій, і у нас не було SQL, у нас були реляційні мови до SQL. Думаю, тоді в Інгресі його називали Квель. Отже, ви отримали від цих старих парадигм бази даних, таких як мережа та вища графічна чи ієрархічна, і ви проходите через реляційні парадигми через пару десятиліть, і тепер мені здається, що ми знову повертаємося майже до ієрархічної. Це майже так, як ми повернулися.

Робін Блор: Так, правильно. Краще передайте Еріку, я витрачаю занадто багато часу, але чи є у нас якісь запитання від аудиторії, Еріку?

Ерік Кавана: У нас є кілька. Ми йдемо трохи довше тут, але я перекину пару на вас. У нас було кілька запитань навколо невидимих ​​індексів. Одне питання було: «Чи потрібно комусь користуватися вашим інструментом, щоб побачити їх?» Інше питання було: «Ну що робити, якщо ви сліпі?»

Берт Скальцо: Це добре.

Ерік Кавана: Цікаве питання теж, тож просто FYI.

Берт Скальцо: Ні, не потрібно мати наших інструментів. Це функція Oracle, індекс невидимок. В основному в словнику даних Oracle просто зберігає фрагмент метаданих, який говорить: "Оптимізатор, ігноруйте цей індекс. Це тут, але якщо ви не отримаєте фізичні вказівки через підказку в, натяк оптимізатора в команді SQL, не використовуйте це. "І так, ні, вам не потрібно мати наших інструментів, і в будь-якому відношенні це це звичайний старий індекс, ви можете бачити його в будь-якому інструменті, він просто оптимізатор скаже: "Ми будемо ігнорувати його при звичайній обробці запитів". Ви повинні направити його, якщо хочете, щоб він звик. Це дуже зручно для описаного мною сценарію, який є, якщо ви хотіли створити індекс у виробництві, але не ризикуєте зламати звіти або речі, які вже запущені, але ви хотіли перевірити їх, ви могли це зробити. Ось для чого це найкорисніше.

Ерік Кавана: Це хороші речі, і тут виникло ще одне хороше питання. «А як щодо деяких цих нових баз даних в пам'яті? Як технології бази даних в пам'яті змінюють гру щодо індексації? "

Берт Скальцо: Хлопчик, ну ми - тепер це добре, я радий, що хтось задав це питання, нам доведеться їхати ще півгодини. Ні, в пам'яті, це залежить від постачальника бази даних. Зараз, як правило, я є, я не кажу нічого, крім похвали за все, що робить Oracle, тому що це дивовижна технологія, яку вони побудували, але коли ти відірвешся під обкладинки і дивишся, що є в пам'яті в Oracle, в Oracle база даних, що це насправді - це все ще зберігається рядок на диску, і він завантажиться в пам'ять стовпців-пам'яті, і якщо недостатньо пам’яті, щоб вмістити всю таблицю, вона повернеться до порцій; це не вписується в пам'ять, робити це зберігання рядків, і таким чином ви насправді можете зробити вибір проти таблиці та для половини таблиці, ви використовуєте індексацію, потрапляючи на традиційні рядки за столом, а для другої половини виберіть, що насправді виходить, і просто захоплює все з пошуку в пам'яті, і так, це відрізняється тим, як SQL Server, наприклад, реалізував це за допомогою своєї технології Hekaton, як ви знаєте, і SQL 2014, і це було вдосконалено у SQL 2016, але, в деяких аспектах, їхня версія є більш вірною версією пам’яті, але, але кожна реалізація має свої плюси і мінуси, але вам потрібно заглянути в обкладинки і усвідомити. Тому що у мене був клієнт, який сказав: "О, це пам’ять цієї таблиці - я просто збираюся скласти всі індекси", і я начебто: "Таблиця більша за об'єм пам'яті, яку ви маєте на сервері, тож у якийсь момент деякі запити потрапляють на диск ».

Ерік Кавана: Це хороший опис; це хороший матеріал. Ну, люди, у нас буде ще кілька веб-трансляцій з цими хлопцями протягом решти цього року, повертайтеся будь-коли, коли почуєте, як Берт був на презентації, бо ми знаємо, що він знає свої речі. Завжди весело спілкуватися з експертами. Ми зберігаємо всі ці трансляції для подальшого перегляду. Ось контактна інформація Берта ще раз, і ми спробуємо перекопати це посилання для завантаження та надіслати його також електронною поштою, але ви завжди можете відправити електронний лист по-справжньому: у нас є ще безліч веб-трансляцій для цього. рік, і ми зараз робимо ед-кал, тож, люди, якщо є якісь теми, про які ви дійсно хочете почути наступного року, не соромтесь: Бережіться, люди, ми поговоримо з вами наступного разу. Бувай.

Партнер з вмісту Techopedia

Персонал Techopedia пов'язаний з Bloor Group і з ним можна зв’язатися, скориставшись опціями праворуч. Для отримання інформації про те, як ми працюємо з галузевими партнерами, натисніть тут.

• Профіль
• Веб-сайт