Как ускорить время поиска?

← →
AlexLines (2006-01-05 18:19) [0]

При формировании запроса к БД с помощью Like, особенно при длинном запросе like %а% and like %в% not like %б% и т.д. время запроса может составлять до 2-3 секунд (в базе содержится около 2000 записей) на Pentium 4,
на Pentium 3 время возрастает до 4 - 7 секунд,
на Pentium 2 может достигать 5 - 8 секунд.
Это время пропорционально количеству записей в БД

При таком поисковом запросе можно ли ускорить процесс поиска. Где можно найти литературу по оптимизации поиска. Может быть использовать локальные базы данных?

Спасибо

← →
Anatoly Podgoretsky © (2006-01-05 18:47) [1]

Не делать таких запросов.

← →
Fay © (2006-01-05 18:51) [2]

Время выполнения какое-то нереальное.
Количество записей просто смешное, а вот 3 секунды - уже не смешно. Жалко, не могу сам "потрогать" эту "БД".

← →
Desdechado © (2006-01-05 19:41) [3]

запросы с LIKE "%ю%" не используют индексов, только полный перебор всех записей

← →
Fay © (2006-01-05 19:57) [4]

2 Desdechado © (05.01.06 19:41) [3]
Там всего 2000 записей! На таком количестве особо и не нужен.

← →
Fay © (2006-01-05 19:58) [5]

Fay © (05.01.06 19:57) [4]
В смысле, "индекс особо не нужен".

← →
AlexLines (2006-01-05 21:14) [6]

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

индекс
"индекс"
(индекс)
/индекс/
индекс.
индекс!
индекс,

и т.д.

← →
AlexLines (2006-01-05 21:18) [7]

А еще вопрос к Анатолию Подгорецкому

А какие запросы делать ...?
Если вы конечно знаете
И где искать литературу по вопросу оптимизации поиска

← →
Anatoly Podgoretsky © (2006-01-05 21:38) [8]

AlexLines (05.01.06 21:18) [7]
При таких запросах %x% индексы не используются, к тому же у тебя много AND в одном запросе, так что время умножается.

А что ты хочешь сделать, может тебе поможет поиск по таблице слов?

← →
AlexLines (2006-01-05 22:27) [9]

Anatoly Podgoretsky © (05.01.06 21:38) [8]

Как осуществляется поиск по таблице слов?

← →
Anatoly Podgoretsky © (2006-01-05 22:35) [10]

Select * from Words where Wird="sdfsaf"

← →
Fay © (2006-01-05 22:40) [11]

2 Anatoly Podgoretsky © (05.01.06 21:38) [8]
> так что время умножается.

Всё должно быть не так трагично. В конце концов, не очевидно, что для большинства записей выполняются все проверки.

Ещё раз. Время выборки слишком большое - рагадох не держит особо длинных строк, а записей - кот наплакал. Т.о. общее количество операций довольно маленькое.

Мне кажется, дело не в запросе. Что-то с компом (или с сетью) не в порядке.

← →
Anatoly Podgoretsky © (2006-01-05 22:42) [12]

Fay © (05.01.06 22:40) [11]
Согласно теории вероятности 50%

← →
AlexLines (2006-01-05 23:30) [13]

Fay © (05.01.06 22:40) [11]
Что-то с компом (или с сетью) не в порядке.

Проверял на 10 компьютерах разной конфигурации
Приложение для локального использования (сеть не используется)

Поиск происходит по 3 полям базы данных типа memo
Размер базы 2 Мб

← →
Fay © (2006-01-05 23:58) [14]

Ага, MEMO значит. Об индексах говорить не приходится вовсе.

Что можно сказать в таком случае? Paradox фтопку.
Могу посоветовать MSSQL 2005 Express - там есть отлисная штука по имени varchar(max).
Хотя, возможно, это
а) неосуществимо (чужая прога, исходников нет (зато есть бесценные секретные алгоритмы), Коран не велит, и т.п.)
б) слишким жирно для решаемой задачи

Вы не пытались открыть тот же набор данных используя не where, а OnFilterRecord?

← →
sniknik © (2006-01-06 00:04) [15]

> Поиск происходит по 3 полям базы данных типа memo
чем дальше в лес, тем ну его нафиг. ;))

> Размер базы 2 Мб
это действительно размер базы? или таблици? или таблицы с файлом содержашим значения мемо полей? (т.е. того от чего зависит)

p.s.
> для локального использования
тут будет быстрее табличный доступ и поиск перебором, с однократным извлечением мемо поля и многократным поиском в нем вхождений.

← →
AlexLines (2006-01-06 00:31) [16]

Fay ©

Что можно сказать в таком случае? Paradox фтопку.

Если запрос состоит только из одного слова поиск значительно ускоряется - менее секунды

Однако поиск по маске может включать достаточно большой запрос - десятки слов "индекс", (индекс), индекс! not "яндекс", (яндекс), яндекс! и т.д. При этом поиск значительно замедляется

А почему Paradox -то фтопку?

sniknik ©

1. это действительно размер базы?

Размер таблицы с файлом содержашим значения мемо полей

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

А как это лучше осуществить (хотя бы кратко - основная идея)?

← →
Fay © (2006-01-06 00:42) [17]

2 AlexLines (06.01.06 0:31) [16]
> А почему Paradox -то фтопку?
Потому, что он - гуано полное. Прошу прощения за мой французский. Не понимаю, как можно до сих пор на нём писать, когда есть куча других движков (бесплатных и куда более мощных).

← →
AlexLines (2006-01-06 00:48) [18]

Fay ©

А что посоветуете
И чем оно лучше

Кроме этого, если присоединить Блоб поле, к этой базе данных, например с изображением (размер базы данных увеличивается с 2 до 12 Мб) поиск происходит очень медленно - на Pentium 4 - 10 - 15 секунд

Из-за чего это может происходить?

2 AlexLines (06.01.06 0:48) [18]
> Из-за чего это может происходить?
Рагадох не использовал уже лет сто, и не помню что там почём.

> А что посоветуете
Могу посоветовать FireBird. Могу. Но сам бы выбрал MSDE или, что куда вероятнее, MSSQL 2005 Express (совершенно бесплатная штука).

> И чем оно лучше
Не смогу объяснить. Это как сравнивать кошачью блевотину и армянский коньяк - даже не знаю с чего начать.
Попробуй, сравни сам. Такой опыт не останется мёртвым грузом.
Скажу только, что про "до 2-3 секунд (в базе содержится около 2000 записей) на Pentium 4" забудешь навсегда.

← →
AlexLines (2006-01-06 09:02) [20]

А что можно сказать по поводу FireBird против MySql

2 AlexLines (06.01.06 9:02) [20]
> А что можно сказать по поводу FireBird против MySql
Из FB и MySQL я бы выбрал первое. Но после рагадоха это без разницы 8)

Защитники и недоброжелатели найдутся для какого угодно движка. При этом у обоих сторон найдутся достаточно объективные аргументы.

З.Ы.
Уверен, с FB работать будет проще.

> [20] AlexLines (06.01.06 09:02)
> А что можно сказать по поводу FireBird против MySql

В MySQL транзакциев нормальных нету :0)

> [23] Anatoly Podgoretsky © (06.01.06 15:28)
> Джо © (06.01.06 15:15) [22]
> МайЭскьэлов - много, много тысяц

Стандартный дистрибутив ведь имеется? Вот я о нем. Или уже включили туда кривенькую поддержку транзакций. Ох, сомневаюсь...

2000 записей проще в память прочитать

Джо © (06.01.06 15:49) [24]
Да у них новые версии штампуются так, что не успеваешь их скачивать, я как то подсчитал количество для версии 3.х.х.х и прослезился.

Как ускорить время поиска? Найти похожие ветки