Время выполнения запроса

[Dimitry Sibiryakov]

Да мне этот индекс нужен - у меня полно отчетов с выборкой по starttime.

И ты абсолютно уверен, что этот индекс им помогает, а не мешает?

[pticelov]

Уверен. Чем может мешать этот индекс в отчете вроде
select userid,sum(length),count(*) from outcalls where starttime >= ... and starttime <= ... group by userid

Это для отчета о работе дспетчеров, обслуживавших вызовы

в базе - миллионы записей

не исключено, что в данном случае мешающим может оказаться индекс по userid Но вообще-то мне до сих пор казалось, что это sql сервер должен разбираться, кто ему мешает, а кто - нет

[kdv]

Правда у embedded, конечно, грабля неприятная - одно соединение к БД и все. jet позволяет несколько соединений.

Я имел в виду именно от разных. Хочется иметь возможность заглянуть в БД не прибивая приложение.

еще пара таких откровений, и забаню с одновременным посылом в FAQ.
Jet это файл-серверный движок, он не может не позволять другим Jet-ам подключаться к файлам бд.
Embedded - это dll, которая вместе с exe представляет собой СЕРВЕР. А в клиент-сервере кроме сервера никто к базе подсоединиться не может.

[pticelov]

Правда у embedded, конечно, грабля неприятная - одно соединение к БД и все. jet позволяет несколько соединений.

Я имел в виду именно от разных. Хочется иметь возможность заглянуть в БД не прибивая приложение.

еще пара таких откровений, и забаню с одновременным посылом в FAQ.
Jet это файл-серверный движок, он не может не позволять другим Jet-ам подключаться к файлам бд.
Embedded - это dll, которая вместе с exe представляет собой СЕРВЕР. А в клиент-сервере кроме сервера никто к базе подсоединиться не может.

Откровение, простите, в чем? В том, что jet позволяет разным приложениям коннектится к одной БД, а embedded firebird нет, и поэтому мне не очень подходит? Я и не думал, что мои личные предпочтения катят на откровения.

На самом деле хотите откровений - да легко. Файл-серверный движек не обязан обеспечивать множественный доступ к одной БД разным приложениям. Но jet - обеспечивает. Причем не за счет тупого разрешения множественной записи в файл БД указанием соотвествующего параметра доступа при открытии файла (что чревато жуткими глюками) - файл-то блокируется на запись, лично проверил. Но jet замечательно обеспечивает разделение открытой БД между разными приложениями. В общем - работает как типичный клиент-сервер, только локальный.

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

[kdv]

Файл-серверный движек не обязан обеспечивать множественный доступ к одной БД разным приложениям. Но jet - обеспечивает.

обалдеть. 100%-файл-серверных движков обеспечивают доступ к одной "БД" с разных компьютеров.
Потому что это файл-серверные движки. Есть еще просто файловые движки, которые не являются "серверными", и да, вот они не обеспечивают разделяемого доступа.

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

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

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

переходите на Oracle или MS SQL.

[pticelov]

Файл-серверный движек не обязан обеспечивать множественный доступ к одной БД разным приложениям. Но jet - обеспечивает.

обалдеть. 100%-файл-серверных движков обеспечивают доступ к одной "БД" с разных компьютеров.
Потому что это файл-серверные движки. Есть еще просто файловые движки, которые не являются "серверными", и да, вот они не обеспечивают разделяемого доступа.

Верно. Посмотрел первоисточник - я действительно перепутал файловый и файлсерверный движек. Впрочем, это совсем не интересно в данной теме.

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

Попытаюсь Вам объяснить. Я действительно чудовищно дремуч в вопросах различия движков СУБД. Впрочем, уверен, намного менее дремуч, чем Вы - в вопросах VoiP или каких-то других вопросах, которые Вам не интересны.

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

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

переходите на Oracle или MS SQL.

Т.е. firebird однозначно сам нормально не может разобраться с этим? Тогда действительно посмотрю на MS SQL или другие бесплатные движки.

[kdv]

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

Это Вы занимаетесь флудом. Попробуйте что-нибудь еще кроме Firebird, чтобы перестать страдать по поводу "почему на Jet было хорошо, а тут плохо".
Можете, к примеру, прочитать статью
http://www.ibase.ru/devinfo/dataaccesspaths.htm

Т.е. firebird однозначно сам нормально не может разобраться с этим? Тогда действительно посмотрю на MS SQL или другие бесплатные движки.

я Вам рекомендовал попробовать Вашу задачу на Оракле или МС SQL. Вообще, идеальных оптимизаторов не существует. А если у Вас задача однопользовательская - то пробуйте SQLLite. В конце-концов, не бывает СУБД, идеально подходящих под все случаи.
Кроме того, иногда проще отправить человека на другой сервер, чем вот так мучиться.

[pticelov]

Попробуйте что-нибудь еще кроме Firebird, чтобы перестать страдать по поводу "почему на Jet было хорошо, а тут плохо".

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

В первом запросе, где я на эти грабли наступил, было 250 ms - это же нереальная цифра. Да и 7 ms, в общем, страшно далеки от разумного.

я Вам рекомендовал попробовать Вашу задачу на Оракле или МС SQL. Вообще, идеальных оптимизаторов не существует.

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

А если у Вас задача однопользовательская - то пробуйте SQLLite. В конце-концов, не бывает СУБД, идеально подходящих под все случаи.
Кроме того, иногда проще отправить человека на другой сервер, чем вот так мучиться.

А может кто-то знает, почему могут быть такие странности? Перебирать все СУБД по первому чиху - не самый лучший путь.

[kdv]

А может кто-то знает, почему могут быть такие странности? Перебирать все СУБД по первому чиху - не самый лучший путь.

я советы со своей стороны уже исчерпал. А теперь посмотрите - кто еще Вам отвечает кроме меня на уже третьей странице топика?

[Tonal]

2 pticelov Я согласен с kdv - или попытайся разобраться как работает конкретный движёк, или попытайся найти тот движёк, который бы приемлемо работал на твоих запросах.

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

Во втором случае возможно найдёшь что-то удовлетворительное.

[pticelov]

А может кто-то знает, почему могут быть такие странности? Перебирать все СУБД по первому чиху - не самый лучший путь.

я советы со своей стороны уже исчерпал. А теперь посмотрите - кто еще Вам отвечает кроме меня на уже третьей странице топика?

Ну раз пошла такая пьянка ...

Если посчитать ответы по сути, то первый дельный совет дал hvlad (+0),
Второй ответ невредный, но не совсем мне подходит - hvlad (embedded)
Tonal рассказал про left join, пусть и не актуально, но пробел у меня оказался сильный, WildSery подкинул ссылку на статью
hvlad еще раз ткнул, как правильно делать +0

Вроде бы никого не забыл.

[pticelov]

2 pticelov Я согласен с kdv - или попытайся разобраться как работает конкретный движёк, или попытайся найти тот движёк, который бы приемлемо работал на твоих запросах.

Так я ж понимаю. Проблема в том, что проблема возникла на очень простом запросе. Я грешным делом не думал, что для запросов вида:

select CallTo,UserID,Len,Unsuccess,DialLength,DiscReason,StartTime from outcalls where incall=? order by id

нужно подбирать движек.

Я-то думаю, что у меня какая-то кривизна где-то, но где ее искать - не знаю. То, что на таких запросах надо явно +0 ручками ставить кажется мне странным. Поэтому и спрашиваю. Опыт хождения по граблям у меня уже есть, включая "магические значения" в fb 1.5 и привет от system restore

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

Так я не скрываю инфу и сразу отвечаю на все наводящие вопросы ... Ну да, еще флеймим помаленьку

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

Да у меня в этом проекте нет ни одного замысловатого запроса.

[Tonal]

Да у меня в этом проекте нет ни одного замысловатого запроса.

О чём я и пишу и другие тебе говорят.
Вместо твоего простого ... from outcalls where incall=? order by id дёргающегося для каждого номера вполне возможно сложный запрос с join и группировкой будет в сумме отрабатывать быстрее.

Кстати, у тебя все эти запросы хоть в одной транзакции выполняются?

Ну и из параллельных советов - может попробовать отказаться от ODBC?
Взять ibpp или, если таки не хочется привязываться к конкретному API, какой-нибудь SOCI, или другие из нативных клиентов, IBProvider например...

[kdv]

Вроде бы никого не забыл.

меня. который сделал ibase.ru, и разместил там и faq, в котором написано про +0 и про embedded, и статью про join.

То, что на таких запросах надо явно +0 ручками ставить кажется мне странным. Поэтому и спрашиваю.

потому что миллисекунды обычно никого не "парят". Это считается нормальным. Обычно о длительности выполнения запроса начинают задумываться когда она превышает, скажем, 0.5-1 секунду.
У Вас же задача более специфическая, чем обычно, еще и осложненная привычкой к файл-серверному движку. Поэтому жалобы на миллисекунды выглядят как странный каприз.

Так я не скрываю инфу и сразу отвечаю на все наводящие вопросы ... Ну да, еще флеймим помаленьку

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

[pticelov]

Да у меня в этом проекте нет ни одного замысловатого запроса.

О чём я и пишу и другие тебе говорят.
Вместо твоего простого ... from outcalls where incall=? order by id дёргающегося для каждого номера вполне возможно сложный запрос с join и группировкой будет в сумме отрабатывать быстрее.

Я уже намекнул - в отчете колцентра я могу сделать ну не очень хитрый join. Тут тема для дискуссии закончилась сразу, как выяснилось про мой провал в знаниях о левом join, и дальше я буду это знание использовать, естественно Но проблема-то не в одном запросе. Например у меня есть реалтайм часть, которая кое что смотрит в БД. Там тоже есть пара подобных запросов. Нагрузка - приличная. Там появление запроса, который систематически жрет 10 ms там, где достаточно 0.5 ms - это убиение системы.

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

Кстати, у тебя все эти запросы хоть в одной транзакции выполняются?

Ага.

Ну и из параллельных советов - может попробовать отказаться от ODBC?

Так проблема-то не в производительности интерфейса СУБД, а в том, что оптимизатор план строит неоптимально.

[pticelov]

меня. который сделал ibase.ru, и разместил там и faq, в котором написано про +0 и про embedded, и статью про join.

Ну это мимо дискуссии. Здесь мы совместно лишь воду льем А так, конечно, спасибо.

То, что на таких запросах надо явно +0 ручками ставить кажется мне странным. Поэтому и спрашиваю.

потому что миллисекунды обычно никого не "парят". Это считается нормальным. Обычно о длительности выполнения запроса начинают задумываться когда она превышает, скажем, 0.5-1 секунду.
У Вас же задача более специфическая, чем обычно, еще и осложненная привычкой к файл-серверному движку. Поэтому жалобы на миллисекунды выглядят как странный каприз.

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

Файл-серверный движек тут ничего не менял. Как показало вскрытие, embeded firebird, хоть и клиент-сервер, при добавлении в нужные места +0 давал производительность не хуже jet'а.

[kdv]

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

я заметил

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

похоже на задачу диспетчерской такси. на ФБ таких решений много.

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

клиент-серверные системы, в отличие от файл-серверных, можно назвать "нестабильными". Потому что у файл-серверных оптимизатор как правило отсутствует, и классическая файл-серверная СУБД работает навигационным способом.
То есть, на файл-сервере выполняем 1 запрос - получаем n миллисекунд, выполняем 10 одновременно, получаем n*10*k, и так далее, затык может произойти только если будут неожиданные тормоза по сети или неприятности с файловым кэшем серверной ОС.
В клиент-сервере факторов, влияющих на производительность, много больше. Основной - оптимизатор, который вчера оптимизировал запрос одним способом, а сегодня - может другим. Второй - например версионность, или как следствие версионности - накопление версий или кооперативная сборка мусора.
То есть, обычные нынешние СУБД - это не системы реального времени с предсказуемым временем выполнения запроса. То есть, время, конечно, предсказуемое, но оно может колебаться в +- 200 и больше %.

В Вашей задаче время отклика на запрос - важное условие ТЗ. Глядя на это ТЗ, с учетом простых запросов, я бы предложил MySQL, причем без версионного движка и даже без транзакций. Либо другой блокировочный сервер.

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

Поэтому совет - перестаньте мыслить категориями ассемблера. В нем было все просто, вот А, вот Б, вот А+Б. Клиент-серверные СУБД - не ассемблер. И если уж что сравнивать с ассемблером, то например, C#, где и трансляция в байт-код, и сборка мусора в памяти, и виртуальная машина, и т.п.
Буквально Вы переносите код с ассемблера на C#, и жалуетесь на не тот результат, который был на ассемблере.
Вот такие пироги.

[WildSery]

Но проблема-то не в одном запросе. ...
не как обойти конкретный запрос в конкретном месте...

Извините за сарказм, но для меня такие рассуждения звучат примерно так:
Задача - топлю печку-буржуйку.
У меня был секатор. Лёгкий и всегда с собой. Любую веточку в саду срубал мгновенно. А уж как кусты кромсал, один за другим И всегда я был хворостом обеспечен.
Решил приобщиться к серьёзной технике - бензопила.
Но блин! Она мало того, что долго снаряжается, тяжёлая, так ещё бензин жрёт! И веточки на кустах стричь тяжело и неудобно. Я знаю, что бензопила легко пилит деревья, и дровами я обеспечен, но моя задача требует топить печку хворостом (уже не помню, почему, всегда так делал), вот с кустами и мучаюсь. Так ещё и заглохнуть может, оказывается - тогда очередную веточку состричь не успею, чтобы в топку бросить
Как бы так её заставить удобно кусты по одной веточке стричь?

[pticelov]

Но проблема-то не в одном запросе. ...
У меня был секатор. Лёгкий и всегда с собой. Любую веточку в саду срубал мгновенно. А уж как кусты кромсал, один за другим И всегда я был хворостом обеспечен.
Решил приобщиться к серьёзной технике - бензопила.
Но блин! Она мало того, что долго снаряжается, тяжёлая, так ещё бензин жрёт! И веточки на кустах стричь тяжело и неудобно. Я знаю, что бензопила легко пилит деревья, и дровами я обеспечен, но моя задача требует топить печку хворостом (уже не помню, почему, всегда так делал), вот с кустами и мучаюсь. Так ещё и заглохнуть может, оказывается - тогда очередную веточку состричь не успею, чтобы в топку бросить
Как бы так её заставить удобно кусты по одной веточке стричь?

Все не так.

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

[pticelov]

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

похоже на задачу диспетчерской такси. на ФБ таких решений много.

Ну я сказал, что колцентр.

Но с диспетчерской такси все проще - там сидит 1-2-3 диспетчера, и минимум интеллекта. Я как раз с таксистами пару дней назад разговаривал. У меня в самом крупном проекте до 50 сидят одновременно. А проект, в который я собирался вписаться, но откат авансом дать не смог - это сотни рабочих мест и кластер серверов. Тут вопрос о масштабировании весьма актуален

То есть, обычные нынешние СУБД - это не системы реального времени с предсказуемым временем выполнения запроса. То есть, время, конечно, предсказуемое, но оно может колебаться в +- 200 и больше %.

Я бы про 200% и не заикался.

первый запрос, с которого я стартовал этот тред - это не 200%, а 1000x (100000%) - 250 ms против 0.2 ms после добавления +0, последний, на котором я понял, что проблема какая-то системная - это 35x (3500%) - 7 ms против 0.2 ms после добавления +0.

Причем подобной непредсказуемости я раньше на firebird ни разу не встречал, а у меня на нем 2 проекта сделано. Возможно, что я просто грабли нужной сторонйо для наступания мог наконец повернуть, но может и поломал что.

В Вашей задаче время отклика на запрос - важное условие ТЗ. Глядя на это ТЗ, с учетом простых запросов, я бы предложил MySQL, причем без версионного движка и даже без транзакций. Либо другой блокировочный сервер.

В 2005 году я отказался от идеи использовать MySQL по простой причине - он просто не поддерживал использование нескольких индексов в запросе. Я не поверил своим глазам, но нашел про это явное указание в описании.-

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

Да я прихожу сюда с вопросами в основном обоснованно возникающими