Лента
Мой малыш
Мой малыш - Основной
Мой малыш - Объявления: детская одежда
Мой малыш - Объявления: детский транспорт, игрушки, мебель
Мой малыш - Объявления: детская обувь
Мой малыш - Объявления. Общий
Городские форумы
Автофорумы
Халявный
Домоводство
Дачный. Основной.
Дачный. Объявления.
Цветочный форум
Деревенский форум
Форум владельцев кошек
Показать ещё
Проф. и бизнес форумы
Строительные форумы
Строительный форум (основной)
Форум электриков
Мебель
Окна
Форум строительных объявлений
Показать ещё
Технофорумы
Собачий форум
Велофорумы Нижнего Новгорода
Наши дети
Туризм, отдых, экстрим
Творческий
Путешествия
Спортивные форумы
Нижегородская область
Недвижимость
Форумы по интересам
Частные форумы
Форумы домов
Жилые районы
Отзывы и предложения (техподдержка)
Требуется прикрутить autocomplete
Все равно непонятно)
Надо хотя бы ссылку на какую-нибудь страницу. Возможно это на php написано.
Собственно вся задача состоит из двух частей:
1) К текстбоксу привязять Javascript + AJAX запрос на сервер
2) Серверный метод, который делает сам поиск и возвращает ссылки
Если сайт писался руками, то в принципе понятно как прикручивать, а если каким-то движком генерился, то тут надо искать специалиста по движку.
Надо хотя бы ссылку на какую-нибудь страницу. Возможно это на php написано.
Собственно вся задача состоит из двух частей:
1) К текстбоксу привязять Javascript + AJAX запрос на сервер
2) Серверный метод, который делает сам поиск и возвращает ссылки
Если сайт писался руками, то в принципе понятно как прикручивать, а если каким-то движком генерился, то тут надо искать специалиста по движку.
0
на сервере PHP, база думаю SQL'ная, скорее всего MySQL.
можно тупо через SELECT ... WHERE ... LIKE запрос сделать по полям, либо если хочется полнотекстовый поиск, то MATCH ... AGAINST
для ограничения совпадений рекомендую либо искать когда набрано не менее 3-х букв, либо использовать LIMIT в запросе
на клиенте jQuery, к полю привязаться не проблема (на onchange смотреть, что что-то набрано и делать запрос).
движок какой - пофиг, т.к. можно "сбоку" отдельный скрипт написать просто.
можно тупо через SELECT ... WHERE ... LIKE запрос сделать по полям, либо если хочется полнотекстовый поиск, то MATCH ... AGAINST
для ограничения совпадений рекомендую либо искать когда набрано не менее 3-х букв, либо использовать LIMIT в запросе
на клиенте jQuery, к полю привязаться не проблема (на onchange смотреть, что что-то набрано и делать запрос).
движок какой - пофиг, т.к. можно "сбоку" отдельный скрипт написать просто.
0
S
Sergey Pravodelov
14 августа 2015
На примере в клиенте сидит Keen JS, что довольно мощная вещь для организации запросов и кэша.
Дальше всё зависит от того, как и на чём построена БД.
Сильно нагруженный (подвисающий) autocomplete будет не помогать, а раздражать пользователя.
Нужен кэш. Строить грамотно кэш - задача не простая. Можно легко лешиться части позиций в списке.
Дальше всё зависит от того, как и на чём построена БД.
Сильно нагруженный (подвисающий) autocomplete будет не помогать, а раздражать пользователя.
Нужен кэш. Строить грамотно кэш - задача не простая. Можно легко лешиться части позиций в списке.
0
Простой like убьет производительность.
Не знаю, как с mysql, но на других базах делал словарь, связанный с изначальным списком, и индексацию на префиксный like. Работало неплохо.
На postgres есть вообще FTS как раз для полнотекстового поиска (правда, мне не совсем подошло).
Не знаю, как с mysql, но на других базах делал словарь, связанный с изначальным списком, и индексацию на префиксный like. Работало неплохо.
На postgres есть вообще FTS как раз для полнотекстового поиска (правда, мне не совсем подошло).
0
Да.
Проблема обычно в том, что надо искать по всем словам в строке.
Первый же пример из первого же попавшегося магазина:
"17.3" Ноутбук DEXP Ares E101 серый"
Просто like ноутбук% или Ares% (наиболее очевидные варианты) тут уже не проходит.
Для моих целей было достаточно искать по началу слова, или по префиксу всей строки, но, как правило, может быть сложнее
"ноутбук Ares" - вполне разумный запрос. А тут уже надо, как минимум, разбиение поисковой строки на токены, разбиение наименований на токены с индексацией и прочая хрень по сведению.
В общем, колхоз сделать не так просто, как кажется. Так что для "общих целей" лучше посмотреть в сторону баз, который поддерживают индексацию для текстового поиска и задрачиваться с ними.
UPD: Ну, или формализировать критерии поиска для конкретной предметной области, и наколхозить именно для нее. Так даже может получиться лучше, но такую формализацию сделать - не в лужу пукнуть.
Проблема обычно в том, что надо искать по всем словам в строке.
Первый же пример из первого же попавшегося магазина:
"17.3" Ноутбук DEXP Ares E101 серый"
Просто like ноутбук% или Ares% (наиболее очевидные варианты) тут уже не проходит.
Для моих целей было достаточно искать по началу слова, или по префиксу всей строки, но, как правило, может быть сложнее
"ноутбук Ares" - вполне разумный запрос. А тут уже надо, как минимум, разбиение поисковой строки на токены, разбиение наименований на токены с индексацией и прочая хрень по сведению.
В общем, колхоз сделать не так просто, как кажется. Так что для "общих целей" лучше посмотреть в сторону баз, который поддерживают индексацию для текстового поиска и задрачиваться с ними.
UPD: Ну, или формализировать критерии поиска для конкретной предметной области, и наколхозить именно для нее. Так даже может получиться лучше, но такую формализацию сделать - не в лужу пукнуть.
0
S
Sergey Pravodelov
14 августа 2015
Ну на типа того. Я бы на Redis поставил.
В общем работа с данными, БД и её сервером должна решаться до autocomplete :)
В общем работа с данными, БД и её сервером должна решаться до autocomplete :)
0
Ну, я и говорил, что лучше воспользоваться продуктами, которые эту проблему решают.
Вроде, я его видел, когда колхозил (дело было месяцев 8 назад, а прототип надо было делать буквально за недели), но что-то не подошло. Так же как и с FTS в Postgresql.
Если интересно - большинство проблем, которые возникали с полнотекстовыми решениями:
- нужно было выдавать хоть какие-то результаты по первым буквам (кто-то, вроде, мог это делать, но большинство дает тупо по словарям)
- проблемы с разными языками/стоп-словами и прочее. Это зашибись для поиска в документах, где это реально важно, чтобы по букве 'a' не выдавалось все, ибо артикль везде, но надо было искать по "номенклатуре", где это не применимо.
- результаты должны были ранжироваться не только по релевантности "текстовой", но и по дополнительному "приоритету" со стороны (ну, типа популярности запроса).
Вроде, я его видел, когда колхозил (дело было месяцев 8 назад, а прототип надо было делать буквально за недели), но что-то не подошло. Так же как и с FTS в Postgresql.
Если интересно - большинство проблем, которые возникали с полнотекстовыми решениями:
- нужно было выдавать хоть какие-то результаты по первым буквам (кто-то, вроде, мог это делать, но большинство дает тупо по словарям)
- проблемы с разными языками/стоп-словами и прочее. Это зашибись для поиска в документах, где это реально важно, чтобы по букве 'a' не выдавалось все, ибо артикль везде, но надо было искать по "номенклатуре", где это не применимо.
- результаты должны были ранжироваться не только по релевантности "текстовой", но и по дополнительному "приоритету" со стороны (ну, типа популярности запроса).
0
Хорошо, например, Гуглу с кешем. Хомячки бОльшую часть популярных запросов протащат в кеш так, что сколь-либо значимый процент пользователей не заметит первой задержки.
Но вот если хомячков мало, и каждый ищет свое - процент непопадания в кеш будет полной жопой. Вот как ее решить - в этом весь вопрос.
З.Ы. Гуглу вообще хорошо - у них уже и словарные базы есть, и синонимы и прочее... Но заказчик, я полагаю, совсем не Гугл :-)
Но вот если хомячков мало, и каждый ищет свое - процент непопадания в кеш будет полной жопой. Вот как ее решить - в этом весь вопрос.
З.Ы. Гуглу вообще хорошо - у них уже и словарные базы есть, и синонимы и прочее... Но заказчик, я полагаю, совсем не Гугл :-)
0
у нас написано руками на PHP, MySQL. autocomplete вовсе не обязательно.
сейчас в БД более 86 тыс. profsector.com/katalog. Планируется более 600 тыс. вероятно нужна какая то подготовка индексов БД.
сейчас в БД более 86 тыс. profsector.com/katalog. Планируется более 600 тыс. вероятно нужна какая то подготовка индексов БД.
0
alxumuk2 писал(а)Это на калькуляторе что ли? :о)
Но я на 300к записей делал - там поиск будет минутами исчисляться
Вот есть под рукой MS SQL Server 2008 на серваке средней руки. Есть таблица на 400К записей. Запрос
select * from MyTable where FIO like '%иванов%иван%'
выполнялся 0.2 секунды. Неужто мыскль настолько тормознее?
0
Жданный Гость
17 августа 2015
Да тут без разницы - с автокомплитом или без.
Вам, как я понимаю, нужен поиск по сложным документам.
Эластиксерч весьма пригож именно для этого - разные атрибуты, веса, очепятки и стемминг - работа с словоформами.
При этом он живуч под нагрузками.
сколько записей не столь важно - вопрос скорее в объеме данных, по которым вам нужен поиск и требования к скорости - т.е. нужна ли вам эта мощь.
Вам, как я понимаю, нужен поиск по сложным документам.
Эластиксерч весьма пригож именно для этого - разные атрибуты, веса, очепятки и стемминг - работа с словоформами.
При этом он живуч под нагрузками.
сколько записей не столь важно - вопрос скорее в объеме данных, по которым вам нужен поиск и требования к скорости - т.е. нужна ли вам эта мощь.
0
Вы не можете отвечать в этой теме.
Вы не авторизованы на сайте. Авторизоваться или
зарегистрироваться на сайте.
