Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
мне поставлена задача для mssql-сервера. думаю, задача типичная.
однако я практически не знаю sql и вообще БД. могу составлять запросы :)

есть:
1)t_phrs: таблица неких "фраз" ("предложений").
по ней построены таблицы:
2)t_dict: словарь
3)t_word: идексы и позиция слова (см.ниже)

--таблица "предложений" (упрощенно):
create t_phrs (id int IDENTITY(1,1) NOT NULL, phrase nvarchar(3000) NOT NULL)

--таблица словарь:
create t_dict (id int IDENTITY(1,1) NOT NULL, txt nvarchar(64) NOT NULL)
CREATE UNIQUE NONCLUSTERED INDEX [IX_T_DICT] ON t_dict (txt ASC)

--таблица идентификаторов слов и фраз, в которых они (словА) находятся:

create t_word ( wid NOT NULL, -- индекс слова, содержащегося во фразе
pid int NOT NULL, -- индекс фразы
pos tinyint NOT NULL)-- позиция слова во фразе

CREATE NONCLUSTERED INDEX [IX_T_WORD] ON t_word (pid ASC)
CREATE NONCLUSTERED INDEX [IX_T_WORD] ON t_word (wid ASC)
ALTER TABLE t_word WITH NOCHECK ADD CONSTRAINT [FK_T_WORD_T_DICT] FOREIGN KEY([wid])
ALTER TABLE t_word WITH NOCHECK ADD CONSTRAINT [FK_T_WORD_T_PHRS] FOREIGN KEY([pid])

есть несколько таблиц t_phrs и соответствующих им t_word (по датам).
в каждой t_phrs по несколько десятков млн строк. соответственно, в t_word - сотни млн строк

-- для примера, поиск фраз, содержащих два слова:
select * from t_phrs p
inner join t_word w1 on w1.pid=p.id
inner join t_dict d1 on w1.wid=d1.id
inner join t_word w2 on w2.pid=p.id
inner join t_dict d2 on w2.wid=d2.id
where d1.txt='хорошая' and d2.txt='погода'
order by b.id

-- или для примера, поиск фраз, содержащих два слова, стоящих во фразе в порядке одно за другим:
select * from t_phrs p
inner join t_word w1 on w1.pid=p.id
inner join t_dict d1 on w1.wid=d1.id
inner join t_word w2 on w2.pid=p.id
inner join t_dict d2 on w2.wid=d2.id
where d1.txt='хорошая' and d2.txt='погода' and (w1.pos+1)=w2.pos
order by b.id

соответственно, для трех слов запросы длиннее.

однако, есть проблема.
Приведенные запросы выполняются по несколько минут (cpu i7, hdd тоже не слабый) при одной таблице t_phrs (30 млн строк), что, очень, очень долго.
А fulltext применять вообще невозможно, также по причине его тормозов. воще ужасных тормозов (или я что-то неправильно делаю).
При использовании fulltext запись происходит безобрАзно медленно. А надо до 100 тыс фраз в минуту.

Вопросы такие:
1. Правильно ли составлены таблицы, запросы.
2. Если нет - скажите, как это делают профессионалы
3. если кто сталкивался с такой задачей: как добиться максимального быстродействия?
10 авг 09, 01:15    [7515755]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3205
Лучше б вы начали не с изобретения очередного велосипеда типа "самописный FTS", а с закрытия вот этого ключевого недостатка:
vv40in
однако я практически не знаю sql и вообще БД.
Не говоря о данном занятии в целом, навскидку - индексы не имеют смысла и с большой долей вероятности не используются сервером. Вы, конечно же, планы выполнения запросов не смотрели?
10 авг 09, 01:32    [7515767]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
Ennor Tiegael
Лучше б вы начали не с изобретения очередного велосипеда типа "самописный FTS", а с закрытия вот этого ключевого недостатка:
vv40in
однако я практически не знаю sql и вообще БД.


вообще-то, я не большой поклонник sql, а совсем наоборот, скорее. и надеюсь, он мне больше не понадобится в дальнейшем.
у меня конкрктные вопросы, а не филосифский разговор о том, что чем больше узнаёшь тем больше убеждаешься в своём невЕдении.

да - это самописный FTS. но нам нужно сделать быстрый FTS, или заставить быстро работать существующий, если нужно и возможно - избавив его от какой-то лишней функциональности. нужно, чтоб в таблицу писАлось минимум, 20 тыс строк в минуту, до 100 тыс - нормально на загруженном сервере, до 200 тыс/мин - на незагруженном. Этого было бы достаточно.
собственно, это и есть вопросы:
1)возможно ли заставить быстро работать FTS MSSQL? как?
2)как далается FTS? что можно почитать на эту тему? нам много не надо. просто - достаточного быстродействия с минимумом функциональности (тезаурусов там, исправления ошибок, игнорирования предлогов там, и, ну, типа, слов, засоряющих русский язык :)

Ennor Tiegael

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

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

так есть в форуме, кто решал подобную задачу? помогите. вообще-то интересная ведь проблема..
10 авг 09, 17:49    [7519030]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
invm
Member

Откуда: Москва
Сообщений: 9226
Что делать, когда Full-Text бессилен или зарисовки на тему LIKE '%искомое%'
10 авг 09, 19:27    [7519414]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3205
100 000 вставок в минуту - вы собираетесь писать собственный гугл? В таком случае, я бы не рекомендовал использовать для хранения данных реляционную СУБД общего назначения - говорят, они для этого не очень подходят. Пейдж и Брин, насколько я помню, юзают что-то свое; Амазон тоже.

Ознакомиться с возможностями FTS можно, например, по официальной документации. Там даже русский есть, не поверите. И даже для 2005 версии - тоже, не поверите. Тезаурусы есть, нойз-ворды есть, FREETEXT() / SOUNDEX() тоже, опять-таки, никто не отменял...

Ну то есть, если вам надо обосновать начальству трату денег и времени на собственный велосипед - конечно, переубедить вас не сможет никто. Если же нет - наймите квалифицированного разработчика БД, имеющего опыт в использовании полнотекстового поиска, это будет наименее рискованным вариантом.

Касательно индексов - на малом объеме они могли сработать, но очень быстро отключатся, т.к. для сопоставления строк у вас используется столбец pos, а он никак не проиндексирован.

ЗЫ Можете и дальше бравировать нежеланием изучать sql, никто не заставляет Наоборот, все будут только рады.
10 авг 09, 19:28    [7519420]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
Ennor Tiegael
100 000 вставок в минуту - вы собираетесь писать собственный гугл? В таком случае, я бы не рекомендовал использовать для хранения данных реляционную СУБД общего назначения - говорят, они для этого не очень подходят. Пейдж и Брин, насколько я помню, юзают что-то свое; Амазон тоже.

Ну то есть, если вам надо обосновать начальству трату денег и времени на собственный велосипед - конечно, переубедить вас не сможет никто. Если же нет - наймите квалифицированного разработчика БД, имеющего опыт в использовании полнотекстового поиска, это будет наименее рискованным вариантом.

Касательно индексов - на малом объеме они могли сработать, но очень быстро отключатся, т.к. для сопоставления строк у вас используется столбец pos, а он никак не проиндексирован.

ЗЫ Можете и дальше бравировать нежеланием изучать sql, никто не заставляет Наоборот, все будут только рады.


спасибо за всё. только насчёт гула я не понял. но кажется это шутка. в расписанный выше набор таблиц я пишу ч-з ADO как раз скоростью 200 тыс строк в минуту. данные к нам поступают до 100 тыс строк в минуту, но надо обеспечить солидный запас...
кстати, не может ли кто посоветовать более быстрый интерфейс для mssql, чем ADO?

что касается этой разработки - я вообще здесь недавно и это как раз идея начальства, а мне же вовсе не хочется бодаться с sql. поэтому я предварительно пробовал побаловаться задать FT-индекс - оказалось, что меня не обманули: MSSQL FTS тормозит.
10 авг 09, 23:46    [7519880]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
vv40in
...поэтому я предварительно пробовал побаловаться задать FT-индекс - оказалось, что меня не обманули: MSSQL FTS тормозит.
Вы просто не умеете его готовить...
Да, бывают разного рода технические огрехи, которые, к слову, производитель достаточно резво исправляет...
Если же так хочестся написать "свой" или просто частично погрузится в один из принципов построения поисковиков, милости прошу -

http://www.itcommunity.ru/blogs/rsug/archive/2009/04/17/61528.aspx

Сообщение было отредактировано: 11 авг 09, 06:37
11 авг 09, 06:36    [7520109]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Tosh
Member

Откуда: Vladivostok
Сообщений: 2956
если честно - задача не достаточно тривиальная в плане нахождения фраз, содержащих искомые слова. Проблема только с обеспечением высокой производительности выборки (это было решено) и с поддержкой поискового индекса в актуальном состоянии (я в свое время забил на это и сделал отложенное перестроение индекса).
Если отказаться от идеи учитывать позицию слова в тексте - все достаточно просто:
1. Создается таблица уникальных слов, встречающихся по всем текстам (тут мы будем искать)
2. Создается таблица соотношения между словом и самим текстом
3. Имея только одну табличку под поиском - ничего не заморачиваемся и ищем наши слова в индексе
4. Полученную выборку из индекса накладываем на наши данные

Мне в свое время очень помогла эта статья - вдруг и Вам поможет.

Часть продукта, работающего на этой технологии трудится здесь (можно считать саморекламой )
______________________________
Чем чаще программист жалуется на чужой soft, тем хуже он делает свой.
11 авг 09, 07:27    [7520133]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3205
vv40in
вообще-то интересная ведь проблема..
Совершенно не интересная. Проще потратить 2-3 месяца на изучение готовых решений, имеющихся на рынке, и потом еще примерно столько же на разработку архитектуры системы на основе одного из них, нежели выбрасывать несколько лет своей жизни на создание монстра, который в конечном итоге окажется неработоспособен, т.к. в самом начале все забыли про какую-нибудь фишку в функциональности, без которой такой продукт никому не нужен.

На пальцах: допустим, вы найдете у себя в тексте словосочетание "хорошая погода" - окей. Но как вы рассчитываете найти его же в, скажем, дательном падеже? В FTS вычленением корней занимается отдельная библиотека-стеммер, которая для каждого языка, в общем случае, своя (хотя бы в силу того обстоятельства, что в каждом языке свои правила морфологии). Таким образом, несчастному пользователю придется последовательно искать в вашем поисковике "хорошей погоды", "хорошей погоде" и т.д., и это я еще не говорю об окончаниях числа и спряжения глаголов - там будет просто ад.
Для английского языка попытка наваять такое может иметь смысл, но русский - язык флексивного типа, без качественного стеммера в нем делать нечего.
11 авг 09, 09:26    [7520327]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
Ennor Tiegael
vv40in
вообще-то интересная ведь проблема..
Совершенно не интересная. Проще потратить 2-3 месяца на изучение готовых решений, имеющихся на рынке, и потом еще примерно столько же на разработку архитектуры системы на основе одного из них, нежели выбрасывать несколько лет своей жизни на создание монстра, который в конечном итоге окажется неработоспособен, т.к. в самом начале все забыли про какую-нибудь фишку в функциональности, без которой такой продукт никому не нужен.

На пальцах: допустим, вы найдете у себя в тексте словосочетание "хорошая погода" - окей. Но как вы рассчитываете найти его же в, скажем, дательном падеже? В FTS вычленением корней занимается отдельная библиотека-стеммер, которая для каждого языка, в общем случае, своя (хотя бы в силу того обстоятельства, что в каждом языке свои правила морфологии). Таким образом, несчастному пользователю придется последовательно искать в вашем поисковике "хорошей погоды", "хорошей погоде" и т.д., и это я еще не говорю об окончаниях числа и спряжения глаголов - там будет просто ад.
Для английского языка попытка наваять такое может иметь смысл, но русский - язык флексивного типа, без качественного стеммера в нем делать нечего.


спасибо. посоветую начальству прочитать эту переписку
11 авг 09, 17:04    [7524161]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
показал нач-ству. не помогло. в общем надо делать дальше в том же духе.
возвращаюсь к вопросам, сформулированным мной в начале этого треда. может кто-н прояснить ситуацию?
заранее спасибо за помощь.
8 сен 09, 18:30    [7633486]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
test1111
Guest
1. проиндескировать поле pos

2. написать что-то вроде
select [что нужно] from t_dict d1
inner join t_dict d2 on d1.pos=d2.pos-1 and d1.pid=d2.pid
where d1.wid = [id слова 'хорошая' в словаре]
and d2.wid = [id слова 'погода' в словаре]
9 сен 09, 12:28    [7636344]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
test1111
Guest
кстати, а какая все-таки задача была поставлена?
9 сен 09, 14:01    [7637031]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
test1111
Guest
прошу прощения, точнее вот так:

select p.* from
(
select w1.pid from t_word w1
inner join t_word w2 on w1.pos=w2.pos-1 and w1.pid=w2.pid
where w1.wid = [id слова 'хорошая' в словаре]
and w2.wid = [id слова 'погода' в словаре]
) fp
left join t_phrs p on p.id = fp.pid
10 сен 09, 01:54    [7639779]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
test1111
кстати, а какая все-таки задача была поставлена?

ну, она в точности описана в сАмом первом посте треда. я не знаю, что добавить. Вы наверное имеете ввиду: для чего всё это надо? но я не имею правов для уточнения. да и не важны ведь такие детали, не так ли? главное - добиться приемлегого быстродействия.
я раньше программировал железо. и таких прикладных задач не делал. с sql тож мало знаком. но и это не важно. надо бы сначала определить алгоритм индексирования-поиска. а на чём реализовывать - задача выбора
найти бы описания таких алгоритмов (теории fts). кто-н знает где искать?

test1111
1. проиндескировать поле pos
2. написать что-то вроде
select [что нужно] from t_dict d1
inner join t_dict d2 on d1.pos=d2.pos-1 and d1.pid=d2.pid
where d1.wid = [id слова 'хорошая' в словаре]
and d2.wid = [id слова 'погода' в словаре]


на сАмом деле поле pos проиндексировано. это я в первом посте упустил при записи.

test1111
прошу прощения, точнее вот так:

select p.* from
(
select w1.pid from t_word w1
inner join t_word w2 on w1.pos=w2.pos-1 and w1.pid=w2.pid
where w1.wid = [id слова 'хорошая' в словаре]
and w2.wid = [id слова 'погода' в словаре]
) fp
left join t_phrs p on p.id = fp.pid


спасибо. но так гораздо медленнее, чем в запросе из первого пОста. при поиске четырёх слов медленнее аж в 5 раз.
10 сен 09, 14:21    [7642277]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
vv40in,

Приведите скрипты создания таблиц с индексами без ошибок.

ЗЫ. У Вас ошибка в проектировании. Между сущностями "Слово" и "Фраза" отношение многие-ко-многим, а не один-ко-многим как у Вас
10 сен 09, 14:46    [7642519]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
vv40in,

И про планы уже упоминали. Без них топик превращается в пустой разговор ни о чем.
10 сен 09, 14:48    [7642532]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
Senya_L
Приведите скрипты создания таблиц с индексами без ошибок.

вот:
CREATE TABLE T_DICTIONARY (id int IDENTITY(1,1) NOT NULL,text nvarchar(64)COLLATE Cyrillic_General_CI_AS NOT NULL)ON Data_Dictionary
CREATE  UNIQUE  INDEX IX_T_DICTIONARY ON T_DICTIONARY(text)ON Index_DictionaryWord
ALTER TABLE T_DICTIONARY ADD CONSTRAINT PK_T_T_DICTIONARY PRIMARY KEY CLUSTERED(id)ON Data_Dictionary

CREATE TABLE t_word_ids(word_id int NOT NULL,phrase_id int NOT NULL,pos int NOT NULL)ON Data_Billing
ALTER TABLE word_ids  WITH NOCHECK ADD  CONSTRAINT FK_word_ids_T_DICTIONARY FOREIGN KEY(word_id)
REFERENCES T_DICTIONARY(id)
ALTER TABLE word_ids CHECK CONSTRAINT FK_word_ids_T_DICTIONARY
CREATE NONCLUSTERED INDEX IX_word_ids ON word_ids(word_id ASC)ON Index_WordId
CREATE NONCLUSTERED INDEX IX_word_ids_1 ON word_ids(phrase_id ASC) ON Index_WordId
CREATE NONCLUSTERED INDEX IX_word_ids_2 ON word_ids(pos ASC) ON Index_WordId

CREATE TABLE t_prases(Id bigint IDENTITY(1,1) NOT NULL, SysTime datetime, phrase nvarchar(2500), InterfaceID int CONSTRAINT PK_t_prases PRIMARY KEY CLUSTERED(Id)ON Data_Billing)ON Data_Billing
CREATE  INDEX IX_t_prases_SysTime ON t_prases(SysTime) ON Index_SysTime
CREATE  INDEX IX_t_prases_interface_id ON t_prases(interfaceID) ON Index_Interface_Id

вот запрос (поиск четырёх слов подряд):
SELECT  TOP 3000  * 
FROM T_phrases b WITH (NOLOCK)
 inner join T_WORD_IDS w1 on b.id=w1.phrase_id 
 inner join T_WORD_IDS w2 on b.id=w2.phrase_id and w1.pos=w2.pos-1
 inner join T_WORD_IDS w3 on b.id=w3.phrase_id and w2.pos=w3.pos-1
 inner join T_WORD_IDS w4 on b.id=w4.phrase_id and w3.pos=w4.pos-1
 inner join T_DICTIONARY d1 on d1.id=w1.word_id
 inner join T_DICTIONARY d2 on d2.id=w2.word_id 
 inner join T_DICTIONARY d3 on d3.id=w3.word_id
 inner join T_DICTIONARY d4 on d4.id=w4.word_id
WHERE InterfaceId=1 AND SysTime<=CONVERT(datetime,'2009-09-10 23:59:59', 120) AND SysTime>=CONVERT(datetime, '2000-01-01 00:00:00', 120)
 and d1.text='Нечего' AND  d2.text='мне' and d3.text='мозг' AND  d4.text='парить'
ORDER BY [SysTime] DESC 

план прикреплён (не знаю как его правильно публиковать).
запрос выполнялся 14 сек на маленьких таблицах:
T_DICTIONARY: 4.133 млн строк (в реальности видел 12 млн)
T_WORD_IDS: 28.714 млн строк (в реальности видел 80 млн)
T_phrases: 65 тыс строк (в реальности видел 4.5 млн. много слов с самыми разнообразными ошибками, несколько различных языков,кодировок, пр.)

Senya_L
У Вас ошибка в проектировании. Между сущностями "Слово" и "Фраза" отношение многие-ко-многим, а не один-ко-многим как у Вас

в чём проявляется ошибка? вообще-то я подразумеваю как раз многие-ко-многим.

что касается экспериментов с mssql fts.
на машине CPU: Intel core2duo 2xCPU 2666 MGz с RAM 1 GB выполнение последовательности 1000 запросов вставки строк по 4-10 слов происходит 4-6 секунд !!! .
а надо за секунду до 100 тыс строк (по 4-20 слов).

К сообщению приложен файл (explan.sqlplan.rar - 5Kb) cкачать
10 сен 09, 16:40    [7643506]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
извиняюсь. ошибочка. перепутал местами таблицы

надо читать:
запрос выполнялся 14 сек на маленьких таблицах:
T_phrases: 4.133 млн строк (в реальности видел 12 млн)
T_WORD_IDS: 28.714 млн строк (в реальности видел 80 млн)
T_DICTIONARY: 65 тыс строк (в реальности видел 4.5 млн. много слов с самыми разнообразными ошибками, несколько различных языков,кодировок, пр.)
10 сен 09, 16:44    [7643530]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
vv40in
извиняюсь. ошибочка. перепутал местами таблицы

надо читать:
запрос выполнялся 14 сек на маленьких таблицах:
T_phrases: 4.133 млн строк (в реальности видел 12 млн)
T_WORD_IDS: 28.714 млн строк (в реальности видел 80 млн)
T_DICTIONARY: 65 тыс строк (в реальности видел 4.5 млн. много слов с самыми разнообразными ошибками, несколько различных языков,кодировок, пр.)
предлагаю изменить декларацию индекса IX_word_ids на
CREATE UNIQUE CLUSTERED INDEX IX_word_ids ON word_ids(word_id ASC, phrase_id asc)
и сделать всем индексам REBUILD (на всякий пожарный).
10 сен 09, 17:58    [7644107]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
Senya_L,
Senya_L
предлагаю изменить декларацию индекса IX_word_ids на
CREATE UNIQUE CLUSTERED INDEX IX_word_ids ON word_ids(word_id ASC, phrase_id asc)
и сделать всем индексам REBUILD (на всякий пожарный).

word_id (как и др.столбцы) не уникальны в таблице word_ids.
а CLUSTERED нужен ?
10 сен 09, 18:35    [7644389]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
vv40in
извиняюсь. ошибочка. перепутал местами таблицы

надо читать:
запрос выполнялся 14 сек на маленьких таблицах:
T_phrases: 4.133 млн строк (в реальности видел 12 млн)
T_WORD_IDS: 28.714 млн строк (в реальности видел 80 млн)
T_DICTIONARY: 65 тыс строк (в реальности видел 4.5 млн. много слов с самыми разнообразными ошибками, несколько различных языков,кодировок, пр.)


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

10 сен 09, 18:37    [7644407]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
vv40in
Senya_L,
Senya_L
предлагаю изменить декларацию индекса IX_word_ids на
CREATE UNIQUE CLUSTERED INDEX IX_word_ids ON word_ids(word_id ASC, phrase_id asc)
и сделать всем индексам REBUILD (на всякий пожарный).

word_id (как и др.столбцы) не уникальны в таблице word_ids.
а CLUSTERED нужен ?
Я просто опечатался и не включил позицию слова. У Вас, я так понимаю, одно слово может несколько раз входит в одну фразу, но в разные положения.

Насчет CLUSTERED - да, обязательно. У Вас таблица в "куче" и судя по плану более половины затрат идет на RID Lookup.
10 сен 09, 19:02    [7644592]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
Alexes
Member

Откуда:
Сообщений: 1100
vv40in
в расписанный выше набор таблиц я пишу ч-з ADO как раз скоростью 200 тыс строк в минуту. данные к нам поступают до 100 тыс строк в минуту, но надо обеспечить солидный запас...
кстати, не может ли кто посоветовать более быстрый интерфейс для mssql, чем ADO?

Если бы не было возможности использовать FTS, то я бы отказался от identity на t_prases.Id и T_DICTIONARY, генерировал бы эти идентификаторы в клиентском приложении, разбивал фразы на слова тоже в клинтском приложении, и загружал бы данные во все таблицы с помощью Bulk copy.
Кстати, у вас не совпадают типы данных столбцов t_prases.Id и t_word_ids.phrase_id.
10 сен 09, 19:03    [7644597]     Ответить | Цитировать Сообщить модератору
 Re: слишком медленный поиск  [new]
vv40in
Member

Откуда:
Сообщений: 122
Alexes
Если бы не было возможности использовать FTS, то я бы отказался от identity на t_prases.Id и T_DICTIONARY, генерировал бы эти идентификаторы в клиентском приложении, ...
для чего отказываться от identity? и пр...?

Alexes
я бы ... разбивал фразы на слова тоже в клинтском приложении, и загружал бы данные во все таблицы с помощью Bulk copy.
примерно так и делаю при записи.

Alexes
Кстати, у вас не совпадают типы данных столбцов t_prases.Id и t_word_ids.phrase_id.
так давно исторически сложилось, а я здесь недавно. bigint на int заменить ужЕ невозможно

если я правильно понял, Вы ведете речь о заполнении таблиц. и это может повлиять лишь на скорость заполнения, но не поиска.
при заполнении (всё делается различными потоками):
1) предложение разбивается на словА
2) словА пачками записываются в T_DICTIONARY (возвращаются id-ы = word_id в T_WORDS_IDS)
3) предложения пачками записывается в T_PHRASES (возвращаются id-ы = phrase_id в T_WORDS_IDS)
4) заполняется T_WORDS_IDS (также пачками)
10 сен 09, 19:35    [7644758]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить