Сколько индексов базы данных слишком много?

Question

Я работаю над проектом с довольно большой базой данных Oracle (хотя мой вопрос в равной степени относится и к другим базам данных). У нас есть веб-интерфейс, который позволяет пользователям выполнять поиск практически по любой возможной комбинации полей.

Чтобы ускорить этот поиск, мы добавляем индексы к полям и комбинациям полей, по которым, как мы полагаем, пользователи будут часто искать. Однако, поскольку мы не знаем, как наши клиенты будут использовать это программное обеспечение, сложно определить, какие индексы создать.

Пространство не проблема; у нас есть 4-терабайтный RAID-накопитель, из которого мы используем лишь небольшую часть. Однако меня беспокоит возможное снижение производительности из-за слишком большого количества индексов. Поскольку эти индексы необходимо обновлять каждый раз при добавлении, удалении или изменении строки, я думаю, было бы плохой идеей иметь десятки индексов в одной таблице.

Так сколько индексов считается слишком большим? 10? 25? 50? Или я должен просто охватить действительно, действительно распространенные и очевидные случаи и игнорировать все остальное?

Answer 1

Это зависит от операций, которые происходят с таблицей.

Если есть много SELECT и очень мало изменений, индексируйте все, что вам нравится ... это (потенциально) ускорит операторы SELECT.

Если таблица сильно пострадала от ОБНОВЛЕНИЙ, ВСТАВКИ + УДАЛЕНИЯ ... они будут очень медленными с большим количеством индексов, поскольку все они должны изменяться каждый раз, когда выполняется одна из этих операций

Сказав это, вы можете явно добавить в таблицу множество бессмысленных индексов, которые ничего не будут делать. Добавление индексов B-Tree в столбец с двумя различными значениями будет бессмысленным, поскольку оно ничего не добавляет в плане поиска данных. Чем более уникальны значения в столбце, тем больше он выиграет от индекса.

Answer 2

Обычно я так поступаю.

1. Получить журнал запросов real , выполняемых на данных в обычный день.
2. Добавьте индексы, чтобы наиболее важные запросы попадали в индексы в их плане выполнения.
3. Старайтесь не индексировать поля, в которых много обновлений или вставок
4. После нескольких индексов получите новый журнал и повторите.

Как и при любой другой оптимизации, я останавливаюсь при достижении запрошенной производительности (это, очевидно, подразумевает, что точка 0. получит конкретные требования к производительности).

Answer 3

Все остальные дают вам отличный совет. У меня есть дополнительное предложение для вас, когда вы продвигаетесь вперед. В какой-то момент вы должны принять решение о вашей лучшей стратегии индексации. В конце концов, лучшая стратегия индексирования PLANNED может все же в конечном итоге создать индексы, которые в конечном итоге не будут использованы. Одна из стратегий, позволяющая находить неиспользуемые индексы, заключается в мониторинге использования индексов. Вы делаете это следующим образом: -

alter index my_index_name monitoring usage;

После этого вы можете отслеживать, используется ли индекс с этого момента, выполнив запрос v $ object_usage. Информацию об этом можно найти в Oracle® Database Administrator's Guide .

Просто помните, что если у вас есть складская стратегия удаления индексов перед обновлением таблицы, а затем их повторного создания, вам придется заново настроить индекс для мониторинга, и вы потеряете всю историю мониторинга для этого индекса.

Answer 4

В хранилищах данных очень часто бывает большое количество индексов. Я работал с таблицами фактов, имеющими двести столбцов, и 190 из них проиндексированы.

Несмотря на то, что в этом есть издержки, следует понимать, что в хранилище данных мы обычно вставляем строку только один раз, мы никогда не обновляем ее, но затем она может участвовать в тысячах запросов SELECT, которые могут извлечь выгоду из индексации. на любом из столбцов.

Для максимальной гибкости хранилище данных обычно использует одноколонные индексы растровых изображений, за исключением столбцов с высокой мощностью, где могут использоваться (сжатые) индексы btree.

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

Чтобы ответить на ваш вопрос более прямо, я думаю, что поначалу было бы неплохо проиндексировать очевидное, но не бойтесь добавлять больше индексов, если выигрывают запросы к таблице.

Answer 5

Перефразируя Эйнштейна о простоте, добавьте столько индексов, сколько вам нужно, и не более.

Серьезно, однако, каждый добавляемый вами индекс требует обслуживания при добавлении данных в таблицу. Для таблиц, которые в основном предназначены только для чтения, хорошо использовать множество индексов. Для таблиц с высокой динамикой лучше меньше.

Мой совет заключается в том, чтобы охватить общие и очевидные случаи, а затем, когда вы сталкиваетесь с проблемами, требующими большей скорости в получении данных из конкретных таблиц, оценивать и добавлять индексы на этом этапе.

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

Answer 6

В дополнение к пунктам, которые все остальные подняли, оптимизатор на основе затрат несет затраты при создании плана для оператора SQL, если существует больше индексов, потому что есть больше комбинаций для его рассмотрения. Вы можете уменьшить это, правильно используя переменные связывания, чтобы операторы SQL оставались в кэше SQL. Затем Oracle может выполнить мягкий анализ и повторно использовать план, который он нашел в прошлый раз.

Как всегда, все просто. Если задействованы перекошенные столбцы и гистограммы, это может быть плохой идеей.

В наших веб-приложениях мы стремимся ограничить количество возможных поисков. В противном случае вам пришлось бы тестировать буквально каждую комбинацию на производительность, чтобы убедиться, что у вас нет скрытой проблемы, которую кто-то найдет однажды. Мы также установили ограничения по ресурсам, чтобы предотвратить возникновение проблем в других местах приложения, если что-то пойдет не так.

Answer 7

Я провел несколько простых тестов на своем реальном проекте и реальной базе данных MySql. Я уже ответил в этой теме: Какова стоимость индексации нескольких столбцов дБ?

Но я думаю, что будет лучше, если я приведу это здесь:

Я сделал несколько простых тестов, используя мой реальный проект и реальная база данных MySql.

Мои результаты: добавление среднего индекса (1-3 столбца в индексе) к таблице - делает вставки медленнее на 2,1%. Так что если Вы добавите 20 индексов, ваши вставки будут быть медленнее на 40-50%. Но вы выбираете будет в 10-100 раз быстрее.

Так нормально ли добавлять много индексов? - Это зависит :) Я дал вам свои результаты - Вы решать!

Answer 8

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

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

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

Answer 9

На мой взгляд, нет статического ответа, такого рода вещи подпадают под «настройку производительности».

Может случиться так, что все, что делает ваше приложение, просматривается первичным ключом, или это может быть противоположностью тому, что запросы выполняются для неограниченных комбинаций полей, и любое из них может быть использовано в любой момент времени.

Помимо индексирования, существует реорганизация вашей БД для включения вычисляемых полей поиска, таблиц разбиения и т. Д. - это действительно зависит от ваших форм загрузки и параметров запроса, от того, сколько / какие данные «действительно» необходимо повторно обработать запросом. 1005 *

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

Для SQL Server я нашел советника по настройке ядра СУБД полезным - вы устанавливаете «типичные» рабочие нагрузки, и он может давать рекомендации по добавлению / удалению индексов и статистики. Я уверен, что другие БД имеют аналогичные инструменты, «официальные» или сторонние.

Answer 10

Это действительно более теоретические вопросы, чем практические. Влияние индексов на вашу производительность зависит от имеющегося у вас оборудования, версии Oracle, типов индексов и т. Д. Вчера я слышал, что Oracle объявила о выделенном хранилище от HP, которое должно работать в 10 раз быстрее с базой данных 11g. Что касается вашего случая, может быть несколько решений: 1. Имейте большое количество индексов (> 20) и перестраивайте их ежедневно (ночью). Это было бы особенно полезно, если бы таблица ежедневно получала тысячи обновлений / удалений. 2. Разделите вашу таблицу (если это применимо к вашей модели данных). 3. Используйте отдельную таблицу для новых / обновленных данных и запускайте ночной процесс, который объединяет данные вместе. Это потребует изменения в логике вашего приложения. 4. Переключитесь на IOT (индексированная организованная таблица), если ваши данные поддерживают это.

Конечно, для такого случая может быть гораздо больше решений. Мое первое предложение - клонировать БД в среду разработки и провести на ней стресс-тестирование.