Комментарии 41
НЛО прилетело и опубликовало эту надпись здесь
Хотелось бы по подробнее узнать, для каких случаев какие индексы лучше выбрать.
Это довольно большой объем нетривиальной информации будет, в следующих статьях постараюсь затронуть как можно больше различных вариантов.
Поддержу. Хотелось бы узнать плюсы и минусы разных типов индексов.
Тут вопрос в том, что еще нужно решать — а стоит ли использовать индексы в конкретной таблице.
Я в одной таблице задал только Primary key и все. Ибо в нее идет только запись. Когда там было еще пару индексов — мускуль вешался неплохо… Таблица уже гига полтора весит. Индексы нужны были на varchar полях.
Я в одной таблице задал только Primary key и все. Ибо в нее идет только запись. Когда там было еще пару индексов — мускуль вешался неплохо… Таблица уже гига полтора весит. Индексы нужны были на varchar полях.
НЛО прилетело и опубликовало эту надпись здесь
Полезно, спасибо. Но, всё-таки, очень хочется увидеть развёрнутое описание каждого типа индексов. Понятно, что всё это есть в документации, но в большинстве случаев информация в ней слишком размазана по разным главам, поэтому компиляция инфы по одной теме в одном документе всегда очень полезна. Может возьмётесь, раз начали? «И моя благодарность не будет иметь границ в разумных пределах» (ц)
Развёрнутое описание каждого типа индексов, превышающее по информативности официальную документацию — можно получить только описав практическое применение того или иного типа индексов в том или ином своём проекте. Не факт что автор использовал все описанные им типы индексов в практических разработках живых БД. Я к примеру битмапами ещё не пользовался (как впрочем и Spatial grid и R-tree)
Отличный обзор, спасибо!
У постгресса нет bitmat index'ов, однако он может строить такие структуры в памяти при выполнении запроса
В MSSQL в индексе можно указать обратную сортировкую, наверное это и есть Reverse index?
В PostgreSQL можно запросто организовать reverse index. Для этого достаточно сделать свою функцию сравнения (которая сравнивает в перевернутом порядке), а на основе неё класс операторов для btree, и использовать этот класс операторов для индекса.
Вопрос про Inverted index в Oracle. Имеется ввиду Oracle Text??
Я бы еще добавил partial index из Postgre SQL, пример из доки:
CREATE INDEX access_log_client_ip_ix ON access_log (client_ip)
WHERE NOT (client_ip > inet '192.168.100.0' AND client_ip < inet '192.168.100.255');
A typical query that can use this index would be:
SELECT * FROM access_log WHERE url = '/index.html' AND client_ip = inet '212.78.10.32';
CREATE INDEX access_log_client_ip_ix ON access_log (client_ip)
WHERE NOT (client_ip > inet '192.168.100.0' AND client_ip < inet '192.168.100.255');
A typical query that can use this index would be:
SELECT * FROM access_log WHERE url = '/index.html' AND client_ip = inet '212.78.10.32';
Добавил, но он есть только в PostgreSQL, в Oracle и MS SQL может быть сделан с помощью функциональных индексов, правда чуть большего размера.
Как можно сделать частичный индекс с помощью функционального?
Создав функциональный индекс, который при удовлетворяющих условию значениях будет возвращать само значение, в противном случае одинаковое маленькое заранее опреденное значение. Таким образом индекс станет меньше чем обычный как по размеру самих данных, так и по количеству в нем ветвей, но, конечно, он будет побольше.
Непонятно почему он меньше-то станет, указатели на все ряды с маленьким значением всё равно будут в нём хранится. И насколько это будет быстро работать?
Указатели на неудовлетворящие условию ряды будут, но все они будут в одном листе дерева.
Например, пусть есть таблица полем id заполненным от 1 до 1000000. Создаем функциональный индекс возвращающий -1 для всех кроме диапазона от 1 до 100. В таком случае у нас дерево для индекса будет высотой всего в 7 вместо 20
Например, пусть есть таблица полем id заполненным от 1 до 1000000. Создаем функциональный индекс возвращающий -1 для всех кроме диапазона от 1 до 100. В таком случае у нас дерево для индекса будет высотой всего в 7 вместо 20
Хорошая статья.
Также очень интересно узнать о практическом применении этих знаний — лично Вашем. То есть какие БД вы разрабатывали, их размер (по разным критериям), какая нагрузка на них была, на какой СУБД, где Вы использовали тот или иной тип индекса. Какие выбирали решения при проектировании структуры БД и прочее прочее прочее… Эта тема достаточно интересна, но малопопулярна на хабре.
К примеру — как лучше реализовать диапазонный поиск (индекс) для диапазонных значений (если вы сталкивались с такой задачей)…
Также очень интересно узнать о практическом применении этих знаний — лично Вашем. То есть какие БД вы разрабатывали, их размер (по разным критериям), какая нагрузка на них была, на какой СУБД, где Вы использовали тот или иной тип индекса. Какие выбирали решения при проектировании структуры БД и прочее прочее прочее… Эта тема достаточно интересна, но малопопулярна на хабре.
К примеру — как лучше реализовать диапазонный поиск (индекс) для диапазонных значений (если вы сталкивались с такой задачей)…
Подробнее опишу в следующих статьях, а сейчас вкратце насчет диапазонного поиска:
В таком случае есть три наиболее ярких варианта, если для простоты рассматривать только оптимизацию под большое количество select'ов:
1) Большое количество разных значений и они равномерно распределены
2) Большое количество разных значений и они очень неравномерно распределены(допустим, несколько значений у 90% записей)
3) Малое количество разных значений относительно общего количество записей
В первом варианте лучше всего будет «index organized»(это для Oracle, в MS SQL она называется clustered table) таблица секционированная по кластерному b-tree индексу. Таки образом и сама таблица будет отсортирована и поиск будет быстрее, т.к. после поиска первого значения будет использоваться проход по нижним листам дерева.
Во-втором варианте, скорее всего будет лучше использовать bitmap индекс, несмотря на то, что обычно его не советуют для диапазонного поиска. Дело в том, что поиск 90% записей будет проводиться гораздо быстрее, следовательно, при равномерном разбросе диапазонов запросов в 90% случаев будет быстрее чем b-tree
В-третьем варианте нюансов будет побольше и следовало бы оценить все факторы.Вот здесь подробнее, почему
В таком случае есть три наиболее ярких варианта, если для простоты рассматривать только оптимизацию под большое количество select'ов:
1) Большое количество разных значений и они равномерно распределены
2) Большое количество разных значений и они очень неравномерно распределены(допустим, несколько значений у 90% записей)
3) Малое количество разных значений относительно общего количество записей
В первом варианте лучше всего будет «index organized»(это для Oracle, в MS SQL она называется clustered table) таблица секционированная по кластерному b-tree индексу. Таки образом и сама таблица будет отсортирована и поиск будет быстрее, т.к. после поиска первого значения будет использоваться проход по нижним листам дерева.
Во-втором варианте, скорее всего будет лучше использовать bitmap индекс, несмотря на то, что обычно его не советуют для диапазонного поиска. Дело в том, что поиск 90% записей будет проводиться гораздо быстрее, следовательно, при равномерном разбросе диапазонов запросов в 90% случаев будет быстрее чем b-tree
В-третьем варианте нюансов будет побольше и следовало бы оценить все факторы.Вот здесь подробнее, почему
я имел ввиде не самостоятельный диапазонный поиск а именно для диапазонных значений, к примеру пользователь задал цену покупки от 1000 до 10000 и ему необходимо показать се предложения в этом диапазоне, а собственно продавцы задают чёткое значение. Я этузадачу решил, но интересно услышать ваш вариант…
НЛО прилетело и опубликовало эту надпись здесь
Подскажите, можно ли сделать какие-либо выводы относительно выбора той или иной субд исходя из представленной таблицы Сводная таблица типов индексов?
Что-то вроде «для решения таких-то задач лучше такие-то индексы, а вот эта и эта суд их не поддерживает, поэтому при прочих равных лучше вот эту субд».
Что-то вроде «для решения таких-то задач лучше такие-то индексы, а вот эта и эта суд их не поддерживает, поэтому при прочих равных лучше вот эту субд».
в PostgreSQL нет bitmap индексов. Есть bitmap index scan, который используется при выполнении запросов, чтобы упорядочивать записи по физическому расположению и чтобы пересекать/объединять результаты поиска по нескольким индексам
Мда, странно. Хотели включить еще три года назад, а до сих пор откладывают: developer.postgresql.org/index.php/Todo:PatchStatus
Вот можете еще посмотреть: pgug.org.nz/sites/pgug.org.nz/files/bitmap-indexes.pdf
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор типов индексов Oracle, MySQL, PostgreSQL, MS SQL