Почему УИДы генерируются инкрементно? #801986


#0 by vi0
Коллеги, может кто-нибудь привести цитату от фирмы 1с, что УИДы намеренно генерируются инкрементно с такой от целью. Под инкрементно подразумеваю, что при сортировке по УИД, более ранние значения будут стоять перед поздними.
#1 by 1dvd
никто не гарантирует этого. Одинесникам не положено знать как генерятся уиды
#2 by Два Плюс Два
Когда-нибудь мирок 1С сожмется в черную звезду и схлопнется? Все объекты придут к крайнему УИДу и дальше несуществование? Классная мысль с утра. Бодрит.
#3 by Два Плюс Два
Сколько у нас времени до катастрофы? Посчитай пожалуйста. Это важно.
#4 by Два Плюс Два
Ждем конца света (УИДов)
#5 by 1dvd
Ващета, уиды действительно генерятся инкрементно, но последовательные серии идут в пределах сессии
#6 by 1dvd
так что об сортировке речи идти не может
#7 by 1dvd
*в пределах сеанса
#8 by Два Плюс Два
Сколько может прожить сеанс пока кончатся УИДы? Все равно мы все умрем. Разница лишь в способе.
#9 by Два Плюс Два
Есть, например,Моби-С. Ну или другая прелесть, которая автоматически прогружает сторонние данные, плодя сущности. Делает это отдельной обработкой, запущенной в сеансе. Сеанс этот может не гаситься месяц или год. Когда им придет капец?
#10 by 1dvd
очень нескоро
#11 by Два Плюс Два
Вы как опытный продажник отвечаете.
#12 by 1dvd
потому что нельзя однозначно сказать, через 36 лет 17 часов 19 минут 59 секунд
#13 by torgm
Нифига подобного, смотри статью на мистастарте про это.
#14 by Два Плюс Два
Можно. Среднюю скорость проведения новой Реализации берем и умножаем.... Считаем что заявки льются без остановки. Получаем минимальное гарантированное время жизни.
#15 by Два Плюс Два
Ссылка?
#16 by Diman000
Только Темная Сторона Силы поможет нам избежать катастрофы. Присоединись к ней, познай истинную мощь желто-красного кода и ты спасешь Галактику"
#17 by 1dvd
Вот несколько уидов Номенклатуры в нашей базе: 6c7e132d-6c57-11e7-80c6-801844deba29 6c7e132e-6c57-11e7-80c6-801844deba29 6c7e132f-6c57-11e7-80c6-801844deba29 6c7e1330-6c57-11e7-80c6-801844deba29 6c7e1331-6c57-11e7-80c6-801844deba29 6c7e1332-6c57-11e7-80c6-801844deba29 6c7e1333-6c57-11e7-80c6-801844deba29 6c7e1334-6c57-11e7-80c6-801844deba29 6c7e1335-6c57-11e7-80c6-801844deba29 6c7e1336-6c57-11e7-80c6-801844deba29 6c7e1337-6c57-11e7-80c6-801844deba29 6c7e1338-6c57-11e7-80c6-801844deba29 6c7e1339-6c57-11e7-80c6-801844deba29 6c7e133a-6c57-11e7-80c6-801844deba29 6c7e132d-6c57-11e7-80c6-801844deba29 6c7e132e-6c57-11e7-80c6-801844deba29 6c7e132f-6c57-11e7-80c6-801844deba29 6c7e1330-6c57-11e7-80c6-801844deba29 6c7e1331-6c57-11e7-80c6-801844deba29 6c7e1332-6c57-11e7-80c6-801844deba29 6c7e1333-6c57-11e7-80c6-801844deba29 6c7e1334-6c57-11e7-80c6-801844deba29 6c7e1335-6c57-11e7-80c6-801844deba29 6c7e1336-6c57-11e7-80c6-801844deba29 6c7e1337-6c57-11e7-80c6-801844deba29 6c7e1338-6c57-11e7-80c6-801844deba29 6c7e1339-6c57-11e7-80c6-801844deba29 6c7e133a-6c57-11e7-80c6-801844deba29 Понятно, что они нифига не случайным образом сгенерены
#18 by Рэйв
Скорее всего случайно генерятся только УИДы таблиц. А внутри них уже просто в HEX идет счетчик
#19 by torgm
в поиске забанили?
#20 by Два Плюс Два
Дык, уже. Нет. Просто лень.
#21 by DmitrO
Попросту для равномерного заполнения страниц в БД.
#22 by MrStomak
Если гуиды не будут инкрементны, а точнее если их порядок не будет детерминирован, то кластерный индекс по ним будет чудовищно деградировать по времени вставки. Поэтому 1с старается обеспечить, чтобы следующий по времени гуид был > предыдущего и вставлялся в конец таблицы.
#23 by vi0
а нужно ли оно, равномерное заполнение страниц?
#24 by 1dvd
откуда дровишки?
#25 by Вафель
Получается одни плюсы от такого формирования гуидов
#26 by MrStomak
Какие? Что гуид плох для кластерного индекса? Это напрямую из природы индексов и гуидов вытекает. Это столкновение абсолютной упорядоченности с абсолютной случайностью, это не сочетается. Погугли про проблемы кластерных индексов на гуид. Что до утверждения, что 1с для решения именно этой проблемы использует инкремент гуидов - это моё предположение. Логично же.
#27 by 1dvd
если ты отсортируешь любой справочник по гуидам, то получишь радугу. гиуд не предназначен для сортировки
#28 by Вафель
Но при этом по нему сортировка по умолчанию )))
#29 by 1dvd
у меня по основному представлению сортируется по-умолчанию
#30 by MrStomak
Да капитан. Теперь изложи свои мысли о том, как работает кластерный индекс. Уж не сортирует ли гуиды, а?
#31 by MrStomak
Там чуть пониже 1с, есть такая штука как СУБД, таблицы и индексы к таблицам. И в 1с есть документация насчет того, к каким объектам, при каких условиях какие индексы создаются, а также используется ли кластерный индекс.
#32 by igork1966
+ характерно что биты guid переставляются для получения uid который записывается в базе... в младшие биты помещаются как раз 'инкрементируемые'
#33 by 1dvd
понятия не имею, но к решению вопроса это не имеет отношения. 1С не гарантирует что каждый новый УИД больше предыдущего
#34 by Вафель
В нигде не сказано про гарантию
#35 by MrStomak
Если ты не имеешь понятия про принципы организации кластерного индекса, зачем ты лезешь спорить с разумным предположением аргументами в стиле "у меня по представлению порядок стоит, иди в жпу"?
#36 by 1dvd
Так какого хрена ему никто не ответил?
#37 by Вафель
на его вопрос ответ есть полностью.
#38 by 1dvd
что, умный, да?
#39 by 1dvd
он просил источник
#40 by Вафель
1с не раскрывает источников: почему да как
#41 by 1dvd
и в каком посте, до тебя, ему об этом сказали?
#42 by MrStomak
А ты изысканный собеседник, еще пара постов и будет каноническое "сам дурак!" Продолжай, пожалуйста, раскрывать свою безграмотность, не дай утонуть ветке в серой будничной пучине.
#43 by 1dvd
почитал я уже про кластерные индексы. В принципе, и ранее имел с ними дело. Ещё до 1С, в конце 90-х. Ну, не суть. Да, скорее всего, 1С именно с этой целью уиды генерирует инкрементно в пределах сессии, но что с того?
#44 by MrStomak
Ну вот, ты обрел новые знания. Теперь на вопрос коллеги "1с тупая даже не может нормальные гуиды генерить", ты сможешь аргументированно ответить - это компромисс между производительностью и РИБ.
#45 by igork1966
Ну вот майкрасофт тож говорит о последовательных guid: Функцию NEWSEQUENTIALID можно использовать для формирования идентификаторов GUID, чтобы уменьшить состязание страниц на конечном уровне индексов. Каждый идентификатор GUID, сформированный с помощью функции NEWSEQUENTIALID, является уникальным на данном компьютере. Идентификаторы GUID, сформированные с помощью функции NEWSEQUENTIALID, становятся уникальными для нескольких компьютеров, только если в компьютере-источнике имеется сетевая плата.
#46 by igork1966
+ вот кстати статейка где сравниваются GUID vs SeqGUID vs INT The above considerations make the use of GUIDs unfavorable for a clustered index in environments which have large number of queries performing JOIN operations in OLTP and when referential integrity is enforced on the database among multiple tables. Throw non-clustered indexes that you created on the table as covering indexes for the frequently run queries against the database, you can have a significant performance bottleneck.
#47 by vi0
ну тут цитата у тебя не про 1с т.к. не OLTP и в 1с нет ссылочной целостности на уровне СУБД
#48 by Вафель
1c как раз ОЛТП
#49 by vi0
да, перепутал с олапом
#50 by vi0
да, вот еще это из книги Training Kit (Exam 70-461): Querying Microsoft SQL Server 2012 Starting with sequential keys, all rows go into the right end of the index. When a page is full, SQL Server allocates a new page and fills it. This results in less fragmentation in the index, which is beneficial for read performance. Also, insertions can be faster when a single session is loading the data, and the data resides on a single drive or a small number of drives. However, with high-end storage subsystems that have many spindles, the situation can be different. When loading data from multiple sessions, you will end up with page latch contention (latches are objects used to synchronize access to database pages) against the rightmost pages of the index leaf level’s linked list. This bottleneck prevents use of the full throughput of the storage subsystem. Consider nonsequential keys, such as random ones generated with NEWID or with a custom solution. When trying to force a row into an already full page, SQL Server performs a classic page split—it allocates a new page and moves half the rows from the original page to the new one. A page split has a cost, plus it results in index fragmentation. Index fragmentation can have a negative impact on the performance of reads. However, in terms of insert performance, if the storage subsystem contains many spindles and you’re loading data from multiple sessions, the random order can actually be better than sequential despite the splits. That’s because there’s no hot spot at the right end of the index, and you use the storage subsystem’s available throughput better. A good example for a benchmark demonstrating this strategy can be found in a blog by Thomas Kejser at /boosting-insert-speed-by-generating-scalable-keys/. Note that splits and index fragmentation can be mitigated by periodic index rebuilds as part of the usual maintenance activities—assuming you have a window available for this. If for aforementioned reasons you decide to rely on keys generated in random order, you will still need to decide between GUIDs and a custom random key generator solution. As already mentioned, GUIDs are stored in a UNIQUEIDENTIFIER type that is 16 bytes in size; that’s large. But one of the main benefits of GUIDs is the fact that they can be generated anywhere and not conflict across time and space. You can generate GUIDs not just in SQL Server using the NEWID function, but anywhere, using APIs. Otherwise, you could come up with a custom solution that generates smaller random keys. The solution can even be a mix of a built-in tool and some tweaking on top. For example, you can find a creative solution by Wolfgang 'Rick' Kutschera at 2011/10/day-sequences-saved-world.html. Rick uses the SQL Server sequence object, but flips the bits of the values so that the insertion is distributed across the index leaf. To conclude this section about keys and types for keys, remember that there are multiple options. Smaller is generally better, but then there’s the question of the hardware that you use, and where your performance priorities are. Also remember that although it is very important to make educated guesses, it is also important to benchmark solutions in the target environment.
#51 by dezss
Блин, мы даже пишем на русском, а на форум выкладывают текст на английском...тьфу...
#52 by vi0
ну можешь поискать это на русском я читал это книгу и в переводе и в оригинале - крайне не рекомендую на русском, т.к. переводил не технарь и при этом на коленке
#53 by vi0
кстати? исходя из этого текста, я могу предположить, что проблема вставки не будет актуальна для SSD
#54 by igork1966
Абзац в вполне приемлемо переводится в google-переводчике. Для понимания достаточно.
#55 by Йохохо
почему? заполнение страниц все равно хуже при гуиде
#56 by vi0
второй абзац в про неинкрементные ключи как раз говорится, что при наличии нескольких spindles (я так понимаю что это физические диски) вставка будет быстрее в паралельных сеансах плюс там же говорится про фрагментированность у неинкрементных ключей, а у ssd нет проблемы фрагментированности, там она даже полезна это все лично мои выводы
#57 by vi0
"как раз говорится, что при наличии нескольких spindles вставка будет быстрее в паралельных сеансах " Это я про то, что в SSD вставка и делается параллельно
#58 by Йохохо
это просто вопрос распараллеливания, что разреженные параллелятся лучше. Но разреженные все равно жрут больше кешей и требуют больше ИОпс, т.к. почти равновероятен целевой лист для записи попадание в кеш менее вероятно. Кроме кеша да, ссд лишен болячек хдд и проигрыш от многопоточной записи в разные места ничтожен
#59 by vi0
это не просто вопрос распаралеливания, это я тебе ответил на ))
#60 by Йохохо
да понятно, я просто пытаюсь уточнить акценты. Шпиндели дают параллельность, которая больше решает для классики в смысле расширения бутылочного горлышка. Но если еще не уперлись, если система в зеленой зоне, указанной деградации от ГУИД ссд не лишен
#61 by vi0
т.е. ты говоришь, что увеличение количества шпинделей расширяют бутылочное горлышко, а ssd нет?
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С

Back to top