powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird vs MS SQL
143 сообщений из 143, показаны все 6 страниц
Firebird vs MS SQL
    #39775271
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Имеется многопотоковое дельфийское приложение, у каждого потока свое соединение к общей базе. Через Unidac может работать с Firebird и MS SQL. Каждый поток выполняет (регулярно и часто) одинаковый для всех сложный SELECT, и затем одинаковый для всех простой UPDATE, со своим набором параметров. При тестировании обнаружил, что с MS SQL программа работает быстро и реально многопотоково, а с Firebird выглядит так как будто каждый поток ждет когда до него дойдет очередь выполнять запрос, в итоге получается а разы медленнее чем с MS SQL. Тестировал на FB2.5 и FB3.0 со всеми архитектурами, ситуация примерно одинакова. В какую сторону смотреть? Не может же быть, что Firebird в разы хуже MS SQL.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775273
Фэйтл Эра
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

давай сюда тест, повторимый. Иначе о чем.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775274
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Поменять сообщение видимо нельзя, поэтому добавлю, что все запросы делаются через критическую секцию, т.е. фактически эти запросы к базе выполняются потоками по очереди, но это не мешает MS SQL обрабатывать их очень быстро в отличии от FB.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775276
Фэйтл Эра
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

набросать тест? А ты, не имея его исходников, начнешь угадывать, насколько он соответствует твоим задачам.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775278
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Фэйтл ЭраMolochnik,

давай сюда тест, повторимый. Иначе о чем.
Сильно много усилий придется потратить такой тест сделать, фактически надо с нуля тестовое приложение написать. Если без этого никак проще оставить как есть и не париться.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775279
Фэйтл Эра
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnikпроще оставить как есть и не париться
Если допустимо не оптимизировать - не оптимизируй.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775281
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Фэйтл ЭраMolochnikпроще оставить как есть и не париться
Если допустимо не оптимизировать - не оптимизируй.
Наверное так и оставлю, в принципе работает, посмотрел как запрос выполняется в IBExpert, все вроде корректно, в плане куча джойнов и индексов, "natural" только один, в таблице где обычно 1-2 записи. Чтобы оптимизировать вероятно нужно будет сильно потрудиться. Не стоит игра свеч наверно.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775282
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikПри тестировании обнаружил, что с MS SQL программа работает быстро и реально многопотоково
Molochnikвсе запросы делаются через критическую секцию, т.е. фактически эти запросы к базе выполняются потоками по очередиТы определись - "реально многопотоково" или таки "по очереди"
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775284
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikКаждый поток выполняет (регулярно и часто) одинаковый для всех сложный SELECT, и затем одинаковый для всех простой UPDATE, со своим набором параметровА коммит - где ?
В MSSQL - автокоммит небось, а у FB нужно явно делать.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775295
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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 формально выглядит так же, транзакции без параметров. Зачем вообще две транзакции, если все равно запросы выполняются в критической секции? Потому что имеется еще другое приложение, которое тоже может работать с этими таблицами, но оно выполняет запросы вручную и в тесте не участвует.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775302
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код в каждом потоке выглядит примерно так
Код: pascal
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
    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, но суть ту же) выглядит так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
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 апдейт очень простой:
Код: sql
1.
2.
UPDATE tbl1 SET TextMarked=1
WHERE TextId=:TextId
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775307
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikИмеется многопотоковое дельфийское приложение, у каждого потока свое соединение к общей базе <..>.
Милый друг, ну а зачем же ты тогда критические секции в них запихал?
И что будет, если обращение к ним (секциям) просто закомментировать?
И если уж на то пошло, то мерить/сравнивать тебе надо, для начала, простое последовательное выполнение
тех запросов в цикле. Слелай циклы на тысячу итераций к каждому серверу (вот тебе саамый простой тест),
засеки время и озвучь результат.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775308
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

за такой SELECT надо руки отрывать, без относительно того на каком сервере это выполняется
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775310
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Vlad FМилый друг, ну а зачем же ты тогда критические секции в них запихал?

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

да, сделаю
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775311
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов ДенисMolochnik,
за такой SELECT надо руки отрывать, без относительно того на каком сервере это выполняется
И в чем кривость?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775312
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikЗачем вообще две транзакции, если все равно запросы выполняются в критической секции? Потому что имеется еще другое приложение, которое тоже может работать с этими таблицами, но оно выполняет запросы вручную и в тесте не участвует.

Это вообще феерический бред. Каким образом боком здесь вообще другое приложение работающее с теми же таблицаим?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775313
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

во всём, начиная от table.*, поля в where без уточнений к какой таблице относятся, 100500 условий фильтрации
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775314
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов ДенисMolochnikЗачем вообще две транзакции, если все равно запросы выполняются в критической секции? Потому что имеется еще другое приложение, которое тоже может работать с этими таблицами, но оно выполняет запросы вручную и в тесте не участвует.

Это вообще феерический бред. Каким образом боком здесь вообще другое приложение работающее с теми же таблицаим?
Никакого, я просто объяснил почему несмотря на критическую секцию здесь используются две транзакции а не одна
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775316
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов ДенисMolochnik,

во всём, начиная от table.*, поля в where без уточнений к какой таблице относятся, 100500 условий фильтрации
Поля используются практически все, их очень много, чтобы по отдельности выписывать. в WHERE поля без уточнения, согласен, но это косметика. Условий фильтрации много, ну и что? Все нужны.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775322
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikСмысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись.
Select for update, с с оответствующей обработкой результатов возможного отлупа в потоках,
с тем чтобы они в подобной ситуации повторяли попытку поиска неиспользуемой записи?
Подумай над этим.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775331
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Vlad FSelect for update, с с оответствующей обработкой результатов возможного отлупа в потоках,
с тем чтобы они в подобной ситуации повторяли попытку поиска неиспользуемой записи?
Подумай над этим.
Этой конструкции нет в MS SQL поэтому я стараюсь такие не использовать. Также например не использую функцию IIF, потому что вплоть до 2008 года в MS SQL ее не было.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775338
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

Но case то был??
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775340
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Vlad FMolochnik,
Но case то был??
Да, как ни странно, case был. У меня сейчас совместимость вплоть до MS SQL 2000
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775342
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

Это очень даже не странно, это стандарт.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775343
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Vlad FMolochnik,
Это очень даже не странно, это стандарт.
Странно что в микрософте об этом знали :)
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775347
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikНикакого, я просто объяснил почему несмотря на критическую секцию здесь используются две транзакции а не одна

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

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

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

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

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

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

Его наверняка можно упростить, пусть даже не для сервера, а для самого себя чтобы понимать проще было. ДА и не верю я что нельзя придумать чуть более прямую схему фильтрации.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775355
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов Денисэто как раз и есть чушь. Паттерн с использованием двух транзакций происходит от нежелания закрывать недофетченный курсор, при завершении единственной транзакции которая обновила запись. От наличия нескольких приложений работающих с теми же таблицами это никак не зависит.

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

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

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

Это понятно
Симонов ДенисЕго наверняка можно упростить, пусть даже не для сервера, а для самого себя чтобы понимать проще было. ДА и не верю я что нельзя придумать чуть более прямую схему фильтрации.
Сомнительно. Все условия разнородные, скорее всего упростить можно только уменьшив количество возможностей, чего не хотелось бы.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775358
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikVlad FMolochnik,
Это очень даже не странно, это стандарт.
Странно что в микрософте об этом знали :)
Да это, поди, сделали еще те, у кого майкрософт это дело скупила.))
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775361
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikЕсли и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения?

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

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

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

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

я уверен что это можно сделать. Просто вы проектируете в лоб: одно поле — один фильтр
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775388
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

про потоки.
- в одном коннекте у ФБ параллельные операции не работают. Они будут ждать друг друга и выполняться последовательно.
В других серверах точно так же. 1 поток - 1 коннект.
- если потоки сериализуются по условиям задачи, то зачем они вообще нужны? Ради прикола, написать какой-то интересный в данный момент код?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775393
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikСмысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись.

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

зы
поговаривают зубы можно per rectum удалять, но зачем
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775422
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов ДенисMolochnikЕсли и селект и апдейт засунуть в одну долгую пишущую транзакцию, то что это никак не повлияет на доступ к тем же таблицам из другого приложения?
а почему это она должна быть долгой? В твоём SELECT выбирается одна жалкая запись. Если это делается долго, то нужно запрос оптимизировать.

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

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

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

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

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

Так делать не хочу поскольку в данном случае считаю это излишним усложнением. И зачем тогда вообще сервер баз данных использовать? Сделал всю работу с бд через один поток и радуйся. Работа с файловыми таблицами парадокса быстрее любого SQL сервера на порядок. Там где не используется бд, этот механизм (один поток для обработки информации) я использую часто, но с базой желания нет. Тем более как я уже сказал MS SQL работает как и надо.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775428
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikС увеличением числа записей скорость выборки в FB ощутимо падает, при наличии 10 тыс в двух больших таблицах еще более менее, но если по 50 тыс то каждый запрос секунды две длится. В MS SQL скорость в первом приближении от размера не зависит.Ну так там и кеш не 16МБ, не так ли ?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775450
Фотография o_v_a
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну и уж истины ради только...
Увидим мы статистику выполнения реального запроса, который "тормозит в сравнении с таким же на MS SQL) или нет? А также конфиг сервера firebird SQL и заголовок статистики базы ?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775460
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikТем более как я уже сказал MS SQL работает как и надо.
но это не значит что сделано все как надо

Если инкапсулировать логику работы с очередью, то реализации могут максимально использовать особенности выбранных способов хранения и нюансы этой логики не будут размазаны по воркерам
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775486
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Файл конфига FB 3 приложен. Для FB2.5 настроек специальных никогда не делалось.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775489
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вот лог с тестированием одного селекта при 50 тыс записей для FB И MS SQL, работает только один поток.
Первые записи - идет выборка с FB, последние - с MS
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775499
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik#hqbird traceapi plugin should be in plugins folder!
TracePlugin = fbtrace2db

так у тебя HQBird? Или просто скопировал бездумно?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775502
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
400-500ms на получение задачи из очереди это "как и надо"?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775513
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дегтярев Евгений,

у него фильтрация записи мутная. Т.е. если сам SELECT запрос медленный, то там чего не делай с прикладой всё равно работать будет отвратительно
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775519
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дегтярев ЕвгенийЕсли инкапсулировать логику работы с очередью, то реализации могут максимально использовать особенности выбранных способов хранения и нюансы этой логики не будут размазаны по воркерам
По мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Ваш вариант с одним потоком обработчиком базы сильно усложняет систему потому, что НЕ ВСЕ записи подходят потоку и время обработки записи потоком неизвестно.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775522
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikКритическая секция используется только для выборки данных.

к чему тогда откровения по поводу потоков и критических секций? Это уже внутреннее дело вашего приложения, которые к работе с БД не относятся.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775527
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов Денистак у тебя HQBird? Или просто скопировал бездумно?
да тупо скопировал оптимизированный конфиг для суперсервера. Для классик и суперклассик параметры в файле меняю на рекомендуемые оптимизированные с того же сайта.
Дегтярев Евгений400-500ms на получение задачи из очереди это "как и надо"?
ну, скажем так приемлемо. Сама обработка записи может десяток секунд идти
kdvMolochnikКритическая секция используется только для выборки данных.

к чему тогда откровения по поводу потоков и критических секций? Это уже внутреннее дело вашего приложения, которые к работе с БД не относятся.
Да, ни к чему конечно, к работе с БД это не относится. Ошибся и заметил это после отправки вопроса
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775532
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikПо мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему
незанятую запись и обрабатывает ее столько сколь считает нужным.

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

Проще говоря, твоя система обработки не работает от слова "совсем" на сервере где нет
грязного чтения. MS SQL - твоё всё и альтернатив нет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775537
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovОна логична, но при её реализации ты допустил две ошибки:
1) Длинная читающая транзакция не позволяет видеть изменения флага параллельными потоками,
что на корню рушит логику.

У меня же читающая транзакция read_commited. Если параллельный поток закоммитил данные, неужели читающая другого этого не увидит? Как же у меня она вообще работает тогда? А она работает, причем без исключений
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775539
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikПо мне текущая архитектура выглядит логично - каждый поток выбирает подходящую ему незанятую запись и обрабатывает ее столько сколь считает нужным. Ваш вариант с одним потоком обработчиком базы сильно усложняет систему потому, что НЕ ВСЕ записи подходят потоку и время обработки записи потоком неизвестно.
- не вижу ничего логичного
- не вижу усложнения
- поделите записи на группы и отдавайте обработчику нужную
- время обработки тут вообще причем?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775540
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikКак же у меня она вообще работает тогда?

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

MolochnikА она работает, причем без исключений
Это естественно, потому что ты глушишь их секцией except.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775545
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дегтярев Евгений- поделите записи на группы и отдавайте обработчику нужную
/quot]
Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
Dimitry SibiryakovЭто в народе называется "дуракам везёт".

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

Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775546
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дегтярев Евгений- поделите записи на группы и отдавайте обработчику нужную
- время обработки тут вообще причем?
Это фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
Dimitry SibiryakovЭто в народе называется "дуракам везёт".

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

Я глушу там просто на всякий случай, по инерции, по логике хуже не будет. Исключения в дебаггере не блокируются и всегда вылазят если что. Если бы были глюки я бы уже давно этим озаботился. А так просто медленно. Если записей 100, то практически незаметно, вот с большим числом сразу это вылезло.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775553
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikЭто фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
оставим тему про дублирование, я понял что для вас значит усложнение...

вернемся к скорости
в вашем случае выбрать одну запись или 10 по времени одинаково, потому выхлоп будет
но сначала оптимизируйте запрос/структуру (которых мы так и не увидели)
в мсскл у вас та же проблема - 0.5 сек для выборки 1 записи из очереди много
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775567
Фотография o_v_a
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а физически не на одну ли тачку взгромоздили Firebird SQL и MS SQL?
Потому как если это так, то можно пеплом присыпать себе всё... Метра на два.
Firebird будет на правах падчерицы по ресурсам в этой ситуации.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775590
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikВсе время же везти не может

Может.

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

Ну да. Подумаешь: незамеченный конфликт. Это всего лишь означает, что одна и та же запись
будет обработана несколько раз разными потоками. Ничего страшного, просто из-за долгого
времени обработки одной записи обработка всех записей будет в несколько раз дольше. Стоп!
Уж не на это ли ты жаловался?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775670
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дегтярев ЕвгенийMolochnikЭто фактически означает сдублировать работу с бд в памяти одного потока. Можно конечно, но скорости это не прибавит как уже выяснилось.
оставим тему про дублирование, я понял что для вас значит усложнение...

вернемся к скорости
в вашем случае выбрать одну запись или 10 по времени одинаково, потому выхлоп будет
но сначала оптимизируйте запрос/структуру (которых мы так и не увидели)
в мсскл у вас та же проблема - 0.5 сек для выборки 1 записи из очереди много
Да, решил разобраться с самим запросом. Отключая разные куски запроса оказалось что проблема в скорости связана с ORDER BY:
Код: sql
1.
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 особенно. Правда как дальше быть не знаю, поскольку сортировка по приоритету должна быть, он все таки может быть разным. Индексы на оба поля делал но толку нет, значения то одинаковые.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775686
crazypiggy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775698
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

я же тебе сразу сказал, что твои * играют злую шутку, потому что план там SORT
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775702
Фотография o_v_a
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
... а статистику выполнения реального запроса и
gstat -h
базы мы, похоже, что так и не дождёмся
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775816
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikПри объединении таблиц получаются 50 тыс записей у которых tbl1.Priority=0 и tbl2.Priority=0 и по этим полям идет сортировка, которая напрягает оба серверы, но FB особенно. Правда как дальше быть не знаю, поскольку сортировка по приоритету должна быть, он все таки может быть разным. Индексы на оба поля делал но толку нет, значения то одинаковые.
и все эти 50т требуют обработки?
если нет, то сначала отобрать те которые требуют - после и сортировать до посинения
и еще вопрос почему задачи не сортируются по одной таблице?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775847
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
o_v_a... а статистику выполнения реального запроса и
gstat -h
базы мы, похоже, что так и не дождёмся
просто не знал как это делается. Понял сделаю.
Дегтярев Евгенийи все эти 50т требуют обработки?
если нет, то сначала отобрать те которые требуют - после и сортировать до посинения

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

Не совсем понял вопрос, имеется ввиду почему "сортировка по полям разных таблиц а не по одной"? Две разные сущности и каждая имеет приоритет.
Симонов ДенисMolochnik,
я же тебе сразу сказал, что твои * играют злую шутку, потому что план там SORT
Я просто не мог предположить что поле с постоянным значением оказывает такое тяжелое воздействие.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775865
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

авторда нужно именно все записи обработать, может сложиться ситуация когда 49999 записей имеют приоритет 0, а последняя 1, нужно чтобы сначала была обработана последняя запись
это решается соответствующим индексом, но для этого данные должны быть в одной таблице
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39775943
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

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

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

.......
ФБ - простая легковесная штука. отсюда ее плюсы и минусы.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776009
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дегтярев ЕвгенийMolochnik,
это решается соответствующим индексом, но для этого данные должны быть в одной таблице
Может представление сделать? Будет фактически одна виртуальная таблица, но индекс же на ней не построишь, не вариант. Тогда может просто дублировать поля Priority в одну таблицу? И при любом изменении исходных (это случается крайне редко) просто обновлять результирующую по которой и идет запрос?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776010
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SiemarglMolochnik,
топик, непонятно чего ты хочешь?
на халяву получить производительность коммерческой дорогой СУБД?
.......
ФБ - простая легковесная штука. отсюда ее плюсы и минусы.
У меня претензий к нему нет, MS SQL тоже же медленно работает, а проблема оказалась в запросе который писал я сам. Если убрать поля приоритетов из сортировки, запрос выполняется обоими серверами мгновенно (5-10 мс)
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776241
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik
Код: sql
1.
ORDER BY tbl1.Priority DESC, tbl2.Priority DESC, NextDateTimeText ASC



....а вот в планировщике процессов в windows ввели такое понятие как dynamic priority boost, иначе на сильно загруженной системе некоторые процессы вообще переставали выполнятьcя, могли часами висеть в состоянии "жду своего шанса"
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776317
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikSiemarglMolochnik,
топик, непонятно чего ты хочешь?
на халяву получить производительность коммерческой дорогой СУБД?
.......
ФБ - простая легковесная штука. отсюда ее плюсы и минусы.
У меня претензий к нему нет, MS SQL тоже же медленно работает, а проблема оказалась в запросе который писал я сам. Если убрать поля приоритетов из сортировки, запрос выполняется обоими серверами мгновенно (5-10 мс)

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

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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
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.

Касательно в два запроса выглядит криво. Таки нам шашечки или ехать? Ходы кривые роет подземный умный крот, нормальные герои всегда идут в обход проблем.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776471
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Старый плюшевый мишкаЕсли приоритетных действительно заметно меньше, есть смысл сотворить индекс по Priority и добиться его использования в QPriority , вплоть до создания композита Priority,ID. И обеспечить его неиспользование в QCommon через +0. Это, правда, может повлечь за собой аналогичную подрихтовку других запросов с условием на Priority.

Касательно в два запроса выглядит криво. Таки нам шашечки или ехать? Ходы кривые роет подземный умный крот, нормальные герои всегда идут в обход проблем.
Выглядит круто, но мне непонятно без примера. Это обработка одного потока, желающего получить одну запись? Тогда почему Priority=1? Потоку же нужен не конкретный приоритет а просто самый высокий.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776476
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
На текущий момент сделал в основной таблице поле Priority в дополнение к полю NextDateTimeText. Значение в него пишется синтетическое, вычисляемое на основе tbl1.Priority и tbl2.Priority и всегда обновляемое при изменении либо tbl1 либо tbl2. Сделал индекс на основе Priority, NextDateTimeText. Сейчас первая запись, если подходит, ищется около 10 мс на FB. Если дополнительный фильтр по времени запрещает все записи, т.е. худший случай, когда шерстятся все 50 тыс. записей и ничего не находится, запрос длится около 1 сек. Т.е. даже в худшем случае запрос открывается существенно быстрее чем раньше в лучшем случае.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776478
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

Т.е. все-таки можешь, когда захочешь?))
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776486
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Vlad FMolochnik,
Т.е. все-таки можешь, когда захочешь?))
Так криво же! Лишнее поле, лишние запросы. :) Тут вопрос как дальше оптимизировать чтобы убрать эту 1 секунду на поиск несуществующей записи, видимо циклов с вложенным запросами не избежать.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776490
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

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

1. Можно кое что покумекать с CTE для отделения фильтрации и получения первой записи от присоединения дополнительных данных
2. Условия фильтрации можно упростить, да и вообще всякие LIKE нормально не оптмизируются
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776504
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов ДенисMolochnik,
1. Можно кое что покумекать с CTE для отделения фильтрации и получения первой записи от присоединения дополнительных данных

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

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

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

Код: sql
1.
2.
SELECT Info FROM Table1 LEFT JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE  Table2.Condition=1



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

Я уже немного поправил часть с LIKE:
Код: sql
1.
:AllowedTexts='' OR Text1 LIKE :AllowedTexts

заменил
Код: sql
1.
:AllowedTexts IS NULL OR Text1 LIKE :AllowedTexts

иначе без CAST ошибка при непустом :AllowedTexts вылезала. Вообще этот параметр используется очень редко, поэтому LIKE там обычно не срабатывает (т.е. условие всегда True). А вот условие по времени и дате срабатывает часто.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776522
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikЭто обработка одного потока, желающего получить одну запись?


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

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


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

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


что 1 - приоритетные строки, 0 - нет. Если есть иерархия приоритетов и основная масса всё-таки с нулевым, отсекаем её в первом запросе по where priority>0 и сортировку оставляем, на небольшом количестве записей она мешать не будет. Во втором уже ни условия на priority, ни сортировки по нему нет - ненулевые поймает первый, до второго дело дойдёт только если он пустой.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776556
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Старый плюшевый мишка
Будем считать, что я неправильно понял, что извлечение данных из базы и отметка того, что запись принята к рассмотрнию, сведены в критической секции, а потоки растекаются мыслью по древу с полученными из неё, секции, данными, каждый со своей возвращаемой этой секцией строкой резалтсета.

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

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

Старый плюшевый мишкаЭто я тоже неправильно понял из
что 1 - приоритетные строки, 0 - нет. Если есть иерархия приоритетов и основная масса всё-таки с нулевым, отсекаем её в первом запросе по where priority>0 и сортировку оставляем, на небольшом количестве записей она мешать не будет. Во втором уже ни условия на priority, ни сортировки по нему нет - ненулевые поймает первый, до второго дело дойдёт только если он пустой.
Понял вашу логику. Приоритет меняется от 1 до 5 в двух используемых таблицах, думаю больше никому не потребуется, по умолчанию - 3. Обычно да, приоритет не меняют, но если все-таки поменяют, он сразу будет другим во многих записях. Т.е если сделать ускорение только для обычного приоритета, клиент будет недоумевать почему при обычном приоритете система работает быстро, а при критическом тормозит :)
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776570
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikВсе придумывают кто на что горазд: TOP, ROWS, FIRST. Стандарта видимо нет. ROWS - стандарт.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776573
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
WildSeryROWS - стандарт.
Хорошо бы микрософту об этом сказать
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776576
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSeryROWS - стандарт.

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

Код: plaintext
1.
[OFFSET n {ROW | ROWS}]
[FETCH {FIRST | NEXT} [m] {ROW | ROWS} ONLY]

гы. Теперь в Firebird аж 3 способа сделать одно и то же
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776592
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

Я имел в виду ISO SQL 2008, а не Firebird.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776597
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSery,

вот как раз там и есть тот синтаксис что я привёл. Его кстати почти во всех последних версиях SQL серверов прикрутили в том числе и в Oracle, MS SQL Server
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39776943
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 выполняется только у очень немногих записей.
Кажется считается, что индексы по таким столбцам неэффективны.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777101
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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 (это к примеру на предыдущей странице) и только по ним делать выборку:
Код: sql
1.
SELECT TaskID FROM Table2 WHERE Condition=1


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


Как сделать такой же эффективный один запрос я не знаю.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777107
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikОчевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку:
Код: sql
1.
SELECT TaskID FROM Table2 WHERE Condition=1



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



Как сделать такой же эффективный один запрос я не знаю.
Встряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем
Код: sql
1.
2.
SELECT .... FROM Table1  JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table2.Condition=1
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777108
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikОчевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку:
Код: sql
1.
SELECT TaskID FROM Table2 WHERE Condition=1



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



Как сделать такой же эффективный один запрос я не знаю.
Встряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем
Код: sql
1.
2.
SELECT .... FROM Table1  JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table2.Condition=1
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777117
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

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

зы
и даже без индексов, 50т записей в табличке с десятком целых полей - фильтр + сортировка + получение первой записи менее 50мс
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777208
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
m7mВстряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем
Код: sql
1.
2.
SELECT .... FROM Table1  JOIN Table2 ON Table1.TaskId=Table2.TaskId
WHERE Table2.Condition=1


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

зы
и даже без индексов, 50т записей в табличке с десятком целых полей - фильтр + сортировка + получение первой записи менее 50мс
так почти все поля и нужны (процентов 70), если все вносить в одну таблицу, то постоянно придется отслеживать все изменения в исходных, коих различных 6 штук, но вариант конечно рабочий
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777318
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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 просто удручающие
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777340
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

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

делай так

Код: sql
1.
2.
3.
SELECT COUNT(*)
FROM T1 JOIN T2 ....
WHERE <твой фильтр>



если этот запрос будет быстро работать, то и остальное заработает.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777353
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 - то ещё дольше.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777360
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikВ общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета

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

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

Molochnik50 тыс записей, 10 потоков, т.е. TextMarked=0 у 49990 записей.
это сегодня.
завтра у тебя 50К с 0 и 50К с 1
послезавтра - 50К с 0 и 100К с 1
через месяц - 50К с 0 и 3М с 1
и т.д.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777364
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дегтярев Евгенийне первый раз говорят - сделайте отдельную узкую таблицу для очереди

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

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

но захват пачки заданий становится максимально быстрым и вообще без возможных пересечений с конкурентами
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777369
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikПоследние результаты для FB просто удручающие

а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777385
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

20 сек - это, конечно, сильно. Может анализ производительности в Эксперте посмотрим? План?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777414
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
AriochMolochnikПоследние результаты для 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 просто смерть какая-то.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777436
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik Но INNER JOIN просто смерть какая-то.
Вот тут ты не прав
нельзя просто так заменить LEFT JOIN на INNER JOIN
ибо это совершенно разные запросы и
совершенно разные результаты выполнения

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

ззы. то что я написал относилось конкретно к тем двум запросам что были в сообщении
и никак не означало что надо заменить LEFT JOIN на INNER JOIN в твоем исходном запросе
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777539
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikAriochпропущено...

а если перед запуском запроса выключать службы 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 для того, чтобы он не использовал заведомо вредные для этого конкретного запроса индексы. В смысле чтобы добиться среднестатистической оптимальности, по наиболее распространённому случаю. Кстати, сортировки тоже тормозят тем сильнее, чем больше дубликатов по этим полям. Если их нет, то почти что с сортировкой, что без.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777543
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов ДенисMolochnik,

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

делай так

Код: sql
1.
2.
3.
SELECT COUNT(*)
FROM T1 JOIN T2 ....
WHERE <твой фильтр>



если этот запрос будет быстро работать, то и остальное заработает.
Потестировал ваш вариант, оставил одно поле
Код: sql
1.
COUNT(*) 

и убрал
Код: sql
1.
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 в общем то доказывают.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777553
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
m7mне видя ни структур таблиц, ни планов, ни запросов
мы тебе тут много чего насоветуем

ззы. то что я написал относилось конкретно к тем двум запросам что были в сообщении
и никак не означало что надо заменить LEFT JOIN на INNER JOIN в твоем исходном запросе
Реально там нет ничего интересного, ну вообще ничего, 6 таблиц джойнятся с разными несложными разумными условиями, никаких нестед таблиц или сложных конструкций, две таблицы большие да, по 200 тыс записей, джойнятся один к одному по полю, которое в одной таблице уникально, остальные таблицы по 1-3 записи. Основная проблема судя по всему - очень много одинаковых значений по полям, которые используется при сортировке и фильтре.
Старый плюшевый мишкаДа план меняется просто при заменах inner-left. Порядок перебора таблиц и, соответственно, используемые индексы. При left порядок задан жёстко, при inner его определяет оптимизатор. Опираясь на статистику индексов. Но он не знает сколько у тебя в какой таблице дубликатов по индексам и, бывает, оптимизирует не в ту сторону. А у тебя их, дубликатов, сорок бочек арестантов. Но ты-то об этом знаешь, так и направляй оптимизатора через +0 для того, чтобы он не использовал заведомо вредные для этого конкретного запроса индексы. В смысле чтобы добиться среднестатистической оптимальности, по наиболее распространённому случаю. Кстати, сортировки тоже тормозят тем сильнее, чем больше дубликатов по этим полям. Если их нет, то почти что с сортировкой, что без.
Это пока для меня слишком сложно, я сейчас почитаю как работает FB (ссылку дали). Но что интересно, если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять" :)
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777561
Фэйтл Эра
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnikесли у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять"
Ты просто пока не сталкивался. Например, выполни поиск слова "хинт" в форуме https://www.sql.ru/forum/microsoft-sql-server.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777573
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik,

упрости запрос по максимуму на которых проявляются тормоза. Приведи его здесь, статистику выполнения и explain план запроса.
Кстати в MS SQL ном варианте тоже хотелось бы на план взглянуть
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777588
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikЭто пока для меня слишком сложно, я сейчас почитаю как работает FB (ссылку дали). Но что интересно, если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять" :)

IBExpert внизу, вместе со временем выполнения, показывает пресловутый план. Перечень использованных индексов. Причём они перечисляются в порядке перебора таблиц, на которых они созданы. То есть, индексы таблицы, от которой начинается перебор, идут первыми (если она вообще не идёт натуралом), первого уровня подчинённости - вторыми и так далее. Скажем, условие "on t1.id=t2.id" в иннер может быть выполнено как перебором t1 с подтягиванием записей из t2 по индексу на t2, так и наоборот. Посмотри на план и прикинь как ТЫ бы это делал сам, ручками, чтобы не за... за... устать, в общем. И если оптимизатор сделал наоборот, то имеем то, что имеем, и надо вправлять ему мозги подзатыльником. Типа "on t1.id+0=t2.id". Тогда t1 точно будет ведущей, а t2 подтягиваться по индексу.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777596
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов Денис
Старый плюшевый мишка
Да все сделаю, посмотрю и проверю
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777936
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Старый плюшевый мишкаIBExpert внизу, вместе со временем выполнения, показывает пресловутый план

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

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

вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777942
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дегтярев Евгенийсделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей


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

едва ли критерии распределения тасков по разным типов воркеров менются часто
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39777971
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AriochСтарый плюшевый мишкаIBExpert внизу, вместе со временем выполнения, показывает пресловутый план

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

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

вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше
MSSQL "жует" _многостраничные_ _автогенерируемые_ запросы 1С, например.

А вы тут к каждому индексу цепляетесь.... =)
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39778000
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglAriochпропущено...


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

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

вполне возможно, что часть преимущества MS SQL просто в бОльшем кэше
MSSQL "жует" _многостраничные_ _автогенерируемые_ запросы 1С, например.

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

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

Для по-настоящему больших задач все равно динозавры-оракулы.
Наша ниша - маленькие теплокровные млекопитающие(ся).
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39778045
Фэйтл Эра
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglMSSQL "жует" _многостраничные_ _автогенерируемые_ запросы 1С, например.

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

Чудо-СУБД не существует.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39778092
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AriochДегтярев Евгенийсделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей
....а если таски настолько разные, что полей надо мноооого и узко не получается
хрень если так, очень даже хрень
на до даже в этом случае есть решение

зы
сорри за резкость, в сибири пятница празднуется во всю
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39792652
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дегтярев ЕвгенийMolochnikСмысл этого простой - очередь. Каждый поток по очереди выбирает первую доступную запись для обработки и помечает ее как используемую. Если потоки будут читать одновременно они могут выбрать одну и туже запись.

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

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

Опять вернулся к этой задаче и к вашему методу решения. Интересно что у меня примерно так раньше (лет 10 назад) так и работало, когда один поток лазил в базу и создавал очередь заданий в памяти (кэш), к которой уже обращались потоки обработчики, не лазящие в базу. Потом я бросил этот способ, поскольку:
1) кэш иногда переполнялся, если ни одному потоку не нужна была запись долгое время (а может и не вовсе не пригодилась бы),
2) приходилось отслеживать его актуальность, если таблица менялась сторонней программой,
3) иногда нужной записи не было в кэше и поток простаивал.
Все это конечно решалось, но выглядело сложно и уродливо, и я бросил этот способ в пользу теперешней схемы. Если рассматривать вариант без кэша, когда данные берутся из таблицы только когда они реально нужны (онлайн), то в чем тогда преимущество одного потока перед несколькими потоками, работающими через критическую секцию? В оверхеде работы критической секции? Это разве не "ловля блох"? Хотя потоков может быть и штук двести.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39792736
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik3) иногда нужной записи не было в кэше и поток простаивал

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

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

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

зызы
мне кажется, что в вашем случае при удачной организации структуры таблиц и индексов можно решить задачу на уровне бд
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39903019
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дегтярев Евгений,
Жаль в форуме нет кнопки "проблема решена", а то можно было бы нажать.
Все сделал как здесь вы и другие советовали:
1) В базу лазит только один поток (супервизор), он регулярно создает небольшую очередь (ThreadList) для чтения для каждого из типов потоков-обработчиков и еще одну - для записи в базу. Типов потоков-обработчиков обычно мало (как правило один). Кэш при любых изменениях базы из сторонней программы очищается.
2) Потоки обработчики работают: берут Item из одной очереди, обрабатывают его и кладут в другую. Поток-супервизор регулярно обновляет базу записывая все изменения в одной транзакции и очищая очередь записи.
3) Аккуратно сгладил все потенциальные затыки и сейчас уже при 10ти потоках этот механизм работает намного веселее а при 200х - вообще небо и земля
4) Также изначально с FB была проблема, что выборка по условию осуществлялась долго, если поле условия (приоритет) находится в отдельной таблице и везде одинаково (В MS SQL этой проблемы не было). Поэтому сделал дополнительное поле в основной таблице выборки, куда и дублирую значение приоритета. Все стало работать идеально: со скоростью сравнимой с MS SQL (всего раза в 2-3 медленннее, а не на 3 порядка на 50 тыс записей).
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39903360
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вот это поворот
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39913053
Troglodit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2Molochnik,
Прочитал все пять страниц взахлеб. Свежо, интригующе.
У меня только один вопрос.
WTF?
Я понимаю, что задача как минимум взломать пентагон, но
все же можно доступным языком понять что именно за хрень за шедевр вы автоматизируете?
Т.е. именно постановка задачи, а не ваша реализация.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39913059
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Троглодиты среди нас. =8-[ ]
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39915143
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Troglodit,
там реально было две проблемы.
1) Первая, медленно запрос делался. Сейчас есть свободное время, сделал тесты, урезал базу и запрос до минимума. Вот что получилось:
Сама заполненная база - ссылка (ссылка неделю хранится)

Медленный запрос:
Код: sql
1.
2.
3.
4.
SELECT ActiveTaskContacts.*
FROM ActiveTaskContacts LEFT JOIN Contacts ON Contacts.ContactId=ActiveTaskContacts.ContactId
ORDER BY Contacts.Priority ASC
ROWS 1


Быстрый запрос по "лишнему полю" Priority, которое оказалось совсем нелишним и с помощью которого я обошел проблему (здесь посоветовали):
Код: sql
1.
2.
3.
4.
SELECT ActiveTaskContacts.*
FROM ActiveTaskContacts LEFT JOIN Contacts ON Contacts.ContactId=ActiveTaskContacts.ContactId
ORDER BY ActiveTaskContacts.Priority ASC
ROWS 1



2) Вторая, много потоков, каждый из которых лазил в базу на чтение и на запись. Работало на небольшом числе потоков, но очень плохо масштабировалось. Если потоков становилось несколько десятков уже довольно сильно тормозило, а если их сотня система вообще становилась неработоспособной. Эту я решил сделав один поток работающим с базой, а остальные потоки работающими с очередями запросов.

Вложенный файл таблицы стилей это я просто тесты с форумом проводил - не мог поверить что 150 кб это максимум (архив базы у меня 500 занимает). Причем удалить сылку уже нельзя как я понял.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39915713
Troglodit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Molochnik
Troglodit,
там реально было две проблемы.
1) Первая, медленно запрос делался. Сейчас есть свободное время, сделал тесты, урезал базу и запрос до минимума. Вот что получилось:
Сама заполненная база - ссылка (ссылка неделю хранится)

Медленный запрос:
Код: sql
1.
2.
3.
4.
SELECT ActiveTaskContacts.*
FROM ActiveTaskContacts LEFT JOIN Contacts ON Contacts.ContactId=ActiveTaskContacts.ContactId
ORDER BY Contacts.Priority ASC
ROWS 1


Быстрый запрос по "лишнему полю" Priority, которое оказалось совсем нелишним и с помощью которого я обошел проблему (здесь посоветовали):
Код: sql
1.
2.
3.
4.
SELECT ActiveTaskContacts.*
FROM ActiveTaskContacts LEFT JOIN Contacts ON Contacts.ContactId=ActiveTaskContacts.ContactId
ORDER BY ActiveTaskContacts.Priority ASC
ROWS 1



2) Вторая, много потоков, каждый из которых лазил в базу на чтение и на запись. Работало на небольшом числе потоков, но очень плохо масштабировалось. Если потоков становилось несколько десятков уже довольно сильно тормозило, а если их сотня система вообще становилась неработоспособной. Эту я решил сделав один поток работающим с базой, а остальные потоки работающими с очередями запросов.

Вложенный файл таблицы стилей это я просто тесты с форумом проводил - не мог поверить что 150 кб это максимум (архив базы у меня 500 занимает). Причем удалить сылку уже нельзя как я понял.

Это все очень познавательно, но , внезапно, у меня опять 2 вопроса.
1. Зачем вам автор LEFT JOIN Contacts ON Contacts.ContactId=ActiveTaskContacts.ContactId во втором запросе, вы явно не используете contacts, пытаетесь запутать оптимизатор?
2. Что именно тормозит можете по человечески объяснить.
2.1 Это вашe приложение на delphi? может проще воспользоваться готовыми проверенными очередями, которые работают без проблем? По моей памяти с мультитредом в делфи все очень плохо. Вы давно слышали фразу "Гляди какой классный http-сервер, наверно он написан на Delphi"?
2.2 СУБД? крайне странно с учетом малого количества потоков. В мое время птица спокойно держала десятки коннектов в рабочем порядке на железе 15 летней давности. Думаю текущая версия еще лучше.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39915730
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Troglodit

Это все очень познавательно, но , внезапно, у меня опять 2 вопроса.
1. Зачем вам автор LEFT JOIN Contacts ON Contacts.ContactId=ActiveTaskContacts.ContactId
во втором запросе, вы явно не используете contacts, пытаетесь запутать оптимизатор?
2. Что именно тормозит можете по человечески объяснить.
2.1 Это вашe приложение на delphi? может проще воспользоваться готовыми проверенными очередями, которые работают без проблем? По моей памяти с мультитредом в делфи все очень плохо. Вы давно слышали фразу "Гляди какой классный http-сервер, наверно он написан на Delphi"?
2.2 СУБД? крайне странно с учетом малого количества потоков. В мое время птица спокойно держала десятки коннектов в рабочем порядке на железе 15 летней давности. Думаю текущая версия еще лучше.
Ответы
1. Почему не использую? Contacts не используется в тестовом примере, а вообще используется, причем много полей
2. Просто можете проверить выполнение запроса в IBExpert, первый ("медленный") выполняется на этой базе у меня около 200 мс, а второй ("быстрый") - мгновенно. Причем с увеличением числа записей скорость "меленного" падает в геметрической прогрессии. Причем:
а) в запросе нет условий и берется всего одна запись (по логике первая попавшаяся) и запрос по идее не должен тормозить
б) значение поля приоритета везде одинаковое, но индекс по нему в ActiveTaskContacts очень важен и без него "быстрый" запрос выполняется также медленно. Где то на форуме давно читал что в firebird/interbase по маломеняющемуся полю индексы смысла нет строить. Этот же пример говорит об обратном - индекс точно нужен даже для неменяющегося поля.
в) в то же время индекс по полю приоритета в таблице Contacts не влияет на скорость
г) в MS SQL скорость выполнения обоих запросов одинаково быстрая и независимая от наличия индексов (быстрее "быстрого" запроса в Firebird раза в три), т.е. именно так и должно быть по логике запроса (достань первую попавшуюся запись)
2.1 Здесь все нормально, в Дельфях сейчас все хорошо и с потоками и параллелелизмом, сам пользуюсь TThread, TThreadList и TParallel когда по смыслу надо. С TThreadedQueue у меня не заладилось, возможностей мало, проще здесь свое было сделать. Сейчас тестировал на ноутбуке 400 потоковую систему, тормозов нет вообще, все идеально работает.
2.2 сейчас использую FB 3.0. Коннекты держит, не падает, это точно, но даже визуально (у меня работа потоков визуализирована) видно что схема с одним потоком "базы" работает на порядок быстрее уже при 10 потоках-обработчиках. При схеме с одним потоком в базу много запросов выполняется в одной траназкции и это сильно ускоряет дело.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39915752
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik Где то на форуме давно читал что в firebird/interbase по маломеняющемуся полю индексы смысла нет строить.
гм, что? Может, не по "маломеняющемуся", а по имеющему сильно мало разных значений относительно количества записей? И то тут ситуации разные бывают, в зависимости от распределения таких значений.

Судя по вашим описаниям, вы просто "тыкаете палочкой в Firebird", хотя уже давно можно было разобраться, по статьям и видео.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39915754
vvvait
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
если заменить left join на join, то медленный запрос становится быстрым
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39915759
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vvvait,

а если поставить SSD вместо HDD, то запрос становится еще быстрее.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39915784
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv,
Да, имел ввиду поле с малым разнообразием значений, в данном случае их максимальное количество 5 но обычно используется одно
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39916867
Troglodit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Molochnik
Troglodit

Это все очень познавательно, но , внезапно, у меня опять 2 вопроса.
1. Зачем вам пропущено...
во втором запросе, вы явно не используете contacts, пытаетесь запутать оптимизатор?
2. Что именно тормозит можете по человечески объяснить.
2.1 Это вашe приложение на delphi? может проще воспользоваться готовыми проверенными очередями, которые работают без проблем? По моей памяти с мультитредом в делфи все очень плохо. Вы давно слышали фразу "Гляди какой классный http-сервер, наверно он написан на Delphi"?
2.2 СУБД? крайне странно с учетом малого количества потоков. В мое время птица спокойно держала десятки коннектов в рабочем порядке на железе 15 летней давности. Думаю текущая версия еще лучше.

Ответы
1. Почему не использую? Contacts не используется в тестовом примере, а вообще используется, причем много полей
2. Просто можете проверить выполнение запроса в IBExpert, первый ("медленный") выполняется на этой базе у меня около 200 мс, а второй ("быстрый") - мгновенно. Причем с увеличением числа записей скорость "меленного" падает в геметрической прогрессии. Причем:
а) в запросе нет условий и берется всего одна запись (по логике первая попавшаяся) и запрос по идее не должен тормозить
б) значение поля приоритета везде одинаковое, но индекс по нему в ActiveTaskContacts очень важен и без него "быстрый" запрос выполняется также медленно. Где то на форуме давно читал что в firebird/interbase по маломеняющемуся полю индексы смысла нет строить. Этот же пример говорит об обратном - индекс точно нужен даже для неменяющегося поля.
в) в то же время индекс по полю приоритета в таблице Contacts не влияет на скорость
г) в MS SQL скорость выполнения обоих запросов одинаково быстрая и независимая от наличия индексов (быстрее "быстрого" запроса в Firebird раза в три), т.е. именно так и должно быть по логике запроса (достань первую попавшуюся запись)
2.1 Здесь все нормально, в Дельфях сейчас все хорошо и с потоками и параллелелизмом, сам пользуюсь TThread, TThreadList и TParallel когда по смыслу надо. С TThreadedQueue у меня не заладилось, возможностей мало, проще здесь свое было сделать. Сейчас тестировал на ноутбуке 400 потоковую систему, тормозов нет вообще, все идеально работает.
2.2 сейчас использую FB 3.0. Коннекты держит, не падает, это точно, но даже визуально (у меня работа потоков визуализирована) видно что схема с одним потоком "базы" работает на порядок быстрее уже при 10 потоках-обработчиках. При схеме с одним потоком в базу много запросов выполняется в одной траназкции и это сильно ускоряет дело.

1. Телепаты в отпуске. Тупая вводная->тупой комментарий.
б) маломеняющееся поле, что это за зверь применимый к индексу. Индексу плохо только когда поле имеет мало уникальных значений.
в) т.е. в сортировке он не участвует?
г) настройки птицы и mssql одинаковые?
2.1 Вы уверены, что делфевая реализация потоков,сервисов не медленная по сравнению с традиционным стэком серверных ЯП?
2.2 А не следует ли скорость 1 поток базы ->10 потоков в ваших терминах,что вы не реализовали коннектпул, и все ваше богатство в скорости, что в каждом потоке вы создаете новый коннект к примеру?
"При схеме с одним потоком в базу много запросов выполняется в одной траназкции" Это вообще за гранью моего понимания. Если вы перемешиваете запросы из разных потоков в 1-й транзакции-это феерический выстрел в ногу.
Если вам нужна очередь используйте готовые вещи, что умные дядьки не чета нам сирым и убогим написали. И вы удивитесь скорости и надежности.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39916987
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnikно обычно используется одно
если в столбце одно значение, то в индексе один ключ, и индекс такой тогда нахрен не нужен. Он будет жрать память при поиске, и добавлять тормоза при ресторе.
Понятно, что поиск по одному значению - бессмыслица. Смыслица может быть только если по этому столбцу ищутся НЕСУЩЕСТВУЮЩИЕ значения. Например, там только 1 (или даже 0 и 1), а ищется 2 или 3. Тогда индекс будет ОЧЕНЬ полезен, моментально выдавая, что таких ключей нет.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917284
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv
если в столбце одно значение, то в индексе один ключ, и индекс такой тогда нахрен не нужен. Он будет жрать память при поиске, и добавлять тормоза при ресторе.
Понятно, что поиск по одному значению - бессмыслица. Смыслица может быть только если по этому столбцу ищутся НЕСУЩЕСТВУЮЩИЕ значения. Например, там только 1 (или даже 0 и 1), а ищется 2 или 3. Тогда индекс будет ОЧЕНЬ полезен, моментально выдавая, что таких ключей нет.

Есть и менее очевидные выгоды от индекса по "слабоселективному" полю.

Например, есть таблица в 100 полей, одно из которых F и есть "слабоселективное" поле.
Нужно часто вычислять select F, count(*). Скан индекс по полю F будет работать быстрее чем скан всех данных таблицы.

PS
Да, какое-нибудь материализованное агрегатное вью или колоночное хранение выиграют у простого индекса по полю F, но мы же сравниваем варианты с наличием и отсутствием этого индекса.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917297
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex,

смотря где. В Firebird или не будет или даст очень слабый прирост, если конечно там больше 1 уникального значения.
Нету у нас only index scan
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917369
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Troglodit

б) маломеняющееся поле, что это за зверь применимый к индексу. Индексу плохо только когда поле имеет мало уникальных значений.
в) т.е. в сортировке он не участвует?
г) настройки птицы и mssql одинаковые?
2.1 Вы уверены, что делфевая реализация потоков,сервисов не медленная по сравнению с традиционным стэком серверных ЯП?
2.2 А не следует ли скорость 1 поток базы ->10 потоков в ваших терминах,что вы не реализовали коннектпул, и все ваше богатство в скорости, что в каждом потоке вы создаете новый коннект к примеру?
"При схеме с одним потоком в базу много запросов выполняется в одной траназкции" Это вообще за гранью моего понимания. Если вы перемешиваете запросы из разных потоков в 1-й транзакции-это феерический выстрел в ногу.
Если вам нужна очередь используйте готовые вещи, что умные дядьки не чета нам сирым и убогим написали. И вы удивитесь скорости и надежности.

б) Это поле (Priority) имеет не мало, а "одно" значение. Индексу может и плохо но запросу хорошо.
в) Участвует, в запросе это видно невооруженным взглядом
г) fb настройки оптимизированные, ms sql все по умолчанию
2.1 Исходные коды всех дельфийских реализаций присуствуют, там очень быстрый спуск на нижний уровень WinApi, чтото там новое делать это ловить блох
2.2 Да раньше каждый поток создавал полностью независимое соединение по которому соединялся с БД в начале своей работы и отключался в конце. А потоки работали все время работы программы. Так что можно конечно такую реализацию и пулом назвать просто "пулом постоянных соединений". В другом месте у меня переменное число потоков (обработка сетевых запросов) разного времени жизни, там как раз нормальный пул: коннекты по мере надобности создаются и живут своей жизнью. Изредка происходит очистка.
Обрабатываеть в одной транзакции данные от разных потоков согласен в общем случае может и не совсем верно. Но в данном случае все хорошо - запросы же одни и же просто с разными параметрами. Если теоретически один запрос завалит всю транзакцию (реально это невозможно) ничего страшного, в следующий раз пройдет.
"Умные дядьки" уже придумали вместо критических секций использовать TMonitor, который вроде как быстрее, я туда и не лезу, может и правда быстрее, надежность точно не ниже.

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

если в столбце одно значение, то в индексе один ключ, и индекс такой тогда нахрен не нужен. Он будет жрать память при поиске, и добавлять тормоза при ресторе.
Понятно, что поиск по одному значению - бессмыслица. Смыслица может быть только если по этому столбцу ищутся НЕСУЩЕСТВУЮЩИЕ значения. Например, там только 1 (или даже 0 и 1), а ищется 2 или 3. Тогда индекс будет ОЧЕНЬ полезен, моментально выдавая, что таких ключей нет.

Да, значение в поле только одно, по нему сортировка и индекс очень даже нужен оказывается.
Так чего говорить то? база есть - скачать, зарегистрировать в айбиэксперте и выполнить указанные запросы, потом удалить индекс и опять выполнить. У меня часто бывает что клиент видит сразу то чего не вижу я, может и здесь так же
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917503
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLexНужно часто вычислять select F, count(*). Скан индекс по полю F будет работать быстрее чем скан всех данных таблицы.
в Firebird такого нет. Индекс содержит все значения всех версий записи (стольбца), но не содержит номеров транзакций, поэтому по индексу нельзя определить, можно конкретной транзакции видеть некий ключ, или нельзя.
Определить это можно только читая версию записи.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917504
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikТак чего говорить то? база есть - скачать, зарегистрировать в айбиэксперте и выполнить указанные запросы, потом удалить индекс и опять выполнить
если это предложение в мою сторону, то увы - я бесплатно не работаю. Да и вообще, мы оптимизируем системы комплексно, "от 70к руб и полутора месяцев".
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917525
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv
MolochnikТак чего говорить то? база есть - скачать, зарегистрировать в айбиэксперте и выполнить указанные запросы, потом удалить индекс и опять выполнить

если это предложение в мою сторону, то увы - я бесплатно не работаю. Да и вообще, мы оптимизируем системы комплексно, "от 70к руб и полутора месяцев".
А ясно, значит на форуме просто так, палкой воду мутите. Если вы не заметили, то я вам не работу предлагал, а возможность убедиться в собственной неправоте (или правоте). Но если вам это неинтересно, то мне тем более, можете проходить мимо, просто троглодит заинтересовался, пришлось напрячься.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917529
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molochnik
kdv
пропущено...

если это предложение в мою сторону, то увы - я бесплатно не работаю. Да и вообще, мы оптимизируем системы комплексно, "от 70к руб и полутора месяцев".

А ясно, значит на форуме просто так, палкой воду мутите. Если вы не заметили, то я вам не работу предлагал, а возможность убедиться в собственной неправоте (или правоте). Но если вам это неинтересно, то мне тем более, можете проходить мимо, просто троглодит заинтересовался, пришлось напрячься.


Ну словами-то не бросайся
Для того чтобы убедиться совершенно не обязательно скачивать твою базу, ибо с этими двумя запросами и так все ясно
А вот насколько именно такие запросы нужны это тебе виднее
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917546
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikА ясно, значит на форуме просто так, палкой воду мутите. Если вы не заметили, то я вам не работу предлагал, а возможность убедиться в собственной неправоте (или правоте).
у меня несколько другой подход. Я предпочитаю дать системные знания. Например, на сайте есть статья
http://www.ibase.ru/dataaccesspaths/
(и другие) про оптимизатор.
На ютубе сделали несколько роликов про оптимизатор
https://www.youtube.com/user/ibdeveloper/videos
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917555
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolochnikДа, значение в поле только одно, по нему сортировка и индекс очень даже нужен оказывается.
кстати, в чистом виде вот такой вывод - ахинея полная.
Потому что сортировать N записей с одним значением в столбце - это пустая трата времени, и индекс тут абсолютно лишний, потому что ключи в этом индексе всё равно одинаковые. На эту тему есть специальное видео и статья
http://www.ibase.ru/files/articles/performance/Firebird Optimizer - ORDER vs SORT.pdf
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39917610
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv

кстати, в чистом виде вот такой вывод - ахинея полная.


Не только вывод. Налицо классический стук в подвале. DDL нет, планов нет, запрос не реальный, а "иллюстративная" вырезка. Наличие бредового индекса на короткой таблице случайно привело к отказу от использования не менее бредового на длинной, вот и вся нЕдолга. Чего можно было добиться и традиционными средствами.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39918145
Troglodit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Molochnik

б) Это поле (Priority) имеет не мало, а "одно" значение. Индексу может и плохо но запросу хорошо.
в) Участвует, в запросе это видно невооруженным взглядом
г) fb настройки оптимизированные, ms sql все по умолчанию
2.1 Исходные коды всех дельфийских реализаций присуствуют, там очень быстрый спуск на нижний уровень WinApi, чтото там новое делать это ловить блох
2.2 Да раньше каждый поток создавал полностью независимое соединение по которому соединялся с БД в начале своей работы и отключался в конце. А потоки работали все время работы программы. Так что можно конечно такую реализацию и пулом назвать просто "пулом постоянных соединений". В другом месте у меня переменное число потоков (обработка сетевых запросов) разного времени жизни, там как раз нормальный пул: коннекты по мере надобности создаются и живут своей жизнью. Изредка происходит очистка.
Обрабатываеть в одной транзакции данные от разных потоков согласен в общем случае может и не совсем верно. Но в данном случае все хорошо - запросы же одни и же просто с разными параметрами. Если теоретически один запрос завалит всю транзакцию (реально это невозможно) ничего страшного, в следующий раз пройдет.
"Умные дядьки" уже придумали вместо критических секций использовать TMonitor, который вроде как быстрее, я туда и не лезу, может и правда быстрее, надежность точно не ниже.

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

если в столбце одно значение, то в индексе один ключ, и индекс такой тогда нахрен не нужен. Он будет жрать память при поиске, и добавлять тормоза при ресторе.
Понятно, что поиск по одному значению - бессмыслица. Смыслица может быть только если по этому столбцу ищутся НЕСУЩЕСТВУЮЩИЕ значения. Например, там только 1 (или даже 0 и 1), а ищется 2 или 3. Тогда индекс будет ОЧЕНЬ полезен, моментально выдавая, что таких ключей нет.

Да, значение в поле только одно, по нему сортировка и индекс очень даже нужен оказывается.
Так чего говорить то? база есть - скачать, зарегистрировать в айбиэксперте и выполнить указанные запросы, потом удалить индекс и опять выполнить. У меня часто бывает что клиент видит сразу то чего не вижу я, может и здесь так же

б) вообще непонятно зачем поле с сортировкой,в котором 1 значение.
в) ну значит я пацифист, и глаза пацифистские
г) Без комментариев, меня еще в школе отучили сравнивать груши и помидоры.
2.1 Без обид, но выбор делфи в таких задачах, это клиническая ошибка. При чем здесь winapi. На нем и бешенной обезъяне пытаются лепить на андроиде и даже вебсервер я когда то видел, но это не отменяет факта, что делфи было не про то. У него до сих пор есть своя очень уже узкая ниша (славься эмбаркадеро), но использовать в бэкенде-это надо очень сильно ненавидеть своих заказчиков.
2.2 " коннекты по мере надобности создаются и живут своей жизнью"-это не коннекшнпул, у вас беда с матчастью.
"Умные дядьки"-это те кто юзает HighLoad, а не пинает труп мертвой коровы. Я что то не слышал про классный софт с очередями на делфи.
Почему же каффка, rabitmq не на делфи. Странно.
Ваш идеал, это повышенное ЧСВ, если вам так важны потоки, с оговорками посмотрите сколько котлин корутин вам выдаст, будете долго думать. На реальных данных, в 100-500гб вас ждет еще много открытий, когда ваше волшебное приложение превратиться в тыкву.
У меня давно был случай. В одну контору много лет назад принудительно заставили внедрить софт от очередного гения, угадайте на каком языке этот софт был. У него все летало. На нашем объеме данных, все умерло так и не родившись, в итоге программу поставили, под ковер ее зачистили, галочку поставили и выдохнули.

Зачем наезжать на kdv? Он уже забыл то, что мы может быть узнаем. :)
Вы хоть узнайте на кого вы бросаетесь. :)
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39918232
Василий 2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Troglodit
делфи было не про то. У него до сих пор есть своя очень уже узкая ниша (славься эмбаркадеро), но использовать в бэкенде-это надо очень сильно ненавидеть своих заказчиков.


авторкотлин

Ахаха, опускать Дельфи и восхвалять надстройку над Джавой для бэкенда - это сильно!
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39918476
Troglodit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Василий 2

Ахаха, опускать Дельфи и восхвалять надстройку над Джавой для бэкенда - это сильно!

У вас видимо пятница пораньше началась.
Где я восхвалял котлин?
И почему нельзя использовать JVM-языки на бэкенде можете просветить?
И кто сказал, что Kotlin надстройка над java?
Kotlin (Ко́тлин) — статически типизированный язык программирования, работающий поверх JVM и разрабатываемый компанией JetBrains. Также компилируется в JavaScript и в исполняемый код ряда платформ через инфраструктуру LLVM.

*
Делфи я не опускал, он более чем мертв очень давно, просто по медицинским показателям формально еще жив.
Что для меня прискорбно.
*
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39918485
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
24.01.2020 17:09, Troglodit пишет:
>
> И почему нельзя использовать JVM-языки на бэкенде можете просветить?

потому, что ГОВНО.
сужу по Oracle SQL Developer.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39918490
Troglodit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Мимопроходящий

24.01.2020 17:09, Troglodit пишет:
>
> И почему нельзя использовать JVM-языки на бэкенде можете просветить?

потому, что ГОВНО.
сужу по Oracle SQL Developer.

Вы точно про бэкенд, а не фронт говорите?
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39918513
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис
msLex,

смотря где. В Firebird или не будет или даст очень слабый прирост, если конечно там больше 1 уникального значения.
Нету у нас only index scan

Упс...
Будем считать что я писал только про SQL Server
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39918514
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv
в Firebird такого нет. Индекс содержит все значения всех версий записи (стольбца), но не содержит номеров транзакций, поэтому по индексу нельзя определить, можно конкретной транзакции видеть некий ключ, или нельзя.
Определить это можно только читая версию записи.


Понятно, спасибо за инфу.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39918634
Molochnik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Troglodit

б) вообще непонятно зачем поле с сортировкой,в котором 1 значение.

я же его не сделал его уникальным, пусть одно значение будет
Troglodit

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

задача то одна - сохранить много и быстро достать одно, впрочем как и у груш с помидорами
Troglodit

2.1 Без обид, но выбор делфи в таких задачах, это клиническая ошибка

Странно, но у меня все работает и быстро, кастомеров устраивает. Но правда бэкэнд использует не только дельфи, там скорее мидлэнд (клиенты, база, потоки), нижняя часть чисто сишная. С потоками я уже сказал проблем пока нет, возможно появятся с обработкой многих клиентов если их будет несколько сотен одновременно, но такого пока не было, поэтому по индукции считаем что такого не бывает никогда.
Troglodit

Зачем наезжать на kdv? Он уже забыл то, что мы может быть узнаем. :)

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

Вы хоть узнайте на кого вы бросаетесь. :)

Смысла нет - тут айкью форума зашкаливает. Я тоже не лыком шит - в детстве Олимпиаду городскую по физике выиграл!
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39918738
Troglodit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Molochnik

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

1. Ответ достойный Сократа.
2. Сохранить много и быстро и наверно еще надо добавлять надежно, это каффка, а не ваш велосипед. Но судя по тому, что вы описывали ранее объем данных у вас очень малый, поэтому каффка-это как микроскопом забивать гвозди, но то, что вы собственные костыли внедряете клиентам вместо устоявшихся,проверенных инструментов-это просто показатель вашей квалификации, вашей ответственности перед клиентами.
3. Есть и еще одна часть самописная часть, уже на си. Прэлестно, просто прэлестно. Я уже выше писал, как только пойдут объемы данных ваш софт превратиться в тыкву, особенно будет интересно когда ресурсов на сервере перестанет хватать.
5. Смысл всегда есть осмотреться, чтобы понять кто есть ваш собеседник. Но это видимо только участь моего поколения.
Я уверен, что ваш зоопарк технологий в данном случае как то работает, но для эксплуатации это ад. Вы внедрили и уехали в другой город/страну/галактику, а потом кто то будет разгребать ваш шедевральный софт. Скорее всего дело закончиться тем, что ваше поделие аккуратно выпилят и сделают как положено, но ваш клиент потеряет время и деньги. Дальше не вижу смысла со своей стороны вмешиваться в дискуссию.
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39919171
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так-с, горячие парни. Попрошу!

...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39919179
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSery
Так-с, горячие парни. Попрошу!
на этой картинке надпись была...
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39919206
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSery
Так-с, горячие парни. Попрошу!



Дарю на такие случАи
[spoiler]
YouTube Video
...
Рейтинг: 0 / 0
Firebird vs MS SQL
    #39919266
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Залетные бранятся — только тешатся.
...
Рейтинг: 0 / 0
143 сообщений из 143, показаны все 6 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird vs MS SQL
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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