iBase.ru Forum

Имеется Firebird 2.0
Имеется таблица 9 полей Integer, одно текстовое.
Делаем запрос где field4 единственное текстовое:
select * from tablename oder by field1,field2,field3,field4
оптимизатор выдает PLAN SORT ((tablename NATURAL))
данные (12 тыс записей) выбираются за 500мсек на обычном целероне.
Потом делаем индекс по таблице по полям field1,field2,field3,field4
Повторяем запрос и получаем 800мсек на выполнение. Причем оптимизатор выбирает этот созданный индекс
PLAN (tablename ORDER tablename_idx1)
Так вот вопрос: как мне казалось, что имеющийся идекс только усугубляет выборку, т.к. отсуствие этого индекса дает прирост скорости чуть ли не 50%. Это нормально, или я что то не так делаю?

Тынц!

2 kdv: Дмитрий, может ты его как заметку какую-то короткую сюда перенесёшь, с ссылкой в факе?
А то уже неоднократно на этот твой пост ссылались, и ты сам в том числе неоднократно

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

"Тынц", почитал, суть понял. Что собственно делать чтобы ускорить выборку не понял. Причем, индекс по этим четырем значениям уникальный, по крайней мере нет ни одной записи в таблице с одинаковым field4.

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

Что собственно делать чтобы ускорить выборку не понял.

гм. в том тексте явно говорится, что в описываемом случае наличие индекса ХУЖЕ чем его отсутствие. Прочитай еще раз.

А ускорить все можно только телепортацией. только ее еще не изобрели.

Задача поставлена мне просто такая - борьба за миллисекунды ведется. Нужно загрузить приложение не более секунды на все сортировки закачки и т.д. Т.е. если есть возможность экономии нескольких десятков миллисекунд, эту возможность приходится использовать. Но это не суть. Самое быстрое - получено эмпирическим путем - загрузка из таблицы без сортировки и "быстрая сортировка" по четырем параметрам клиенским приложением (на грамотную реализацию последней ушла неделя). Но! есть такая проблема - в связном списке получается, что узлы далеко разбросаны (из-за сортировки) друг от друга по ОЗУ, и загрузка собственно в визуальный компонент уже медленнее на 100мсек. Могу предположить, что у целерона просто в кэше не помещяется, и ему приходиться активно таскать туда сюда банки ОЗУ, ИМХО. Поэтому приходится отсортированный список снова пересоздавать уже по порядку, тогда навигация value:=value.next (где value довольно емкий record) быстрее примерно процентов на 40. Вот так.... вместо order by такой геморой в клиенском приложении... вот она - привычка к SQL серверу. Интересно, у других SQL серверов индексы при сортировке тоже могут мешать? Например, у других бесплатных, у MySQL? Для виндов очевидно, что мне удобнее FB, но вот для web эта тема с order болезненна...

Про тему на счет индексов понял. Очень жаль... Например в случае работы FB+PHP запросы в вэб-сервер по любому придется сортировать средствами сервера через order, т.к. писать на PHP быструю сортировку совсем не есть хорошо и хорошо реализуемое... оч. жаль.

А что, полный фетч входит в условия задачи?

Вот так.... вместо order by такой геморой в клиенском приложении... вот она - привычка к SQL серверу.

почему геморрой? Вполне нормальное решение, когда надо сортировать по разным критериям не дергая сервер. Обычно используют TClientDataSet, у него даже индексы в памяти есть, и т.п. На сайте есть ряд ссылок про работу с cds.

2 Merlin

Да, входит.

2 kdv

Дмитрий, я понимаю, что этот форум не для того, чтобы писать про другие сервера, но плиз скажите свое мнение, для серьезного web-сервера рационально ли использовать Firebird?
База примерно 10-40гиг, select будет значительно чаще update, и insert реже чем update. Причем в массе своей select будет безумный по 4-5 таблицам с явным join и проч. Голова на плечах есть, и не плохая, просто оч. не хочется упереться в потолок SQL-сервера и потом мучительно мигрировать работающим web-сервером на другой SQL.
Скажу по чесноку - по форуму таких вопросов не искал и поначалу вообще хотел сразу в почту Дмитрию написать, уже много переписывались, но что то постеснялся
Я реальный почитатель FB, для мелких задач он супер, но для серьезных...

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

что значит "серьезный"? вот что это за критерий, например? ERP-решение AVARDA - это несерьезно? (выпуклый пример с реальными данными и клиентами. к сожалению по большинству клиентов я не имею права давать информацию). Остальные - в бирюльки играют?

оч. не хочется упереться в потолок SQL-сервера

в какой именно "потолок"? я так понимаю, что на нынешний момент "потолком" считается скорость сортировки. Так? Если она не удовлетворяет критериям конкретной и (сами сказали) экстремальной задачи - сервер несерьезный. А который удовлетворяет - серьезный?

по моему мнению, не бывает так, чтобы конкретная СУБД удовлетворяла всем перекошенным критериям на 100%. версионник не блокирует, но плодит мусор. блокировочник работает быстро, но блокирует. Там оптимизатор хорошо одни запросы обрабатывает, тут - другие. И т.д.

и потом мучительно мигрировать работающим web-сервером на другой SQL.

на какой другой, например. MySQL? проверяйте его характеристики на вашей задаче.

p.s. "нет в жизни счастья".

Не понял как тут цитировать

Потолок - это то, что однажды упрусь в то, что например не умеет он сортировать быстро. Не надо злиться И упрусь в производительность web-сервера. Наращивать его нельзя (кластеризовать, распараллеливать) и ага.. Дальше деньги на рэйд массив, потом на следующий, потом на проц extreme edition, потом на охлаждение всего этого, а потом опять бац и потолок. Конечно, я попытаюсь реализовать на FB... даже предполагаю все же как его кластеризовать - разнести задачу на несколько серверов (у каждого своя задача будет, не все на одну задачу будут молотить) Но блииин.. как бы не разочароваться... FB мне нравится своей простотой... 10 лет уже с IB/FB работаю. Понимаю, как работает версионник, но оч. слабо, как работает блокировочник. Не мешало бы и то и то осветить на сайте. По моему мнению блокировочник - это плохо С другой стороны при подавляющем кол-ве select я плаваю в инфе отличия версионника от блокировочника. Серьезно. Причем я считаю себя весьма продвинутым девелопером.

2 kdv

Тогда НАФИГА FB выбирает индекс при сортировке в план, если знает, что получится медленнее чем план натурал???

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

Тему можно закрыть.

на какой другой, например. MySQL? проверяйте его характеристики на вашей задаче.

Заплатить и купить Oracle
Когда заказчик услышит стоимость апгрейтов железа, кулеров, процев, рэйдов за 14уе, то вполне может поставить задачу миграции на оракл или еще что. Тут встанет вопрос деньги/результат. Кстати, по этому поводу тоже не мешало бы статью.. чтобы любители FB не пытались на нем повторить mamba.ru
Интересно, кстати, на каком SQL сервере живет mamba.ru и другие соц. проекты типа одноклассников, мойкруг и т.д.

Тогда НАФИГА FB выбирает индекс при сортировке в план, если знает, что получится медленнее чем план натурал???

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

если вернуться к перебору по индексу - то при небольшом объеме данных он эффективнее сортировки.

Понятно что FB в обиду не дадите

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

к слову. в каждой новой версии FB оптимизатор обязательно дорабатывается и улучшается. Но идеальных оптимизаторов не бывает в принципе. Нет таких и в MS SQL и в Oracle.

Понимаю, как работает версионник, но оч. слабо, как работает блокировочник. Не мешало бы и то и то осветить на сайте.

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

Кстати, по этому поводу тоже не мешало бы статью.. чтобы любители FB не пытались на нем повторить mamba.ru
Интересно, кстати, на каком SQL сервере живет mamba.ru и другие соц. проекты типа одноклассников, мойкруг и т.д.

[/quote]

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

Много бы отдал чтобы понять как работают сервера google.
И про то, что не знает, не верю. Видимо что то не доработано. Т.к. имея статистику индексов, имея примерный объем записей в таблице опять же на основе ун.индекса можно все предположить с вероятностью в данном случае оч. высокой, я думаю под 90%. Самописные программы могут ведь адаптированно сортировать, анализировать и расчитывать обладая только стат.информацией.

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

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

Vaлera писал(а):И про то, что не знает, не верю. Видимо что то не доработано. Т.к. имея статистику индексов, имея примерный объем записей в таблице опять же на основе ун.индекса можно все предположить с вероятностью в данном случае оч. высокой, я думаю под 90%.

Ты тут воду не лей, ты патчи давай!

И про то, что не знает, не верю. Видимо что то не доработано.

да, видимо что-то случилось (с).

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

да примерный объем записей и так определяется сервером, по числу страниц-указателей на данные. Но- таблице может быть 10 записей, а вот валяться они могут на 10-ти разных страницах. Соответственно стоимость ввода-вывода тут уже другая, чем если бы все эти 10 записей лежали на одной странице.
Причем из этих 10-ти - 9 могут быть удалены, а 1 - еще не committed. А узнать это можно только при чтении записи.

он мне тааакого нарассказал про FB и др

интересно, чего нарассказал.

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

невозможно написать такое. потому что "чего не стоит делать" определяется только по конкретной задаче. Типа "база 5 терабайт", 2000 пользователей (хотя их столько можно, но не в к-с), 10 тысяч селектов в секунду, и так далее.