|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
Есть некоторое соображение о фундаментальном недостатке guid-идентификаторов. Оно не имеет четкого подтверждения в виде хорошо сформулированных экспериментальных данных, пока лишь очень интуитивно. С размером и некоторым временем на генерацию всем все известно - тут обсуждать уже нечего. Но есть еще один нюанс: если guid-идент является первичным ключом в индексе по схеме b-дерева, то из-за того, что значение такого идентификатора - практически случайный хэш, записи, которые естественным образом "жмутся" друг к другу при поиски по guid-ключу попадают в разные узлы b-дерева. В результате поиск по сравнению с целочисленными autoincrement-ключами значительно затормаживается. Если у вас в таблице тысячи или десятки тысяч записей, то вы ничего не заметите, но в случае с миллионами записей (тем паче, при бОльших порядках) разница становится существенной. Аналогичная проблема при вставке записей. Решением этой трудности мог бы быть хэш-индекс, но в реальности его редко применяют и многие dbms даже не предоставляют возможность его использования. Вопрос: я ошибаюсь, или так оно и есть? Если у кого-то есть ссылки на подробный анализ вопроса - буду благодарен. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.07.2015, 01:37 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
sobolev, вроде уже и секюенталгуид придумали и пользуются :) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.07.2015, 02:27 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
ViPRossobolev, вроде уже и секюенталгуид придумали и пользуются :) посмотрел. я не знал об sequential guid. значит мне не показалось. только мою проблему это не решает. я гребаный фиас загружаю, а там гуиды обычные. спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.07.2015, 08:43 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
sobolev, ну а так, какая разница что там сортируется (гуид или число) просто число априори имеет свойство рости с определенным сиид. что дает компактность ну будут чуть чаще перестраиваться индексы, не думаю что это так уж аукнется ... |
|||
:
Нравится:
Не нравится:
|
|||
10.07.2015, 11:18 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
sobolevя гребаный фиас загружаю, а там гуиды обычные а в чем проблема? это не ежесекундно меняющиеся данные. загрузите данные, перестройте индексы, все нормально разложится. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.07.2015, 12:48 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
sobolevзаписи, которые естественным образом "жмутся" друг к другу при поиски по guid-ключу попадают в разные узлы b-дерева. В результате поиск по сравнению с целочисленными autoincrement-ключами значительно затормаживается. Не понял этой фразы. Что и с чем Вы сравниваете? Cобственно, непонятки начинаются уже со "жмутся". Допустим, таблица состоит из трёх блоков. В первом свободно 100 байт, во втором свободно 200 байт, третий пустой. Мы вставляем в неё сначала запись длиной 150 байт, потом запись длиной 90 байт. Внимание, вопрос: как размещение записей зависит от значения ключа? sobolevВопрос: я ошибаюсь, или так оно и есть? Здорово похоже, что Вам стоит глубже изучить структуру и алгоритмы хранения данных в используемой СУБД. Просто для того, чтобы правильно задать вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2015, 09:10 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
softwarersobolevзаписи, которые естественным образом "жмутся" друг к другу при поиски по guid-ключу попадают в разные узлы b-дерева. В результате поиск по сравнению с целочисленными autoincrement-ключами значительно затормаживается. Не понял этой фразы. Что и с чем Вы сравниваете? Cобственно, непонятки начинаются уже со "жмутся". Допустим, таблица состоит из трёх блоков. В первом свободно 100 байт, во втором свободно 200 байт, третий пустой. Мы вставляем в неё сначала запись длиной 150 байт, потом запись длиной 90 байт. Внимание, вопрос: как размещение записей зависит от значения ключа? Речь об индексных страницах. В страницах данных, само собой, размещение от значения ключа не зависит. Впрочем, ViPRos дал наводку на sequential guid. В контексте этого термина проблема расписана куда грамотней, чем я сформулировал. Думаю, вам тоже полезно будет почитать. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2015, 15:44 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
sobolevРечь об индексных страницах. Впрочем, ViPRos дал наводку на sequential guid. В контексте этого термина проблема расписана куда грамотней, С точки зрения индексных страниц последовательные ключи отличаются от произвольных двумя вещами. Во-первых, возникает конкуренция за последний блок (горячая страница), которая может затормозить вставку. В ряде случаев именно здесь возникает "бутылочное горлышко", определяющее скорость всего процесса. Во-вторых, СУБД, как правило, обладает специальным алгоритмом расщепления последней страницы, в результате чего последовательные ключи оказываются плотнее уложенными, то есть индекс занимает несколько меньше места, как следствие - несколько лучше кэшируется итд. Для решения первой обозначенной проблемы можно использовать реверсивные либо хэш-индексы - то есть разрушить узкое место, размазать его по всему индексу. Для решения второй стоит поискать в СУБД штатные средства "уплотнения" индекса после массовой загрузки. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2015, 16:12 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
softwarerВо-первых, возникает конкуренция за последний блок (горячая страница), которая может затормозить вставку. +1 Интересный тест по ссылке (СУБД Cache): http://habrahabr.ru/company/intersystems/blog/263793/ В двух словах, когда 10 процессов параллельно записывали данные с линейно возрастающим ключом, суммарное время было 21 сек. Когда процессы получали "кусочно" возрастающие последовательности ключей, каждый свою последовательность, вставка выполнялась в разные страницы и суммарное время было 3.3 сек! Сказать по правде, не ожидал, что проблема "узкого горлышка" такая "острая". ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 16:56 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
DirksDRСказать по правде, не ожидал, что проблема "узкого горлышка" такая "острая". Ну, справедливости ради, здесь она искусственно обострена. Ситуация, когда параллельно работают несколько массовых загрузчиков, валя при этом данные в одну неразделяемую кучу, в которой нужно идентифицировать запись по суррогатному ключу - довольно редка на практике, имхо. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 17:57 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
если говорить о GUID идентификаторах, то их неиспользование обусловлено какими-то сказками. Их же использование в качестве идентификаторов имеет массу преимуществ, особенно в многозвенных системах и в задачах репликации данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 19:16 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
GUID must haveИх же использование в качестве идентификаторов имеет массу преимуществ Чушь. GUID must haveособенно в многозвенных системах Скорее всего чушь. GUID must haveи в задачах репликации данных. Чушь. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 19:37 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
softwarerGUID must haveИх же использование в качестве идентификаторов имеет массу преимуществ Чушь. GUID must haveособенно в многозвенных системах Скорее всего чушь. GUID must haveи в задачах репликации данных. Чушь. сплошная чушь. Я на основании множества систем говорил это.... а Вы? Поразительный ресурс. Приходит некто, кто и понятия не имеет что такое многозвенные системы или для репликации гоняет тонны данных туда сюда вместо реплики изменений и т.п. Но главное ляпнуть "чушь!" ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 20:00 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
GUID must haveПоразительный ресурс. Приходит некто, И начинает пороть чушь, скорее всего высосанную из пары рекламных статеек MSSQL-я. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 20:16 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
это примерно как в такой ситуации: ссылка на хабр т.е. приводятся результаты тестов, типа генерация 50000 новых записей с GUID в качестве первичных ключей выполняется медленнее. При этом у автора с хабра почему-то даже не возникает в статье вопроса: а нафига нужно 50000 новых записей генерировать и насколько это более критично, чем синхронизация ключей другого формата, НЕ gUID, в распределенной сети. Т.е. главное выполнить никому не нужный тест и обратить внимание на его результаты. MSDN на тему выбора ключа публикует такие мысли: ссылка на MSDN ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 20:23 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
softwarerGUID must haveПоразительный ресурс. Приходит некто, И начинает пороть чушь, скорее всего высосанную из пары рекламных статеек MSSQL-я. нет, он просто своими руками строит распределенные многозвенные системы. А на чем Ваш опыт обратного базируется, да еще и с таким апломбом? Или здесь просто так принято? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 20:27 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
GUID must haveнет, он просто своими руками строит распределенные многозвенные системы. Вы говорите так пафосно, словно это достижение. GUID must haveА на чем Ваш опыт обратного базируется, Частично на опыте проектов, в которых принимал участие. Частично на опыте систем, с которыми интегрировался, мигрировал данные, иным образом взаимодействовал или наблюдал со стороны. Частично на материале всевозможных бесед, дискуссий, книг, статей и так далее. Ну и наконец, на куче мелких наблюдений, которые по деталям Ваших слов заставляют предположить, что Вы работаете с MSSQL, в тщательном соответствии с тем или иным руководством "как строить распределённые многозвенные системы", гордитесь тем, что у Вас что-то получилось, но ещё не дошли до стадии критического осмысления собственного опыта и не выработали умение, видя какое-либо возможное решение задачи, искать другие, сравнивать и выбирать лучшее. GUID must haveда еще и с таким апломбом? Или здесь просто так принято? Да нет, просто люблю "зеркалить" собеседника. Люди так забавно раздражаются, когда отвечаешь им в их же манере... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 21:12 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
softwarer, так в чем все же проблемы у Вас возникали? Вы скрываете это? как передаете данные между узлами и их синхронизируете? Изобретаете какие-то составные ключи? Если записи логического объекта переносятся (копируются) с одной БД в другую, то каким образом распознаете что это записи того же объекта, просто в другом месте хранения. Или просто не приходилось сталкиваться с распределенными системами и основываетесь банально на опытах локальных БД, скорее всего в обычных двухзвенных приложениях к СУБД? p.s. я работаю с Oracle, MS SQL, Firebird. С MySQL только плотно не приходилось. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 22:42 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
softwarerGUID must haveда еще и с таким апломбом? Или здесь просто так принято? Да нет, просто люблю "зеркалить" собеседника. Люди так забавно раздражаются, когда отвечаешь им в их же манере... гениально. Первый же ответ был НЕ "в их же манере"... 18177523 Вы просто назвали "чушью" то, чем заниматься, похоже, не приходилось. И судя по всему какую-то душевную травму Вам нанес MS SQL. Так как я разрабатываю приложения и для ORACLE и часто общаюсь в среде администраторов и разработчиков приложения для этой СУБД, Вы похожи на тех, кто кроме ORACLE ничего не видел и так называемый "дремучий ораклист". Хотя не уверен. Может и другой СУБД... не знаю. Просто "дремучие ораклисты" так себя ведут, психотип знаковый. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 22:54 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
softwarerGUID must haveи в задачах репликации данных. Чушь. точно - не чушь. для репликации гуиды - находка. есть некоторые побочные проблемы, но абсолютная уникальность в этой области - очень хорошо. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2015, 23:50 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
sobolevsoftwarerпропущено... Чушь. точно - не чушь. для репликации гуиды - находка. есть некоторые побочные проблемы, но абсолютная уникальность в этой области - очень хорошо. для репликации иногда специальный столбец делается с GUID, если первичный ключ иной. Просто задачи репликации на порядок проще решаются когда можно просто идентифицировать запись. Аналогично и задачи в распределенных системах решаются на порядки проще есть уникальный идентификатор у записи. И это не сравнимо по выгодам в сравнении с затратами при использовании других ключей. А для единичных таблиц с кучей данных конечно можно INT (BIGINT) ключи использовать, ведь их логическое предназначение - просто куча данных, нужных только "здесь" какое-то определенное время ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2015, 00:28 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
sobolevsoftwarerпропущено... Чушь. точно - не чушь. для репликации гуиды - находка. есть некоторые побочные проблемы,"Чемодан без ручек: нести тяжело, выбросить жалко" (с) Если бы это были просто "некоторые проблемы", то вопрос об использовании или не использовании гуидов не вылезал бы с завидной регулярностью по всему интернету. sobolevно абсолютная уникальность в этой области - очень хорошо.к слову, гуид не гарантирует абсолютной уникальности - у него приемлемый практический уровень вероятности несовпадения значений. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2015, 08:16 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
что говорят о GUID другие: Например на известсном у ораклистов ресурсе Ask Tom автор считает: Tom KyteIf your tables have a natural key already - a true key - do not replace them with surrogates. If you are already using a surrogate (a sequence for example) and you are going to populate yet another surrogate, I would chose to use a single surrogate if I could - one less column, one less unique index to maintain. a GUID should be a 16 byte raw (hopefully they are not using a 32 byte varchar2..) and will perform adequately as a primary key. ссылка на вопрос-ответ stackexchange.com GUID Pros Unique across every table,every database, every server Allows easy merging of records from different databases Allows easy distribution of databases across multiple servers You can generate IDs anywhere, instead of having to roundtrip to the database Most replication scenarios require GUID columns anyway GUID Cons It is a whopping 4 times larger than the traditional 4-byte index value; this can have serious performance and storage implications if you're not careful Cumbersome to debug (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}') The generated GUIDs should be partially sequential for best performance (eg, newsequentialid() on SQL 2005) and to enable use of clustered indexes ссылка p.s. чмо, опущенное автором за подписью _реальность и гадящее теперь в других топиках прикрываясь этой подписью ничего общего с автором за подписью _реальность из топика о "шине" не имеет. Чтобы было понятно, сообщение выше 18178527 написано этим чмом, а не реальность. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2015, 10:21 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
sobolevточно - не чушь. для репликации гуиды - находка. есть некоторые побочные проблемы, но абсолютная уникальность в этой области - очень хорошо. Во-первых, с абсолютной уникальностью у гуида хуже, чем у нормальных решений. Её можно считать приемлемой, но регулярные сообщения "а мы ещё доработали гуид, и теперь-то он точно не облажается" вставляют. В остальном же Ваша фраза напоминает неумеренный восторг типа "Солярка - находка для автомобиля". Да, у неё есть своя ниша предпочтительного применения, но большинство движков и без неё отлично себя чувствует, а многим она прямо вредна. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2015, 11:06 |
|
о guid идентификаторах
|
|||
---|---|---|---|
#18+
Вот тут Эрик про гуиды разжевывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2015, 11:06 |
|
|
start [/forum/topic.php?fid=33&msg=39058109&tid=1547434]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
157ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 292ms |
total: | 557ms |
0 / 0 |