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

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

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

Вопрос бывалым на тему скорости запроса
Я
   AlexAl-77
 
08.09.16 - 10:09
Всем привет. у кого есть опыт, что быстрее работает в запросе? если делать отбор по строке или уникальному идентификатору. записей более 10 мил.
 
 
   mkalimulin
 
1 - 08.09.16 - 10:10
(0) Сам как думаешь?
   Cyberhawk
 
2 - 08.09.16 - 10:15
"в запросе ... делать отбор по ... уникальному идентификатору." // Это как?
   piter3
 
3 - 08.09.16 - 10:17
Строка это like?
   mkalimulin
 
4 - 08.09.16 - 10:17
(2) Ну, как обычно.
   PRO100 NigGaZ
 
5 - 08.09.16 - 10:17
Индекс по этому полю
   Armando
 
6 - 08.09.16 - 10:18
В каком запросе?
   denis_jj
 
7 - 08.09.16 - 10:26
(0) однозначно сказать нельзя. В каждом случае нужно тестировать производительность на живых данных.
   xafavute
 
8 - 08.09.16 - 10:31
гуид поле поменьше длиной, поэтому должно быть быстрее.
Но не думаю что разница настолько существенна
   ViSo76
 
9 - 08.09.16 - 10:32
(0) Ссылка это 16 байт. Скорее всего индекс ref по объёму меньше индекса строки, от сюда I/O будет меньше и тем самым поиск по ref будет быстрее.
   ptiz
 
10 - 08.09.16 - 10:32
(0) Важно только "в индексе / не в индексе".
 
 Рекламное место пустует
   xafavute
 
11 - 08.09.16 - 10:33
строка на 16 байт - это всего 8 символов
   ViSo76
 
12 - 08.09.16 - 10:35
(11) Я думаю что в индексе для строк используешься хэш функция и скорее всего индекс так же содержит исходное поле
   Feanor
 
13 - 08.09.16 - 10:36
(10) еще важна селективность индекса
   ViSo76
 
14 - 08.09.16 - 10:37
(13) Для GUID селективность высокая, да и для строк скорее всего так же
   xafavute
 
15 - 08.09.16 - 10:38
(14) Не факт. Например ТЧ документа на 10тыщ строк
   regi1984
 
16 - 08.09.16 - 10:41
Мои мысли: отбор по УИД, это скорее всего кластерный индекс, а в нем много всяких других полей. Индекс по строке  - содержит сму строку + мниимум (в зависимости от данных). Получается во втором случаее на одной странице данных больше вариантов и меньшее количество страниц будет считано во время "индекс сик". В чем моя ошибка?
   ViSo76
 
17 - 08.09.16 - 10:42
(15) Ты думаешь что каждая строка табличной части в индексе занимает по одной записи в индексе? А не блок ссылок на станицы, с указанием позиции в ней?
   ViSo76
 
18 - 08.09.16 - 10:44
(16) А что такое кластер :) И как физически распределяется хранение ссылок в кластерном индексе?
   Feanor
 
19 - 08.09.16 - 10:44
(16) по-твоему, поиск в кластерном индексе - это всегда скан?
   regi1984
 
20 - 08.09.16 - 10:47
(19) Нет, там тоже индекс сик. Но данных ведь больше на странице. Значит и количество страниц раве не будет прочтено больше в итоге?
   xafavute
 
21 - 08.09.16 - 10:47
(17) чем блок ссылок отличается от самих ссылок?
   Feanor
 
22 - 08.09.16 - 10:48
(20) почему данных то больше?
   regi1984
 
23 - 08.09.16 - 10:53
(22) Это я фантазирую: индекс по ID включает большее кол-во столбцов. Да, мои мысли ошибочны. Спасибо.
   ViSo76
 
24 - 08.09.16 - 10:54
В физическом хранении. Есть в ссылка, которая идёт в индексе уже отсортированная. В блоках. Нахождение такой ссылки делается так: считывается первый, последний и средний блок. Идёт проверка в каком из диапазонов лежит ссылка, таким образом после первой проверки идёт уполавинивание данных для поиска. Так деля на диапазоны выискивается блок где содержится ссылка, далее в найденных данных есть указание что все 10000 ссылок указаны в таком то блоке, и идёт считывание цепи страниц с ссылками. Это моё предположение, ведь нафейхуа увеличивать индекс дубликатами?
   denis_jj
 
25 - 08.09.16 - 10:56
(16) отбор по УИД это кластерный индекс если этот УИД является, например, ссылкой справочника. А если УИД это какой-то реквизит регистра сведений, то это однозначно не кластерный.
Производительность индекса по строке зависит от самой строки: длины и содержания.
На мой взгляд вопрос неоднозначный. Требуется проверка и оптимизация непосредственно на реальных данных.
   Feanor
 
26 - 08.09.16 - 10:59
(23) индекс же дерево, не будет там большого кол-ва столбцов
   xafavute
 
27 - 08.09.16 - 11:01
(24) так сами данные то лежат на разных страницах.
И может случиться так, что все 10к записей данных лежат каждая в своей стрнице.
Где тут блок указать?
   xafavute
 
28 - 08.09.16 - 11:02
(25) уид - это не всегда ссылка.
например ключстроки в ЕРП в документах
   ViSo76
 
29 - 08.09.16 - 11:07
(27) Ну смотри
Индекс:
[Ссылка нижележащая]   -> [Это отдельные физические страницы на случай вставки]
[Ссылка наша]           -> [Странница(ы) с указателями на физическое хранение данных]
[Ссылка вышележащая]
   vi0
 
30 - 08.09.16 - 11:12
а что за строка?
какая длина, что хранить хочешь там
   AlexAl-77
 
31 - 08.09.16 - 11:31
меня интересует, что будет работать быстрее тип ГУИД или строка. У меня есть уникальный идентификатор, я думаю если я его сделаю строкой, не будет ли быстрее работать запрос на выборку с отбором по этому полю.
   Feanor
 
32 - 08.09.16 - 11:43
(31) что мешает проверить?
   denis_jj
 
33 - 08.09.16 - 11:50
(31) Насколько я понимаю тип сравнения будет Равно (не подобно). В таких условиях думаю что какой либо существенной разницы в производительности не будет.
Правда где-то видел в рекомендациях 1С что предпочтительнее не использовать простые типы данных в отборах в запросах. Но могу ошибаться.
 
 
   mistеr
 
34 - 08.09.16 - 11:57
(24) Ты гонишь.

(31) Пофиг.
   AlexAl-77
 
35 - 08.09.16 - 12:00
Проверить можно, но это долго так как база большая пока тип поменяется 5 часов проходит. весит много развернуть тоже целая история. поэтому спросил у вас, может кто сталкивался. Спасибо в любом случае.
   AlexAl-77
 
36 - 08.09.16 - 12:00
(32)Проверить можно, но это долго так как база большая пока тип поменяется 5 часов проходит. весит много развернуть тоже целая история. поэтому спросил у вас, может кто сталкивался. Спасибо в любом случае.
   SSSSS_AAAAA
 
37 - 08.09.16 - 12:02
(31) Вопрос из серии "Кто сильнее - кит или слон". То есть, мягко говоря, не совсем корректный и умный. В деле поиска данных в базах данных нет абслоюта, который ищется заданным вопросом.
   denis_jj
 
38 - 08.09.16 - 12:07
(31) Предполагаю, что по ГУИД будет немного быстрее, т.к. для этого типа данных в индексе будет использована наиболее подходящая хэш функция, тогда как для строки эта функция будет основана на общем анализе содержимого строк и, вероятно, будет хуже.
   ViSo76
 
39 - 08.09.16 - 12:09
(34) Блясни познаниями, опиши процесс
   mistеr
 
40 - 08.09.16 - 12:18
(39) Если и правда интересно, https://en.wikipedia.org/wiki/B%2B_tree#Search
   SSSSS_AAAAA
 
41 - 08.09.16 - 12:24
(38) Интересно, откуда вообще бред про хеш-функции в индексах?
   mistеr
 
42 - 08.09.16 - 12:26
(41) В некоторых индексах используются. Но не в скуле.
   denis_jj
 
43 - 08.09.16 - 12:28
(41) а как по вашему индексы строятся?
   ViSo76
 
44 - 08.09.16 - 12:29
(40) Ты про BTree говоришь? Про поиск в составном ключе?

http://www.sql.ru/articles/mssql/03013101indexes.shtml#3
   mkalimulin
 
45 - 08.09.16 - 12:31
(36) А ты проверь на маленькой.
   SSSSS_AAAAA
 
46 - 08.09.16 - 12:32
(43) Молча. Как минимум в MS SQL без каких-либо функций. Потому здесь размышлизмы о повышении скорости поиска за счет использования каких-то функций и есть бред.
   mistеr
 
47 - 08.09.16 - 12:33
(44) WTF is "поиск в составном ключе"?

(43) См. по ссылкам (40), (44).
   ViSo76
 
48 - 08.09.16 - 12:35
(47) Не тыкай, а на пальцах распиши :)
   denis_jj
 
49 - 08.09.16 - 12:37
(46) Ну так просветите, уважаемый. А то критика есть, а по существу ничего не сказали.
 
 Рекламное место пустует
   ViSo76
 
50 - 08.09.16 - 12:39
У меня создаётся впечатление что кроме BTree дерева ничего не существует
   SSSSS_AAAAA
 
51 - 08.09.16 - 12:47
(49) В чем просветить? Вроде однозначно написано - нет в индексах функций. Разумеется, если речь о практически используемых с 1С СУБД, а не про сферическую СУБД в вакууме, в которой, возможно, и применяются функции, в том числе и такие, которые не гарантируют уникальности возвращаемого значения при уникальных входных данных.
   denis_jj
 
52 - 08.09.16 - 12:47
(46) И по поводу размышлизмов:
Индекс для типа ГУИД будет создаваться платформой 1С. По какому принципу - известно разработчикам платформы (может вам известно?). Но осмелюсь предположить, что заранее зная что хранится в этом поле, какие данные, то будет использоваться некоторый алгоритм (или хэш функция) которая позволит построить наиболее эффективный для этого поля индекс.
Что же касается строкового значения, то там может быть всё что угодно и заранее, без анализа данных, подобрать наиболее эффективный способ построения индекса проблематично. Поэтому, вероятно, индекс построенный для строки в которой записаны ГУИДы будет хуже чем индекс построенный для ГУИДов.
   denis_jj
 
53 - 08.09.16 - 12:49
(49) Если вам известно как платформа строит индексы для полей разных типов, расскажите.
   denis_jj
 
54 - 08.09.16 - 12:50
(51)Если вам известно как платформа строит индексы для полей разных типов, расскажите.
   SSSSS_AAAAA
 
55 - 08.09.16 - 12:51
(52) Индекс будет создаваться СУБД по правилам СУБД. Вне зависимости от хотелок 1С. В частности, в MS SQL индексы строятся исключительно по списку полей. И никакая 1С не заставит его делать иное.
   Oftan_Idy
 
56 - 08.09.16 - 12:52
(0) Ты хочешь напрямую к SQL обращаться?
Тогда тип UUID
   denis_jj
 
57 - 08.09.16 - 12:57
(55) Я видел в ИТС описание того, как платформа создает индексы для разных объектов метаданных. Например для справочников это ссылка, для документов ссылка плюс дата и.т.д. Поэтому платформа некоторым образом влияет на создание индексов.
Расскажите по каким правилам SQL создаст индекс для типа UUID и для типа STRING. Может они чем-то будут отличаться?
   SSSSS_AAAAA
 
58 - 08.09.16 - 13:02
(57) "платформа некоторым образом влияет на создание индексов."
Разумеется, влияет. Указанием списка полей индекса. Но не более того.
"по каким правилам SQL создаст индекс для типа UUID и для типа STRING"
По одним и тем же. При создании индекса указывается только список полей.
"Может они чем-то будут отличаться?"
Своим содержимым.
   ViSo76
 
59 - 08.09.16 - 13:03
(57) Платформа не создаёт индексы физически. При создании таблицы в базе данных указывается какие создавать поля, их тип, индексы, ограничения данных. Далее база сама при insert создаёт нужные индексы.
   ViSo76
 
60 - 08.09.16 - 13:05
(59) "создаёт нужные индексы" читать как вставляет в индексные станицы данные
   SSSSS_AAAAA
 
61 - 08.09.16 - 13:05
(57) "для документов ссылка плюс дата"
Create index on <Document?????> (<поле-ссылка>,<поле-дата>)
   ViSo76
 
62 - 08.09.16 - 13:09
Вообще платформа для документа создаёт кластерный первичный индекс по полю Ссылка ещё уникальный индекс "Data + Ссылка" и "Номер + Ссылка"
   denis_jj
 
63 - 08.09.16 - 13:13
(61) Заклинание, которые вы написали "Create index on <Document?????> (<поле-ссылка>,<поле-дата>)" это хорошо.
Но мы тут подошли к сути вопроса:
для типа UUID по какому алгоритму будет строится индекс?
для типа STRING по какому алгоритму будет строится индекс?
Какой из индексов будет эффективнее если в строку записать УИДы?
   ViSo76
 
64 - 08.09.16 - 13:18
(63) Не мне вопрос, но в кластерном ( упорядоченном массиве по полю UUID ) поиск будет быстрее, чем поиск строки.
   denis_jj
 
65 - 08.09.16 - 13:21
(64) Да :-)
Но по условию задачи, если это просто какой-то реквизит, то индекс будет не кластерным. Как в таком случае будет?
   SSSSS_AAAAA
 
66 - 08.09.16 - 13:23
(63) Без алгоритмов. Просто значение поля. Некластерный индекс - вырезка из таблицы указанных полей в указанном порядке.
   denis_jj
 
67 - 08.09.16 - 13:30
(63) Ну как же без алгоритмов? Какие-то алгоритмы есть, например построение дерева по некоторой по части UUIDa (это хэш функция такая) в листьях которого указатели на строки в таблице СУБД.
Я не силен в низкоуровневых алгоритмах СУБД, но точно знаю что какие-то алгоритмы используются.
Вопрос то как эффективнее хранить данные и быстрее их искать. Свои размышлизмы я высказал.
   denis_jj
 
68 - 08.09.16 - 13:30
(66)Ну как же без алгоритмов? Какие-то алгоритмы есть, например построение дерева по некоторой по части UUIDa (это хэш функция такая) в листьях которого указатели на строки в таблице СУБД.
Я не силен в низкоуровневых алгоритмах СУБД, но точно знаю что какие-то алгоритмы используются.
Вопрос то как эффективнее хранить данные и быстрее их искать. Свои размышлизмы я высказал.
   ViSo76
 
69 - 08.09.16 - 13:32
(65) Допустим что строка и UUID это реквизиты, тогда что в одном случае будет ссылка на кластерный индекс что в другом ( чтобы извлечь сами данные ), далее GUID это binary(16) строка может содержать больше количество символов. Точно как создаётся индекс для строк я не знаю, но я бы сделал так: на основе строки с помощью хэш функции сделал бы те же binary(16) с не уникальным индексом, далее при поиске с помощью хэш функции вычисляем ключ, далее поиск по алгоритму деления диапазона, и затем уже продолжение поиска к данных на точное сравнение строки. Если это физически происходит так, то поиск UUID теоретически быстрее
   SSSSS_AAAAA
 
70 - 08.09.16 - 13:37
(68) Еще раз - молча, без каких-либо преобразований значений полей. Дерево строится без преобразований значений полей. Ибо эти значения потом могут (и используются) для выдачи данных без обращения к таблице. При выполнении некоторых условий, конечно же.
И не надо повторять как мантру про хэш-функцию.
   SSSSS_AAAAA
 
71 - 08.09.16 - 13:40
(69) " binary(16) строка может содержать больше количество символов."
Чего только люди не придумают...
binary(16) - это 16 байт и не более того. Всегда 16. Байтов, произвольных.
   ViSo76
 
72 - 08.09.16 - 13:43
(71) Может я плохо написал, но то что там ты вычитал я не писал
   denis_jj
 
73 - 08.09.16 - 13:43
(69) Осторожнее с предположениями, вас могут обвинить в размышлизмах и бреде :-)
Я с вами согласен, но есть нюансы. Для UUID точно известна его длина и структура. На основе анализа возможных комбинаций данных можно построить хэш функцию, которая позволит вычислить ключ и наиболее эффективно построить индекс.
Со строкой всё не так однозначно т.к. длина строки разная и данные в строке тоже сильно разные. Например, во всех строках может повторяться первые 16 символов, тогда некоторые индексы (в которых хэш использует эти 16 символов) могут стать вообще неэффективными и даже замедлить работу.
Поэтому, я предполагаю, что по условию конкретно этой задачи быстрее будет использовать тип УИД.
   ViSo76
 
74 - 08.09.16 - 13:44
(72) далее GUID это binary(16), строка может содержать больше количество символов.

Не хватает запятой или точки на твой выбор
   SSSSS_AAAAA
 
75 - 08.09.16 - 13:48
(73) Серверу плевать на ваши размышлизмы и идею-фикс с хэш-функцией. Для него это 16 байт и более ничего.
   ViSo76
 
76 - 08.09.16 - 13:48
(73) UUID это всего лишь сишная функция, которая позволяет генерить уникальное значение https://ru.wikipedia.org/wiki/UUID
   ViSo76
 
77 - 08.09.16 - 13:48
(75) Я тебе указал что не поставил знак препинания или точку, что тебе ещё нужно?
   SSSSS_AAAAA
 
78 - 08.09.16 - 13:49
(74) а, ну в таком случае претензий не имею. :)
   SSSSS_AAAAA
 
79 - 08.09.16 - 13:50
(77) повнимательнее посмотри кому было написано.
   ViSo76
 
80 - 08.09.16 - 13:51
(79) Да, звени не туда посмотрел
   ViSo76
 
81 - 08.09.16 - 13:51
(80) звени*
   ViSo76
 
82 - 08.09.16 - 13:52
(81) "и" не прожималась...
   SSSSS_AAAAA
 
83 - 08.09.16 - 13:54
В слове "извини" вообще не бывает буквы Е.
   ViSo76
 
84 - 08.09.16 - 13:56
(83) Ты знал, ты знал :) долблю и часто не смотрю на клаву
   ViSo76
 
85 - 08.09.16 - 13:57
И на набранный текст, привычка с полиграфии
   denis_jj
 
86 - 08.09.16 - 13:57
(75) Серверу безусловно наплевать. Но алгоритмы серверу пишут люди.
Есть алгоритмы, которые позволяют среди множества значений каждое из которых 16 байт найти искомое наиболее быстрым способом, не перебирая каждое из них. Но это лирика, мы отвлеклись от сути задачи.
Может вы выскажете ваши размышлизмы по существу задачи? Как эффективнее хранить данные в описанной ситуации?
   ViSo76
 
87 - 08.09.16 - 14:02
UUID в кластере и отбор по UUID, если поиск нужно по строке и это не 1С, а к примеру Oracle, я бы тогда сделал кластерный индекс разбитый ещё и на диапазоны
   ViSo76
 
88 - 08.09.16 - 14:05
(87) В Oracle это называется секционирование по диапазону, как-то так. Не знаю в MS SQL есть такие возможности или нет...
   SSSSS_AAAAA
 
89 - 08.09.16 - 14:06
(86) Вы издеваетесь? Вы читаете что вам пишут? Поиск идет по значениям полей, в индексе значения полей и сервер не знает и знать не должен семантику данных. Для него это наборы байтов. Которые в зависимости от указанного типа можно/нельзя некоторыми способами обрабатывать. И не более того.
   denis_jj
 
90 - 08.09.16 - 14:09
(89) Нисколько не издеваюсь.
Вы написали "Которые в зависимости от указанного типа можно/нельзя некоторыми способами обрабатывать".
Можете поподробнее о зависимости способа обработки от типа данных?
   SSSSS_AAAAA
 
91 - 08.09.16 - 14:13
(90) Для строк можно использовать перекодировку, но их нельзя использовать в арифметических операциях, числа можно использовать в арифметических операциях, но нельзя перекодировать. Как и бинарные данные. Можно делать некоторые приведения типов. Это что-то для вас новое? Необычное? Непонятное?
   denis_jj
 
92 - 08.09.16 - 14:16
(91) Вы немного не так меня поняли. Вопрос о поиске значения. Как наиболее эффективно найти какое-либо значение для типа Строка и для типа УИД? И обоснуйте пожалуйста.
   novichok79
 
93 - 08.09.16 - 14:19
можно вычислить конечное кол-во записей в регистре и взять число какой-то разрядности с запасом как первичный ключ. можно использовать UID. строки как маркер уникальности в регистре я бы вообще не использовал, т. к. однажды такое измерение в регистре сведений повесило базу, которую мне пришлось потом восстанавливать.
   ViSo76
 
94 - 08.09.16 - 14:20
(92) Алгоритмы все в базе данных, тип индекса выбираешь ты при создании, как физически хранить и какой алгоритм использовать это прерогатива РСУБД. Так что твоё дело только USE THIS.
   ViSo76
 
95 - 08.09.16 - 14:23
(93) Пусть использует GUID ( Уникальный идентификатор ) ничего страшного в binary(16) я лично не вижу. У тебя просто бэд сектор скорее всего образовался и тебе не повезло, вот и всё.
   denis_jj
 
96 - 08.09.16 - 14:24
(94) Об том и речь! Нужно выбрать какой тип использовать разработчику Строку или УИД. Вы ваше мнение высказали. Хотелось бы услышать мнение SSSSS_AAAAA, и желательно с обоснованием.
   SSSSS_AAAAA
 
97 - 08.09.16 - 14:25
(92) "Строка и для типа УИД"
Для сервера это просто два набора байт. Один из которых помечен как доступный для перекодировки (строка) и для вычисления длины набора надо учитывать возможную двухбайтовость кодировки, а второй - недоступен(бинари). ВСЁ! Больше между ними для сервера разницы нет. В индексе при поиске сравниваются наборы байт.
   denis_jj
 
98 - 08.09.16 - 14:27
(97) а способы построения индексов от типа не зависят? Не будет ли в данной задаче индекс для УИДа эффективней чем индекс для Строки?
   SSSSS_AAAAA
 
99 - 08.09.16 - 14:28
(96) Все вопросы по поиску лучшего способа для сферического запроса в сферической системе со сферической схемой хранения данных на сферическом сервере - полный идиотизм.
   SSSSS_AAAAA
 
100 - 08.09.16 - 14:29
(98) Сколько раз надо повторить, что нет отдельных способов построения индексов для разных типов данных?
  1  2   

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