Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Таблица для хранения Nested Sets - почему рекомендуют составной индекс? / 10 сообщений из 10, страница 1 из 1
26.12.2012, 10:51
    #38093015
Kenworth
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Есть некая таблица, которая используется для хранения структуры дерева Nested Sets. Соответственно, в ней есть поля "левый_ключ", "правый_ключ" и "уровень". И вот во всех материалах, что мне попадались по Nested Sets, всегда на подобные таблицы устанавливается составной индекс (левый_ключ, правый_ключ, уровень). Иногда с пояснением, что так надо для быстродействия, чаще это момент вообще никак не комментируется.

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

Возвращаемся к Nested Sets. И видим, что значения в столбце "левый_ключ" у нас уникальны. Так зачем делают составной индекс? Что я упускаю из виду или понимаю неправильно?
...
Рейтинг: 0 / 0
26.12.2012, 12:31
    #38093205
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Kenworth,

Если все поля, на которые наложены условия выборки, входят в индекс - выборка происходит быстрее, поскольку серверу при поиске не приходится читать саму таблицу, только индекс.
...
Рейтинг: 0 / 0
26.12.2012, 13:59
    #38093374
Kenworth
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Кот МатроскинЕсли все поля, на которые наложены условия выборки, входят в индекс - выборка происходит быстрее, поскольку серверу при поиске не приходится читать саму таблицу, только индекс.

Понял, спасибо за объяснение.
...
Рейтинг: 0 / 0
26.12.2012, 21:35
    #38094152
Passed_by
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Kenworth,

Это не совсем так. Например, в PostgreSQL < 9-х версий Index Only Scan просто отсутствует (и таблица всегда читается), в MS SQL индекс можно сделать кластерным, и тогда дополнительного чтения таблицы и не нужно.

Зачем так надо для быстродействия, сходу не понятно.
...
Рейтинг: 0 / 0
27.12.2012, 07:03
    #38094359
Arhat109
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Kenworth,

Это имеет смысл, потому что любой джойн, любой движок БД "рано или поздно" переколбасит в обыкновенный "вложенный цикл" перебора записей (не забываем про банальный Ассемблер в самом низу)... таблицы или индекса... так вот, в ряде случаев, сортировка составного индекса - ускоряет просмотры таких вложенных циклов на порядки, потому что составной, сортированный индекс - гарантирует, что запись не будет пропущена при дихотомическом спуске по индексу... не знаю, как по-другому объяснить, но составные индексы - это не просто "три отдельных поля"... это почти "муж и жена"... :)

В Мускуле, используя переменные и составные индексы можно практически вручную управлять этим процессом перебора записей, и зная логику, ускорять выборки на порядки... но индивидуально к задаче... (из раздела "так делать не надо") :)
...
Рейтинг: 0 / 0
27.12.2012, 12:45
    #38094735
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Arhat109любой джойн, любой движок БД "рано или поздно" переколбасит в обыкновенный
"вложенный цикл" перебора записей
Да шаззз... А как же MERGE JOIN и HASH JOIN?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.12.2012, 16:57
    #38095194
Arhat109
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Dimitry Sibiryakov,

Что такое "щазззз"? Учите матчасть :), вот выписка из википедии (самому лениво):

Это про merge join:
Алгоритм соединения слиянием сортированных списков (merge join, sort merge join, sort-merge join) — разновидность алгоритма соединения.

Алгоритм получает на вход 2 таблицы и условие соединения. Результатом его работы является таблица с результатами соединения.

Входные таблицы должны быть отсортированы по столбцам , участвующим в условии соединения. Соединение осуществляется за одно сканирование (проход по) каждой из входных таблиц ( читай цикл, невложенный, потому что данные сортированы, о чём и написал, перечитайте внимательнее со слов "так вот..." ). То есть одна и та же строка считывается только один раз, что даёт преимущество перед соединением вложенными циклами...
...
Главным недостатком алгоритма является необходимость в предварительной сортировке списков. Накладные расходы на сортировку могут быть неприемлемо высокими.
При реализации в СУБД, соединение слиянием требует больше памяти и менее гибко, чем алгоритм соединения вложенными циклами.Многие авторы, в связи с этим, на практике рекомендуют избегать этого вида соединения. Во многих СУБД соединение слиянием по умолчанию не используется оптимизатором запросов и должно быть включено явно.


Далее про хеш-джойн:
Алгоритм соединения хэшированием (hash join) разновидность алгоритма соединения.

Алгоритм получает на вход 2 таблицы и условие соединения. Результатом его работы является таблица с результатами соединения.

Меньшая из двух входных таблиц помещается в специальную структуру данных в памяти: хэш-таблицу, которая обеспечивает очень высокую скорость поиска ( примечание - тоже самое и тут верно ). Затем для каждой строки из большей таблицы выполняется поиск значений, соответствующих условию соединения. Результаты помещаются в выходную таблицу.
...
Недостатки:

Условием соединения может быть только равенство.


... и эт-та, вопрос "об чём" был? О составном индексе... вот именно он и даёт ту самую сортировку ещё на стадии "вставки записи" ( понятно что за счет удлиненния времени вставки ), что и позволяет использовать "продвинутые методы", об чём и написал, вроде как. :)
...
Рейтинг: 0 / 0
27.12.2012, 17:21
    #38095255
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Arhat109эт-та, вопрос "об чём" был? О составном индексе... вот именно он и даёт ту
самую сортировку ещё на стадии "вставки записи"
Вопрос был "назачем он составной". А "сортировку на стадии записи" он даёт только если он
кластерный или в случае IOT. Нормальные индексы данные не упорядочивают.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.12.2012, 18:07
    #38095314
Arhat109
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Dimitry Sibiryakov, "на стадии записи" - это зрятраты на создание самого индексу...
...
Рейтинг: 0 / 0
27.12.2012, 18:13
    #38095318
Arhat109
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблица для хранения Nested Sets - почему рекомендуют составной индекс?
Arhat109, дополню: мне, и думаю не только мне, в целом "по-бабрабану" как там лежат сами данные. Индекс, в т.ч. и составной - таки упорядочен. И, если я знаю что выборка по упорядоченному составному индексу идет значительно быстрее, то в ряде отдельно взятых случаев (из разряда не надо так делать, но приходится) могу выжать ту производительность из запроса, которую мне другим способом не получить ну никак... вон тут совсем недавно, чел мучался: миллионная табличка ищет записи по 40 секунд... или чуть пораньше: как избежать неограниченно вложенных джойнов в деревьях на одном parent_id... легко. Посмотрите фак по деревьям в разделе Мускуля и дату моего первого поста про один запрос и без джойнов... ваще без. Простой скан индекса. :)
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Таблица для хранения Nested Sets - почему рекомендуют составной индекс? / 10 сообщений из 10, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]