Здравствуйте, AndrewVK, Вы писали:
GZ>>Одно из бенефитов встроенной базы данных должно быть то, что ты можешь работать с массивом информации с достаточно низким потреблением оперативной памяти.
AVK>Но затачивать дизайн под это я бы не стал. Максимум — сделать это регулируемым.
Обязательно. Но при слишком маленьком кэше быстродействие может пострадать. И возможно (пока только подозрения) эта зависимость может быть экспотенциальной.
Здравствуйте, stalcer, Вы писали: S>Кстати, когда СУБД делает хеш-джоин, она ведь строит хэш, то есть где-то его хранит. А если он в память не помещается?
Спулит на диск, естеснно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, GlebZ, Вы писали:
GZ>Да я то вполне понимаю(и про ошибочку с like понимаю ). Но наверняка начнутся привязки системы поиск к несвойственным ему полям. Другого пути то нет. Есть поле comments, в который кладут некоторый коментарий. И захотелось программеру сделать по нему поиск. Обычно комментс в районе 200-300 байт(если не null), но один коммент — 2000 кила. Ошибка вывалится то у пользователя, и что делать? Какой нибудь рычаг о том, что структура выходит за пределы индекса нужен. Пуская программер обрабатывает его по своему усмотрению. Но он нужен.
Никакой ошибки не вывалится. Индекс по строке означает ускорение трех типов запросов:
select * from ... where str between "Иванов" and "Петров"
select * from ... where str like "Ива%"
select * from ... where str = "Иванов Иван Иваныч потеплей оделся на ночь"
Во всех остальных случаях будет идти честное сканирование таблицы.
Что же произойдет в случае поиска типа 1? "Обрезанные" ключи сохраняют лексикографическую упорядоченность, за исключением "длинной" части. Ну, давай предположим для упрощения, что у нас ключ длиной всего в 6 символов. С точки зрения этого индекса Авалонов идет до Иванова, а Хунта — после Петрова.
Поэтому Range seek прекрасно пройдет по индексу и никаких проблем не встретит. Поиск с like — точно так же.
Если значение, которое мы ищем, длинее ключа индекса, то предикат распадется на два:
___str_key = "Иванов" AND str = "Иванов Иван Иваныч потеплей оделся на ночь"
Это позволяет выполнить нормальный index seek+bookmark lookup+filter. Первая операция имеет хорошие шансы существенно сократить объем filter.
К тому же собственно bookmark lookup нужен только для тех записей, где длина фактически превышает длину ключа, что вполне соответствует нашей модели: быстро работаем там, где возможно, откатываясь на более медленный алгоритм там, где приходится.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Читать надо весь топик, а не цепляться к словам. Речь шла об алгоритме, который был бы быстрее В+, а не вобще. S>> Ну дык был показан этот самый алгоритм.
AVK>Ничего там не было показано. Был показан алгоритм, который, как мне кажется, как минимум не лучше В+, если не хуже.
S>> Кроме того, при достижении большого размера, хэш таблица может плавно переходить в Б+ дерево, получая нужную универсальность.
AVK>Плавно не получится, слишком дорого обходится перестройка.
Смотря на каких объемах. Отключение индекса при масштабных вставках нормальная практика, а эффект от построения индекса с 0 достаточный. S>> На самом деле я не цепляюсь. Честно. Но сам алгоритм Extendible Hashing мне лично очень нравится.
AVK>Мне тоже, когда речь идет об объемах, которые не сложно уместить в памяти, либо когда данные не меняются.
Так скажем меняются, но в определенном диапозоне и память нужна только для ~ 1/1024 (1 узел на страницу) от всего объема данных то это не проблема. Перестроение страниц индекса при переполнении не приводят же в ужас.
Нужно реально щупать бенефиты. Но скорее всего они не будут впечатляющими, а поэтому данный алгоритм мало пригодный, интересен в основном с теоритической точки.
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
S>> В чем премущество хранения данных в кластерном индексе по ПК??? M>Кластерный индекс по PK создается в очень редких случаях.
Использование Такой Хэш таблицы только как быстрого поиска по хэшу первичного ключа. Словарь одним словом.
Там упорядочивание не нужно.
Ключи для подчиненных таблиц это другая песня.
Ладно не туда я влез. Прошу прощения.
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, stalcer, Вы писали: S>>Кстати, когда СУБД делает хеш-джоин, она ведь строит хэш, то есть где-то его хранит. А если он в память не помещается? S>Спулит на диск, естеснно.
Зачем?
Здравствуйте, Serginio1, Вы писали:
S> Смотря на каких объемах.
На больших. А на маленьких В+ практически идентичен хеш-таблице.
S> Отключение индекса при масштабных вставках нормальная практика,
Масштабные вставки нечастая операция. Куда чаще бывают единичные вставки, но следующие с маленьким интервалом. Перестройка хеша при переполнении приведет к резкому увеличению времени отклика.
AVK>>Мне тоже, когда речь идет об объемах, которые не сложно уместить в памяти, либо когда данные не меняются. S> Так скажем меняются, но в определенном диапозоне и память нужна только для ~ 1/1024 (1 узел на страницу) от всего объема данных то это не проблема.
Извини конечно, но спорить с человеком, игнорирующим логику, тяжело. Попробуй объяснить, как связана твоя и моя фраза. Я не смог.
Здравствуйте, GlebZ, Вы писали:
GZ>Очень интересно посмотреть на выгоды от использования кластерного индекса на основе guid.
А кто сказал, что я собираюсь использовать кластерный индекс на основе GUID? Это Serginio собирается его для хэшей использовать, вот я и спросил зачем...
Кстати, по GUID он бы пригодился, в случае если GUID FK, а не PK...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
GZ>>Поэтому считаю что каждый отданный килобайт — это отданный килобайт врагу. В отличие от серверных приложений, мы обязаны ограничивать размер используемой оперативной памяти. M>От оперативной памяти здесь ничего не зависит. Это все упирается в высоту B+ дерева, чем выше дерево, тем больше обращений к диску. Реально, при разнице длинны ключа больше чем в 2 раза, разница в высоте дерева будет более-менее ощутима при количестве записей подгребающих к паре миллионов, да и то, только на групповых операциях.
Давай все таки разберем нагрузку как это делает оптимизатор. Нагрузка на хард, нагрузка на проц, нагрузка на память. Нагрузка на проц меньше чем в случае с B+. Нагрузка на память также меньше. Нагрузка на диск меньше. Так чем он хуже чем B+?
GZ>>При ста маленьких таблиц? Играет. M>Нет, так как при нехватке памяти нет проблем скинуть их на диск. Реально же для десктопа, будет одна-две больших таблицы и пара десятков маленьких, максимум...
Абсолютно согласен. Но опять подумаем, у нас есть две таблицы, одна на миллион, вторая на 1000. Нам нужно будет сделать миллион сравнений. Какая будет разница между хеш-таблицей и B+ учитывая, что хеш-таблица не требует сравнений значений.
И еще, какая разница будет в производительности, если Андрей будет в основном использовать keyset курсоры.
Здравствуйте, AndrewVK, Вы писали:
AVK>И это все равно будет полнотекстовый поиск, со всеми вытекающими.
Да, но у тебя есть бесплатные инструменты полнотекстового поиска на твоей базе?
Здравствуйте, GlebZ, Вы писали:
AVK>>И это все равно будет полнотекстовый поиск, со всеми вытекающими. GZ>Да, но у тебя есть бесплатные инструменты полнотекстового поиска на твоей базе?
Нету. Но эту проблему надо решать отдельно, там совсем другие алгоритмы.
Здравствуйте, GlebZ, Вы писали:
GZ>Давай все таки разберем нагрузку как это делает оптимизатор. Нагрузка на хард, нагрузка на проц, нагрузка на память. Нагрузка на проц меньше чем в случае с B+. Нагрузка на память также меньше. Нагрузка на диск меньше.
Это все вилами по воде писано. Ту разве что тесты что то покажут.
GZ>И еще, какая разница будет в производительности, если Андрей будет в основном использовать keyset курсоры.
Здравствуйте, GlebZ, Вы писали:
GZ> Нагрузка на проц меньше чем в случае с B+. Нагрузка на память также меньше. Нагрузка на диск меньше. Так чем он хуже чем B+?
Нагрузка на проц меньше, нагрузка на память — больше, нагрузка на диск +/- такая же...
Она может быть даже и не хуже, но и не настолько лучше, чтобы заморачиваться с созданием и поддержкой еще одного типа индексов.
GZ> Какая будет разница между хеш-таблицей и B+ учитывая, что хеш-таблица не требует сравнений значений.
А ты всеь миллион в памяти будешь деражать? Вот и вылезет в итоге, что если B+ проигрывает, то не на много...
Здравствуйте, AndrewVK, Вы писали:
AVK>Извини конечно, но спорить с человеком, игнорирующим логику, тяжело. Попробуй объяснить, как связана твоя и моя фраза. Я не смог.
А мы разве спорим??? Просто не ты ни я не видим смысла в этой хэш таблице, но ты её отвергаешь, мне интересна как теоретическая разработка.
А понятия ("об объемах, которые не сложно уместить в памяти, либо когда данные не меняются")
Понятия растяжимые. Опять же перестройке подвергается не вся хэш таблица. Ладно пусть будет у меня плохо с логикой.
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
Что бы замять этот разговор то в зависимости от строение бд можно придумать строение ПК так, чтобы по нему можно было найти физический адрес. Например номер записи, по которой можно найти требуемую страницу итд. Если не требуется репликация то можно его совмещать и ИД БД.
Но это так фантазии, но не безнадёжные. некий RID
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
1.1.4 stable rev. 510
). Но наверняка начнутся привязки системы поиск к несвойственным ему полям. Другого пути то нет. Есть поле comments, в который кладут некоторый коментарий. И захотелось программеру сделать по нему поиск. Обычно комментс в районе 200-300 байт(если не null), но один коммент — 2000 кила. Ошибка вывалится то у пользователя, и что делать? Какой нибудь рычаг о том, что структура выходит за пределы индекса нужен. Пуская программер обрабатывает его по своему усмотрению. Но он нужен.
Но сам алгоритм Extendible Hashing мне лично очень нравится.
Мы уже победили, просто это еще не так заметно...
