Re: Время выполнения запроса
Добавлено: 15 фев 2009, 12:49
И ты абсолютно уверен, что этот индекс им помогает, а не мешает?pticelov писал(а):Да мне этот индекс нужен - у меня полно отчетов с выборкой по starttime.
И ты абсолютно уверен, что этот индекс им помогает, а не мешает?pticelov писал(а):Да мне этот индекс нужен - у меня полно отчетов с выборкой по starttime.
Правда у embedded, конечно, грабля неприятная - одно соединение к БД и все. jet позволяет несколько соединений.
еще пара таких откровений, и забаню с одновременным посылом в FAQ.Я имел в виду именно от разных. Хочется иметь возможность заглянуть в БД не прибивая приложение.
Откровение, простите, в чем? В том, что jet позволяет разным приложениям коннектится к одной БД, а embedded firebird нет, и поэтому мне не очень подходит? Я и не думал, что мои личные предпочтения катят на откровения.kdv писал(а):Правда у embedded, конечно, грабля неприятная - одно соединение к БД и все. jet позволяет несколько соединений.еще пара таких откровений, и забаню с одновременным посылом в FAQ.Я имел в виду именно от разных. Хочется иметь возможность заглянуть в БД не прибивая приложение.
Jet это файл-серверный движок, он не может не позволять другим Jet-ам подключаться к файлам бд.
Embedded - это dll, которая вместе с exe представляет собой СЕРВЕР. А в клиент-сервере кроме сервера никто к базе подсоединиться не может.
обалдеть. 100%-файл-серверных движков обеспечивают доступ к одной "БД" с разных компьютеров.Файл-серверный движек не обязан обеспечивать множественный доступ к одной БД разным приложениям. Но jet - обеспечивает.
Вы или валяете дурака, испытывая мое терпение, или ... программист чудовищной дремучести.файл-то блокируется на запись, лично проверил. Но jet замечательно обеспечивает разделение открытой БД между разными приложениями. В общем - работает как типичный клиент-сервер, только локальный.
переходите на Oracle или MS SQL.Не лирика - почему firebird так странно себя ведет при наличии нескольких индексов и чем мне ему помочь, кроем как ручками все запросы прооптимизировать дабы заблокировать любую попытку использовать лишние индексы в них.
Верно. Посмотрел первоисточник - я действительно перепутал файловый и файлсерверный движек. Впрочем, это совсем не интересно в данной теме.kdv писал(а):обалдеть. 100%-файл-серверных движков обеспечивают доступ к одной "БД" с разных компьютеров.Файл-серверный движек не обязан обеспечивать множественный доступ к одной БД разным приложениям. Но jet - обеспечивает.
Потому что это файл-серверные движки. Есть еще просто файловые движки, которые не являются "серверными", и да, вот они не обеспечивают разделяемого доступа.
Попытаюсь Вам объяснить. Я действительно чудовищно дремуч в вопросах различия движков СУБД. Впрочем, уверен, намного менее дремуч, чем Вы - в вопросах VoiP или каких-то других вопросах, которые Вам не интересны.Вы или валяете дурака, испытывая мое терпение, или ... программист чудовищной дремучести.
Т.е. firebird однозначно сам нормально не может разобраться с этим? Тогда действительно посмотрю на MS SQL или другие бесплатные движки.переходите на Oracle или MS SQL.Не лирика - почему firebird так странно себя ведет при наличии нескольких индексов и чем мне ему помочь, кроем как ручками все запросы прооптимизировать дабы заблокировать любую попытку использовать лишние индексы в них.
Это Вы занимаетесь флудом. Попробуйте что-нибудь еще кроме Firebird, чтобы перестать страдать по поводу "почему на Jet было хорошо, а тут плохо".У меня не был ни малейшего желания обсуждать различия файл-серверных и клиент-серверных движков. Почему-то Вы, увидев мое замечание, что embedded firebird мне не подходит, из-за того, что не обеспечивает множественные коннекты от разных приложений, решили со мной обсудить тему различия движков, хотя можете поверить мне на слово - мне абсолютно пофиг, почему это так. Важно, что не может, и все. Как я уже несколько раз заметил, вопрос я задавал совсем не об этом. Зачем нам плодить это флуд?
я Вам рекомендовал попробовать Вашу задачу на Оракле или МС SQL. Вообще, идеальных оптимизаторов не существует. А если у Вас задача однопользовательская - то пробуйте SQLLite. В конце-концов, не бывает СУБД, идеально подходящих под все случаи.Т.е. firebird однозначно сам нормально не может разобраться с этим? Тогда действительно посмотрю на MS SQL или другие бесплатные движки.
Да я не страдаю, а спрашиваю, что может быть не так у меня, чтобы приводить к таким последствиям.kdv писал(а):Попробуйте что-нибудь еще кроме Firebird, чтобы перестать страдать по поводу "почему на Jet было хорошо, а тут плохо".
Я почему-то думаю, что виновата не неидеальность оптимизатора, а скорее всего какая-то известная грабля.я Вам рекомендовал попробовать Вашу задачу на Оракле или МС SQL. Вообще, идеальных оптимизаторов не существует.
А может кто-то знает, почему могут быть такие странности? Перебирать все СУБД по первому чиху - не самый лучший путь.А если у Вас задача однопользовательская - то пробуйте SQLLite. В конце-концов, не бывает СУБД, идеально подходящих под все случаи.
Кроме того, иногда проще отправить человека на другой сервер, чем вот так мучиться.
я советы со своей стороны уже исчерпал. А теперь посмотрите - кто еще Вам отвечает кроме меня на уже третьей странице топика?А может кто-то знает, почему могут быть такие странности? Перебирать все СУБД по первому чиху - не самый лучший путь.
Ну раз пошла такая пьянка ...kdv писал(а):я советы со своей стороны уже исчерпал. А теперь посмотрите - кто еще Вам отвечает кроме меня на уже третьей странице топика?А может кто-то знает, почему могут быть такие странности? Перебирать все СУБД по первому чиху - не самый лучший путь.
Так я ж понимаю. Проблема в том, что проблема возникла на очень простом запросе. Я грешным делом не думал, что для запросов вида:Tonal писал(а):2 pticelov Я согласен с kdv - или попытайся разобраться как работает конкретный движёк, или попытайся найти тот движёк, который бы приемлемо работал на твоих запросах.
Так я не скрываю инфу и сразу отвечаю на все наводящие вопросы ... Ну да, еще флеймим помаленькуВ первом случае нужно таки читать документацию, а если спрашиваешь, то предоставлять полную инфу.
В любом случае это выльется в изменение запросов и алгоритмов работы с базой.
Да у меня в этом проекте нет ни одного замысловатого запроса.Например, насколько я в курсе, FB медленнее Jet-а на большом количестве запросов по одному объекту.
С другой стороны гораздо лучше отрабатывает сложные условия и соединения, хотя иногда приходится подсказывать оптимизатору.
О чём я и пишу и другие тебе говорят.pticelov писал(а):Да у меня в этом проекте нет ни одного замысловатого запроса.
меня. который сделал ibase.ru, и разместил там и faq, в котором написано про +0 и про embedded, и статью про join.Вроде бы никого не забыл.
потому что миллисекунды обычно никого не "парят". Это считается нормальным. Обычно о длительности выполнения запроса начинают задумываться когда она превышает, скажем, 0.5-1 секунду.То, что на таких запросах надо явно +0 ручками ставить кажется мне странным. Поэтому и спрашиваю.
три страницы толчения воды в ступе. управиться можно было одной страницей.Так я не скрываю инфу и сразу отвечаю на все наводящие вопросы ... Ну да, еще флеймим помаленьку
Я уже намекнул - в отчете колцентра я могу сделать ну не очень хитрый join. Тут тема для дискуссии закончилась сразу, как выяснилось про мой провал в знаниях о левом join, и дальше я буду это знание использовать, естественно Но проблема-то не в одном запросе. Например у меня есть реалтайм часть, которая кое что смотрит в БД. Там тоже есть пара подобных запросов. Нагрузка - приличная. Там появление запроса, который систематически жрет 10 ms там, где достаточно 0.5 ms - это убиение системы.Tonal писал(а):О чём я и пишу и другие тебе говорят.pticelov писал(а):Да у меня в этом проекте нет ни одного замысловатого запроса.
Вместо твоего простого ... from outcalls where incall=? order by id дёргающегося для каждого номера вполне возможно сложный запрос с join и группировкой будет в сумме отрабатывать быстрее.
Ага.Кстати, у тебя все эти запросы хоть в одной транзакции выполняются?
Так проблема-то не в производительности интерфейса СУБД, а в том, что оптимизатор план строит неоптимально.Ну и из параллельных советов - может попробовать отказаться от ODBC?
Ну это мимо дискуссии. Здесь мы совместно лишь воду льем А так, конечно, спасибо.kdv писал(а): меня. который сделал ibase.ru, и разместил там и faq, в котором написано про +0 и про embedded, и статью про join.
Простите меня, но я члеовек старорежимный, воспитанный ассемблером. Для меня любая неадекватность - это повод задуматься о том, как я буду систему расширять завтра В тестовом режиме я монопольно запрос меряю, а на реальной системе у меня 50 диспетчеров сидят, так что там порождается по несколько "отчетов" в секунду (пришел вызов от клиента, надо вывести историю звонка, информацию о клиенте и еще кучу всего), так что секунда на запрос - это полный капец, и перекомумтируется куча вызовов в секунду, а по приходе каждого надо кучку информации из БД достать о звоняшем клиенте, куда его отправить, с кем он разговаривал в прошлый раз и т.д. Тут уже десятки миллисекунд на простом запросе начинают парить. Поэтому в ситуации, когда я натыкаюсь на то, что оптимизатор без моей помощзи делает что-от тормозное, я хочу понять, чем ему помочь.потому что миллисекунды обычно никого не "парят". Это считается нормальным. Обычно о длительности выполнения запроса начинают задумываться когда она превышает, скажем, 0.5-1 секунду.То, что на таких запросах надо явно +0 ручками ставить кажется мне странным. Поэтому и спрашиваю.
У Вас же задача более специфическая, чем обычно, еще и осложненная привычкой к файл-серверному движку. Поэтому жалобы на миллисекунды выглядят как странный каприз.
я заметилно я члеовек старорежимный, воспитанный ассемблером.
похоже на задачу диспетчерской такси. на ФБ таких решений много.так что там порождается по несколько "отчетов" в секунду (пришел вызов от клиента, надо вывести историю звонка, информацию о клиенте и еще кучу всего)
клиент-серверные системы, в отличие от файл-серверных, можно назвать "нестабильными". Потому что у файл-серверных оптимизатор как правило отсутствует, и классическая файл-серверная СУБД работает навигационным способом.Тут уже десятки миллисекунд на простом запросе начинают парить. Поэтому в ситуации, когда я натыкаюсь на то, что оптимизатор без моей помощзи делает что-от тормозное, я хочу понять, чем ему помочь.
Извините за сарказм, но для меня такие рассуждения звучат примерно так:pticelov писал(а):Но проблема-то не в одном запросе. ...
не как обойти конкретный запрос в конкретном месте...
Все не так.WildSery писал(а):pticelov писал(а):Но проблема-то не в одном запросе. ...
У меня был секатор. Лёгкий и всегда с собой. Любую веточку в саду срубал мгновенно. А уж как кусты кромсал, один за другим И всегда я был хворостом обеспечен.
Решил приобщиться к серьёзной технике - бензопила.
Но блин! Она мало того, что долго снаряжается, тяжёлая, так ещё бензин жрёт! И веточки на кустах стричь тяжело и неудобно. Я знаю, что бензопила легко пилит деревья, и дровами я обеспечен, но моя задача требует топить печку хворостом (уже не помню, почему, всегда так делал), вот с кустами и мучаюсь. Так ещё и заглохнуть может, оказывается - тогда очередную веточку состричь не успею, чтобы в топку бросить
Как бы так её заставить удобно кусты по одной веточке стричь?
Ну я сказал, что колцентр.похоже на задачу диспетчерской такси. на ФБ таких решений много.так что там порождается по несколько "отчетов" в секунду (пришел вызов от клиента, надо вывести историю звонка, информацию о клиенте и еще кучу всего)
Я бы про 200% и не заикался.То есть, обычные нынешние СУБД - это не системы реального времени с предсказуемым временем выполнения запроса. То есть, время, конечно, предсказуемое, но оно может колебаться в +- 200 и больше %.
В 2005 году я отказался от идеи использовать MySQL по простой причине - он просто не поддерживал использование нескольких индексов в запросе. Я не поверил своим глазам, но нашел про это явное указание в описании.-В Вашей задаче время отклика на запрос - важное условие ТЗ. Глядя на это ТЗ, с учетом простых запросов, я бы предложил MySQL, причем без версионного движка и даже без транзакций. Либо другой блокировочный сервер.
Да я прихожу сюда с вопросами в основном обоснованно возникающимиЭто пример выбора инструмента для решения конкретной задачи. Текущий топик - пример блуждания в темноте. Как минимум потому, что если сегодня Вы получите требуемую скорость запросов от ФБ, то завтра Вы придете сюда же с жалобой "почему вдруг начало работать медленнее". В этом случае мы уже не потратим столько времени, и ответом будет "потому что что-то не так с транзакциями, накапливаются версии", и т.д.