text based database

[uniqueman]

Возникла следущая задача.

Клиентское приложение будет получать и сохранять очень много текстовой информации в таком виде "header" + "body". То есть приходит комбинация хедер плюс тело и я сохраняю это в базе (очень грубо говоря две колонки в таблице). Длина обоих полей заранее неизвестна и может быть любой.

В последующем эту информацию надо будет анализировать. Пример:

Мне надо найти все header + body поля, которые содержат слово "Morgan Stanley". Неважно какое поле (хедер или тело) содержит это ключевое слово. Другими словами производить text search.

Существуют ли такие базы данных (или какие то другие тулы), которые ориентированы именно на работу с текстом в таком виде. Я слышал что Yukon SQL Server вроде оптимизирован для этого. Если сохранять просто в SQL Server допустим и потом писать запрос типа

"SELECT * FROM Table WHERE Header LIKE '%keyword%' OR Body LIKE '%keyword%'

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

Подскажите идеи
Спасибо

[Win32nipuh]

Возникла следущая задача.

Клиентское приложение будет получать и сохранять очень много текстовой информации в таком виде "header" + "body". То есть приходит комбинация хедер плюс тело и я сохраняю это в базе (очень грубо говоря две колонки в таблице). Длина обоих полей заранее неизвестна и может быть любой.

В последующем эту информацию надо будет анализировать. Пример:

Мне надо найти все header + body поля, которые содержат слово "Morgan Stanley". Неважно какое поле (хедер или тело) содержит это ключевое слово. Другими словами производить text search.

Существуют ли такие базы данных (или какие то другие тулы), которые ориентированы именно на работу с текстом в таком виде. Я слышал что Yukon SQL Server вроде оптимизирован для этого. Если сохранять просто в SQL Server допустим и потом писать запрос типа

"SELECT * FROM Table WHERE Header LIKE '%keyword%' OR Body LIKE '%keyword%'

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

Подскажите идеи
Спасибо

Full-text search как раз то, что надо.
Правда запросы будут выглядеть по-другому, например так
"SELECT * FROM Table WHERE CONTAINS(*, FORMASOF(INFLECTIONAL,keyword')"

[uniqueman]

хорошо, а нормально ли отреагирует SQL server 2000 если я попытаюсь сохранить в поле допустим текст ну размером порядка 200 листов ворда Нормально ли это для этой базы или все же надо искать что то, которое специально ориентировано на работу с текстом?

[Митяй]

Тексты такого рода хранятся в BLOB / CLOB (Binary/Character Big OBjects) и ограничения на объем "в листах Ворда" накладываются ограничениями на общую длину blob. Как правило, это не менее 2 GB.
Поиск производится специально пристегиваемыми продуктами третьих фирм - например, для Информикса это Escalibur datablade http://www-3.ibm.com/software/data/info ... liburtext/

С ростом объемов хранимого текста могут полезть подводные камни - часто сильно ухудшается время поиска/индексации

[uniqueman]

Только что сейчас узнал более подробную спецификацию. В день примерно будет сохранятся 15К текстовой информации. Не все конечно в одной строке По частям. Мне кажется что SQL Server справится с такой нагрузкой нормально и full text search будет нормально работать. Или все же обратить внимание на продукты третьих фирм для поиска?

[camel]

в оракле эта фича называется Oracle Text, она есть как в Enterprise, так и в Standard Edition - т.е. если оракл уже имеется, не надо ничего покупать дополнительно

документы могут быть в любых форматах - doc, ppt, xls, pdf, html, txt и т.д. - они могут храниться как внутри базы в полях типа BLOB/CLOB, так и снаружи в файлах или в интранете

все технические детали можно найти здесь:
http://download-west.oracle.com/docs/cd ... 17/toc.htm
http://download-west.oracle.com/docs/cd ... 18/toc.htm

[Hatih]

Простите бедного униксоида-ембедщика, а зачем вам вообще БД? Большая директория. header=filename, body=file contents. А великий и могучий grep - вместо SQL запросов.

Ну уж на самый крайний случай (ext3fs плохо себя чуствует с сотней тысяч файлов в одной директории) - dbm/gdbm.

[RGoo]

А можно уточнить ? Меня вот схожий вопрос волнует - есть куча юзеров, у каждого свой XML файл с данными. Пока дело касается только генерации отчетов по этим данным - все ОК. А если встанет вопрос контекстного поиска ? Как быть ? Сливать все файлы в базу ? Ну есть у Oracle родные средства для поддержки XML, а у MySQL, скажем нет. Если брать вопрос "теоритически", независимо от конкретых фич базы - как ПРАВИЛЬНО поступить в таком случае :
1) Оставить файлы по user-директориям и grep
2) Свалить их все в одну и опять grep
3) Засунуть их в базу целиком в поле и искать там
4) Дробить по таблицам\записям по тэгам XML
5) Просто и не балуя и использовать средства\фичи\функции самого XML типа XPath и XSQL(?) и файлы как лежали так и лежат ?

[A. Fig Lee]

Я для текста делал свою базу.
Смысл в следующем:
1) Спейс реаллокируется блоками - если нет места - сразу резервируется целый блок
2) База состоит ис линкед листа етих блоков, блоки сами по себе достаточно большие
3) В блоке хранится только один филд, то есть как минимум нужно столько же блоков, сколько и фиелд. Ето удобно при поиске - данные для филда хранятся непрерывно, легко загрузить и сделать плейн сёч (пустые места - спейс, нот 0).
4) Каждый блоцк имеет хеадер где указана длина записи в филде и старт
5) Все рекорды в филде алайнед (например на 64 байта) - ето вейст оф спейс, но высокая скорость поиска - при поиске луплю через етот алайнмент. Если нашел - тогда побежал в хеадеры и в первом приближении на такое же смещение где и текст обнаружил. Методом половинного деления (почти, чуть чуть изменен алгоритм) нахожупоинтер к етому филду и длину.
6) Измерения показали в 100 мегабайтном файле с 6 филдс, алайнмент 32 удается найти 90,000 записей в минуту на Пентиум 400, что гдето в 3 раза медленнее простого копирования файла

[SiarheiH]

Для IBM DB2 есть
Text Extender, для полнотекстового поиска.
XML Extender, для XML и он может работать в двух вариантах, либо хранить целиком XML, либо разбивать его на тэги и хранить как колонки.

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

[Win32nipuh]

А можно уточнить ? Меня вот схожий вопрос волнует - есть куча юзеров, у каждого свой XML файл с данными. Пока дело касается только генерации отчетов по этим данным - все ОК. А если встанет вопрос контекстного поиска ? Как быть ? Сливать все файлы в базу ? Ну есть у Oracle родные средства для поддержки XML, а у MySQL, скажем нет. Если брать вопрос "теоритически", независимо от конкретых фич базы - как ПРАВИЛЬНО поступить в таком случае :
1) Оставить файлы по user-директориям и grep
2) Свалить их все в одну и опять grep
3) Засунуть их в базу целиком в поле и искать там
4) Дробить по таблицам\записям по тэгам XML
5) Просто и не балуя и использовать средства\фичи\функции самого XML типа XPath и XSQL(?) и файлы как лежали так и лежат ?

Я одно не могу понять, уважаемые коллеги:
Grep и полнотекстовый поиск - это "две большие разницы".
Grep хранит индексы?
индексирует что называется "на лету"?
умеет искать словоформы?

????? (

Для RGoo: я бы зная постановку задачи определился бы с платформой и сервером. От их выбора зависит решение. Вряд ли удастся сделать нечто независимое от них.

Если, например, это Windows и MS SQL Server - моногое из ваших пунктов решается без особых проблем, файлы храинте на дисках, работаете с индексным сервером и SQL Server.

Windows умеет индексировать многие типы файлов, есть фильтры третьих производителей, на худой конец незнакомые типы могут быть проиндексированы как бинарные.

[f_evgeny]

А можно уточнить ? Меня вот схожий вопрос волнует - есть куча юзеров, у каждого свой XML файл с данными. Пока дело касается только генерации отчетов по этим данным - все ОК. А если встанет вопрос контекстного поиска ? Как быть ? Сливать все файлы в базу ? Ну есть у Oracle родные средства для поддержки XML, а у MySQL, скажем нет. Если брать вопрос "теоритически", независимо от конкретых фич базы - как ПРАВИЛЬНО поступить в таком случае :
1) Оставить файлы по user-директориям и grep
2) Свалить их все в одну и опять grep
3) Засунуть их в базу целиком в поле и искать там
4) Дробить по таблицам\записям по тэгам XML
5) Просто и не балуя и использовать средства\фичи\функции самого XML типа XPath и XSQL(?) и файлы как лежали так и лежат ?

glimpse?

[mzn]

Lotus Notes?