Вопрос по SQL Server Yukon

[uniqueman]

Можно ли задать full text seach в новой версии Yukon как case sensitive?

В предыдущих версиях SQL Server такой поиск был строго case insensitive благодаря природе организации поиска (использование отдельного сервиса для индексирования и поиска и тому подобное).

Интергрирован ли full text search в новой версии полностью в ядро базы и позволяет ли новая версия проводить case sensitive поиск?

[8K]

Интергрирован ли full text search в новой версии полностью в ядро базы и позволяет ли новая версия проводить case sensitive поиск?

Я бы не рассчитывал на это. MS Search по-прежнему цветет и пахнет.

[uniqueman]

Уважаемый 8К,

Как правильно организовать работу full text search на SQL Server 2000. Каждый день с этим search какие то проблемы. Выполнил все по указаниям, поставил все как надо. Проходит день и опять что то сбивается и результаты выборок становятся неправильными.

Если нужны исходдные данные, то напишу с радостью. Запарился я уже с этим full text search.

[8K]

Ну, не то чтобы я разбирался, как оно там в SQL Server 2000 устроено (это вообще болото страшное, к тому же, я пришел уже после того, как его шипнули)...

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

[uniqueman]

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

Сейчас. Вот как обстоит дело.

Есть таблица TABLE. В ней два поля типа text настроены под full text search. Настроил индекс, сделал full population и поставил Change tracking with backgound indexing.

В базу льется информация примерно 10К в секунду. Мне надо обновлять индексы сразу же, именно поэтому выставил change tracking.

Каждую ночь из таблицы удаляются записи некоторые. Вопрос сразу. Надо ли после этого делать full population заново? Я сначала делал, потом по совету приветовцев перестал делать. Если надо, то надо ли после этого заново переустанавливать change tracking with background indexing?

Периодечески калатог входит в состояние Shutdown. Что это значит и почему происходит? После этого судя по всему никакого индексирования не происходит. Приходится делать Rebuild catalog чтобы опять вернутся в нормальное состояние

Сейчас допустим я пишу запрос

SELECT *
FROM TABLE
WHERE CONTAINS (*, 'full')

возвращаются записи как содержащие слово full так и НЕ содержащие этого слова. Как я проверяю? Я в коде просто создаю переменную типа string, присваиваю ей возвращенный результат и вызываю функцию find с параметром full. Возвращается -1, то бишь слово не найдено. Тогда для подтверждения я просто копирую текст который мне возвращатся в текстовый редактор и пытаюсь найти слово full там. Также не находит.

Какие параметры надо проверить, чтобы удостоверится что все настроено правильно? Гемор имею каждый день с FTS

Спасибо

[uniqueman]

и еще. Возможно ли как то настроить case sensitive full text search ?

[8K]

Возможно ли как то настроить case sensitive full text search ?

Нет.

[8K]

Каждую ночь из таблицы удаляются записи некоторые. Вопрос сразу. Надо ли после этого делать full population заново?

Если некоторые - то не надо. Индекс, правда, разбухает. Хотя при включенном change tracking - не должен. Ввиду асинхронности индексирования может влиять на результаты поиска (например, запись удалена, затем вставлена с тем же самым значением full-text key, но с другим содержимым full-text column - пока индекс не обновится, вы будете иногда получать эту запись, даже если она не удовлетворяет критерию поиска). Если значения full-text key не переиспользуются, то все нормально.

[8K]

пишу запрос

SELECT *
FROM TABLE
WHERE CONTAINS (*, 'full')

возвращаются записи как содержащие слово full так и НЕ содержащие этого слова. Как я проверяю? Я в коде просто создаю переменную типа string, присваиваю ей возвращенный результат и вызываю функцию find с параметром full. Возвращается -1, то бишь слово не найдено. Тогда для подтверждения я просто копирую текст который мне возвращатся в текстовый редактор и пытаюсь найти слово full там. Также не находит.

Вы сказали, что там две колонки зарегестрированы для индексирования. Вы в обеих колонках текст ищете? Вообще, этот изврат с find и тестовым редактором я не понимаю для чего нужен. LIKE '%full%' должно работать не хуже.

Убедитесь также, что эта "неправильная" запись не висит в sysfulltextnotify. Может, она просто еще не дошла до MS Search по какой-то причине. В принципе, можно посмотреть, что там в каталоге находится, но я не уверен, что эту программу вместе с сервером поставляют, да и даже если бы она была - затрахаешься ей правильные параметры передавать.

[uniqueman]

Если некоторые - то не надо. Индекс, правда, разбухает.

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

Удаляются примерно 4000 записей каждую ночь. Это "некоторые" или нет?

Ввиду асинхронности индексирования может влиять на результаты поиска (например, запись удалена, затем вставлена с тем же самым значением full-text key, но с другим содержимым full-text column - пока индекс не обновится, вы будете иногда получать эту запись, даже если она не удовлетворяет критерию поиска). Если значения full-text key не переиспользуются, то все нормально.

Не могли бы Вы подробнее объяснить, что значит "не используются full text key".

[uniqueman]

Вы сказали, что там две колонки зарегестрированы для индексирования. Вы в обеих колонках текст ищете?

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

Вообще, этот изврат с find и тестовым редактором я не понимаю для чего нужен. LIKE '%full%' должно работать не хуже.

когда я показываю текст в клиентском приложении, то мне нужно ключевые слова, по которым я осуществлял поиск выделять другим цветом. Следовательно мне надо найти их в контроле. Текст показывается в CRichEditCtrl. В этом контроле есть функция FindText, которая как раз ищет текст. Так вот в некоторые момент выделения цветом не происходит. Я сначала думал, что FindText глючит, поэтому ради эексперимента скопировал текст из контрола в текстовый редакторе и попытался найти там. Тоже пусто.

[8K]

Если некоторые - то не надо. Индекс, правда, разбухает.

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

Удаляются примерно 4000 записей каждую ночь. Это "некоторые" или нет?

Зависит от размера таблицы. Если в ней всего 20M записей - то "некоторые", а если всего 20K - наверное, проще делать full crawl после удаления.

[uniqueman]

Если некоторые - то не надо. Индекс, правда, разбухает.

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

Удаляются примерно 4000 записей каждую ночь. Это "некоторые" или нет?

Зависит от размера таблицы. Если в ней всего 20M записей - то "некоторые", а если всего 20K - наверное, проще делать full crawl после удаления.

размер всей базы - 300 мегабайт. Учитывая что это единственная таблица созданная мной, то наверное она и занимает основную часть всей базы. Значит "некоторые"

[8K]

Не могли бы Вы подробнее объяснить, что значит "не используются full text key".

переиспользуются.

Когда вы создаете full-text index для таблицы, вы назначаете один из ее UNIQUE single column индексов full-text key. Грубо говоря, значения full-text key хранятся в full-text индексе вместе с содержимым full-text columns.

Когда вы в своем запросе используете CONTAINS, он неявно превращается в вызов CONTAINSTABLE, который, в свою очередь, является прямым вызовом MS Search, результат - значения full-text key, удовлетворяющих критерию поиска. После этого результат JOIN'а с исходной таблицей ограничивает набор записей в исходном запросе.

Если вы обновили запись в таблице (удалили все вхождения слова foo), но она еще не ушла для индексирования MS Search'ем, вы можете получить обновленную запись как результат запроса CONTAINS(*, 'foo'). Это неверный результат.

Другая ситуация - если запись была удалена, а затем вновь создана, причем значение full-text key для новой записи - то же самое, что и удаленной. По-моему, у нас были баги насчет того, в каком порядке MS Search получает и обрабатывает эти два события. Если сперва DELETE, а потом INSERT - все нормально. Если наоборот - вы можете никогда не увидеть свою вновь вставленную запись, даже если она на самом деле содержит foo. Впрочем, если я не путаю и эти баги были действительно в SQL Server 2000, то они уже исправлены в одном из сервис-паков.

[8K]

Вы сказали, что там две колонки зарегестрированы для индексирования. Вы в обеих колонках текст ищете?

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

Я имел в виду, когда вы результат проверяете при помощи текстового редактора.

Еще хотел добавить, что есть принципиальная проблема, что корректность результатов не обеспечивается даже в пределах одной записи. Например, если в вашей таблице два BLOB'а (например, TEXT), то пока MS Search индексирует первую колонку текущей записи, SQL Server может обновить всю запись. Первая колонка использует старые значения, а вторая - новые.

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

[uniqueman]

Я имел в виду, когда вы результат проверяете при помощи текстового редактора.

да конечно. первая колонка то короткая, там текста обычно очень мало. Зато вторая большая. СТроки которые туда вставляются могут быть легко по 8К текста.

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

перестроил нафиг весь каталог, вроде стало работать как надо. надолго ли Сердцем чую завтра приду на работу и опять что то не так будет.

Спасибо, 8К, за помощь и объяснения. По возможности буду держать в курсе, может что нарою, найду в чем проблема, основываясь на Ваших подсказках

[Dmitry67]

можно только порадоваться что я забил на это дело и написал свой full text search

[8K]

можно только порадоваться что я забил на это дело и написал свой full text search

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

Проблема в том, что full-text search в SQL Server'е никому по большому счету не нужен, разве что для галочки. Но у нас все записано, все фичи пронумерованы. Т.е. мы знаем, чего пипл хочет. Yukon FTS, конечно, не такой позорный, но за кой-какие закидоны я бы кой-кому уши пообрывал, вот только руки коротки.

А uniqueman'у для hit highlighting'а можно разве что ORACLE или DB2 посоветовать.

[uniqueman]

Проблема в том, что full-text search в SQL Server'е никому по большому счету не нужен, разве что для галочки.

ну почему же так категорично. А как можно заменить функциональность эту другим способом? Как быстро искать информацию в большом объеме текстовой информации?

Знаю что существуют специальные тулы, направленные именно на поиск текста. Но мы работаем с SQL Server уже давно. Эта база зарекомендовала себя с очень неплохой стороны, по крайней мере проблем с ней мы никогда не имели. Поэтому мы не хотим переходить ни на какие другие продукты, хотим чтобы вся работа поддерживалась именно SQL Server.

большинство тулов, которые я встречал в инете, не позволяют обращатся к ним через стандартные DB interfaces, такие как ODBC, OLE DB и тому подобное. Именно поэтому я стараюсь настроить full text search у себя.

Однако если результаты работы full text search будут из рук вон плохи, то придется искать замену

Yukon FTS, конечно, не такой позорный, но за кой-какие закидоны я бы кой-кому уши пообрывал, вот только руки коротки.

ну раз уж заговорили, скажите пару слов, какие улучшения будут в Юконе на этот счет?

А uniqueman'у для hit highlighting'а можно разве что ORACLE или DB2 посоветовать.

ну highlighting никак не связан с базой то Он на клиенте выполняется. Оракл тяжелый неимоверно и под него машину надо соотвествующую. С DB2 дело не имел ни разу. А что там full text search работает гораздо лучше чем в SQL SErver?

[Dmitry67]

Огласите еще объемы пожалуйста

Количество документов
KB текста на документ
Обновлений в день

[uniqueman]

за сутки (от периода удаления записей до след. удаления) в базу втекает примерно 6000 - 8000 записей. Каждая запись по 8К текста примерно. обновления происходят по разному, может быть 5 записей в секунду, может быть одна запись за минуту.

[8K]

Проблема в том, что full-text search в SQL Server'е никому по большому счету не нужен, разве что для галочки.

ну почему же так категорично. А как можно заменить функциональность эту другим способом? Как быстро искать информацию в большом объеме текстовой информации?

Пользователям full-text search, конечно, нужен. Я больше про то, что эта нужда среди нашего upper management'а как-то не особенно ощущается.

[8K]

ну раз уж заговорили, скажите пару слов, какие улучшения будут в Юконе на этот счет?

В основном - быстрее он, да и масштабироваться худо-бедно научили. Раньше время индексирования экспоненциально росло от размера таблицы, а многопроцессорность как бы не совсем (т.е. совсем не) помогала. Работает надежнее. Есть несколько полезных примочек, но пока еще рано говорить. Вроде бы в бете они не появлялись. Есть крупные и очень полезные фичи, которые должны были в бету попасть, но точно не знаю, так что тоже лучше помолчу. Будет время - поищу help-file от беты, посмотрю, что в ней уже показано. Тогда можно будет более предметно поговорить.

[8K]

большинство тулов, которые я встречал в инете, не позволяют обращатся к ним через стандартные DB interfaces, такие как ODBC, OLE DB и тому подобное. Именно поэтому я стараюсь настроить full text search у себя.

Однако если результаты работы full text search будут из рук вон плохи, то придется искать замену

Ну, крутые пацаны за пару-тройку недель пишут нормальный быстрый поиск и индексирование без всяких излишеств. Индекс построить не проблема (доставать данные через SQL OLE DB). Запрос сделать - тоже (поиск должен прикидываться OLE DB provider'ом, и тогда его можно через OpenRowset() изнутри T-SQL'а звать).

Но хочется, конечно, побольше синтаксического сахара. С обеих сторон. Попробуйте, скажем, немецкий текст на слова разбить. Это не на пару-тройку недель работа. Можно, впрочем, уже существующие компоненты звать. Или, с другой стороны, попробуйте переписать свои запросы так, чтобы вместо CONTAINS везде были OpenRowset/OpenQuery к msidx provider'у.

[8K]

Оракл тяжелый неимоверно и под него машину надо соотвествующую. С DB2 дело не имел ни разу. А что там full text search работает гораздо лучше чем в SQL SErver?

Я бы сказал, что у них полезных фич больше, т.е. они к пользователю лицом, а не задницей. Впрочем, Yukon FTS на порядок лучше SQL Server 2000, а следующая версия будет еще лучше Yukon'а.