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

Откуда:
Сообщений: 81
Имеется многопотоковое дельфийское приложение, у каждого потока свое соединение к общей базе. Через Unidac может работать с Firebird и MS SQL. Каждый поток выполняет (регулярно и часто) одинаковый для всех сложный SELECT, и затем одинаковый для всех простой UPDATE, со своим набором параметров. При тестировании обнаружил, что с MS SQL программа работает быстро и реально многопотоково, а с Firebird выглядит так как будто каждый поток ждет когда до него дойдет очередь выполнять запрос, в итоге получается а разы медленнее чем с MS SQL. Тестировал на FB2.5 и FB3.0 со всеми архитектурами, ситуация примерно одинакова. В какую сторону смотреть? Не может же быть, что Firebird в разы хуже MS SQL.
17 фев 19, 23:50    [21812385]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Фэйтл Эра
Member

Откуда:
Сообщений: 630
Molochnik,

давай сюда тест, повторимый. Иначе о чем.
18 фев 19, 00:09    [21812414]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Поменять сообщение видимо нельзя, поэтому добавлю, что все запросы делаются через критическую секцию, т.е. фактически эти запросы к базе выполняются потоками по очереди, но это не мешает MS SQL обрабатывать их очень быстро в отличии от FB.
18 фев 19, 00:11    [21812416]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Фэйтл Эра
Member

Откуда:
Сообщений: 630
Molochnik,

набросать тест? А ты, не имея его исходников, начнешь угадывать, насколько он соответствует твоим задачам.
18 фев 19, 00:20    [21812425]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Фэйтл Эра
Molochnik,

давай сюда тест, повторимый. Иначе о чем.

Сильно много усилий придется потратить такой тест сделать, фактически надо с нуля тестовое приложение написать. Если без этого никак проще оставить как есть и не париться.
18 фев 19, 00:23    [21812429]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Фэйтл Эра
Member

Откуда:
Сообщений: 630
Molochnik
проще оставить как есть и не париться

Если допустимо не оптимизировать - не оптимизируй.
18 фев 19, 00:25    [21812430]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Фэйтл Эра
Molochnik
проще оставить как есть и не париться

Если допустимо не оптимизировать - не оптимизируй.

Наверное так и оставлю, в принципе работает, посмотрел как запрос выполняется в IBExpert, все вроде корректно, в плане куча джойнов и индексов, "natural" только один, в таблице где обычно 1-2 записи. Чтобы оптимизировать вероятно нужно будет сильно потрудиться. Не стоит игра свеч наверно.
18 фев 19, 00:33    [21812436]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 10195
Molochnik
При тестировании обнаружил, что с MS SQL программа работает быстро и реально многопотоково

Molochnik
все запросы делаются через критическую секцию, т.е. фактически эти запросы к базе выполняются потоками по очереди
Ты определись - "реально многопотоково" или таки "по очереди"
18 фев 19, 00:45    [21812440]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 10195
Molochnik
Каждый поток выполняет (регулярно и часто) одинаковый для всех сложный SELECT, и затем одинаковый для всех простой UPDATE, со своим набором параметров
А коммит - где ?
В MSSQL - автокоммит небось, а у FB нужно явно делать.
18 фев 19, 00:47    [21812442]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
hvlad
Ты определись - "реально многопотоково" или таки "по очереди"

Да, ошибся поправить вопрос уже было нельзя. с базой приложение работают фактически однопотоково. Просто визуально MS SQL работал намного быстрее и выглядело так, будто потоки выполняют запросы одновременно.
hvlad
А коммит - где ?
В MSSQL - автокоммит небось, а у FB нужно явно делать.

Нет все явно, для каждого потока две формальных транзакции, первый (SELECT) SQL выполняется в читающей, второй (UPDATE) - в пишущей. Для FB у читающей 'Params=read;wait;read_committed;rec_version', у пишущей 'Params=write;wait;read_committed;rec_version', читающая постоянная, пишущая - открывается, закрывается. Для MS SQl формально выглядит так же, транзакции без параметров. Зачем вообще две транзакции, если все равно запросы выполняются в критической секции? Потому что имеется еще другое приложение, которое тоже может работать с этими таблицами, но оно выполняет запросы вручную и в тесте не участвует.
18 фев 19, 06:29    [21812477]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Код в каждом потоке выглядит примерно так
    CriticalSection.Enter;
    try
        QuerySelect.Open;// read trasaction is already opened
        uniWriteTransaction.StartTransaction;
        try
          QueryUpdate.ExecSQL;
          uniWriteTransaction.Commit;
        except
          uniWriteTransaction.Rollback;
        end;
    finally
      CriticalSection.Leave;
    end;

SQL селект очень большой, упрощенно (уменьшено раза в 3, но суть ту же) выглядит так:
SELECT tbl1.*, tbl2.*, tbl3.*, tbl4.*, tbl5.*, tbl6.*, 
 CASE WHEN UseText=1 AND Text1<>'' AND Text1Done<>1 AND
  (:AllowedTexts='' OR Text1 LIKE :AllowedTexts) AND TextTypes1.Allow1=1 AND TextTypes1.Allow2=1 AND
  (TextCondition=:TextCondition OR Text1Count<MaxTextCount) THEN 1 ELSE 0 END ActualUseText1,
 CASE WHEN UseText=1 AND Text2<>'' AND Text2Done<>1 AND
  (:AllowedTexts='' OR Text2 LIKE :AllowedTexts) AND TextTypes1.Allow1=1 AND TextTypes1.Allow2=1 AND
  (TextCondition=:TextCondition OR Text2Count<MaxTextCount) THEN 1 ELSE 0 END ActualUseText2,
 CASE WHEN UseText=1 AND Text3<>'' AND Text3Done<>1 AND
  (:AllowedTexts='' OR Text3 LIKE :AllowedTexts) AND TextTypes1.Allow1=1 AND TextTypes1.Allow2=1 AND
  (TextCondition=:TextCondition OR Text3Count<MaxTextCount) THEN 1 ELSE 0 END ActualUseText3
FROM tbl1
LEFT JOIN tbl2 ON tbl1.UserId=tbl2.UserId
LEFT JOIN tbl3 ON tbl1.ContactId=tbl3.ContactId
LEFT JOIN tbl4 ON tbl1.ContactId=tbl4.ContactId
LEFT JOIN tbl5 ON tbl5.UserId=tbl2.UserId
LEFT JOIN tbl6 ON tbl1.TaskId=tbl6.TaskId
LEFT JOIN tbl7 ON tbl1.TaskId=tbl7.TaskId
LEFT JOIN tbl8 ON tbl1.TextId=tbl8.TextId
LEFT JOIN tbl9 ON tbl1.TextId=tbl9.TextId
WHERE Paused<>1 AND (DBType=0 OR DBType=2) AND ContactOn=1 AND 
TextMarked=0 AND NextDateTimeText<=CURRENT_TIMESTAMP AND
( (UseText=1 AND Text1<>'' AND Text1Done<>1 AND
  (:AllowedTexts='' OR Text1 LIKE :AllowedTexts) AND TextTypes1.Allow1=1 AND TextTypes1.Allow2=1 AND
  (TextCondition=:TextCondition OR Text1Count<MaxTextCount)) OR
  (UseText=1 AND Text2<>'' AND Text2Done<>1 AND TextTypes2.Allow1=1 AND TextTypes2.Allow2=1 AND
  (:AllowedTexts='' OR Text2 LIKE :AllowedTexts) AND
  (TextCondition=:TextCondition OR Text2Count<MaxTextCount)) OR
  (UseText=1 AND Text3<>'' AND Text3Done<>1 AND TextTypes3.Allow1=1 AND TextTypes3.Allow2=1 AND
  (:AllowedTexts='' OR Text3 LIKE :AllowedTexts) AND
  (TextCondition=:TextCondition OR Text3Count<MaxTextCount)) OR
  (UseNumber=1 AND Contacts.Number<>'' AND NumberDone<>1 AND
  (:AllowedTexts='' OR Contacts.Number LIKE :AllowedTexts) AND
  (TextCondition=:TextCondition OR NumberCount<MaxTextCount))) AND
(tbl4.LineTypeId IS NULL OR tbl4.LineTypeId=:LineTypeId) AND
StartDate<=CAST(CURRENT_TIMESTAMP AS DATE) AND EndDate>=CAST(CURRENT_TIMESTAMP AS DATE) AND
((RoundTheClock=1) OR 
((StartTime<=EndTime) AND (CAST(StartTime AS TIME)<=CAST(CURRENT_TIMESTAMP AS TIME)) AND (CAST(EndTime AS TIME)>=CAST(CURRENT_TIMESTAMP AS TIME))) OR
((StartTime>EndTime) AND ((CAST(StartTime AS TIME)<=CAST(CURRENT_TIMESTAMP AS TIME)) OR (CAST(EndTime AS TIME)>=CAST(CURRENT_TIMESTAMP AS TIME))))) AND
Done = -1 AND :UseType = 1
ORDER BY tbl1.Priority DESC, tbl2.Priority DESC, NextDateTimeText ASC
ROWS 1

SQL апдейт очень простой:
UPDATE tbl1 SET TextMarked=1
WHERE TextId=:TextId
18 фев 19, 07:54    [21812490]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Vlad F
Member

Откуда:
Сообщений: 701
Molochnik
Имеется многопотоковое дельфийское приложение, у каждого потока свое соединение к общей базе <..>.

Милый друг, ну а зачем же ты тогда критические секции в них запихал?
И что будет, если обращение к ним (секциям) просто закомментировать?
И если уж на то пошло, то мерить/сравнивать тебе надо, для начала, простое последовательное выполнение
тех запросов в цикле. Слелай циклы на тысячу итераций к каждому серверу (вот тебе саамый простой тест),
засеки время и озвучь результат.
18 фев 19, 08:28    [21812498]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Molochnik,

за такой SELECT надо руки отрывать, без относительно того на каком сервере это выполняется
18 фев 19, 08:32    [21812499]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Vlad F
Милый друг, ну а зачем же ты тогда критические секции в них запихал?

Смысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись.
Vlad F
И если уж на то пошло, то мерить/сравнивать тебе надо, для начала, простое последовательное выполнение
тех запросов в цикле. Слелай циклы на тысячу итераций к каждому серверу (вот тебе саамый простой тест),
засеки время и озвучь результат.

да, сделаю
18 фев 19, 08:34    [21812502]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Симонов Денис
Molochnik,
за такой SELECT надо руки отрывать, без относительно того на каком сервере это выполняется

И в чем кривость?
18 фев 19, 08:35    [21812503]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Molochnik
Зачем вообще две транзакции, если все равно запросы выполняются в критической секции? Потому что имеется еще другое приложение, которое тоже может работать с этими таблицами, но оно выполняет запросы вручную и в тесте не участвует
.

Это вообще феерический бред. Каким образом боком здесь вообще другое приложение работающее с теми же таблицаим?
18 фев 19, 08:42    [21812504]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Molochnik,

во всём, начиная от table.*, поля в where без уточнений к какой таблице относятся, 100500 условий фильтрации
18 фев 19, 08:46    [21812505]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Симонов Денис
Molochnik
Зачем вообще две транзакции, если все равно запросы выполняются в критической секции? Потому что имеется еще другое приложение, которое тоже может работать с этими таблицами, но оно выполняет запросы вручную и в тесте не участвует
.

Это вообще феерический бред. Каким образом боком здесь вообще другое приложение работающее с теми же таблицаим?

Никакого, я просто объяснил почему несмотря на критическую секцию здесь используются две транзакции а не одна
18 фев 19, 08:47    [21812506]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Симонов Денис
Molochnik,

во всём, начиная от table.*, поля в where без уточнений к какой таблице относятся, 100500 условий фильтрации

Поля используются практически все, их очень много, чтобы по отдельности выписывать. в WHERE поля без уточнения, согласен, но это косметика. Условий фильтрации много, ну и что? Все нужны.
18 фев 19, 08:49    [21812510]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Vlad F
Member

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

Select for update, с с оответствующей обработкой результатов возможного отлупа в потоках,
с тем чтобы они в подобной ситуации повторяли попытку поиска неиспользуемой записи?
Подумай над этим.
18 фев 19, 09:03    [21812516]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Vlad F
Select for update, с с оответствующей обработкой результатов возможного отлупа в потоках,
с тем чтобы они в подобной ситуации повторяли попытку поиска неиспользуемой записи?
Подумай над этим.

Этой конструкции нет в MS SQL поэтому я стараюсь такие не использовать. Также например не использую функцию IIF, потому что вплоть до 2008 года в MS SQL ее не было.
18 фев 19, 09:18    [21812528]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Vlad F
Member

Откуда:
Сообщений: 701
Molochnik,

Но case то был??
18 фев 19, 09:30    [21812538]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Vlad F
Molochnik,
Но case то был??

Да, как ни странно, case был. У меня сейчас совместимость вплоть до MS SQL 2000
18 фев 19, 09:37    [21812540]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Vlad F
Member

Откуда:
Сообщений: 701
Molochnik,

Это очень даже не странно, это стандарт.
18 фев 19, 09:43    [21812546]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Vlad F
Molochnik,
Это очень даже не странно, это стандарт.

Странно что в микрософте об этом знали :)
18 фев 19, 09:45    [21812549]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Molochnik
Никакого, я просто объяснил почему несмотря на критическую секцию здесь используются две транзакции а не одна


это как раз и есть чушь. Паттерн с использованием двух транзакций происходит от нежелания закрывать недофетченный курсор, при завершении единственной транзакции которая обновила запись. От наличия нескольких приложений работающих с теми же таблицами это никак не зависит.

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

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

> в WHERE поля без уточнения, согласен, но это косметика.

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

> Условий фильтрации много, ну и что? Все нужны.

Его наверняка можно упростить, пусть даже не для сервера, а для самого себя чтобы понимать проще было. ДА и не верю я что нельзя придумать чуть более прямую схему фильтрации.
18 фев 19, 09:48    [21812556]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Симонов Денис
это как раз и есть чушь. Паттерн с использованием двух транзакций происходит от нежелания закрывать недофетченный курсор, при завершении единственной транзакции которая обновила запись. От наличия нескольких приложений работающих с теми же таблицами это никак не зависит.

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

Симонов Денис
ну да. А то что это влияет на ширину резалтсета для сортировки конечно не думаем. Да и тащить по сети лишнее это конечно круто, она же жирная выдержит.

Для FB используется ROWS 1, для MS SQL - TOP 1. Увеличивать и так гигантский текст SQL перечислением нескольких десятков полей особо желания не было. Этот так важно?
Симонов Денис
Во-первых это потенциальные грабли, на которые со временем наступишь.

Это понятно
Симонов Денис
Его наверняка можно упростить, пусть даже не для сервера, а для самого себя чтобы понимать проще было. ДА и не верю я что нельзя придумать чуть более прямую схему фильтрации.

Сомнительно. Все условия разнородные, скорее всего упростить можно только уменьшив количество возможностей, чего не хотелось бы.
18 фев 19, 10:08    [21812568]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Vlad F
Member

Откуда:
Сообщений: 701
Molochnik
Vlad F
Molochnik,
Это очень даже не странно, это стандарт.

Странно что в микрософте об этом знали :)

Да это, поди, сделали еще те, у кого майкрософт это дело скупила.))
18 фев 19, 10:12    [21812572]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Molochnik
Если и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения?


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

> Этот так важно?

пока не увидел план сказать не могу, но почему-то у меня подозрения что сортировка не планом ORDER идет, а через SORT и тогда это действительно важно

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

я уверен что это можно сделать. Просто вы проектируете в лоб: одно поле — один фильтр
18 фев 19, 10:21    [21812577]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27844
Molochnik,

про потоки.
- в одном коннекте у ФБ параллельные операции не работают. Они будут ждать друг друга и выполняться последовательно.
В других серверах точно так же. 1 поток - 1 коннект.
- если потоки сериализуются по условиям задачи, то зачем они вообще нужны? Ради прикола, написать какой-то интересный в данный момент код?
18 фев 19, 10:56    [21812637]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

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

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

зы
поговаривают зубы можно per rectum удалять, но зачем
18 фев 19, 11:00    [21812644]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Симонов Денис
Molochnik
Если и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения?

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

В реальности две таблицы большие остальные очень маленькие. С увеличением числа записей скорость выборки в FB ощутимо падает, при наличии 10 тыс в двух больших таблицах еще более менее, но если по 50 тыс то каждый запрос секунды две длится. В MS SQL скорость в первом приближении от размера не зависит. Как я уже говорил таблицы, поля и индексы обеих баз одинаковы и тексты запросов тоже.
Симонов Денис
пока не увидел план сказать не могу, но почему-то у меня подозрения что сортировка не планом ORDER идет, а через SORT и тогда это действительно важно

Посмотрел в ibexpert там действительно вначале идет PLAN SORT...
Симонов Денис
я уверен что это можно сделать. Просто вы проектируете в лоб: одно поле — один фильтр

Да было бы неплохо

kdv
Molochnik,
про потоки.
- в одном коннекте у ФБ параллельные операции не работают. Они будут ждать друг друга и выполняться последовательно.
В других серверах точно так же. 1 поток - 1 коннект.

так и устроено один поток - один коннект.
kdv
Molochnik,
- если потоки сериализуются по условиям задачи, то зачем они вообще нужны? Ради прикола, написать какой-то интересный в данный момент код?

Работа с базой не является основной целью программы, а полезная деятельность отлично распараллеливается. Критическая секция используется только для выборки данных.
Дегтярев Евгений
сделайте один поток, ответственный за распределение заданий из очереди

Так делать не хочу поскольку в данном случае считаю это излишним усложнением. И зачем тогда вообще сервер баз данных использовать? Сделал всю работу с бд через один поток и радуйся. Работа с файловыми таблицами парадокса быстрее любого SQL сервера на порядок. Там где не используется бд, этот механизм (один поток для обработки информации) я использую часто, но с базой желания нет. Тем более как я уже сказал MS SQL работает как и надо.
18 фев 19, 11:30    [21812707]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 10195
Molochnik
С увеличением числа записей скорость выборки в FB ощутимо падает, при наличии 10 тыс в двух больших таблицах еще более менее, но если по 50 тыс то каждый запрос секунды две длится. В MS SQL скорость в первом приближении от размера не зависит.
Ну так там и кеш не 16МБ, не так ли ?
18 фев 19, 11:37    [21812721]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
o_v_a
Member

Откуда: Тула
Сообщений: 1041
Ну и уж истины ради только...
Увидим мы статистику выполнения реального запроса, который "тормозит в сравнении с таким же на MS SQL) или нет? А также конфиг сервера firebird SQL и заголовок статистики базы ?
18 фев 19, 12:09    [21812767]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1502
Molochnik
Тем более как я уже сказал MS SQL работает как и надо.

но это не значит что сделано все как надо

Если инкапсулировать логику работы с очередью, то реализации могут максимально использовать особенности выбранных способов хранения и нюансы этой логики не будут размазаны по воркерам
18 фев 19, 12:13    [21812780]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Файл конфига FB 3 приложен. Для FB2.5 настроек специальных никогда не делалось.

К сообщению приложен файл (firebird.conf - 2Kb) cкачать
18 фев 19, 12:46    [21812842]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Вот лог с тестированием одного селекта при 50 тыс записей для FB И MS SQL, работает только один поток.
Первые записи - идет выборка с FB, последние - с MS

К сообщению приложен файл (database.2019.02.log - 4Kb) cкачать
18 фев 19, 12:48    [21812847]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Molochnik
#hqbird traceapi plugin should be in plugins folder!
TracePlugin = fbtrace2db


так у тебя HQBird? Или просто скопировал бездумно?
18 фев 19, 12:55    [21812868]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1502
400-500ms на получение задачи из очереди это "как и надо"?
18 фев 19, 12:56    [21812871]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Дегтярев Евгений,

у него фильтрация записи мутная. Т.е. если сам SELECT запрос медленный, то там чего не делай с прикладой всё равно работать будет отвратительно
18 фев 19, 13:04    [21812895]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

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

По мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Ваш вариант с одним потоком обработчиком базы сильно усложняет систему потому, что НЕ ВСЕ записи подходят потоку и время обработки записи потоком неизвестно.
18 фев 19, 13:11    [21812914]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27844
Molochnik
Критическая секция используется только для выборки данных.

к чему тогда откровения по поводу потоков и критических секций? Это уже внутреннее дело вашего приложения, которые к работе с БД не относятся.
18 фев 19, 13:13    [21812920]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Симонов Денис
так у тебя HQBird? Или просто скопировал бездумно?

да тупо скопировал оптимизированный конфиг для суперсервера. Для классик и суперклассик параметры в файле меняю на рекомендуемые оптимизированные с того же сайта.
Дегтярев Евгений
400-500ms на получение задачи из очереди это "как и надо"?

ну, скажем так приемлемо. Сама обработка записи может десяток секунд идти
kdv
Molochnik
Критическая секция используется только для выборки данных.

к чему тогда откровения по поводу потоков и критических секций? Это уже внутреннее дело вашего приложения, которые к работе с БД не относятся.

Да, ни к чему конечно, к работе с БД это не относится. Ошибся и заметил это после отправки вопроса
18 фев 19, 13:17    [21812931]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47080

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

Она логична, но при её реализации ты допустил две ошибки:
1) Длинная читающая транзакция не позволяет видеть изменения флага параллельными потоками,
что на корню рушит логику.
2) Подавленное исключение не позволяет заметить ошибку обновления и пропустить уже
захваченную другим потоком запись.

Проще говоря, твоя система обработки не работает от слова "совсем" на сервере где нет
грязного чтения. MS SQL - твоё всё и альтернатив нет.

Posted via ActualForum NNTP Server 1.5

18 фев 19, 13:21    [21812941]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Dimitry Sibiryakov
Она логична, но при её реализации ты допустил две ошибки:
1) Длинная читающая транзакция не позволяет видеть изменения флага параллельными потоками,
что на корню рушит логику.

У меня же читающая транзакция read_commited. Если параллельный поток закоммитил данные, неужели читающая другого этого не увидит? Как же у меня она вообще работает тогда? А она работает, причем без исключений
18 фев 19, 13:25    [21812951]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

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

- не вижу ничего логичного
- не вижу усложнения
- поделите записи на группы и отдавайте обработчику нужную
- время обработки тут вообще причем?
18 фев 19, 13:28    [21812953]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47080

Molochnik
Как же у меня она вообще работает тогда?

Это в народе называется "дуракам везёт".

Molochnik
А она работает, причем без исключений

Это естественно, потому что ты глушишь их секцией except.

Posted via ActualForum NNTP Server 1.5

18 фев 19, 13:28    [21812954]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Дегтярев Евгений
- поделите записи на группы и отдавайте обработчику нужную
/quot]
Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
Dimitry Sibiryakov
Это в народе называется "дуракам везёт".

Все время же везти не может
Molochnik
А она работает, причем без исключений

Это естественно, потому что ты глушишь их секцией except.

Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло.
18 фев 19, 13:41    [21812970]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Дегтярев Евгений
- поделите записи на группы и отдавайте обработчику нужную
- время обработки тут вообще причем?

Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
Dimitry Sibiryakov
Это в народе называется "дуракам везёт".

Все время же везти не может
Dimitry Sibiryakov
Это естественно, потому что ты глушишь их секцией except.

Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло.
18 фев 19, 13:43    [21812971]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1502
Molochnik
Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.

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

вернемся к скорости
в вашем случае выбрать одну запись или 10 по времени одинаково, потому выхлоп будет
но сначала оптимизируйте запрос/структуру (которых мы так и не увидели)
в мсскл у вас та же проблема - 0.5 сек для выборки 1 записи из очереди много
18 фев 19, 13:56    [21812984]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
o_v_a
Member

Откуда: Тула
Сообщений: 1041
а физически не на одну ли тачку взгромоздили Firebird SQL и MS SQL?
Потому как если это так, то можно пеплом присыпать себе всё... Метра на два.
Firebird будет на правах падчерицы по ресурсам в этой ситуации.
18 фев 19, 14:09    [21813006]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47080

Molochnik
Все время же везти не может

Может.

Molochnik
Я глушу там просто на всякий случай, по инерции, по логике хуже не будет.

Ну да. Подумаешь: незамеченный конфликт. Это всего лишь означает, что одна и та же запись
будет обработана несколько раз разными потоками. Ничего страшного, просто из-за долгого
времени обработки одной записи обработка всех записей будет в несколько раз дольше. Стоп!
Уж не на это ли ты жаловался?..

Posted via ActualForum NNTP Server 1.5

18 фев 19, 14:44    [21813068]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

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

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

вернемся к скорости
в вашем случае выбрать одну запись или 10 по времени одинаково, потому выхлоп будет
но сначала оптимизируйте запрос/структуру (которых мы так и не увидели)
в мсскл у вас та же проблема - 0.5 сек для выборки 1 записи из очереди много

Да, решил разобраться с самим запросом. Отключая разные куски запроса оказалось что проблема в скорости связана с ORDER BY:
ORDER BY tbl1.Priority DESC, tbl2.Priority DESC, NextDateTimeText ASC

tbl1.Priority у всех записей одинаковый, в tbl1 запись одна
tbl2.Priority у всех записей одинаковый, и их в tbl2 50 тыс штук
При объединении таблиц получаются 50 тыс записей у которых tbl1.Priority=0 и tbl2.Priority=0 и по этим полям идет сортировка, которая напрягает оба серверы, но FB особенно. Правда как дальше быть не знаю, поскольку сортировка по приоритету должна быть, он все таки может быть разным. Индексы на оба поля делал но толку нет, значения то одинаковые.
18 фев 19, 15:59    [21813239]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
crazypiggy
Member

Откуда:
Сообщений: 58
http://www.ibase.ru/files/articles/performance/Firebird Optimizer - ORDER vs SORT.pdf
18 фев 19, 16:08    [21813272]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Molochnik,

я же тебе сразу сказал, что твои * играют злую шутку, потому что план там SORT
18 фев 19, 16:16    [21813295]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
o_v_a
Member

Откуда: Тула
Сообщений: 1041
... а статистику выполнения реального запроса и
gstat -h
базы мы, похоже, что так и не дождёмся
18 фев 19, 16:21    [21813309]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1502
Molochnik
При объединении таблиц получаются 50 тыс записей у которых tbl1.Priority=0 и tbl2.Priority=0 и по этим полям идет сортировка, которая напрягает оба серверы, но FB особенно. Правда как дальше быть не знаю, поскольку сортировка по приоритету должна быть, он все таки может быть разным. Индексы на оба поля делал но толку нет, значения то одинаковые.

и все эти 50т требуют обработки?
если нет, то сначала отобрать те которые требуют - после и сортировать до посинения
и еще вопрос почему задачи не сортируются по одной таблице?
18 фев 19, 18:02    [21813514]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
o_v_a
... а статистику выполнения реального запроса и
gstat -h
базы мы, похоже, что так и не дождёмся

просто не знал как это делается. Понял сделаю.
Дегтярев Евгений
и все эти 50т требуют обработки?
если нет, то сначала отобрать те которые требуют - после и сортировать до посинения

да нужно именно все записи обработать, может сложиться ситуация когда 49999 записей имеют приоритет 0, а последняя 1, нужно чтобы сначала была обработана последняя запись. Наверное можно сначала выбрать всевозможные приоритеты первой таблицы, затем всевозможные приоритеты второй, потом организовать вложенные циклы c запросом в котором уже не будет ORDER BY по приоритетам. Неужели так и надо делать? Выглядит ужасно криво.
Дегтярев Евгений
и еще вопрос почему задачи не сортируются по одной таблице?

Не совсем понял вопрос, имеется ввиду почему "сортировка по полям разных таблиц а не по одной"? Две разные сущности и каждая имеет приоритет.
Симонов Денис
Molochnik,
я же тебе сразу сказал, что твои * играют злую шутку, потому что план там SORT

Я просто не мог предположить что поле с постоянным значением оказывает такое тяжелое воздействие.
18 фев 19, 18:34    [21813586]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1502
Molochnik,

автор
да нужно именно все записи обработать, может сложиться ситуация когда 49999 записей имеют приоритет 0, а последняя 1, нужно чтобы сначала была обработана последняя запись

это решается соответствующим индексом, но для этого данные должны быть в одной таблице
18 фев 19, 18:58    [21813626]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6065
Molochnik,

топик, непонятно чего ты хочешь?

на халяву получить производительность коммерческой дорогой СУБД?

.......
ФБ - простая легковесная штука. отсюда ее плюсы и минусы.
18 фев 19, 22:56    [21813761]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Дегтярев Евгений
Molochnik,
это решается соответствующим индексом, но для этого данные должны быть в одной таблице

Может представление сделать? Будет фактически одна виртуальная таблица, но индекс же на ней не построишь, не вариант. Тогда может просто дублировать поля Priority в одну таблицу? И при любом изменении исходных (это случается крайне редко) просто обновлять результирующую по которой и идет запрос?
19 фев 19, 07:58    [21813905]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Siemargl
Molochnik,
топик, непонятно чего ты хочешь?
на халяву получить производительность коммерческой дорогой СУБД?
.......
ФБ - простая легковесная штука. отсюда ее плюсы и минусы.

У меня претензий к нему нет, MS SQL тоже же медленно работает, а проблема оказалась в запросе который писал я сам. Если убрать поля приоритетов из сортировки, запрос выполняется обоими серверами мгновенно (5-10 мс)
19 фев 19, 08:01    [21813906]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10630
Molochnik
ORDER BY tbl1.Priority DESC, tbl2.Priority DESC, NextDateTimeText ASC


....а вот в планировщике процессов в windows ввели такое понятие как dynamic priority boost, иначе на сильно загруженной системе некоторые процессы вообще переставали выполнятьcя, могли часами висеть в состоянии "жду своего шанса"
19 фев 19, 15:40    [21814431]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 513
Molochnik
Siemargl
Molochnik,
топик, непонятно чего ты хочешь?
на халяву получить производительность коммерческой дорогой СУБД?
.......
ФБ - простая легковесная штука. отсюда ее плюсы и минусы.

У меня претензий к нему нет, MS SQL тоже же медленно работает, а проблема оказалась в запросе который писал я сам. Если убрать поля приоритетов из сортировки, запрос выполняется обоими серверами мгновенно (5-10 мс)


Во-первых, чем какое-то штуко универсальнее, тем оно хуже в каждом конкретном применении, это аксиома. Это насчёт проектирования единого приложения под любую СУБД.

Во вторых, убрать это поле из сортировки как два пальца об асфальт, и не надо городить никаких процедур-вьюх. Делаем в приложении примерно так.

ResultDataSource.DataSet:=Nil;
QPriority.Close; /* Это запрос с where prority=1*/
QCommon.Close; /* Это запрос без условия по Priority*/

QPriority.Open;
if Not QPriority.IsEmpty then
 ResultDataSource.DataSet=QPriority
else
 begin
   QCommon.Open;
   if Not QCommon.IsEmpty then
    ResultDataSource.DataSet=QCommon;
 end
if ResultDataSource.DataSet=Nil then
 /*Ставим какой-то флажок для извещения интересующегося потока что ничего нет*/
else
 With ResultDataSource.DataSet Do
  begin
   /*Выполняем нужный Update. Конфликт не проглатываем, обслуживаем по-людски*/
   /*Загоняем значения полей в буфер для потока и ставим флажок - попалась, тварь!*/
  end;


Если приоритетных действительно заметно меньше, есть смысл сотворить индекс по Priority и добиться его использования в QPriority, вплоть до создания композита Priority,ID. И обеспечить его неиспользование в QCommon через +0. Это, правда, может повлечь за собой аналогичную подрихтовку других запросов с условием на Priority.

Касательно в два запроса выглядит криво. Таки нам шашечки или ехать? Ходы кривые роет подземный умный крот, нормальные герои всегда идут в обход проблем.
19 фев 19, 17:00    [21814572]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Старый плюшевый мишка
Если приоритетных действительно заметно меньше, есть смысл сотворить индекс по Priority и добиться его использования в QPriority, вплоть до создания композита Priority,ID. И обеспечить его неиспользование в QCommon через +0. Это, правда, может повлечь за собой аналогичную подрихтовку других запросов с условием на Priority.

Касательно в два запроса выглядит криво. Таки нам шашечки или ехать? Ходы кривые роет подземный умный крот, нормальные герои всегда идут в обход проблем.

Выглядит круто, но мне непонятно без примера. Это обработка одного потока, желающего получить одну запись? Тогда почему Priority=1? Потоку же нужен не конкретный приоритет а просто самый высокий.
19 фев 19, 21:24    [21814911]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
На текущий момент сделал в основной таблице поле Priority в дополнение к полю NextDateTimeText. Значение в него пишется синтетическое, вычисляемое на основе tbl1.Priority и tbl2.Priority и всегда обновляемое при изменении либо tbl1 либо tbl2. Сделал индекс на основе Priority, NextDateTimeText. Сейчас первая запись, если подходит, ищется около 10 мс на FB. Если дополнительный фильтр по времени запрещает все записи, т.е. худший случай, когда шерстятся все 50 тыс. записей и ничего не находится, запрос длится около 1 сек. Т.е. даже в худшем случае запрос открывается существенно быстрее чем раньше в лучшем случае.
19 фев 19, 21:38    [21814917]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Vlad F
Member

Откуда:
Сообщений: 701
Molochnik,

Т.е. все-таки можешь, когда захочешь?))
19 фев 19, 21:47    [21814919]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Vlad F
Molochnik,
Т.е. все-таки можешь, когда захочешь?))

Так криво же! Лишнее поле, лишние запросы. :) Тут вопрос как дальше оптимизировать чтобы убрать эту 1 секунду на поиск несуществующей записи, видимо циклов с вложенным запросами не избежать.
19 фев 19, 22:09    [21814932]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Molochnik,

не обязательно.

1. Можно кое что покумекать с CTE для отделения фильтрации и получения первой записи от присоединения дополнительных данных
2. Условия фильтрации можно упростить, да и вообще всякие LIKE нормально не оптмизируются
19 фев 19, 22:34    [21814939]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Симонов Денис
Molochnik,
1. Можно кое что покумекать с CTE для отделения фильтрации и получения первой записи от присоединения дополнительных данных

Думаете, возможно оптимизировать? Вот я попроще оформил эту проблему:

Table1
Id | TaskId | Info|
--------------------
1 | 1 | ' ' |
2 | 1 | ' ' |
3 | 1 | ' ' |
4 | 1 | ' ' |
...| ...| ...|

Table2
TaskId | Condition |
--------------------
1 | 0 |

SELECT Info FROM Table1 LEFT JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE  Table2.Condition=1


Симонов Денис
Molochnik,
1. Условия фильтрации можно упростить, да и вообще всякие LIKE нормально не оптмизируются

Я уже немного поправил часть с LIKE:
:AllowedTexts='' OR Text1 LIKE :AllowedTexts
заменил
:AllowedTexts IS NULL OR Text1 LIKE :AllowedTexts
иначе без CAST ошибка при непустом :AllowedTexts вылезала. Вообще этот параметр используется очень редко, поэтому LIKE там обычно не срабатывает (т.е. условие всегда True). А вот условие по времени и дате срабатывает часто.
20 фев 19, 00:17    [21814972]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 513
Molochnik
Это обработка одного потока, желающего получить одну запись?


Будем считать, что я неправильно понял, что извлечение данных из базы и отметка того, что запись принята к рассмотрнию, сведены в критической секции, а потоки растекаются мыслью по древу с полученными из неё, секции, данными, каждый со своей возвращаемой этой секцией строкой резалтсета. На что наводит такая штучка как ROWS 1 в тексте запроса. Кстати, такой синтаксис мне незнаком, но я подумал, что либо я не в курсе последних веяний, либо автор привёл запрос MS SQL.

Molochnik
Тогда почему Priority=1? Потоку же нужен не конкретный приоритет а просто самый высокий.


Это я тоже неправильно понял из

Molochnik
tbl1.Priority у всех записей одинаковый, в tbl1 запись одна
tbl2.Priority у всех записей одинаковый, и их в tbl2 50 тыс штук


что 1 - приоритетные строки, 0 - нет. Если есть иерархия приоритетов и основная масса всё-таки с нулевым, отсекаем её в первом запросе по where priority>0 и сортировку оставляем, на небольшом количестве записей она мешать не будет. Во втором уже ни условия на priority, ни сортировки по нему нет - ненулевые поймает первый, до второго дело дойдёт только если он пустой.
20 фев 19, 02:29    [21815023]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Старый плюшевый мишка

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

да, все так оно и есть
Старый плюшевый мишка
На что наводит такая штучка как ROWS 1 в тексте запроса. Кстати, такой синтаксис мне незнаком, но я подумал, что либо я не в курсе последних веяний, либо автор привёл запрос MS SQL.

Все придумывают кто на что горазд: TOP, ROWS, FIRST. Стандарта видимо нет.

Старый плюшевый мишка
Это я тоже неправильно понял из
что 1 - приоритетные строки, 0 - нет. Если есть иерархия приоритетов и основная масса всё-таки с нулевым, отсекаем её в первом запросе по where priority>0 и сортировку оставляем, на небольшом количестве записей она мешать не будет. Во втором уже ни условия на priority, ни сортировки по нему нет - ненулевые поймает первый, до второго дело дойдёт только если он пустой.

Понял вашу логику. Приоритет меняется от 1 до 5 в двух используемых таблицах, думаю больше никому не потребуется, по умолчанию - 3. Обычно да, приоритет не меняют, но если все-таки поменяют, он сразу будет другим во многих записях. Т.е если сделать ускорение только для обычного приоритета, клиент будет недоумевать почему при обычном приоритете система работает быстро, а при критическом тормозит :)
20 фев 19, 08:22    [21815101]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 14852
Molochnik
Все придумывают кто на что горазд: TOP, ROWS, FIRST. Стандарта видимо нет.
ROWS - стандарт.
20 фев 19, 09:11    [21815122]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
WildSery
ROWS - стандарт.

Хорошо бы микрософту об этом сказать
20 фев 19, 09:20    [21815127]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
WildSery
ROWS - стандарт.


Нет. По стандарту только в 3.0 сделано

[OFFSET n {ROW | ROWS}]
[FETCH {FIRST | NEXT} [m] {ROW | ROWS} ONLY]

гы. Теперь в Firebird аж 3 способа сделать одно и то же
20 фев 19, 09:35    [21815132]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 14852
Симонов Денис,

Я имел в виду ISO SQL 2008, а не Firebird.
20 фев 19, 10:03    [21815155]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
WildSery,

вот как раз там и есть тот синтаксис что я привёл. Его кстати почти во всех последних версиях SQL серверов прикрутили в том числе и в Oracle, MS SQL Server
20 фев 19, 10:13    [21815161]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10630
Molochnik
Т.е если сделать ускорение только для обычного приоритета


почему для обычного, делай для всех

Molochnik
Приоритет меняется от 1 до 5 в двух используемых таблицах


можно вообще сделать таблицу Максимальный_Приоритет с одной единственнйо строкой и заполнять её на триггерах.

или тупо в клиенте сделать цикл по приоритетам, как только нашлась первая запись, цикл прерывать

и поскольку тебе все равно никогда больше одоной строки не надо, то вместо "ORDER BY tbl1.Priority DESC" написать "WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) )"

Но IMHO зря это. Лучше реально считывать пачками хотя бы пару десятков задач, а потом уже на клиенте их разбирать по потокам. Впрочем, если обработка задачи по 10 секунд... (интересно, почему так долго)

SQL апдейт очень простой:
UPDATE tbl1 SET TextMarked=1
WHERE TextId=:TextId


Вот это мне тоже не нравится.
Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами).
Соответственно, при ошибке в обработчике можно задачу возвращать в пул "неназначенных".
При Успешной обработке - просто удалять из таблицы.

У тебя же похоже что во-первых идёт модификация "широкой" таблицы по одному столбцу.
Во вторых получается таблица, где TextMarked=0 выполняется только у очень немногих записей.
Кажется считается, что индексы по таким столбцам неэффективны.
20 фев 19, 20:08    [21815786]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Arioch
или тупо в клиенте сделать цикл по приоритетам, как только нашлась первая запись, цикл прерывать

Да, вариант рабочий, я просто хотел обойтись одним запросом
Arioch
и поскольку тебе все равно никогда больше одоной строки не надо, то вместо "ORDER BY tbl1.Priority DESC" написать "WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) )"

Это не прокатит, может быть так, что запись с максимальным приоритетом не удовлетворяет другим условиям, например по времени, а записи с меньшим - удовлетворяют. В итоге, при наличии реальных записей система будет стоять.
Arioch
Но IMHO зря это. Лучше реально считывать пачками хотя бы пару десятков задач, а потом уже на клиенте их разбирать по потокам.

Да уже предлагали этот вариант (Дегтярев Евгений) - один поток, обработчик базы, раскидывает данные по потокам. Я предположил что это чересчур сложно, имея сервер БД, который в общем то должен сам решать эту задачу
Arioch
Впрочем, если обработка задачи по 10 секунд... (интересно, почему так долго)

Пользователь долго думает.
Arioch
Вот это мне тоже не нравится.
Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами).
Соответственно, при ошибке в обработчике можно задачу возвращать в пул "неназначенных".
При Успешной обработке - просто удалять из таблицы.

В общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета
Arioch
У тебя же похоже что во-первых идёт модификация "широкой" таблицы по одному столбцу.
Во вторых получается таблица, где TextMarked=0 выполняется только у очень немногих записей.

50 тыс записей, 10 потоков, т.е. TextMarked=0 у 49990 записей. Очень немного записей (обычно 0) получается когда не выполняется условие, подобное для всех, например время. Тут сразу получается очень долго. Очевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку:
SELECT TaskID FROM Table2 WHERE Condition=1

и затем цикл по всем полученнным TaskId:
SELECT Info FROM Table1 LEFT JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table1.TaskId=:TaskId

Как сделать такой же эффективный один запрос я не знаю.
21 фев 19, 09:38    [21816024]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1303
Molochnik
Очевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку:
SELECT TaskID FROM Table2 WHERE Condition=1


и затем цикл по всем полученнным TaskId:
SELECT Info FROM Table1 LEFT JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table1.TaskId=:TaskId


Как сделать такой же эффективный один запрос я не знаю.

Встряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем
SELECT .... FROM Table1  JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table2.Condition=1
21 фев 19, 09:59    [21816034]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1303
Molochnik
Очевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку:
SELECT TaskID FROM Table2 WHERE Condition=1


и затем цикл по всем полученнным TaskId:
SELECT Info FROM Table1 LEFT JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table1.TaskId=:TaskId


Как сделать такой же эффективный один запрос я не знаю.

Встряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем
SELECT .... FROM Table1  JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table2.Condition=1
21 фев 19, 09:59    [21816035]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1502
Molochnik,

> > Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами).
> В общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета
примерно да не так
не первый раз говорят - сделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей, постройте индексы покрывающие ваши кейсы и крутите ее как угодно, разделите захват таска и получение данных по нему

зы
и даже без индексов, 50т записей в табличке с десятком целых полей - фильтр + сортировка + получение первой записи менее 50мс
21 фев 19, 10:22    [21816050]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
m7m
Встряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем
SELECT .... FROM Table1  JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table2.Condition=1

Пример просто был вырожденный чересчур, реально в Table2 имеются еще полезные поля которые нужно извлечь с помощью JOIN.
Да действительно, заменить LEFT на INNER в голову не приходило, раньше где ни использовал INNER, всегда медленно было, а сейчас протестировал с INNER - мгновенно происходит при невыполнении условия
Дегтярев Евгений
не первый раз говорят - сделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей, постройте индексы покрывающие ваши кейсы и крутите ее как угодно, разделите захват таска и получение данных по нему

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

так почти все поля и нужны (процентов 70), если все вносить в одну таблицу, то постоянно придется отслеживать все изменения в исходных, коих различных 6 штук, но вариант конечно рабочий
21 фев 19, 12:46    [21816205]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Molochnik
Да действительно, заменить LEFT на INNER в голову не приходило, раньше где ни использовал INNER, всегда медленно было, а сейчас протестировал с INNER - мгновенно происходит при невыполнении условия

А нет, все от данных зависит, сейчас тестировал на 200 тыс идентичных записях в обоих серверах. Составил табличку

1)Если нет ни одной удовлетворяющей записи,
FB
INNER JOIN - 1.6 сек
LEFT JOIN - 5.5 сек

MS
INNER JOIN - 0.6 сек,
LEFT JOIN - 0.6 сек

2) Если из 200 тыс доступны по условию все, то при получении одной записи
FB
INNER JOIN - 20 сек,
LEFT JOIN - 0.8 секунды

MS
INNER JOIN - 0.01 сек
LEFT JOIN - 0.01 сек

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

Откуда: Рязань
Сообщений: 9246
Molochnik,

я тебе уже советовал отделять условия фильтрации от остальных данных?

делай так

SELECT COUNT(*)
FROM T1 JOIN T2 ....
WHERE <твой фильтр>


если этот запрос будет быстро работать, то и остальное заработает.
21 фев 19, 15:08    [21816473]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10630
Molochnik
Это не прокатит, может быть так, что запись с максимальным приоритетом не удовлетворяет другим условиям, например по времени, а записи с меньшим - удовлетворяют.


Хммм... Ну тогда вот именно в этом случае, относительно редком, и "сыграешь на понижение", сделаешь второй запрос

Arioch
"WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) ) - :StepDown "


StepDown = 0, 1, 2, 3....

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


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

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

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

Даже вот тупо так:

процессор 1 начал получать задание
процессор 2 начал получать задание
процессор 1 получил задание №1
процессор 2 получил задание №1
процессор 1 начал обрабатывать задание №1
процессор 2 начал обрабатывать задание №1
процессор 1 кончил обрабатывать задание №1
процессор 2 кончил обрабатывать задание №1
процессор 1 положил в БД задание №1
процессор 2 попытался положить в БД задание №1 - и обломался (а то, не дай бог, и положил, дубль)
процессор 1 начал получать задание
процессор 2 начал получать задание
процессор 1 получил задание №2
процессор 2 получил задание №2
....

если задания примерно равнозначные по сложности - то такая цепочка может дооолго идти.
а если процессоров >2 - то ещё дольше.
21 фев 19, 15:15    [21816489]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10630
Molochnik
В общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета


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

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

Molochnik
50 тыс записей, 10 потоков, т.е. TextMarked=0 у 49990 записей.

это сегодня.
завтра у тебя 50К с 0 и 50К с 1
послезавтра - 50К с 0 и 100К с 1
через месяц - 50К с 0 и 3М с 1
и т.д.
21 фев 19, 15:20    [21816496]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

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


туда ещё и генератор можно будет прицепить, ради dirty read, ради того, чтобы "захват таска" выполнялся вообще ВНЕ ТРАНЗАКЦИЙ и таким образом два разных клиента просто В ПРИНЦИПЕ не могли схватить один и тот же таск

да, надо будет отрабатывать ошибочные ситуации типа "клиент схватил таск и умер, а уборщица украла сетевой кабель" - вбрасывать задание обратно с новым ID > generator-value

но захват пачки заданий становится максимально быстрым и вообще без возможных пересечений с конкурентами
21 фев 19, 15:24    [21816502]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

Откуда:
Сообщений: 10630
Molochnik
Последние результаты для FB просто удручающие


а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ?
21 фев 19, 15:27    [21816507]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 600
Molochnik,

20 сек - это, конечно, сильно. Может анализ производительности в Эксперте посмотрим? План?
21 фев 19, 15:42    [21816527]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Arioch
Molochnik
Последние результаты для FB просто удручающие

а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ?

Да сделал так, еще дополнительно провел бэкап рестор базы, результаты получше стали
1)Если нет ни одной удовлетворяющей записи,
FB
INNER JOIN - 1.2 сек
LEFT JOIN - 4.1 сек

2) Если из 200 тыс доступны по условию все, то при получении одной записи
FB
INNER JOIN - 17 сек,
LEFT JOIN - 0.015 сек

То есть в идеальном случае, когда любая запись подходит FB работает почти как MS, что не может не радовать. Но INNER JOIN просто смерть какая-то.
21 фев 19, 16:10    [21816570]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
m7m
Member

Откуда: Украина, Мариуполь
Сообщений: 1303
Molochnik
Но INNER JOIN просто смерть какая-то.

Вот тут ты не прав
нельзя просто так заменить LEFT JOIN на INNER JOIN
ибо это совершенно разные запросы и
совершенно разные результаты выполнения

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

ззы. то что я написал относилось конкретно к тем двум запросам что были в сообщении
и никак не означало что надо заменить LEFT JOIN на INNER JOIN в твоем исходном запросе
21 фев 19, 16:45    [21816603]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 513
Molochnik
Arioch
пропущено...

а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ?

Да сделал так, еще дополнительно провел бэкап рестор базы, результаты получше стали
1)Если нет ни одной удовлетворяющей записи,
FB
INNER JOIN - 1.2 сек
LEFT JOIN - 4.1 сек

2) Если из 200 тыс доступны по условию все, то при получении одной записи
FB
INNER JOIN - 17 сек,
LEFT JOIN - 0.015 сек

То есть в идеальном случае, когда любая запись подходит FB работает почти как MS, что не может не радовать. Но INNER JOIN просто смерть какая-то.


Да план меняется просто при заменах inner-left. Порядок перебора таблиц и, соответственно, используемые индексы. При left порядок задан жёстко, при inner его определяет оптимизатор. Опираясь на статистику индексов. Но он не знает сколько у тебя в какой таблице дубликатов по индексам и, бывает, оптимизирует не в ту сторону. А у тебя их, дубликатов, сорок бочек арестантов. Но ты-то об этом знаешь, так и направляй оптимизатора через +0 для того, чтобы он не использовал заведомо вредные для этого конкретного запроса индексы. В смысле чтобы добиться среднестатистической оптимальности, по наиболее распространённому случаю. Кстати, сортировки тоже тормозят тем сильнее, чем больше дубликатов по этим полям. Если их нет, то почти что с сортировкой, что без.
21 фев 19, 19:03    [21816776]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Симонов Денис
Molochnik,

я тебе уже советовал отделять условия фильтрации от остальных данных?

делай так

SELECT COUNT(*)
FROM T1 JOIN T2 ....
WHERE <твой фильтр>


если этот запрос будет быстро работать, то и остальное заработает.

Потестировал ваш вариант, оставил одно поле
COUNT(*) 
и убрал
ORDER BY
иначе выдавал ошибку. Результаты следующие:
1)Если нет ни одной удовлетворяющей записи (Count =0)
FB
INNER JOIN - 1.3 сек
LEFT JOIN - 3.8 сек

MS
INNER JOIN - 0.005 сек,
LEFT JOIN - 0.005 сек

2) Если из 200 тыс доступны по условию все ( Count =200000)
FB
INNER JOIN - 4.2 сек,
LEFT JOIN - 4.2 сек

MS
INNER JOIN - 0.7 сек
LEFT JOIN - 0.7 сек
m7m
Вот тут ты не прав
нельзя просто так заменить LEFT JOIN на INNER JOIN
ибо это совершенно разные запросы и
совершенно разные результаты выполнения

В общем случае согласен, но в моем варианте и варианте тестового примера, когда возвращается одна строка результат по логике должен быть примерно одинаковым, что результаты MS в общем то доказывают.
21 фев 19, 19:09    [21816781]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
m7m
не видя ни структур таблиц, ни планов, ни запросов
мы тебе тут много чего насоветуем

ззы. то что я написал относилось конкретно к тем двум запросам что были в сообщении
и никак не означало что надо заменить LEFT JOIN на INNER JOIN в твоем исходном запросе

Реально там нет ничего интересного, ну вообще ничего, 6 таблиц джойнятся с разными несложными разумными условиями, никаких нестед таблиц или сложных конструкций, две таблицы большие да, по 200 тыс записей, джойнятся один к одному по полю, которое в одной таблице уникально, остальные таблицы по 1-3 записи. Основная проблема судя по всему - очень много одинаковых значений по полям, которые используется при сортировке и фильтре.
Старый плюшевый мишка
Да план меняется просто при заменах inner-left. Порядок перебора таблиц и, соответственно, используемые индексы. При left порядок задан жёстко, при inner его определяет оптимизатор. Опираясь на статистику индексов. Но он не знает сколько у тебя в какой таблице дубликатов по индексам и, бывает, оптимизирует не в ту сторону. А у тебя их, дубликатов, сорок бочек арестантов. Но ты-то об этом знаешь, так и направляй оптимизатора через +0 для того, чтобы он не использовал заведомо вредные для этого конкретного запроса индексы. В смысле чтобы добиться среднестатистической оптимальности, по наиболее распространённому случаю. Кстати, сортировки тоже тормозят тем сильнее, чем больше дубликатов по этим полям. Если их нет, то почти что с сортировкой, что без.

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

Откуда:
Сообщений: 630
Molochnik
если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять"

Ты просто пока не сталкивался. Например, выполни поиск слова "хинт" в форуме https://www.sql.ru/forum/microsoft-sql-server.
21 фев 19, 19:35    [21816802]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9246
Molochnik,

упрости запрос по максимуму на которых проявляются тормоза. Приведи его здесь, статистику выполнения и explain план запроса.
Кстати в MS SQL ном варианте тоже хотелось бы на план взглянуть
21 фев 19, 19:47    [21816815]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 513
Molochnik
Это пока для меня слишком сложно, я сейчас почитаю как работает FB (ссылку дали). Но что интересно, если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять" :)


IBExpert внизу, вместе со временем выполнения, показывает пресловутый план. Перечень использованных индексов. Причём они перечисляются в порядке перебора таблиц, на которых они созданы. То есть, индексы таблицы, от которой начинается перебор, идут первыми (если она вообще не идёт натуралом), первого уровня подчинённости - вторыми и так далее. Скажем, условие "on t1.id=t2.id" в иннер может быть выполнено как перебором t1 с подтягиванием записей из t2 по индексу на t2, так и наоборот. Посмотри на план и прикинь как ТЫ бы это делал сам, ручками, чтобы не за... за... устать, в общем. И если оптимизатор сделал наоборот, то имеем то, что имеем, и надо вправлять ему мозги подзатыльником. Типа "on t1.id+0=t2.id". Тогда t1 точно будет ведущей, а t2 подтягиваться по индексу.
21 фев 19, 20:13    [21816831]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Molochnik
Member

Откуда:
Сообщений: 81
Симонов Денис
Старый плюшевый мишка
Да все сделаю, посмотрю и проверю
21 фев 19, 20:28    [21816840]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

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


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

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

вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше
22 фев 19, 14:18    [21817307]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs MS SQL  [new]
Arioch
Member

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



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

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

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


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

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

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

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

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

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


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

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

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

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

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


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

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

Откуда:
Сообщений: 630
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

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

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

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

зы
сорри за резкость, в сибири пятница празднуется во всю
22 фев 19, 17:58    [21817536]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5      [все]
Все форумы / Firebird, InterBase Ответить