Интересно мнение людей по методам поиска в базе.
Если есть линки по этому поводу, кидайте с удовольствием почитаю. Интересуют методы реализации быстрого поиска, но скорее не на основе составления индекса слов по базе (fulltext index). Имхо, поиск по проиндексированным словам не удобен и найти в нем что либо проблематично (особенно когда записи составляют не словесный текст), хотя и работает он очень быстро.
К примеру есть запись "Привет страна", записей подобных скажем около 1 млн.
И по поиску "трана", все таки найти эту запись с приемлемой скоростью.

Цитата

К примеру есть запись "Привет страна", записей подобных скажем около 1 млн.

Цитата

И по поиску "трана", все таки найти эту запись с приемлемой скоростью.

Код

Select idn, field1 from table1 where field1 Like '%трана'

%abc-любое количество символов перед abc (abc-в конце строки)
abc%-любое количество символов после abc (abc-в начале строки)
%abc%-любое количество символов после и перед abc (abc-в любом месте строки строки)

1 млн. это множественное число а "эта запись" единственное - уточни чего хотел найти.

ещё с Where (поиск по условию) можно использовать In, all, any,
c Join также производится поиск с использованием нескольких таблиц (в смысле выводятся одинаковые записи из разных таблиц),
есть ещё Having,
да мало-ли ещё чего есть.

В общем мой совет: учи SQL

Проблема не в знании мной SQL. А скорее в не огромном опыте который у меня имеется. На форуме много людей и суммарный опыт огромен.

Метод который Вы описали критичен и не выполним на практике. Вернее выполним, но очень глуп.
Почему? Опишу:
1. Есть оператор locate в mysql, который работать будет немного быстрее чем like с регулярками.
2. Таблица с 1 млн. строк предположим будет занимать 2.5 гиг. Так же предположим, что у сервера есть 1 гиг оперативки. Сугубо теоретически сервер сможет кешировать 1 гиг этой таблицы. Для выполнения sql описанного Вами потребуется огромное кол-во времени.
Для выполнения sql серверу mysql потребуется поднять абсолютно все данные находящиеся к этому моменту в этой таблице. Для кешированого 1 гигабайта данных это пройдет относительно быстро (1-3 секунды, на процессоре > 2 гигагерц). Дальше самое интересное. Остальную часть данных придется читать винчестеру. Предположим на сервере стоят высокоскоростные винты со скоростью чтения около 100 мегов в секунду. Для часто изменяемой таблицы данные в ней будут сильно фрагментированы (даже если несколько раз в неделю проводить дефрагментацию данных в самой таблице mysql и самого файла хранящего инфу в таблице (что сложнее)) и скорость чтения упадет скажем в 3 раза (сомневаюсь, падение будет гениальным), т.е. получаем 33 mb/s в лучшем случае. И так считаем 1500/33 = 45 секунд. В итоге получаем оптимальное время поиска в 47 секунд в случае если поиск проводит 1 человек. Если поиск будут проводить одновременно 10 человек, то уверен, что никто из них результата не получит.

Мне же хочется найти/изучить метод (именно метод, не думаю, что есть определенный sql код который мне поможет. Fulltext index, мне не сильно подходит. Т.к. в нем очень проблематично найти данные, если записи хранят не словесный текст.)

Zipo
Мимо индекса тебе в принципе не пройти. Либо индекс, либо прямой просмотр - третьего не дано.
В приведенном тобой примере простое существование индекса по полю, где ищешь, приведет к просмотру не всех данных, а только самого индекса - а это уже не 2.5 гектара.

PS. Конечно, надо посмотреть план выполнения и убедиться, что этот индекс таки используется.

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

Zipo
Дался тебе этот полнотекстовый, тем более что он тебе не подходит... обычный некластерный индекс построй - уже будет ощутимый прирост по сравнению с прямым просмотром.
А насчет

Цитата(Zipo @ 28.7.2005, 16:18)

Лучше сначала убедится, что другого метода в принципе не существует.

так все методы поиска и оптимизации, заложенные в движок БД, расписаны в документации, искать что-то еще - зря время тратить, ибо нету... не собираешься же ты модифицировать исходный код и вводить туда особый тип поиска...

Цитата

обычный некластерный индекс построй

Что ты имеешь ввиду под этим?

Zipo
Ну знаешь... насчет того что есть кластерные и некластерные индексы - давай ты все-таки в поиск сходишь или доки почитаешь, а?

А как насчет full text search in boolean mode. Пробовал, но большого опыта нет. Было бы здорово испытать на скорость

Цитата

Ну знаешь... насчет того что есть кластерные и некластерные индексы - давай ты все-таки в поиск сходишь или доки почитаешь, а?

Вообще-то fulltext index относится к не кластерным индексам. И, что Вы имели ввиду когда говорили

Цитата

Дался тебе этот полнотекстовый, тем более что он тебе не подходит... обычный некластерный индекс построй - уже будет ощутимый прирост по сравнению с прямым просмотром.

мне не понятно.
Обычные некластерные простые индексы могут быть построены только на поля ограниченной длинны (char, varchar). И абсолютно не пригодны для поиска в больших кол-вах текста. Именно для этого и был создан полнотекстовый индекс. Полнотекстовый индекс как мне известно это единственный метод предлагаемый БД для поиска по текстовой информации. При его использовании получаем огромный прирост скорости взамен удобству и качеству, который предлагает like с регулярными выражениями.
Поэтому я и попросил Вас уточнить мысль, если она конечно вообще имеется.
Исходный текст БД модифицировать не обязательно, можно строить методы поиска на основе функций которые предлагают современные БД. Наподобие того, как несколько лет назад делали ручную реализацию полнотекстового индекса описаного в этой статье http://www.citforum.ru/database/articles/search_sys.shtml


Гость_Станислав: Был бы рад ссылкам на описание метода с помощью которого реализовывается алгоритм.

Цитата(Zipo @ 1.8.2005, 20:06)

fulltext index относится к не кластерным индексам

Да, но это особый тип индекса, сильно отличающийся от обычных.

Цитата(Zipo @ 1.8.2005, 20:06)

Поэтому я и попросил Вас уточнить мысль, если она конечно вообще имеется.

Имеется, имеется. Вы так и не соизволили сообщить, каковы типы данных в БД, в которых производится поиск. Однако фразы

Цитата(Zipo @ 28.7.2005, 15:02)

Таблица с 1 млн. строк

Цитата(Zipo @ 28.7.2005, 15:02)

хранят не словесный текст

заставили меня думать, что поиск ведется НЕ в полях типа text/blob, а именно в varchar почему-то... или интерес - в данный момент чисто академический, к конкретной работе не привязанный?

Кстати,

Цитата

В версии MySQL 4.0 производится другая оптимизация на выражении LIKE. Если используется выражение ... LIKE "%string%" и длина строки (string) больше, чем 3 символа, то MySQL будет применять алгоритм Турбо Бойера-Мура для инициализации шаблона для строки и затем использовать этот шаблон, чтобы выполнить поиск быстрее.

так что не все так грустно. Кстати, это работает не только на varchar, но и на префиксе text.

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

Использоваться будут поля varchar.

Алгоритм Турбо Бойера-Мура уменьшает нагрузку на процессор, но в любом случае требует просмотра всех данных. В примере который я описывал 45 секунд будет идти на чтение данных. Это очень хорошо, что используется этот алгоритм в mysql. Но он не поможет.

Если кому интерестно, то вот отличное описание алгоритма Алгоритм Турбо Бойера-Мура и его визуализация.
http://rain.ifmo.ru/cat/view.php/vis/strin...oyer-moore-2001

Цитата(Zipo @ 2.8.2005, 01:15)

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

???

Если у нас есть обычный индекс длинной 20 на поле varchar которое в обной из строк содержит
"САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ"

То этот индекс будет использован только в случае подобного запроса:
... where fld1 like "САНКТ%"
... where fld1 = "САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ"

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

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

Zipo
Вообще обычно индексы планируются не для самоудовлетворения, а именно для того чтобы они использовались запросами.
А если ТАКОЙ контент поля не в словаре, а в основной БД - есть повод пересмотреть структуру базы, а не заниматься оптимизацией запросов.