Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5]      все
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 11038
Дегтярев Евгений
сделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей



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

едва ли критерии распределения тасков по разным типов воркеров менются часто
22 фев 19, 14:21    [21817313]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6285
Arioch
Старый плюшевый мишка
IBExpert внизу, вместе со временем выполнения, показывает пресловутый план


там ещё статистика чтений показываетсЯ, сколько с диска и сколько с кэша в памяти

особенно еслди сравнить один и тот же запрос по холодному и по горячему

вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше

MSSQL "жует" _многостраничные_ _автогенерируемые_ запросы 1С, например.

А вы тут к каждому индексу цепляетесь.... =)
22 фев 19, 14:41    [21817343]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
pastor
Member

Откуда: Калуга
Сообщений: 1032
Siemargl
Arioch
пропущено...


там ещё статистика чтений показываетсЯ, сколько с диска и сколько с кэша в памяти

особенно еслди сравнить один и тот же запрос по холодному и по горячему

вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше

MSSQL "жует" _многостраничные_ _автогенерируемые_ запросы 1С, например.

А вы тут к каждому индексу цепляетесь.... =)


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

Для по-настоящему больших задач все равно динозавры-оракулы.
Наша ниша - маленькие теплокровные млекопитающие(ся).
22 фев 19, 15:19    [21817383]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Фэйтл Эра
Member

Откуда:
Сообщений: 627
Siemargl
MSSQL "жует" _многостраничные_ _автогенерируемые_ запросы 1С, например.

А вы тут к каждому индексу цепляетесь.... =)

К сожалению, там те же проблемы. Оптимизатор конкретной СУБД (MS SQL, DB2, PostgrSQL), используемой совместно с 1С, тоже строит планы по схожим принципам. Просто разработчики 1С более тщательно, чем Вы, подходят к вопросу генерации запросов.
И все равно, иногда приходится работать ручками, об этом много написано, например: http://www.gilev.ru/optimquery/
http://www.gilev.ru/index/

Чудо-СУБД не существует.
22 фев 19, 16:22    [21817459]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1690
Arioch
Дегтярев Евгений
сделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей

....а если таски настолько разные, что полей надо мноооого и узко не получается

хрень если так, очень даже хрень
на до даже в этом случае есть решение

зы
сорри за резкость, в сибири пятница празднуется во всю
22 фев 19, 17:58    [21817536]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 130
Дегтярев Евгений
Molochnik
Смысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись.

сделайте один поток, ответственный за распределение заданий из очереди

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

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

оставим тему про дублирование, я понял что для вас значит усложнение...

Опять вернулся к этой задаче и к вашему методу решения. Интересно что у меня примерно так раньше (лет 10 назад) так и работало, когда один поток лазил в базу и создавал очередь заданий в памяти (кэш), к которой уже обращались потоки обработчики, не лазящие в базу. Потом я бросил этот способ, поскольку:
1) кэш иногда переполнялся, если ни одному потоку не нужна была запись долгое время (а может и не вовсе не пригодилась бы),
2) приходилось отслеживать его актуальность, если таблица менялась сторонней программой,
3) иногда нужной записи не было в кэше и поток простаивал.
Все это конечно решалось, но выглядело сложно и уродливо, и я бросил этот способ в пользу теперешней схемы. Если рассматривать вариант без кэша, когда данные берутся из таблицы только когда они реально нужны (онлайн), то в чем тогда преимущество одного потока перед несколькими потоками, работающими через критическую секцию? В оверхеде работы критической секции? Это разве не "ловля блох"? Хотя потоков может быть и штук двести.
28 мар 19, 00:18    [21845559]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1690
Molochnik
3) иногда нужной записи не было в кэше и поток простаивал

он так и так будет простаивать, только в вашем случае он будет постоянно долбить БД тяжелым запросом, который ничего не возвращает.

Molochnik
Если рассматривать вариант без кэша, когда данные берутся из таблицы только когда они реально нужны (онлайн), то в чем тогда преимущество одного потока перед несколькими потоками, работающими через критическую секцию? В оверхеде работы критической секции? Это разве не "ловля блох"? Хотя потоков может быть и штук двести.

какая выгода, если если все будет упираться во время запроса к БД?
я повторюсь, сложно судить не зная деталей

зы
почему топил за такой вариант
один из примеров, есть задача - раздача экономических новостей клиентам по вебсокету
данные в памяти, несколько фидов, в каждом по несколько тыс записей, в общей сложности около 50т
одни поток раз в секунду читает из новые записи БД с банальным условием where id > lastId
далее уже в сервисе решается к какому фиду относится новость, какому клиенту ее отправить (у каждого свои фильтры)
данные в памяти позволяют обслуживать запросы чтение отдельных новостей или списков с пагинацией, с учетом фильтров и пр требований за микросекунды, для клиента время обработки запроса = времени пинга
в моем случае это еще и легко масштабируется без масштабирования БД

зызы
мне кажется, что в вашем случае при удачной организации структуры таблиц и индексов можно решить задачу на уровне бд
28 мар 19, 09:55    [21845762]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5]      все
Все форумы / Firebird, InterBase Ответить