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

Если делать в лоб, то при достаточно большом числе конкурентных запросов нагрузка на сервер значительно возрастает (у БД есть ещё и другие задачи). Кто-нибудь знает, как оптимизировать данную конструкцию, и какие решения этой проблемы используются на HighLoad-проектах?

Petro123,
На текущий момент ничего нет, я проектированием занимаюсь...
вот задумался на тему выбора типа селекторов: ComboBox на AJAX или отдельная форма с полем ввода кнопкой "Найти"... вот думаю, как комбо-бокс будет работать и прикидываю ресурсы и нагрузки.

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

Над ораклом будет или Hiber или TopLink

Но вообще, лучше, чтоб "Кэш-машина" лезла в базу сама по соображениям производительности...

Petro123,
Ситуация такая, есть готовая база и есть система аналитических отчётов, которая написана в ГУЕ.
Её надо портировать на ВЭБ.
В качестве генератора отчётов выбран Jasper, репозиторий отчётов JasperServer, у которого есть открытое API. Чтобы сгенерить отчёт, нужно ввести входные параметры и дёрнуть JasperServ, чтобы тот выдал печатную форму в указанном формате или в режиме пейджинга запрашивать нужную страницу для отображения в HTML.
Я сейчас нахожусь на стадии раздумий по поводу ввода параметров. Цель примерно нарисовал такую, создать библиотеку тэгов, в которой были бы прикладные селекторы-валидаторы различных справочников и объектов существующей базы.

Работа комбо-бокса очень привлекает своей интерактивностью, сразу видно что есть ещё в БД рядом. Но для этого нужен индекс, чтобы не "бомбить" БД запросами.
Вот lucene нашёл... наверно он меня спасёт...

Petro123-=*ShamaN*=-,
если данных реально много, наверно ты прав - средства самой БД могут не хватить.
И наклон проекта у тебя на report'инг, поэтому кэши коллекций-сущностей это не совсем то (параметров).

автора посоветуйте, пожалуйста, БД/движок для индексации _имён_, размеров, дат (но не содержимого файлов) файлов с возможностью поиска по %query%. В данный момент используется mysql, но при базе в пару гигов скорость сильно падает (с 2-3 секунд до десятка). Пару раз пробовал lucene, но на паре млн документов на %query% запросах его скорость не выше mysql'я
Удачи!

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


Kachalov-=*ShamaN*=-Если делать в лоб, то при достаточно большом числе конкурентных запросов нагрузка на сервер значительно возрастает (у БД есть ещё и другие задачи). Кто-нибудь знает, как оптимизировать данную конструкцию, и какие решения этой проблемы используются на HighLoad-проектах?
- у БД есть собственный кэш запросов, при достаточном размере этого кэша, проблем с производительностью в описанной Вами задаче не возникает (делал аналогичные поиски по КЛАДР и по списку станций ЖД - проблем с производительностью в этом месте не было)

А поиск был именно по маске типа like '%ФРАЗА%'? В таком раскладе план запроса - TableScan, что не есть зер гут. + не все справочники могут влезть в горячий кэш, да и не хотелось бы драгоценную память SQL-сервера на 80% использовать для красивого Комбобокса, жирно ему будет... Я выше в посте специально указал, что на сервере и так много чего висит...


Диез-=*ShamaN*=-
Ситуация такая, есть готовая база и есть система аналитических отчётов, которая написана в ГУЕ.
Её надо портировать на ВЭБ.
...


А что за ГУЙ? Самописный или какой-то продукт?


Гуй самописный, много программ, база одна...

Petro123тут главное не перемудрить, что в вэбе очень часто.
Узкий канал - слабое место.
Пока по каналу дойдут события мышки или открытие комба бокса - СУБД 1000 раз успеет ответить.
Попробуйте!
Почему на десктопе нет кэшей?

Попробовал:)
Залил реальных данных в облегчённую таблицу": 25000 строк - 2 столбца BIGINT и VARCHAR(255), FF-100
Время поиска Oracle и PG одинаково (TableScan) - 15-16ms без фетча
Время поиска по GIN-индексу PG ~300ms без фетча (зря парился, lucene скорее всего такие же результаты выдаст)

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

Petro123тут главное не перемудрить, что в вэбе очень часто.
Узкий канал - слабое место.
Пока по каналу дойдут события мышки или открытие комба бокса - СУБД 1000 раз успеет ответить.
Попробуйте!
Почему на десктопе нет кэшей?

В смысле на десктопе? не понял вопроса..

В вэбе нагрузка немного меньше в том случае, когда есть отсечка данных аля "limit X offset X" для PG и "ROWNUM between Y and Y" для Oraclа и выборка идёт чётко по индексам (и то, это экономит память и процессор только при отсутсвии "order by..." в запросе)... Сервер понимает эти инструкции и выполняет "Поднятие" данных с винта заранее зная (из индекса), какие окна стораджа ему нужны.

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

Источником запросов, напомню, являются нажатия пользователем кнопок на клавиатуре...
Работать оно будет так:
пользователь нажал кнопку А, таймер начал отсчитывать 500мс, если пользователь нажал ещё одну кнопку, таймер сбросился и начал опять отсчитывать 500с. Как только 500с прошли производится AJAX запрос и генерация контента для слоя (DIV) выпадающего списка.
т.е., гипотетически от одного пользователя максимальная частота запросов может составлять 2 запроса в секунду, если пренебречь затратами на доставку Запроса-Ответа, парсинг JSON, подготовку SQL, фетч и генерацией HTML.

Kachalov-=*ShamaN*=-Работать оно будет так:
- есть готовые скрипты, например плагин (не помню названия, если надо вспомню) к jQuery

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