Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 34 35 36 37 38 [39] 40 41 42 43 .. 50   вперед  Ctrl
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1720
Картинка с другого сайта.
30 сен 19, 12:10    [21982533]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10221
rdb_dev,

включи мозг. В СУБД самое узкое место это IO и именно его надо экономить.
Пока индексы и таблица полностью вмещаются в кеш всё хорошо на любом алгоритме. И то не всегда так. fetch из страничного кеша тоже пожирает процессор.
Или ты считаешь производителей других СУБД полными идиотами, что они HASH используют чаще чем NESTED LOOP с индексами?
30 сен 19, 13:10    [21982629]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Симонов Денис, что ты собираешься экономить, если записи связываемых наборов, по полям которых СУБД будет строить хэш-индексы, отсутствуют в кэше? А если СУБД необходимо загрузить все эти данные с HDD, потом ещё и хэш-индексы рассчитать и построить, вместо того, чтобы просто загрузить страницы готовых индексов, то где тут ускорение?
30 сен 19, 13:17    [21982635]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48866

rdb_dev
потом ещё и хэш-индексы рассчитать

При чём тут хэш-индексы, тебе говорят о хэш-таблице. Это две большие разницы. На этот раз
ты сильно ошибся с гуглем.

Posted via ActualForum NNTP Server 1.5

30 сен 19, 13:21    [21982638]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Симонов Денис
Или ты считаешь производителей других СУБД полными идиотами, что они HASH используют чаще чем NESTED LOOP с индексами?
Я считаю, что подобные вещи сделаны для многократного переиспользования одних и тех же данных в SP, EB, триггерах и функциях на полях, по которым, по какой-то причине, нет обычных индексов. Возможно, это такой метод перестраховаться, но всё равно не понятно - как они собираются обеспечить безошибочность связывания при хэшировании байтовых последовательностей размером существенно больше, чем результат функции хэширования. Ещё раз, HASH интересен только при сравнении больших объемов данных - длинных строк или блобов. Если построенный индекс хэша позволяет тебе быстрее идентифицировать наличие в системе хранения точно такого же документа, который поступает на вход, то можно использовать дедупликацию документов или поиск документа в системе по его копии, но обязательно с последующим контекстным сравнением, поэтому хэши просто необходимы для Big Data.
30 сен 19, 13:27    [21982645]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10221
rdb_dev,

потому что HASH JOIN это два NATURAL. Они не вытесняют кеш, в отличие от того когда доступ идёт по индексу.
Плюс ты забываешь что по индексу страницы будут перечитываться повторно в некоторых случаях
30 сен 19, 13:27    [21982646]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Dimitry Sibiryakov, я вообще ни разу не пользовался какой-либо поисковой системой при обсуждении хэшей. ;)
Ты хочешь сказать, что "хэш-таблицы" не сделаны в виде обычных индексов, а сделаны в виде кластерного индекса или вообще никак не упорядочены? Очень занимательно!...
30 сен 19, 13:31    [21982652]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Симонов Денис, ну так не вытесняйте страницы индексов по связываемым наборам данных! Зачем? Чтобы потом строить хэш-таблицы и фигачить по ним связывание, всё равно размещая их в оперативной памяти? Бред какой-то!
30 сен 19, 13:34    [21982658]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48866

rdb_dev
Ты хочешь сказать, что "хэш-таблицы" не сделаны в виде обычных индексов, а сделаны в виде
кластерного индекса или вообще никак не упорядочены?

Ага. Они, строго говоря, и не таблицы вообще.

Posted via ActualForum NNTP Server 1.5

30 сен 19, 13:56    [21982688]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1720
rdb_dev
я вообще ни разу не пользовался какой-либо поисковой системой при обсуждении хэшей. ;)

зря
rdb_dev
Ты хочешь сказать, что "хэш-таблицы" не сделаны в виде обычных индексов, а сделаны в виде кластерного индекса или вообще никак не упорядочены?

- хештаблица ни разу не индекс в терминологии СУБД
- и таки да )) они не упорядочены
30 сен 19, 13:59    [21982696]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Dimitry Sibiryakov, ага! Потому что, строго говоря, они индексы и вообще не важно какой алгоритм для этого используется - B-TREE или красно-чёрные деревья, они упорядочены, что и позволяет обеспечить приемлемое время поиска.
30 сен 19, 13:59    [21982699]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1720
rdb_dev
Dimitry Sibiryakov, ага! Потому что, строго говоря, они индексы и вообще не важно какой алгоритм для этого используется - B-TREE или красно-чёрные деревья, они упорядочены, что и позволяет обеспечить приемлемое время поиска.

или вообще не сечешь (без обид) или это такое трололо
30 сен 19, 14:02    [21982702]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10221
rdb_dev,

пока ты не прочитаешь о хеш-таблицах и HASH JOIN, считаю обсуждать с тобой что-то бессмысленно
30 сен 19, 14:06    [21982708]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Симонов Денис, так где я это должен прочитать?! Второй раз спрашиваю.
30 сен 19, 15:09    [21982805]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Дегтярев Евгений
или вообще не сечешь (без обид) или это такое трололо
Первая же фраза в вики:
"Хеш-табли́ца — это структура данных, реализующая интерфейс ассоциативного массива, ..."

ВСЁ!!! Дальше можно не читать! Ассоциативный массив, это индекс. Даже если бы это был не ассоциативный массив с чёрно-красным деревом, а, всего лишь, дополнительный служебный столбец, по которому записи были бы упорядочены физически и который СУБД могла бы использовать посредством простого алгоритма поиска по упорядоченному списку с предсказанием по статистическому распределению или же тупо "поймай льва в пустыне", это всё равно ИНДЕКС! И тут уже не важен формат хранения.
30 сен 19, 15:13    [21982815]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48866

rdb_dev
Ассоциативный массив, это индекс.

Какой идиот тебе это сказал? Плюнь в глаз этому лжецу.

Posted via ActualForum NNTP Server 1.5

30 сен 19, 15:19    [21982826]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Dimitry Sibiryakov, раз ты так любишь гугл, но не в курсе элементарных понятий в области информационных систем и СУБД, придётся мне цитировать вики...
"Индекс (англ. index) — объект базы данных, создаваемый с целью повышения производительности поиска данных. Таблицы в базе данных могут иметь большое количество строк, которые хранятся в произвольном порядке, и их поиск по заданному критерию путём последовательного просмотра таблицы строка за строкой может занимать много времени. Индекс формируется из значений одного или нескольких столбцов таблицы и указателей на соответствующие строки таблицы и, таким образом, позволяет искать строки, удовлетворяющие критерию поиска. Ускорение работы с использованием индексов достигается в первую очередь за счёт того, что индекс имеет структуру, оптимизированную под поиск — например, сбалансированного дерева."

Заметь, здесь нет ни слова о формате хранения, а лишь указано, что это некий объект БД в котором значения индексируемых полей упорядочены и который СУБД использует для оптимизации поиска. Иными словами, банальная физическая упорядоченность набора записей по индексируемым столбца, которую СУБД может использовать для оптимизации поиска, также является индексом и, к примеру, в терминах MS SQL это называется "кластерный индекс" (clustered index). Так понятно?
30 сен 19, 15:25    [21982838]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10221
rdb_dev,

ты достал уже своей некомпетентностью. Читай медленно и до конца о хеш-таблицах.
Ну не упорядочена она совсем. По ходу курс "Структуры Данных" у вас в институте отсутствовал.
30 сен 19, 15:31    [21982848]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48866

rdb_dev
Индекс (англ. index) — объект базы данных, создаваемый с целью повышения
производительности поиска данных.

И, внезапно, ни ассоциативный массив вообще, ни хэщ-таблица в частности не являются
объектами базы данных. Поэтому давай, плюй в глаз идиоту.

Posted via ActualForum NNTP Server 1.5

30 сен 19, 15:31    [21982849]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Dimitry Sibiryakov
И, внезапно, ни ассоциативный массив вообще, ни хэщ-таблица в частности не являются
объектами базы данных. Поэтому давай, плюй в глаз идиоту.
Рукалицо...
Столбец таблицы, это объект БД? Объект!
Физическое упорядочение набора записей по конкретному столбцу, которое сервер СУБД может использовать для оптимизации поиска, это индекс? Индекс!
Отношение упорядоченных значений столбца к записям того же набора, это ассоциативный массив? Безусловно!

Что тебе опять не так?
30 сен 19, 15:37    [21982858]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Симонов Денис
rdb_dev,
ты достал уже своей некомпетентностью. Читай медленно и до конца о хеш-таблицах.
Ну не упорядочена она совсем. По ходу курс "Структуры Данных" у вас в институте отсутствовал.
Некоторые преподаватели даже в университетах учат так, что лучше бы не учили вовсе, а просто давали читать грамотную профильную литературу, вместо того, чтобы вводить в заблуждение учащихся и давать им некорректные определения.
30 сен 19, 15:47    [21982878]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9599
rdb_dev
Физическое упорядочение набора записей по конкретному столбцу, которое сервер СУБД может использовать для оптимизации поиска, это индекс?
Начать можно с того, что у ОгнеПтицы нет таблиц, упорядоченных по индексу ...
30 сен 19, 15:50    [21982885]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3062
Basil A. Sidorov, а как же хэш-таблицы? Или они ни разу не ассоциативный массив?
30 сен 19, 15:53    [21982890]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9599
rdb_dev
а как же хэш-таблицы?
А этот вопрос к чему???
30 сен 19, 15:55    [21982892]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10221
rdb_dev,

ну да все вокруг дураки и твердят тебе что хэш-таблица это не индекс. А ты один умный.

И да тот же оракуль лепит HASH JOIN во все щели (заверяю там нет никаких хранимок).
Отчасти это из-за устройства их индексов, но не только поэтому. Наверное дураки
30 сен 19, 15:55    [21982893]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 34 35 36 37 38 [39] 40 41 42 43 .. 50   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить