ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Нужен совет. Частота запросов к базе. Производительность
49 сообщений из 49, показаны все 2 страниц
  все  
Нужен совет. Частота запросов к базе. Производительность
    #39288209
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
День добрый.

Нужен совет, информация.
Делаю проект, в котором необходимо максимально обеспечить актуальность отображаемых данных во времени. Серверная часть - ФБ 2.5 SuperClassic
- создаётся заказ на стороне клиента. пишется в базу (статус "создано")
- у операторов с частотой (желательно раз в секунду) обновляется список созданных заказов
- оператор принимает заказ, по мере обработки меняет статусы ("принято", "в работе", "готово"). Промежуток между "принято" и "готово" - около 5 минут.
- статусы аналогично актуально отображаются клиенту
- забирает заказ - статус "выполено"

Думаю сделать общую таблицу заказов и плюс к ней - вспомогательную таблицу только актуальных заказов - в ней будут только статусы "создано", "принято", "в работе", "готово"

как ведёт себя ФБ при такой частоте запросов ?

PS: в начале рабочей сессии будет запускаться принудительный сборщик мусора.
...
Рейтинг: 0 / 0
08.08.2016, 12:17
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288221
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
fankhmНужен совет
Делай трёхзвенку или отдельный сервер рассылки изменений по push-технологии. Прикручивать
pull при таких условиях - бесперспективняк.

Рассматривай свою задачу как online-MMORPG.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.08.2016, 12:27
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288230
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Dimitry Sibiryakov,

т.е. не потянет частые запросы ?
клиентских мест - до 5-ти (т.е. 5 возможных одновременных заказа)
операторских - до 10-ти
это в будущем, вначале 1 клиентское и 2 операторских.
...
Рейтинг: 0 / 0
08.08.2016, 12:35
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288235
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
fankhmт.е. не потянет частые запросы ?
Потянет, но это совершенно криво и бессмысленно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.08.2016, 12:44
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288364
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
fankhmDimitry Sibiryakov,

т.е. не потянет частые запросы ?
клиентских мест - до 5-ти (т.е. 5 возможных одновременных заказа)
операторских - до 10-ти
это в будущем, вначале 1 клиентское и 2 операторских.Потянет, даже если к твоим исходным данным нолик дописать, хотя конечно это будет увлекательный танец по граблям. Но, как сказал Dimitry Sibiryakov, "сервер рассылки изменений по push-технологии" будет гораздо изящнее.
...
Рейтинг: 0 / 0
08.08.2016, 15:13
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288569
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Andrey_fankhmDimitry Sibiryakov,

т.е. не потянет частые запросы ?
клиентских мест - до 5-ти (т.е. 5 возможных одновременных заказа)
операторских - до 10-ти
это в будущем, вначале 1 клиентское и 2 операторских.Потянет, даже если к твоим исходным данным нолик дописать, хотя конечно это будет увлекательный танец по граблям. Но, как сказал Dimitry Sibiryakov, "сервер рассылки изменений по push-технологии" будет гораздо изящнее.

почитал про "технология Push".

Технология Push — один из способов распространения информации (контента),
когда данные поступают от поставщика к пользователю на основе установленных
параметров. Пользователь же в свою очередь либо отвергает, либо принимает данные.

Противоположностью Push-технологии является технология Pull, где запрос инициирует
клиентское программное обеспечение.

не понял как её реализовать в моём случае ?
на каких принципах и какими инструментами ?

надо поднимать сервер - чего ? (POP3, SMTP, IRC, NetSend)
синхронизировать его с работой клиентов и операторов.
ещё одно звено - минус в надёжности, я так думаю...

если можно - объясните про "сервер рассылки изменений по push-технологии" - принцип работы и инструментарий. везде только описание конечного результата "всплывающие информационные плашки", а как информация туда попала ?
...
Рейтинг: 0 / 0
08.08.2016, 20:27
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288570
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Andrey_,

про "будет увлекательный танец по граблям" тоже не очень понятно. если работает чётко по транзакциям, в чём может быть проблема ?

я вижу только проблему в сборе "мусора" и обновлении статистики индексов, но это обычное, знакомое и предсказуемое.
...
Рейтинг: 0 / 0
08.08.2016, 20:30
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288572
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
fankhmа как информация туда попала ?
С сервера. Любым подходящим способом. Обычно - через TCP.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.08.2016, 20:36
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288573
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
хотя конечно можно сделать этот push просто на сокетах... когда-то чат делал на ICS компонентах

или есть что-то уже стандартизированное и обкатанное ?
...
Рейтинг: 0 / 0
08.08.2016, 20:38
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288584
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Раз чат делал, значит он у тебя уже обкатан. Кого волнуют стандарты?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.08.2016, 21:08
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288595
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
afgm
Участник
fankhmне понял как её реализовать в моём случае ?
на каких принципах и какими инструментами ?
Посмотри Redis Pub/Sub
...
Рейтинг: 0 / 0
08.08.2016, 22:20
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288605
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
fankhm,

такси, что-ли? если да, то на ФБ их полно. И обсуждение кое-каких аспектов было тут несколько лет назад.

fankhmв начале рабочей сессии будет запускаться принудительный сборщик мусора.
такая фраза настораживает, потому что версии обычно накапливаются из-за длинных транзакций (не read read committed), а в этом случае "сборщики мусора" бесполезны.
Нужно будет смотреть на результат многопользовательской работы такой системы, и уже ПОТОМ либо чинить длинные транзакции, либо ... не беспокоиться о мусоре.
...
Рейтинг: 0 / 0
08.08.2016, 23:11
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288633
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
kdvfankhm,

такси, что-ли? если да, то на ФБ их полно. И обсуждение кое-каких аспектов было тут несколько лет назад.

fankhmв начале рабочей сессии будет запускаться принудительный сборщик мусора.
такая фраза настораживает, потому что версии обычно накапливаются из-за длинных транзакций (не read read committed), а в этом случае "сборщики мусора" бесполезны.
Нужно будет смотреть на результат многопользовательской работы такой системы, и уже ПОТОМ либо чинить длинные транзакции, либо ... не беспокоиться о мусоре.

нет. не такси. что-то вроде фастфуда

версии будут накапливаться из-за большого числа вставок/удалений в одной таблице, см. первый пост - "Думаю сделать общую таблицу заказов и плюс к ней - вспомогательную таблицу только актуальных заказов - в ней будут только статусы "создано", "принято", "в работе", "готово".
Заказы. Статусы. Из этого формируется очередь. Вот "живую очередь" думаю вывести/продублировать в отдельную таблицу для скорости запроса. Но из-за того, что там будет постоянно вставка/удаление - будут накапливаться версии. Которые периодически будут "собираться". Где-то так.
...
Рейтинг: 0 / 0
09.08.2016, 02:03
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288678
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
fankhmнет. не такси. что-то вроде фастфуда

версии будут накапливаться из-за большого числа вставок/удалений в одной таблице, см. первый пост - "Думаю сделать общую таблицу заказов и плюс к ней - вспомогательную таблицу только актуальных заказов - в ней будут только статусы "создано", "принято", "в работе", "готово".
Заказы. Статусы. Из этого формируется очередь. Вот "живую очередь" думаю вывести/продублировать в отдельную таблицу для скорости запроса. Но из-за того, что там будет постоянно вставка/удаление - будут накапливаться версии. Которые периодически будут "собираться". Где-то так.
Вам таблица не нужна. Сделайте сервис и храните актуальные заказы в памяти. При подъеме сервиса считывайте актуальную заказы и оповещайте этот сервис об их изменении.
...
Рейтинг: 0 / 0
09.08.2016, 08:30
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288691
MikeDD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MikeDD
Участник
fankhmнет. не такси. что-то вроде фастфуда

Думается вам нужно пересмотреть постановку ТЗ. Вы имеете дело не с бездушными железками, которые беспрерывно хреначат данные, а с людьми. Какой смысл опрашивать очередь раз в секунду если как я понимаю заказ клиент получит не раньше чем через 5 минут? Кроме того поступившие заказы обрабатывают тоже люди. Они же не просто тупо меняют статус заказа с "принято" на "в работе" а еще чего-то делают? А это значит что следующий поступивший заказ все равно не будет обработан до тех пор пока оператор не разделается с предыдущим.
...
Рейтинг: 0 / 0
09.08.2016, 09:10
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288695
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
MikeDDfankhmнет. не такси. что-то вроде фастфуда

Думается вам нужно пересмотреть постановку ТЗ. Вы имеете дело не с бездушными железками, которые беспрерывно хреначат данные, а с людьми. Какой смысл опрашивать очередь раз в секунду если как я понимаю заказ клиент получит не раньше чем через 5 минут? Кроме того поступившие заказы обрабатывают тоже люди. Они же не просто тупо меняют статус заказа с "принято" на "в работе" а еще чего-то делают? А это значит что следующий поступивший заказ все равно не будет обработан до тех пор пока оператор не разделается с предыдущим.
Видимо количеством заказов небольшое. И основное время занимает не заполнение заказов, а простой менеджера до следующего заказа.
...
Рейтинг: 0 / 0
09.08.2016, 09:18
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288697
MikeDD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MikeDD
Участник
Хнык, время выполнения заказа больше в десятки раз. Какой смысл ловить блох в ПО если 99% времени ожидания заказа клиентом приходится на кухню?
...
Рейтинг: 0 / 0
09.08.2016, 09:23
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288705
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
MikeDDХнык, время выполнения заказа больше в десятки раз. Какой смысл ловить блох в ПО если 99% времени ожидания заказа клиентом приходится на кухню?
Возможно, заказчик одним из плюсов автоматизации видит уменьшение простоя менеджеров. Если цикл заказа пять минут, то простой в две минуты может быть довольно ощутимым.
...
Рейтинг: 0 / 0
09.08.2016, 09:35
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288711
MikeDD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MikeDD
Участник
Хнык, но ТС ведь гоняется за секундами! На мой взгляд на общее время выполнения заказа существенно не увеличится если период опроса очереди будет не 1 секунда а к примеру 5.
...
Рейтинг: 0 / 0
09.08.2016, 09:47
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288715
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
MikeDDХнык, но ТС ведь гоняется за секундами! На мой взгляд на общее время выполнения заказа существенно не увеличится если период опроса очереди будет не 1 секунда а к примеру 5.
Что секунда, что пять, какая разница на таком количество операторов? Зато нет видимой задержки между попаданием заказа в очередь и оповещением менеджера. Заказчик будет доволен осознавая, что приложение не тратить ни одной лишней секунды его денег.
...
Рейтинг: 0 / 0
09.08.2016, 09:53
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288721
MikeDD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MikeDD
Участник
Хнык, кстати а сколько заказов поступает в минуту? Ведь на то, чтобы заказать еду пусть и в фастфуде тоже уходит время. Я сильно сомневаюсь что количество заказов будет измеряться сотнями в минуту. На деле в лучшем случае их будут десятки в минуту. Тогда спрашивается нафига городить всю эту реалтайм фигню если с этим легко справится post_event?
Я к чему все это - требования к ПО должны идти не с потолка а строго из предметной области. Ну и делать с запасом раза в 2-3 на случай роста бизнеса. Все остальное - пустая трата времени.
...
Рейтинг: 0 / 0
09.08.2016, 10:03
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288740
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
MikeDDХнык, кстати а сколько заказов поступает в минуту? Ведь на то, чтобы заказать еду пусть и в фастфуде тоже уходит время. Я сильно сомневаюсь что количество заказов будет измеряться сотнями в минуту.
Скорее всего, есть пики, когда ваш подход оправдан, т.е. количество заказов столько, что с ними не справляются и оперативное обновление очереди никому не интересно (если честно, странно обновлять для оператора очередь, если он оформляет заказ). В остальных случаях, если операторы успевают разбирать очередь и количество заказов в день, скажем, 500, лишние 5 секунд превращаются в 2500 секунд во время которых оператор ничего не делает, а только напряжённо всматривается в экран, к примеру.
...
Рейтинг: 0 / 0
09.08.2016, 10:24
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288781
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Хныклишние 5 секунд превращаются в 2500 секунд во время которых оператор ничего не делает, а
только напряжённо всматривается в экран, к примеру.

Как давно Вы последний раз вглядывались в экран своего сотового, ожидая когда кто-нибудь
выйдет на связь? Звонок к телефону прикрутили ещё два века назад. Закипающий чайник
оснастили свистком и то гораздо позже.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.08.2016, 11:28
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288783
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
Dimitry SibiryakovХныклишние 5 секунд превращаются в 2500 секунд во время которых оператор ничего не делает, а
только напряжённо всматривается в экран, к примеру.

Как давно Вы последний раз вглядывались в экран своего сотового, ожидая когда кто-нибудь
выйдет на связь? Звонок к телефону прикрутили ещё два века назад. Закипающий чайник
оснастили свистком и то гораздо позже.

Я думаю, если вам в качестве мелодии телефона поставить вашу любимую музыку и звонить по 100 раз в день, вы довольно скоро перейдёте на беззвучный режим и только иногда будете читать смс-ки о пропущенных звонках.
...
Рейтинг: 0 / 0
09.08.2016, 11:32
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288798
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Хныки только иногда будете читать смс-ки о пропущенных звонках.
дык. Собственно, задача "магазина с экраном о заказах в онлайне", такси, фастфуда, обменников, и прочего, решается двумя способами, про которые тут уже сказали
1. Pull. Клиент дергает сервер с определенным интервалом (раз в 1-5 секунд) - "нет-ли чего нового?". И если есть, верещит об этом пользователю программы.
Проблемы начинаются когда таких клиентов 5, 10 и больше. То есть, начинается конкуренция за ресурс, даже по чтению. И для Firebird это выливается в большое количество read locks (страниц) и соответственно высокий mutex wait в выводе fb_lock_print.
Система тормозит, при этом толком нихрена не делая.
(один из типичных примеров - "календарь событий" в организациях. Утром толпы сотрудников запускают приложение, которое им всем открывает календарь (одну и ту же таблицу), и ...).

2. Push. Когда сам сервер сообщает клиенту о некоем событии. ФБ имеет механизм post_event. Однако, вероятно, лучше сделать трехзвенку, которая сама будет "более умно" сообщать клиентам о происходящих событиях (как минимум, в post_event нет масок событий, регистрируются только конкретные события по имени).

Дальше, в примере со звонками, уже проблема частоты push. Например, на мобиле gmail синхронизируется с сервером через заданные интервалы времени. Яндекс-почта наоборот, уведомляет о каждом новом письме, что невероятно раздражает.
Та же фигня с уведомлениями соц-сетей. Якобы фэйсбуковое приложение (да и OK) лепит отдельные уведомления на каждый случай, что тоже невероятно раздражает. Другие умудряются как-то группировать уведомления. Но это уже вопрос важности событий для получателя. Понятно, что "группировка" ни для такси, ни для фастфуда не подойдет.
...
Рейтинг: 0 / 0
09.08.2016, 11:58
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288808
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
kdv,

Проще использовать первый вариант, т.к. во втором необходимо конфигурировать систему, описывая схему доступа до каждого из получателей.
Если волнуют блокировки, возможно, стоит использовать кеш, вместо обращения к базе данных.
...
Рейтинг: 0 / 0
09.08.2016, 12:07
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288819
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
fankhm,

у нас есть така фигня для тренеров/инструкторов

дергаем генератор с инкрементом 0. если значение с последнего раза поменялось - перечитываем все.
поскольку рисуется шахматка, строится очередь по приоритетам для инструкторов, то время от времени перересовываем и перечитываем все.

никакого гемора с трехзвенками, событиями и пр.

производительности - на 10 рабочих мест 100+ инструкторов 300+ занятий вполне достаточно

читается по фильтрам (окно ~ 100 позиций)
...
Рейтинг: 0 / 0
09.08.2016, 12:16
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288827
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
fankhmпочитал про "технология Push".

не понял как её реализовать в моём случае ?
Как-нибудь с помощью третьего звена :) И оно не обязательно должно быть между клиентом и СУБД. Это может быть сервис/служба/демон/консольное приложение/что угодно. Оно где-то висит, и слушает например сокет. В этот сокет пишут все твои "клиентские места" при создании заказа. Когда оно получает заказ, оно рассылает всем "операторским местам" информацию о новом заказе (через такой же сокет напримре). Это может быть только его ID (и тогда "операторские места" сами ломануться в базу и вычитать заказ) или полная информация по заказу (тогда операторским местам остается только отобразить его в интерфейсе).

Основная идея, это именно то что ты процитировал - сервер инициирует передачу данных клиенту, а не клиент по таймеру дергает сервер.

fankhmпро "будет увлекательный танец по граблям" тоже не очень понятно. если работает чётко по транзакциям, в чём может быть проблема ?

я вижу только проблему в сборе "мусора" и обновлении статистики индексов, но это обычное, знакомое и предсказуемое.Ивенты в FB не умеют быть параметризируемыми. То есть при добавлении нового заказа ты не сможешь его ID запихнуть в ивент и разослать всем операторам ивент "Читайте заказ с ID=:pID". В результате, для реализации оповещения операторов о новом заказе нужно или писать третье звено (как я описал выше) или городить страшный огород из таблиц логирования и тригеров на комит транзакции. Обычно второй вариант не рекомендуют т.к. он и есть тот самый "увлекательный танец по граблям".

И кстати, а как у тебя операторы будут между собой решать, кому достанется заказ? Если несколько свободных одновременно.
...
Рейтинг: 0 / 0
09.08.2016, 12:24
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288852
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
pastorесли значение с последнего раза поменялось - перечитываем все.
все перечитывать не обязательно. Иногда добавляют в таблицу столбец, в который при insert и update пишется значение генератора +1. И тогда можно выбрать все, что вставлялось или менялось с момента последнего получения генератора. Облом разве что с удалениями. Но в приличных системах данные не удаляют :-)
...
Рейтинг: 0 / 0
09.08.2016, 12:49
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288900
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
kdv,

Уважаемый Дима!

В этой предметной области перечитывать надо все.
Ибо.

1. Заказы добавляются/удаляются/изменяется фаза обслуживания/статус
2. Меняются приоритеты (очередь)
3. Несколько точек обслуживания. Коллизий нет, т.к. обслуживается клиент, стоящий перед мордой, а ресурс (инструктор) берется с первой успешно блокирующей попытки
3. Объем всего тащимого на клиента несоизмеримо меньше геморроя согласования частей.

У меня есть в голове готовая модель фастфуда, и я ее обязательно сделаю. С бесплатным вариантом на 2 точки.
...
Рейтинг: 0 / 0
09.08.2016, 13:41
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288931
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
pastorkdv,

Уважаемый Дима!

В этой предметной области перечитывать надо все.
Ибо.

1. Заказы добавляются/удаляются/изменяется фаза обслуживания/статус
2. Меняются приоритеты (очередь)
3. Несколько точек обслуживания. Коллизий нет, т.к. обслуживается клиент, стоящий перед мордой, а ресурс (инструктор) берется с первой успешно блокирующей попытки
3. Объем всего тащимого на клиента несоизмеримо меньше геморроя согласования частей.

У меня есть в голове готовая модель фастфуда, и я ее обязательно сделаю. С бесплатным вариантом на 2 точки.

ну где-то так я это и думаю.
"Третье звено" (оповещатель) - согласен, будет очень красиво и логично.
Но настройка и возможный проброс портов (если файрвол корпоративный, порт нестандартный, надо писать в главконтору что-зачем-почему), согласование и отлавливание рассогласования, причём это только для того, чтобы не перечитывать лишний раз таблицу, где будет максимум 100 записей.

Про генератор ещё не думал, спасибо за направление.
...
Рейтинг: 0 / 0
09.08.2016, 14:09
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288951
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
kdvpastorесли значение с последнего раза поменялось - перечитываем все.
все перечитывать не обязательно. Иногда добавляют в таблицу столбец, в который при insert и update пишется значение генератора +1. И тогда можно выбрать все, что вставлялось или менялось с момента последнего получения генератора. Облом разве что с удалениями. Но в приличных системах данные не удаляют :-)Еще облом, если пишущие транзакции разной длинны. Может сложится так, что транзакция обновившая поле флага еще не закомитилась. В результате, читающая транзакция эти обновления пропустит, а значение генератора последнего апдейта запомнит, и уже никогда не прочитает, что там обновила та длинная пишущая транзакция.
...
Рейтинг: 0 / 0
09.08.2016, 14:26
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288953
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Andrey_... или городить страшный огород из таблиц логирования и тригеров на комит транзакции. Обычно второй вариант не рекомендуют т.к. он и есть тот самый "увлекательный танец по граблям".


не могу понять про "страшный огород".
таблица Заказы с полем Текущий статус (меняется триггером).
Код: sql
1.
2.
3.
4.
Orders
OrdID integer PK
...
CurState integer FK



таблица Статусы Заказов (полная история Статусов Заказа)
Код: sql
1.
2.
3.
4.
5.
OrderStates
OSID integer PK
OrdID integer FK
StateID integer FK
OnDate timestamp



таблица Очереди (формируется триггером или процедурой при внесении в Статусы Заказов. Статус "принято", "в работе", "готово" - запись в Очереди, статус "выдано" - удаление из Очереди. т.е в Очереди только активные статусы)

Код: sql
1.
2.
3.
4.
5.
Queue
QID integer PK
OrdID integer FK
StateID integer FK
OnDate timestamp



в чём, кроме сбора "мусора", здесь может быть проблема ?

Andrey_И кстати, а как у тебя операторы будут между собой решать, кому достанется заказ? Если несколько свободных одновременно.
[/quot]

так же как в случае с "оповещателем" - кто первый нажал "Принять", тому и разворачивает на экран состав заказа для выполнения и фиксирует этого оператора в Исполнители.
Или здесь возможны какие-то варианты ?
...
Рейтинг: 0 / 0
09.08.2016, 14:28
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288968
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Andrey_Может сложится так, что транзакция обновившая поле флага еще не закомитилась.

Именно поэтому ивенты - надёжнее.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.08.2016, 14:43
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288974
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
Dimitry SibiryakovAndrey_Может сложится так, что транзакция обновившая поле флага еще не закомитилась.

Именно поэтому ивенты - надёжнее.


без эвентов - еще надежнее :)
...
Рейтинг: 0 / 0
09.08.2016, 14:49
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288988
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
fankhmне могу понять про "страшный огород".Пока у тебя заказов мало - ни в чем. Каждый раз вычитываешь все не закрытые, и всё ок. Но когда у тебя появятся предварительные заказы, сама таблица заказов разрастется с 10-15 полей до 100+, или произойдет другое "внеплановое" увеличение размера вычитываемого пакета данных, тогда ты захочешь читать только то что изменилось. А это уже приведет к логу изменений и тригеру на комит генерирующему ивент для операторов. Вот это те самые грабли, а если заказов мало - как реализовывать, это скорее эстетический вопрос.

fankhmAndrey_И кстати, а как у тебя операторы будут между собой решать, кому достанется заказ? Если несколько свободных одновременно.так же как в случае с "оповещателем" - кто первый нажал "Принять", тому и разворачивает на экран состав заказа для выполнения и фиксирует этого оператора в Исполнители.
Или здесь возможны какие-то варианты ?Если с сериализацией (холостой апдейт/select with lock/etc) делать, все будет ок. А вот если так как я думал в этом топике - могут быть нюансы.
...
Рейтинг: 0 / 0
09.08.2016, 15:02
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289236
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
fankhmтак же как в случае с "оповещателем" - кто первый нажал "Принять", тому и разворачивает на экран состав заказа для выполнения и фиксирует этого оператора в Исполнители.
Или здесь возможны какие-то варианты ?
А зачем, вообще, кнопка "Принять"? Если человек, закончил заказ, автоматично скидывайте ему новый. Если хочет пойти в туалет, к примеру, пусть отпускает заказ или, если его нет, переводит своё рабочее место в статус "неактивный". Это нормально масштабируется на любое количество заказов. Плюс, простенький отчёт со среднем временем оформления заказа покажет, кому в этом месяце премия, а кому - нет.
...
Рейтинг: 0 / 0
09.08.2016, 18:47
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289243
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
Для введения игрового элемента при переводе в режим "неактивный" пользователь пусть видит статистику по количеству своих оформленных заказов и топ-дня по заказам других операторов.
...
Рейтинг: 0 / 0
09.08.2016, 18:56
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289247
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Хныкfankhmтак же как в случае с "оповещателем" - кто первый нажал "Принять", тому и разворачивает на экран состав заказа для выполнения и фиксирует этого оператора в Исполнители.
Или здесь возможны какие-то варианты ?
А зачем, вообще, кнопка "Принять"? Если человек, закончил заказ, автоматично скидывайте ему новый. Если хочет пойти в туалет, к примеру, пусть отпускает заказ или, если его нет, переводит своё рабочее место в статус "неактивный". Это нормально масштабируется на любое количество заказов. Плюс, простенький отчёт со среднем временем оформления заказа покажет, кому в этом месяце премия, а кому - нет.

для отображения на табло информации о статусах заказов в очереди

клиент набрал заказ, подтвердил - статус "создано" с фиксацией времени создания - отображается у операторов и (ещё думают надо ли) на табло.

оператор принимает на себя заказ - статус "принято" с фиксацией начала времени приготовления и именем оператора - отображается на табло

оператор передал заказ на следующие стадии - статус "в работе" (можно совместить конечно с принято, посмотрим по логике) - отображается на табло

оператор запаковал заказ - статус "выполнено" - отображается на табло

клиент забрал заказ - статус "выдано" - нигде не отображается (удаляет из таблицы Очередь свою запись)
...
Рейтинг: 0 / 0
09.08.2016, 19:06
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289248
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Хныкпереводит своё рабочее место в статус "неактивный".

не успеет, система ему новый заказ уже всунет, как тоьлко он закроет предыдущий :-P
...
Рейтинг: 0 / 0
09.08.2016, 19:06
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289252
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
статус "в работе" скорее всего будет детализирован по процессам
...
Рейтинг: 0 / 0
09.08.2016, 19:08
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289253
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
fankhm,
Я понимаю. Проще сделать это автоматично и бить операторов, которые отбегают от компьютера, без нажатия спец-кнопки "Последний заказ".
...
Рейтинг: 0 / 0
09.08.2016, 19:08
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289254
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
AriochХныкпереводит своё рабочее место в статус "неактивный".

не успеет, система ему новый заказ уже всунет, как тоьлко он закроет предыдущий :-P
Оператор должен изъявлять своё желание перевести в режим "неактивный" до окончания заказа.
...
Рейтинг: 0 / 0
09.08.2016, 19:09
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289255
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
AriochХныкпереводит своё рабочее место в статус "неактивный".

не успеет, система ему новый заказ уже всунет, как тоьлко он закроет предыдущий :-P

в принципе - да - человеческий фактор.

обычный режим - просто список с номерами и временем заказа. оператор не может "взять" любую позицию, только крайнюю.

"взял" позицию - ему развернулось её детализация
...
Рейтинг: 0 / 0
09.08.2016, 19:10
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289257
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Хныкfankhm,
Я понимаю. Проще сделать это автоматично и бить операторов, которые отбегают от компьютера, без нажатия спец-кнопки "Последний заказ".

для это как раз "принято".
Взял заказ - делает.
Не взял - висит в очереди
...
Рейтинг: 0 / 0
09.08.2016, 19:11
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289260
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
fankhmХныкfankhm,
Я понимаю. Проще сделать это автоматично и бить операторов, которые отбегают от компьютера, без нажатия спец-кнопки "Последний заказ".

для это как раз "принято".
Взял заказ - делает.
Не взял - висит в очереди
Это ломает поток. Оператор должен бить заказы, пока не поймёт, что нужно сделать вынужденный перерыв. Подобная схема будет подталкивать операторов максимизировать периоды ввода заказов, что отлично себя покажет в пиковые часы нагрузки и будет держать в тонусе, после её спада.
...
Рейтинг: 0 / 0
09.08.2016, 19:15
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289262
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Хныкfankhmпропущено...


для это как раз "принято".
Взял заказ - делает.
Не взял - висит в очереди
Это ломает поток. Оператор должен бить заказы, пока не поймёт, что нужно сделать вынужденный перерыв. Подобная схема будет подталкивать операторов максимизировать периоды ввода заказов, что отлично себя покажет в пиковые часы нагрузки и будет держать в тонусе, после её спада.

гм... надо подумать... спасибо за мысль
...
Рейтинг: 0 / 0
09.08.2016, 19:17
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289362
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fraks
Участник
kdvpastorесли значение с последнего раза поменялось - перечитываем все.
все перечитывать не обязательно. Иногда добавляют в таблицу столбец, в который при insert и update пишется значение генератора +1. И тогда можно выбрать все, что вставлялось или менялось с момента последнего получения генератора. Облом разве что с удалениями. Но в приличных системах данные не удаляют :-)

Этот метод потенциально опасен пропуском новинок.
Если пишушая транзакция затянет коммит то клиент может посчитать что раз он уже получал записи с бОльшим значением этого автоинкремента - то более ранние запрашивать больше не нужно.

Вариант с просто проверкой изменился ли генератор - более достоверен и не надо тратиться на лишнее поле.
...
Рейтинг: 0 / 0
10.08.2016, 06:22
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39289372
Фотография Tonal
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tonal
Участник
Если отталкиваться от постановки в стартовом топике, то можно обойтись вовсе без FB.
Вполне хватит RabbitQM или какого другого менеджера очередей.
В этом случае FB можно использовать разве что как систему архивирования. :)

Ну а если рассматривать постановку от pastor 19520053 , то действительно FB - основной. А Rabbit-а можно как оповещатель прикрутить. :)
...
Рейтинг: 0 / 0
10.08.2016, 07:16
| Ответить | Цитировать | Написать  
49 сообщений из 49, показаны все 2 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Нужен совет. Частота запросов к базе. Производительность
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]