Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
Ну, не знаю, как в высоконагруженных системах, но при числе соединений до 100 и при выдаче 100-300 документов за день, никаких видимых задержек при формировании номера документа из таблицы счетчиков+триггер не наблюдалось на протяжении много лет эксплуатации. И вроде бы ТС ничего не указывал на высоконагруженную систему, а тут сразу начали выдумывать термоядерные движки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:26 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
d7i, автор100-300 документов за день это без проблем ведётся в толстой тетрадке с учётом переноса её между складами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:30 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
iapВсё равно же надо ждать, пока он освободится!Надо. Только зачем выстраивать одну большую очередь, когда ее можно разбить на несколько меньших? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:46 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
d7iНу, не знаю, как в высоконагруженных системах, но при числе соединений до 100 и при выдаче 100-300 документов за день, никаких видимых задержек при формировании номера документа из таблицы счетчиков+триггер не наблюдалось на протяжении много лет эксплуатации. И вроде бы ТС ничего не указывал на высоконагруженную систему, а тут сразу начали выдумывать термоядерные движки...ТС дали разные варианты, что тут плохого, пусть почитает. Конечно, для создания 100-300 документов за день не нужно делать так сложно, задержек и не может быть. Проблемы будут, когда в среднее время транзакции нужно успеть завести более одного документа. Скажем, если транзакция 100мс, то заводим 10 документов в сек, или 36 000 в час. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 17:45 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
iapinvmпропущено... Разница большая, - потому что общий ресурс не таблица, а строка этой таблицы.Всё равно же надо ждать, пока он освободится! Если для каждого склада будет своя строка номера, то существует некая "параллельность". Дмитрий Короткевич на тему блокировок строк таблицы и их (блокировок) влияния на select по таблице делал сообщение,- лет пять-семь тому назад,- но с тех пор много воды утекло и что-то в механизмах MS SQL Server могло уйти вперёд... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 00:14 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
msLexSIMPLicity_Я бы, наверное, построил НЕкластерный индекс по склад - номер. Кластерный (такой же) был бы идеален, но на больших данных частых вставках, подозреваю, он будет слишком часто обновляться; а в том как работает механизм перестроения кластерного индекса я не сильно разбираюсь ... А как работает "механизм перестроения НЕкластерного индекса" вы разбираетесь? НЕкластерный не нужно обновлять? А после обновления НЕкластерного не нужно обновлять кластерный/кучу? При обновлении полей НЕкластерного индекса НЕ происходит перестроения самой таблицы. При добавлении/удалении строки - тоже. Если есть какая-то другая информация - буду признателен... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 00:31 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
[quot SIMPLicity_]msLexпропущено... При обновлении полей НЕкластерного индекса НЕ происходит перестроения самой таблицы. При добавлении/удалении строки - тоже. Если есть какая-то другая информация - буду признателен... Эвона как, а мужики то не знают! Ваш пример будет верен только если табл ввиде кучи и у нее есть хотя бы один не кластерный инд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 01:09 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_При обновлении полей НЕкластерного индекса НЕ происходит перестроения самой таблицы. При добавлении/удалении строки - тоже. А что, в вашем понимании, "перестроения самой таблицы" и что вообще такое "сама таблица"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 11:11 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
[quot Mr. X]SIMPLicity_пропущено... Эвона как, а мужики то не знают! Ваш пример будет верен только если табл ввиде кучи и у нее есть хотя бы один не кластерный инд. Почему именно так? ... Может быть кластерный индекс по времени появления строк в таблице, например (если такое поле предусмотрено). Тогда таблица будет монотонно расти согласно кластерного индекса. Изменения других полей (номер, ....) не будет влиять на него. А некластерные индексы будут перестраиваться согласно изменениям в соответствующих полях.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 01:36 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
msLexSIMPLicity_При обновлении полей НЕкластерного индекса НЕ происходит перестроения самой таблицы. При добавлении/удалении строки - тоже. А что, в вашем понимании , "перестроения самой таблицы" и что вообще такое " сама таблица "? Если отвлечься от того, как данные распределены "физически" по системе хранения (хард, полка, ssd-шник, RAMdrive, виртуальное хранилище, оперативка...) то для таблицы с кластерным индексом - это записи, уложенные друг за дружкой по кластерному индексу. Про columnstore-таблицы не интересовался. Если запись вставляется в середину страницы, то она либо попадает в неё (если есть место), либо страница расщепляется на две и новая запись попадает в одну из них. В случае "кучи": новые записи кидаются в конец "таблицы" и НЕкластерные индексы их ни как не организовывают. Кажется так. По крайней мере, я себе так представляю процесс... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 01:47 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_Если отвлечься от того, как данные распределены "физически" по системе хранения (хард, полка, ssd-шник, RAMdrive, виртуальное хранилище, оперативка...) то для таблицы с кластерным индексом - это записи, уложенные друг за дружкой по кластерному индексу. Про columnstore-таблицы не интересовался. Если запись вставляется в середину страницы, то она либо попадает в неё (если есть место), либо страница расщепляется на две и новая запись попадает в одну из них. В случае "кучи": новые записи кидаются в конец "таблицы" и НЕкластерные индексы их ни как не организовывают. Кажется так. По крайней мере, я себе так представляю процесс... Коль 1. В качестве физического уровня вы выбрали "железо" 2. Вы говорите о проблеме расщеплении данных на логическом уровне стоит предположить, что логический уровень хранения, это файлы данных и страниц в них (так же, кстати, логический уровень хранения определяют и разработчики SQL Server-а, когда называют внешнюю фрагментацию данных логической) В этом случае , логически эти данные не обязаны быть "уложены" друг за дружкой и часто могут быть разбросаны как внутри одного файла данных так и по разным файлам Если возвращаться к начальному вопросу кластерный - плохо, потому что будет "перестроение" (как мы выяснили, вы говорили про расщепление станиц данных) , некластерный - хорошо. то главная ваша ошибка в том, что при добавлении новых данных страницы некслатерного индекса так же могут расщепляться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 13:05 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
msLexто главная ваша ошибка в том, что при добавлении новых данных страницы некслатерного индекса так же могут расщепляться Да. Но как правило (даже если мы используем в НЕкластерном индексе включённые поля) , то на страницу умещается значимо больше "записей" некластерного индекса; соответственно и процесс "расщепления" идёт реже. Опять-таки, перестроение КЛАСТЕРНОГО индекса влечёт за собой корректировку всех НЕкластерных индексов. А наоборот - нет. Возможно, что это принципиально (т.е. явно заметно с точки зрения потери производительности) только на сильно больших данных. Общий вопрос: "подряд" или "НЕподряд" лежат записи в классической (НЕ column-store) таблице сильно обесценивается внедрением SSD, но остаётся актуальном в силу блочности операций чтения с СХД (СХД в широком смысле слова) . Насколько я понимаю, любая СХД (вне зависимости от реализации на физическом уровне) отдаёт данные сиквелу блоками. И чем компактнее данные лежат в блоках, тем лучше; а порядок расположения блоков в самой СХД в случае RAID уже не сильно принципиален (исключая чередование, зеркалирование и чередование+зеркалирование) . Думаю, что любой SQL|noSQL сервер НЕ умеет получать исключительно определённую запись таблицы с СХД; кроме как в случае, когда запись ложиться ровно в блок ;-) . ! Интересно, как всё происходит в случае сжатых данных .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 15:45 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_Опять-таки, перестроение КЛАСТЕРНОГО индекса влечёт за собой корректировку всех НЕкластерных индексов. А наоборот - нет все с точностью до наоборот ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 15:52 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_, авторНо как правило (даже если мы используем в НЕкластерном индексе включённые поля), то на страницу умещается значимо больше "записей" некластерного индекса; с страница 8кб, что такое значимо больше/значимо меньше не ясно как это влияет на расщипление, занято - split авторОбщий вопрос: "подряд" или "НЕподряд" лежат записи в классической (НЕ column-store) таблице сильно обесценивается внедрением SSD, но остаётся актуальном в силу блочности операций чтения с СХД (СХД в широком смысле слова). Насколько я понимаю, любая СХД (вне зависимости от реализации на физическом уровне) отдаёт данные сиквелу блоками. И чем компактнее данные лежат в блоках, тем лучше; а порядок расположения блоков в самой СХД в случае RAID уже не сильно принципиален (исключая чередование, зеркалирование и чередование+зеркалирование). Думаю, что любой SQL|noSQL сервер НЕ умеет получать исключительно определённую запись таблицы с СХД; кроме как в случае, когда запись ложиться ровно в блок ;-) . тут как то вообще не ясно о чём. Читает минимум экстентом и опять логическая и физическая фрагментация это вообще разные вещи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 15:54 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
авторОпять-таки, перестроение КЛАСТЕРНОГО индекса влечёт за собой корректировку всех НЕкластерных индексов. Нет. зачем? авторА наоборот - нет ну тут фиг поспоришь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 15:57 |
|
||
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1689619]: |
0ms |
get settings: |
8ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
28ms |
get topic data: |
7ms |
get first new msg: |
4ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 312ms |
| 0 / 0 |
