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

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

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

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

Может.

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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