Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Один работает - остальные висят. [MSSQL]

Страницы: 1 2 >
Shirson © (2003-12-04 07:43:00)

Если у одного пользователя отрабатывается большой и ресурсоёмкий запрос, например по поиску в полях типа text, то остальные аользователи не то что тормозят - просто "висят".
Есть ли возможность это побороть? Какой-нибудь ограничитель ресурсов сервера на выполнение одного запроса.
Можно без подробностей, просто подскажите в какую сторону смотреть :)

Hooch (2003-12-05 07:21:00) [1]

> Огромное Спасибо за идею.

Всегда пожалуйста ! :-)

Shirson (2003-12-05 06:25:00) [2]

Я его внедрю для Унутреннего пользования.
Когда докупят железячку, переключу на всеобщее пользование. Заодно и новую версию программы закончу. Кроме проблемы поиска в textесть и другие. Заодно и их решу и выдам всё за раз :)

(за 10 часов ночной работы по заполнению словаря, обработалось ~21000 существующих записей. Осталось еще ~48000. Как раз на выходные оставить жужжать.)

Anatoly Podgoretsky (2003-12-04 20:30:00) [3]

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

Anatoly Podgoretsky (2003-12-04 20:29:00) [4]

sniknik © (04.12.03 10:50) [26]
Машину усилить надо, но не по этой причине. Аппаратный RAID1/5 взависимости от денежных русурсов. Процессор можно и один, но лучше 2/4 XEON HT/MP
Двух канальная память до 2 гб

Shirson (2003-12-04 18:50:00) [5]

>Hooch

Огромное Спасибо за идею .
Написал я словарь, прикрутил реляции и даже статистику повторений приклямал.
База начинает расти (но не катастрофически, а логарифмически, причём с убыванием прогрессии роста. О загнул :)) Но скорость! Это просто пугает и ищешь подвох :) Раньше запрос считал статистику до 10 минут. Сейчас я палец не успеваю от кнопы оторвать, как выплёвывается результат.
За это пришлось, правда, заплатить потерей скорости в другом месте - при занесении данных. Но это еще можно пережить. Блок текста на ~270000 символов он раздербанивает за 2:10-2:20 минуты. Фигня, таких кусков не так уж и много и на этом этапе время некритично (потоковая обработка .doc-файлов в автоматическом режиме)

Shirson (2003-12-04 12:44:00) [6]

Это понятно, проблема в другом.
Запрос считает статистику повторений слова в поле. Вот это и тормозит запрос жутко. И есть CONTANS или нет его сути не имеет - этим оператором статистику не посчитаешь.

Я тут делаю пока словарь, сделал разбивалку на слова. Работает ОЧЕНЬ быстро. Вот её же я хочу прикрутить вместо статистического запроса с жуткими READTEXT и UPDATETEXT.

SergSuper (2003-12-04 11:29:00) [7]

Full-Text Index предназначен для Full-Text Search, который выполняяется посредством Full-text Query, в результате запрос должен быть вида:
SELECT ProductName FROM Products WHERE CONTAINS(ProductName, "spread NEAR Boysenberry")

Shirson (2003-12-04 11:06:00) [8]

>sniknik

Я себе это вижу так:
При вставке/апдейте поля с текстом, оно разбивается на слова.
Все слова, которые не содержатся в словаре в оный заносятся.
Кроме таблицы словаря, есть таблица содержания. Она связанна со словарём и в неё заносятся ID записей, содержащих тексты.

Словарь
-Народ-5
-Партия-6
Содержание
-5-1598
-5-16598
-5-21598
-5-1009598
-5-15980
-5-159648
-6-1009598
-6-4576
-6-786

Ищем "Народ" - получаем список ID-шников всех статей, где он есть.
Пересечение никаких проблем не вызывает. Можно выбирать или-или.
"Народ" или "Партия".
Можно и по И искать.

Вроде ничего. Только со статистикой пока затык.

Shirson (2003-12-04 10:59:00) [9]

>Anatoly Podgoretsky

Это само собой. Но железо под шумок выбить - тоже полезно.

Сейчас вариант Hooch-а пробую реализовать. Посмотрим, что получится.

sniknik (2003-12-04 10:50:00) [10]

Hooch © (04.12.03 09:58) [23]
а как с повторами быть? ведь необязательно 1 слово в одном тексте. надо список вхождений хранить. плюс если по нескольким словам поиск искать пересечения. получается чтото вроде интернет поисковика (в некоторых пишут слово - сколько вхождений, ...). ну в общем то они быстро ищут, несмотря на массу текстов (представляю себе сколько там). но вот только одним запросом не ограничишся, это целый алгоритм.

Anatoly Podgoretsky © (04.12.03 10:08) [25]
машину проапгрейдить тоже лишним не будет. (чего это за сервер без рейда на одном проце? просто рабочей станции присвоили гордое имя сервер? ;о))

Anatoly Podgoretsky (2003-12-04 10:08:00) [11]

Надо не железо менять, а алгоритмы, это основой резерв, а наращивание железа это экстенсивный путь, ведущий в тупик.

Shirson (2003-12-04 10:04:00) [12]

>Hooch

Тогда размер будет действительно не-детский...
Но это вариант. Спасибо, я его помозгую.

Hooch (2003-12-04 09:58:00) [13]

>> Shirson ©

"Заранее неизвестно, по каким словам будет поиск"
прежде чем текст ляжет в таблицу он разбирется и пополняет словарь отсутствующими словами, так что не важно по каким словам идет поиск, нет в словаре нет в тексте. Что касается нарезки на парараграфы, мне кажется это мало поможет, тормоза из-за полного прохода всех данных а в предложенном мною способе получается эффект поиска по индексу

Shirson (2003-12-04 09:31:00) [14]

>Nikolay M.

Попробую, спасибо.

Shirson (2003-12-04 09:25:00) [15]

>Hooch
Заранее неизвестно, по каким словам будет поиск, поэтому словарь тут неподойдёт.
У меня тут появилась одна ганжубасная идея... Нарезать текст на параграфы, и хранить как varchar.
Теперь надо подумать, как эту идею реализовать...

Nikolay M. (2003-12-04 09:10:00) [16]

> остальные аользователи не то что тормозят - просто "висят".

Именно висят? Попробуй FROM mytable ( nolock)
?

Shirson (2003-12-04 09:08:00) [17]

>sniknik
Таблица под Full-Text отмеченна.
Насчёт RAID - сам хочу, но недадут. Для них это дорого.

Hooch (2003-12-04 08:58:00) [18]

у нас есть справочник номенклатуры пордяка 2 миллионов товаров, на каждый товар несколько колонок с описанием типа text. есть справочник основ слов. при изменении поля текст разбирается на слова, у слов отсекаются окончания и создается "перевязка" между справочникм слов и текстом (КОД_СЛОВА;НОМЕР_ТОВАРА).
в итоге поиск просто "летает", но соответсвенно и размер БД будет больше. попробуй по такому принцпу сделать должно помочь

sniknik (2003-12-04 08:58:00) [19]

Shirson © (04.12.03 08:53) [15]
> Второй проц + 512 метров, это минимум. :)))
попытайся RAID выбить, если пока нет, 5 уровня (масив мин. на 3диска или 4(необязательно) 2(зеркало) просто не эфективно в плане скорости(та же остается)). ОЧЕНЬ ускоряет дисковые операции (в 2 раза гарантирую).

sniknik (2003-12-04 08:54:00) [20]

> Есть поле, типа text. Там лежит шмат текста, килов на 10-20.
а ты не путаеш?(или я) full-text это же вроде не поиск в текстах а поиск "не обрашая внимания на колонки" т.е. по всей строке.
а в тексте в любом случае перебор.
и таблици для него должны быть отмечены, во всяком случае так написано, в справке по sp_fulltext_table

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »