MasterZivOn 29.01.2011 22:41, exploys wrote:

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

Родной мой, если для JOIN-а нет индекса, то там ВСЁ ЧТО УГОДНО будет ЛУЧШЕ,
чем ничего. В смысле, чем O(N*M) ( N,M - размеры таблиц в JOIN-е).
Что тут думать ? Оно будет хуже только при очень малых N,M, типа 1-2-3.

Зачем вообще думать о JOIN-ах без индексов -- не понимаю. JOIN без индекса --
надо уволнять программиста, который его (и/или БД) написал.

Если есть индексы по обоим полям то применялось бы всегда MERGE или NESTED LOOP. Тогда и не было бы смысла в HASH JOIN в принципе. Кроме того индексы могут быть, но не всегда могут применяться, к примеру при соединении трех больших таблиц. И к чему весь этот бред про более оптимальные алгоритмы?

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

Как вы обойдетесь без HASH JOIN, когда 3 таблицы имеют размеры от 1000000 строк?
По таблице B будет использоваться либо индекс по B.A_ID либо B.ID.

MasterZiv> Т.е. в этом случае, когда нету индексов и обе таблицы не помещаются в памяти по
> вашему оптимальнее будет использовать SORT MERGE и NESTED LOOP?

1) как правило СУБД никогда не завязываются на содержимое кэша при составлении
планов. Кэш потому что может быть и почищен ко времени выполнения запроса.

Кэш тут вообще не причем.
Таблицы не помещается в памяти - означает, что они не помещаются в памяти. Т.е. их размер больше чем свободное RAM. СУБД оценивает количество необходимых IO включая запись в Temp.


vadiminfo , SORT MERGE это вообще сортировка слиянием и никакого отношения к соединениям не имеет. А NESTED LOOP используется когда одна из таблиц исключительно мала и никак не может применяться для соединения двух больших таблиц. Учите матчасть.
С картезианом туда же.

NESTED LOOP на миллионных таблицах...
Мда господа, 5 баллов! :)

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

Это не я так делаю, а оптимизаторы MS SQL и Oracle, а вы можете опасаться и дальше. Тем более, что очевидно вы так и не прочитали по приведённым ссылкам как на самом деле работает HASH JOIN.

Вы когда-нибудь с СУБД работали?

tanglirexploysВы когда-нибудь с СУБД работали?Вы форумом не ошиблись ?
Меня удивляет, что во-первых люди пишут не по теме поста, а во-вторых бред. Надо же как-то выяснить в чем причина.

miksoftexploysа во-вторых бред. Надо же как-то выяснить в чем причина.Ну так Вы цитируйте конкретные места и указывайте с чем именно Вы не согласны. Желательно со ссылками на доку/источники, подтверждающие Вашу правоту. А то, действительно, больше на ПТ похоже.
Вы чем читали? Я подробно все описал с сылками и примерами.
Лично вам я ответил и привел ссылки, что ваше описание HASH JOIN не полно и привел несколько ссылок.

miksoftexploysЛично вам я ответил и привел ссылки, что ваше описание HASH JOIN не полно и привел несколько ссылок.Сорри, не вижу. Может, не мне, а MasterZiv-у?
Может ему. Перечитайте весь топик и если разбираетесь поймете кто прав.

авторТак вот и я о чем. Что группировка по хэш значениям это второстепенная задача. Когда хэш-таблица становиться слишком большой тогда действительно она делиться на группы по хэш-функции выполняющей роль двухуровневого дерева. Но O(1) - может быть в случае отображения через хэш-функцию непосредственно адресов строк в памяти.

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

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

+
Основные сведения о хэш-соединениях
Выводы?

vadiminfoЭто значительно поднимает ценность MERGE или NESTED LOOP. Ну тада собсно Хэш особо и не нужен получается, поскоку индексы понасоздавать может кажный.
Т.е. по вашему всегда можно понасоздавать индексов и всегда они будут использоваться, а HASH JOIN в СУБД реализовали зря? :)

vadiminfoexploysТ.е. по вашему всегда можно понасоздавать индексов и всегда они будут использоваться, а HASH JOIN в СУБД реализовали зря? :)
Нет это Вы сказали, что если есть индексы, то HASH JOIN не нужен. Я то так не считал до сих пор, что он эффективнее всех остальных алгоритмов при определенных факторах (соединение на равеннство, относительно небольшая меньшая табла) всех дуругих известных алгоритмов не зависмо от наличия индексов на соединемые поля. Т.е. создавай не создавай индексы, нельзя пока обойтись.

Но если Вы были правы, то можно было бы. Тада да, зря парились, поскоку "Если есть индексы по обоим полям то применялось бы всегда MERGE или NESTED LOOP".

Как вы обойдетесь без HASH JOIN, когда 3 таблицы имеют размеры от 1000000 строк?
По таблице B будет использоваться либо индекс по B.A_ID либо B.ID.

NESTED LOOP
авторСоединение вложенных циклов является особенно эффективным в случае, когда внешние входные данные сравнительно невелики , а внутренние входные данные велики и заранее индексированы.

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

vadiminfo,

Как вы обойдетесь без HASH JOIN, когда 3 таблицы имеют размеры от 1000000 строк?
Покрывающие индексы созданы по:
A.ID
B.A_ID
B.ID
C.B_ID
По таблице B будет использоваться либо индекс по B.A_ID либо по B.ID.

NESTED LOOP
авторСоединение вложенных циклов является особенно эффективным в случае, когда внешние входные данные сравнительно невелики , а внутренние входные данные велики и заранее индексированы.

MERGE
авторСоединение слиянием — очень быстрая операция, но она может оказаться ресурсоемкой, если требуется выполнение операций сортировки .[/quot]

vadiminfoexploysЕсли есть индексы по обоим полям то применялось бы всегда MERGE или NESTED LOOP. Тогда и не было бы смысла в HASH JOIN в принципе.

exploysиндексы созданы


Ну на скока я понял Вы обошлись без HASH JOIN "в принципе"?

А я, если прикажет партия непеременно "обойтись" без HASH JOIN, напишу хинты, наверное, на случай если оптимизатор выберет HASH JOIN.
Вы читать умеете?

По таблице B будет использоваться либо индекс по B.A_ID либо по B.ID.
Индекс создан, но использоваться не сможет. Поэтому хоть обсоздавайся индексов, без HASH JOIN ты тот запрос будешь выполнять до морковкеного заговенья. Именно потому, что таблицы не отсортированы, слишком велики и не помещаются в памяти.

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

Если укажите хинт MERGE JOIN, то пойдет сортировка - самая тяжелая операция. Таблицы не помещаются в памяти - значит сортировка будет происходить с использованием temp сохраняемого на диск. Вы представляете что это такое?
Вы когда-нибуть видели планы и их стоимость при использовании SORT IN TEMP?