ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Про полнотекстовый поиск и поисковые машины
21 сообщений из 21, страница 1 из 1
Про полнотекстовый поиск и поисковые машины
    #35854401
dundin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dundin
Гость
Добрый день!
Вопрос касается быстродействия полнотекстового поиска.
Разрабатываю что то типа сервиса вертикального поиска. Ну к примеру чтобы было понятно
http://100rabot.ru . Если вы зайдете и проверите - ну например вводим в строку поиска
"менеджер по продажам" - результат формируется мгновенно. При
этом в результате поиска мы видим только те документы которые содержат все три слова.
И сдается мне этот сервис не использует какую либо из СУБД, а использует технологии которые используются в обычных поисковиках.

Как вы считаете? Реально ли такой скорости достичь на MySQL/Oracle или еще какой либо СУБД?
Стоит заметить что поиск производится по более чем 600 000 документов. Я попробовал протестировать
стандартный полнотекстовый поиск на MySQL (fulltext match и т.д.). Чтобы выводились ТОЛЬКО
те документы содержащие ВСЕ ТРИ заданных слова - необходимо включать логический поиск. Так вот на 30 000 документах на Pentium 2.4 500МБ поиск выполнялся более минуты

Затем я попробовал пойти нестандартным путем и создал две таблицы
справочник слов и таблицу связи "слова - документы".
Т.е. сначала определяем id всех слов в справочнике, а затем выполняем вот такой запрос который
выводит только те документы которые содержат все три слова:

SELECT docs.id SUM(docwords.relev)
FROM docwords INNER JOIN docs ON docs.`id` = docwords.`doc_id`
WHERE docwords.word_id IN (517544, 517559, 518262)
GROUP BY id
HAVING SUM(docwords.relev) > (Здесь пороговое значение релевантности)
ORDER BY relev DESC

Ну вообщем думаю смысл понятен.

Собственно этот вариант работал на порядок быстрее чем стандартный полнотекстовый поиск,
но все равно время измерялось секундами (1,2,3).

Из всех эксперементов сделал вывод что 100rabot.ru и подобные ему сервисы - это не СУБД,
а что то типа маленького Гугля.

И еще: очень мало нашел в инете информации про технологию работы поисковых сервисов и собственно - создание самих сервисов.
Везде только общие слова - а конкретных примеров вообще нет.
Может кто нибудь интересовался этой темой - помогите ссылками?
...
Рейтинг: 0 / 0
05.03.2009, 20:20
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854411
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
dundinМожет кто нибудь интересовался этой темой - помогите ссылками?

Коллега, поиск - движки и их создание - это целая наука. Не зря же существует такая конкуренция в казалось бы простой и никому не нужной среде - поиска.... Посмотрите тут
...
Рейтинг: 0 / 0
05.03.2009, 20:27
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854414
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Обычными средствами - уже существующими - Вы совершенно правы - проще пользовать именно полнотекстовой поиск баз данных. Но каковы Ваши задачи...?
...
Рейтинг: 0 / 0
05.03.2009, 20:28
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854417
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Имхо, вполне в качестве хранилища может использоваться СУБД. Но современные сайты строятся так, что вовсе необязательно запрос страницы приводит к чтению из СУБД.
Например, почитайте тут (материала там маловато, но ключевых слов достаточно на первое время)
...
Рейтинг: 0 / 0
05.03.2009, 20:31
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854423
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
dundinИз всех эксперементов сделал вывод что 100rabot.ru и подобные ему сервисы - это не СУБД, а что то типа маленького Гугля.

И еще: очень мало нашел в инете информации про технологию работы поисковых сервисов и собственно - создание самих сервисов.
Везде только общие слова - а конкретных примеров вообще нет.
Может кто нибудь интересовался этой темой - помогите ссылками?

дА Есть Вики - может и тут найдёте чё нить стоящее... А насчёт что там - база или не только... Хороший вопрос. Обычно и то и другое.
...
Рейтинг: 0 / 0
05.03.2009, 20:34
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854461
dundin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dundin
Гость
Спасибо всем за ответы. Ссылки посмотрю.

Mr MarmeladОбычными средствами - уже существующими - Вы совершенно правы - проще пользовать именно полнотекстовой поиск баз данных. Но каковы Ваши задачи...?

Задача - максимальная скорость поиска. Т.е. представляете - заходит чел. на Яндекс вводит "куплю лопаты" - и секунд через 15 ему результат. Я думаю - уже на следующий день лидирующим поисковиком в Рунете станет Гугль:))

Я собственно интересуюсь идеологией построения индексов поисковых систем. Ну хотя бы в общих чертах. Хотя бы на словах. На словах я описываю это так: определить id документов где встречается слово1, слово2, слово3. Взять только те - которые есть в каждом документе. Но: на Pentium 2.4 даже примитивный запрос в MySQL на проиндексированных полях такие запросы выполняются несколько десятков (или даже сотен) милисекунд.

А вот поисковая машина StackSearch выполняет такой поиск за 0,03 сек.
...
Рейтинг: 0 / 0
05.03.2009, 20:59
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854464
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
dundinна Pentium 2.4 даже примитивный запрос в MySQL на проиндексированных полях такие запросы выполняются несколько десятков (или даже сотен) милисекунд.Показывайте ваш запрос :)
...
Рейтинг: 0 / 0
05.03.2009, 21:02
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854469
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
dundinА вот поисковая машина StackSearch выполняет такой поиск за 0,03 сек.

Ну и с чего Вы коллега решили что там MySQL рулит.... Любой поисковый движок - прежде всего аппаратная система - Обычно не на основе Windows - с серъёзным хранилищем и целым рядом специальных "лубрикаторов" для вывода .... Шоб не скрипело когда выводит...
...
Рейтинг: 0 / 0
05.03.2009, 21:08
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854482
dundin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dundin
Гость
miksoftdundinна Pentium 2.4 даже примитивный запрос в MySQL на проиндексированных полях такие запросы выполняются несколько десятков (или даже сотен) милисекунд.Показывайте ваш запрос :)

есть 3 таблицы:
1. Справочник слов words (id INTEGER PRIMARY KEY, word VARCHAR(250));
2. Документы (id: Integer PRIMARY KEY, body : Text);
3. Таблица связи docwords (doc_id, word_id, relev) построен индекс (doc_id, word_id). Для увеличения скорости поиск я этот индекс загружал в кеш в оперативку. Relev - это релевантность данного слова в данном документе.

Собственно запрос:

SELECT docs.id, SUM(docwords.relev)
FROM docwords INNER JOIN docs ON docs.`id` = docwords.`doc_id`
WHERE docwords.word_id IN (517544, 517559, 518262)
GROUP BY id
HAVING SUM(docwords.relev) > (Здесь пороговое значение релевантности ниже которого попадают документы содержащие не все заданные слова)
ORDER BY relev DESC

Результат: 30 - 35 тыс. документов, в справочнике слов 98 000 записей, в таблице связи 2,5 млн. записей. Минимальное время выполнения запроса - 0,3 сек. Если количество полей для выборки увеличить - время возрастет до секунды, а то и более.
...
Рейтинг: 0 / 0
05.03.2009, 21:19
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854496
dundin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dundin
Гость
Mr MarmeladdundinА вот поисковая машина StackSearch выполняет такой поиск за 0,03 сек.

Ну и с чего Вы коллега решили что там MySQL рулит.... Любой поисковый движок - прежде всего аппаратная система - Обычно не на основе Windows - с серъёзным хранилищем и целым рядом специальных "лубрикаторов" для вывода .... Шоб не скрипело когда выводит...

Так я и не говорил что там MySQL рулит, коллега:) Я зашел спросить что там рулит. Т.е. что представляет из себя индексы поисковых систем?
...
Рейтинг: 0 / 0
05.03.2009, 21:23
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854518
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
dundinесть 3 таблицы:
1. Справочник слов words (id INTEGER PRIMARY KEY, word VARCHAR(250));
2. Документы (id: Integer PRIMARY KEY, body : Text);
3. Таблица связи docwords (doc_id, word_id, relev) построен индекс (doc_id, word_id). Для увеличения скорости поиск я этот индекс загружал в кеш в оперативку. Relev - это релевантность данного слова в данном документе.

Собственно запрос:

SELECT docs.id, SUM(docwords.relev)
FROM docwords INNER JOIN docs ON docs.`id` = docwords.`doc_id`
WHERE docwords.word_id IN (517544, 517559, 518262)
GROUP BY id
HAVING SUM(docwords.relev) > (Здесь пороговое значение релевантности ниже которого попадают документы содержащие не все заданные слова)
ORDER BY relev DESCНужен индекс на таблице docwords, имеющий первым поле word_id.
Какой именно - точно не скажу, зависит от данных. Попробуйте (word_id) и (word_id, doc_id, relev).
Не поможет - показывайте все варианты запросов, индексов и планы.

PS. Наверное, стоит нам переехать с этим вопросом в подфорум MySQL.
...
Рейтинг: 0 / 0
05.03.2009, 21:32
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854597
dundin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dundin
Гость
miksoftНужен индекс на таблице docwords, имеющий первым поле word_id.
Какой именно - точно не скажу, зависит от данных. Попробуйте (word_id) и (word_id, doc_id, relev).
Не поможет - показывайте все варианты запросов, индексов и планы.

PS. Наверное, стоит нам переехать с этим вопросом в подфорум MySQL.

Это я все делал. Сделал индекс word_id - doc_id, первым идет поле word_id, + каждое поле в отдельности проиндексировал (кстати в плане видно что MySQL не берет составной индекс если не указать его явно USE INDEX (...), а берет простой по полю word_id), загрузил этот индекс в оперативку.

Все равно термин "мгновенно" не применим к времени выполнения - ощутимые тормоза. И это при 30 000 документах. А если их будет 300 000 - то время будет исчислятся секундами, а то и более.
...
Рейтинг: 0 / 0
05.03.2009, 22:22
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35854742
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
dundinСделал индекс word_id - doc_id, первым идет поле word_id, + каждое поле в отдельности проиндексировал (кстати в плане видно что MySQL не берет составной индекс если не указать его явно USE INDEX (...), а берет простой по полю word_id), загрузил этот индекс в оперативку.Правильно не берет, индексы (word_id, doc_id) и (word_id, relev) явно хуже, чем просто (word_id).

dundinВсе равно термин "мгновенно" не применим к времени выполнения - ощутимые тормоза. И это при 30 000 документах. А если их будет 300 000 - то время будет исчислятся секундами, а то и более.Таки изложите все это в подробностях в подфоруме по MySQL, покумекаем... если интересно, конечно.
...
Рейтинг: 0 / 0
06.03.2009, 00:00
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35855096
TomasVercetti
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TomasVercetti
Гость
Вам нужен full-text index . Это не тоже самое, что обычный index - строится другой тип деревьев. Под MySQL популярна реализация Sphinx .

Гугл для достижения таких скоростей использует свою собственную базу данных - BigTable , спаренную с их же файловой системой. Да и количество и качество железа играют далеко не последнюю роль.
...
Рейтинг: 0 / 0
06.03.2009, 10:14
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35855301
dundin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dundin
Гость
TomasVercettiВам нужен full-text index . Это не тоже самое, что обычный index - строится другой тип деревьев. Под MySQL популярна реализация Sphinx .

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

Спасибо, TomasVercetti , за ссылки. Вообще по слову Sphinx нашел вот такую страницу
http://www.opennet.ru/prog/sml/77.shtml , где описаны много поисковых систем. В том числе и Sphinx.

Я второй Гугл делать не собираюсь, у меня задача вполне конкретная - полнотекстовый поиск по 600 000 документов. При этом на более менее современном оборудовании (к примеру Intel Xeon 3 GHz с 1 Gb ОЗУ, ОС Linux;) поиск не должен превышать 0,1 сек. При этом если в запросе несколько слов - то должны выводится документы содержащие ВСЕ слова. А если еще будет сортировка по релевантности - то я буду самым счастливым челом на свете

Про Full Text: я делал все по инструкции:): Например вот .
Т.е. делаем FULL TEXT индекс
Затем пишем
SELECT * FROM table WHERE MATCH field1, field2 AGAINST (строка для поиска);

Но, когда нужно чтобы выводились документы содержащиен все слова запроса - нам нужно включить опцию IN BOOLEAN MODE и добавить "+" перед каждым словом. Так вот: Без BOOLEAN MODE - этот поиск выполняется не быстро, а при включении BOOLEAN MODE время запроса увеличивается в разы. На 30 000 документах время составляло десяки секунд.

Поэтому я и пришел к выводу: сделать справочник слов, и таблицу связи в каком документе какое слово встречается. Как показывает вот эта статья - я был недалек от того как работают реальные поисковики. Конечно там все гораздо сложнее и запущенее:) но в моем случае стоит гораздо более примитивная задача нежели перед Гуглем.
...
Рейтинг: 0 / 0
06.03.2009, 11:16
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35855791
TomasVercetti
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TomasVercetti
Гость
[quote dundin ]...При этом если в запросе несколько слов - то должны выводится документы содержащие ВСЕ слова. А если еще будет сортировка по релевантности - то я буду самым счастливым челом на свете

Про Full Text: я делал все по инструкции:)...

...Поэтому я и пришел к выводу: сделать справочник слов, и таблицу связи в каком документе какое слово встречается. Как показывает вот эта статья - я был недалек от того как работают реальные поисковики...[/quote]

Встроенный в MySQL fulltext работает очень медленно (по сравнению с теми же MSSQL и Oracle), имеет немало ограничений, "существенная" настройка - через изменение исходников и перекомпиляцию (или плагины в 5.1). Не зная объёма ваших 30 000 документов и прочей технической информации, сложно сказать, является ли узким местом именно это. А вы проверяли, что индексы были (корректно) созданы и сервер их использует? Конструкция MATCH (...) AGAINST (...) работает и без них, но на порядки медленнее.

Да, по идее реализации вы начинаете двигаться в нужном направлении. :) Но осуществление всякого рода релевантностей, приемлемого по времени поиска по вашему "индексу" съест немало времени. И, учитывая количество уже готовых и проверенных "в бою" fti (indexers), предназначенных для больших объёмов данных и находящихся в разработке годами, - просто не нужно. Всё равно по скорости они будут впереди, и, скорее всего, значительно.

Успехов :)
...
Рейтинг: 0 / 0
06.03.2009, 13:14
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35856248
dundin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dundin
Гость
К этому моменту прочитал уже немало статей про Sphinx - одни радужные отзывы:) По ходу дела - то что нужно. Вот цитата из статьи:

"
Например, в реальной базе данных, состоящей примерно из 300 000 строк и пяти индексированных столбцов, где каждый столбец содержит около 15 слов, Sphinx может выдать результат по поиску "любое из этих слов" за одну сотую долю секунды (на сервере с процессором AMD Opteron с частотой 2 ГГц и 1 ГБ памяти, работающем под управлением Debian Linux® Sarge).
"

А вот сама статья .

Как раз скорость в "одну сотую секунды" меня и интересует:)

Спасибо еще раз всем, особенно TomasVercetti :)
...
Рейтинг: 0 / 0
06.03.2009, 15:51
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35856768
Dmitriy Ivanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dmitriy Ivanov
Участник
d> Автор: dundin
d> Спасибо еще раз всем, особенно TomasVercetti :)

Позволю добавить к сказанному TomasVercetti. Реляционная БД не очень
подходящий инструмент для полнотестового поиска. А потому
1) храните документы не базе, а в обычный файлах,
2) установите Google Desktop и Яндекс персональный поиск.
и наслаждайтесь :-)


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
06.03.2009, 21:31
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35856960
dundin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dundin
Гость
Dmitriy Ivanov

2) установите Google Desktop и Яндекс персональный поиск.
и наслаждайтесь :-)



Я делаю интернет - сервис, т.е. обычный сайт. Там "Яндекс персональный поиск." не уместен:)

...

Только что протестировал Sphinx. Результат сравнения:
Набор данных: >36 000 записей.
Ищем по 2 полям: title (varchar 100) и description(Text);
Запрос: "менеджер по продажам" .
Цель: найти все документы содержащие все три слова.

Результат для собственного вышеописанного поиска (со справочником слов, таблицой связи и запросом с группировкой) 1.1 сек.
Найдено записей: 2134

Результат для Сфинкса:
Время выполнения запроса: 0.1 сек
Найдено записей: 3867

Вывод: скорость поиска в 11 раз быстрее. Плюс в Сфинксе есть учет морфологии: он и нашел больше записей потому что искал не только слово "продажам", а и "продажи", "продажа" и т.д. что есть неоспоримый плюс.

Это я еще не упомянул стандартный полнотекстовый поиск в MySQL - там результаты будут исчислятся десятками секунд.
...
Рейтинг: 0 / 0
07.03.2009, 08:56
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35857559
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tadmin
Участник
Откуда у вас берутся секунды не понимаю.

Postgresql 8.3, используем FTS на ispell словарях (ru + en, 138K +235K словоформ), stemmer словари и свой словарь синонимов ~ 600 слов.

Вот результаты:

Код: plaintext
1.
select count(*) from articles;
 42656

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
explain analyze select name from articles as a where  (to_tsquery('fts_ru', 'кирпичей') @@ to_tsvector('fts_ru', a.name))
"Bitmap Heap Scan on articles a  (cost=4.42..143.96 rows=43 width=31) (actual time=0.051..0.052 rows=1 loops=1)"
"  Recheck Cond: ('''кирпич'''::tsquery @@ to_tsvector('fts_ru'::regconfig, (name)::text))"
"  ->  Bitmap Index Scan on i_fts_gin_articles_name  (cost=0.00..4.41 rows=43 width=0) (actual time=0.039..0.039 rows=1 loops=1)"
"        Index Cond: ('''кирпич'''::tsquery @@ to_tsvector('fts_ru'::regconfig, (name)::text))"
"Total runtime: 0.094 ms"

"Антистресс «Кирпич»"
...
Рейтинг: 0 / 0
08.03.2009, 13:06
| Ответить | Цитировать | Написать  
Про полнотекстовый поиск и поисковые машины
    #35857566
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tadmin
Участник
замечу, что даже самый тупорылый способ индексации, когда вы не подготавливаете поисковые слова для индекса дает хорошую скорость на фразах:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
explain analyze select name from articles as a where  (to_tsquery('remba_ru', 'кружек') && (to_tsquery('remba_ru', 'синих')) @@ to_tsvector('remba_ru', a.name))
"Bitmap Heap Scan on articles a  (cost=4.42..143.96 rows=43 width=31) (actual time=0.707..0.745 rows=12 loops=1)"
"  Recheck Cond: ('''кружка'' & ''синий'''::tsquery @@ to_tsvector('remba_ru'::regconfig, (name)::text))"
"  ->  Bitmap Index Scan on i_fts_gin_articles_name  (cost=0.00..4.41 rows=43 width=0) (actual time=0.692..0.692 rows=12 loops=1)"
"        Index Cond: ('''кружка'' & ''синий'''::tsquery @@ to_tsvector('remba_ru'::regconfig, (name)::text))"
"Total runtime: 0.794 ms"
"Дорожная кружка, синяя, 450 мл"
"Кружка синяя (кобальт) цилиндрическая, 300мл."
"Кружка синяя матированная 340мл, Тайвань"
"Кружка матовая, синяя"
"Набор: термос (1л)+2 кружки (300 мл),сталь, снаружи пластик синего цвета"
"SN125 Кружка ярко-синяя (Reflex Blue), 300 мл"
"Кружка ,синяя Frost"
"Кружки Regal синие"
"Кружка синяя, прозрачная"
"Кружка синяя"
"Кружка, 300мл, темно-синяя"
"Кружка, 300мл, ярко-синяя"


explain analyze select name from articles as a where  (to_tsquery('remba_ru', 'прозрачную') && to_tsquery('remba_ru', 'синюю') &&  to_tsquery('remba_ru', 'кружку')) @@ to_tsvector('remba_ru', a.name)
"Bitmap Heap Scan on articles a  (cost=4.42..143.96 rows=43 width=31) (actual time=0.954..0.955 rows=1 loops=1)"
"  Recheck Cond: ('''прозрачный'' & ''синий'' & ( ''кружка'' | ''кружок'' )'::tsquery @@ to_tsvector('remba_ru'::regconfig, (name)::text))"
"  ->  Bitmap Index Scan on i_fts_gin_articles_name  (cost=0.00..4.41 rows=43 width=0) (actual time=0.944..0.944 rows=1 loops=1)"
"        Index Cond: ('''прозрачный'' & ''синий'' & ( ''кружка'' | ''кружок'' )'::tsquery @@ to_tsvector('remba_ru'::regconfig, (name)::text))"
"Total runtime: 0.995 ms"
"Кружка синяя, прозрачная"
...
Рейтинг: 0 / 0
08.03.2009, 13:18
| Ответить | Цитировать | Написать  
21 сообщений из 21, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Про полнотекстовый поиск и поисковые машины
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=35857559&tid=1543387]:
 0ms
get settings:
 5ms
get forum list:
 14ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 253ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 53ms
get tp. blocked users:
 1ms
others: 205ms
total:  545ms
созд. / загр.: 545ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]