|
|
|
База только для выборки данных. Как лучше сделать для наибольшей скорости выборки?
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Мне нужно сделать программу в архитектуре КС, которая по запросам пользователей будет производить поиск в базе и выдавать пользователям информацию. На этом её функции исчерпываются, т.е. заливку, обновление или удаление данных буду производить я сам и очень редко, так что в первую (и, похоже, единственную) очередь интересует скорость поиска. Что из себя представляет база. У меня это несколько файлов Access порядка 600 Мбайт. Связей между таблицами нет, они отображают одну и ту же информацию, но собиралась она из разных источников, так что пока структура таблиц отличается. Почти все поля текстовые, также присутствуют Дата/Время и целочисленные. Поиск предположительно будет вестись только по текстовым полям. Большинство запросов будет вида LIKE БЛА-БЛА%, но возможны и вхождения %БЛА-БЛА%. В идеале пользователю должно возвратиться мало записей 1-10, если он указал точные параметры поиска. Железо следующее: есть три варианта. 1 – Pentium 2800 Мгц с 1024 Мб ОЗУ,. 2 – Pentium 500 Мгц и 128 метров оперативы, 3 - Celeron 1000 и 256 Мб ОЗУ. Желательно чтобы оно работало на 128 Мб ОЗУ (чем меньше требования, тем круче, так как комп должен быть включен постоянно, а свободных компов не хватает) – будет старый отдельный комп, сеть на 100 Мбит/с одноранговая. Скорее всего одновременно обращаться не будут, а если и будут, то не более двух-трёх пользователей (уже было что-то похожее, но база была небольшая и комп нормальный). Вся задача, чтобы прога работала пошустрее на старом железе с малым объёмом ОЗУ и небольшой тактовой частотой процессора. Посоветуйте, что сделать для наибольшей скорости поиска (или ничего не трогать и не обращать внимание на то, что будет только чтение из базы?): 1) Преобразовать к единой структуре таблицы (т.е. вся база будет состоять из одной таблицы) и слить в эту таблицу все данные. 2) Проиндексировать наиболее часто используемые текстовые поля. Вот тут возникает вопрос, может выбрать какую другую СУБД, не Access, чтобы искать по тексту с индексами. Может где индексы похитрее есть? 3) Ваши варианты, критика и т.п. У меня есть вариант слить всё это добро в Firebird или SQL Server 2000 (для 2005 уж точно комп со 128 Мб не пойдёт или я не прав?), так как может подойдут ещё данные, а в Access уже близко ограничение на размер базы. И как там с одновременно подключенными пользователями применительно к моей задаче? Справится с тремя? Может тупой вопрос, но я писал только однопользовательские проги с исп-ем Access. P.S. Сумбурно и много написал, а вопрос один: отличается ли проектирование баз только для выборки данных от «нормальных» БД, если хочется повысить скорость работы? Ну и с учётом не самого нового железа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2006, 21:43 |
|
||
|
База только для выборки данных. Как лучше сделать для наибольшей скорости выборки?
|
|||
|---|---|---|---|
|
#18+
И п1 и п2 подойдут, я бы сделал на OLAP-решение MS SQL Server`е, но это дело вкуса) Кстати при %БЛА-БЛА% индексы не используются, так что если такие запросы будут часто, то придется делать свою систему поиска на основе словарей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2006, 11:00 |
|
||
|
База только для выборки данных. Как лучше сделать для наибольшей скорости выборки?
|
|||
|---|---|---|---|
|
#18+
авторИ п1 и п2 подойдут, я бы сделал на OLAP-решение MS SQL Server`е, но это дело вкуса) Кстати при %БЛА-БЛА% индексы не используются, так что если такие запросы будут часто, то придется делать свою систему поиска на основе словарей. При чем тот ОЛАП то? И свою систему поиска не надо - есть Full Text Search у MS SQL, как раз для поиска, особенно такого - быстрее его не будет. Все поля, по которым искать, индексируются фуллтекстом и вперед. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2006, 12:58 |
|
||
|
База только для выборки данных. Как лучше сделать для наибольшей скорости выборки?
|
|||
|---|---|---|---|
|
#18+
ВСЕМ СПАСИБО! Значит так, сделал почти (под SQL Server 2005). На Celeron 1000 МГц самый тяжёлый запрос выполняется меньше чем за 40 секунд (правда если что-то ещё ресурсоёмкое запущено, то тайм-аут всё-таки выходит, надо увеличить). Средненький запрос <= 10 секунд, при условии, что это один пользователь одновременно запрашивает. P.S. Люди, смотрю я как Яндекс работает - порядка 1-2 секунд на запрос. Там ведь тоже полнотекстовый поиск, но почему быстрее? У них-то ведь и объёмы должны быть больше. Не только ведь в оборудовании дело? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2006, 15:51 |
|
||
|
База только для выборки данных. Как лучше сделать для наибольшей скорости выборки?
|
|||
|---|---|---|---|
|
#18+
Как сделал то? У яндекса свой сервер поиска, собственный, разработанный. И железо сумасшедшее. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2006, 11:27 |
|
||
|
База только для выборки данных. Как лучше сделать для наибольшей скорости выборки?
|
|||
|---|---|---|---|
|
#18+
Пока что с обычными индексами и то по паре полей... У меня вопрос: а можно использовать полнотекстовый поиск к словам, которые не являются обычными словами языка (ну там условные обозначения, аббревиатуры, фамилии, адреса, т.е. их нельзя взять из толкового словаря или любого другого словаря языка)? Я только в общем представляю, что такое FT-Search. Для изучения создал на 250 мегабайтной базе (с одной таблицей) полнотекстовый индекс по одному полю (в этом столбце информации мегабайт на 50-70), а база с индексом стала весить один гигабайт. Это нормально? Обобщённая база готова, в конце концов хочу и на ней попробовать, но пока что на небольшой тестирую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2006, 22:06 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33706703&tid=1545259]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
150ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 420ms |

| 0 / 0 |
