|
|
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
В некотором учреждении есть 10 очередей. В каждой очереди народ прет с разной интенсивностью. Каждый чувак из очереди получает случайный номер (распределение случайное, равномерное, датчики случайных чисел независимые, не один датчик, а 10) от 1 до 20 и идет к оператору с соответствующим номером. Будут ли кассиры загружены равномерно? Вот в чем вопрос. Как доказать или опровергнуть с точки зрения математики? На практике: Мне нужно чтобы таблицы росли более-менее одинаково, не более того. Я просто хочу журнал регистрации изменений разбить на 10 таблиц, а чтобы определять, в какой писать, хочу заюзать такую схему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2008, 19:34 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
FixinБудут ли кассиры загружены равномерно? Думаю, что да. Ведь ни у одного из кассиров нет преимущества перед другими, поскольку номера [1-20] равновероятны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2008, 19:44 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
FixinВ некотором учреждении есть 10 очередей. В каждой очереди народ прет с разной интенсивностью. Каждый чувак из очереди получает случайный номер (распределение случайное, равномерное, датчики случайных чисел независимые, не один датчик, а 10) от 1 до 20 и идет к оператору с соответствующим номером. Будут ли кассиры загружены равномерно? Вот в чем вопрос.Да. И это не зависит от количества датчиков случайных чисел, будь их один на всю систему или один на каждое получение номера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2008, 19:54 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
FixinЯ просто хочу журнал регистрации изменений разбить на 10 таблиц, а чтобы определять, в какой писать, хочу заюзать такую схему.Что такое "журнал"? Это таблица? Зачем нужно разбивать его на 10 таблиц? И зачем для этого использовать генератор случайных чисел? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2008, 19:58 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
FixinЯ просто хочу журнал регистрации изменений разбить на 10 таблиц, а чтобы определять, в какой писать, хочу заюзать такую схему. Звучит как вещь, которую вряд ли хоть когда-нибудь нужно делать. Случайные числа тут в любом случае не в кассу. Берите задачу в том виде, в котором она есть, без "аналогий", и пишите ее в форум по используемой СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2008, 20:43 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
softwarer FixinЯ просто хочу журнал регистрации изменений разбить на 10 таблиц, а чтобы определять, в какой писать, хочу заюзать такую схему. Звучит как вещь, которую вряд ли хоть когда-нибудь нужно делать. Случайные числа тут в любом случае не в кассу. Берите задачу в том виде, в котором она есть, без "аналогий", и пишите ее в форум по используемой СУБД. Объясняю еще раз популярно: Есть 10 таблиц одинаковой структуры (1С). В них я регистрирую изменения, производимые в других таблицах - так надо, потому что так меньше блокировок. Нужно, чтобы число записей в этих таблицах было примерно одинаковым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2008, 21:07 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
FixinВ них я регистрирую изменения, производимые в других таблицах - так надо, потому что так меньше блокировок.А вы уверены, что даст прирост производительности? Ведь других ресурсов это потребует не меньше, а часто и больше, чем в случае с одной таблицей. Какого характера эти блокировки? FixinНужно, чтобы число записей в этих таблицах было примерно одинаковым.Для этого необязательно использовать генератор случайных чисел (который в большинстве реализаций относительно медленный), а можно, например, опираться на входящие данные. Например на идентификатор изменения. Тогда таблицу, в которую нужно вставить запись, можно будет определить по остатку от деления на 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2008, 22:16 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
Пожалуй это самый странный подход к performance tunning. Я-бы для начала почитал документацию по RDBMS. Я уверен что есть методики уменьшения влияния блокировки на другие процессы. Может сегментация. Может - смена режима блокировки табличная/строчна. Может - увеличение скорости самой операции, которая требует блокирования. В некоторых случаях можно использовать пакетную вставку, если бизнес-логика не требует постоянного commit на каждую операцию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2008, 14:38 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
А что, нельзя использовать простой циклический счетчик для этих очередей? Т.е. подходит один человек-ему номерок 1, второму(возможно из другой очереди) номерок 2 и т.д? 21 в любой очереди получает номер 1. Каждый день можно циклически сдвигать счетчик на 1, чтобы не было увеличения нагрузок операторов в зависимости от номера. Имхо где-то так, либо я неправильно понял постановку вопроса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2008, 18:49 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
Fixin Объясняю еще раз популярно: Есть 10 таблиц одинаковой структуры (1С). В них я регистрирую изменения, производимые в других таблицах - так надо, потому что так меньше блокировок. Нужно, чтобы число записей в этих таблицах было примерно одинаковым. Тогда у Вас неудачное решение. Нужно Выбирать свободную таблицу а не случайную. По поводу блокировок в 1с в 99% случаев достаточно переписать проседуру ПриПроведении и удалить оттудова никому не нужные (именно при проведении а не при сохранении) проверки типа ВыбранЛиСчет() ВыбранЛиПоставщик и еще 90% процедуры припрведении() из стандартной конфигурации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2008, 19:16 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
zloy denА что, нельзя использовать простой циклический счетчик для этих очередей? Т.е. подходит один человек-ему номерок 1, второму(возможно из другой очереди) номерок 2 и т.д? 21 в любой очереди получает номер 1. Каждый день можно циклически сдвигать счетчик на 1, чтобы не было увеличения нагрузок операторов в зависимости от номера. Имхо где-то так, либо я неправильно понял постановку вопроса Еще раз повторяю прикладной характер задачи. Если в модуле объектов в процедуре перед записью выбирать одну из 20 таблиц одинаковой структуры для записи версии изменяемого объекта, будут ли таблицы расти одинаково или нет. Специально переформулировал таск для тупых 1сников. Видите ли, в процедуре перед записью я не могу знать, к каким другим таблицам обращаются другие процессы, если за этим следить, это вызовет еще одну блокировку. А суть в том, что 10 таблиц меньше блокируют друг друга, чем одна! ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2008, 03:17 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
Еще более простая формулировка - хочу использовать журнал регистрации объектов, но разбить его на 10 таблиц. Нужен такой диспетчер, чтобы таблицы росли одинаково. Вариант со случайными числами идеален, ибо не требует сравнения числа записей между собой и т.п., т.е. при записи не будет тратиться лишнее время на координацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2008, 11:07 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
FixinЕще более простая формулировка - хочу использовать журнал регистрации объектов, но разбить его на 10 таблиц. Нужен такой диспетчер, чтобы таблицы росли одинаково. Вариант со случайными числами идеален, ибо не требует сравнения числа записей между собой и т.п., т.е. при записи не будет тратиться лишнее время на координацию. С точки зрения вероятностных процессов Вы даете не более простые а всегда принципиально разные задачи. По поводу блокировок. Задайтесь вопросом, какова вероятность того, что шесть бросаний кубика приведут к тому что каждое бросание даст разные номера в пределах от 1 до 6. Это Ваша вторая формулировка. Ваша первая формулировка формулирует другую задачу, которая отличается второй формулировки, и в которой не хватает информации для ее решения. Ну а последняя формулировка - да таблицы будут расти относительно равномерно. Но к блокировкам это уже не имеет отношения. Скорее, к качеству генератора случайных чисел. Тут Вам предложили нормальный вариант. Сделать глобальный циклический счетчик и его наращивать. Вы же хотите, чтобы Вам подтвердили Ваше не имеющее отношение ни к математике ни к жизни решение. Не даю Вам такого подтверждения. Плохое решение. Тупое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2008, 12:41 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
apapacyкакова вероятность того, что шесть бросаний кубика приведут к тому что каждое бросание даст разные номера в пределах от 1 до 6. Примерно 1,543% ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2008, 20:18 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
А вообще обычно в таком простом случае как таблицо под журнал, параллельные вставки друг друга не блокируют - они просто лочат непересекающиеся первичные ключи. Вам стоило бы проверить - не боретесь ли вы с несуществующей проблемой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2008, 20:33 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
Да там у него 1с. Если 8-ка то конечно проблем нет. Но может 7-ка. Тогда при проведении могут быть задержки. Хохма в том что на 20 операторов он предлагает 10 таблиц. Ну где 10 (само по себе абсурд) там уж и 20 таблиц прекрасно уживутся. Если уж так хочется показать свои "оптимизаторские" способности - закрепил бы за каждой таблицей по 2 оператора. Фактически тот же генератор случайных чисел, только более надежный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2008, 20:54 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
Я конечно не математик но как помню случайные числа генерируются с "нормальным распределением", а его график выглядит как парабола. Т.е. если числа генерируются в диапазоне от 1 до 100 то числа по середине будут выпадать большее количество раз. Следовательно таблицы с такими индексами будут больше заполнены. Или нужно искать другое распределение. Нормальное распределение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2008, 23:37 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
ekochnevЯ конечно не математик но как помню случайные числа генерируются с "нормальным распределением", Кем именно? Конечно, если сделать аппаратный датчик на основе какого-либо физического процесса, оно будет именно так, но таким оборудованием обычные сервера не комплектуются. ekochnevТ.е. если числа генерируются в диапазоне от 1 до 100 то числа по середине будут выпадать большее количество раз. Сугубо для информации: превратить датчик с известным распределением в датчик с нужным распределением - задачка на пару минут для сообразительного второкурсника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2008, 00:39 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
ekochnevЯ конечно не математик но как помню случайные числа генерируются с "нормальным распределением" Это не так, обычно ГСЧ распределены равномерно. Гаусс будет, если сложить кучу равномерных величин ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2008, 09:26 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
apapacy Сделать глобальный циклический счетчик и его наращивать. Вы же хотите, чтобы Вам подтвердили Ваше не имеющее отношение ни к математике ни к жизни решение. Не даю Вам такого подтверждения. Плохое решение. Тупое. Видите ли, технические ограничения платформы 1с не позволяют сделать глобальный циклический счетчик. Если реализовывать его через константы, то будет очередь на блокировку этой константы, т.е. счетчик станет узким местом. Я вам не сообщил об этой особенности платформы, имейте ее ввиду. Каждый процесс управляет только своими переменными в памяти, для синхронизации можно использовать только записанные в базу данных значения, которые может считать другой процесс. Т.е. введение такого хранимого в базе данных счетчика ведет как к блокировкам этого счетчика, так и к излишнему дерганию базы данных постоянно для считывания и записи этого счетчика. Еще худшее решение, чем мое! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2008, 11:26 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
apapacyДа там у него 1с. Если 8-ка то конечно проблем нет. Но может 7-ка. Тогда при проведении могут быть задержки. Хохма в том что на 20 операторов он предлагает 10 таблиц. Ну где 10 (само по себе абсурд) там уж и 20 таблиц прекрасно уживутся. Если уж так хочется показать свои "оптимизаторские" способности - закрепил бы за каждой таблицей по 2 оператора. Фактически тот же генератор случайных чисел, только более надежный. Числа я привел условно. У каждого пользователя разная производительность и это будет вести к тому, что таблицы будут расти неравномерно, а значит в некоторые таблицы запись будет вестись чаще, чем в другие, что может вызвать блокировки. По любому в одну таблицу будут писать данные несколько пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2008, 11:28 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
Чорный БадаА вообще обычно в таком простом случае как таблицо под журнал, параллельные вставки друг друга не блокируют - они просто лочат непересекающиеся первичные ключи. Вам стоило бы проверить - не боретесь ли вы с несуществующей проблемой. В файловой версии таблица блокируется целиком. В SQL - надо подумать. ;-) Возможно, вы высказали здравую мысль. Хотя в любом случае, размер индекса для одной большой и 10 маленьких таблиц разный - скорость поиска соответственно тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2008, 11:30 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
miksoft FixinВ некотором учреждении есть 10 очередей. В каждой очереди народ прет с разной интенсивностью. Каждый чувак из очереди получает случайный номер (распределение случайное, равномерное, датчики случайных чисел независимые, не один датчик, а 10) от 1 до 20 и идет к оператору с соответствующим номером. Будут ли кассиры загружены равномерно? Вот в чем вопрос.Да. И это не зависит от количества датчиков случайных чисел, будь их один на всю систему или один на каждое получение номера. А затраты кассира на клиента не учитываются? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2008, 12:49 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
Николай1[А затраты кассира на клиента не учитываются? Мдя, вот что поисходит, когда используют неверные аналогии... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2008, 12:54 |
|
||
|
10 очередей, 20 операторов.
|
|||
|---|---|---|---|
|
#18+
FixinХотя в любом случае, размер индекса для одной большой и 10 маленьких таблиц разный - скорость поиска соответственно тоже. А причем здесь индексы? Насколько я знаю, компаундные индексы Dbase (а именно они используются в файл-серверной версии 1С) - это бинарное дерево, посему строятся методом "половинного деления", так что увеличение базы в два раза приводит только к одному дополнительному шагу при поиске... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2008, 18:25 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=35537550&tid=1344940]: |
0ms |
get settings: |
5ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
176ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 203ms |
| total: | 474ms |

| 0 / 0 |
