|
Вопрос бывалым на тему скорости запроса | ☑ | ||
---|---|---|---|---|
0
AlexAl-77
08.09.16
✎
10:09
|
Всем привет. у кого есть опыт, что быстрее работает в запросе? если делать отбор по строке или уникальному идентификатору. записей более 10 мил.
|
|||
1
mkalimulin
08.09.16
✎
10:10
|
(0) Сам как думаешь?
|
|||
2
Cyberhawk
08.09.16
✎
10:15
|
"в запросе ... делать отбор по ... уникальному идентификатору." // Это как?
|
|||
3
piter3
08.09.16
✎
10:17
|
Строка это like?
|
|||
4
mkalimulin
08.09.16
✎
10:17
|
(2) Ну, как обычно.
|
|||
5
PRO100 NigGaZ
08.09.16
✎
10:17
|
Индекс по этому полю
|
|||
6
Armando
08.09.16
✎
10:18
|
В каком запросе?
|
|||
7
denis_jj
08.09.16
✎
10:26
|
(0) однозначно сказать нельзя. В каждом случае нужно тестировать производительность на живых данных.
|
|||
8
xafavute
08.09.16
✎
10:31
|
гуид поле поменьше длиной, поэтому должно быть быстрее.
Но не думаю что разница настолько существенна |
|||
9
ViSo76
08.09.16
✎
10:32
|
(0) Ссылка это 16 байт. Скорее всего индекс ref по объёму меньше индекса строки, от сюда I/O будет меньше и тем самым поиск по ref будет быстрее.
|
|||
10
ptiz
08.09.16
✎
10:32
|
(0) Важно только "в индексе / не в индексе".
|
|||
11
xafavute
08.09.16
✎
10:33
|
строка на 16 байт - это всего 8 символов
|
|||
12
ViSo76
08.09.16
✎
10:35
|
(11) Я думаю что в индексе для строк используешься хэш функция и скорее всего индекс так же содержит исходное поле
|
|||
13
Feanor
08.09.16
✎
10:36
|
(10) еще важна селективность индекса
|
|||
14
ViSo76
08.09.16
✎
10:37
|
(13) Для GUID селективность высокая, да и для строк скорее всего так же
|
|||
15
xafavute
08.09.16
✎
10:38
|
(14) Не факт. Например ТЧ документа на 10тыщ строк
|
|||
16
regi1984
08.09.16
✎
10:41
|
Мои мысли: отбор по УИД, это скорее всего кластерный индекс, а в нем много всяких других полей. Индекс по строке - содержит сму строку + мниимум (в зависимости от данных). Получается во втором случаее на одной странице данных больше вариантов и меньшее количество страниц будет считано во время "индекс сик". В чем моя ошибка?
|
|||
17
ViSo76
08.09.16
✎
10:42
|
(15) Ты думаешь что каждая строка табличной части в индексе занимает по одной записи в индексе? А не блок ссылок на станицы, с указанием позиции в ней?
|
|||
18
ViSo76
08.09.16
✎
10:44
|
(16) А что такое кластер :) И как физически распределяется хранение ссылок в кластерном индексе?
|
|||
19
Feanor
08.09.16
✎
10:44
|
(16) по-твоему, поиск в кластерном индексе - это всегда скан?
|
|||
20
regi1984
08.09.16
✎
10:47
|
(19) Нет, там тоже индекс сик. Но данных ведь больше на странице. Значит и количество страниц раве не будет прочтено больше в итоге?
|
|||
21
xafavute
08.09.16
✎
10:47
|
(17) чем блок ссылок отличается от самих ссылок?
|
|||
22
Feanor
08.09.16
✎
10:48
|
(20) почему данных то больше?
|
|||
23
regi1984
08.09.16
✎
10:53
|
(22) Это я фантазирую: индекс по ID включает большее кол-во столбцов. Да, мои мысли ошибочны. Спасибо.
|
|||
24
ViSo76
08.09.16
✎
10:54
|
В физическом хранении. Есть в ссылка, которая идёт в индексе уже отсортированная. В блоках. Нахождение такой ссылки делается так: считывается первый, последний и средний блок. Идёт проверка в каком из диапазонов лежит ссылка, таким образом после первой проверки идёт уполавинивание данных для поиска. Так деля на диапазоны выискивается блок где содержится ссылка, далее в найденных данных есть указание что все 10000 ссылок указаны в таком то блоке, и идёт считывание цепи страниц с ссылками. Это моё предположение, ведь нафейхуа увеличивать индекс дубликатами?
|
|||
25
denis_jj
08.09.16
✎
10:56
|
(16) отбор по УИД это кластерный индекс если этот УИД является, например, ссылкой справочника. А если УИД это какой-то реквизит регистра сведений, то это однозначно не кластерный.
Производительность индекса по строке зависит от самой строки: длины и содержания. На мой взгляд вопрос неоднозначный. Требуется проверка и оптимизация непосредственно на реальных данных. |
|||
26
Feanor
08.09.16
✎
10:59
|
(23) индекс же дерево, не будет там большого кол-ва столбцов
|
|||
27
xafavute
08.09.16
✎
11:01
|
(24) так сами данные то лежат на разных страницах.
И может случиться так, что все 10к записей данных лежат каждая в своей стрнице. Где тут блок указать? |
|||
28
xafavute
08.09.16
✎
11:02
|
(25) уид - это не всегда ссылка.
например ключстроки в ЕРП в документах |
|||
29
ViSo76
08.09.16
✎
11:07
|
(27) Ну смотри
Индекс: [Ссылка нижележащая] -> [Это отдельные физические страницы на случай вставки] [Ссылка наша] -> [Странница(ы) с указателями на физическое хранение данных] [Ссылка вышележащая] |
|||
30
vi0
08.09.16
✎
11:12
|
а что за строка?
какая длина, что хранить хочешь там |
|||
31
AlexAl-77
08.09.16
✎
11:31
|
меня интересует, что будет работать быстрее тип ГУИД или строка. У меня есть уникальный идентификатор, я думаю если я его сделаю строкой, не будет ли быстрее работать запрос на выборку с отбором по этому полю.
|
|||
32
Feanor
08.09.16
✎
11:43
|
(31) что мешает проверить?
|
|||
33
denis_jj
08.09.16
✎
11:50
|
(31) Насколько я понимаю тип сравнения будет Равно (не подобно). В таких условиях думаю что какой либо существенной разницы в производительности не будет.
Правда где-то видел в рекомендациях 1С что предпочтительнее не использовать простые типы данных в отборах в запросах. Но могу ошибаться. |
|||
34
mistеr
08.09.16
✎
11:57
|
(24) Ты гонишь.
(31) Пофиг. |
|||
35
AlexAl-77
08.09.16
✎
12:00
|
Проверить можно, но это долго так как база большая пока тип поменяется 5 часов проходит. весит много развернуть тоже целая история. поэтому спросил у вас, может кто сталкивался. Спасибо в любом случае.
|
|||
36
AlexAl-77
08.09.16
✎
12:00
|
(32)Проверить можно, но это долго так как база большая пока тип поменяется 5 часов проходит. весит много развернуть тоже целая история. поэтому спросил у вас, может кто сталкивался. Спасибо в любом случае.
|
|||
37
SSSSS_AAAAA
08.09.16
✎
12:02
|
(31) Вопрос из серии "Кто сильнее - кит или слон". То есть, мягко говоря, не совсем корректный и умный. В деле поиска данных в базах данных нет абслоюта, который ищется заданным вопросом.
|
|||
38
denis_jj
08.09.16
✎
12:07
|
(31) Предполагаю, что по ГУИД будет немного быстрее, т.к. для этого типа данных в индексе будет использована наиболее подходящая хэш функция, тогда как для строки эта функция будет основана на общем анализе содержимого строк и, вероятно, будет хуже.
|
|||
39
ViSo76
08.09.16
✎
12:09
|
(34) Блясни познаниями, опиши процесс
|
|||
40
mistеr
08.09.16
✎
12:18
|
(39) Если и правда интересно, https://en.wikipedia.org/wiki/B%2B_tree#Search
|
|||
41
SSSSS_AAAAA
08.09.16
✎
12:24
|
(38) Интересно, откуда вообще бред про хеш-функции в индексах?
|
|||
42
mistеr
08.09.16
✎
12:26
|
(41) В некоторых индексах используются. Но не в скуле.
|
|||
43
denis_jj
08.09.16
✎
12:28
|
(41) а как по вашему индексы строятся?
|
|||
44
ViSo76
08.09.16
✎
12:29
|
(40) Ты про BTree говоришь? Про поиск в составном ключе?
http://www.sql.ru/articles/mssql/03013101indexes.shtml#3 |
|||
45
mkalimulin
08.09.16
✎
12:31
|
(36) А ты проверь на маленькой.
|
|||
46
SSSSS_AAAAA
08.09.16
✎
12:32
|
(43) Молча. Как минимум в MS SQL без каких-либо функций. Потому здесь размышлизмы о повышении скорости поиска за счет использования каких-то функций и есть бред.
|
|||
47
mistеr
08.09.16
✎
12:33
|
(44) WTF is "поиск в составном ключе"?
(43) См. по ссылкам (40), (44). |
|||
48
ViSo76
08.09.16
✎
12:35
|
(47) Не тыкай, а на пальцах распиши :)
|
|||
49
denis_jj
08.09.16
✎
12:37
|
(46) Ну так просветите, уважаемый. А то критика есть, а по существу ничего не сказали.
|
|||
50
ViSo76
08.09.16
✎
12:39
|
У меня создаётся впечатление что кроме BTree дерева ничего не существует
|
|||
51
SSSSS_AAAAA
08.09.16
✎
12:47
|
(49) В чем просветить? Вроде однозначно написано - нет в индексах функций. Разумеется, если речь о практически используемых с 1С СУБД, а не про сферическую СУБД в вакууме, в которой, возможно, и применяются функции, в том числе и такие, которые не гарантируют уникальности возвращаемого значения при уникальных входных данных.
|
|||
52
denis_jj
08.09.16
✎
12:47
|
(46) И по поводу размышлизмов:
Индекс для типа ГУИД будет создаваться платформой 1С. По какому принципу - известно разработчикам платформы (может вам известно?). Но осмелюсь предположить, что заранее зная что хранится в этом поле, какие данные, то будет использоваться некоторый алгоритм (или хэш функция) которая позволит построить наиболее эффективный для этого поля индекс. Что же касается строкового значения, то там может быть всё что угодно и заранее, без анализа данных, подобрать наиболее эффективный способ построения индекса проблематично. Поэтому, вероятно, индекс построенный для строки в которой записаны ГУИДы будет хуже чем индекс построенный для ГУИДов. |
|||
53
denis_jj
08.09.16
✎
12:49
|
(49) Если вам известно как платформа строит индексы для полей разных типов, расскажите.
|
|||
54
denis_jj
08.09.16
✎
12:50
|
(51)Если вам известно как платформа строит индексы для полей разных типов, расскажите.
|
|||
55
SSSSS_AAAAA
08.09.16
✎
12:51
|
(52) Индекс будет создаваться СУБД по правилам СУБД. Вне зависимости от хотелок 1С. В частности, в MS SQL индексы строятся исключительно по списку полей. И никакая 1С не заставит его делать иное.
|
|||
56
Oftan_Idy
08.09.16
✎
12:52
|
(0) Ты хочешь напрямую к SQL обращаться?
Тогда тип UUID |
|||
57
denis_jj
08.09.16
✎
12:57
|
(55) Я видел в ИТС описание того, как платформа создает индексы для разных объектов метаданных. Например для справочников это ссылка, для документов ссылка плюс дата и.т.д. Поэтому платформа некоторым образом влияет на создание индексов.
Расскажите по каким правилам SQL создаст индекс для типа UUID и для типа STRING. Может они чем-то будут отличаться? |
|||
58
SSSSS_AAAAA
08.09.16
✎
13:02
|
(57) "платформа некоторым образом влияет на создание индексов."
Разумеется, влияет. Указанием списка полей индекса. Но не более того. "по каким правилам SQL создаст индекс для типа UUID и для типа STRING" По одним и тем же. При создании индекса указывается только список полей. "Может они чем-то будут отличаться?" Своим содержимым. |
|||
59
ViSo76
08.09.16
✎
13:03
|
(57) Платформа не создаёт индексы физически. При создании таблицы в базе данных указывается какие создавать поля, их тип, индексы, ограничения данных. Далее база сама при insert создаёт нужные индексы.
|
|||
60
ViSo76
08.09.16
✎
13:05
|
(59) "создаёт нужные индексы" читать как вставляет в индексные станицы данные
|
|||
61
SSSSS_AAAAA
08.09.16
✎
13:05
|
(57) "для документов ссылка плюс дата"
Create index on <Document?????> (<поле-ссылка>,<поле-дата>) |
|||
62
ViSo76
08.09.16
✎
13:09
|
Вообще платформа для документа создаёт кластерный первичный индекс по полю Ссылка ещё уникальный индекс "Data + Ссылка" и "Номер + Ссылка"
|
|||
63
denis_jj
08.09.16
✎
13:13
|
(61) Заклинание, которые вы написали "Create index on <Document?????> (<поле-ссылка>,<поле-дата>)" это хорошо.
Но мы тут подошли к сути вопроса: для типа UUID по какому алгоритму будет строится индекс? для типа STRING по какому алгоритму будет строится индекс? Какой из индексов будет эффективнее если в строку записать УИДы? |
|||
64
ViSo76
08.09.16
✎
13:18
|
(63) Не мне вопрос, но в кластерном ( упорядоченном массиве по полю UUID ) поиск будет быстрее, чем поиск строки.
|
|||
65
denis_jj
08.09.16
✎
13:21
|
(64) Да :-)
Но по условию задачи, если это просто какой-то реквизит, то индекс будет не кластерным. Как в таком случае будет? |
|||
66
SSSSS_AAAAA
08.09.16
✎
13:23
|
(63) Без алгоритмов. Просто значение поля. Некластерный индекс - вырезка из таблицы указанных полей в указанном порядке.
|
|||
67
denis_jj
08.09.16
✎
13:30
|
(63) Ну как же без алгоритмов? Какие-то алгоритмы есть, например построение дерева по некоторой по части UUIDa (это хэш функция такая) в листьях которого указатели на строки в таблице СУБД.
Я не силен в низкоуровневых алгоритмах СУБД, но точно знаю что какие-то алгоритмы используются. Вопрос то как эффективнее хранить данные и быстрее их искать. Свои размышлизмы я высказал. |
|||
68
denis_jj
08.09.16
✎
13:30
|
(66)Ну как же без алгоритмов? Какие-то алгоритмы есть, например построение дерева по некоторой по части UUIDa (это хэш функция такая) в листьях которого указатели на строки в таблице СУБД.
Я не силен в низкоуровневых алгоритмах СУБД, но точно знаю что какие-то алгоритмы используются. Вопрос то как эффективнее хранить данные и быстрее их искать. Свои размышлизмы я высказал. |
|||
69
ViSo76
08.09.16
✎
13:32
|
(65) Допустим что строка и UUID это реквизиты, тогда что в одном случае будет ссылка на кластерный индекс что в другом ( чтобы извлечь сами данные ), далее GUID это binary(16) строка может содержать больше количество символов. Точно как создаётся индекс для строк я не знаю, но я бы сделал так: на основе строки с помощью хэш функции сделал бы те же binary(16) с не уникальным индексом, далее при поиске с помощью хэш функции вычисляем ключ, далее поиск по алгоритму деления диапазона, и затем уже продолжение поиска к данных на точное сравнение строки. Если это физически происходит так, то поиск UUID теоретически быстрее
|
|||
70
SSSSS_AAAAA
08.09.16
✎
13:37
|
(68) Еще раз - молча, без каких-либо преобразований значений полей. Дерево строится без преобразований значений полей. Ибо эти значения потом могут (и используются) для выдачи данных без обращения к таблице. При выполнении некоторых условий, конечно же.
И не надо повторять как мантру про хэш-функцию. |
|||
71
SSSSS_AAAAA
08.09.16
✎
13:40
|
(69) " binary(16) строка может содержать больше количество символов."
Чего только люди не придумают... binary(16) - это 16 байт и не более того. Всегда 16. Байтов, произвольных. |
|||
72
ViSo76
08.09.16
✎
13:43
|
(71) Может я плохо написал, но то что там ты вычитал я не писал
|
|||
73
denis_jj
08.09.16
✎
13:43
|
(69) Осторожнее с предположениями, вас могут обвинить в размышлизмах и бреде :-)
Я с вами согласен, но есть нюансы. Для UUID точно известна его длина и структура. На основе анализа возможных комбинаций данных можно построить хэш функцию, которая позволит вычислить ключ и наиболее эффективно построить индекс. Со строкой всё не так однозначно т.к. длина строки разная и данные в строке тоже сильно разные. Например, во всех строках может повторяться первые 16 символов, тогда некоторые индексы (в которых хэш использует эти 16 символов) могут стать вообще неэффективными и даже замедлить работу. Поэтому, я предполагаю, что по условию конкретно этой задачи быстрее будет использовать тип УИД. |
|||
74
ViSo76
08.09.16
✎
13:44
|
(72) далее GUID это binary(16), строка может содержать больше количество символов.
Не хватает запятой или точки на твой выбор |
|||
75
SSSSS_AAAAA
08.09.16
✎
13:48
|
(73) Серверу плевать на ваши размышлизмы и идею-фикс с хэш-функцией. Для него это 16 байт и более ничего.
|
|||
76
ViSo76
08.09.16
✎
13:48
|
(73) UUID это всего лишь сишная функция, которая позволяет генерить уникальное значение https://ru.wikipedia.org/wiki/UUID
|
|||
77
ViSo76
08.09.16
✎
13:48
|
(75) Я тебе указал что не поставил знак препинания или точку, что тебе ещё нужно?
|
|||
78
SSSSS_AAAAA
08.09.16
✎
13:49
|
(74) а, ну в таком случае претензий не имею. :)
|
|||
79
SSSSS_AAAAA
08.09.16
✎
13:50
|
(77) повнимательнее посмотри кому было написано.
|
|||
80
ViSo76
08.09.16
✎
13:51
|
(79) Да, звени не туда посмотрел
|
|||
81
ViSo76
08.09.16
✎
13:51
|
(80) звени*
|
|||
82
ViSo76
08.09.16
✎
13:52
|
(81) "и" не прожималась...
|
|||
83
SSSSS_AAAAA
08.09.16
✎
13:54
|
В слове "извини" вообще не бывает буквы Е.
|
|||
84
ViSo76
08.09.16
✎
13:56
|
(83) Ты знал, ты знал :) долблю и часто не смотрю на клаву
|
|||
85
ViSo76
08.09.16
✎
13:57
|
И на набранный текст, привычка с полиграфии
|
|||
86
denis_jj
08.09.16
✎
13:57
|
(75) Серверу безусловно наплевать. Но алгоритмы серверу пишут люди.
Есть алгоритмы, которые позволяют среди множества значений каждое из которых 16 байт найти искомое наиболее быстрым способом, не перебирая каждое из них. Но это лирика, мы отвлеклись от сути задачи. Может вы выскажете ваши размышлизмы по существу задачи? Как эффективнее хранить данные в описанной ситуации? |
|||
87
ViSo76
08.09.16
✎
14:02
|
UUID в кластере и отбор по UUID, если поиск нужно по строке и это не 1С, а к примеру Oracle, я бы тогда сделал кластерный индекс разбитый ещё и на диапазоны
|
|||
88
ViSo76
08.09.16
✎
14:05
|
(87) В Oracle это называется секционирование по диапазону, как-то так. Не знаю в MS SQL есть такие возможности или нет...
|
|||
89
SSSSS_AAAAA
08.09.16
✎
14:06
|
(86) Вы издеваетесь? Вы читаете что вам пишут? Поиск идет по значениям полей, в индексе значения полей и сервер не знает и знать не должен семантику данных. Для него это наборы байтов. Которые в зависимости от указанного типа можно/нельзя некоторыми способами обрабатывать. И не более того.
|
|||
90
denis_jj
08.09.16
✎
14:09
|
(89) Нисколько не издеваюсь.
Вы написали "Которые в зависимости от указанного типа можно/нельзя некоторыми способами обрабатывать". Можете поподробнее о зависимости способа обработки от типа данных? |
|||
91
SSSSS_AAAAA
08.09.16
✎
14:13
|
(90) Для строк можно использовать перекодировку, но их нельзя использовать в арифметических операциях, числа можно использовать в арифметических операциях, но нельзя перекодировать. Как и бинарные данные. Можно делать некоторые приведения типов. Это что-то для вас новое? Необычное? Непонятное?
|
|||
92
denis_jj
08.09.16
✎
14:16
|
(91) Вы немного не так меня поняли. Вопрос о поиске значения. Как наиболее эффективно найти какое-либо значение для типа Строка и для типа УИД? И обоснуйте пожалуйста.
|
|||
93
novichok79
08.09.16
✎
14:19
|
можно вычислить конечное кол-во записей в регистре и взять число какой-то разрядности с запасом как первичный ключ. можно использовать UID. строки как маркер уникальности в регистре я бы вообще не использовал, т. к. однажды такое измерение в регистре сведений повесило базу, которую мне пришлось потом восстанавливать.
|
|||
94
ViSo76
08.09.16
✎
14:20
|
(92) Алгоритмы все в базе данных, тип индекса выбираешь ты при создании, как физически хранить и какой алгоритм использовать это прерогатива РСУБД. Так что твоё дело только USE THIS.
|
|||
95
ViSo76
08.09.16
✎
14:23
|
(93) Пусть использует GUID ( Уникальный идентификатор ) ничего страшного в binary(16) я лично не вижу. У тебя просто бэд сектор скорее всего образовался и тебе не повезло, вот и всё.
|
|||
96
denis_jj
08.09.16
✎
14:24
|
(94) Об том и речь! Нужно выбрать какой тип использовать разработчику Строку или УИД. Вы ваше мнение высказали. Хотелось бы услышать мнение SSSSS_AAAAA, и желательно с обоснованием.
|
|||
97
SSSSS_AAAAA
08.09.16
✎
14:25
|
(92) "Строка и для типа УИД"
Для сервера это просто два набора байт. Один из которых помечен как доступный для перекодировки (строка) и для вычисления длины набора надо учитывать возможную двухбайтовость кодировки, а второй - недоступен(бинари). ВСЁ! Больше между ними для сервера разницы нет. В индексе при поиске сравниваются наборы байт. |
|||
98
denis_jj
08.09.16
✎
14:27
|
(97) а способы построения индексов от типа не зависят? Не будет ли в данной задаче индекс для УИДа эффективней чем индекс для Строки?
|
|||
99
SSSSS_AAAAA
08.09.16
✎
14:28
|
(96) Все вопросы по поиску лучшего способа для сферического запроса в сферической системе со сферической схемой хранения данных на сферическом сервере - полный идиотизм.
|
|||
100
SSSSS_AAAAA
08.09.16
✎
14:29
|
(98) Сколько раз надо повторить, что нет отдельных способов построения индексов для разных типов данных?
|
|||
101
mistеr
08.09.16
✎
14:31
|
(92) Ты троллишь похоже. Ответ на твой вопрос давно дан. С точки зрения поиска по UID - все равно, что он в виде строки, что он в виде UUID. А если ты хочешь детального обоснования - извини, тут придется попыхтеть, почитать книжки, вникнуть в подробности. В двух словах не расскажешь.
|
|||
102
SSSSS_AAAAA
08.09.16
✎
14:33
|
(98) Откуда такая твердая уверенность, что UID - это нечто совершенно уникальное в части типов данных и для него просто обязано быть какое-то особенное построение индекса?
|
|||
103
denis_jj
08.09.16
✎
14:38
|
(102) УИД имеет четкую структуру и длину. Исходя из этого для него можно построить более эффективный индекс чем для других типов.
|
|||
104
ViSo76
08.09.16
✎
14:42
|
(103) Структура тут не причём, а так ату их, ату :)
|
|||
105
Feanor
08.09.16
✎
14:43
|
(103) что может быть эффективнее сбалансированного дерева?
|
|||
106
Feanor
08.09.16
✎
14:44
|
+(105) вам надо свою СУБД написать, со своими УИДАМИ и алгоритмами))
|
|||
107
ViSo76
08.09.16
✎
14:45
|
(105) Вот у тебя не уникальный индекс по строке - Name as string(100). Вот как тут использовать сбалансированное дерево?
|
|||
108
ViSo76
08.09.16
✎
14:46
|
(107) Да ещё 10 лямов записей
|
|||
109
denis_jj
08.09.16
✎
14:48
|
(104) Ну как же структура не причём? Возьмите например тип Дата, для него построение индекса ой как от структуры зависит. Причем разные индексы в зависимости от потребностей поиска.
|
|||
110
ViSo76
08.09.16
✎
14:49
|
(109) Дата это набор байтов и ничем не отличается от GUID, разве что размером
|
|||
111
denis_jj
08.09.16
✎
14:53
|
(110) Это так. И индекс для него это тоже набор байт. Но строится он по некоторым правилам и искать по нему быстрее чем по исходной таблице.
|
|||
112
SSSSS_AAAAA
08.09.16
✎
14:55
|
(103) Еще раз - для сервера это просто 16 байт без какой-либо структуры. Отсюда ваши рассуждения о возможности построения для него какого-то особенного индекса становятся измышлизамами.
|
|||
113
SSSSS_AAAAA
08.09.16
✎
14:56
|
(111) НЕТ для него особых правил.
|
|||
114
SSSSS_AAAAA
08.09.16
✎
14:57
|
(109) "тип Дата, для него построение индекса ой как от структуры зависит."
Где вы набрались такой чуши? С каких пор для двух байт понадобились структуры и особые индексы? |
|||
115
ViSo76
08.09.16
✎
15:04
|
(114) Для булева индекса в Oracle к примеру есть Битовые индексы (bitmap indexes) http://oracle-dba.ru/docs/architecture/indexes
|
|||
116
Feanor
08.09.16
✎
15:04
|
(107) как говорили товарищи выше: молча :)
с чем именно проблемы то? с уникальностью или сбалансированностью? |
|||
117
denis_jj
08.09.16
✎
15:05
|
(114) Тип дата в разных системах храниться по разному. Поэтому ваше утверждение о двух байтах неверно.
А индексы нужны для быстрого поиска значений в базе данных. Поэтому для типа Дата может быть несколько вариантов индекса. Но конечно, все они будут наборами байтов и серверу всё равно :-) |
|||
118
ViSo76
08.09.16
✎
15:08
|
(116) Да пусть опишет как физически строится B-Tree индекс для строки?
|
|||
119
SSSSS_AAAAA
08.09.16
✎
15:08
|
(117) "Тип дата в разных системах храниться по разному."
Не просветите нас по этому вопросу? Назовите хоть пару систем с хранением даты в других форматах? И какие такие для них разные индексы можно построить? "Но конечно, все они будут наборами байтов и серверу всё равно" Именно. |
|||
120
denis_jj
08.09.16
✎
15:10
|
(119) Вот для примера https://habrahabr.ru/post/69983/
|
|||
121
denis_jj
08.09.16
✎
15:10
|
(119) Как вы можете увидеть
•DATE — тип данных для хранения даты. Диапазон значений: 1000-01-01 — 9999-12-31. Занимает 3 байта. |
|||
122
denis_jj
08.09.16
✎
15:14
|
(119) А вы на какую систему ориентируетесь?
|
|||
123
ViSo76
08.09.16
✎
15:14
|
(121) Забей в общем у индекса просто поле ключа будет иметь разную длину и в странице просто будет меньше ключей. Для строки я думаю всё же используется кэш и будет всё тот же использоваться тип индекса, с небольшими изменениями, если строка имеет длину в 100 байт, то на сравнениях будет большие потери, хотя не факт.
|
|||
124
SSSSS_AAAAA
08.09.16
✎
15:18
|
(121) Как вы можете увидеть в любом случае сервер оперирует именно наборами байт, представляющими из себя ЧИСЛО каких-то единиц времени до/от какой-то точки на шкале времени. Разница только в длине/разрядности числа.
|
|||
125
ViSo76
08.09.16
✎
15:24
|
(124) Только битами, битами управляет :) байт это уже высокоуровневая тема...
|
|||
126
denis_jj
08.09.16
✎
15:55
|
(119) Вы писали "И какие такие для них разные индексы можно построить?"
Тут ответ в прикладной задаче. Например: 1. Нужно выбрать все записи за 2015 год. 2. Нужно выбрать все записи за первое число всех месяцев всех лет. Для первого случая подойдет индекс, построенный по части поля Год. Для второго случая подойдет индекс, построенный по части поля Число. Если использовать во второй задаче индекс от первой задачи, то эффективность такого поиска будет хуже чем просто сканирование таблицы. Почувствуйте разницу. |
|||
127
SSSSS_AAAAA
08.09.16
✎
16:02
|
(126) Для сервера в дате нет частей. Никаких.
Для конкретной прикладной задачи будут хранить не дату, а части даты в виде строк или чисел и по ним и будут делать индексы. Почувствуйте разницу. |
|||
128
ViSo76
08.09.16
✎
16:04
|
(126) Это дано на откуп тебе. В любом случае нужно из даты выносить либо год либо число и индексировать ( и индекс будет в данном случае по структуре одинаковым ). Для баз данных есть DBA и если построенные индексы разработчиков не удовлетворяют потребностям, у него всегда есть возможность повлиять на физическую сущность.
|
|||
129
denis_jj
08.09.16
✎
16:07
|
(127) (128) Ну это просто пример, который удобно рассматривать. Я хочу сказать, что для разных типов данных индекс будет строится по некоторым правилам, хотя бы по структуре хранения данных.
|
|||
130
ViSo76
08.09.16
✎
16:13
|
(127) Он весь твой :)
|
|||
131
SSSSS_AAAAA
08.09.16
✎
16:13
|
(129) Пошли отмазы про неудачно выбранный пример...
"для разных типов данных индекс будет строится" Еще раз - где такой чуши набрались? Откуда уверенность, что именно так и будет? Структура у индексов одна и она не зависит от типа данных. Ибо она рассчитана изначально на хранение значений большинства известных серверу типов данных без учета смысла этих значений для конечного пользователя. |
|||
132
denis_jj
08.09.16
✎
16:16
|
(131) Никаких отмазов. В условии автор спрашивает какой тип данных выбрать. А от этого зависит как будут данные храниться в базе и как построятся индексы. А от того как они построятся будет зависеть в конечном счете скорость поиска.
|
|||
133
ViSo76
08.09.16
✎
16:17
|
(132) Автор уже давно забил и запил, в крайнем случае перелогинься :)
|
|||
134
ViSo76
08.09.16
✎
16:24
|
(132) Он спросил всего лишь что быстрее работает поиска по ссылке или поиск по строке на 10 лямах, ну ясен пень что ссылка ( тем более кластер ) будет работать гораздо быстрее.
|
|||
135
SSSSS_AAAAA
08.09.16
✎
16:29
|
(132) "В условии автор спрашивает какой тип данных выбрать."
Уже написано, что для сферического и т.д. по тесту вопрос идиотский. Он перестанет быть таковым только после указания всех влияющих на выбор факторов. "А от этого зависит как будут данные храниться в базе" Это называется проектирование структуры и к индексам в этом деле относится только не/возможность проиндексировать какое-либо важное для поиска поле. " и как построятся индексы." Не построятся. Если не дать соответствующую команду. И их структура будет зависеть от списка полей, а не от их типа. "А от того как они построятся будет зависеть в конечном счете скорость поиска." Построятся они одинаково - вырезкой указанных полей из таблицы. Без преобразований и без учета их типа. Вы быть хоть что-то для чайников по базам почитали бы... Разработчиков СУБД за идиотов считаете? Не пробовали выяснить насколько ваши представления о БД, в общем, и о индексах, в частности, расходятся с теорией и практикой работы с базами данных? |
|||
136
denis_jj
08.09.16
✎
16:52
|
(135) Некоторое представление о работе СУБД у меня есть и мне этого достаточно. То, что поиск по полям разных типов в прикладной системе происходит по разному я знаю точно ибо проверял не раз. И меня интересует в первую очередь результат в прикладной системе, а не то как там байты хранятся. Поэтому для меня решение данной задачи очевидно.
А с вами я не согласен. От типа данных зависит как данные хранятся в базе а значит зависят и индексы и производительность. |
|||
137
SSSSS_AAAAA
08.09.16
✎
17:19
|
(136) "Некоторое представление о работе СУБД у меня есть и мне этого достаточно."
Ну, для вас и вашей работы может и достаточно, а вот для споров по узким и/или глубоким темам... "Некоторое представление о работе СУБД у меня есть и мне этого достаточно. " Потрясающе! Дилетант поставил свои дилетантские тесты и они теперь мерило всех баз данных... Сильный аргумент. "И меня интересует в первую очередь результат в прикладной системе, а не то как там байты хранятся. " Тем не менее именно про хранение вы нам тут много долго что-то пытались втирать... " Поэтому для меня решение данной задачи очевидно. " Какой задачи? Где и какую задачу то увидели? "А с вами я не согласен." Всё, от такого удара я сейчас сдохну... Несогласие со мной ТАКОГО спеца - невыносимо... "От типа данных зависит как данные хранятся в базе а значит зависят и индексы и производительность." Чуть вышек вы писали, что "меня интересует в первую очередь результат в прикладной системе, а не то как там байты хранятся." Вы уж определитесь... Короче, аргументов и так было кот наплакал и потому пошли бездоказательные рассказы о собственно доблести. |
|||
138
SSSSS_AAAAA
08.09.16
✎
17:22
|
(137) Вторая цитатка должна быть такой:
"поиск по полям разных типов в прикладной системе происходит по разному я знаю точно ибо проверял не раз." И ей соответствует ответ про тесты. |
|||
139
denis_jj
08.09.16
✎
17:59
|
(137)(138) Если вы тут не видите задачи, то откуда тут может быть спор по узким и/или глубоким темам?
А тем более интересно на каких основаниях вы сделали вывод о "дилетанте и дилетантских тестах"? Я высказал свое мнение, основанное на моём опыте и защищаю свою позицию, делаю это корректно и не перехожу на личности. А вы ведете себя некорректно. |
|||
140
ViSo76
08.09.16
✎
18:05
|
(138) В данном случае я думаю что тебе будет проще признать что ты не прав :) исходя из постов типа (139)
|
|||
141
Feanor
08.09.16
✎
18:08
|
(140) тема с хэш-функцией строки в индексе выглядит не очень убедительно :)
|
|||
142
denis_jj
08.09.16
✎
18:11
|
(140) Я так не считаю.
|
|||
143
Feanor
08.09.16
✎
18:13
|
(142) каким образом тогда будет работать покрывающий индекс? ведь фактически в этом случае нужен будет кей или рид лукап
|
|||
144
denis_jj
08.09.16
✎
18:19
|
(143) какое отношение ваш вопрос имеет к теме, которую мы обсуждаем?
|
|||
145
ViSo76
08.09.16
✎
18:20
|
(143) Если про like, то можно сделать первые 5,10 символов в качестве ключа и после подгрузи данных, сравнение уже с полной строкой... это уменьшит объём чтения, да и индекса. К примеру на строку в 250 символов.
|
|||
146
vi0
08.09.16
✎
19:44
|
(0) логически рассуждая, уид будет 16 байт, его строкоеое представление 72 байта
т.е. таблица будет больше размером, выборка будет больше теоритически, строка будет менее производиельна |
|||
147
Feanor
08.09.16
✎
20:35
|
(145) речь не про лайк, а про то, как вытащить данные из индекса, который построен как хэш-функция от строкового поля, без обращения к самим данным. По-моему, это невозможно. А обращение к данным сведет на нет все преимущества хэширования.
|
|||
148
ViSo76
08.09.16
✎
20:47
|
(147) Вообще-то проблема не в выстаскивании 1 блока из тысячи, а в нахождении оного. Я не утверждаю что это так. Но хэш реально может ускорить и скорость не будет шибко зависить от длины строки.
|
|||
149
Feanor
08.09.16
✎
20:57
|
(148) положим, тебе нужно выбрать фамилии всех сотрудников, есть индекс по фамилии. Если хэша нет, то все просто, достаточно сделать индекс скан и задача решена. А если в индексе лишь непонятный хэш? Скока тогда нужно будет сделать лишних действий и прочитать лишних страниц?
|
|||
150
Torquader
08.09.16
✎
21:03
|
У SQL-сервера индекс по GUID-у должен быть более оптимизирован, так при поиске строк будет выполняться анализ кодовой страницы.
В остальных случаях - чтение сектора с диска намного медленнее поиска по памяти - следовательно - при сравнимой длине (72 символа и 16 символов) скорость поиска будет примерно одинаковой. |
|||
151
ViSo76
08.09.16
✎
21:44
|
(149) Хэш к примеру на первые 5 байт. Далее поиск в данных
|
|||
152
AlexAl-77
08.09.16
✎
22:15
|
Замеры показали что почти одинаково разница от пол секунды до секунды в пользу гуида.Всем спасибо за мысли.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |