Коллеги, может кто-нибудь привести цитату от фирмы 1с, что УИДы намеренно генерируются инкрементно с такой от целью.
Под инкрементно подразумеваю, что при сортировке по УИД, более ранние значения будут стоять перед поздними.

(0) никто не гарантирует этого. Одинесникам не положено знать как генерятся уиды

(0)Когда-нибудь мирок 1С сожмется в черную звезду и схлопнется? Все объекты придут к крайнему УИДу и дальше несуществование?
Классная мысль с утра. Бодрит.

(0) Сколько у нас времени до катастрофы? Посчитай пожалуйста. Это важно.

Ждем конца света (УИДов)

Ващета, уиды действительно генерятся инкрементно, но последовательные серии идут в пределах сессии

так что об сортировке речи идти не может

*в пределах сеанса

(7) Сколько может прожить сеанс пока кончатся УИДы?

Все равно мы все умрем. Разница лишь в способе.

Есть, например,Моби-С. Ну или другая прелесть, которая автоматически прогружает сторонние данные, плодя сущности.
Делает это отдельной обработкой, запущенной в сеансе.

Сеанс этот может не гаситься месяц или год.

Когда им придет капец?

(9) очень нескоро

(10) Вы как опытный продажник отвечаете.

(11) потому что нельзя однозначно сказать, через 36 лет 17 часов 19 минут 59 секунд

(0) Нифига подобного, смотри статью на мистастарте про это.

(12) Можно. Среднюю скорость проведения новой Реализации берем и умножаем.... Считаем что заявки льются без остановки. Получаем минимальное гарантированное время жизни.

(13) Ссылка?

(3) Только Темная Сторона Силы поможет нам избежать катастрофы. Присоединись к ней, познай истинную мощь желто-красного кода и ты спасешь Галактику"

Вот несколько уидов Номенклатуры в нашей базе:

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

Понятно, что они нифига не случайным образом сгенерены

(17)Скорее всего случайно генерятся только УИДы таблиц. А внутри них уже просто в HEX идет счетчик

(15) в поиске забанили?

http://catalog.mista.ru/public/635159/

(16) Дык, уже.
(19) Нет. Просто лень.

(0)Попросту для равномерного заполнения страниц в БД.

(0) Если гуиды не будут инкрементны, а точнее если их порядок не будет детерминирован, то кластерный индекс по ним будет чудовищно деградировать по времени вставки. Поэтому 1с старается обеспечить, чтобы следующий по времени гуид был > предыдущего и вставлялся в конец таблицы.

(21) а нужно ли оно, равномерное заполнение страниц?

(22) откуда дровишки?

Получается одни плюсы от такого формирования гуидов

(24)
Какие? Что гуид плох для кластерного индекса? Это напрямую из природы индексов и гуидов вытекает. Это столкновение абсолютной упорядоченности с абсолютной случайностью, это не сочетается.

Погугли про проблемы кластерных индексов на гуид.

Что до утверждения, что 1с для решения именно этой проблемы использует инкремент гуидов - это моё предположение. Логично же.

(26) если ты отсортируешь любой справочник по гуидам, то получишь радугу. гиуд не предназначен для сортировки

(27) Но при этом по нему сортировка по умолчанию )))

(28) у меня по основному представлению сортируется по-умолчанию

(27)
Да капитан.
Теперь изложи свои мысли о том, как работает кластерный индекс. Уж не сортирует ли гуиды, а?

(29) Там чуть пониже 1с, есть такая штука как СУБД, таблицы и индексы к таблицам. И в 1с есть документация насчет того, к каким объектам, при каких условиях какие индексы создаются, а также используется ли кластерный индекс.

(26) + характерно что биты guid переставляются для получения uid который записывается в базе... в младшие биты помещаются как раз 'инкрементируемые'

(30) понятия не имею, но к решению вопроса (0) это не имеет отношения. 1С не гарантирует что каждый новый УИД больше предыдущего

(33) В (0) нигде не сказано про гарантию

(33) Если ты не имеешь понятия про принципы организации кластерного индекса, зачем ты лезешь спорить с разумным предположением аргументами в стиле "у меня по представлению порядок стоит, иди в жпу"?

(34) Так какого хрена ему никто не ответил?

(36) на его вопрос ответ есть полностью.

(35) что, умный, да?

(37) он просил источник

(39) 1с не раскрывает источников: почему да как

(40) и в каком посте, до тебя, ему об этом сказали?

(38) А ты изысканный собеседник, еще пара постов и будет каноническое "сам дурак!"

Продолжай, пожалуйста, раскрывать свою безграмотность, не дай утонуть ветке в серой будничной пучине.

(42) почитал я уже про кластерные индексы. В принципе, и ранее имел с ними дело. Ещё до 1С, в конце 90-х.
Ну, не суть. Да, скорее всего, 1С именно с этой целью уиды генерирует инкрементно в пределах сессии, но что с того?

(43) Ну вот, ты обрел новые знания. Теперь на вопрос коллеги "1с тупая даже не может нормальные гуиды генерить", ты сможешь аргументированно ответить - это компромисс между производительностью и РИБ.

Ну вот майкрасофт тож говорит о последовательных guid:
https://msdn.microsoft.com/ru-ru/library/ms189786(v=sql.120).aspx

Функцию NEWSEQUENTIALID() можно использовать для формирования идентификаторов GUID, чтобы уменьшить состязание страниц на конечном уровне индексов.

Каждый идентификатор GUID, сформированный с помощью функции NEWSEQUENTIALID(), является уникальным на данном компьютере. Идентификаторы GUID, сформированные с помощью функции NEWSEQUENTIALID(), становятся уникальными для нескольких компьютеров, только если в компьютере-источнике имеется сетевая плата.

(42) + вот кстати статейка где сравниваются GUID vs SeqGUID vs INT

https://blogs.msdn.microsoft.com/sqlserverfaq/2010/05/27/guid-vs-int-debate/

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.

(46) ну тут цитата у тебя не про 1с
т.к. не OLTP и в 1с нет ссылочной целостности на уровне СУБД

1c как раз ОЛТП

(48) да, перепутал с олапом

(45) да, вот еще это из книги 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 http://blog.kejser.org/2011/10/05
/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 http://dangerousdba.blogspot.com/
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) ну можешь поискать это на русском
я читал это книгу и в переводе и в оригинале - крайне не рекомендую на русском, т.к. переводил не технарь и при этом на коленке

(50) кстати? исходя из этого текста, я могу предположить, что проблема вставки не будет актуальна для SSD

(51) Абзац в (46) вполне приемлемо переводится в google-переводчике. Для понимания достаточно.

(53) почему? заполнение страниц все равно хуже при гуиде

(55) второй абзац в (50) про неинкрементные ключи
как раз говорится, что при наличии нескольких spindles (я так понимаю что это физические диски) вставка будет быстрее в паралельных сеансах

плюс там же говорится про фрагментированность у неинкрементных ключей, а у ssd нет проблемы фрагментированности, там она даже полезна

это все лично мои выводы

(56) "как раз говорится, что при наличии нескольких spindles вставка будет быстрее в паралельных сеансах "

Это я про то, что в SSD вставка и делается параллельно

(56) это просто вопрос распараллеливания, что разреженные параллелятся лучше. Но разреженные все равно жрут больше кешей и требуют больше ИОпс, т.к. почти равновероятен целевой лист для записи попадание в кеш менее вероятно. Кроме кеша да, ссд лишен болячек хдд и проигрыш от многопоточной записи в разные места ничтожен

(58) это не просто вопрос распаралеливания, это я тебе ответил на (55) ))

(59) да понятно, я просто пытаюсь уточнить акценты. Шпиндели дают параллельность, которая больше решает для классики в смысле расширения бутылочного горлышка. Но если еще не уперлись, если система в зеленой зоне, указанной деградации от ГУИД ссд не лишен

(60) т.е. ты говоришь, что увеличение количества шпинделей расширяют бутылочное горлышко, а ssd нет?