Вход | Регистрация

  1  2
1С:Предприятие :: 1С:Предприятие 8 общая

Вопрос бывалым на тему скорости запроса

Вопрос бывалым на тему скорости запроса
Я
   AlexAl-77
 
08.09.16 - 10:09
Всем привет. у кого есть опыт, что быстрее работает в запросе? если делать отбор по строке или уникальному идентификатору. записей более 10 мил.
 
 
   mistеr
 
101 - 08.09.16 - 14:31
(92) Ты троллишь похоже. Ответ на твой вопрос давно дан. С точки зрения поиска по UID - все равно, что он в виде строки, что он в виде UUID. А если ты хочешь детального обоснования - извини, тут придется попыхтеть, почитать книжки, вникнуть в подробности. В двух словах не расскажешь.
   SSSSS_AAAAA
 
102 - 08.09.16 - 14:33
(98) Откуда такая твердая уверенность, что UID - это нечто совершенно уникальное в части типов данных и для него просто обязано быть какое-то особенное построение индекса?
   denis_jj
 
103 - 08.09.16 - 14:38
(102) УИД имеет четкую структуру и длину. Исходя из этого для него можно построить более эффективный индекс чем для других типов.
   ViSo76
 
104 - 08.09.16 - 14:42
(103) Структура тут не причём, а так ату их, ату :)
   Feanor
 
105 - 08.09.16 - 14:43
(103) что может быть эффективнее сбалансированного дерева?
   Feanor
 
106 - 08.09.16 - 14:44
+(105) вам надо свою СУБД написать, со своими УИДАМИ и алгоритмами))
   ViSo76
 
107 - 08.09.16 - 14:45
(105) Вот у тебя не уникальный индекс по строке - Name as string(100). Вот как тут использовать сбалансированное дерево?
   ViSo76
 
108 - 08.09.16 - 14:46
(107) Да ещё 10 лямов записей
   denis_jj
 
109 - 08.09.16 - 14:48
(104) Ну как же структура не причём? Возьмите например тип Дата, для него построение индекса ой как от структуры зависит. Причем разные индексы в зависимости от потребностей поиска.
   ViSo76
 
110 - 08.09.16 - 14:49
(109) Дата это набор байтов и ничем не отличается от GUID, разве что размером
 
 Рекламное место пустует
   denis_jj
 
111 - 08.09.16 - 14:53
(110) Это так. И индекс для него это тоже набор байт. Но строится он по некоторым правилам и искать по нему быстрее чем по исходной таблице.
   SSSSS_AAAAA
 
112 - 08.09.16 - 14:55
(103) Еще раз - для сервера это просто 16 байт без какой-либо структуры. Отсюда ваши рассуждения о возможности построения для него какого-то особенного индекса становятся измышлизамами.
   SSSSS_AAAAA
 
113 - 08.09.16 - 14:56
(111) НЕТ для него особых правил.
   SSSSS_AAAAA
 
114 - 08.09.16 - 14:57
(109) "тип Дата, для него построение индекса ой как от структуры зависит."
Где вы набрались такой чуши? С каких пор для двух байт понадобились структуры и особые индексы?
   ViSo76
 
115 - 08.09.16 - 15:04
(114) Для булева индекса в Oracle к примеру есть Битовые индексы (bitmap indexes) http://oracle-dba.ru/docs/architecture/indexes
   Feanor
 
116 - 08.09.16 - 15:04
(107) как говорили товарищи выше: молча :)
с чем именно проблемы то? с уникальностью или сбалансированностью?
   denis_jj
 
117 - 08.09.16 - 15:05
(114) Тип дата в разных системах храниться по разному. Поэтому ваше утверждение о двух байтах неверно.
А индексы нужны для быстрого поиска значений в базе данных. Поэтому для типа Дата может быть несколько вариантов индекса.
Но конечно, все они будут наборами байтов и серверу всё равно :-)
   ViSo76
 
118 - 08.09.16 - 15:08
(116) Да пусть опишет как физически строится B-Tree индекс для строки?
   SSSSS_AAAAA
 
119 - 08.09.16 - 15:08
(117) "Тип дата в разных системах храниться по разному."
Не просветите нас по этому вопросу? Назовите хоть пару систем с хранением даты в других форматах? И какие такие для них разные индексы можно построить?
"Но конечно, все они будут наборами байтов и серверу всё равно"
Именно.
   denis_jj
 
120 - 08.09.16 - 15:10
(119) Вот для примера https://habrahabr.ru/post/69983/
   denis_jj
 
121 - 08.09.16 - 15:10
(119) Как вы можете увидеть
•DATE — тип данных для хранения даты. Диапазон значений: 1000-01-01 — 9999-12-31. Занимает 3 байта.
   denis_jj
 
122 - 08.09.16 - 15:14
(119) А вы на какую систему ориентируетесь?
   ViSo76
 
123 - 08.09.16 - 15:14
(121) Забей в общем у индекса просто поле ключа будет иметь разную длину и в странице просто будет меньше ключей. Для строки я думаю всё же используется кэш и будет всё тот же использоваться тип индекса, с небольшими изменениями, если строка имеет длину в 100 байт, то на сравнениях будет большие потери, хотя не факт.
   SSSSS_AAAAA
 
124 - 08.09.16 - 15:18
(121) Как вы можете увидеть в любом случае сервер оперирует именно наборами байт, представляющими из себя ЧИСЛО каких-то единиц времени до/от какой-то точки на шкале времени. Разница только в длине/разрядности числа.
   ViSo76
 
125 - 08.09.16 - 15:24
(124) Только битами, битами управляет :) байт это уже высокоуровневая тема...
   denis_jj
 
126 - 08.09.16 - 15:55
(119) Вы писали "И какие такие для них разные индексы можно построить?"
Тут ответ в прикладной задаче. Например:
1. Нужно выбрать все записи за 2015 год.
2. Нужно выбрать все записи за первое число всех месяцев всех лет.

Для первого случая подойдет индекс, построенный по части поля Год.
Для второго случая подойдет индекс, построенный по части поля Число.

Если использовать во второй задаче индекс от первой задачи, то эффективность такого поиска будет хуже чем просто сканирование таблицы.
Почувствуйте разницу.
   SSSSS_AAAAA
 
127 - 08.09.16 - 16:02
(126) Для сервера в дате нет частей. Никаких.
Для конкретной прикладной задачи будут хранить не дату, а части даты в виде строк или чисел и по ним и будут делать индексы.
Почувствуйте разницу.
   ViSo76
 
128 - 08.09.16 - 16:04
(126) Это дано на откуп тебе. В любом случае нужно из даты выносить либо год либо число и индексировать ( и индекс будет в данном случае по структуре одинаковым ). Для баз данных есть DBA и если построенные индексы разработчиков не удовлетворяют потребностям, у него всегда есть возможность повлиять на физическую сущность.
   denis_jj
 
129 - 08.09.16 - 16:07
(127) (128) Ну это просто пример, который удобно рассматривать. Я хочу сказать, что для разных типов данных индекс будет строится по некоторым правилам, хотя бы по структуре хранения данных.
   ViSo76
 
130 - 08.09.16 - 16:13
(127) Он весь твой :)
   SSSSS_AAAAA
 
131 - 08.09.16 - 16:13
(129) Пошли отмазы про неудачно выбранный пример...
"для разных типов данных индекс будет строится"
Еще раз - где такой чуши набрались? Откуда уверенность, что именно так и будет? Структура у индексов одна и она не зависит от типа данных. Ибо она рассчитана изначально на хранение значений большинства известных серверу типов данных без учета смысла этих значений для конечного пользователя.
   denis_jj
 
132 - 08.09.16 - 16:16
(131) Никаких отмазов. В условии автор спрашивает какой тип данных выбрать. А от этого зависит как будут данные храниться в базе и как построятся индексы. А от того как они построятся будет зависеть в конечном счете скорость поиска.
   ViSo76
 
133 - 08.09.16 - 16:17
(132) Автор уже давно забил и запил, в крайнем случае перелогинься :)
 
 
   ViSo76
 
134 - 08.09.16 - 16:24
(132) Он спросил всего лишь что быстрее работает поиска по ссылке или поиск по строке на 10 лямах, ну ясен пень что ссылка ( тем более кластер ) будет работать гораздо быстрее.
   SSSSS_AAAAA
 
135 - 08.09.16 - 16:29
(132) "В условии автор спрашивает какой тип данных выбрать."
Уже написано, что для сферического и т.д. по тесту вопрос идиотский. Он перестанет быть таковым только после указания всех влияющих на выбор факторов.
"А от этого зависит как будут данные храниться в базе"
Это называется проектирование структуры и к индексам в этом деле относится только не/возможность проиндексировать какое-либо важное  для поиска поле.
" и как построятся индексы."
Не построятся. Если не дать соответствующую команду. И их структура будет зависеть от списка полей, а не от их типа.
"А от того как они построятся будет зависеть в конечном счете скорость поиска."
Построятся они одинаково - вырезкой указанных полей из таблицы. Без преобразований и без учета их типа.

Вы быть хоть что-то для чайников по базам почитали бы... Разработчиков СУБД за идиотов считаете? Не пробовали выяснить насколько ваши представления о БД, в общем, и о индексах, в частности, расходятся с теорией и практикой работы с базами данных?
   denis_jj
 
136 - 08.09.16 - 16:52
(135) Некоторое представление о работе СУБД у меня есть и мне этого достаточно. То, что поиск по полям разных типов в прикладной системе происходит по разному я знаю точно ибо проверял не раз. И меня интересует в первую очередь результат в прикладной системе, а не то как там байты хранятся. Поэтому для меня решение данной задачи очевидно.
А с вами я не согласен. От типа данных зависит как данные хранятся в базе а значит зависят и индексы и производительность.
   SSSSS_AAAAA
 
137 - 08.09.16 - 17:19
(136) "Некоторое представление о работе СУБД у меня есть и мне этого достаточно."
Ну, для вас и вашей работы может и достаточно, а вот для споров по узким и/или глубоким темам...
"Некоторое представление о работе СУБД у меня есть и мне этого достаточно. "
Потрясающе! Дилетант поставил свои дилетантские тесты и они теперь мерило всех баз данных... Сильный аргумент.
"И меня интересует в первую очередь результат в прикладной системе, а не то как там байты хранятся. "
Тем не менее именно про хранение вы нам тут много долго что-то пытались втирать...
" Поэтому для меня решение данной задачи очевидно. "
Какой задачи? Где и какую задачу то увидели? 
"А с вами я не согласен."
Всё, от такого удара я сейчас сдохну... Несогласие со мной ТАКОГО спеца - невыносимо...
"От типа данных зависит как данные хранятся в базе а значит зависят и индексы и производительность."
Чуть вышек вы писали, что 
"меня интересует в первую очередь результат в прикладной системе, а не то как там байты хранятся."
Вы уж определитесь...

Короче, аргументов и так было кот наплакал и потому пошли бездоказательные рассказы о собственно доблести.
   SSSSS_AAAAA
 
138 - 08.09.16 - 17:22
(137) Вторая цитатка должна быть такой:
"поиск по полям разных типов в прикладной системе происходит по разному я знаю точно ибо проверял не раз."
И ей соответствует ответ про тесты.
   denis_jj
 
139 - 08.09.16 - 17:59
(137)(138) Если вы тут не видите задачи, то откуда тут может быть спор по узким и/или глубоким темам?
А тем более интересно на каких основаниях вы сделали вывод о "дилетанте и дилетантских тестах"?
Я высказал свое мнение, основанное на моём опыте и защищаю свою позицию, делаю это корректно и не перехожу на личности. А вы ведете себя некорректно.
   ViSo76
 
140 - 08.09.16 - 18:05
(138) В данном случае я думаю что тебе будет проще признать что ты не прав :) исходя из постов типа (139)
   Feanor
 
141 - 08.09.16 - 18:08
(140) тема с хэш-функцией строки в индексе выглядит не очень убедительно :)
   denis_jj
 
142 - 08.09.16 - 18:11
(140) Я так не считаю.
   Feanor
 
143 - 08.09.16 - 18:13
(142) каким образом тогда будет работать покрывающий индекс? ведь фактически в этом случае нужен будет кей или рид лукап
   denis_jj
 
144 - 08.09.16 - 18:19
(143) какое отношение ваш вопрос имеет к теме, которую мы обсуждаем?
   ViSo76
 
145 - 08.09.16 - 18:20
(143) Если про like, то можно сделать первые 5,10 символов в качестве ключа и после подгрузи данных, сравнение уже с полной строкой... это уменьшит объём чтения, да и индекса. К примеру на строку в 250 символов.
   vi0
 
146 - 08.09.16 - 19:44
(0) логически рассуждая, уид будет 16 байт, его строкоеое представление  72 байта
т.е. таблица будет больше размером, выборка будет больше
теоритически, строка будет менее производиельна
   Feanor
 
147 - 08.09.16 - 20:35
(145) речь не про лайк, а про то, как вытащить данные из индекса, который построен как хэш-функция от строкового поля, без обращения к самим данным. По-моему, это невозможно. А обращение к данным сведет на нет все преимущества хэширования.
   ViSo76
 
148 - 08.09.16 - 20:47
(147) Вообще-то проблема не в выстаскивании 1 блока из тысячи, а в нахождении оного. Я не утверждаю что это так. Но хэш реально может ускорить и скорость не будет шибко зависить от длины строки.
   Feanor
 
149 - 08.09.16 - 20:57
(148) положим, тебе нужно выбрать фамилии всех сотрудников, есть индекс по фамилии. Если хэша нет, то все просто, достаточно сделать индекс скан и задача решена. А если в индексе лишь непонятный хэш? Скока тогда нужно будет сделать лишних действий и прочитать лишних страниц?
 
 Рекламное место пустует
   Torquader
 
150 - 08.09.16 - 21:03
У SQL-сервера индекс по GUID-у должен быть более оптимизирован, так при поиске строк будет выполняться анализ кодовой страницы.
В остальных случаях - чтение сектора с диска намного медленнее поиска по памяти - следовательно - при сравнимой длине (72 символа и 16 символов) скорость поиска будет примерно одинаковой.
   ViSo76
 
151 - 08.09.16 - 21:44
(149) Хэш к примеру на первые 5 байт. Далее поиск в данных
   AlexAl-77
 
152 - 08.09.16 - 22:15
Замеры показали что почти одинаково разница от пол секунды до секунды в пользу гуида.Всем спасибо за мысли.
  1  2

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует